Pular para o conteúdo
Como funciona este fórum

Moderado por Emanuel Kaufman. As três primeiras mensagens de cada pessoa passam por revisão e respondemos em até 1 dia útil.

Aqui se discute o comportamento do sistema. Decisão tributária é sempre da sua empresa, e ninguém neste fórum dá parecer.

Tudo o que você publicar é público e pode ser usado por terceiros, inclusive por sistemas de IA. Não publique dado de cliente, nome de empresa nem tela do produto.

Esta pergunta foi sinalizada
6 Respostas

Pessoal, estou passando por um processo de implementação fiscal no S/4HANA 1909 e, embora tenhamos mapeado os requisitos, o rollout tem gerado algumas surpresas no fechamento. Passou por situação parecida no fechamento do mês passado, e achei que podemos compartilhar experiências. Já fizemos os testes de ponta a ponta e os cenários mitigados, mas ao rodar o primeiro cenário completo, alguns documentos gerados não estão refletindo o esperado no módulo tributário. Olha, no fim das contas, eu gostaria de saber se vocês identificaram algum ponto crítico ou erro recorrente neste estágio inicial de operação. Quais são os tropeços mais comuns que vocês encontraram ao levar um sistema à operação fiscal completa?


Atualização:

Olha, no fim das contas, pessoal, agradeço muito as contribuições de vocês. Já vivenciei essa passagem do teste para o real e o volume faz toda diferença. Olhando para o que discutimos, dedicamos tempo revisando os logs de saída para verificar a correta composição dos valores tributários versus o esperado no cenário mitigado. Gostaria de saber se alguém encontrou algum gargalo específico no processo de determinação da base de cálculo que costuma ser negligenciado durante as simulações mais controladas.


Atualização:

Olha, no fim das contas, percebi que revisitar os logs de saída para cotejar a composição dos valores tributários versus o esperado no cenário mitigado foi crucial para nós. Diante de tudo que foi compartilhado sobre a sequência de eventos e a geração de documentos, gostaria de saber se alguém identificou um ponto de falha comum na gestão dos dados mestre que potencializa incorreção no cálculo durante o rollout.

Avatar
Cancelar
Melhor resposta

A transição para um novo ambiente fiscal exige atenção além da apuração tributária. É fundamental que a integridade dos dados cadastrais que alimentam o módulo de cálculo esteja perfeita antes da ativação em produção. Variações mínimas nesses dados mestres podem desencadear impactos tributários não previstos, mesmo que o volume de transações simulado tenha sido pequeno. Além disso, a correta sequência de geração e encadeamento dos documentos fiscais intermediários é decisiva. Recomendamos dedicar esforço à simulação de cenários marginais, daqueles que forçam o sistema a percorrer caminhos menos usuais, para validar a robustez do fluxo completo.

Avatar
Cancelar
Melhor resposta

Débora Teixeira, pensando na experiência de vocês, eu gostaria de adicionar um aspecto relacionado à parametrização do fluxo de documentos. Muitas vezes, o problema não reside apenas no cálculo ou na regra de negócio, mas na forma como o sistema encadeia os documentos intermediários. Se o passo anterior não estiver gerando a informação necessária para o próximo estágio, o resultado final pode estar incorreto. O risco é, pois é, que um detalhe inicial não mapeado reverta meses de esforço.

Avatar
Cancelar
Melhor resposta

Larissa Dias, eu concordo com o foco na base de cálculo. No meu time, ó, passamos por isso ao migrar para o S/4HANA. Além da composição dos valores, um erro comum que extrapola a simples transação é a inconsistência na parametrização de regras de negócio que afetam o cálculo tributário. Pequenos ajustes no timing de gatilho ou na sequência de eventos podem levar a discrepâncias no resultado final, mesmo que os dados de entrada pareçam corretos no papel.

Avatar
Cancelar
Melhor resposta

No nosso contexto, o gargalo frequentemente não é o cálculo em si, mas como o sistema interpreta a sequência dos eventos fiscais. Muitas vezes, a regra de negócio tributária dispara em um ponto específico do fluxo que não foi considerado na fase de testes. Que eu saiba, dedicar um tempo extra para simular cenários extremos, aqueles que raramente ocorrem no dia a dia, mas que acionam diferentes caminhos no software, ajudou muito a mapear essas dependências críticas.

Avatar
Cancelar
Melhor resposta

Kátia Campos, concordo com o Nelson. Além da diferença de volume, um ponto que sempre gera retrabalho é a configuração inicial dos documentos fiscais gerados. Muitas vezes, o mapeamento do comportamento esperado é feito com um volume de transações baixo, mas quando o sistema encontra uma variação mínima no cadastro mestre, o impacto tributário se torna inesperado. Batendo o olho, ó, recomendo revisar a integridade dos dados mestres que alimentam o cálculo antes de qualquer execução em produção.

Avatar
Cancelar
Melhor resposta

Acredito que a principal dificuldade reside na transição do ambiente de teste para a operação real. O que costuma surpreender é a complexidade inerente à parametrização tributária ao vivo, que difere muito do que se simula em um ambiente controlado. Veja, no nosso caso, pequenos desvios no fluxo operacional que só se tornam evidentes quando o volume transacional é elevado. Essa passagem do papel ao executado é onde os detalhes mais esquecidos do mapeamento inicial costumam reprovar.

Avatar
Cancelar

Sua resposta

Tente oferecer uma resposta substancial. Se quiser comentar sobre a pergunta ou resposta, basta utilizar a ferramenta de comentários. Lembre-se de que você sempre pode revisar suas respostas - Não há necessidade de responder à mesma pergunta duas vezes. Não esqueça de votar - Selecionar as melhores perguntas e respostas é realmente útil!

Perguntas relacionadas

Mais conversas em Testes fiscais, cutover e go-live fiscal no S/4HANA.

Ver todas do fórum