IA no Protheus: como integrar agentes sem trocar o ERP

A maior parte dos projetos de IA corporativa para no mesmo lugar: um painel bonito que responde perguntas sobre o ERP mas nunca grava nada nele. Isso não é integração. É decoração. Colocar IA no Protheus de verdade significa fazer o agente executar transações, respeitar o TES, atravessar o fluxo de compras e devolver o controle ao humano no momento certo. O diferencial não está em ler os dados. Está em saber escrever neles sem quebrar a operação.

O Protheus não é um banco de dados

Esse é o primeiro erro conceitual de quase todo projeto de integração. Equipes técnicas olham para o Protheus e enxergam tabelas: SC7, SC1, SD1, SA1. E concluem, razoavelmente, que basta uma query ou um INSERT e o trabalho está feito. Não está.

O Protheus é um sistema de regras acumuladas ao longo de décadas. Cada tabela carrega filiais, moedas, datas de competência, vínculos fiscais e contábeis que só fazem sentido quando ativados pelas rotinas internas do sistema. Uma gravação direta no banco bypassa essas regras. O resultado pode parecer correto por dias, até que o contador ou o fiscal descubram que a nota entrou sem o lançamento contábil, ou que o pedido gerou saldo de estoque sem atualizar o custo médio. Integrar IA ao Protheus começa por aceitar que a operação tem que passar pelo Protheus, não por baixo dele.

TES: o vocabulário que o agente precisa dominar

TES é a sigla para Tipo de Entrada e Saída. No Protheus, é o código que diz ao sistema o que uma transação significa: se gera estoque, se gera financeiro, se atualiza custo, se aciona o fiscal, se integra com a contabilidade. Um pedido de compra com o TES errado pode criar um recebimento que não atualiza o saldo, gerar um lançamento contábil duplicado, ou simplesmente travar a integração com a SEFAZ mais tarde.

Para um agente de IA funcionar dentro do fluxo de compras do Protheus, ele precisa conhecer o TES antes de montar qualquer documento. Não é exagero dizer que o TES é o vocabulário do ERP: sem dominá-lo, o agente fala uma língua que o sistema não entende. O que torna isso difícil é que o TES não vive em um lugar só. Ele está em tabelas de configuração, em exceções por fornecedor, em regras por CFOP, em combinações que variam por filial. Mapear esse vocabulário para o agente é um trabalho de levantamento que precede qualquer linha de código de IA.

O agente que sabe gravar com o TES certo faz o que um analista experiente faz: não apenas preenche o campo, entende o que aquele campo aciona dentro do sistema.

O fluxo de compras como campo de prova

O fluxo de compras no Protheus é longo e ramificado. Começa na solicitação de compra (SC1), passa pelo pedido de compra (SC7), vai ao recebimento via MATA103 ou MATA104, cruza com a nota fiscal nas tabelas SD1 e SF1, e termina no contas a pagar (SE2) com os títulos para pagamento. Cada etapa tem suas próprias validações, seus campos obrigatórios, seus gatilhos internos.

É exatamente por isso que o fluxo de compras é o melhor laboratório para testar uma integração de IA com o Protheus. Ele é representativo o suficiente para exigir gravação transacional real, mas delimitado o suficiente para ser implementado em fases sem comprometer a operação inteira. Um agente bem construído para esse fluxo consegue receber uma requisição em linguagem natural, consultar os fornecedores ativos, verificar contratos vigentes, montar o pedido de compra com os campos corretos, propor o TES adequado e apresentar tudo isso para aprovação humana antes de tocar no sistema.

Gravação transacional: o que significa gravar de verdade

Gravar no Protheus de forma correta não significa fazer um POST numa tabela. Significa acionar as rotinas do sistema da mesma forma que um usuário faria pela interface, com todas as validações ativas. O caminho mais robusto é a camada de APIs REST que a TOTVS disponibiliza para o Protheus. Essas APIs encapsulam as regras de negócio: quando o agente chama o endpoint de criação de pedido de compra, o Protheus executa internamente as mesmas validações que executaria via tela. O TES é verificado. Os campos obrigatórios são checados. Os gatilhos contábeis e fiscais são acionados.

Existe também a abordagem via RPO customizado, que permite ao agente chamar funções AdvPL diretamente. É mais flexível e cobre casos que as APIs ainda não atingem, mas exige maior atenção à manutenção e ao versionamento. Em ambos os casos, o princípio é o mesmo: o agente nunca toca nas tabelas diretamente. Ele fala com o Protheus através das interfaces que o Protheus reconhece. Essa distinção entre gravar no banco e gravar no sistema é o que separa uma integração frágil de uma que vai para produção e fica.

A confirmação humana não é uma concessão

Há uma pressão natural, em projetos de automação, para eliminar etapas humanas. Cada aprovação manual parece um gargalo. A lógica de negócio diz: se o agente é confiável, por que parar? A resposta está na natureza do que está sendo gravado. Um pedido de compra no Protheus tem consequências fiscais, contábeis e financeiras que se propagam por meses. Um erro não se desfaz com Ctrl+Z: exige estorno, nota de devolução, ajuste contábil, às vezes comunicação com fornecedor e com o fisco.

A confirmação humana, nesse contexto, não é sinal de desconfiança no agente. É a arquitetura correta para o nível de risco da operação. O agente faz o trabalho pesado: levanta dados, propõe o documento, valida o TES, formata os campos. O humano revisa em segundos o que antes levava minutos e autoriza com conhecimento de causa. Essa divisão não é conservadorismo: é o que permite escalar sem acumular passivo operacional. Em operações que acompanhamos de perto, o resultado dessa arquitetura foi reduzir o tempo por pedido de 30 para 5 minutos, com a equipe mantendo o mesmo nível de controle e zerando os erros de digitação que antes chegavam ao ERP.

Automação sem confirmação humana no ponto certo não é eficiência. É risco transferido para mais longe, onde custa mais para corrigir.

Por que a maioria dos projetos não chega até aqui

Relatórios de grandes consultorias como McKinsey e Deloitte apontam que a maioria dos pilotos de IA não chega à produção. A observação é conhecida. O que raramente se discute é por que isso acontece especificamente no contexto de ERP. A razão mais comum não é técnica. É de profundidade de levantamento. Integrar IA ao Protheus exige entender o TES, o fluxo transacional, as regras de filial, as exceções de fornecedor, o comportamento das APIs em casos de erro. Esse levantamento leva tempo e exige proximidade com quem opera o sistema, não apenas com quem o administra tecnicamente.

Projetos que pulam essa etapa chegam a um agente que funciona no piloto mas quebra na primeira exceção real: um fornecedor com CFOP diferente, uma filial com configuração específica de TES, um recebimento parcial que o agente não sabe como tratar. Aí o projeto para. Não por falha da IA, mas por falta de modelo do domínio. O diferencial está em construir esse modelo antes de escrever o primeiro agente.

A infraestrutura que sustenta a operação em produção

Colocar IA no Protheus em produção exige mais do que o agente em si. É preciso um mecanismo de observabilidade que mostre o que o agente tentou gravar, o que o Protheus rejeitou e por quê. É preciso tratamento de erro que não deixe o fluxo pendurado entre um estado intermediário no agente e um estado inconsistente no ERP. É preciso log auditável para que o time financeiro ou fiscal possa responder perguntas sobre qualquer transação sem depender do time técnico.

Esses elementos não são sofisticação extra. São requisitos de operação. Um agente que grava no ERP sem eles não é uma solução: é um risco com interface bonita. Nossa abordagem é construir cada integração sobre uma fábrica de agentes que já entrega esses mecanismos por padrão: logs estruturados por transação, reprocessamento seguro em caso de falha, notificação ao operador quando uma gravação não é confirmada dentro do prazo esperado. Isso permite que a equipe do cliente opere o sistema com autonomia e sem dependência constante do time técnico para entender o que aconteceu.

O ERP fica. A operação muda.

A pergunta que abre muitas conversas sobre IA no Protheus é direta: precisamos trocar o ERP? A resposta, na quase totalidade dos casos, é não. O Protheus carrega anos de configuração, histórico transacional e regras de negócio que nenhuma migração transfere sem perda. O que muda é a camada que interage com ele. Agentes de IA assumem as tarefas repetitivas e estruturáveis: montar pedidos, conferir notas, acionar aprovações, preencher campos. O ERP continua sendo a fonte da verdade. O humano continua sendo o responsável pela decisão.

Essa arquitetura não é uma concessão ao conservadorismo. É o reconhecimento de que o valor real de integrar IA ao Protheus está em acelerar o que a equipe já sabe fazer bem, sem substituir o sistema que garante a integridade da operação. Quem entende isso constrói algo que vai para produção e escala. Quem não entende constrói um piloto que fica na apresentação.

Quer ler a sua operação a fundo?