GUEPARDO Tax ou parametrização standard do SAP: como decidir o que usar?

Ainda estou aprendendo, então discordo com cuidado: olha, em campo, o critério mais traiçoeiro é o que não está na lista. Existe caso em que o padrão do SAP só chega lá com desenvolvimento, por exemplo a natureza da receita sem determinação por NCM, que no GUEPARDO Tax também exige BAdI, segundo a documentação da NTT. Então o add-on não elimina o desenvolvimento; muda onde ele fica. Compare o desenho, não só o produto.

Desculpem a insistência, mas resumindo, né: peçam evidência de coisa que se pode testar. Promessa de ganho de produtividade ou de redução de custo é texto comercial, não evidência. Peça uma demonstração com uma obrigação real de período fechado e compare o resultado com o que foi entregue e com o razão. Se o fornecedor de qualquer dos dois lados não aceitar o teste, isso também é informação.

Boa tarde, colegas do fiscal. A sacada é, viu, comparar o custo de manter, não só o de comprar. Pelo que registramos como prática:

• quanto desenvolvimento próprio cada caminho exige;
• quem mantém esse desenvolvimento depois do go-live;
• o que acontece com ele na próxima atualização.

A regra que usamos é parametrização antes de desenvolvimento, e ponto de extensão previsto antes de alterar objeto padrão.

Dúvida curta, resposta curta: decida por obrigação, não pelo produto inteiro. Como falei, tá, o material que temos não afirma desempenho nem vantagem medida. Segundo a documentação da NTT, o GUEPARDO Tax é um add-on que complementa as apurações pelo menu padrão. Então, para cada obrigação, pergunte: o padrão entrega o arquivo e a prova? Se sim, não precisa de camada. Se não, o que falta e quem mantém?