Como o SAP deve tratar o split payment se a regra da LC 214/2025 mudar antes da implantação?

Discordo da ideia de tratar todas as operações do mesmo jeito. Como sempre, pois é, a operação industrial em área incentivada exige que o campo de origem venha informado, senão o cálculo não sabe em que regra cair. Discordo também que a data resolva sozinha, porque essa regra pode depender de processo que a Suframa tenha aceito e não só da data. Eu separaria a configuração em dois grupos antes de qualquer teste, um para as operações comuns e outro para as que têm benefício.

Daniela Monteiro, agora, a dica é olhar a unidade federada do fornecedor antes de cadastrar o split. Quando o fornecedor muda de região no meio do ano, a regra antiga continua valendo se ninguém atualizar o cadastro. Eu acrescentaria um campo de vigência no cadastro do fornecedor, e a regra só troca quando a data passar. Assim, a sua regra de travar o lote fica mais segura, porque a tela não depende de alguém lembrar de mudar nada.

O risco que já vi é o pagamento dividido sair antes da liberação. Bem, com a mão na massa, nós seguimos outro caminho, e deixamos a regra de split só para as entidades que já aparecem com dados completos no cadastro, e o restante fica em regra manual. Vale quando a base é pequena e as entidades envolvidas têm pouca variação. Se a lei mudar e a conta ainda não estiver validada, a gente trava o lote e não solta nada. Quando o volume cresce, aí sim vale automatizar tudo.

Quem responde pelo imposto nesse caso, Alexandre? Se não me engano, viu, a cláusula que trata do pagamento para conta de terceiro é a que mais pesa, e o conhecimento disso muda a configuração. O contribuinte precisa aparecer no cadastro certo, senão o split vai para a conta errada. Eu separaria o cadastro de bancos do cadastro de parceiros, porque misturar os dois gera erro que só aparece no fechamento.

Concordo em parte com a Larissa, no meu time, tá, a data de início ajuda muito. Discordo quando ela sugere que a configuração resolve tudo. A decisão de como tratar o pagamento é do cliente, e o sistema só executa o que as disposições internas dele definirem. Se o destinatário não constar na nota, a configuração aplica a regra errada sem aviso, e isso eu não deixaria passar.

A fonte é, na minha rotina automotiva, o split payment cai no pagamento de peças e a conciliação é mensal, então qualquer data errada aparece tarde. Larissa, a referência é o que você disse da data? Quando você fala em data de início, é a da nota ou a do pagamento apurado? Eu preciso desse detalhe para a avaliação do caso de uma nota com duas datas, porque a conciliação mensal não perdoa.

Quando a regra mudar, Roberta, antes de mais nada, pois é, eu colocaria a data como campo obrigatório. Os documentos apresentados pelo cliente precisam mostrar qual versão valeu em cada pagamento, e isso ajuda a auditoria a reconstruir o caminho. Se o split payment não tiver essa data, o aprovado no pagamento vira um número sem histórico. Eu testaria com um lote de pagamentos de um mês fechado antes de liberar a configuração para produção.

A referência precisa ser a que o cliente definir por escrito, porque a escolha tributária é dele, e o SAP só executa o que for parametrizado. Bem, a saída é cadastrar as duas regras com data de início, assim a operação amparada pela regra vigente naquele dia recebe o tratamento certo. Os textos que temos falam da posição dos estados e de benefício regional, e não falam de split payment, então isso não está resolvido por eles. Eu deixaria a análise da mudança com o jurídico do cliente, que analisará o caso antes de qualquer ajuste, e só depois a aplicação entra no sistema.