Como validar o cálculo de impostos do SAP com base em resultado esperado definido pelo fiscal?

Então, seja como for, dá para incluir. A ficha precisa de uma coluna de apuração esperada para o período de teste e a comparação nota a nota. Se existe função do GUEPARDO Tax para rodar teste de cenário, o material que temos não afirma; confirme com a NTT ou teste no ambiente.

Segundo a documentação da NTT, o produto usa rotinas de pré-validação para achar inconformidades antes da entrega, mas isso não substitui a sua ficha.

Discordo de começar só com os cenários mais comuns. Agora, a gente costuma ver o erro nas exceções: devolução, bonificação, operação com substituição, cliente com cadastro incomum. Cenário de caminho feliz passa sempre e dá falsa segurança.

Peça ao fiscal os 10 casos que já geraram correção no passado e comece por eles.

Agora, em outras palavras: quem assina o esperado é o fiscal da empresa, com data e versão da ficha, porque o esperado é interpretação, não dado técnico. Quando a regra ou o cadastro mudar, a ficha muda de versão e a antiga vira histórico.

Um material de projeto descreve o mesmo raciocínio no dossiê do cliente: dono por regra, data e vínculo com a regra.

E aí, em todo caso, não pare no cálculo. O material de projeto lista tipos de teste: técnico, integrado, regressão, contábil, homologação do cliente e o primeiro fechamento em produção. Sua ficha cobre o integrado e a regressão.

A parte contábil, isto é, a nota ir para a conta certa, precisa de coluna própria na ficha.

Agora, olhando o XML: o teste mais barato é a nota de valor redondo. Monte cada cenário como uma ficha: tipo de operação, origem e destino, material, regime do emitente e o resultado esperado por imposto, com valor.

Emita a nota no ambiente de qualidade e compare cada tag de imposto do XML com a ficha. Comece com 10 cenários dos mais comuns. Planilha já serve; automatizar vem depois que as fichas existirem.