Split payment with klarna

Se eu entendi bem, Diego, você vinculou pelo cadastro e não pelo documento fiscal. No meu caso, que é outro ERP migrando para SAP, os documentos eletrônicos chegam com dados parciais de pagamento. O efeito disso, vale registrar, muda a ordem da liquidação. Como você tratou o caso em que o arquivo eletrônico sai antes do pagamento ser liquidado?

O resultado que importa, Letícia, é que a classificação do parceiro só funciona se o desenvolvimento do cadastro acontecer antes do go live. Os campos deverão estar prontos antes disso, e o desenho do processo, como bem lembrou, né, está disposto em três etapas, para o sistema ler o tipo de cliente sem digitação manual. Na minha rotina de logística, sempre peço campo obrigatório, porque sem isso o split vira exceção em todo lote. Sugiro testar os campos novos num ambiente de homologação com um lote de pagamentos anonimizado.

Discordo da Beatriz, com respeito. Bom, a sacada é, pois é, que o problema não está só no cadastro do cliente. Eu vejo o conjunto de regras de liquidação como ponto principal, porque o split atinge quem não é contribuinte do IBS e da CBS no regime regular, e esse enquadramento precisa estar no sistema antes de tudo. Um contribuinte com cadastro certo ainda pode cair na conta errada se a regra estiver invertida. Por isso eu começaria pelo enquadramento de cada parceiro, com a decisão tributária registrada pelo próprio contribuinte.

Beatriz, a primeira coisa é separar os valores do pagamento antes de qualquer ajuste no documento, porque o split atua na liquidação e não no cadastro. O erro mais comum, de longe, é tratar o Klarna como simples meio de cobrança, quando ele é um dos canais que liquidam a transação. Aqueles que já passaram por isso costumam mapear primeiro o tipo de cliente e depois a bandeira. Os auditores compreendem essa ordem e, mais adiante, compreenderão também a prova do teste. Na prática, valide o cadastro de cada cliente antes de olhar o fluxo de pagamento inteiro.