Olá pessoal,
O intuito deste tópico é contribuir com os usuários Mk-Auth que utilizam a Gerencianet a conhecerem uma maneira de identificarem o por quê e como resolver quando o Mk-Auth apresenta a mensagem "Alguns títulos Invalidos, consulte log" ou outra mensagem relacionada a títulos processados com erro quando se tenta emitir uma cobrança.
Estas explicações foram baseadas em um sistema Mk-Auth 18.01 que está utilizando a API Gerencianet (ou seja, está usando "Client_Id" e "Client_Secret").
Primeiramente, efetue login em sua conta Gerencianet, acesse a opção "API" no menu, depois vá em "Minhas Aplicações" selecione a sua aplicação. Agora, clique na aba "Produção", desça a barra de rolagem e acesse a sub-aba "Histórico de Requisições". Repare as transações que estão com o status "Falha" (veja nesta imagem).
Vamos acessar agora os detalhes de algumas dessas requisições que estão com falha: clique no ícone de um "olho" presente na última coluna e veja o que é exibido em "Dados de Saída". Vejamos 3 situações encontradas:
1) Limite de emissões mensais excedido (veja esta imagem): relacionado ao limite de emissões excedido para um mesmo cliente. Atualmente, o limite de emissões para um mesmo cliente é 13 (treze) diárias e/ou 30 (trinta) mensais. É importante certificar de informar sempre dados válidos e corretos do cliente final. Também possuímos uma FAQ explicando (vide link).
2) Transação não processada por conter incoerência nos dados cadastrais (veja esta imagem): esta mensagem indica que algum dado fornecido na cobrança está incorreto, no sentido de não pertencer ao cliente informado. Neste caso, foi observado o CPF fornecido não pertence ao cliente informado. Para solucionar, corrija a informação e tente emitir novamente.
3) /customer/phone_number - A string não corresponde ao modelo (veja esta imagem): indica que o telefone do cliente final foi fornecido de maneira incorreta. Neste caso, observa-se a ausência do DDD (sem o "0"), ou seja, se o telefone é 2526-1234, deve ser informado 1125261234 (caso o DDD deste exemplo fosse 11). Para solucionar, corrija a informação e tente emitir novamente. (obs: este telefone 1125261234 é apenas de exemplo, é fictício).
Em suma, o recurso "Histórico de Requisições" da API Gerencianet pode (e deve) ser utilizado caso queira visualizar como a Gerencianet recebeu os dados enviados por seu sistema Mk-Auth. O "Histórico de Requisições" é tão importante e extremamente útil que a Gerencianet disponibiliza uma página dedicada a ele (vide link), explicando como interpretar os retornos da API e, claro, corrigir possíveis erros de validação de dados ou outros similares.
A Gerencianet espera que com este tutorial possa contribuir, de alguma forma, com a melhoria na experiência de uso entre sistema Mk-Auth e API Gerencianet.
Respostas
Bom dia!
Como resolver esse erro na emissão de boleto?
Aqui os boletos que estao sendo gerado automaticamente não estao indo para o gerencianet, nao sei se o problema é porq o mkauth parou de repassar e-mail do cliente preciso resolver o mais rapido pocivel sao quase 1000 boletos mensal
Boa noite pessoal, atualizei o MKauth para versão 18.02 e observei que os boletos que estao sendo gerador automaticamente não estao indo para o gerencianet, eu preciso clicar em imprimir para que eles apareçam no gerencia, gostaria de saber se esse é o comportamento normal dessa versão.
Obrigado!
@Welerson Reis Braz
Considerando que hoje é dia 26/02/2019, veja que você está informando a data de vencimento como sendo 15/02/2019 - não é possível gerar uma cobrança com uma data que já passou.
Basta corrigir, informando uma data válida.
Tambem estou com o mesmo problema.
Estou com um problema parecido
aqui também, não esta emitindo boletos, e não ta dando erro no log, ta dificil trabalhar com gerencianet
titulo1.png
titulo2.png
@Pedro Alves de Almeida Junior
A API sempre seguiu este padrão de validação. Ou seja, todos os clientes que você permitirá pagamento por cartão de crédito, o atributo "birth" deverá ser fornecido no formato YYYY-MM-DD.
Tenho uma infinidade de clientes que seguem esse modelo ddmmyyyy e tenho certeza que muitos provedores também seguem esse padrão. terei que fazer essa mudança com todos?
Consultoria Gerencianet disse: