Histórico da Página
...
| Produto: |
| ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Linha de Produto: |
| ||||||||
| Segmento: |
| ||||||||
| Tipo de Documento: | Manutenção | ||||||||
| Módulo: | PDV | ||||||||
| Caminho: | Caminho > da > aplicação. | ||||||||
| Função: | Cancelamento por substituição | ||||||||
| País: | Brasil | ||||||||
| Ticket: | 24697671 | ||||||||
| Requisito/Story/Issue (informe o requisito relacionado) : |
|
02. SITUAÇÃO/REQUISITO
O problema é Foi verificado que , em casos de duplicidade, o documento deveria permanecer na tabela tb_doctoinutnfe, permitindo que o cliente gere-se a devolução , ou em caso do documento não está estar na SEFAZ, permanecer para ser inutilizado.
Como o sistema está inserindo o documento no Banco banco de Dados, dados com o protocolo de autorização, mesmo o documento não existir existindo na SEFAZ. Ele está integrando no Fiscal , ele está sendo integrado no fiscal e o cliente só percebe quando a SEFAZ notifica que o documento não existe na SEFAZ , ou quando o cliente bate o valor de duplicidade com o de devolução e verifica que não existe devolução para aquele documento.
...
Foi ajustada a regra criada na issue DSUPPDVTURING-12569: , onde, além de manter a nota como válida quando não há protocolo de cancelamento, agora também registramos registra na tabela de inutilização/devolução. Isso evita Evitando duplicidade sem devolução e mantém mantendo a proteção contra o problema original.
04. REQUISITOS DE VERSÃO
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas