Como funciona SAP TDF no Brasil no SAP?

Na nossa rotina, o cadastro muda toda semana por causa do time de compras, e, diga-se de passagem, isso já nos pegou antes. Pedro, quando você fala em voltar até o elo que mudou por último, como identifica esse elo sem um histórico de alteração do cadastro? Aqui a gente não tem essa trilha completa. Qual é o primeiro sinal que você olha?

Quando todo cadastro dispara um gatilho, o time passa a ignorar o alerta em pouco tempo, e isso é pior do que não ter alerta nenhum. Discordo da Fernanda nesse ponto, porque já vi uma equipe com alarme em tudo parar de olhar o único que importava. Então a saída é, tá, um gatilho só para a alteração que mexe em código de imposto, e a revisão do resto fica na rotina mensal. Assim o alerta continua sendo lido.

Essa parte é menos óbvia. No agro, como todo mundo sabe, a gente resolve com uma rotina de conferência mensal, em que o time compara o resultado do TDF com uma amostra de documentos já auditados. Esse caminho vale quando o volume é alto e a configuração muda pouco. Quando o cenário muda a cada trimestre, prefiro o teste de regressão com casos conhecidos, porque pega a mudança logo. Os dois se complementam, e a escolha depende de quanto a operação mexe no cadastro.

O resultado que importa é que a conferência evita o erro de cadastro, e a Aline acertou nisso. Mas, puxando o fio, ela não pega a mudança feita fora do ciclo. Eu já vi isso: o auditor olhou a amostra do mês e o problema estava numa alteração feita no meio do trimestre. Por isso a rotina mensal precisa de um gatilho que revise o cadastro quando alguém mexe nele. Sem o gatilho, a conferência fica confortável e a exceção passa.

Fernando, tem razão sobre o log, e completo com um ponto que sempre passa batido: o log do job não guarda o parâmetro de entrada, e, agora, a questão é que isso pesa muito. Quando rodamos o caso conhecido, a tela de resultado mostrou a mesma saída, mas o campo de data estava com o valor padrão. Por isso eu gravaria o parâmetro junto com o resultado, para comparar depois sem depender de memória. Isso economiza muito tempo de investigação em cada ciclo.

Concordo que o cerne está na configuração, mas a resposta direta é que o TDF funciona como uma cadeia de regras, e o zero pode nascer em qualquer elo dela. Discordo de olhar só a tabela. Eu começaria pelo log de cada etapa, na prática, tá, porque a tabela costuma estar certa e o erro mora numa regra antiga que ninguém lembra de ter criado. Pressa de fechamento faz a gente pular esse passo. Se o resultado sair zerado, volte até o elo que mudou por último.

O risco que já vi é tratar o log como prova. O Pedro sugeriu começar pelo log de cada etapa, e discordo: o log mostra o que rodou, não o que deveria ter rodado. Vi isso num fechamento em que o log estava limpo e o documento saiu errado, porque o cadastro tinha uma validade vencida. Diante disso, e aí, o caminho é comparar o resultado com um caso conhecido, e não confiar na ausência de erro.