Comunidade

Contexto

Estamos realizando uma integração via API com a Rodonaves em um e-commerce.
Ao confirmar um pedido com frete Rodonaves, nosso sistema executa duas chamadas em sequência:

1. POST /api/v1/customer/savecustomer — cadastra/atualiza o destinatário com os dados do pedido
2. POST /api/v1/gera-cotacao — gera a cotação oficial com protocolo

O problema

Na tela da cotação gerada no sistema de vocês, os campos Recebedor e Destinatário estão exibindo endereços diferentes. Por causa dessa divergência, a operação não está aceitando a cotação.

O que já analisamos

Mapeamento que identificamos

Pela análise da documentação e dos logs, entendemos que os campos funcionam assim:

Com base nisso, o Destinatário está correto — ele vem do DestinationAddress que enviamos no payload. O problema está no Recebedor, que lê o perfil cadastrado para o ReceiverCpfcnp na base de vocês.

O que o saveCustomer está retornando

Chamamos o savecustomer antes de cada gera-cotacao para garantir que o CPF esteja cadastrado e com o endereço de entrega correto. Porém, analisando o retorno da API, identificamos o seguinte no endereço criado/atualizado:

"Type": "FISCO",
"TypeDescription": "Fiscal/Principal",
"IsDelivery": false,
"Origin": "LOG"

O endereço criado pelo savecustomer é do tipo Fiscal e não é marcado como
endereço de entrega (IsDelivery: false).

Nossa hipótese

O savecustomer cria/atualiza um endereço do tipo FISCO, mas o gera-cotacao
pode estar usando uma fonte de dados diferente para preencher o Recebedor —
possivelmente o endereço principal/original do cliente cadastrado na base de vocês,
que é diferente do endereço FISCO que criamos.

Isso explicaria por que mesmo chamando o savecustomer com o endereço correto antes
do gera-cotacao, o Recebedor continua exibindo um endereço diferente do
Destinatário.

Detalhe importante: os CPFs usados nos testes já possuíam cadastro anterior na
base de vocês, com endereço diferente do endereço de entrega do pedido.

---
Exemplo real

Payload enviado ao savecustomer:

{
  "Description": "Nome do Cliente",
  "TaxIdRegistration": "***********",
  "Email": "[email protected]",
  "Phone": "***********",
  "ZipCode": "********",
  "Street": "Rua Exemplo",
  "Number": "100",
  "Supplement": "",
  "District": "Centro",
  "City": "Cidade Exemplo",
  "UnitFederation": "UF"
}

Trecho do payload enviado ao gera-cotacao:

{
  "ReceiverCpfcnp": "***********",
  "ContactName": "Nome do Cliente",
  "ContactPhoneNumber": "***********",
  "DestinationAddress": {
    "Address": "Rua Exemplo",
    "Number": "100",
    "Supplement": "",
    "District": "Centro",
    "City": "Cidade Exemplo",
    "UnitFederation": "UF",
    "ZipCode": "********"
  }
}

Ambos os payloads carregam o mesmo endereço. Mesmo assim, os campos Recebedor
e Destinatário exibem endereços diferentes na tela da cotação.

Dúvidas

1. O endereço exibido no campo Recebedor da cotação vem do perfil cadastrado via savecustomer, ou de outra fonte de dados?

2. O endereço do tipo FISCO criado pelo savecustomer (IsDelivery: false) é o mesmo que o gera-cotacao utiliza para preencher o Recebedor? Ou o gera-cotacao lê um endereço de tipo diferente (por exemplo, IsDelivery: true)?

3. Para CPFs que já possuíam cadastro anterior na base de vocês (com endereço diferente), o savecustomer atualiza o endereço existente ou cria um endereço adicional sem sobrescrever o original? Se criar um adicional, como forçar a atualização do endereço principal que o gera-cotacao utiliza?

4. Existe algum parâmetro no savecustomer para definir o tipo do endereço (por exemplo, para criar um endereço de entrega com IsDelivery: true em vez de FISCO)? Isso resolveria o problema?

5. Qual é o fluxo correto, via API, para garantir que Recebedor e Destinatário exibam o mesmo endereço de entrega na tela da cotação?

Objetivo

Garantir que, ao gerar uma cotação via API, os campos Recebedor e Destinatário exibam sempre o mesmo endereço de entrega — sem divergência — para que a cotação seja aceita pela operação.

Qualquer orientação sobre como estruturar as chamadas ou quais parâmetros utilizar será muito bem-vinda.

Fico no aguardo, grato desde já.