Cada Service Pack do Linx ERP altera procedures, functions, triggers, telas, relatórios e scripts de banco. Em um ambiente sem customização, isso é transparente. Em uma rede de moda com anos de ajustes acumulados, é exatamente onde a atualização quebra.
Este é o roteiro que seguimos antes de qualquer atualização. Ele serve tanto para quem vai conduzir o processo internamente quanto para quem quer saber o que cobrar de um fornecedor.
1. Inventário do que é customizado
O primeiro passo é saber o que existe fora do padrão. No SQL Server do Linx ERP, isso costuma estar em:
- Objetos de banco criados pela empresa: procedures, functions, views e triggers com prefixo próprio ou fora da nomenclatura Linx.
- Objetos padrão alterados: procedures da Linx que receberam ajustes internos. Estes são os mais perigosos, porque o Service Pack sobrescreve sem avisar.
- Jobs do SQL Agent: rotinas noturnas de carga, integração e recálculo.
- Relatórios personalizados e consultas usadas por BI.
- Integrações externas que leem ou gravam direto no banco.
Uma consulta simples em sys.objects filtrando por data de modificação e por nome já entrega uma primeira lista. O ideal é manter esse inventário versionado, com o script de cada objeto salvo, para reaplicar depois.
2. Ler as notas da versão
Parece óbvio, mas raramente é feito. As notas do Service Pack listam os componentes alterados. Cruzar essa lista com o inventário do passo 1 mostra onde há conflito antes de encostar no ambiente.
Preste atenção especial em:
- Mudanças de estrutura em tabelas de movimento, estoque e fiscal.
- Procedures que suas customizações chamam ou que chamam suas customizações.
- Pré-requisitos de versão do SQL Server e do sistema operacional.
3. Ambiente de homologação com dados reais
Atualizar direto em produção não é opção. Restaure um backup recente em um servidor de homologação, com a mesma versão do SQL Server, e aplique o Service Pack ali primeiro.
Se a empresa não tem esse ambiente, este é o momento de criar. Um servidor modesto já resolve, e ele vai servir para todas as próximas atualizações e para testar customizações.
4. Roteiro de testes dos processos críticos
Defina, junto com a operação, o que não pode falhar. Em varejo de moda, normalmente:
- Venda no PDV e sincronização com o ERP.
- Faturamento e emissão de nota.
- Entrada de mercadoria e transferência entre lojas.
- Fechamento de caixa e conciliação.
- Rotinas de integração com e-commerce e franquias.
- Relatórios que a diretoria usa toda semana.
Execute cada item na homologação depois da atualização, com dados reais, e registre o resultado. Quem executa deve ser alguém da operação, não só da TI.
5. Plano de aplicação e de retorno
Com a homologação aprovada, planeje a janela de produção:
- Horário: fora do expediente das lojas, com margem para imprevistos.
- Backup completo imediatamente antes de começar, testado para restauração.
- Ordem de execução: Service Pack, reaplicação das customizações, validação.
- Critério de rollback: o que precisa falhar para voltar o backup, e quem decide.
- Comunicação: quem avisa as lojas e o que dizer caso a janela estoure.
6. Reaplicar e documentar
Depois do Service Pack, reaplique as customizações a partir do inventário, na ordem correta de dependência. Rode o roteiro de testes de novo, agora em produção, com acompanhamento nas primeiras horas do dia seguinte.
Por fim, atualize o inventário com o que mudou. A próxima atualização vai começar por ele.
Quanto tempo leva
Depende do volume de customização e do número de versões acumuladas. Um ambiente com poucas customizações e uma versão de defasagem se resolve em alguns dias. Um ambiente com muitos anos sem atualizar pode exigir semanas de homologação, principalmente se houver várias versões intermediárias obrigatórias.
O que não muda é a regra: nada em produção sem passar pela homologação.
Se a sua empresa está com o Linx ERP defasado e receio de atualizar, esse é exatamente o tipo de projeto que conduzimos. Veja mais em Atualização de versão ou fale com a gente.