A distribuição de Documentos Fiscais eletrônicos (DF-e) é uma rotina importante para empresas que precisam organizar documentos de transporte, integrar dados a ERPs e apoiar conferências fiscais e contábeis. Para quem desenvolve em Delphi, o assunto envolve mais do que realizar uma chamada SOAP: é necessário identificar corretamente o interessado, controlar a sequência de NSU, processar o conteúdo devolvido e respeitar os limites de consulta estabelecidos pelo ambiente nacional.
A Nota Técnica 2015.002, versão 1.05, atualiza a documentação do Web Service de distribuição de DF-e de interesse dos atores do CT-e. Seu ponto específico é a inclusão do CT-e Simplificado na documentação do serviço. Isso merece atenção porque a distribuição desse documento não segue uma lógica genérica de envio para todos os participantes registrados: a matriz da nota define precisamente quem pode recebê-lo.
Neste artigo, vamos separar o que está expressamente registrado na nota técnica do que deve ser tratado como decisão de implementação. Também abordaremos os cuidados operacionais para times de desenvolvimento e para profissionais da contabilidade que dependem do ERP para capturar e organizar DF-e de transporte.
O que a versão 1.05 efetivamente altera
A NT 2015.002 v.1.05 é identificada como documento técnico oficial de novembro de 2024. O índice de notas técnicas do Portal do CT-e a relaciona como publicada em 13 de novembro de 2024.
No controle de versões, a alteração declarada é objetiva: houve uma atualização da documentação para incluir o CT-e Simplificado. Portanto, a leitura adequada não é a de criação de um novo serviço de distribuição. O serviço tratado continua sendo o CTeDistribuicaoDFe, e a mudança documentada está no reconhecimento do CT-e Simplificado dentro das regras de distribuição apresentadas pela nota.
A comparação com a versão 1.04 ajuda a delimitar esse alcance. A v.1.04 não possuía linha específica para CT-e Simplificado em sua tabela de distribuição. Já a v.1.05 passa a trazer essa previsão. Essa comparação sustenta a inclusão documental do tipo de documento, mas não autoriza concluir, sem evidência adicional, que tenham ocorrido alterações no protocolo SOAP, no método, na versão do serviço ou nos schemas.
Essa distinção é especialmente útil em projetos Delphi. Uma equipe pode ter uma biblioteca de consumo do distribuidor madura e funcional, mas ainda precisar adaptar a camada de negócio: classificação do documento recebido, permissões por papel do interessado e exibição correta para usuários fiscais. Em outras palavras, a revisão pode estar menos no transporte da mensagem e mais no processamento e na governança do XML devolvido.
Datas registradas e cautela na interpretação
O cronograma interno da NT registra a implantação da v.1.05 em homologação e em produção em 21 de outubro de 2024. Essa data é anterior à publicação indicada no índice do Portal, em 13 de novembro de 2024.
As fontes consultadas não explicam a razão dessa cronologia. Assim, não é apropriado atribuir a diferença a publicação tardia, vigência retroativa ou qualquer outro motivo. Para uma política interna de atualização, o dado seguro é registrar ambas as informações como constam na documentação: as datas de implantação previstas na nota e a data de publicação indicada pelo Portal.
Como funciona o CTeDistribuicaoDFe
A NT descreve o CTeDistribuicaoDFe como um serviço síncrono, utilizado pelo método cteDistDFeInteresse. A sincronia importa para o desenho da aplicação: o cliente envia uma solicitação e recebe a resposta dentro da própria interação, em vez de gerar um recibo para consulta posterior.
O serviço permite duas formas de consulta:
- distNSU, para solicitar documentos a partir de uma sequência de NSU;
- consNSU, para consultar um NSU específico, inclusive quando se deseja investigar uma lacuna na sequência processada.
NSU é o número sequencial que orienta a recuperação dos documentos disponibilizados ao interessado. Na prática, ele deve ser tratado como dado de controle da integração, e não como detalhe descartável do XML. Quando uma aplicação não persiste adequadamente o último NSU processado, aumenta o risco de repetição desnecessária de consultas, perda de rastreabilidade interna ou reprocessamentos sem critério.
A resposta pode devolver até 50 documentos por lote. Os conteúdos são disponibilizados no campo docZip, codificados em base64 e compactados em GZip. Assim, uma rotina completa precisa executar, em ordem lógica, a extração do conteúdo base64, a descompactação GZip e a interpretação do XML resultante. A ordem é relevante: tentar tratar diretamente como XML um conteúdo ainda compactado levará a falhas de processamento.
Os DF-e permanecem disponíveis por até três meses após a recepção pelo Ambiente Nacional do CT-e. Essa informação não determina, por si só, a frequência ideal de consulta para cada empresa. Porém, ela evidencia que uma rotina eventual ou deixada sem monitoramento pode não ser suficiente para organizações que dependem da captura automatizada desses documentos.
Quem pode usar o serviço
Segundo a nota, o serviço pode ser usado por pessoa física ou jurídica que atue como emitente, remetente, destinatário, expedidor, recebedor, tomador ou terceiro autorizado, desde que possua certificado digital nas condições previstas no documento técnico.
Para a pessoa jurídica, a documentação prevê consulta abrangendo estabelecimentos com o mesmo CNPJ-base do certificado. Essa regra deve ser considerada na modelagem de cadastros e controles de acesso. Não é recomendável tratar a consulta como se cada filial fosse necessariamente uma integração totalmente isolada, nem assumir o contrário sem conferir o comportamento esperado no cenário da empresa e do certificado utilizado.
Para profissionais contábeis, esse ponto reforça a necessidade de alinhar cadastro societário, certificados e organização das filiais no ERP. A captura técnica pode ser centralizada, mas a classificação, a conferência e a destinação dos documentos ainda precisam respeitar o contexto operacional de cada estabelecimento.
CT-e Simplificado: quais interessados recebem o documento
A principal contribuição da versão 1.05 está na regra documental dedicada ao CT-e Simplificado. A tabela de distribuição estabelece que esse documento é disponibilizado para o tomador e para terceiros autorizados.
Por outro lado, a tabela não prevê distribuição do CT-e Simplificado ao remetente, destinatário, recebedor ou expedidor. Esse é um ponto que merece tradução direta para a regra de negócio do ERP: não se deve presumir que um participante operacionalmente relacionado à operação receberá o XML distribuído apenas por ocupar um desses papéis.
O terceiro autorizado é aquele cujo CPF ou CNPJ consta no grupo autXML. Para esse participante, a NT determina uma regra de sigilo fiscal: as chaves de CT-e e de NF-e relacionadas no XML distribuído devem ser substituídas pelo literal composto por 999...999. A documentação apresenta essa medida como mecanismo de preservação do sigilo fiscal.
Impacto para a camada fiscal e contábil
Para a área fiscal, a consequência prática é clara: o recebimento do documento não significa, automaticamente, acesso irrestrito a todos os vínculos documentais que poderiam existir no XML em outros contextos. Quando o interessado for terceiro autorizado, os dados mascarados precisam ser interpretados como resultado esperado da regra de distribuição, e não como defeito de descompactação ou falha do parser.
Para o desenvolvimento, isso sugere que a aplicação não deve exigir essas chaves mascaradas como pré-requisito para aceitar ou armazenar o XML. Uma validação interna que classifique o documento como inválido porque encontrou o literal de sigilo pode criar rejeições indevidas dentro do próprio ERP.
Também é prudente separar dois conceitos que podem parecer semelhantes, mas não são equivalentes: ser ator de uma operação e estar habilitado a receber determinado documento no distribuidor. A matriz da NT é a referência para a distribuição do CT-e Simplificado. Regras gerais adotadas para outros DF-e não devem ser reaproveitadas automaticamente sem validação.
Arquitetura de integração: decisões que reduzem inconsistências
Uma integração robusta precisa combinar protocolo, persistência e tratamento de dados. A NT informa que, quando ultNSU for igual a maxNSU, deve-se aguardar pelo menos uma hora antes de realizar nova consulta. Esse comportamento deve ser codificado como regra de agendamento, e não deixado a cargo de tentativas contínuas em caso de resposta sem novos documentos.
Em uma aplicação Delphi, a escolha das bibliotecas de HTTP, SOAP, certificado e compactação dependerá da arquitetura adotada pelo produto. A nota técnica não prescreve uma biblioteca Delphi. Ainda assim, qualquer implementação precisa garantir alguns comportamentos verificáveis: apresentar o certificado compatível, enviar a solicitação no formato requerido pelo serviço, controlar NSU por interessado, decodificar base64, descompactar GZip e persistir o resultado do processamento.
Persistência por interessado
Uma estratégia consistente é manter o controle de NSU associado ao interessado efetivamente consultado, identificado conforme a operação da empresa. Esse registro deve preservar, pelo menos, o último NSU confirmado, o maior NSU informado na resposta, o instante da consulta e o resultado técnico do processamento.
A razão é simples: o NSU não deve ser tratado como contador global de toda a base de clientes do ERP. Empresas diferentes, certificados diferentes e perfis de interessados distintos exigem rastreabilidade própria. Essa é uma recomendação de arquitetura derivada da necessidade de controlar a sequência de consultas; o formato exato das tabelas, classes ou repositórios não é definido pela NT.
Também convém registrar separadamente o XML bruto retornado, o resultado da descompactação e o status da interpretação interna. Essa separação facilita auditoria técnica quando houver divergência entre o que o serviço devolveu e o que o ERP exibiu ao usuário.
Tratamento de erros e reprocessamento
A documentação enumera códigos de rejeição, entre eles 137, 138, 214, 215, 252, 472, 473, 489, 490, 589, 593 e 656. A existência desses códigos reforça a necessidade de registrar cStat e mensagens retornadas pelo ambiente, em vez de reduzir toda resposta não bem-sucedida a um erro genérico.
Contudo, a lista de códigos, por si só, não define uma política completa de repetição. Não se deve programar retentativas agressivas apenas porque uma consulta não devolveu documentos. A regra expressa de espera mínima de uma hora quando ultNSU e maxNSU forem iguais precisa prevalecer sobre a conveniência de consultar continuamente.
Aplicação prática
A atualização para a v.1.05 pode ser conduzida como uma revisão técnica e funcional, sem pressupor que seja necessário reescrever o consumidor SOAP existente. O roteiro abaixo ajuda equipes Delphi, analistas fiscais e contadores a transformar a regra documental em controles observáveis.
1. Atualize a matriz de participantes do CT-e Simplificado
Revise a regra usada pelo ERP para classificar o interessado de cada XML. Para CT-e Simplificado, registre explicitamente que a distribuição prevista é para tomador e terceiro autorizado em autXML. Não configure recebimento para remetente, destinatário, recebedor ou expedidor como se fosse uma consequência automática desses papéis.
Esse teste deve envolver exemplos em que o mesmo CNPJ apareça em papéis distintos. O objetivo não é inferir elegibilidade com base no cadastro comercial, mas assegurar que a aplicação reflita a matriz documental da NT.
2. Teste o fluxo completo de docZip
Monte testes que cubram as três etapas técnicas: leitura do conteúdo em base64, descompactação GZip e interpretação do XML. O resultado esperado não deve ser apenas “não gerar exceção”. Confirme também se o XML final é armazenado, classificado e associado ao interessado correto.
Inclua um caso de terceiro autorizado em que chaves relacionadas estejam substituídas por 999...999. Nesse cenário, valide que o ERP preserva o documento e sinaliza corretamente a informação mascarada, sem tratá-la como corrupção de conteúdo.
3. Controle NSU e evite ciclos de consulta
Implemente consultas distNSU com persistência do avanço de NSU. Quando for necessário investigar uma posição específica, utilize consNSU de maneira rastreável. Em ambos os casos, guarde ultNSU, maxNSU, data e resultado da chamada.
Quando o retorno indicar ultNSU igual a maxNSU, aplique a espera mínima de uma hora antes da próxima consulta. Esse controle deve estar no agendador ou na regra central de integração. Colocá-lo apenas na interface do usuário não protege processos automáticos executados em segundo plano.
4. Valide nos ambientes publicados
O Portal do CT-e lista o CTeDistribuicaoDFe, versão 1.00, no Ambiente Nacional, com serviços publicados para produção e homologação. Antes de liberar uma alteração, confira a relação de serviços de produção e a relação de serviços de homologação, além de executar testes controlados.
A listagem oficial confirma a existência dos ambientes e do serviço, mas não substitui a homologação da integração no contexto do certificado, da infraestrutura e da biblioteca adotada pela aplicação. Disponibilidade de endpoint e comportamento de certificado são aspectos que precisam ser verificados tecnicamente pelo time responsável.
5. Alinhe tecnologia e contabilidade
O desenvolvimento deve entregar rastreabilidade: XML recebido, horário de consulta, dados de NSU, resultado da descompactação e retorno do serviço. A equipe contábil e fiscal, por sua vez, deve definir como os documentos capturados serão conferidos e associados aos processos internos.
Essa divisão evita dois problemas recorrentes: esperar que a contabilidade diagnostique uma falha de transporte SOAP ou, no sentido oposto, esperar que o desenvolvedor decida sozinho a interpretação operacional de um documento recebido. A NT esclarece a distribuição técnica; os procedimentos internos de escrituração, conferência e guarda precisam ser definidos pela organização conforme suas necessidades e orientações aplicáveis.
Limitações da documentação analisada
A NT 2015.002 v.1.05 é uma especificação técnica oficial do projeto CT-e. Nas fontes examinadas, não foi localizado ato normativo, legislação ou decisão judicial que trate especificamente essa atualização documental. Por isso, não é adequado qualificá-la como criação de obrigação tributária autônoma.
A nota menciona o pacote PL_CTeDistDFe_100 e os schemas distDFeInt_v9.99.xsd e retDistDFeInt_v9.99.xsd, mas o arquivo ZIP oficial desses schemas não foi localizado e auditado na pesquisa utilizada neste artigo. Portanto, não há base suficiente para afirmar que a v.1.05 tenha modificado os XSD, o método SOAP ou a estrutura de pedido e resposta.
Também há uma inconsistência editorial no informe do Portal publicado em 13 de novembro de 2024: seu título faz referência à versão 1.05, enquanto o corpo menciona a v.1.04. Para o conteúdo técnico, a referência mais segura é o PDF da v.1.05 e o índice de notas técnicas, que identificam a versão publicada.
Por fim, a ausência de uma v.1.06 na listagem oficial consultada não prova que não possa haver publicação posterior ou alteração futura. Antes de aplicar mudanças em produção, é recomendável conferir novamente o índice oficial e os comunicados do Portal do CT-e.
Conclusão
A NT 2015.002 v.1.05 documenta a inclusão do CT-e Simplificado na distribuição de DF-e de interesse dos atores do CT-e. Para esse documento, a regra é específica: a distribuição alcança tomador e terceiros autorizados em autXML, sem previsão de distribuição para remetente, destinatário, recebedor ou expedidor.
Para sistemas Delphi e ERPs, o trabalho central é refletir essa matriz de participantes e manter a integração tecnicamente disciplinada: controle individualizado de NSU, processamento correto de base64 e GZip, armazenamento rastreável dos retornos e respeito ao intervalo mínimo entre consultas quando não houver novos documentos.
Para contadores e áreas fiscais, o principal ganho está em saber interpretar o que chega ao sistema — e também o que pode não chegar por determinado papel no documento. O CT-e Simplificado exige uma leitura baseada na regra de distribuição da nota, não em suposições sobre todos os participantes da operação. Com essa separação entre regra técnica, processamento do ERP e procedimento interno, a atualização se torna verificável e mais segura.
Referências
PORTAL DO CONHECIMENTO DE TRANSPORTE ELETRÔNICO. Nota Técnica 2015.002 — Web Service de Distribuição de DF-e de Interesse dos Atores do CT-e, CT-e OS e GTV-e (PF ou PJ), versão 1.04. [S. l.], jun. 2024. Disponível em: https://www.cte.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=/VPENnM7j8s=. Acesso em: 12 out. 2026.
PORTAL DO CONHECIMENTO DE TRANSPORTE ELETRÔNICO. Nota Técnica 2015.002 — Web Service de Distribuição de DF-e de Interesse dos Atores do CT-e, CT-e OS e GTV-e (PF ou PJ), versão 1.05. [S. l.], nov. 2024. Disponível em: https://www.cte.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=LLSQYxGtwv0=. Acesso em: 12 out. 2026.
PORTAL DO CONHECIMENTO DE TRANSPORTE ELETRÔNICO. Notas Técnicas. [S. l.], [s. d.]. Disponível em: https://www.cte.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=Y0nErnoZpsg%3D. Acesso em: 12 out. 2026.
PORTAL DO CONHECIMENTO DE TRANSPORTE ELETRÔNICO. Relação de Serviços Web — Ambiente Nacional do CT-e. [S. l.], [s. d.]. Disponível em: https://www.cte.fazenda.gov.br/portal/webServices.aspx?tipoConteudo=wp. Acesso em: 12 out. 2026.
PORTAL DO CONHECIMENTO DE TRANSPORTE ELETRÔNICO. Relação de Serviços Web — Ambiente de Homologação do CT-e. [S. l.], [s. d.]. Disponível em: https://hom.cte.fazenda.gov.br/portal/webServices.aspx. Acesso em: 12 out. 2026.
0 comentário(s)