Como o GUEPARDO Tax recebe as retenções vindas do contas a pagar do SAP?

Do lado da auditoria, de cabeça, tá: quando a retenção não bate entre nota, guia, Reinf e saldo contábil, as notas de projeto dizem que a causa costuma estar na origem, e raramente no módulo de apuração. Isso muda a evidência que eu peço: o documento de origem de cada retenção, com data e usuário, e a prova de que o ERP padrão calcula a retenção certa antes de se culpar a parametrização do GUEPARDO Tax. O produto lê o que o ERP gravou.

Discordo em parte. Pra ser justo, pois é, rastrear nota por nota funciona, mas não pega o caso que mais dói: retenção lançada direto na contabilidade, sem passar pelo registro do documento. Segundo as notas de projeto que usamos, nesse caso o imposto existe no razão e não na base da apuração. Antes da tabela, eu listaria os lançamentos da conta de retenção e separaria o que veio de documento fiscal do que foi manual. O manual é o resto que nenhuma conferência por nota vai achar.

A documentação que consultamos não descreve o caminho a partir do pagamento. O que ela cita como pré-requisito da Reinf é a nota de serviço de entrada registrada pela MIRO ou por fatura em FI. Diga-se de passagem, ó, é nessa nota que o caminho começa, não no pagamento. Então o primeiro passo na segunda-feira: pegue um fornecedor com retenção, localize o Docnum gerado na MIRO e confirme que a retenção já aparece no documento fiscal antes de qualquer pagamento. Se ela só aparece depois, o caminho do seu ambiente é outro e precisa ser desenhado e provado.

Outro jeito de olhar, e o básico, tá: em vez de partir do pagamento, parta do número. Escolha cinco notas de serviço do mês passado com retenção e monte uma tabelinha com quatro colunas: Docnum, valor retido na nota, valor da guia paga e valor que aparece no painel de apurações da Reinf. Onde as quatro batem, o caminho funciona. Onde não bate, você já tem o ponto exato para perguntar à NTT ou ao parceiro, com caso na mão e não com suspeita.