Configuração própria por desenvolvimento ou parametrização padrão: onde traçar a linha?

Discordo de tratar o urgente como exceção à regra. Por via das dúvidas, o urgente é justamente quando nasce o desenvolvimento sem dono.

Se for mesmo urgente, aceite o desenvolvimento provisório, mas com data de vencimento escrita: em tantos dias ele é revisto e vira parametrização ou entra no inventário. Sem a data, o provisório vira definitivo. A regra continua a mesma, só ganha um prazo para a dívida técnica.

Uma alternativa à discussão caso a caso é dar a cada lado uma lista fixa. Parametrização: o que depende de tabela, condição, CST ou CFOP e que o fiscal muda sem transporte de código. Desenvolvimento: cálculo que a tabela não expressa, ou integração com outro sistema.

Olha, o óbvio é que pedido da primeira lista nem chega ao time de TI. Pedido da segunda passa pela revisão do fiscal antes de programar. Com a lista, a briga vira consulta.

Completando a regra com o motivo: ao pé da letra, ó, é custo de vida. A mesma extensão que hoje economiza dois dias cobra a cada atualização, porque alguém precisa testá-la de novo.

Por isso o desenvolvimento só entra com inventário: dono, o que a extensão assume do produto e qual teste de regressão a cobre. O mesmo material diz que as extensões em torno do fiscal são a parte que mais quebra na atualização. Em dez anos de fiscal, nunca vi extensão sem dono dar certo.

A regra mais simples: parametrização primeiro, desenvolvimento só quando a parametrização não alcança. Como de costume, tá, o que falta é perguntar isso por escrito: o que a configuração padrão não consegue fazer neste caso? Se o pedido não responde, volta para o solicitante.

Se responde, o desenvolvimento entra com ponto de extensão previsto, nunca alterando objeto padrão. O material de projeto que consultamos descreve exatamente essa ordem para extensões Z em torno do fiscal.