Como versionar mudanças de parametrização fiscal com o GUEPARDO Tax?

Tirando a prova, ó, discordo de começar só por foto de tabela. Parametrização fiscal quase sempre vem junto com extensão Z, e a foto não pega código.

Segundo o material de governança, extensões em torno do fiscal são a parte que mais quebra na atualização, e a regra de decisão é inventário vivo com dono, objetivo e o que cada extensão assume do produto. Versione as duas coisas juntas ou a volta a um estado conhecido volta pela metade.

Então, pra constar, aqui a gente fez de outro jeito: foto antes e depois. Em cada transporte, exportamos o conteúdo das tabelas que a mudança toca, gravamos com data no repositório do projeto e comparamos os dois arquivos linha a linha.

O diff vira o anexo do chamado. Voltar a um estado conhecido é reimportar a foto anterior no ambiente de teste primeiro. Não é elegante, mas funcionou nas três mudanças de alíquota que enfrentamos.

Na real, né, o produto não é a parte que eu confiaria sozinha para isso. O que temos de documentação não afirma que o GUEPARDO Tax guarde histórico de versões da parametrização. Confirme com a NTT ou teste no ambiente.

Enquanto isso, o controle por fora precisa ter, para cada mudança: o que mudou, quem pediu, quem aplicou, data, motivo e como desfazer. Sem a última coluna, não é versionamento, é diário.

No go-live a gente aprendeu que o inventário vale mais que o histórico. Segundo a documentação da NTT, na configuração da FSI o código de configuração vale para todas as apurações criadas com ele. Ou seja, uma mudança num código atinge todas as apurações vinculadas.

Por isso a regra aqui é: antes de mexer, listar o que depende daquele parâmetro. Mudança sem essa lista é a que causa susto no fechamento.