Como diagnosticar uma rejeição de documento no SAP DRC por erro de dado fiscal?

O cenário é este: rejeição que some depois de reenviar. Meu palpite, é regra de extensão própria que preenche campo só em parte dos casos. Como desenvolvedora, minha checagem é pegar duas notas do mesmo tipo, uma aceita e uma rejeitada, e comparar campo a campo o que a nossa extensão Z gravou. A diferença apontada diz se o erro é de dado ou de código. Se for de código, o conserto vai por transporte e não por correção no cadastro.

Discordo em um ponto. Pensando bem, viu, os três baldes ajudam, mas divergência de configuração, dado ou produto costuma ser descoberta só na homologação do cliente, perto da data de exigência, e o ambiente de qualidade muitas vezes está sem a transmissão configurada. Então parte do fluxo nunca foi testada antes. Eu acrescentaria um passo ao roteiro: confirmar se o ambiente de teste enviou de verdade, antes de concluir que o dado está errado.

Saudações, pessoal. Aqui a gente olhou de perto por outro caminho: em vez de começar pela mensagem, começamos pelo monitor da nota. Para NF-e, segundo a documentação da NTT sobre o módulo e-Invoicing, o acompanhamento é pela transação J1BNFE, e o de NFS-e por transações ECG. O status do monitor mostra em que etapa a nota parou, e isso já elimina o balde de comunicação antes de qualquer análise de dado. A documentação do produto que temos não afirma como o SAP DRC e o GUEPARDO Tax se relacionam nessa checagem: confirme com a NTT ou teste no ambiente.

Na real, pois é, o truque é classificar a rejeição antes de corrigir. Use três baldes:

1. Cadastro: a mensagem cita CNPJ, IE, endereço, NCM ou campo de parceiro vazio. Compare o dado da nota com o cadastro mestre.
2. Regra: a mensagem cita CST, CFOP ou imposto calculado. Compare com um documento aceito do mesmo tipo.
3. Comunicação: não há código de rejeição do órgão, só falha de envio. Veja o status da mensagem.

Escreva o balde ao lado de cada rejeição e conte no fim da semana.