Manual do usuário
Central de ajuda/Manual do usuário/Conectar a SPS Commerce: pedidos EDI de entrada, ASN e faturas de saída

Conectar a SPS Commerce: pedidos EDI de entrada, ASN e faturas de saída

Última atualização 2026-11-01

Copie a URL base da API dos seus documentos de abertura da SPS, pegue o Client ID e o Client Secret emitidos juntos na abertura da sua conta SPS, cole os três no Integration, teste, mapeie cada parceiro comercial e ative: entram pedidos 850 e saem documentos 856 / 810.

O conector da SPS Commerce troca documentos EDI com seus parceiros comerciais do varejo por meio da SPS Commerce (RSX / API): documentos de entrada, como ordens de compra 850, chegam dos parceiros e viram pedidos, e documentos de saída, como avisos de embarque 856 e faturas 810, voltam para os mesmos parceiros. Não é uma conexão de loja e não há autorização de loja: tudo é organizado por parceiro comercial e por tipo de documento, então cada parceiro é configurado e verificado separadamente.

Passos da SPS Commerce: URL base e credenciais, teste, mapping de parceiros comerciais, ativar.

Pré-requisitos#

  • Uma conta da SPS Commerce aberta com acesso à API. Suas credenciais e sua URL base da API vêm dessa abertura: elas não são criadas dentro do Integration.
  • Seus documentos de abertura da SPS. Eles indicam a URL base da API da sua conta e trazem o Client ID e o Client Secret emitidos para o seu acesso à API: deixe-os à mão para as duas próximas etapas.
  • Pelo menos um parceiro comercial para trocar documentos por meio da SPS Commerce, e uma lista clara de quais tipos de documento você trocará com esse parceiro: por exemplo, ordens de compra 850 de entrada e 856 e 810 de saída. Esta conexão não cria o parceiro para você.
  • Na primeira conexão, prove primeiro a configuração com um parceiro e um tipo de documento; nunca teste um mapping novo com documentos reais de um parceiro.

Obter credenciais#

  1. Encontre a URL base da API nos seus documentos de abertura da SPS e copie-a exatamente como está escrita. Todos os endpoints que a conexão usa, incluindo o endpoint do token OAuth, são relativos a esse endereço base, então um endereço copiado com uma parte faltando ou sobrando não funcionará.
  2. Encontre o Client ID e o Client Secret nos mesmos materiais de abertura. Eles foram emitidos juntos, como um par, quando sua conta SPS foi aberta com acesso à API: guarde o par junto e não o misture com credenciais de outra conta.
  3. Não há uma página de autoatendimento onde você gere essas credenciais por conta própria. Se o Client Secret foi perdido ou nunca foi entregue, contate a pessoa da SPS que cuidou da abertura da sua conta e peça a reemissão; não tente criar um substituto em outro lugar.
  4. Guarde os três valores juntos para a próxima etapa: a URL base da API, o Client ID e o Client Secret. O teste de uma etapa posterior precisa dos três, e deixar qualquer um de fora é reportado como valor faltante.

Preencher no Integration#

  1. Abra Integration → Marketplace → SPS Commerce → Nova conexão.
  2. URL base da API (base_url) — obrigatório: cole o endereço base da API exatamente como aparece nos seus documentos de abertura da SPS. Não deixe este campo vazio nem o substitua por um endereço web geral da SPS: a conexão fala com esse endereço base e, sem ele, o teste para antes mesmo de tentar suas credenciais.
  3. Client ID (client_id) — obrigatório: cole o Client ID emitido para a sua conta na abertura da conta SPS. Cuidado para não colar o Client Secret neste campo: os dois valores formam um par e cada um pertence ao seu próprio campo.
  4. Client Secret (client_secret) — obrigatório: cole o Client Secret emitido junto com o Client ID. Ele é armazenado criptografado e nunca é exibido de volta após salvar, então cole-o com cuidado e guarde sua própria cópia nos materiais de abertura.

Testar a conexão#

Clique em Testar a conexão. O teste primeiro verifica se a URL base da API, o Client ID e o Client Secret estão todos presentes e depois os usa para trocar um token OAuth com a SPS: ele pede um token à SPS e confirma que um token volta. O teste não importa nenhum documento EDI. Passar, portanto, prova apenas que o endereço base e o par de credenciais são utilizáveis; não significa que seus parceiros comerciais ou seu mapping de documentos já estejam configurados: isso é a próxima etapa.

Mapping / escolher modelo#

Na SPS Commerce, o mapping é feito por parceiro comercial e por tipo de documento: não há um único mapping que cubra todos os parceiros, porque cada parceiro do varejo pode exigir campos e regras diferentes sobre o mesmo tipo de documento. Para cada parceiro, escolha o modelo dos tipos de documento que você troca com ele e confira o mapping lado a lado: nas ordens de compra 850 de entrada, o número do pedido, as linhas, as quantidades e os dados de entrega chegam ao pedido padrão; nos documentos de saída, como avisos de embarque 856 e faturas 810, os dados de envio e de fatura são mapeados de volta ao formato esperado pelo parceiro. Se um parceiro pedir um campo que seus documentos habituais não carregam, adicione-o no mapping daquele parceiro em vez de mudar o de todos os outros. Passe por cada parceiro com quem você planeja operar antes de ativar: um parceiro sem um mapping concluído não trocará documentos, mesmo quando o teste de conexão passar.

Ida e volta de documentos na SPS Commerce: entram pedidos 850 pela SPS e voltam documentos 856 e 810 ao parceiro.

Ativar#

Após ativar, o Integration troca documentos com cada parceiro comercial mapeado por meio da SPS Commerce: documentos de entrada, como ordens de compra 850, são importados e viram pedidos, e documentos de saída, como avisos de embarque 856 e faturas 810, são enviados de volta conforme o fulfillment e o faturamento avançam. Parceiros cujo mapping não está concluído não começam a trocar só porque a conexão está ativa. Acompanhe os primeiros documentos de cada parceiro em Runs / Logs antes de confiar no fluxo sem supervisão.

Perguntas frequentes#

O teste para e diz que falta a URL base da API

O campo base_url ficou vazio. Esse campo é fácil de esquecer, porque a conexão da SPS precisa de três valores, não de dois: sem o endereço base, a conexão não sabe com onde falar, então o teste para antes de verificar suas credenciais.

Copie a URL base da API dos seus documentos de abertura da SPS exatamente como está escrita, cole-a no campo de URL base da API, salve e execute o teste de novo. Se o endereço dos seus documentos parecer incompleto, peça ao seu contato de abertura de conta da SPS que o confirme em vez de adivinhar o restante.

O teste falha na troca de token: a autenticação não passa

A SPS não devolveu um token para os valores que você inseriu. Em termos simples, o endereço base, o Client ID e o Client Secret não combinam entre si: o endereço base pode ter sido copiado errado, o Client ID e o Client Secret podem estar trocados entre os dois campos, o secret pode ter sido reemitido depois que sua cópia foi feita, ou o par pode pertencer a outra conta da SPS.

Copie de novo os três valores dos seus documentos de abertura da SPS, verificando se o Client ID vai no campo Client ID e o Client Secret no campo Client Secret, e teste novamente. Se ainda falhar, contate a pessoa da SPS que cuidou da abertura da sua conta e peça que confirme o endereço base e reemita o secret se necessário: não há uma página de autoatendimento onde você possa redefini-lo sozinho.

O teste passa, mas nenhum pedido 850 chega

Isso geralmente não significa que a conexão está quebrada. O teste só troca um token — ele nunca importa um documento — então passar não diz nada sobre pedidos. Os pedidos continuam faltando quando o mapping do parceiro comercial não está concluído, quando aquele parceiro e seu tipo de documento 850 não fazem parte da sua configuração ativa, ou quando o parceiro simplesmente ainda não enviou pedidos novos.

Conclua o mapping daquele parceiro e do seu tipo de documento 850, confirme que a conexão está ativada e verifique Runs / Logs para aquele parceiro. Se tudo estiver configurado e o parceiro confirmar que um pedido foi enviado, use o horário em que o parceiro o enviou para procurar aquele documento em Runs / Logs.

O parceiro rejeita os documentos de saída 856 / 810

A conexão e o token estão bem: o problema é que o próprio documento não corresponde ao que esse parceiro espera. Cada parceiro do varejo pode exigir seus próprios campos e regras nos documentos 856 e 810, então um mapping que funciona para um parceiro ainda pode deixar faltar um campo que outro parceiro exige, ou carregar um valor num formato que aquele parceiro não aceita.

Compare o documento rejeitado com os requisitos daquele parceiro, adicione ou corrija os campos apenas no mapping daquele parceiro e reenvie um documento para confirmar antes de deixar o restante fluir. Não mude o mapping compartilhado de todos os parceiros para corrigir a rejeição de um só.