A integração Protheus com Tray conecta o ERP da TOTVS à plataforma de e-commerce de forma automática: produtos, estoque, preços, pedidos, clientes, faturamento e documentos fiscais circulam entre os dois sistemas sem digitação manual.
Antes de entrar no funcionamento, vale resolver a confusão mais comum de quem avalia esse projeto: quem faz o quê. São três peças envolvidas, e cada uma resolve um problema distinto. A Tray vende, o Protheus governa, e a camada de integração traduz a conversa entre os dois. Nenhuma substitui a outra.
Entender essa divisão evita dois erros caros: achar que a plataforma de e-commerce resolve sozinha a parte fiscal e operacional dentro do ERP, ou imaginar que basta o Protheus estar bem configurado para o canal funcionar.
Neste conteúdo, você vai ver a função exata de cada peça, como o dado percorre esse caminho, o que a API da Tray permite de específico e por que a nota fiscal precisa nascer no ERP.
O que é a integração Protheus com Tray?
É a conexão automática entre o ERP TOTVS Protheus e a Tray, fazendo os dois sistemas trocarem dados sem intervenção manual.
O Protheus é o ERP mais configurável do portfólio da TOTVS, e essa flexibilidade é exatamente o que torna a integração delicada, porque cada empresa tem a própria parametrização. A Tray é uma plataforma de e-commerce brasileira, usada por operações que querem loja própria com recursos de plataforma madura.
A ponte entre os dois só funciona bem quando respeita o que cada lado exige de verdade: as rotinas e regras fiscais configuradas no ERP, e as características da API da plataforma. É a mesma lógica das demais conexões do ERP que a Plugar.me mantém para o Protheus.
Sua empresa está profissionalizando o e-commerce e percebeu que o Protheus continua recebendo pedidos por digitação? Esse é o elo que trava o crescimento do canal. Converse com a equipe da Plugar.me e veja o que dá para automatizar antes de aumentar o volume.
Quem faz o quê: Tray, Plugar.me e Protheus
Cada peça dessa arquitetura resolve um problema diferente. A tabela deixa a divisão clara:
| Peça | Função principal | O que ela não faz |
|---|---|---|
| Tray | Apresenta o produto, capta o cliente, processa o checkout e registra o pedido | Não gerencia o seu estoque real nem emite os seus documentos fiscais |
| Plugar.me | Conecta a plataforma ao Protheus, traduzindo dados e respeitando a parametrização do ERP | Não gerencia a loja, o layout ou a experiência de compra do cliente |
| Protheus | Governa produto, estoque, preço, pedido de venda, NF-e e financeiro | Não conhece as regras específicas da plataforma nem administra a vitrine |
O papel da Tray
Ela é a vitrine e o ponto de contato com o cliente. Cuida do catálogo exibido, da experiência de navegação, do carrinho, dos meios de pagamento e do checkout. É onde a venda acontece, mas nada além disso: a plataforma não sabe quanto você realmente tem em estoque na filial, nem qual operação fiscal aplicar ao pedido.
O papel da Plugar.me
É a ponte entre o canal e a gestão. Traduz o modelo de dados da plataforma para o do ERP e vice-versa, respeitando as rotinas oficiais do Protheus, os campos de usuário, as TES e a parametrização do ambiente. Sem essa camada, o pedido até existe na loja, mas para na porta do sistema de gestão.
O papel do Protheus
É a fonte da verdade. O saldo que vale é o dele, o preço oficial parte dele, o pedido vira documento nele e a nota fiscal sai dele. Todo o resto orbita essa base, no princípio ERP First que orienta esse tipo de projeto.
Na prática, a divisão é simples: a Tray cuida da venda, a integração cuida da conversa entre os sistemas, e o Protheus cuida do negócio. Quando uma dessas peças tenta assumir a função da outra, aparece o problema.
Ficou claro que cada peça resolve um problema diferente e que faltar uma delas quebra a corrente? Se você já tem a Tray rodando mas os pedidos ainda são digitados no ERP, é exatamente a ponte que está faltando. Apresente o seu cenário à Plugar.me e veja onde está o elo aberto.
E o que a API da Tray permite de específico? O próximo tópico detalha.
O que a API da Tray permite?
A plataforma expõe uma API própria, e algumas características dela desenham o projeto desde o início:
- Autenticação por OAuth 2.0. A loja autoriza o aplicativo e a integração recebe as credenciais para operar, modelo que exige gestão adequada dos tokens.
- Escopo amplo. A API cobre produtos, variações, categorias, clientes, pedidos, nota fiscal e webhooks, o que permite automatizar o ciclo completo.
- Endpoint de MultiCD. A plataforma trabalha com estoque por centro de distribuição, e não apenas um saldo único por produto.
- Preço no produto e listas B2B. O valor é campo do produto ou da variação, e existem endpoints próprios para listas de preço voltadas a operações B2B.
O MultiCD é a peça que costuma ser ignorada, e é justamente a mais relevante para quem roda Protheus. Um ERP que já controla saldo por filial ou depósito pode espelhar essa estrutura na plataforma em vez de achatá-la num número só. Quem publica saldo único quando a operação tem mais de um centro de distribuição perde a capacidade de dizer de onde a mercadoria sai, e descobre isso na hora de expedir.
Para ver como essas regras se aplicam a outros sistemas de gestão, vale conferir o guia da Tray com o seu ERP.
Sua operação tem mais de um centro de distribuição e ainda publica um saldo único na loja? Esse atalho funciona até o primeiro pedido que precisa sair da filial errada. Pergunte à Plugar.me como fica o mapa de filiais e centros de distribuição na sua operação.
Como o dado percorre as três camadas?
O tráfego acontece nos dois sentidos, e cada direção resolve uma parte da operação:
| Dado | Direção | O que acontece |
|---|---|---|
| Produtos e categorias | Protheus para Tray | Cadastro sai do ERP e alimenta o canal |
| Estoque | Protheus para Tray | Saldo da filial correta atualiza a oferta |
| Preços | Protheus para Tray | Valor sai da política definida no ERP |
| Pedidos | Tray para Protheus | Venda entra como pedido, com a operação correta |
| Clientes | Tray para Protheus | Dados do comprador chegam prontos para faturar |
| Nota fiscal | Protheus para Tray | NF-e emitida no ERP e informada ao canal |
| Rastreio | Protheus para Tray | Código de envio atualiza o pedido na loja |
Na prática, o caminho completo funciona assim:
- O cliente compra na Tray.
- A integração captura o pedido e o cria no Protheus, na operação correta.
- O estoque é baixado no ERP e o saldo do canal é atualizado.
- O pedido segue o fluxo interno de separação e conferência.
- O faturamento é executado no Protheus e a NF-e é emitida.
- Número da nota e rastreio voltam para o canal.
- O painel da Plugar.me registra cada etapa em log, para auditoria.
Repare que a ida garante que a loja mostre a verdade do ERP, e a volta garante que o ERP registre o que aconteceu na loja. Uma integração que faz só metade disso deixa sempre uma ponta descoberta, situação comum quando o ERP se conecta a hubs e canais com fluxos próprios.
Consegue apontar em qual etapa desse caminho a sua operação ainda depende de trabalho manual? Normalmente é no meio, entre a loja e o ERP, justamente onde o erro custa nota atrasada e prazo perdido. Descreva o seu fluxo para o time da Plugar.me.
Por que a parametrização do Protheus muda o projeto?
Porque não existe Protheus padrão. Cada empresa configurou o ERP ao longo de anos, e uma integração que ignora isso quebra a operação em vez de ajudá-la.
Quatro pontos exigem atenção específica:
- TES e natureza de operação. O Protheus define por essas estruturas como cada pedido é processado e faturado. Uma integração que as ignora gera pedido com operação errada e nota fiscal furada.
- Parametrização própria. O mapeamento precisa partir da configuração real da sua empresa, não de um modelo genérico.
- Gravação pelas rotinas oficiais. Inserir registro direto no banco de dados contorna as validações do ERP e cria inconsistência que só aparece no fechamento, além de comprometer o suporte da TOTVS.
- Múltiplas filiais. A estrutura de filiais define de onde sai o saldo e quem fatura, e isso precisa estar espelhado na plataforma.
A camada de integração carrega justamente esse conhecimento. Ela sabe quais campos de usuário a sua empresa criou, qual TES aplicar a cada tipo de venda e como a estrutura de filiais se relaciona com os centros de distribuição da loja. É o mesmo cuidado aplicado quando outros ERPs se conectam à mesma plataforma, como na conexão da Tray com o SAP Business One.
Sua TI já avaliou conectores prontos e percebeu que nenhum deles conhece a parametrização do seu Protheus? Essa percepção é correta e é o ponto de partida de um projeto bem feito. Traga esse cenário para a Plugar.me e receba uma avaliação do seu ambiente.
Como funcionam o faturamento e a emissão da NF-e?
A nota nasce no Protheus. É a regra que separa uma integração ERP First de um conector qualquer.
O pedido segue a cadeia de documentos da empresa e a NF-e é emitida com a TES adequada à operação de venda para consumidor final, diferente da usada em venda para revenda. O canal recebe a informação do documento emitido e não substitui essa etapa, o que mantém o seu fiscal centralizado em um lugar só.
Esse ponto merece destaque porque é onde o improviso custa mais caro. Um pedido lançado às pressas, com operação fiscal errada, gera nota que precisa ser cancelada e refeita, com retrabalho na contabilidade e, dependendo do volume, um problema que se multiplica rápido.
O ciclo fecha com o retorno: número da nota e código de rastreio voltam para a loja, atualizando o comprador sem que ninguém precise lançar essa informação manualmente. O tráfego desses dados envolve informações pessoais, o que exige transmissão protegida e acesso restrito por função, tema tratado nas práticas de segurança aplicadas às integrações.
Você ainda emite as notas do canal digital fora do fluxo normal do Protheus? Isso multiplica trabalho e abre espaço para operação fiscal errada. Fale com a Plugar.me e traga a emissão para dentro da cadeia de documentos que a sua empresa já domina.
Preciso desenvolver essa integração do zero?
Não existe conector nativo entre o TOTVS Protheus e a Tray. Os dois lados têm interface, mas ninguém fez a ponte por você.
| Caminho | Investimento inicial | Tempo até operar | Manutenção |
|---|---|---|---|
| Desenvolver internamente | Alto | Longo | Sua equipe, inclusive quando a API mudar |
| Consultoria sob medida | Alto | Médio | Depende de contrato, cada ajuste vira novo escopo |
| Hub com modelo ERP First | Baixo | Curto | Do fornecedor, com o ERP seguindo como fonte da verdade |
O que costuma ser subestimado no desenvolvimento interno não é construir, é manter. O canal muda regra de API, muda exigência de cadastro e muda comportamento. Quem construiu internamente assume essa fila para sempre.
E a ponte não é só transporte de dados: envolve mapear a estrutura do ERP, respeitar os limites do canal e tratar o que falha. Vale lembrar que a mesma fundação atende outros sistemas de gestão, como mostra a lista de ERPs integrados pela Plugar.me.
Sua TI já estimou quanto tempo levaria para construir e manter essa integração internamente? Some a isso as mudanças de API que virão nos próximos anos. Traga esse comparativo para a Plugar.me e avalie o caminho com números na mesa.
Como a Plugar.me realiza a integração Protheus com Tray?
A operação roda em nuvem, sem necessidade de subir servidor nem manter estrutura adicional na sua infraestrutura.
O projeto segue três etapas:
- Diagnóstico: entender como o seu Protheus está configurado, com filiais, armazéns, TES, campos de usuário e parametrização fiscal, além do que a operação exige do canal.
- Mapeamento e setup: definir de onde sai cada dado, qual operação o pedido da Tray deve usar, qual saldo o canal enxerga e qual centro de distribuição corresponde a qual filial.
- Go-live assistido: acompanhamento nos primeiros ciclos, quando os casos de exceção aparecem, com painel de logs para auditar cada etapa.
Empresas que integraram seus sistemas com a Plugar.me contam essa experiência na página de clientes e parceiros, incluindo operações que rodam canal digital em alto volume com o ERP no comando.
Cada mês com a Tray operando fora do ERP é margem evaporando em erro, atraso e conciliação manual, e esse custo cresce junto com o canal. Fale com o time da Plugar.me, apresente o seu cenário e descubra em quanto tempo a sua operação pode estar rodando integrada.
Conclusão
A integração Protheus com Tray funciona quando cada peça faz o seu papel: a plataforma capta o cliente e registra o pedido, a camada de integração traduz os dados respeitando a parametrização do ERP, e o Protheus governa estoque, preço, faturamento e cada NF-e emitida no fluxo e transmitida ao ambiente oficial da NF-e.
O erro mais comum é imaginar que uma dessas peças substitui a outra. Plataforma sem integração com o ERP deixa o pedido parado antes do faturamento. ERP sem integração obriga alguém a digitar tudo manualmente. As duas coisas conectadas, com a tradução correta entre elas, é o que sustenta um e-commerce profissionalizado.
A integração bem feita não muda a forma como a sua empresa opera. Faz o contrário: garante que o canal se encaixe na operação que já existe no Protheus, em vez de obrigar a operação a se contorcer para caber no canal.
Fale agora com a Plugar.me, apresente o cenário do seu Protheus e receba uma análise técnica de quem homologa essas integrações todos os dias. O primeiro passo não custa nada.
Não. Os dois lados oferecem interfaces oficiais, mas a ponte entre elas precisa ser construída e mantida, respeitando a parametrização, as TES e os campos de usuário configurados no seu ambiente.
A Tray é canal: apresenta o produto, capta o cliente e registra o pedido. O Protheus é a fonte oficial: controla estoque, preço, faturamento e fiscal. A camada de integração traduz a conversa entre os dois.
No ERP. A NF-e nasce no Protheus, com a TES adequada à venda para consumidor final, e a plataforma apenas recebe a informação do documento emitido, mantendo o fiscal centralizado.
A Tray expõe estoque por centro de distribuição, e não apenas um saldo único por produto. Isso permite espelhar a estrutura de filiais do Protheus, desde que o mapa entre filial e centro de distribuição seja definido no projeto.
Sim, e esse é um ponto central. A gravação acontece pelas rotinas oficiais do ERP, respeitando TES, campos de usuário e regras de negócio, em vez de inserir registros direto no banco de dados.
Sim. O escopo cobre produtos, variações, categorias, clientes, pedidos, nota fiscal e webhooks, com autenticação por OAuth 2.0, o que viabiliza o fluxo do cadastro à emissão do documento fiscal.
Sim. Como a fonte da verdade permanece no Protheus, a mesma fundação atende outros canais, incluindo marketplaces e hubs, sem duplicar cadastro nem mudar o dono do dado.
Luan Carvalho é fundador e CTO da Plugar.me, empresa especializada em integração de ERP com marketplaces e plataformas de e-commerce. Atua no desenvolvimento de soluções para automação de pedidos, estoque, preços, faturamento e documentos fiscais, ajudando empresas a escalarem suas operações com estabilidade, segurança e alto desempenho. Ao longo de sua trajetória, participa da implementação de integrações entre ERPs como SAP Business One, Protheus, WinThor, Consinco e Sankhya, conectando-os aos principais marketplaces e plataformas do mercado.
