Faturamento triangulado entre empresas, à prova de reprocessamento

Desafio

Uma indústria têxtil vende tecido cortado. O pedido nasce com o insumo, passa por uma operação de corte na matriz, vira produto acabado por uma tabela de equivalência e é transferido para a filial, que fatura para o cliente final. O ERP padrão não conhece esse desenho: para ele, cada empresa vê só a sua metade.

A primeira versão funcionava no caminho feliz. A produção trouxe o resto: um romaneio encerrado duas vezes com onze segundos de diferença duplicou a saída de estoque; cancelar a nota da filial apagava o pedido espelho em vez de devolvê-lo ao monitor; e a quantidade atendida era estornada duas vezes, uma pela customização e outra pela rotina padrão.

Solução

Idempotência por etapa. O encerramento do romaneio gera a saída do insumo e a entrada do acabado. Passei a registrar o progresso por romaneio, item e etapa: se o processo cai no meio e roda de novo, ele continua de onde parou e não repete movimento já feito.

Estorno em cascata. Cancelar a nota da filial ou a nota de transferência agora desfaz, na ordem certa, a quantidade atendida, os lançamentos do romaneio, o comprometido e o aceite, e recria o pedido espelho na filial. Cada estorno verifica se o padrão já fez a sua parte antes de fazer a dele. A dupla subtração foi diagnosticada lendo o log de alterações nativo do ERP, nó a nó, até achar quem gravava o quê.

Tradução no ponto certo. A troca de insumo por acabado acontecia na montagem da tela, então só abrir a tela já gravava dado. Mudei para o gatilho imediatamente anterior à geração da nota, com reversão no cancelamento da seleção.

Imposto da filial. O CFOP é recalculado e o ICMS usa a alíquota da UF da filial, não a do cliente do pedido, que é o que o padrão aplicaria.

Os casos que já tinham ficado inconsistentes foram corrigidos por scripts com simulação, backup e escopo conferido na base, um por incidente.

Resultado

Reprocessar deixou de ser perigoso: uma etapa que falha pode rodar de novo sem duplicar estoque. Cancelar uma nota passou a deixar pedido, estoque e espelho coerentes nas duas empresas, sem ajuste manual de dado. Tudo isso entrou por gatilhos, sem alterar o código do produto.

O que esse case mostra

Idempotência num ERP legado, sem transação distribuída, se constrói com controle explícito de etapa. Bug de dado se resolve com investigação no log, não com palpite. E customização convive com a rotina padrão quando cada estorno sabe o que o outro já fez.