Como organizar a carga de dados mestres fiscais para a implantação do GUEPARDO Tax?

Tirando a prova, é por camadas: compare a carga com a fonte, por amostra, e registre resultado, data e responsável. Mas o teste que conta é o primeiro fechamento em produção, depois do teste técnico, do integrado, da regressão, do contábil e da homologação do cliente. Esse último inclui a interpretação tributária, que é do cliente.

Discordo de deixar a validação só com o fiscal. Então, olhando o número de itens que a retenção exige, há dado que o fiscal não enxerga sozinho:

1. Cadastro do parceiro: tipo de prestador, obra, natureza do rendimento, dependentes.
2. Código de receita preso ao cadastro do parceiro.
3. Letras no CNPJ, com interfaces e obrigações que as aceitem.

Cada item precisa de dono e de teste.

Olha, a dúvida é como organizar a carga. A documentação da Reinf mostra que o cadastro de fornecedores e clientes tem tabela própria no produto, então a carga fiscal pode envolver tabelas do produto além das do SAP. Peça à NTT a lista de tabelas de cadastro que a sua versão usa, em vez de supor, e registre a resposta com data.

Quem define o conteúdo é o fiscal, quem executa a carga é a TI, e quem desenha o modelo de carga e prova o resultado é a consultoria. É julgamento de projeto, não regra da NTT. No rollout, né, o erro comum é inverter: a TI define o que carregar. O motivo é que, segundo o material institucional, o produto não corrige dado mestre ruim, então o dado precisa chegar certo.