Que validação no SAP impede o envio da tag IBSCBS/CST com um CST do IBS/CBS que não existe, conforme a rejeição 1020 da NT 2025.002?

Emanuel Kaufman, dado que o log interno aponta a falha tributária sem detalhar a regra exata, o foco deve migrar da simples geração do documento para a análise detalhada dos dados antes da saída. É preciso isolar o ponto de checagem que o sistema utiliza. Sugiro que voltemos à questão da codificação tributária, pois se o CST do IBS/CBS enviado não existe na tabela de Código de Situação Tributária, como mencionado na Obrigatória 311, o sistema mapeia isso como inconsistência grave antes do envio externo.

Eu e minha equipe enfrentamos o mesmo cenário em uma implementação anterior. Inicialmente, tentamos contornar a validação forçando a aplicação dos padrões fiscais esperados. Isso causou problemas sérios de conciliação gerados pelo fluxo de saída. Percebemos que, olhando o XML, pois é, a inconsistência raiz residia na forma como o sistema cruzava os dados tributários gerados internamente com os parâmetros de saída. Para operações futuras, ao invés de paliativos, trabalhamos na correção do mapeamento para endereçar o cerne da questão antes do envio.

Úrsula Machado, considerando sua vivência com a coerência do CST no S/4HANA, gostaria de saber um detalhe sobre essa checagem que você mencionou. Especificamente, qual funcionalidade ou parâmetro do sistema você acredita que deve ser revisado para garantir que a informação do IBS/CBS para a tag IBSCBS/CST esteja perfeitamente alinhada com o que o ambiente fiscal espera naquele momento da transação.

Rogério Cardoso, quando migramos, o que observamos ao analisar o log de saída foi que o sistema não aceitava a combinação dos dados. Parecia que a estrutura interna gerava um alerta de inconsistência mapeada no próprio fluxo antes do envio, mesmo que o disparo fosse subsequente. Essa fase de preparação dos dados fiscais era evidentemente onde residia a coerência que precisava ser estabelecida.

Luciana Jesus, baseado na minha experiência com o S/4HANA 1909, o que provavelmente ocorre é que o middleware fiscal do SAP está acionando uma regra de negócio que confronta o CST informado com a existência prévia desse mesmo indicador no cabeçalho da nota. Essa checagem interna é o que impede o envio quando há um desalinhamento entre o que o sistema gerou e o que o fisco espera. Agora, o custo é garantir que a parametrização da tributação no próprio ECC reflita com precisão a realidade da operação, antes mesmo do acionamento do protocolo.

Nós passamos por isso ao migrar o ERP antigo para o novo ambiente. Inicialmente, tentamos forçar o envio, mas isso apenas gerava inconsistências mapeadas no log de saída. Aprendemos que, para operações mais complexas, o cerne, pois é, está na fase de estruturação interna do documento. Antes de gerar o XML final, precisamos assegurar que todos os atributos tributários estejam sincronizados com a visão que o sistema espera. Essa sincronia é o que evita a rejeição na transmissão.

O próprio módulo fiscal do SAP realiza essa checagem antes da transmissão externa, validando a coerência entre o código tributário informado e a tributação esperada para aquela operação. Essa validação interna cruza os dados gerados no sistema com as regras de negócio configuradas para o documento fiscal. Então, por via das dúvidas, para mitigar esse tipo de rejeição na NT 2025.002, é fundamental garantir que o mapeamento do CST IBS/CBS esteja perfeitamente alinhado com o cenário tributário da operação antes de gerar o documento para envio.