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
5 Respostas

Olá pessoal, sou Adriana. Sou analista fiscal com uns doze anos de estrada, e embora meu foco não seja exclusivamente o fiscal, estou na trincheira com o assunto. Estamos migrando nosso ambiente para o S/4HANA 2021 e o tema da reforma tributária brasileira tem gerado um volume de ajustes enormes. Já tentamos mapear cenários específicos, como a validação da inscrição do emitente na SUFRAMA, utilizando o campo emit/ISUFemit, que indica se a informação é obrigatória. No entanto, encontramos um bloqueio recorrente referente à rejeição por dígito verificador inválido ao processarmos a Nota Fiscal. Um adendo, viu, isso tem ocorrido em algumas transações. Gostaria de saber se alguém enfrentou algo semelhante ao tentar conciliar essa validação durante a transição ou se há algum detalhe que estou deixando passar por conta da complexidade da transição.


Atualização:

Prezada equipe, obrigado pelas contribuições tão pertinentes sobre a integração tributária e a rejeição da SUFRAMA. Meu principal teste foi replicar este erro em um ambiente de homologação utilizando o lote de notas fiscais antigos, e o problema da não aceitação persiste mesmo após conferirmos a unicidade do número. Um adendo, viu, gostaria de saber se vocês observaram alguma funcionalidade trazida pelo S/4HANA que permita um tratamento mais granular ou um alerta específico sobre o cruzamento desses dados migrados, fugindo da simples rejeição total.


Atualização:

Agradeço a visibilidade de vocês sobre essa complicação. Fizemos o teste comparando o que o sistema antigo gerava com o que o S/4HANA espera, e a rejeição por dígito ainda aparece. Um adendo, viu, gostaria de saber se alguém mapeou algum caminho ou recurso interno para passar por essa checagem inicial do verificador sem prejudicar a trilha documental fiscal gerada.

Avatar
Cancelar
Melhor resposta

Entendo o impasse gerado pela validação do identificador da SUFRAMA ao passar ao novo módulo. A persistência dessa recusa, mesmo após a checagem dos dados trazidos do ambiente anterior, aponta para um ponto de fricção específico na aceitação do novo ambiente. O fato de o campo estar marcado como compulsório torna qualquer erro no dígito um bloqueio ao faturamento. Considerando este cenário, sugiro que vocês detalhem o processo interno de como o sistema atualiza ou gera este número antes da transmissão final. Isso nos ajudará a isolar se o gargalo é na geração do comando ou na interpretação dele pelo novo módulo. Para aprofundar, veja reforma tributária, CBS e IBS no SAP. Confirme com o tributário da empresa antes de aplicar.


Fontes oficiais consultadas

Avatar
Cancelar
Melhor resposta

Embora concorde com a necessidade de cruzar os dados legados, talvez seja prematuro concluir que o erro sempre reside na migração. O problema pode estar na própria janela de aceitação do novo sistema ao processar um volume migrado. Veja, no fim das contas, que mesmo com o campo emit/ISUFemit sinalizando obrigatoriedade, uma falha na validação do dígito verificador do sacrifício da SUFRAMA impede o prosseguimento da escrituração, independentemente da origem da informação.

Avatar
Cancelar
Melhor resposta

Olá Adriana, entendi bem o desafio de migrar o fluxo tributário para o novo sistema. A validação do dígito verificador da SUFRAMA realmente exige atenção redobrada na parametrização. No nosso cenário, ao lidar com o campo emit/ISUFemit marcado como obrigatório, o sistema rejeita a Nota Fiscal quando o número informado apresenta inconsistência. E aí, o curioso é que essa rejeição por dígito inválido impede o faturamento correto. É crucial que o mapeamento dos nossos dados de entrada espelhe exatamente o que o novo ambiente espera para avançar no fechamento.

Avatar
Cancelar
Melhor resposta

Adriana, para complementar o que você mencionou sobre a validação da SUFRAMA, eu queria trazer uma observação sobre a coerência entre os dados cadastrais legados e o que o S/4HANA 2023 está esperando. Na real, quando essa inconsistência do dígito aparece, precisamos verificar se o cadastro base no ERP antigo já estava com o número correto ou se o erro ocorreu durante a transmissão ou geração do documento. Às vezes, o problema não é o motor do novo sistema, mas sim um dado antigo mal migrado.

Avatar
Cancelar
Melhor resposta

Olha, ou seja, olá Adriana, complementando o que você trouxe sobre a checagem da SUFRAMA, achei interessante o seu olhar sobre a origem dos dados. No nosso caso, ao chegarmos nessa rejeição com o dígito incorreto, olhe, ou seja, passamos a olhar além da simples transmissão. É fundamental cruzar essa informação com os nossos registros internos mais antigos, aqueles que geraram o envio inicial. Às vezes, o erro não está na camada de geração do documento, mas sim em uma informação cadastral que foi herdada do sistema anterior e que ainda não foi completamente saneada para o novo padrão.

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 Reforma no SAP: visão geral e transição 2026 a 2033.

Ver todas do fórum