Produto: | TOTVS Varejo Gestão Fiscal
| ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Linha de Produto: | Linha Totvs Processos Fiscais | ||||||||||||||||
Segmento: | Varejo | ||||||||||||||||
Módulo: | NFS-e | ||||||||||||||||
Função: | Reenvio de XML | ||||||||||||||||
Ticket: | |||||||||||||||||
Requisito/Story/Issue (informe o requisito relacionado) : | DVTPFRM-637 |
Ao reenviar o XML, foram identificadas duas falhas:
Identificado que a falha de não reenviar o documento ocorre quando a integração do documento está com as origens "Via Recepção de JSON" (RECEPCAO_JSON) ou "Recepção de XML" (RECEPCAO_XML) no banco de dados. O reenvio é realizado corretamente apenas quando a integração tem a origem "Via Fiscal Sync" (FISCAL_SYNC_TC). Para resolver o problema, implementado o reenvio do XML quando os documentos são de origem "Recepção de JSON" (RECEPCAO_JSON) ou "Recepção de XML" (RECEPCAO_XML). No entanto, a nomenclatura do arquivo será ajustada conforme o fluxo recebido. Por exemplo, se o filtro for aplicado considerando o estabelecimento como prestador, mas o documento estiver salvo com origem "Recepção de JSON" ou "Recepção de XML", o XML será reenviado com a nomenclatura do fluxo 319, mesmo que o fluxo correto seja 203 - Emissor.
Além disso, constatou-se que o erro de reenvio ao ERP ocorre porque o prestador do documento não faz parte do grupo, o que está incorreto, já que o tomador esta vinculado ao grupo. Alterado a lógica condicional dos atores: agora, se o tomador faz parte do grupo e o prestador não, o documento será reenviado; o mesmo vale para a situação inversa.
Não se aplica
Não se aplica
Templatedocumentos |
---|
...