Nota de Devolução de Poder de Terceiro / Nota de Retorno
Microsiga Protheus®Microsiga 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: |
SIGAFAT - Faturamento | Ocorrência: | DEFINIÇÃO DE CENÁRIO:
Conceito
Para entender um pouco mais do conceito de poder DE/EM terceiro veja nosso vídeo How To em:
Conector de Widget |
---|
url | http://youtube.com/watch?v=oS5sdoZBdN8 |
---|
|
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 |
---|
|
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 |
---|
|
- 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.
|
...
...
- se houver grande demanda de tal operação em seu negócio e,
|
...
- 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 |
---|
startHidden | false |
---|
effectDuration | 0. |
---|
|
...
5 | id | Vincular RA / Desvincular RA |
---|
effectType | horizontal |
---|
loopCards | true |
---|
|
Card |
---|
default | true |
---|
id | Premissas (pré-retorno |
---|
label | Premissas (pré-retorno) |
---|
| ETAPA | CAMPO(S) PARA COLOCAR A INFORMAÇÃO/VISUALIZÁ-LA |
---|
NF de Origem (Entrada - MATA103) deve estar devidamente preenchida como beneficiamento | C103TIPO == 'B - Beneficiamento' [SF1] | O TES Entrada |
|
|
...
Conhecimento:
PREMISSAS:
...
deve controlar Poder de Terceiro caracterizando a Remessa |
|
|
...
...
...
...
...
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.
| A entrada deverá alimentar corretamente os campos de poder de terceiros | D1_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 |
---|
default | true |
---|
id | Processo (retorno) |
---|
label | Processo (retorno) |
---|
|
|
...
| - 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])
- Tipo de seleção:
Por fornecedor
|
|
...
- == Permite realizar marcação de
|
|
...
- múltiplas notas desta entidade a retornar
|
|
...
...
- == 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
|
|
...
...
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: |
| - Acesse Pedido de Venda - MATA410
|
|
|
...
- Inserir
- Selecione Tipo: Normal (para retorno de Clientes) ou Utiliza Fornecedor (para retorno de Fornecedor)
- Preencha manualmente o código do Produto e o TES de Retorno (relacionado no F4_TESDV do TES de entrada)
- Pressione "F4" no campo de Quantidade e selecione a NF que deseja devolver
|
|
|
...
Card |
---|
default | true |
---|
id | Observações |
---|
label | Observaçõ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;
|
|
...
INFORMAÇÃO COMPLEMENTAR:
- O Alert DSNOTESDEV caracteriza inconsistência no processo. É necessário validar todo o procedimento e TES utilizados.
|
|
...
Card |
---|
default | true |
---|
id | Situações em que a exclusão da NF entrada é necessário |
---|
label | Situaçõ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
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)!