Como separar o que o produto resolve do que é problema de dado mestre ou de processo?

Olá a todos. Discordo de dizer que a coluna do produto é sempre a mais curta, Anderson. Então, a prova é ler o que o produto afirma fazer e comparar com o problema, e isso depende de documentação por módulo. A documentação da NTT que consultamos cobre só ECD, ECF, ICF/PCR, ISS, PIS/COFINS e EFD-Reinf; fora desses assuntos, não dá para concluir o que o produto resolve, e o jeito honesto é testar no ambiente ou perguntar à NTT.

Foi mal a pergunta, mas deixo outro caminho. Veja, o caminho é montar três colunas por problema: dado (o cadastro está certo?), processo (quem faz e quando?) e produto (a função existe e está configurada?). A terceira só se preenche depois das duas primeiras. A descrição do produto que li diz que ele não define estratégia tributária, não corrige dado mestre ruim e não substitui governança, então as duas primeiras colunas são sempre da empresa. Acompanho o assunto desde a implantação do S/4HANA 1909 e a coluna do produto quase sempre é a mais curta.

Pergunte, para cada problema, onde o erro nasce: se nasce antes de o dado chegar ao produto, é dado ou processo. Perdoem a ignorância, mas é o teste mais simples que conheço. E aí, olha só: nas notas de projeto que li, a regra para a Reinf é confirmar se a retenção sai certa no ERP padrão antes de parametrizar, porque ela lê o que o ERP gravou. Se o erro já aparece no padrão, nenhuma parametrização acima dele resolve. Escreva essa pergunta, ERP certo antes de produto, na coluna de cada problema.

Primeiro o cenário: a obrigação saiu errada e o fiscal culpou a ferramenta. Bem, no mês passado descobrimos que a conta tinha lançamento fora do padrão. Complemento: segundo a documentação da NTT, o produto oferece consultas e relatórios de conciliação, mas isso mostra a diferença, não corrige a causa. A regra que adotamos, vinda das mesmas notas de projeto, é tratar conta com lançamento por bloqueio, não por eliminação, e provar com documento real.