Limpeza de cadastro no meio do projeto: congelar ou limpar em paralelo?

Dá para tirar essa escolha do achismo em três passos:

1. O fiscal escolhe os registros do piloto, e o projeto só diz quantos cabem na rodada.
2. Antes de limpar, rode uma nota de teste com cada registro e guarde o XML.
3. Depois da limpeza, rode de novo. Olhando o XML, ó, é só comparar os campos de imposto antes e depois, sem opinião.

Se a diferença for esperada, ela entra no registro de mudança. Se não for, o cadastro volta ao estado anterior.

Só completando, pelo lado da auditoria. Por precaução, pois é, eu guardaria uma foto do cadastro antes de cada onda de limpeza: extração dos campos fiscais com a data. Quando um teste falhar, a primeira pergunta é se o registro mudou desde a última rodada, e a foto responde sem discussão.

Outro cuidado: a página do produto que consultamos diz que o GUEPARDO Tax não corrige dado mestre ruim. Ninguém deve esperar que a ferramenta limpe o cadastro depois.

Congele só o que alimenta o teste e limpe o resto em paralelo. A verdade é que os dois extremos falham: congelar tudo para o negócio, limpar tudo invalida o teste.

Passo prático: liste os campos que o cálculo de imposto lê (NCM, origem, grupo de material, regime do parceiro), congele só esses durante a janela de teste e leve a limpeza dos demais para uma fila com data. Toda correção vira registro com data, quem mudou, valor antes e depois. Assim você reproduz um teste antigo.

Discordo em parte. Congelar só os campos que o imposto lê deixa passar o que ele lê indiretamente, como unidade de medida e grupo de mercadoria. Veja bem, pois é, já vi teste quebrar por um campo que ninguém achou que fosse fiscal.

Eu faria diferente no piloto: pegue um conjunto pequeno e fechado de materiais e parceiros, limpe, congele e rode todo o teste integrado só nele. O resto da limpeza corre solto, fora do teste, até esse conjunto passar.