SAP DRC e GUEPARDO Tax: como não duplicar esforço de configuração?

E aí, antes de mais nada, guarde o resultado do teste. Para cada regra, o dossiê leva a nota usada, o resultado com um lado e com o outro, a data e quem decidiu. Sem isso, a divisão vira opinião, e opinião não se defende em auditoria. A divisão final é do cliente, e nós só provamos o comportamento do sistema.

Falando sério, pois é, nós usamos uma matriz simples: regra, dono, lado de execução, teste que prova, data. O produto da NTT é descrito como add-on dentro do SAP, complementando as apurações pelo menu padrão. Então partimos de que o padrão faz primeiro e o add-on complementa, e provamos isso por regra com documento real. Se a prova mostrar duas execuções, uma sai.

Discordo de partir de que o padrão faz primeiro. O material que temos não afirma essa ordem para toda regra, e também não afirma nenhuma versão mínima de ECC, S/4HANA ou Support Package exigida pelo Tax. Então, o bom é testar sem premissa: execute a mesma nota com cada lado ligado e desligado, no ambiente de qualidade, e compare o resultado.

Na minha área, pois é, o que ajudou foi separar três prontidões, que a documentação trata como separáveis:

1. SAP: notas da SAP aplicadas.
2. Produto fiscal: notas técnicas da NTT.
3. Dado: NCM, classificação, regra de crédito.

Para cada regra, pergunte qual das três ela depende. A duplicidade costuma nascer quando ninguém sabe a qual prontidão a regra pertence.

Comece pelo que está escrito, e o escrito é pouco. A documentação da NTT que temos cita DRC apenas como nome de menu de configuração. O material que temos não afirma a relação entre os dois produtos; confirme com a NTT ou teste no ambiente. Com a mão na massa, né, o critério que usei foi fazer uma lista de regras e marcar, para cada uma, em qual lado ela é executada hoje no ambiente de qualidade, com a evidência.