Quem deve ser o responsável por fiscal no RISE e GROW with SAP dentro da empresa?

Na minha rotina de farma, o caso concreto é o gestor fiscal querer aprovar tudo. Bem, no nosso caso, isso travou a configuração por muito tempo e a equipe de MM ficou parada esperando uma resposta. Discordo com educação da Ivone: poder de veto sem critério claro vira gargalo, e o responsável acaba sendo o último a saber de cada mudança. Eu separaria aprovação técnica, que pode ser da contabilidade, de aprovação de negócio, que fica com o dono do processo. Assim ninguém precisa esperar a pessoa certa estar disponível.

Quem valida a aprovação técnica, Renata? Olhando o XML, pois é, percebo que a separação que você propõe só funciona se a trilha ficar gravada. Na auditoria, cada alteração de imposto precisa mostrar quem pediu, quem aprovou e em que momento, senão a separação vira só desenho. Eu acrescentaria um campo de justificativa obrigatório e um relatório de mudanças por responsável, revisado a cada ciclo.

O resultado que importa é a nota de entrada cair certa, e isso depende de quem cuida do recebimento, não só da venda. Discordo com educação do Túlio quando ele coloca o responsável no processo de venda: no nosso caso, viu, a maior parte das diferenças nasce na movimentação de material e no recebimento de fornecedor. Se a fiscal fica com o comercial, a logística fica sem voz e a correção chega sempre tarde. Eu dividiria a responsabilidade por fluxo, com um dono para cada processo.

Kátia, na minha visão o responsável deve ser o key user fiscal ligado ao processo de venda, com a contabilidade validando o resultado e a TI cuidando só da execução. Olha, olhando a tela de configuração, cada ajuste de imposto nasce numa área de negócio, então é ela que precisa responder pelo efeito. A contabilidade confere a apuração depois, e a TI não deveria decidir o tratamento. Quando essa separação fica clara, a discussão para de virar briga e o cronograma anda.

Concordo com o Túlio. Olha, falando sério, eu acrescentaria que o responsável precisa ter poder de dizer não para um pedido de mudança que quebra a apuração. Vi isso na nossa rotina: quando o key user só executa o que o negócio pede, ninguém segura a configuração errada antes do teste. Por isso eu daria também ao responsável a função de aprovar ou recusar cada alteração fiscal, com registro do motivo, e não só de ajustar o que foi pedido.