As frentes da TI em uma tabela
As versões mínimas de Application Server, DBAccess e License Server e a convivência da TES com o Configurador de Tributos estão em Protheus 12.1.2610: o que muda. Aqui ficam as mudanças que exigem trabalho da TI no ambiente.
| Frente | O que muda | Quando pesa | Risco se ficar para depois |
|---|---|---|---|
| c-tree | Driver e APIs removidos no AppServer 26.3.0.0 | Na troca do binário | Serviço não sobe e rotinas customizadas param |
| Privilégios | Grupo Default obrigatório em usuário novo; em 2027, para todos | No primeiro usuário criado na 2610 | Usuário novo sem acesso a nada |
| License Server | Versão 3.7.2 obrigatória a partir da LIB 20261016 | Na atualização da LIB, em qualquer release | A validação de licença falha |
| TSS | Usuários migram dos arquivos para o banco | Na atualização do TSS para a 2610 | Acesso às ferramentas e aos CNPJs fora do controle |
| Erro em tela | Pilha completa deixa de aparecer para o usuário | A partir da LIB 20261005 | Suporte sem o log que costumava receber por print |
| Arquitetura | TLS ponta a ponta e HTTP Broker obrigatórios | Na revisão de infraestrutura | Falha de sessão no WebApp |
Fim do c-tree no Application Server 26.3
A TOTVS anunciou a descontinuação definitiva do c-tree para outubro de 2026. Desde o Application Server 24.3.1.0, a chave CTreeMode e as seções ctreeServer e ctreeMaster já estavam descontinuadas. No 26.3.0.0, o driver e as APIs c-tree deixam de existir, e as bibliotecas e RDDs c-tree não são mais carregadas.
| Situação | O que acontece no 26.3.0.0 | O que fazer |
|---|---|---|
| LocalFiles com CTREE no appserver.ini | Mensagem de driver não suportado no console e o serviço é finalizado | Configurar LocalFiles com SQLITE |
| Fonte que chama função c-tree | Na compilação: chamada de função não suportada. No RPO já compilado: a execução é encerrada com erro de função não encontrada | Remover a função do fonte e recompilar |
| Customização com RDD CTREECDX ou CTREETMP | A RDD não é carregada | Trocar para a RDD SQLITE ou para a DBFCDX definida em LocalFiles |
As funções descontinuadas formam quatro famílias: as iniciadas por AX_ (como AX_RLock e AX_Transac), por BTV (como BTVCanOpen e BTVTables), por CT (como CTCanOpen, CTDeleteRec e CTreeDelIdxs) e por SPF_ (como SPF_Seek, SPF_Insert e SPF_Update), além de ConvertBackTTS e CtreeIntCleaner. A lista completa está na página da TOTVS citada nas fontes.
O ponto que mais pega em ambiente grande é o fonte antigo que ninguém lembra que existe: rotina de importação, arquivo temporário, integração feita há anos. Como o erro só aparece quando a rotina roda, a busca precisa ser feita no código, não esperando o usuário reclamar.
Varredura de c-tree no RPO e no appserver.ini é o primeiro item do diagnóstico. A Erpworks levanta os fontes customizados que usam funções e RDDs c-tree, ajusta e recompila numa cópia do ambiente antes de trocar o binário. Conheça o projeto de atualização para a 12.1.2610.
Grupo Default e controle por privilégios
Até a 12.1.2510, o acesso às rotinas podia ser dado pelo menu ou pelo controle por privilégios. O acesso pelo menu segue a lógica de permissão implícita: quem tem o menu acessa tudo o que está nele. A TOTVS aponta o risco disso: o mesmo usuário pode ter permissões diferentes para a mesma rotina em módulos diferentes.
| Release | Usuários novos | Usuários existentes |
|---|---|---|
| 12.1.2510 e anteriores | Menu ou privilégio | Menu ou privilégio |
| 12.1.2610 no lançamento | Grupo Default obrigatório: tudo negado até haver privilégio | Sem mudança, a não ser que o grupo Default seja incluído; depois de incluído, não sai mais |
| 12.1.2610 durante 2027 e seguintes | Negação por padrão para todos os usuários; o grupo Default deixa de existir e todo acesso depende de privilégio. A data exata sai nas notas da release | |
Com isso, a rotina continua precisando estar no menu, mas quem decide se o usuário vê e o que ele pode fazer é o privilégio. A opção da política que incluía o grupo Default automaticamente deixa de ter efeito, porque passa a valer sempre.
O privilégio também traz o que o menu não tem: validade da permissão, regra por empresa e filial e uma mesma permissão aplicada em todos os módulos, com acompanhamento pelo dashboard de privilégios. A TOTVS permite criar privilégios a partir dos menus existentes, o que encurta a adequação.
- Agora: definir quem cria usuários e como o acesso de um usuário novo será montado no primeiro dia.
- Antes de 2027: converter os menus atuais em privilégios por perfil, testar em homologação e só então incluir o grupo Default nos usuários existentes.
- Auditoria: aproveitar a conversão para revisar acessos acumulados, como usuários com o mesmo cadastro aberto para incluir em um módulo e excluir em outro.
License Server 3.7.2 para qualquer release
A partir da LIB 20261016, o Protheus passa a exigir o License Server 3.7.2, e a TOTVS deixa claro que a validação vale para qualquer release. Uma empresa que vai continuar na 12.1.2410 ou na 12.1.2510, mas atualiza a LIB, também precisa estar com o License Server na versão nova. Desde a LIB 20261005, a tela de informações do sistema (Shift+F6) também mostra dados do License Server.
Para a TI, a atualização do License Server deixa de ser um item do projeto da 2610 e passa a ser uma condição para aplicar qualquer LIB nova. Vale atualizar antes, numa janela própria, para que a virada da release não dependa disso.
Usuários do TSS no banco de dados
O TSS tinha dois cadastros separados: um para ferramentas como VSCode e APSDU (arquivo sigapss.spf) e outro para as rotinas TSSInterface, TSSMonitor e TSSManager (arquivo smallapppss.spf). Na 12.1.2610, os dois viram um cadastro único, guardado em tabelas do banco de dados, com usuário e senha iguais para as ferramentas e para as rotinas.
- Gerenciar usuários: inclusão, alteração e exclusão centralizadas, disponíveis só para o usuário admin.
- Vincular CNPJ: cada usuário enxerga nas interfaces do TSS apenas os CNPJs e CPFs vinculados a ele.
- APSDU: só o usuário Administrador mantém acesso.
- Instalação nova: o usuário admin é criado com senha em branco. Trocar a senha é o primeiro passo depois da instalação.
Em releases anteriores, o comportamento antigo continua. Para empresas com vários CNPJs e equipes fiscais separadas, o vínculo por CNPJ é a chance de limitar quem vê o quê no monitor de documentos.
Erro em tela sem pilha completa
A partir da LIB 20261005, a tela de erro mostra só a descrição da ocorrência. O error log completo, com pilha, ambiente e variáveis, vai para um arquivo na pasta fw_error_log do rootpath. A TOTVS justifica pela segurança: a tela completa expõe versões, diretórios e endereços que ajudam quem tenta forçar erros para mapear o sistema.
| Chave no appserver.ini | Efeito |
|---|---|
| DisplayFullLog=2 (padrão na LIB 20261005 em diante) | Descrição em tela e log completo em arquivo |
| DisplayFullLog=1 (padrão nas LIBs anteriores) | Log completo em tela |
| DisplayFullLog=0 | Só a pilha de chamadas em tela |
| KeepErrorLog | Dias de guarda do arquivo, de 4 (mínimo) a 15 |
O botão de enviar log por e-mail continua mandando o erro completo, e jobs e serviços REST seguem registrando no console.log. O que muda é o fluxo do suporte: o print que o usuário mandava deixa de ter a pilha, e quem atende precisa de acesso à pasta de logs. Na mesma LIB entra a autenticação OAuth 2.0 no envio de e-mail.
Regras de arquitetura da 2610
A TOTVS publicou para a 12.1.2610 o dimensionamento mínimo e diretrizes de arquitetura para instalações locais, com dicionário no banco e PostgreSQL, SQL Server ou Oracle. Parte delas é tratada como obrigatória.
- TLS ponta a ponta: tráfego criptografado (TLS 1.3 ou 1.2) entre WebApp, Broker, Application Servers e banco.
- HTTP Broker: obrigatório para distribuir sessões e atuar como proxy reverso. O balanceamento antigo, sem proxy reverso, é incompatível com o WebApp.
- DBAccess fora do servidor do banco: ele fica junto da camada de aplicação, de preferência uma instância por Application Server secundário.
- Homologação: só sistemas operacionais e bancos homologados são suportados, regra que vale desde a 12.1.2410.
- Virtualização: clock base mínimo de 2,3 GHz, perfil de energia de alto desempenho, CPU Ready abaixo de 3%, vCPU e memória dentro de um nó NUMA e reserva de 100% da RAM para as máquinas do ERP e do banco.
Também desde a 12.1.2410, o SmartClient instalado na estação foi descontinuado e o WebApp passou a ser obrigatório, assim como a autenticação nos serviços REST e SOAP. Quem ainda não fez essa migração precisa tratar as duas coisas junto com a 2610.
O que levantar no ambiente
- appserver.ini: LocalFiles, CTreeMode, seções ctreeServer e ctreeMaster, DisplayFullLog e KeepErrorLog, em todos os serviços.
- RPO customizado: chamadas às famílias AX_, BTV, CT e SPF_ e uso das RDDs CTREECDX e CTREETMP.
- Acesso: quantos usuários dependem só de menu, quem cria usuários e quais perfis existem de fato.
- Licença: versão atual do License Server e janela para a 3.7.2.
- TSS: quem usa APSDU e TSSMonitor hoje, e quais CNPJs cada equipe precisa ver.
- Infraestrutura: TLS entre as camadas, Broker, posição do DBAccess, versão do banco e do sistema operacional.
Roteiro da TI até a virada
A TOTVS bloqueia a volta para a release anterior depois da atualização. Por isso, o roteiro separa o que pode ser feito antes, no ambiente atual, do que depende da cópia de homologação.
| Etapa | Onde | O que conferir |
|---|---|---|
| Atualizar o License Server para 3.7.2 | Ambiente atual | Licenças distribuídas e Shift+F6 |
| Trocar LocalFiles para SQLITE | Homologação, depois produção | Serviço no ar e rotinas que usam arquivo local |
| Ajustar e recompilar fontes com c-tree | Homologação | Rotinas customizadas executando no AppServer 26.3 |
| Converter menus em privilégios | Homologação | Usuário novo de teste com o acesso certo por perfil |
| Migrar usuários do TSS e vincular CNPJs | Homologação | Login nas ferramentas e no monitor, senha do admin trocada |
| Definir o DisplayFullLog | Homologação | Erro gerado em teste e arquivo na fw_error_log |
| Revisar TLS, Broker e DBAccess | Infraestrutura | Sessões do WebApp estáveis sob carga |
As mudanças funcionais por área estão em Estoque e Custos, Contabilidade e Ativo, Faturamento e Compras e Financeiro.
Em resumo
- O Application Server 26.3.0.0 remove o driver e as APIs c-tree: LocalFiles vai para SQLITE e fontes com funções c-tree precisam ser ajustados e recompilados.
- Usuário novo na 12.1.2610 entra no grupo Default, com tudo negado até haver privilégio; em 2027 a regra vale para todos os usuários.
- O License Server 3.7.2 é obrigatório a partir da LIB 20261016, em qualquer release.
- Os usuários do TSS passam para o banco de dados, com cadastro único e vínculo por CNPJ.
- A tela de erro deixa de mostrar a pilha completa, e a 2610 exige TLS ponta a ponta e HTTP Broker para o WebApp.
Próximo passo: varrer o appserver.ini e o RPO atrás de c-tree, atualizar o License Server antes da release e converter os menus em privilégios ainda em 2026.
Fontes e referências
- TDN: LIB 20261016, pré-requisitos e pontos de atenção.
- TDN: Application Server, descontinuação do driver c-tree.
- TDN: Application Server, descontinuação do c-tree server e bound server.
- TDN: uso obrigatório do controle por privilégios para novos usuários.
- TDN: TSS0077, manutenção de usuários pelas interfaces do TSS.
- TDN: exibição de informações na ocorrência de erro em tela.
- TDN: 12.1.2610, recomendações de hardware.
- TDN: 12.1.2610, informações gerais sobre o release.
- TOTVS: portal da release 12.1.2610.
Perguntas frequentes
Principais dúvidas sobre o tema
O que acontece com o c-tree na 12.1.2610?
O driver e as APIs c-tree deixam de existir no Application Server 26.3.0.0. Com LocalFiles configurado como CTREE, o serviço é finalizado; fontes que usam funções c-tree param com erro e precisam ser ajustados e recompilados. A configuração indicada para LocalFiles é SQLITE.
Quais customizações usam c-tree?
As que chamam funções das famílias AX_, BTV, CT e SPF_, como CTCanOpen, SPF_Seek ou AX_RLock, e as que usam diretamente as RDDs CTREECDX ou CTREETMP. As RDDs podem ser trocadas pela SQLITE ou pela DBFCDX definida em LocalFiles.
O que é o grupo Default no Protheus 12.1.2610?
É o grupo que nega todos os acessos por padrão. Na 12.1.2610, ele é incluído de forma obrigatória em todo usuário novo, e o acesso passa a ser dado só pelo controle por privilégios. Nos usuários existentes, a inclusão é opcional e não pode ser desfeita.
Os usuários antigos vão perder acesso?
Não no lançamento da 12.1.2610. A TOTVS informa que, durante 2027, a negação por padrão será ligada para todos os usuários e o acesso dependerá só de privilégios. A data exata será informada nas notas da release.
Preciso do License Server 3.7.2 mesmo sem atualizar para a 2610?
Sim, se atualizar a LIB. A partir da LIB 20261016, a versão 3.7.2 do License Server é obrigatória para qualquer release do Protheus.
Por que a tela de erro do Protheus parou de mostrar os detalhes?
A partir da LIB 20261005, a chave DisplayFullLog passa a ter o valor 2 por padrão: a tela mostra só a descrição e o log completo vai para a pasta fw_error_log do rootpath. Para voltar ao comportamento anterior, configure DisplayFullLog=1 no appserver.ini.
Nota: este conteúdo tem finalidade informativa. Questões contratuais, tributárias ou jurídicas devem ser validadas com os responsáveis da sua empresa.
