Alçada de aprovação de compras no Protheus: como configurar e o que muda com agentes

Alçada de aprovação é a regra que diz quem pode autorizar uma compra de acordo com o valor, a categoria ou o centro de custo. Ela existe para separar decisões: o que um comprador fecha sozinho, o que exige gestor e o que sobe para a diretoria. No Protheus, a alçada está distribuída em cadastros, parâmetros e uma rotina de liberação, e boa parte dos problemas de compras nasce da forma como isso foi configurado anos atrás e nunca revisto.

Este artigo mostra como o Protheus estrutura a alçada, os erros mais comuns em campo, como medir o tempo de aprovação com o log do próprio ERP e como a alçada fica quando um agente de IA passa a operar dentro dela.

Por que a alçada existe

Uma política de compras tem duas exigências que puxam em direções opostas. A primeira é controle: ninguém compromete o caixa acima do que pode. A segunda é velocidade: uma solicitação de material de consumo não pode esperar a agenda de um diretor.

A alçada resolve essa tensão com faixas. Até certo valor, o comprador decide. Acima, um gestor confirma. Acima ainda, mais um nível.

O problema é que a alçada envelhece. A empresa cresce, os preços mudam, as pessoas trocam de cargo, e a regra escrita no ERP continua a mesma. Sobre o contexto de compras no ERP, veja a página sobre Protheus.

Como o Protheus estrutura a alçada

O Protheus trata a alçada em três camadas: quem aprova, o que passa por aprovação e como a liberação acontece.

Grupos de aprovação e aprovadores. O cadastro de aprovadores define cada pessoa com seu limite de valor. O grupo de aprovação reúne aprovadores em níveis: nível 1 até um valor, nível 2 acima dele, e assim por diante. O grupo é associado ao documento conforme a parametrização da empresa, por comprador, por grupo de produtos ou por outro critério.

Documentos sujeitos a alçada. Por parâmetro, a empresa decide quais documentos passam por aprovação: a solicitação de compras (SC, rotina MATA110), a cotação (MATA150, com a análise em MATA160) e o pedido de compra (MATA120 ou MATA121). É comum ativar alçada só no pedido, ou na SC e no pedido.

Liberação de documentos. A rotina MATA094 é onde o aprovador vê a fila de documentos pendentes e libera, bloqueia ou transfere. Cada liberação gera um registro na tabela de documentos com alçada (SCR), com usuário, data e hora. Esse registro é a base para medir o tempo de aprovação.

Quando o pedido é criado por integração, seja via API REST ou ExecAuto, ele passa pela mesma alçada de um pedido digitado. Um agente que emite pedidos não contorna a regra, entra nela.

Erros comuns de configuração

Quatro padrões aparecem com frequência em ambientes Protheus com anos de uso.

• Alçada única para tudo. Um limite só, sem distinção de categoria. Compra de matéria-prima e compra de material de escritório passam pelo mesmo caminho, e o gestor aprova cem pedidos pequenos para olhar de verdade dois grandes.
• Aprovador gargalo. Um nome no topo de vários grupos. Quando essa pessoa viaja, a fila para.
• Exceções por e-mail fora do sistema. O pedido urgente é aprovado por mensagem e alguém libera no MATA094 depois. O ERP registra a liberação, não a decisão real.
• Alçada que ninguém revisa. Limites definidos em outra realidade de preços. O que era compra grande virou rotina, e continua exigindo diretor.

Nenhum desses erros aparece na tela de configuração. Aparecem no tempo de ciclo e na quantidade de pedidos aprovados em bloco às 18h de sexta.

Como medir o tempo de aprovação com o log do ERP

O Protheus já registra tudo que é preciso para medir. A SC tem data de emissão e de aprovação; a cotação tem data de geração e de análise; o pedido tem data de emissão, e a liberação fica na SCR com usuário e hora. Colocar esses eventos em sequência por documento é o que o process mining faz.

Três perguntas ganham resposta objetiva.

Quanto tempo cada nível leva? Se o nível 2 demora dias e o nível 1 demora horas, o problema está em uma pessoa, não na política.

Quantos documentos são aprovados sem olhar? Aprovações em bloco, dezenas no mesmo minuto, indicam que a alçada é formalidade naquele nível.

Quanto do ciclo é espera? Exemplo ilustrativo: um pedido de R$ 2.500 com ciclo de 7 dias, em que 6 dias e 20 horas são fila de aprovação.

Esses números são o ponto de partida para redesenhar as faixas. Os KPIs de compras mais usados, como tempo de ciclo e taxa de pedidos emergenciais, dependem diretamente deles.

Como fica a alçada com um agente de IA

Um agente de IA para compras não muda a alçada do Protheus. Ele ganha uma alçada própria, definida pelo comprador, dentro da que já existe.

O agente decide dentro do limite. Para itens de cauda, o comprador define faixa de valor, piso de preço com tolerância, fornecedores homologados e condições. Dentro dessa regra, o agente cota, negocia e emite o pedido via API REST ou ExecAuto. O pedido nasce no Protheus e segue a alçada do ERP como qualquer outro.

O humano aprova a exceção. Preço acima da tolerância, fornecedor novo, item crítico ou condição fora da política: o agente para, monta o resumo e encaminha ao comprador. A aprovação deixa de ser uma fila de cem itens iguais e vira uma lista curta do que saiu da regra.

Cada decisão fica registrada. Além do registro do Protheus na SCR, o agente guarda o histórico consultado, os fornecedores cotados, as propostas, a contraproposta, a regra aplicada e o motivo da decisão.

Na prática, o Agente Negociador da UpFlux opera assim em compras de cauda: a alçada do ERP continua valendo, o comprador escreve a regra do agente e a revisa quando quiser. É o oposto da exceção por e-mail: tudo que sai da regra passa pelo sistema.

Para o volume de pedidos pequenos que costuma entupir o MATA094, veja tail spend e compras indiretas.

Perguntas frequentes

Onde se configura a alçada de aprovação no Protheus?

Em três lugares: no cadastro de aprovadores e grupos de aprovação, que define quem aprova e até que valor em cada nível; nos parâmetros que dizem quais documentos passam por alçada (SC, cotação, pedido); e na rotina de liberação de documentos, MATA094, onde as aprovações acontecem e ficam registradas na tabela SCR.

Como saber se a alçada está gerando atraso?

Medindo o intervalo entre a emissão e a liberação de cada documento no log do próprio Protheus, e separando por nível e por aprovador. A UpFlux faz esse diagnóstico por process mining a partir de um export de eventos de compras, sem instalar nada no ERP, e entrega onde o tempo se perde e quais aprovações são só formalidade.

Um agente de IA passa por cima da alçada?

Não. O agente cria o pedido pela API REST ou pelo ExecAuto, e o Protheus aplica a mesma alçada de um pedido digitado. Além disso, o agente tem uma alçada própria, definida pelo comprador, que limita valor, preço, fornecedores e condições. O que sai dela vai para aprovação humana, com o registro completo da decisão.

Vale a pena rever a alçada antes de colocar um agente?

Sim, e a medição ajuda a decidir. Faixas desenhadas para outra realidade de preços criam fila sem controle real. Na experiência da UpFlux, o roteiro mais eficiente é medir o tempo por nível, redesenhar as faixas com os dados e só então definir a alçada do agente para a cauda, que passa a operar dentro das duas regras.