Ao transmitir uma NF-e pelo TOTVS Protheus, você pode se deparar com mensagens como:
002 – Não foi possível assinar a NF-e – entre em contato com o responsável.
029 – Falha no Schema do XML.
Apesar da primeira mensagem levar naturalmente à investigação do certificado digital, nem sempre o certificado é a verdadeira origem do problema.
Em alguns cenários, principalmente envolvendo NF-e de devolução, notas de entrada e documentos fiscais referenciados, o problema pode estar na própria estrutura do XML gerado pelo Protheus.
Neste artigo vamos analisar um caso real em que uma NF-e de entrada de devolução apresentava exatamente essas mensagens e entender como o referenciamento da nota fiscal de origem no Documento de Entrada do Protheus influencia a geração do XML.
O cenário
O documento analisado era uma NF-e modelo 55 de entrada, emitida pelo próprio estabelecimento.
Algumas informações importantes presentes no XML eram:
<natOp>DEV DE VENDA</natOp>
<mod>55</mod>
<tpNF>0</tpNF>
<finNFe>4</finNFe>
Temos, portanto:
tpNF = 0: operação de entrada;finNFe = 4: NF-e com finalidade de devolução;- natureza da operação: DEV DE VENDA.
Os produtos utilizavam CFOP de entrada de devolução, como:
<CFOP>1201</CFOP>
Até aqui, o XML apresentava características compatíveis com uma operação de entrada referente a uma devolução.
O problema apareceu ao analisar os itens.
O grupo DFeReferenciado
Em cada item da NF-e estava sendo gerada uma estrutura semelhante a esta:
<DFeReferenciado>
<chaveAcesso></chaveAcesso>
<nItem>0</nItem>
</DFeReferenciado>
Esse é um ponto crítico.
O grupo DFeReferenciado permite relacionar o item da NF-e atual com um documento fiscal anteriormente emitido.
Simplificando, podemos interpretar:
Quando esse grupo é informado, espera-se que exista efetivamente um documento fiscal de origem.
No XML analisado, entretanto, tínhamos:
<chaveAcesso></chaveAcesso>
<nItem>0</nItem>
Ou seja, o grupo estava sendo criado, mas sem uma chave de acesso válida e sem um item de origem válido.
Essa situação é diferente de simplesmente não informar um documento referenciado.
Se não existe informação válida para compor o grupo, a aplicação não deveria criar uma estrutura vazia como:
<DFeReferenciado>
<chaveAcesso></chaveAcesso>
<nItem>0</nItem>
</DFeReferenciado>
É justamente esse tipo de estrutura que deve ser investigado quando ocorre uma falha de Schema.
Por que aparece também “Não foi possível assinar a NF-e”?
Esse detalhe pode confundir bastante durante o diagnóstico.
Ao receber:
002 - Não foi possível assinar a NF-e
029 - Falha no Schema do XML
é natural começar verificando:
- validade do certificado A1/A3;
- senha do certificado;
- cadeia de certificados;
- TSS;
- comunicação com o TSS;
- permissões;
- configuração SSL/TLS.
Essas verificações continuam sendo importantes quando há indícios de problema no certificado.
Porém, quando existe simultaneamente uma mensagem explícita de Falha no Schema do XML, vale analisar o XML antes de concentrar toda a investigação no certificado.
A aplicação pode estar tentando processar ou assinar um XML que já contém uma estrutura incompatível com o Schema utilizado.
A relação com a Reforma Tributária
Outro detalhe importante do XML analisado é que ele já contém os novos grupos de IBS e CBS.
Por exemplo:
<IBSCBS>
<CST>000</CST>
<cClassTrib>000001</cClassTrib>
<gIBSCBS>
<vBC>4477.85</vBC>
<gIBSUF>
<pIBSUF>0.1000</pIBSUF>
<vIBSUF>4.48</vIBSUF>
</gIBSUF>
<gIBSMun>
<pIBSMun>0</pIBSMun>
<vIBSMun>0</vIBSMun>
</gIBSMun>
<vIBS>4.48</vIBS>
<gCBS>
<pCBS>0.9000</pCBS>
<vCBS>40.30</vCBS>
</gCBS>
</gIBSCBS>
</IBSCBS>
Isso mostra que estamos trabalhando com um XML já adequado aos novos layouts relacionados à Reforma Tributária.
Consequentemente, o ambiente Protheus/TSS precisa estar atualizado para trabalhar com os Schemas correspondentes.
Mas há outro ponto: a geração do DFeReferenciado depende de o ERP possuir corretamente as informações que relacionam o documento atual ao documento de origem.
É aí que entramos no Documento de Entrada do Protheus.
Como o Protheus relaciona uma Nota de Entrada com a nota de origem
No Protheus, o Documento de Entrada trabalha principalmente com:
SF1 → Cabeçalho da Nota Fiscal de Entrada
SD1 → Itens da Nota Fiscal de Entrada
Para estabelecer a relação entre um item de entrada e seu documento fiscal de origem, existem três campos particularmente importantes na SD1:
D1_NFORI
D1_SERIORI
D1_ITEMORI
Eles representam, respectivamente:
D1_NFORI → Número da nota fiscal de origem
D1_SERIORI → Série da nota fiscal de origem
D1_ITEMORI → Item da nota fiscal de origem
A própria documentação da TOTVS orienta o preenchimento desses campos com as informações da nota de origem em documentos de entrada que precisam desse relacionamento.
Conceitualmente:
SD1 - Item da entrada
D1_NFORI = Nota original
D1_SERIORI = Série original
D1_ITEMORI = Item original
Isso cria a amarração entre o movimento atual e o movimento que lhe deu origem.
Exemplo prático
Imagine que originalmente tenha sido emitida a NF-e:
Nota: 123456
Série: 1
e o produto devolvido estava no:
Item: 0001
No Documento de Entrada relacionado à devolução, o item poderia possuir:
D1_NFORI = 123456
D1_SERIORI = 1
D1_ITEMORI = 0001
O relacionamento conceitual passa a ser:
NF-e original
123456 / Série 1
│
└── Item 0001
│
▼
Documento de Entrada
│
└── Item da devolução
É essa informação de origem que permite ao Protheus reconhecer a relação entre os movimentos.
O relacionamento não deve ser confundido com a chave de acesso
Um detalhe importante é que:
D1_NFORI
não é a chave de acesso da NF-e.
O campo contém o número da nota de origem.
Da mesma maneira:
D1_SERIORI
contém a série e:
D1_ITEMORI
identifica o item correspondente.
A chave eletrônica da NF-e possui 44 posições e é outra informação.
Portanto, não devemos fazer algo como:
D1_NFORI = 3526...
utilizando os 44 dígitos da chave.
O Protheus utiliza os relacionamentos do documento para localizar e tratar as informações fiscais correspondentes.
Como informar a nota de origem no Documento de Entrada
Durante a inclusão do Documento de Entrada, é necessário verificar se o item está corretamente relacionado à nota fiscal original.
Dependendo do processo utilizado, versão do Protheus e configuração da rotina, essa informação pode ser obtida automaticamente pelo processo de devolução ou informada por meio dos campos correspondentes.
O resultado esperado na SD1 é:
D1_NFORI preenchido
D1_SERIORI preenchido
D1_ITEMORI preenchido
Por exemplo:
D1_DOC = 339060
D1_SERIE = 1
D1_ITEM = 01
D1_NFORI = 123456
D1_SERIORI = 1
D1_ITEMORI = 01
Nesse exemplo temos dois documentos diferentes.
O primeiro conjunto:
D1_DOC
D1_SERIE
D1_ITEM
identifica o documento que está sendo lançado agora.
O segundo:
D1_NFORI
D1_SERIORI
D1_ITEMORI
identifica de onde aquele movimento se originou.
Essa diferença é fundamental.
Como consultar diretamente no banco
Em uma investigação técnica, podemos verificar rapidamente os itens da SD1.
Por exemplo:
SELECT
D1_DOC,
D1_SERIE,
D1_ITEM,
D1_COD,
D1_CF,
D1_NFORI,
D1_SERIORI,
D1_ITEMORI
FROM SD1010
WHERE D1_DOC = '339060'
AND D_E_L_E_T_ = '';
A tabela física poderá variar conforme empresa/ambiente, por isso SD1010 é apenas um exemplo.
O objetivo é verificar se estamos encontrando situações como:
D1_NFORI = ''
D1_SERIORI = ''
D1_ITEMORI = ''
ou referências incompletas/inconsistentes.
Se o XML está produzindo DFeReferenciado, vale comparar diretamente essas informações com aquilo que foi gravado na SD1.
O reflexo fiscal dessa referência
O relacionamento não é relevante apenas para a transmissão da NF-e.
A documentação da TOTVS também utiliza:
D1_NFORI
D1_SERIORI
D1_ITEMORI
para estabelecer a referência à nota de origem nos documentos de entrada.
Depois do processamento fiscal, esse relacionamento pode refletir na SFT através de campos como:
FT_NFORI
FT_SERORI
FT_ITEMORI
Essa informação também participa de processos fiscais relacionados aos documentos referenciados e ao registro C113 do SPED Fiscal.
Portanto, não estamos falando simplesmente de “um campo necessário para passar o XML”.
Estamos falando do relacionamento fiscal entre documentos dentro do Protheus.
E nas Notas de Saída?
Existe uma lógica equivalente no faturamento.
Para operações de saída, o relacionamento utiliza campos como:
C6_NFORI
C6_SERIORI
C6_ITEMORI
no item do Pedido de Venda.
Após o faturamento, o relacionamento correspondente aparece nos itens da nota através de:
D2_NFORI
D2_SERIORI
D2_ITEMORI
Podemos resumir assim:
ENTRADA
SD1
├── D1_NFORI
├── D1_SERIORI
└── D1_ITEMORI
SAÍDA
SC6
├── C6_NFORI
├── C6_SERIORI
└── C6_ITEMORI
↓ faturamento
SD2
├── D2_NFORI
├── D2_SERIORI
└── D2_ITEMORI
A TOTVS documenta esse relacionamento tanto para operações de entrada quanto para operações de saída.
Atenção: nem toda devolução exige a mesma forma de referência
Aqui existe uma armadilha importante.
Encontrar:
<finNFe>4</finNFe>
não significa automaticamente que devemos simplesmente preencher qualquer referência para fazer a nota passar.
A necessidade e a forma de referenciamento dependem da operação fiscal, CFOP, documento de origem e regras vigentes da NF-e.
No caso analisado, por exemplo, aparecia:
<CFOP>1201</CFOP>
Portanto, antes de alterar o documento, é necessário determinar:
- qual é a NF-e que originou a devolução;
- quais itens da NF-e original estão sendo devolvidos;
- se o processo do Protheus está corretamente relacionando esses itens;
- se o XML deveria possuir
DFeReferenciado; - se a referência deve ocorrer no nível exigido pelo layout/regra aplicável;
- se Protheus e TSS estão atualizados para o Schema utilizado.
O objetivo não é “preencher a tag até o XML passar”.
O objetivo é fazer com que o relacionamento fiscal existente na operação seja corretamente representado no Protheus e, consequentemente, no XML.
Como eu diagnosticaria o erro 002 + 029
Quando aparecer:
002 - Não foi possível assinar a NF-e
029 - Falha no Schema do XML
eu seguiria esta sequência:
1. Salvar o XML gerado antes da transmissão
Não trabalhar somente com a mensagem apresentada na tela.
O XML geralmente revela muito mais.
2. Procurar tags vazias ou estruturas incompletas
Especialmente grupos novos ou condicionais.
No nosso caso:
<DFeReferenciado>
<chaveAcesso></chaveAcesso>
<nItem>0</nItem>
</DFeReferenciado>
chamou imediatamente a atenção.
3. Identificar a operação fiscal
Verificar:
tpNF
finNFe
CFOP
TES
Finalidade da NF-e
Documento de origem
4. Conferir a SD1
Consultar:
D1_NFORI
D1_SERIORI
D1_ITEMORI
e comparar com a nota original.
5. Conferir a nota de origem
Validar:
Número
Série
Item
Produto
Quantidade
Chave da NF-e
Não basta existir uma referência; ela precisa apontar para o documento correto.
6. Gerar novamente o XML
Depois de corrigir o processo no ERP, gerar novamente a NF-e e comparar o trecho do XML.
Se houver referência válida, espera-se uma estrutura coerente com o documento de origem, por exemplo:
<DFeReferenciado>
<chaveAcesso>CHAVE-DE-44-DIGITOS-DA-NFE-DE-ORIGEM</chaveAcesso>
<nItem>1</nItem>
</DFeReferenciado>
Caso aquele grupo não seja aplicável à operação, ele não deve ser artificialmente criado apenas com valores vazios.
7. Somente depois investigar assinatura/certificado
Se o XML estiver válido e a mensagem 002 continuar ocorrendo, aí sim aprofundamos a investigação em:
Certificado digital
TSS
SmartClient/AppServer
cadeia ICP-Brasil
TLS
permissões
configuração do certificado
Essa ordem evita perder horas investigando certificado quando a causa real está na montagem do XML.
Conclusão
A combinação dos erros:
002 - Não foi possível assinar a NF-e
029 - Falha no Schema do XML
não deve ser interpretada automaticamente como problema no certificado digital.
No caso analisado, o XML forneceu uma pista muito mais relevante:
<DFeReferenciado>
<chaveAcesso></chaveAcesso>
<nItem>0</nItem>
</DFeReferenciado>
Em operações que possuem relacionamento com uma nota anterior, é fundamental verificar como esse vínculo foi registrado no Protheus.
Para Documentos de Entrada, três campos merecem atenção especial:
D1_NFORI
D1_SERIORI
D1_ITEMORI
Eles estabelecem o relacionamento do item atual com a nota fiscal de origem e podem refletir posteriormente nas informações fiscais utilizadas pelo sistema.
Por isso, diante de uma falha de Schema, o melhor diagnóstico não é simplesmente perguntar:
“O certificado está funcionando?”
A pergunta mais útil é:
“Qual estrutura do XML não está atendendo ao Schema e quais dados do Protheus fizeram essa estrutura ser gerada?”
Essa mudança na forma de investigar costuma reduzir bastante o tempo necessário para encontrar a causa do problema.
Referências técnicas
Documentação TOTVS — Manual de utilização do SPED Fiscal (FIS0009), incluindo orientação sobre D1_NFORI, D1_SERIORI, D1_ITEMORI e documentos referenciados.
Documentação TOTVS — Relacionamento entre notas de remessa/devolução, com os relacionamentos de origem utilizados nas operações de entrada e saída.
Documentação técnica da NF-e — leiaute e Notas Técnicas vigentes aplicáveis ao XML da NF-e e aos grupos introduzidos/alterados pela Reforma Tributária.
