Qual a diferença entre erro de dado, de configuração e de produto na prática?

Para situar vocês, o último passo é o produto. A manutenção da licença e a correção de defeitos do produto são da NTT, e a documentação de sustentação que conheço fala em abrir chamado no canal oficial da NTT quando a evidência aponta para o produto. Veja, como vimos, a evidência é o que decide: documento de origem, resultado esperado, resultado obtido, passos para reproduzir. O que a NTT responde em cada prazo o material que temos não afirma; confirme com a NTT.

Primeiro o cenário: discordo de uma ordem fixa de três causas. Existe uma quarta: extensão própria. As notas de projeto dizem que extensões Z quebram na atualização e ninguém sabe dizer qual existe, quem escreveu e o que assume do produto. E aí, na sustentação, isso aparece como erro de produto quando é código nosso. Acrescente uma pergunta antes de escalar: existe extensão Z ou desenvolvimento próprio nesse ponto do cálculo? Se existe, a causa pode estar nela.

Dúvida pontual, e aqui a gente classificou de outro jeito, por experiência, tá: três perguntas no próprio formulário do chamado. O dado de origem está completo? A regra está parametrizada para esse caso? O erro se repete num documento limpo, criado de propósito no ambiente de qualidade? Se repete com dado limpo e regra conferida, o chamado sobe como possível produto. Se não repete, volta para dado ou configuração. É experiência nossa, não uma regra do produto, e depende de ter um ambiente de qualidade utilizável.

O cenário é este: comece sempre pelo dado, porque é onde a causa mora com mais frequência. As notas de projeto dizem que a causa raramente está no módulo de apuração e costuma estar na origem, como retenção fora do padrão, fato gerador errado e falta de registro do tributo retido. Vale registrar, viu, a ordem de eliminação:

1. o documento de origem está completo e correto?
2. a regra está parametrizada para este caso?
3. só então, com dado limpo e regra conferida, suspeite do produto.

Oi, pessoal, tudo bem? Complemento com um passo prático que vi numa nota de projeto: antes de parametrizar ou culpar o módulo, confirmar se a retenção sai certa no ERP padrão, porque a Reinf lê o que o ERP gravou. Saindo um pouco do tema, viu, vale generalizar: se o documento já nasce errado no ERP padrão, o módulo de apuração só repete o erro. Anexe ao chamado a tela ou o registro do documento de origem, para provar que o dado estava certo ou errado antes da apuração.