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-2980 |
02. SITUAÇÃO/REQUISITO
Hoje o TOTVS Transmite armazena os arquivos de documentos fiscais (XML), de forma heterogênea, em base de dados (MongoDB) e na Google Cloud Storage (GCS). Pensando que solução serve também ao proposito de guarda das informações fiscais, essa descentralização da informação pode se tornar uma complexidade em futuras funcionalidades como disponibilização dos documentos em massa.
Com este cenário em mente, existe então a necessidade de tornar a forma de armazenagem homogênea, armazenando todos os documentos fiscais na GCS. Foi decidido que essa alteração será realizada em partes, começando essa adequação para NF-e recebidas, seguindo os seguintes critérios:
- Todos os pontos de entrada de NF-e recebidas; ou seja, importação e sincronização, devem enviar o XML para a GCS, mantendo no MongoDB apenas o metadado deste;
- Funcionalidades existentes que utilizam o XML, como detalhamento, envio de e-mail, exportações, dentre outros serão adaptados para realizar a busca do XML tanto na GCS quanto no MongoDB, preservando o legado e respeitando o novo padrão;
- Especificamente na exportação em lote, deverá ser implementado mecanismo que realize a adequação do legado para o novo padrão; ou seja, coletar os XML ainda no MongoDB e realizar o upload deste para a GCS.
Essa melhoria visa tornar a forma de armazenamento de arquivos centralizada GCS, inclusive os eventos vinculados aos documentos fiscais. Desta premissa surge a necessidade de também enviar os eventos para a GCS. Baseando-se em Nota Técnica (NNT2013 002_B2B_v1.00b) da SEFAZ, definiu-se que ao invés de se gerar arquivos separados de notas e eventos, será gerado um arquivo unificado nos moldes do presente nesta nota técnica, conforme esquema abaixo:
Com isso definido, em adição aos critérios já definidos, somam-se estes:
- Eventos recebidos (importação e sincronização) serão agrupados ao documento técnico seguindo o modelo acima e por consequência também deverão estar na GCS, mantendo apenas o metadado no MongoDB;
- Resumo de nota, porém, não será enviado, pois não se trata de um documento ou evento aprovado, devendo este permanecer no MongoDB;
- Eventos recebidos do sincronismo, sem terem o documento fiscal recebidos (processo não entrega dados em ordem, podendo o evento ser sincronizado antes da nota que o originou), mesmo assim serão enviados a GCS, como parte do arquivo unificado, respeitando também o modelo;
- Função de exportação em lote deverá fornecer a opção de receber o arquivo unificado ou documento e eventos separadamente.
03. SOLUÇÃO
Para realização do proposto, foi necessária a intervenção nos seguintes projetos e serviços:
- transmit.framework;
- transmit.nfse.domain;
- transmit.nfe.domain;
- transmit.mde.worker;
- transmit.mail.worker;
- transmit.portal.api.
Além da codificação foram criados três novos templates XSL para auxiliar no processo de agrupamento de documentos fiscais e eventos, sendo estes:
- AgruparDocumentoAutorizado;
- SegregarDocumentoAutorizado;
- AgruparEventoAutorizado.
TRANSMIT FRAMEWORK
Foi realizada a criação de nova interface chamada IUploadService que possui 4 métodos definidos, sendo 3 desses principais (UploadDocument, UploadEvent e GetXmlContent) e 1 auxiliar (GetAuthEvent), A ideia desta interface é definir um padrão para serviço de upload de arquivo seguindo o modelo agrupado, de forma que seja possível reutilizar essa interface para a implementação futura dos demais modelos de documentos fiscais (CT-e, NFC-e, dentre outros). Além disso, foram realizadas adequações em diversos fontes, pois foram retirados do projeto do transmit.portal.api, referências duplicadas de classes que manipulam o repositório de urls e certificados, dentre outros. Para maiores detalhes de codificação, consultar o Pull request de alterações do transmit-framework.
TRANSMIT NFSE DOMAIN
Por alteração no framework, foi necessário um ajuste menor no transmit.nfse.domain que pode ser conferido em Pull request de alterações do transmit-nfse-domain.
TRANSMIT NFE DOMAIN
Foi realizada a implementação de nova interface IUploadService, na forma do serviço NFeRecebidaUploadService. A implementação dos métodos UploadDocument, UploadEvent e GetXmlContent foi realizada de forma que atendesse aos critérios estabelecidos e fosse possível utilizar em todos os pontos de intervenção, sendo as duas primeiras responsáveis por realizar o upload e manter coeso e atualizado o arquivo unificado, com documento (sempre apenas um deste) e eventos. Nestes fazemos o uso dos templates AgruparDocumentoAutorizado e AgruparEventoAutorizado para respectivamente agrupara a nota e os eventos ao arquivo único. O método GetXmlContent é responsável pro obter o conteúdo do XML, estando ele no MongoDB (legado) ou na GCS. Além disso diversas inclusões e alterações realizadas aqui, visaram a unificação de funcionalidades duplicadas que haviam no transmit.portal.api. Para maiores detalhes de codificação, consultar o Pull request de alterações do transmit-nfe-domain.
TRANSMIT MDE WORKER
Alteração do fluxo de sincronização de NF-e recebidas para utilizar o serviço NFeRecebidaUploadService para realizar a agregação de documento e eventos recebidos no modelo definido, realizando o upload (inserção e atualização do conteúdo), conforme critérios estabelecidos. Para maiores detalhes de codificação, consultar o Pull request de alterações do transmit-mde-worker.
TRANSMIT MAIL WORKER
Alteração do fluxo de envio de e-mail e exportação em lote de NF-e recebidas para utilizar o serviço NFeRecebidaUploadService para obter conteúdo do XML proveniente das fontes disponíveis (MongoDB no legado e GCS para o novo padrão). Além disso, como foi estipulado nos critérios, no serviço MDeExportBatchService foi criado o método UploadLegacyDocumentsAsync para realizar a tratativa dos arquivos considerados legados; ou seja, que tem o arquivo XML da nota e eventos ainda no MongoDB. Ainda na exportação em lote, foi implementado um novo atributo na tarefa enviada pela API, chamada Join, para no futuro receber a opção do cliente de segregar ou agrupar nota e eventos no artefato gerado por esta. Para maiores detalhes de codificação, consultar o Pull request de alterações do transmit-mail-worker.
TRANSMIT PORTAL API
Alteração nos fluxos de manifestação, sincronização manual, exportação individual, impressão e detalhamento de NF-e recebidas para utilizar o serviço NFeRecebidaUploadService para obter conteúdo do XML proveniente das fontes disponíveis (MongoDB no legado e GCS para o novo padrão). Aqui foi necessária a utilização de template SegregarDocumentoAutorizado para continuar devolvendo apenas o conteúdo da nota, ao invés do arquivo único. Além disso, para o processo de importação de nota e eventos de NF-e recebidas, foi ajustado para que estes sejam enviados para a GCS, utilizando-se dos métodos de upload do mesmo serviço. Fora do escopo acordado, foi ainda realizado parte da refatoração, para a remoção dos fontes em duplicidade, existentes hoje no projeto. Para maiores detalhes de codificação, consultar o Pull request de alterações do transmit-portal-api.
TEMPLATES
04. DEMAIS INFORMAÇÕES
Não Há.
05. ASSUNTOS RELACIONADOS
Não Há.