Quem deve ser o responsável por qual módulo do GUEPARDO atende o que você precisa dentro da empresa?

A gente chegou a um meio termo que funcionou para nós no nosso caso, pois é difícil definir um culpado por cada etapa. Decidimos que o ERP faria a camada inicial de detalhamento, como sempre fizemos. Mas foi estabelecido um ponto de checagem específico onde o módulo entrava para validar a tributação complexa. Se a estrutura básica do lançamento estava correta, o fluxo seguia. Se não, o módulo sinalizava a necessidade de ajuste na fonte, e não assumia a responsabilidade de refazer o lançamento inteiro.

Complementando a linha de raciocínio da Kátia, acho importante focar na granularidade da informação trocada. No ECC 6.0, muitas vezes o volume de dados enviados era muito bruto. Para que o novo sistema de taxação realmente agregue valor, ele precisa de um nível de detalhamento que o legado talvez não fornecesse nativamente. E aí, pelo que testei, definir um contrato de dados bem específico para a passagem de informações, delimitando exatamente o que é responsabilidade do ERP e o que é do módulo, é o que evita essa disputa sobre quem errou no lançamento inicial.

Compreendo o argumento de que o módulo de taxação deve ser o validador primário, dada a alta dinâmica tributária. No entanto, minha experiência com o ECC 6.0 sugere que transferir totalmente a validação para o novo sistema gera um gargalo inicial enorme. Então, pensando bem, acho que o ideal é que o módulo receba os dados já processados pelo sistema legado, mas que ele valide a aderência à regra, e não que ele precise refazer todo o processo de extração dos dados brutos do ERP.

Acho que ainda há um ponto a clarificar sobre a correção de base. Quando o módulo precisa corrigir inconsistências estruturais preexistentes no lançamento do ERP, isso sugere que o problema não é apenas de aplicação da regra fiscal, mas sim de integridade do dado de origem. Bem, seja como for, essa atribuição de correção primária deveria ser revisada no escopo da integração inicial para evitar que o sistema de taxação se torne um validador de qualidade de dados do ERP.

Na minha vivência recente, adotamos uma abordagem onde o ERP fornece todos os campos necessários, mas a validação cruzada das implicações fiscais é delegada ao módulo. Isso funcionou bem quando o volume de dados transacionais era alto, mas a complexidade tributária era variável. Então, eu aprendi na marra que se o fluxo de negócio for muito dinâmico, é mais seguro deixar o sistema de taxação como o validador primário das regras específicas, e não apenas um processador passivo do que o ERP emite.

Ana Guimarães: Meu raciocínio, baseado na minha experiência com siderurgia e S/4HANA, é que a clareza reside na sequência dos eventos. O sistema de origem fornece os dados brutos, e o módulo de taxação entra justamente para aplicar o filtro regulatório. Precisamos concordar se a função do módulo é complementar ou corretiva ao que o ERP gera. Vale registrar, né, que essa fronteira define quem assume o risco da não conformidade na entrega final.

Ana, sua colocação sobre a sequência dos fatos é pertinente. No meu cenário, vindo da mineração, a passagem dos dados brutos do ERP para o módulo de taxação é onde a maior fricção ocorre. Gostaria de saber sua visão prática, no rollout, viu, sobre como vocês estão definindo exatamente qual camada do GUEPARDO assume a validação da integridade desses dados vindos do sistema legado, minimizando retrabalho?

Samuel Matos: A transição de uma operação consolidada para a nova arquitetura, especialmente com a camada de taxação, naturalmente exige essa revisão profunda. Onde reside minha dificuldade é justamente na ponte entre o nosso processo de negócio acostumado e o que o software oferece. Tentamos encaixar o processo existente no módulo, mas o ideal seria que o módulo fosse desenhado para suportar nosso fluxo desde o início. Então, em geral, precisamos definir se o módulo trata da entrada de dados ou da regra de saída que valida essa informação.

Para mim, a definição clara de escopo para cada módulo do GUEPARDO Tax é crucial e já estamos vivenciando essa necessidade. Na minha jornada desde a implantação do ECC 6.0, acompanho processos que exigem essa granularidade para garantir a aderência fiscal correta. Bem, a fonte é o detalhamento do fluxo de ponta a ponta que cada funcionalidade endereça. É preciso mapear quais trilhas do sistema cobrem exatamente nossos procedimentos internos para otimizar a operação e minimizar riscos na entrega das informações.