Tray com ERP: como planejar SKUs, estoque e pedidos sem duplicidade

Integrar a Tray a um ERP sem duplicar produtos, vender sem estoque ou perder pedidos depende menos do conector escolhido e mais de três decisões tomadas antes dele: qual sistema manda em cada dado, como cada variação será identificada e o que acontece com o pedido em cada mudança de estado, inclusive cancelamento e devolução. Este guia trata só da integridade dos dados entre a Tray e o ERP. Se a sua dúvida é como distribuir o catálogo entre loja própria e marketplaces, comece pelo guia da loja Tray conectada a marketplaces.

A página de integrações da Tray lista dezenas de ERPs com conexão disponível (consultado em 20/10/2026). O primeiro passo é confirmar ali, ou com o fornecedor do seu ERP, se existe conector para a Tray, quem o mantém e qual versão será usada. Tudo o que vem abaixo depende dessa resposta. Se a disponibilidade de conectores ainda pesa na escolha entre plataformas, vale comparar Tray e Nuvemshop por esse critério.

Qual sistema manda em cada dado?

Em uma integração, cada dado tem um dono. Quando a Tray e o ERP discordam, o valor do sistema mestre vence e o outro é sobrescrito na próxima sincronização. Se essa regra não estiver escrita, a equipe vai corrigir o estoque no painel da loja e ver a correção desaparecer minutos depois. Os critérios gerais para definir essa divisão, válidos para qualquer plataforma, estão nos requisitos da integração com ERP; abaixo, a aplicação na Tray.

Como padronizar o SKU de produto e de variação?

A documentação da API da Tray mostra que tanto o produto quanto cada variação têm campo próprio de referência e de código EAN, e que a variação carrega seus atributos (por exemplo, “Cor: Azul” e “Tamanho: 38”) além de preço e estoque próprios. Na prática, isso significa que cada combinação vendável precisa de um código único, igual no ERP e na Tray.

Regras que evitam a maior parte dos problemas:

1. Um código por item vendável. O produto “pai” tem uma referência; cada variação tem a sua, diferente da do pai e das irmãs.
2. Código nunca reaproveitado. Produto descontinuado leva o código junto. Reaproveitar faz o histórico de pedidos apontar para o item errado.
3. Sem espaços, acentos ou caracteres especiais, e sempre na mesma caixa (maiúsculas ou minúsculas).
4. Estrutura legível, para que a equipe reconheça o item sem consultar o sistema.
5. O ERP gera, a Tray recebe. Se o cadastro nasce na Tray, defina quem cria o código e em que momento ele vai para o ERP.

Exemplo ilustrativo de padrão: CAM-BAS-AZ-M para camiseta básica, azul, tamanho M, com o produto pai como CAM-BAS. O padrão em si importa menos do que ser aplicado sem exceção.

Kits merecem uma decisão à parte: o kit tem código próprio e baixa o estoque dos componentes, ou é um item com estoque independente? A resposta depende do que o ERP e o conector suportam, e precisa ser testada.

Como planejar sincronização, estados de pedido, cancelamentos e devoluções?

A documentação da Tray lista os status de pedido padrão da plataforma: aguardando pagamento, a enviar, enviado, finalizado e cancelado, além de variantes ligadas ao meio de pagamento (a documentação informa que, desde 06/06/2022, os status “Aguardando Vindi” e “A enviar Vindi” são usados por padrão nos novos pedidos). Na tabela de planos, consultada em 20/10/2026, status personalizados aparecem a partir do plano Crescimento, e o workflow de status, no Avançado.

O conector precisa traduzir cada status da Tray para um evento no ERP. O mapa abaixo é um modelo para preencher; a coluna do ERP depende do sistema e do conector.

Três decisões precisam constar no escopo da integração:

• Quando o pedido vai para o ERP: na criação ou só após o pagamento. Enviar na criação ajuda a reservar estoque, mas gera pedidos que nunca serão pagos.
• Quem cancela: se o cancelamento nasce na Tray, no ERP ou nos dois, e como um avisa o outro.
• Devolução não é cancelamento: o item só volta ao estoque depois de recebido e conferido, e isso costuma ser um lançamento manual no ERP.

Frequência e limites

A documentação da Tray descreve um sistema de webhook que avisa o aplicativo integrador quando produtos, preços, estoques, variações, pedidos e clientes são criados, alterados ou excluídos. Ela registra três cuidados: as notificações valem só para ações ocorridas depois da adesão ao webhook; quando a URL do integrador falha, a Tray reenvia com intervalos crescentes; e a recomendação é armazenar as notificações e agrupar as idênticas antes de agir. A mesma documentação informa limite de 180 requisições por minuto, e a tabela de planos lista uma cota diária de API externa por plano (1.000, 5.000 e 30.000 requisições por dia, de Lançamento a Avançado, consultado em 20/10/2026). Pergunte ao fornecedor do conector se ele usa webhook ou consulta periódica, de quanto em quanto tempo sincroniza e como trata esses limites em catálogos grandes.

Como homologar com amostra e corrigir falhas?

Ligar a integração para o catálogo inteiro de uma vez transforma qualquer erro de mapeamento em centenas de produtos para corrigir. A homologação usa uma amostra pequena e representativa.

Amostra mínima sugerida: um produto simples, um produto com variações de dois atributos, um kit (se houver), um item com estoque zero, um item em promoção e um item com peso e dimensões fora do padrão.

Fluxograma do pedido de teste

1. ERP cadastra o produto com variações e envia à Tray. Conferir: referência, EAN, preço e estoque de cada variação.
2. Na Tray, completar descrição, fotos e categoria. Conferir: a próxima sincronização não apaga esse conteúdo.
3. Ajustar estoque no ERP. Conferir: o novo saldo chega à Tray, e em quanto tempo.
4. Fazer um pedido na loja e aprovar o pagamento. Conferir: o pedido chega ao ERP com cliente, itens pela referência certa, frete e desconto.
5. Faturar no ERP. Conferir: nota e rastreio voltam ao pedido na Tray e o status muda.
6. Fazer um segundo pedido e cancelar antes do faturamento. Conferir: cancelamento no ERP e estorno do estoque.
7. Simular uma devolução do primeiro pedido. Conferir: o estoque só volta após a entrada no ERP.

Tabela de campos da homologação

Preencha uma linha por campo. O cabeçalho registra a versão testada, porque uma atualização do conector pode mudar o comportamento.

Conector: __________ · Versão: __________ · ERP e versão: __________ · Plano Tray: __________ · Data do teste: __________

Como identificar e corrigir falhas de sincronização

Depois do lançamento, mantenha um registro simples de falhas: data, item, sintoma, causa e correção. Os sintomas mais comuns e onde olhar primeiro:

Condições e limites

Status de pedido, campos e limites de API foram consultados na documentação de desenvolvedores e na página de planos da Tray em 20/10/2026. Os dois materiais citam limites diários diferentes para a API, por isso confirme com o fornecedor do conector qual se aplica ao seu plano. A base de conhecimento da Tray não pôde ser consultada nesta revisão; o passo a passo de cada conector deve ser conferido no tutorial oficial dele e verificado no plano contratado. A configuração fiscal (regras de tributação e emissão de nota) é responsabilidade do ERP e do contador.

Próximo passo

Se a integração com o ERP vai também alimentar marketplaces, o mapa de canais e o teste do SKU em cada canal estão no guia da loja Tray conectada a marketplaces. Para entregar a loja com o sistema mestre definido, a padronização de SKUs aplicada e a homologação documentada, conheça a nossa criação de loja na Tray.