Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Migration of unmigrated content due to installation of a new plugin

Nota de Devolução de Poder de Terceiro / Nota de Retorno

Produto:

 Microsiga Protheus®

Ocorrência:

DEFINIÇÃO DE CENÁRIO:

 Protheus®

Versões:

A partir da 11.8

Ocorrência:

Explicativo sobre os tipos de utilização do poder de/em terceiro disponíveis no produto Protheus

Ambiente:Faturamento (SIGAFAT)

 


Conceito

Para entender um pouco mais do conceito de poder DE/EM terceiro veja nosso vídeo How To em: How To | MP - SIGAFAT - Conceito: Poder De/Em Terceiros

Se o produto ao qual deu entrada, não foi efetivamente uma compra, mas sim, a entrada de determinado produto (de Cliente ou Fornecedor) do qual se sabe que deverá ser devolvido (exemplo: entrada para conserto, beneficiamento, movimentação de vasilhame, etc)

...

, caracteriza-se uma movimentação que controla Poder de Terceiros

...

(essa documentação).


Dica
titleDICA:

Caso o produto tenha sido efetivamente comprado, e por um motivo qualquer esta compra não é mais devida, sendo necessário devolver a compra;

...

então neste caso, consulte o procedimento da FAQ: FAT0007_Emitir_Nota_de_Devolução_de_Compra

Aviso
titleIMPORTANTE: 
  • Para emitir um Documento de Devolução no módulo Faturamento, por meio da emissão de um Pedido e respectivo Documento de saída, é necessário que sejam informados os itens: NF, Série e Item de origem, de forma a estabelecer relacionamento com o Documento Original a ser devolvido.
    Isto

...

  • pois, a possibilidade de se realizar tal operação sem o devido relacionamento anula a integridade de dados no sistema.

...

  • O SEFAZ rejeita o documento transmitido sem os devidos relacionamentos.

...


  • O indicado é que

...

  • se houver grande demanda de tal operação em seu negócio e,

...

 

...

Passo a passo:

PREMISSAS:

 - A NF de Origem (NF de entrada) deve estar devidamente lançada nos documentos de Entrada como Tipo Beneficiamento;
- O TES deve controlar Poder de Terceiro caracterizando a Remessa do Cliente/Fornecedor à sua empresa (F4_PODER3 = Remessa);
- O TES utilizado na Nota de Entrada deve possuir em seu cadastro o TES compatível, de Saída, caracterizando a Devolução (registrar no F4_TESDV);
- O TES registrado no campo F4_TESDV também deve controlar Poder de Terceiro caracterizando o Retorno de sua empresa ao Cliente/Fornecedor (F4_PODER3 = Devolução);
- O CFOP da NF de Entrada deve ser um CFOP que caracteriza operação de remessa;
- As tabelas SC6 - Itens do PV, SC9 - Liberação e SD2 - Itens Doc. de Saída, não devem conter registros com o campo "XX_NFORI" preenchido para a NF/Item/Quantidade em questão consumindo todo o saldo; caso contrário, o sistema irá associar que já fora realizada a Devolução (Já há outro Pedido de Venda para Devolução dessa Nota) e o processo não será devidamente realizado;
- O ambiente deve estar atualizado conforme Portal do Cliente para contemplar as últimas correções realizadas nos Fontes envolvidos no processo.
 
PROCESSO:
- Acesse Pedido de Venda - MATA410;
- Ações relacionadas / Retornar
- Selecione se o retorno é de Fornecedor ou Cliente e relacione a Entidade;
- Preencha o intervalo de datas no qual a nota pode ser localizada (atenção às datas registradas. Este parâmetro irá inibir a apresentação de certas notas na rotina);
- Tipo de seleção: Por fornecedor permite realizar marcação de "n" notas desta entidade a retornar / Por documento permite realizar a seleção de uma nota específica desta entidade a retornar;- O sistema exibe as NFs de entrada para que marque / selecione a(s) NF(s) que deseja devolver;
- Ao confirmar, o sistema carrega Pedido de Venda (com os dados da NF de Origem) para que seja completado, liberado e Preparado Doc. de saída.

...

  • se for considerado inviável pela própria instituição incluir a Nf de Origem no sistema apenas quando houver necessidade de devolve-lá (ajustando internamente as interferências na regra de negócio como estoque/custos);
    Então, que se alimente previamente o volume de dados (determinado período de registros de Documentos de Entrada/ Saída) na ocasião de implantação do módulo, reduzindo impactos quando se fizer necessário registrar operações relacionadas.


Como passar a usar a devolução com poder de/em terceiros no faturamento

Deck of Cards
startHiddenfalse
effectDuration0.

...

5
idVincular RA / Desvincular RA
effectTypehorizontal
loopCardstrue
Card
defaulttrue
idPremissas (pré-retorno
labelPremissas (pré-retorno)
ETAPACAMPO(S) PARA COLOCAR A INFORMAÇÃO/VISUALIZÁ-LA
NF de Origem (Entrada - MATA103) deve estar devidamente preenchida como beneficiamentoC103TIPO == 'B - Beneficiamento' [SF1]
O TES Entrada deve controlar Poder de Terceiro caracterizando a Remessa à sua empresaF4_PODER3 == 'R - Remessa'
O TES Entrada de entrada deve ter TES Saída para retornar, idêntico, inclusive também controlando poder de/em terceiros com 'Remessa'F4_TESDV (da NF entrada) == 'TES Saída'     (F4_PODER3 == Remessa) [também controla poder de terceiros]

Nas tabelas dos pedidos de venda não devem conter registros com o campo "XX_NFORI" preenchido para a NF  |  Item  |  Quantidade em questão consumindo algum saldo.

Caso contrário, o sistema irá associar que já fora completamente realizada, não tendo mais o que retornar, ou não será possível retornar a quantidade desejada.

C6_NFORI + C6_SERIORI + C6_ITEMORI de todos os registros da SC6 sobre uma NF entrada não pode ter o mesmo valor D1_QTDEV da própria NF Entrada.


D2_NFORI + D2_SERIORI + D2_ITEMORI podem estar preenchidos com a NF Entrada caso a nota além de retornada estiver faturada.


Dica
titleOBSERVAÇÃO:
  • O parâmetro MV_DATAPD3 define um número de dias retroativos na pesquisa de notas com poder de/em terceiros na linha do item do Pedido de Vendas, ao pressionar a tecla [F4] no campo "Quantidade (C6_QTDVEN)" é gerada uma interface gráfica para digitação do intervalo de data de pesquisa das notas de poder de terceiros.


KCS: Cross Segmentos - TOTVS Backoffice (Linha Protheus) - SIGAFAT - Funcionamento do parâmetro MV_DATAPD3


A entrada deverá alimentar corretamente os campos de poder de terceirosD1_IDENTB6 e B6_IDENT
  • O ambiente deve estar atualizado conforme Portal do Cliente (LIB e Fontes do SIGAFAT e SIGACOM) para contemplar as últimas correções realizadas nos Fontes envolvidos no processo.
Card
defaulttrue
idProcesso (retorno)
labelProcesso (retorno)
  1. Acesse Pedido de Venda - MATA410 > Outras Ações > Retornar > Coloque o cliente ou o fornecedor > Preencha o intervalo de datas no qual a nota pode ser localizada (deve compreender a data do campo DDEMISSAO [NF Entrada, no cabeçalho])

  2. Tipo de seleção:
    Por fornecedor == Permite realizar marcação de múltiplas notas desta entidade a retornar
    Por documento == Permite realizar a seleção de uma nota específica desta entidade a retornar

  3. O sistema exibe as NFs de entrada para que marque / selecione a(s) NF(s) que deseja devolver > Ao confirmar, o sistema carrega Pedido de Venda (com os dados da NF de Origem) para que seja completado, liberado e Preparado Doc. de saída.
    Consulte também:

...

OBSERVAÇÃO:

...

Se

...

desejar,

...

ao

...

invés

...

de

...

realizar

...

o

...

processo

...

automático

...

em

...

Ações

...

relacionadas

...

/

...

Retornar,

...

é

...

possível

...

Incluir

...

Pedido

...

de

...

Vendas manual:
  1. Acesse Pedido de Venda - MATA410
  2. Inserir
  3. Selecione Tipo: Normal (para retorno de Clientes) ou Utiliza Fornecedor (para retorno de Fornecedor)
  4. Preencha manualmente o código do Produto e o TES de Retorno (relacionado no F4_TESDV do TES de entrada)
  5. Pressione "F4" no campo de Quantidade e selecione a NF que deseja devolver
Card
defaulttrue
idObservações
labelObservações (Sobre o processo)
  • O CFOP utilizado deve ser um CFOP que o SEFAZ considera válido para NFs de Devolução para que não resulte em Rejeição;


  • A Tag FinNFe do xml a ser transmitido deverá ser gerado com conteúdo 4 (que indica "Devolução") de forma a ser compatível com o CFOP de Devolução e não ocasionar Rejeição 327 / 328;


  • O CFOP não pode estar contido no parâmetro MV_DEVCFOP (este parâmetro armazena CFOPs que não são de devolução e faz com que a Tag FinNFe seja gerada com conteúdo 1 ao invés de 4);


  • Atente-se ao campo F4_AJUSTE no TES, pois caso esteja indicando se tratar NF de ajuste, irá gerar A Tag FinNFe com conteúdo 3;


  • O Alert DSNOTESDEV caracteriza inconsistência no processo. É necessário validar todo o procedimento e TES utilizados.



Card
defaulttrue
idSituações em que a exclusão da NF entrada é necessário
labelSituações em que a exclusão da NF entrada é necessário
  • Caso identifique que a nota de entrada foi lançada de forma errada em comparação às premissas mencionadas acima (por exemplo, com o Tipo diferente de Beneficiamento, ou com um TES que não está devidamente configurado);é necessário excluir o documento de entrada e lançar novamente, para então gerar o Pedido e Nota de saída. Não é possível apenas alterar algo no TES pois o comportamento não será mudado visto que a alteração foi depois de já ter lançado a Nota e realizados devidos relacionamentos.

    Não é procedimento correto alterar o cadastro de um TES! Caso identifique que lançou a nota com um TES que não está de acordo com o especificado, o correto é localizar outro TES já cadastrado que atenda aos requisitos, ou então, incluir o cadastro de um novo TES para atender à necessidade; e então, realizar o lançamento com o TES correto. Porém, deixar o outro TES intacto (pois alterações comprometem o histórico de movimentações no sistema).



  • Se validar a nota de entrada e estiver correta nos requisitos, tanto Tipo da nota quanto os TES com devidas amarrações, é possível, que algum TES já tenha sofrido alteração no cadastro (justamente o processo que não é indicado).

    Desta forma, para fins de TESTE, inclua uma nova nota de entrada igual a nota em questão (mesmo Cliente/produto/TES) e refaça o processo. Poderá validar que, se as amarrações de TES estiverem corretas, de acordo com o orientado aqui, o processo será concluído corretamente.
    Sendo assim, será de qualquer forma, necessário excluir a nota de entrada e lançar novamente para alimentar as devidas tabelas relacionadas (como por exemplo, SB6 - Poder de terceiro)




HELPS

Expandir
titleA410TOTAL

KCS: Cross Segmentos - TOTVS Backoffice (Linha Protheus) - SIGAFAT (Faturamento) - Helps A410TOTAL e A410TOTDPRC no Faturamento

Expandir
titleA410TOTDPRC

KCS: Cross Segmentos - TOTVS Backoffice (Linha Protheus) - SIGAFAT (Faturamento) - Helps A410TOTAL e A410TOTDPRC no Faturamento



Parâmetros

  • MV_LIBESB6: Indica se deve permitir a inclusão de NFE (F4_PODER3=D) com quantidade total da remessa e saldo financeiro a menor.

  • MV_BLOQSB6: A finalidade desse parâmetro é impedir que seja informado um valor unitário diferente do valor unitário do campo B6_PRUNIT.



Sugestões

Gostaria de sugerir uma implementação diferente ou uma melhoria nessa documentação? Abra um ticket para nós, a Equipe Faturamento (SIGAFAT)!

- O CFOP utilizado deve ser um CFOP que o SEFAZ considera válido para NFs de Devolução para que não resulte em Rejeição;
- A Tag FinNFe do xml a ser transmitido deverá ser gerado com conteúdo 4 (que indica "Devolução") de forma a ser compatível com o CFOP de Devolução  e não ocasionar Rejeição 327 / 328;
- O CFOP não pode estar contido no parâmetro MV_DEVCFOP (este parâmetro armazena CFOPs que não são de devolução e faz com que a Tag FinNFe seja gerada com conteúdo 1 ao invés de 4);
- Atente-se ao campo F4_AJUSTE no TES, pois caso esteja indicando se tratar NF de ajuste, irá gerar A Tag FinNFe com conteúdo 3;
- Há no Cabeçalho o campo C5_MENNOTA onde podem ser registradas observações informativas para serem levadas como complemento na Nota.
INFORMAÇÃO COMPLEMENTAR:O Alert DSNOTESDEV caracteriza inconsistência no processo. É necessário validar todo o procedimento e TES utilizados.

Considerações:

  • Caso identifique que a nota de entrada foi lançada de forma errada em comparação às premissas mencionadas acima (por exemplo, com o Tipo diferente de Beneficiamento, ou com um TES que não está devidamente configurado);é necessário excluir o documento de entrada e lançar novamente, para então gerar o Pedido e Nota de saída. Não é possível apenas alterar algo no TES pois o comportamento não será mudado visto que a alteração foi depois de já ter lançado a Nota e realizados devidos relacionamentos.
  • Não é procedimento correto alterar o cadastro de um TES! Caso identifique que lançou a nota com um TES que não está de acordo com o especificado, o correto é localizar outro TES já cadastrado que atenda aos requisitos, ou então, incluir o cadastro de um novo TES para atender à necessidade; e então, realizar o lançamento com o TES correto. Porém, deixar o outro TES intacto (pois alterações comprometem o histórico de movimentações no sistema).
  • Se validar a nota de entrada e estiver correta nos requisitos, tanto Tipo da nota quanto os TES com devidas amarrações, é possível, que algum TES já tenha sofrido alteração no cadastro (justamente o processo que não é indicado).
     Desta forma, para fins de TESTE, inclua uma nova nota de entrada igual a nota em questão (mesmo Cliente/produto/TES) e refaça o processo. Poderá validar que, se as amarrações de TES estiverem corretas, de acordo com o orientado aqui, o processo será concluído corretamente. 
     Sendo assim, será de qualquer forma, necessário excluir a nota de entrada e lançar novamente para alimentar as devidas tabelas relacionadas (como por exemplo, SB6 - Poder de terceiro)

 

 

 

...