Erros criação da proposta
Abaixo listamos os possíveis erros retornados ao enviar uma proposta de solicitação de empréstimo.
Recomendação importantePara que a integração tenha qualidade e seja possível obter resultados positivos com sua operação, é muito importante ter atenção as dicas descritas ao decorrer deste documento.
Confira abaixo os principais códigos de retorno para mapear na integração:
| Code status | Code | Message | Descrição |
|---|---|---|---|
400 | REQUEST_VALIDATION_ERROR | Some fields are invalid | Indica que existem erros em um ou mais campos da sua solicitação. Confira o detalhamento dos principais motivos de erros 400 |
Lead já existente (DUPLICITY)
DUPLICITY)A criação da proposta não retorna erro de lead duplicado. O lead é validado durante o processamento e, quando já existe um lead ativo para o mesmo cliente, a proposta é recusada com rejectionReason: DUPLICITY no step PROPOSAL_CREATED. Esse motivo aparece na consulta de status da proposta.
Casos em que isso ocorre:
- Existência de outro lead ativo na esteira (usando o mesmo CPF ou e-mail).
- Inconsistência de dados cadastrais (e-mail ou CPF) de tentativas anteriores e da atual.
Para minimizar esse caso, verifique a elegibilidade antes de criar a proposta: Auto ou Home.
Principais erros na Criação da Proposta
Ao enviar uma solicitação de empréstimo precisamos que os campos sejam preenchidos corretamente e com valores válidos, caso contrário a solicitação não será concluída com sucesso.
Para garantir que isso não ocorra a dica é garantir que os campos na sua experiência tenham as devidas validações durante o preenchimento do cliente, reduzindo assim um possível erro 400.
Principais erros identificados:
- Campos sem a devida validação
- Falta de monitoramento na integração, importante observar os retornos e o detalhe dos erros
Confira alguns exemplos e dicas para garantir a validação de erros 400
| Descrição do erro | Mensagem de erro API / Envio incorreto | Formato correto / Como corrigir |
|---|---|---|
|
01-08-89 | O campo data deve seguir o formato YYYY-MM-DD |
|
modelYear:"2010"manufacturingYear:"2020" | O campo ANO DE FABRICAÇÃO (manufacturingYear) deve ser igual ao ANO MODELO (modelYear) ou, no máximo, 1 ano posterior. Os campos devem estar de acordo com as informações do veículo |
|
licensePlate: "1234HAJ" | Recomendamos que seja feita uma validação para garantir o correto preenchimento seguindo padrões de placas brasileiras. Exemplo de validação utilizando expressão regular para validar os formatos. |
|
licensePlate: "" | O campo placa deve conter entre 7 ou 8 dígitos, não deve ser enviado vazio. |
|
Informações não sendo enviadas no header | As informações de header e temos devem seguir as recomendações de autorização bacen |
|
Informações enviadas incorretamente, exemplos:
| Formato correto da data deve ser ISO 2021-01-22T09:00 |
| CEP com formato inválido ou vazio |
postalCode: "5947000"postalCode: "" | O campo CEP deve conter 8 números. |
| Nome com valor inválido |
fullName: "Nome de Teste 32" | O campo nome deve conter apenas letras. |
| E-mail inválido |
email: "email@email" | O campo email deve conter o domínio completo e seu um e-mail válido. |
| Telefone inválido |
| O campo telefone deve seguir o formato 988888888, contendo 9 dígitos no total |
| DDD inválido |
| cellphoneCode: "011"O campo cellphoneCode deve conter apenas 2 dígitos (ex.: 11). |
| Valor fora das opções aceitas (ex.: estado civil, tipo de imóvel) |
| maritalStatus: "CASADO"Envie um dos valores listados na própria mensagem de erro e na documentação do campo (ex.: MARRIED). |
| Proprietários do imóvel com valor inválido (Home) |
| owners: ["FAMILIA"]O campo owners deve conter ao menos um item entre BORROWER, SPOUSE e OTHER. |
| Dados profissionais do cônjuge ausentes quando ele é co-signatário (Home) |
| spouse.isCosigner: true sem spouse.professionalInfoInforme os dados profissionais ( professionalInfo) do cônjuge quando isCosigner for true. |
Temos um processo de monitoramento para garantir a qualidade das integrações e os resultados do negócio e um processo importante dele é o processo de homologação da sua integração. No processo conferimos o formato de envio de cada campo porém, ao subir sua integração para um ambiente de produção, se não garantir as validações na sua experiência do cliente, o volume e tipos diferentes de usuários pode preencher indevidamente os campos e com isso é possível que nosso time técnico identifique erros e seja obrigatória a correção para manter o funcionamento.
Sucesso na integraçãoTodos os erros mencionados podem ser tratados antecipadamente ao envio, o ponto importante é implementar validação em cada campo, utilizar o recurso de máscara e mensagens de instruções para que dessa forma o cliente possa ter maior assertividade no preenchimento dos campos e com uma conclusão mais positiva.
Updated 5 days ago
