Conectar a Rithum (Dsco): pedidos entrantes, mensagens ASN e de fatura saintes
Obtenha o Client ID e o Client Secret da sua conta de fornecedor da Rithum, deixe a URL base da API vazia para produção ou preencha o endereço sandbox para testar primeiro, teste, configure o mapeamento por parceiro comercial e ative.
O conector da Rithum troca documentos EDI com varejistas pela rede da Rithum (Dsco API v3): os documentos de pedido dos seus parceiros comerciais entram e viram pedidos, e os documentos ASN e de fatura voltam para esses parceiros, com o estoque trocado pela mesma conexão. Não é um login de loja: tudo é organizado por parceiro comercial e por documento.
Pré-requisitos#
- Uma conta de fornecedor da Rithum (Dsco). As credenciais de API desta conexão pertencem a essa conta de fornecedor: não são um login de loja.
- Seu contato de integração da Rithum ao alcance: o Client ID e o Client Secret são emitidos em par para a sua conta de fornecedor e, se você ainda não os tiver, o contato de integração é quem os fornece.
- Pelo menos um parceiro comercial (varejista) com quem você troque documentos na Rithum: pedidos entrantes, ASN e faturas saintes. Cada parceiro é mapeado separadamente mais adiante neste guia.
- Uma escolha de ambiente para a primeira conexão: deixe a URL base da API vazia para usar produção, ou preencha o endereço sandbox para testar a conexão primeiro. Os endereços exatos estão na etapa de preencher no Integration, abaixo.
Obter credenciais#
- Procure na sua conta de fornecedor da Rithum, nas configurações de API / desenvolvedor, as credenciais de API: o Client ID e o Client Secret. Eles pertencem à conta de fornecedor e são emitidos em par: você precisa dos dois.
- Se não houver credenciais de API ali, peça-as ao seu contato de integração da Rithum. Diga que precisa do Client ID e do Client Secret de API da sua conta de fornecedor.
- Copie os dois valores por completo e guarde-os em local seguro. O par só funciona junto: um Client ID de um par emitido não funciona com um Client Secret de outro.
- Se o Client Secret for perdido, peça à Rithum que emita um novo: um segredo perdido não pode ser recuperado da conexão, porque ele nunca volta a ser exibido depois de salvo.
Preencher no Integration#
- Abra Integration → Marketplace → Rithum → Nova conexão.
- URL base da API (opcional): deixe este campo vazio para usar produção; a conexão irá então para https://api.dsco.io/api/v3. Para testar primeiro a conexão no sandbox, preencha em vez disso https://staging-api.dsco.io/api/v3. Preencha exatamente um desses dois endereços, ou deixe o campo vazio: não digite um endereço de outro sistema.
- Client ID: cole o Client ID emitido para a sua conta de fornecedor da Rithum. Cuidado para não trocá-lo com o Client Secret: o ID vai neste campo e o segredo no próximo.
- Client Secret: cole o Client Secret do mesmo par emitido que o Client ID. Ele é criptografado em repouso e nunca exibido.
Testar a conexão#
Clique em Testar a conexão. O teste roda em duas etapas, e as duas precisam passar para a conexão contar como funcionando. Primeiro ele troca seu Client ID e seu Client Secret por um token de acesso com a Rithum. Depois usa esse token para chamar a verificação /hello no endereço de API que você escolheu: o endereço de produção quando a URL base está vazia, ou o endereço sandbox que você preencheu. Se passar, as duas etapas funcionaram: suas credenciais foram aceitas e a API da Rithum respondeu. Se falhar, guarde o erro que o teste mostra: ele indica se quebrou a etapa do token ou a etapa do /hello, e as perguntas frequentes abaixo tratam de cada caso.
Mapping / escolher modelo#
Na Rithum o mapeamento é por parceiro comercial, não uma configuração única para toda a conexão. Para cada parceiro varejista, escolha o modelo desse parceiro e verifique como os documentos de pedido dele mapeiam para o pedido padrão — número do pedido, linhas, quantidades e dados de entrega — e como os dados de ASN e fatura mapeiam de volta para o formato de documento que esse parceiro espera. Um parceiro sem mapeamento configurado não tem onde pousar seus documentos: os pedidos dele não entram, e os documentos ASN e de fatura não podem ser montados para ele. Um teste de conexão aprovado só prova que as credenciais e o endereço da API funcionam: não significa que algum parceiro já esteja mapeado. Trabalhe parceiro por parceiro e confira a prévia de mapeamento de cada um antes de ativar.
Ativar#
Após ativar, os documentos de pedido dos seus parceiros comerciais mapeados entram e viram pedidos, o estoque é trocado pela conexão, e os documentos ASN e de fatura são enviados de volta a cada parceiro pela Rithum. Parceiros sem mapeamento ficam em silêncio: nada flui para eles até o mapeamento ser configurado. Se você testou no endereço sandbox, volte a deixar a URL base da API vazia (produção) e teste de novo antes de ativar para o comércio real. Acompanhe os primeiros documentos de cada parceiro em Runs / Logs antes de deixar a troca sem supervisão.
Perguntas frequentes#
O teste falha na etapa do token
A Rithum não aceitou as credenciais, então nenhum token foi emitido e o teste nunca chegou à verificação /hello. As causas habituais são um valor copiado incompleto, o Client ID e o Client Secret colados nos campos um do outro, ou os dois valores virem de pares emitidos diferentes: o ID e o segredo só funcionam como o par em que foram emitidos.
Copie de novo os dois valores das configurações de API / desenvolvedor da sua conta de fornecedor, garantindo que o Client ID vá no campo Client ID e o Client Secret no campo Client Secret, ambos do mesmo par emitido. Se você não tiver mais o segredo, ou não tiver certeza de a qual par seus valores pertencem, peça ao seu contato de integração da Rithum um par recém-emitido, preencha os dois valores, salve e teste de novo.
O token é emitido, mas a verificação /hello falha
Suas credenciais foram aceitas — a etapa do token passou — mas o endereço de API para o qual a conexão aponta não respondeu à verificação /hello, então a conexão ainda não conta como conectada. A causa habitual é a URL base da API: foi digitada diferente dos dois endereços que esta conexão usa, foi editada à mão, ou ficou apontando para o sandbox quando você queria testar produção (ou o contrário).
Ajuste a URL base da API para exatamente um dos dois endereços: deixe-a vazia para produção (https://api.dsco.io/api/v3), ou preencha o endereço sandbox https://staging-api.dsco.io/api/v3 se estiver testando no sandbox. Salve e teste de novo. Se a verificação /hello continuar falhando com o endereço exato, guarde o erro que o teste mostra e verifique Runs / Logs antes de tentar de novo.
Conectado, mas os pedidos de um parceiro nunca entram
A conexão em si funciona: o teste passa e outros parceiros podem estar fluindo. O problema é que este parceiro comercial não tem mapeamento configurado, ou você ainda está conectado ao endereço sandbox enquanto o parceiro envia em produção, então os documentos de pedido dele não têm onde pousar nesta conexão.
Primeiro verifique a URL base da API: para o comércio real ela deve estar vazia (produção). Depois abra o mapeamento desse parceiro comercial, escolha o modelo dele e confira a prévia de mapeamento com um dos documentos de pedido reais dele: número do pedido, linhas, quantidades e dados de entrega devem pousar no pedido padrão. Salve o mapeamento e depois veja Runs / Logs para o próximo documento desse parceiro.
Os pedidos entram, mas os documentos ASN e de fatura não chegam ao parceiro
A entrada funciona, então as credenciais e o endereço da API estão certos. A lacuna está no lado de saída do mapeamento desse parceiro: o parceiro está mapeado para os documentos de pedido entrantes, mas os documentos ASN e de fatura saintes dele nunca foram configurados, então os resultados do fulfillment não têm documento para voltar.
Abra o mapeamento desse parceiro comercial e configure também o lado de saída: documentos ASN e documentos de fatura, no formato que esse parceiro espera. Confira a prévia de mapeamento com um pedido já atendido e depois acompanhe Runs / Logs para o próximo documento de saída para esse parceiro.