Contexto: Roteiro geral para atualizações de release do Protheus 12. Os pacotes, ferramentas e a ordem exata dos passos devem seguir as orientações oficiais da TOTVS para a release de destino e a arquitetura do seu ambiente.

Atualizar a release do Protheus é uma daquelas atividades que, quando dá certo, ninguém percebe — e, quando dá errado, todo mundo percebe na segunda-feira de manhã. A diferença entre os dois cenários quase nunca está na janela de atualização em si, mas no que foi feito antes dela.

Este checklist organiza o processo em três fases. Ele não substitui a documentação oficial da TOTVS para a sua release, mas ajuda a garantir que nada importante fique de fora.

Fase 1 — Antes: planejamento e preparação

Defina o escopo e a release de destino

  • Release de destino definida, conferindo o ciclo de vida de suporte das releases na documentação da TOTVS.
  • Notas de versão (release notes) lidas para os módulos que a empresa usa, com atenção a rotinas descontinuadas ou reescritas (por exemplo, migradas para MVC).
  • Versões compatíveis de AppServer, DBAccess, SmartClient e banco de dados identificadas.
  • Obrigações legais e fiscais que dependem da nova release mapeadas, com suas datas.

Inventarie as customizações

Esta é a etapa mais subestimada — e a que mais gera problemas depois.

  • Lista de fontes customizados compilados no RPO atual (o Inspetor de Funções da extensão TDS ajuda a levantar).
  • Lista de pontos de entrada em uso, com a rotina de cada um.
  • Campos, tabelas, índices, gatilhos e parâmetros customizados do dicionário.
  • Integrações (APIs, web services, importações por arquivo, jobs agendados).
  • Relatórios e telas customizados mais usados.
  • Para cada item, um responsável e um roteiro de teste.

Se a empresa não tem inventário de customizações, a atualização é a melhor oportunidade para criar um. Ele vai servir para todas as próximas.

Prepare o ambiente de homologação

  • Ambiente de homologação criado com cópia recente da base de produção.
  • Nova release aplicada na homologação: binários, RPO padrão e atualização de dicionário conforme o procedimento oficial (atualizador de dicionário UPDDISTR e pacotes da release).
  • Fontes customizados recompilados no novo RPO, com os erros de compilação corrigidos.
  • Pontos de entrada conferidos contra a documentação da nova release (ainda existem? mudaram parâmetros?).

Homologue com as áreas

  • Roteiro de testes por processo de negócio — compras, vendas, faturamento, fiscal, financeiro, estoque, contabilidade —, e não apenas por rotina.
  • Cada processo testado além do caminho feliz: variações de tipo de documento, TES, filial, cliente/fornecedor, exceções e execuções automáticas (jobs e integrações).
  • Resultados conferidos, não só a execução: um documento que gravou sem erro não está necessariamente certo. Compare impostos, valores, saldos, títulos e lançamentos contábeis com o mesmo cenário na versão atual (ou com o cálculo esperado pelo fiscal).
  • Testes executados pelos usuários-chave, com evidências registradas.
  • Integrações testadas de ponta a ponta com os sistemas externos.
  • Rotinas de fechamento testadas (estoque, fiscal, contábil), não só as do dia a dia.
  • Problemas encontrados registrados, priorizados e resolvidos ou com contorno definido.
  • Aceite formal das áreas para seguir com a produção.

Planeje a janela

  • Data definida longe de fechamentos e de picos de faturamento.
  • Tempo de execução medido na homologação (atualização de dicionário em base grande pode levar horas).
  • Plano de rollback escrito: o que restaurar, em que ordem, quem decide e até que horário é possível voltar.
  • Comunicação enviada aos usuários: data, horário de indisponibilidade e canal de suporte.
  • Equipe da janela definida, com contatos (incluindo suporte TOTVS e parceiros, se houver).

Fase 2 — Durante: a janela de atualização

  • Usuários desconectados e jobs, integrações e serviços REST parados.
  • Backup completo do banco de dados validado (não basta ter o arquivo: confira que ele restaura).
  • Backup dos binários, do RPO atual e dos arquivos de configuração (appserver.ini, dbaccess.ini).
  • Binários e RPO da nova release aplicados conforme o procedimento oficial.
  • Atualização de dicionário executada, com o log revisado — erros no log não podem ser ignorados.
  • Customizações aplicadas (RPO customizado ou patches gerados e validados na homologação).
  • Configurações de jobs, REST e integrações conferidas.
  • Teste de fumaça antes de liberar: login em cada módulo, inclusão de um pedido, emissão de uma nota em homologação fiscal, consulta financeira, execução de uma integração — conferindo também os valores gerados (impostos, títulos, saldos), e não apenas a ausência de erro.
  • Decisão formal de liberar ou voltar, dentro do horário limite do rollback.

Fase 3 — Depois: estabilização

  • Usuários avisados da liberação.
  • Plantão reforçado nos primeiros dias, com canal claro para registrar problemas.
  • Monitoramento de error.log, console do servidor e filas de integração.
  • Primeira emissão de notas, primeiro processamento financeiro e primeiro fechamento acompanhados de perto, com conferência por amostragem de impostos e valores junto ao fiscal e ao financeiro.
  • Desempenho de rotinas críticas comparado com o de antes da atualização.
  • Problemas registrados com causa e solução.
  • Lições aprendidas documentadas e inventário de customizações atualizado.
  • Ambiente de homologação mantido por um período, para comparar comportamentos.

Os erros que mais custam caro

Erro Consequência
Homologar só com a TI Processos de negócio quebram em produção
Testar só o caminho feliz Variações de TES, filial, tipo de documento e integrações falham na primeira semana
Considerar “rodou sem erro” como aprovado Documento classificado sem error.log, mas com impostos, valores ou contabilização diferentes do esperado — e o problema só aparece na apuração ou no fechamento
Ignorar pontos de entrada Regras da empresa param de funcionar sem aviso
Não testar fechamentos O problema aparece no fim do mês, com prazo apertado
Backup não testado O rollback falha justamente quando é necessário
Janela sem horário limite para voltar Decisão de rollback tomada tarde demais
Não comunicar as áreas Chamados em massa e desgaste com o negócio

Uma atualização de release bem conduzida é, acima de tudo, um projeto de gestão: escopo claro, inventário, homologação com as áreas e um plano de volta. Com isso, a segunda-feira passa a ser só mais uma segunda-feira.