Sap tax declaration framework tdf

O risco que já vi é confundir declaration pronta com declaration entregue. Renato Costa, como vocês registram a diferença entre as duas etapas no framework com o GUEPARDO Tax? Agora, minha leitura, é que cada status precisa de dono. Primeiro, quem prepara; segundo, quem confere; terceiro, quem aprova. Em serviços isso evitou dúvida, mas quero saber se a ferramenta separa isso sozinha.

Concordo em parte com o Moisés, mas discordo de criar classe própria cedo demais. Bem, uma ressalva: primeiro, teste o padrão do framework; segundo, anote o que faltou; terceiro, só então desenvolva. No automotivo, com fechamento apertado, isso evitou retrabalho na declaration e deixou claro o que era de fato lacuna do padrão. Moisés, qual critério vocês usaram para decidir que o padrão não bastava?

Dá para estender sem mexer no padrão? Minha opinião, né, o framework deve ser usado como está, e o que falta vira extensão fora do núcleo, em ABAP. No varejo, em S/4HANA 1909, fizemos assim: uma classe própria lê o resultado da declaration e gera o relatório do cliente. Vale quando a obrigação é local; se o padrão já cobre, nem desenvolva.

Na minha rotina de key user, o primeiro uso foi acompanhar o status de cada declaration. Roberta, completando: o óbvio é que o framework não substitui o conhecimento da obrigação. Migrando de outro ERP, vi o time confiar demais na tela e esquecer de conferir o dado de origem. Então valide a base antes de olhar o framework, e guarde o log.

Se a sua necessidade é padronizar como as declarações são preparadas e acompanhadas, o framework existe para isso, Cristina. Veja, como sempre, o ponto é separar a regra, que vem configurada, do envio, que depende de cada obrigação. Na tela de configuração dos meus projetos em RISE, conferi o status de cada declaration antes de seguir. Confirme na documentação da SAP o que cobre a sua versão.