DSERTSS3-3799 - DT TRANSMITE - CTE API - Implementar upload para a GCS das CT-e/CT-e OS emitidos

01. DADOS GERAIS

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. Continuando este planejamento para CT-e e CT-e OS emitidos, seguindo os seguintes critérios:

• Todos os pontos de entrada de CT-e e CT-e OS emitidos; ou seja, importação e sincronização, devem enviar o XML para a GCS, mantendo no MongoDB também, como contingência temporária;
• 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:

<cteProcB2B xmlns="http://www.portalfiscal.inf.br/cte">
    <cteProc>
        <CTe><!{}dados da CTe{}></CTe>
        <protCte><!{}protocolo da CTe{}></protCte>
    </cteProc>
    <procCancCTe versao="3.0">
        <cancCTe>
            <!{}dados do cancelamento{}>
        </cancCTe>            
        <retCancCTe>
            <!{}dados do protocolo do cancelamento{}>
        </retCancCTe>
    </procCancCTe>
    <procEventoCTe versao="3.0">
        <evento>
            <!{}dados do evento{}>
        </evento>
        <retEvento>
            <!{}dados do protocolo do evento{}>
        </retEvento>
    </procEventoCTe>
</cteProcB2B>

<cteOsProcB2B xmlns="http://www.portalfiscal.inf.br/cte">
    <cteOsProc>
        <CTeOs><!{}dados da CTe OS{}></CTeOs>
        <protCteOs><!{}protocolo da CTe OS{}></protCteOs>
    </cteOsProc>
    <procCancCTe versao="3.0">
        <cancCTe>
            <!{}dados do cancelamento{}>
        </cancCTe>            
        <retCancCTe>
            <!{}dados do protocolo do cancelamento{}>
        </retCancCTe>
    </procCancCTe>
    <procEventoCTe versao="3.0">
        <evento>
            <!{}dados do evento{}>
        </evento>
        <retEvento>
            <!{}dados do protocolo do evento{}>
        </retEvento>
    </procEventoCTe>
</cteOsProcB2B>

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 no MongoDB também, como contingência temporária;;
• 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ções de exportação, individual e em lote, deverão fornecer a opção de receber o arquivo unificado ou documento e eventos separadamente.

03. SOLUÇÃO

Para a resolução deste escopo, foram designadas 4 tarefas, sendo que esta visa adequar o projeto transmit-cte-api, para que todas as funcionalidades relacionadas aos CT-e e CT-e OS emitidos passem a olhar para o XML tanto no MongoDB, respeitando o legado, quanto oriundos da GCS, respeitando o novo padrão. Abaixo, mais detalhes deste ajuste:

• Alteração nos fluxos exportação individual e em lote, impressão e detalhamento de CT-e e CT-e OS emitidos para utilizar os serviços CteUploadService e CteOsUploadService  para obter conteúdo do XML proveniente das fontes disponíveis (MongoDB no legado e GCS para o novo padrão). Além disso, para o processo de importação de nota de CT-e e CT-e OS emitidos, foi ajustado para que estes sejam enviados para a GCS, utilizando-se dos métodos de upload do mesmo serviço.
• No caso especifico destes documentos, CT-e e CT-e OS, existia um mecanismo antigo que fazia upload da nota para a GCS, mas sem a estrutura do B2B, para que o fluxo atual consiga realizar a atualização desses registros, foi implementado script que limpa o caminho preexistente da GCS da collection respectiva, para que quando o legado seja atualizado para o novo modelo, o arquivo antigo da GCS seja reescrito como devido.

04. DEMAIS INFORMAÇÕES

Não Há.

05. ASSUNTOS RELACIONADOS

Não Há.