Páginas filhas
  • DSERTSS3-3645 - DT TRANSMITE - Persistência das requisições de exportação NF-e e controle de Ack das mensagens

01. DADOS GERAIS

Produto:

TOTVS Transmite

Linha de Produto:

Linha Protheus

Segmento:

Backoffice

Módulo:TOTVS Transmite
Função:Não Há
País:Brasil
Ticket:Não Há
Requisito/Story/Issue (informe o requisito relacionado) :DSERTSS3-3645

02. SITUAÇÃO/REQUISITO

Hoje no processo de exportação em lote de NF-e Recebidas, quando ocorre uma exceção de código, tem a solicitação de origem perdida, sendo necessária nova requisição, nestes casos. Tendo esse cenário em mente, faz-se necessário o ajuste para que isso não mais aconteça ou em casos de fluxos, como quando não houverem notas a exportar para a requisição, uma notificação seja gerada, fazendo com que o usuário final receba um feedback em todos os cenários devidos.

03. SOLUÇÃO

Para resolução do cenário descrito, o fluxo foi adequado da seguinte maneira:

  • Ajuste no transmit-framework para que o serviço TaskResponseService e o repositório TaskResponseRepository passassem a utilizar o novo padrão de acesso ao banco de dados, com repositórios como escopo, mitigando possíveis exceções que o modelo antigo de acesso causava;
  • Inclusão do fluxo de exportação em lote no transmit-nfe-worker, para desacoplar este recurso do transmit-mail-worker, pois este encontra-se com tarefas em demasia. A ideia é que funcionalidades sejam agrupadas no projeto pertinente ao documento fiscal, neste caso, tudo o que for referente a NF-e (Recebida ou Emitida), será tratado no transmit-nfe-worker. Além disso, realizou-se a modificação de como o consumidor do RabbitMQ realiza o conhecimento (acknowledge) do recebimento da mensagem. Antes esse processo era automático, logo quando lia a mensagem da fila, o consumidor já dava o conhecimento da mensagem e se em algum momento tivesse uma exceção de fluxo essa mensagem se perdia. Agora o conhecimento só é manifestado pelo consumidor após a tarefa de exportação ter sido realizada. Ainda nesse ponto, foi implementada uma configuração para que os consumidores só possam trabalhar com uma mensagem por vez, sendo que essa medida visa distribuição igualitária de mensagens entre os consumidores das solicitações de exportações. Por fim, foi incluída notificação para alertar o usuário final de que uma exportação não foi realizada, quando o período solicitado não contenha notas em condições de exportação, como resumos que não possuam ainda o XML liberado pela SEFAZ;
  • Ajuste no publicador de mensagens de requisição de exportação em lote, presente no transmit-portal-api, para que este passe a considerar a fila eExportTAskNFe-Queue, em detrimento da fila eTasks-Queue (consumida pelo transmit-mail-worker).

04. DEMAIS INFORMAÇÕES

  • Não há

05. ASSUNTOS RELACIONADOS

  • Não há