Ariba na matriz, Protheus na filial: como operar compras nos dois

Integração entre o SAP Ariba e o Protheus é um assunto sobre o qual quase não existe material publicado, e é uma situação comum em multinacional com operação no Brasil: a matriz padronizou a suíte de procurement global, a operação brasileira continua no ERP nacional por causa da obrigação fiscal, e o comprador daqui trabalha com os dois abertos.

Este artigo não é sobre fazer os dois sistemas conversarem por API. É sobre entender o que cada camada resolve, onde o gasto escapa das duas e o que fazer com essa fatia sem abrir um projeto de integração.

Por que os dois sistemas coexistem no Brasil

A decisão raramente é de tecnologia. A matriz adota uma suíte de source-to-pay para ter visibilidade global de fornecedor, catálogo e contrato. A subsidiária brasileira mantém o Protheus ou o Datasul porque a saída fiscal vive lá: emissão e recebimento de NF-e, escrituração, SPED, obrigações acessórias e as particularidades de tributação que os ERPs nacionais tratam há décadas.

O resultado é uma divisão que se repete: a suíte global fica com sourcing, catálogo, contrato e homologação do fornecedor; o ERP nacional fica com o documento de compra que gera obrigação fiscal, o recebimento e o pagamento. As duas camadas fazem sentido. O que ninguém desenhou é o que acontece no meio.

As quatro rotas de um pedido nessa arquitetura

Na prática, o gasto de uma operação assim se distribui em quatro caminhos, e vale a pena saber o peso de cada um antes de discutir integração:

1. Catálogo global. Item com preço acordado pela matriz, comprado em self-service. Fluxo limpo, preço negociado uma vez, revisado em ciclo longo.
2. Evento de sourcing. Compra relevante que abre cotação ou leilão na suíte, normalmente acima de um valor de corte, com fornecedores convidados.
3. Contrato local. Fornecedor brasileiro com contrato assinado aqui, pedido emitido direto no ERP nacional.
4. Pedido avulso no ERP. Requisição aprovada que vira pedido sem passar por catálogo nem por cotação, porque o valor é baixo, a urgência é alta ou simplesmente porque não há tempo.

A quarta rota é a que interessa. Ela não aparece nos relatórios da suíte global, porque nunca entrou nela. E no relatório do ERP nacional ela aparece como pedido normal, indistinguível de um pedido negociado. É gasto invisível para as duas camadas ao mesmo tempo.

Onde o dinheiro escapa

O padrão que aparece quando se reconstrói o processo real a partir dos eventos do ERP é sempre o mesmo, com variação de tamanho:

• Item recorrente sem negociação. O mesmo material volta todo mês pela rota 4, sempre do mesmo fornecedor, sempre pelo preço anterior, porque ninguém tem tempo de cotar um item de valor baixo.
• Preço diferente entre filiais. O mesmo item, no mesmo mês, comprado por valores distintos em unidades diferentes. Nenhuma das duas compras está errada isoladamente; o que existe é a falta de um piso comum.
• Catálogo envelhecido. O preço acordado na entrada continua valendo dois anos depois, enquanto a própria empresa já comprou o item mais barato em outro canal.
• Pedido depois da nota. Compra feita por fora, regularizada no sistema depois, o que remove qualquer chance de negociar.

Nenhum desses casos é falha da suíte nem do ERP. Todos acontecem exatamente no espaço entre os dois, que é onde nenhum dos dois foi desenhado para atuar.

Por que o projeto de integração raramente resolve

A reação natural é propor um conector entre a suíte e o ERP nacional. Pode fazer sentido por outras razões, como cadastro único de fornecedor ou visibilidade consolidada de contrato. Mas para o problema descrito acima ele costuma entregar pouco, por três motivos.

O primeiro é escopo: o conector transporta documentos que já existem. O pedido da rota 4 continua nascendo sem negociação; ele só passa a ser visível dos dois lados.

O segundo é prazo. Integração entre suíte global e ERP brasileiro envolve mapeamento fiscal, homologação e janela de mudança da matriz. É medido em trimestres.

O terceiro é dono. O conector pertence a TI, e o problema é de compras. Quando o projeto entra na fila de prioridade global, a cauda local continua rodando como antes.

O caminho curto: operar pelo ERP

Existe um caminho mais rápido, e ele parte de um fato simples: todo pedido termina no ERP nacional. O que veio do catálogo global, o que saiu de um evento de sourcing e o que nasceu avulso: todos viram documento de compra no Protheus ou no Datasul, porque é de lá que sai a obrigação fiscal.

Isso significa que o ERP é o único ponto onde o gasto inteiro pode ser lido, sem depender de API da suíte, de janela da matriz ou de projeto de integração. E é por ali que dá para agir.

O process mining sobre os eventos do ERP reconstrói o caminho de cada pedido e mede as quatro rotas: quanto entrou por catálogo, quanto passou por cotação, quanto veio de contrato local e quanto foi emitido direto. Esse é o retrato que nenhuma das duas camadas produz sozinha, e ele costuma ser desconfortável na quarta linha.

Com o retrato, o trabalho na rota 4 é operacional, não estratégico: para cada item recorrente de baixo valor, buscar o menor preço que a própria empresa já pagou, no período e entre as filiais, e negociar a diferença. É trabalho volumoso, repetitivo e sem glamour, exatamente o tipo de coisa que um time digital de agentes faz bem e que um comprador humano nunca vai priorizar contra uma negociação de contrato grande.

No Protheus, o agente lê a solicitação aprovada e grava o pedido pelas rotinas padrão, respeitando a alçada e a liberação de documentos que já existem. No Datasul, pelas APIs padrão, com a aprovação do ERP mandando. No SAP, por BAPI e OData, dentro da estratégia de liberação. Em nenhum dos casos a política de compras da matriz muda: o que muda é que a rota 4 deixa de ser cega.

O que fica com cada camada

Vale dizer com todas as letras, porque a confusão é comum: nada disso substitui a suíte de procurement. O catálogo global, o contrato corporativo, a homologação de fornecedor e o evento de sourcing continuam onde estão, e continuam sendo a forma certa de tratar a compra grande e a compra estratégica.

O que muda é que a fatia que nunca passou por nenhuma das duas camadas deixa de ser gasto anônimo e passa a ser trabalhada pedido a pedido, com o resultado medido contra uma régua declarada antes de começar.

A página UpFlux + SAP Ariba descreve como isso funciona quando a matriz roda Ariba, e a página UpFlux + Protheus descreve a operação do lado do ERP nacional. Quem quiser entender primeiro o tamanho do problema pode começar pela curva C em compras.

Perguntas frequentes

Existe integração nativa entre o SAP Ariba e o Protheus?

Não existe conector padrão entre os dois. O que existe são integrações construídas caso a caso, normalmente por troca de documentos, e projetos assim envolvem mapeamento fiscal, homologação e janela de mudança da matriz. Para o problema do gasto que não passa por catálogo nem por cotação, a integração entre as suítes não é o caminho mais curto: o ERP nacional já concentra todos os pedidos, porque é dele que sai a obrigação fiscal.

Como medir quanto do gasto não passa pelo catálogo nem pela cotação?

Com process mining sobre os eventos do próprio ERP. O retrato separa o gasto em quatro rotas (catálogo global, evento de sourcing, contrato local e pedido avulso) e mostra o peso de cada uma. A UpFlux entrega esse retrato em duas semanas a partir do export de documentos de compras, sem customizar o ERP e sem pedir acesso à suíte de procurement.

A operação brasileira pode abandonar o ERP nacional e ficar só na suíte global?

Na prática, não. A emissão e o recebimento de nota fiscal eletrônica, a escrituração e as obrigações acessórias brasileiras são tratadas pelos ERPs nacionais, e é por isso que a arquitetura de dois sistemas persiste em multinacional com operação no Brasil. A decisão não costuma ser de preferência de compras, e sim de conformidade fiscal.

Um agente de IA operando no ERP quebra a política de compras da matriz?

Não, se ele operar dentro das regras que já existem. O pedido criado pelo agente passa pelas mesmas validações, alçadas e liberação de documentos de um pedido digitado por um comprador, e cada decisão fica registrada. Fornecedor novo, item crítico ou preço fora da tolerância continuam indo para a decisão humana. O que o agente assume é o volume repetitivo de baixo valor, não a exceção.