Que dados de cada venda o SAP precisa guardar para comprovar a condição do adquirente no split payment simplificado?

Dúvida curta: a comprovação precisa acompanhar cada operação ou basta a originação do pedido? Nós adotamos outro caminho, bem, para variar: gravar a originação em uma tabela própria e ligar cada venda a ela. Isso vale quando o mesmo cliente tem várias operações ao mês e a regra de enquadramento muda com frequência. Para casos simples, uma linha de cadastro já responde. Explico quando vale cada um: a tabela própria dá rastreio, o cadastro dá rapidez, e a escolha depende do volume.

Se a venda chega informada pelo canal e a emissão já foi iniciada no SAP, como fica a regra? Fernanda, você mencionou a fila de eventos: ela resolve o caso da inutilização de nota? Na minha coordenação, de cabeça, ó, a dúvida é se a trilha mantém o status antes da emissão.

Na nossa rotina de indústria química, o caso concreto é a venda para distribuidor, e o cliente cobra a comprovação ao pé da letra, ó. Bruno, o seu ponto sobre a data é certo, e eu acrescentaria a versão do leiaute usado na emissão, que muda o que pode ser provado. Literal ou não, a metodologia precisa ser documentada e publicada. Não podemos depender de memória. Sugiro registrar a versão do leiaute junto com cada venda, para a prova não depender de lembrança.

O resultado que importa é que a comprovação não depende só do XML, e sim da trilha de eventos no SAP. Nós trabalhamos com outra saída: uma fila de eventos que registra cada etapa e um relatório que cruza a venda com o retorno do canal. A questão é que isso exige mais esforço inicial, mas evita retrabalho quando há rejeição. Nos incidentes de infinut, a trilha mostra o que aconteceu e por quê. Essa saída vale para quem tem muitas vendas e mais de um canal; para um volume pequeno, o campo obrigatório resolve.

Tenho uma dúvida prática. Gustavo, você falou que a chave da nota basta, mas a identificação do cliente muda quando há cadastro duplicado. Isso implica algum risco no comprovante? Se o incidente acontecer depois da emissão, e aí, em campo, dá para corrigir só o cadastro sem cancelar a venda?

O risco que já vi em produção é o campo de origem ficar vazio em venda feita por integração, e isso ninguém percebe até a auditoria. O campo existir não basta; bem, um alerta, ele precisa ser obrigatório na regra de faturamento. Discordo da ideia de guardar apenas o resultado da tabela, porque, se a tabela muda, a prova antiga efetivamente some. O ideal é o sistema manter a versão da regra que foi usada em cada venda. Só assim a comprovação continua valendo depois.

Concordo em parte com a comprovação por campo, porque ela é rápida. Discordo quando se pensa que basta gravar o valor, e o problema é que, viu, o valor sozinho não prova nada. Nós usamos uma tabela que recalcula os cálculos na hora da venda com a taxa média divulgada pela área tributária, e grava o resultado com a data. Essa saída vale quando o volume é grande e a regra muda pouco. Para vendas com débitos diferentes do padrão, prefiro o campo manual com justificativa, porque a tabela erra nos casos atípicos.

Dúvida curta: Gustavo, quando o contribuinte tem dois estabelecimentos, a chave da nota basta? Na minha auditoria vi que a condição do cliente mudou no meio do mês e o sistema não salvou o histórico. Olha só, né, esse é o ponto que mais preocupa, porque os créditos das vendas anteriores dependem da condição original. Sugiro manter uma linha de histórico por venda com a data de cada alteração. Assim a comprovação sai pronta para qualquer fiscalização e ninguém precisa reconstruir nada.

Quando a venda entra no split simplificado, o SAP precisa manter a data, o tipo de transação e a chave da nota assinada, porque essas três informações sustentam a comprovação. O valor do imposto também deve estar registrado, veja, um lembrete, mas ele é o que menos ajuda a provar o enquadramento, então não precisa ser o centro da tabela. O ponto que costuma faltar é o campo de origem do pedido, que deveria ser preenchido no momento da venda e não depois. Eu configuraria o aplicativo de faturamento para exigir esse campo e, se ele faltar, bloquear a emissão. Assim você comprova sem depender de ajuste manual no fechamento.