Quando a regra gera valor errado no GUEPARDO Tax, TI ou fiscal responde?

O que temos aqui é um ponto de desenvolvimento. Meu adendo, é que regra implementada em programa próprio tem dono técnico, e a documentação de projeto alerta que extensões Z quebram na atualização e ninguém sabe dizer qual existe, quem escreveu e o que assume do produto. O inventário de extensões entra na divisão: cada Z com dono, descrição da regra que ele aplica e teste de regressão antes de cada atualização.

Sou novo nisso, desculpem, e discordo de dividir só por papel. Veja, eu aprendi na marra que o erro costuma aparecer tarde: a documentação de projeto registra divergência descoberta só na homologação do cliente, perto da data de exigência.

1. Dado mestre: quem cadastra.
2. Regra: quem define.
3. Parametrização: quem configura.
4. Homologação: quem aceita.

Cada elo precisa de dono, senão o erro cai no elo sem dono.

Vou direto: a documentação que consultamos não define quem responde por valor errado no GUEPARDO Tax, então essa divisão é de governança do cliente, não do produto. Então, de modo geral, o que funciona é registrar por escrito, antes do go-live, três papéis: quem define a regra (fiscal), quem parametriza (TI ou consultoria) e quem homologa. A documentação de projeto lista os testes e diz que a homologação do cliente inclui a interpretação tributária. Linha de registro:

regra | quem definiu | quem parametrizou | quem homologou | data

E aí, pessoal. Aqui a gente adotou outro desenho: em vez de papéis fixos, cada alteração de regra abre um registro com três assinaturas antes de ir a produção. Olha, quer dizer, o erro continua possível, mas a pergunta "quem assinou" tem resposta em segundos. Serve para auditoria porque a trilha mostra a decisão e a data, não só a pessoa que clicou no botão de transporte.