📅 Data de publicação
06/03/2026
🎯 Objetivo
A rotina Cons.log Aplicação é um recurso do Framework do Protheus voltado à consulta do log de atualização gerado durante a execução do compatibilizador UPDDISTR. Na prática, ela permite que o administrador ou consultor técnico visualize o histórico da atualização aplicada no ambiente e, quando a infraestrutura estiver corretamente configurada, também realize o envio desse log por e-mail. (TDN)
Esse recurso ganha importância principalmente em cenários de governança técnica, auditoria de atualização, rastreabilidade de changes, validação pós-update e compartilhamento de evidências com times internos ou parceiros. Em ambientes com múltiplos grupos de empresas, a correta interpretação da regra de configuração do e-mail é essencial, porque o envio do log não depende apenas de a rotina SMTP estar configurada, mas também de onde ela foi configurada em relação à forma de acesso utilizada. (TDN)
🧠 Visão geral da rotina
Segundo a documentação oficial da TOTVS, a rotina Cons.log Aplicação (Consulta Log da Aplicação) é responsável por exibir o Log de Atualização da execução do compatibilizador UPDDISTR. Em outras palavras, ela atua como uma interface de consulta do resultado técnico da atualização, permitindo ao administrador revisar o processamento executado e, adicionalmente, imprimir ou encaminhar esse conteúdo por e-mail. (TDN)
Além da consulta em si, a documentação enfatiza o comportamento do envio do log por e-mail, que está condicionado à configuração prévia da rotina E-mail/Proxy com os dados do servidor de e-mail. Sem esse pré-requisito, a funcionalidade de envio não estará apta a operar corretamente. (TDN)
🔧 Pré-requisito obrigatório
Antes de utilizar o envio do log por e-mail, é necessário que o ambiente possua a rotina E-mail/Proxy configurada com os dados do servidor de e-mail. Esse é o pré-requisito base para qualquer uma das formas de acesso descritas pela TOTVS. (TDN)
Aqui existe um ponto técnico muito importante: não basta apenas configurar o SMTP no ambiente. A efetividade do envio depende da forma como a rotina Cons.log Aplicação foi aberta e da relação entre essa forma de acesso e o grupo de empresas onde a configuração foi realizada. É exatamente esse detalhe que costuma gerar confusão em projetos, principalmente em ambientes com vários grupos de empresas e múltiplos contextos de execução. A própria documentação demonstra que o mesmo ambiente pode enviar corretamente ou falhar no envio apenas em função do grupo utilizado no acesso. (TDN)
🚪 Formas de acesso à rotina
A TOTVS informa que o acesso à rotina Cons.log Aplicação pode ocorrer de três formas distintas: pelo módulo Configurador (SIGACFG), pelo programa inicial UPDVIEWLOG no Client Protheus e pelo botão Consulta Log ao final da execução do UPDDISTR. (TDN)
Cada uma dessas formas possui uma regra própria para determinar em qual grupo de empresas a configuração da rotina E-mail/Proxy deve existir para que o envio do log por e-mail funcione. Essa diferenciação é o núcleo mais importante da documentação e deve ser compreendida com precisão.
1️⃣ Acesso pelo módulo Configurador (SIGACFG)
📌 Caminho de acesso
Quando a rotina é aberta a partir do Configurador, o caminho indicado pela TOTVS é:
Base de Dados > Gestão de Ambientes > Cons.log Aplicação (TDN)
📌 Regra de funcionamento do e-mail nesse modo
Ao acessar a rotina diretamente pelo SIGACFG, a configuração da rotina E-mail/Proxy precisa estar no grupo de empresas em que o usuário está logado no momento do acesso. (TDN)
Essa regra significa que o contexto do envio é diretamente associado ao grupo de empresas da sessão ativa no Configurador. Portanto, o sistema não procura a configuração em outro grupo “equivalente” ou “global”; ele espera encontrar a parametrização exatamente no contexto do grupo usado para abrir a rotina.
✅ Exemplo de envio com sucesso
A documentação traz o cenário em que o usuário:
acessa o SIGACFG pelo Grupo de Empresas 03;
configura a rotina E-mail/Proxy no Grupo 03;
acessa a rotina Cons.log Aplicação;
realiza a impressão do browse com o tipo E-mail.
Nesse caso, o comportamento esperado é que o e-mail seja enviado com sucesso. (TDN)
❌ Exemplo de falha no envio
No segundo exemplo da documentação:
o acesso ao SIGACFG ocorre pelo Grupo de Empresas 01;
a rotina E-mail/Proxy é configurada no Grupo 02;
a rotina Cons.log Aplicação é acessada normalmente;
a impressão do browse é feita com o tipo E-mail.
Nesse cenário, o comportamento esperado é que o e-mail não seja enviado, porque a configuração não está no mesmo grupo de empresas da sessão utilizada para acessar a rotina. (TDN)
🧭 Interpretação prática
Para times de sustentação, essa regra pode ser resumida assim:
Acesso pelo SIGACFG = o SMTP precisa estar configurado no mesmo grupo de empresas do login utilizado no Configurador.
Esse é o modelo mais intuitivo dos três, porque o contexto da sessão é explícito. Ainda assim, em clientes com múltiplas filiais lógicas ou estruturas separadas por grupo, é comum a configuração existir em um grupo diferente daquele usado pelo analista, o que leva à falsa impressão de erro no recurso, quando na verdade o problema é apenas de contexto operacional. A lógica apresentada pela TOTVS reforça que a rotina respeita o grupo do acesso, e não uma configuração genérica do ambiente. (TDN)
2️⃣ Acesso pelo programa inicial UPDVIEWLOG
📌 Como funciona esse modo
A segunda forma de acesso é informar UPDVIEWLOG diretamente no Programa Inicial do Client Protheus, seja no TOTVS Webapp ou no SmartClient. (TDN)
📌 Regra de funcionamento do e-mail nesse modo
Neste caso, a TOTVS define uma regra diferente da anterior: ao acessar a rotina diretamente pelo UPDVIEWLOG, a configuração da rotina E-mail/Proxy precisa estar no primeiro Grupo de Empresas do ambiente. (TDN)
Esse ponto é extremamente relevante. Aqui o envio não depende do grupo usado no login do Configurador, mas sim de uma referência estrutural do ambiente: o primeiro grupo de empresas.
✅ Exemplo de envio com sucesso
No exemplo positivo da documentação:
a configuração da rotina E-mail/Proxy foi realizada no Grupo de Empresas 01;
o acesso à rotina foi feito diretamente pelo programa inicial UPDVIEWLOG;
a impressão do browse foi realizada com o tipo E-mail.
Resultado esperado: o e-mail é enviado com sucesso. (TDN)
❌ Exemplo de falha no envio
No cenário de falha:
a rotina E-mail/Proxy foi configurada no Grupo de Empresas 02;
o acesso ocorreu diretamente pelo UPDVIEWLOG no programa inicial;
a impressão do browse foi feita com o tipo E-mail.
Resultado esperado: o e-mail não será enviado, justamente porque a configuração não estava no primeiro grupo do ambiente. (TDN)
🧭 Interpretação prática
A regra operacional aqui pode ser resumida assim:
Acesso pelo UPDVIEWLOG = o SMTP precisa estar configurado no primeiro grupo de empresas do ambiente.
Esse comportamento costuma surpreender equipes menos familiarizadas com o Framework, porque o acesso direto por programa inicial pode sugerir neutralidade de contexto, quando na realidade existe uma dependência objetiva do primeiro grupo do ambiente. Em termos de governança, isso pede padronização clara: sempre que a organização utilizar esse modo de consulta, é recomendável garantir que o grupo base do ambiente esteja devidamente preparado para suportar o envio do log. (TDN)
3️⃣ Acesso pelo compatibilizador UPDDISTR
📌 Como funciona esse modo
A terceira forma de acesso ocorre ao final da execução do compatibilizador UPDDISTR, clicando no botão Consulta Log. (TDN)
📌 Regra de funcionamento do e-mail nesse modo
Aqui a TOTVS define uma terceira regra, ainda mais específica: a configuração da rotina E-mail/Proxy precisa estar no PRIMEIRO Grupo de Empresas SELECIONADO na atualização do Update. (TDN)
Esse detalhe merece atenção máxima. Não se trata necessariamente do “primeiro grupo cadastrado no ambiente”, mas do primeiro grupo efetivamente selecionado no processo de atualização executado pelo UPDDISTR.
✅ Exemplo de envio com sucesso
A documentação apresenta o cenário em que:
a rotina E-mail/Proxy foi configurada no Grupo de Empresas 02;
o UPDDISTR foi executado selecionando apenas os Grupos 02, 03 e 04.
Como o primeiro grupo selecionado na atualização foi o Grupo 02, o comportamento esperado é que o e-mail seja enviado com sucesso. (TDN)
❌ Exemplo de falha no envio
No cenário de falha:
a rotina E-mail/Proxy foi configurada no Grupo de Empresas 01;
o UPDDISTR foi executado selecionando apenas os Grupos 02 e 03.
Nesse caso, como o primeiro grupo selecionado na atualização não foi o Grupo 01, o comportamento esperado é que o e-mail não seja enviado. (TDN)
🧭 Interpretação prática
A regra operacional pode ser resumida assim:
Acesso pelo botão Consulta Log do UPDDISTR = o SMTP precisa estar configurado no primeiro grupo selecionado naquele update.
Esse é, provavelmente, o cenário com maior potencial de erro operacional em clientes com múltiplos grupos. Isso ocorre porque muitos times assumem que basta a configuração existir em algum grupo válido do ambiente, quando a regra real depende da ordem e da seleção efetiva dos grupos no momento da atualização. A implicação prática é clara: antes de executar o update, a equipe deve validar não apenas os grupos que serão processados, mas também qual deles será considerado como primeiro grupo selecionado, pois esse detalhe impactará diretamente a capacidade de envio do log por e-mail. (TDN)
🖨️ Como ocorre o envio do log por e-mail
Nos cenários demonstrados pela TOTVS, o fluxo de envio é basicamente o mesmo:
acessar a rotina por uma das formas suportadas;
clicar em Imprimir Browse;
selecionar o tipo E-mail;
informar o endereço de e-mail destinatário;
confirmar a impressão/envio. (TDN)
Quando a configuração está correta conforme a regra do modo de acesso utilizado, o sistema conclui o processo com envio bem-sucedido. Quando não está, a documentação mostra que o sistema não envia o e-mail e apresenta mensagem informando a falha. (TDN)
Do ponto de vista funcional, isso torna a rotina especialmente útil para:
evidenciar tecnicamente uma atualização executada;
compartilhar o log com gestores, consultores ou fábrica de software;
compor trilhas de auditoria e documentação de mudança;
reduzir dependência de coleta manual de evidências após update.
⚠️ O ponto crítico da documentação: contexto do grupo de empresas
O maior valor técnico desta documentação está em deixar explícito que o funcionamento do envio por e-mail não é uniforme entre os três modos de acesso. A diferença entre eles é justamente o que mais gera dúvidas em campo. A síntese correta é a seguinte: (TDN)
SIGACFG: a configuração precisa estar no grupo logado no acesso à rotina.
UPDVIEWLOG: a configuração precisa estar no primeiro grupo do ambiente.
Consulta Log ao final do UPDDISTR: a configuração precisa estar no primeiro grupo selecionado na atualização. (TDN)
Essa distinção não é um detalhe menor. Em ambientes corporativos, ela impacta diretamente:
o planejamento de atualização;
o checklist técnico pré-update;
a documentação de homologação;
o procedimento operacional do time de sustentação;
a confiabilidade do processo de evidência pós-compatibilização.
🏗️ Boas práticas de administração do ambiente
Com base na documentação da TOTVS, algumas boas práticas se destacam por reduzir falhas operacionais e facilitar o uso da rotina:
✅ 1. Padronize a configuração do E-mail/Proxy
Mesmo que a regra varie conforme o modo de acesso, é recomendável que a equipe documente claramente onde o SMTP está configurado e qual forma de acesso será usada no procedimento padrão. Isso reduz ambiguidades e evita testes inconclusivos. A necessidade de configuração prévia da rotina E-mail/Proxy é explicitada pela TOTVS como pré-requisito do envio. (TDN)
✅ 2. Defina um procedimento padrão para consulta de log
Se a empresa sempre utiliza UPDVIEWLOG, o primeiro grupo do ambiente deve ser tratado como ponto crítico da configuração. Se o processo é feito pelo SIGACFG, o time precisa garantir coerência entre o grupo logado e o grupo configurado. Se o uso predominante ocorre ao final do UPDDISTR, o checklist do update deve validar o primeiro grupo selecionado. Essas regras decorrem diretamente do comportamento documentado pela TOTVS. (TDN)
✅ 3. Inclua essa validação no checklist de update
Em projetos com governança madura, vale incorporar ao checklist de atualização perguntas objetivas como:
qual será a forma de acesso ao log;
em qual grupo o SMTP está configurado;
esse grupo coincide com a regra do modo de acesso escolhido;
quem será o destinatário do log por e-mail;
a evidência será anexada ao chamado, à ata ou ao repositório técnico interno.
✅ 4. Evite assumir comportamento “global”
A documentação deixa claro que o envio não funciona com base em uma lógica simplesmente global do ambiente. O contexto de grupo de empresas é determinante, e ignorá-lo costuma ser a origem de incidentes funcionais. (TDN)
✅ 5. Use o recurso como evidência formal de atualização
Como a rotina exibe o log da execução do UPDDISTR, ela pode e deve ser utilizada como instrumento de rastreabilidade técnica da atualização, especialmente em operações AMS, gestão de mudanças, auditorias internas e processos de validação pós-liberação. A finalidade principal da rotina, segundo a TOTVS, é justamente exibir esse log de atualização. (TDN)
🧪 Resumo comparativo dos três cenários
🔹 Pelo SIGACFG
Melhor quando o administrador já está atuando no Configurador.
Depende do grupo logado na sessão.
Mais sensível à troca de grupo no acesso administrativo. (TDN)
🔹 Pelo UPDVIEWLOG
Útil para consulta direta via programa inicial.
Depende do primeiro grupo de empresas do ambiente.
Exige atenção à estrutura base do ambiente, não apenas ao grupo do usuário. (TDN)
🔹 Pelo botão Consulta Log do UPDDISTR
Mais aderente ao fluxo de atualização recém-executada.
Depende do primeiro grupo selecionado no update.
É o cenário que mais exige disciplina operacional no momento da seleção dos grupos. (TDN)
🎓 Conclusão
A rotina Cons.log Aplicação é um recurso simples na aparência, mas bastante relevante do ponto de vista operacional e de governança técnica no Protheus. Sua principal função é permitir a consulta do log de atualização gerado pelo UPDDISTR, oferecendo também a possibilidade de encaminhamento por e-mail quando a rotina E-mail/Proxy estiver corretamente configurada. (TDN)
O aspecto mais importante da documentação da TOTVS está na dependência do contexto de grupo de empresas, que varia conforme a forma de acesso adotada. Esse comportamento precisa ser entendido com precisão por administradores, consultores e equipes AMS, porque a falha no envio do log muitas vezes não está relacionada ao SMTP em si, mas sim à configuração estar em um grupo diferente daquele exigido pela regra daquele modo de acesso. (TDN)
Em termos práticos, dominar essa rotina significa reduzir retrabalho, melhorar a rastreabilidade das atualizações, padronizar evidências técnicas e fortalecer a governança do ambiente Protheus. Para operações maduras, a recomendação é transformar essas regras em procedimento operacional padrão, especialmente em clientes com múltiplos grupos de empresas e rotinas frequentes de atualização. A documentação oficial publicada em 07/10/2025 detalha exatamente esses cenários e seus comportamentos esperados. (TDN)
❓ FAQ
1. O que é a rotina Cons.log Aplicação?
É a rotina responsável por exibir o log de atualização da execução do compatibilizador UPDDISTR no Protheus. (TDN)
2. É possível enviar esse log por e-mail?
Sim. A documentação da TOTVS informa que é possível realizar o envio do log por e-mail, desde que a rotina E-mail/Proxy esteja corretamente configurada com os dados do servidor de e-mail. (TDN)
3. Onde acesso a rotina pelo Configurador?
No SIGACFG, pelo caminho Base de Dados > Gestão de Ambientes > Cons.log Aplicação. (TDN)
4. O envio por e-mail funciona igual em qualquer forma de acesso?
Não. A regra muda conforme o modo de acesso:
no SIGACFG, vale o grupo logado;
no UPDVIEWLOG, vale o primeiro grupo do ambiente;
no UPDDISTR, vale o primeiro grupo selecionado na atualização. (TDN)
5. Qual é o erro mais comum nesse processo?
O erro mais comum é supor que basta o SMTP estar configurado em qualquer grupo. A documentação mostra que o envio depende do grupo correto conforme a forma de acesso utilizada. (TDN)
6. Posso usar essa rotina como evidência de update?
Sim. Como ela exibe o log da atualização executada pelo UPDDISTR, é um recurso muito útil para documentação técnica, auditoria e governança de mudanças. (TDN)
👤 Autor
Fabrizio Augusto Ventavolo
“Conectamos tecnologia, processos e pessoas para acelerar resultados com excelência em sistemas TOTVS.”
As diretrizes de comunicação institucional da Mastersiga reforçam os pilares de Excelência, Inovação e Conectividade, alinhados à proposta deste conteúdo técnico.