Jump to content

Guilherme Borges

Pessoal da TecnoSpeed
  • Contagem de Conteúdo

    58
  • Ingressou

  • Última visita

  • Dias Ganhos

    3

Tudo que foi postado por Guilherme Borges

  1. Fala Desenvolvedor, beleza? Meu nome é Guilherme, sou consultor técnico aqui na TecnoSpeed, e hoje venho comentar sobre o erro "The server encountered an unexpected condition which prevented it from fulfilling the request.", você já recebeu este erro? Sabe como ele pode ser solucionado? Caso sua resposta seja não, fique comigo aqui neste post que vou dar mais detalhes sobre este problema. Basicamente, este erro se refere a algum campo do seu JSON/TX2 que esteja sendo enviada fora dos padrões do WS do Sicredi, e para ter uma mensagem mais clara e um validação melhor recomendamos a marcação do campo abaixo, que fica disponível no cadastro da conta: Este campo marcado fará com que nossa API realize uma validação do seu JSON, e apresente uma validação mais clara antes de disparar o boleto ao banco, fazendo com que caso tenha algum erro a validação já seja mais precisa. Assim, recomendamos este campo como true, pois os motivos deste erro podem ser muitos, inconsistências no JSON, passagem de protesto indevida, campos com tipagens indevidas, dentre outras. Se após a marcação do campo, o erro continue genérico, recomendamos entrar em contato com nosso time para realizarmos mais análises. E por hoje é isso Dev, qualquer dúvida estou à disposição! Até mais!
  2. Fala Desenvolvedor, beleza? Meu nome é Guilherme Borges, sou consultor técnico aqui na operação PlugBank da TecnoSpeed, e você já sabe como destacar os seus valores de desconto na impressão por PDF da nossa API? Caso sua resposta tenha sido não, fique comigo aqui nesta postagem, que vou demonstrar duas maneiras simples de como este processo pode ser realizado DEV! 😁 A primeira maneira que vou apresentar para vocês por aqui, é aquele em que o valor do desconto fica destacado em sua seção no PDF, exatamente igual ao exemplo abaixo: Para emitir seu PDF deste jeito, além das passagens dos campos que já são necessários para o envio de desconto em nossa API, como código, taxa de desconto e data de desconto, você também precisará enviar o campo TituloValorDesconto DEV, esta será a informação presente no JSON que definirá o valor a ser apresentado no campo demonstrado acima na impressão do boleto. Portanto, as informações de desconto ficariam conforme o JSON abaixo, para a geração igual o exemplo apresentado anteriormente: "TituloValorDesconto": "0,05", "TituloValorDescontoTaxa": "0,05", "TituloDataDesconto": "27/02/2024", "TituloCodDesconto": 1 Para um maior detalhamento sobre o significado dos outros campos, acesse a nossa documentação 😉: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360020994254-Como-informar-Desconto Outra maneira de destacar o valor do desconto, é através das mensagens de instruções que podemos enviar no corpo do PDF do boleto: Nesta modalidade, você só vai precisar passar a mensagem de instrução de desconto que for do seu desejo no campo TituloMensagem01, caso este já esteja sendo utilizado, você pode fazer uso do 02, 03 e assim por diante, até o TituloMensagem09 caso seja necessário. Para emitir deste jeito, basta inserir o JSON com o campo abaixo referenciado, além, das instruções de desconto que também precisam ser enviadas para a instrução ser considerada definitivamente pelo banco: "TituloMensagem01": "Desconto de 5 centavos até o dia 27/02", Caso for do seu desejo DEV, você também pode enviar as duas maneiras juntas, ou seja, mandar o valor destacado em TituloValorDesconto e mais uma mensagem para reforçar. 💪 Por hoje seria isso DEV, qualquer dúvida estamos à disposição por aqui e em nossos canais de atendimento. Até mais! 👊
  3. Fala Dev, beleza? Meu nome é Guilherme, sou consultor técnico aqui na operação PlugBank da TecnoSpeed, e hoje venho aqui neste POST comentar sobre um dos erros que envolvem a utilização do WebService do Bradesco para o registro de boletos. Nesse sentido, o erro em questão possui a mensagem ERRO DE CONSISTENCIA: INFORME TODOS OS CAMPOS PARA MULTA (83), e este problema geralmente esta relacionado a inconsistências no JSON de envio do boleto, e na grande maioria dos casos, pode ser solucionado com uma manutenção simples. Portanto, fica comigo neste POST, que a seguir vou demonstrar como você pode ajustar este impasse. Na maioria dos casos, este erro é causado pelo fato do cliente encaminhar a data de multa do boleto com o mesmo valor da data de vencimento, causando uma rejeição do título pelo fato do Bradesco apenas aceitar a cobrança de multa após um dia depois do vencimento. Assim, para solucionar o caso, basta passar o campo de multa com uma data superior a data de vencimento, conforme o exemplo abaixo: "TituloDataVencimento": "10/12/2023", "TituloDatamulta": "11/12/2023" Com este ajuste, provavelmente seus envios já vão dar certo e seus boletos já serão registrados. E por hoje seria isso DEV, qualquer dúvida estamos à disposição em nossos canais de atendimento e aqui neste POST também 😀! Até mais! 👍
  4. Fala Dev, beleza? Meu nome é Guilherme, sou consultor técnico aqui no Grupo TecnoSpeed, e você está recebendo o erro “Alias must be the same as the account holder” em seus PIX emitidos via TecnoPay, e não sabe como resolver este problema? Caso sua resposta tenha sido sim, fique comigo neste POST que vou detalhar como este impasse pode ser solucionado. Basicamente Dev, este erro está relacionado a divergências entre dados cadastrados no TecnoPay, e aqueles inseridos em nossa API de PIX. Portanto, na grande maioria dos casos, o problema ocorre pois a conta homologada no TecnoPay ou os outros dados complementares da conta, são repassados incorretamente na rota de cadastro para account no PlugPIX. Com isso, para solucionar o impasse, basta conferir os dados informados no TecnoPay e checar se eles estão sendo repassados corretamente no PlugPIX. Com essa checagem o erro já deve ser ajustado, porém, caso permaneça, estamos à disposição em nossos canais de atendimento para mais validações. Por hoje é isso Dev! Até mais!
  5. Fala Dev, beleza? Meu nome é Guilherme, sou consultor técnico aqui no Grupo TecnoSpeed, e você está recebendo o erro “Inclusão não permitida para títulos com instrução de protesto marcados como passíveis de pagamento parcial/divergente” para os envios da Caixa por WS? Caso sua resposta tenha sido sim, fique comigo neste POST que vou detalhar como este impasse pode ser solucionado. Resumidamente Dev, este erro ocorre quando você tenta emitir um boleto na Caixa com instruções de protesto, porém, permite que o mesmo tenha pagamentos parciais ou divergentes do valor total da cobrança. Nesse sentido, por ser um título passível de protesto em cartório, a Caixa não permite essa instrução e obriga que boletos com instruções de protesto, tenham liberado apenas o pagamento integral do valor do título. Desse modo, para passar essa instrução em nossa API, basta preencher o campo abaixo como 03: Fazendo isso, os pagamentos parciais serão proibidos e o título será registrado. Com essa checagem o erro já deve ser ajustado, porém, caso permaneça, estamos à disposição em nossos canais de atendimento para mais validações. Por hoje é isso Dev! Até mais!
  6. Fala Dev, beleza? Meu nome é Guilherme, sou consultor técnico aqui na operação PlugBank da TecnoSpeed, e você vem recebendo a mensagem ERRO DE CONSISTENCIA: INFORME TODOS OS CAMPOS PARA COMISSAO DE PERMANENCIA para os seus envios no WS do Bradesco? Caso sua resposta tenha sido sim, e você não sabe como prosseguir com a correção deste impasse, fique comigo aqui neste POST que vou lhe detalhar uma das maneiras de resolver este problema. Antes de prosseguir Dev, é interessante comentar que esta mensagem esta associada a inconsistência entre os campos informados no envio, ou seja, algum campo preenchido incorretamente ou em conflito, portanto, existem diversas possibilidades que podem acabar ocasionando o impasse, porém, a seguir vou estar detalhando uma das mais comuns que costumam ocorrer em nossos atendimentos. Nesse sentido, um dos principais motivos que acabam ocasionando este erro em nossa API, é a passagem das datas de cobrança de juros e multas, com o mesmo valor da data de de vencimento, conforme o exemplo abaixo: Essa validação varia muito de banco para banco, e algumas instituições financeiras até permitem a passagem da data de cobrança de juros no mesmo dia de vencimento, porém, no WebService do Bradesco, isso acaba sendo motivo de ocorrência do erro citado anteriormente. Visto que, para o banco em questão na modalidade WS, as cobranças de encargos por atraso de pagamento só podem se iniciar no dia seguinte ao vencimento, portanto, para corrigir o erro no cenário apontado acima no print, seria necessário passar a data para cobrança de juros como 11/08. Conforme comentei, as razões para a ocorrência do erro são muitas, então, caso mesmo com essa dica o problema continue, entre em contato conosco em nossos canais de atendimento, que estaremos à disposição para realizar os demais testes necessários. E por hoje seria isso Dev, espero que tenha gostado do POST, e caso tenha qualquer dúvida estamos à disposição para soluciona-las. Até mais! 👊
  7. Fala Dev, beleza? Meu nome é Guilherme, sou Consultor Técnico na operação PlugBank da TecnoSpeed, e você já sabe o que significa o erro The specified key does not exist durante a emissão de um PIX no Banco do Brasil? Bem, caso sua resposta tenha sido não, fique aqui comigo neste POST que vou lhe apresentar o significado deste erro e como este impasse pode ser solucionado em nossa API. Então Dev, geralmente este erro esta associado a falta de liberações bancárias na chave PIX cadastrada em nossa API para a emissão dos pagamentos. Nesse sentido, a chave pode até existir para a realização de uma transferência entre contas, contudo, na maioria dos casos faltam os escopos necessários para a emissão de PIX para cobrança, dentre outros. Inclusive, na grande parte das ocorrências desse erro, quando consultamos a chave PIX no endpoint bancário para validação das credenciais utilizadas, o retorno do BB costuma ser este: Ou seja, o banco acaba retornando que a chave PIX não possui permissões para chamar a funcionalidade de criação do pagamento. Nesse mesmo contexto, o erro pode estar associado a inconsistências nas credenciais cadastradas também, como por exemplo, o banco lhe passou uma chave mas em nossa API foi cadastrada outra, ou a chave cadastrada pode até ser a certa, mas se ela estiver com qualquer dígito ou valor incorreto, o erro será apresentado também. Com isso, para solucionar o problema, o ponto inicial é confirmar se a chave cadastrada em nossa API esta certa e conforme as informações disponibilizadas pelo banco. Caso tudo esteja correto, a nossa indicação é entrar em contato com o atendimento do BB para alinhar a liberação desses escopos necessários para a emissão do PIX via API. Lembrando que caso necessite de evidências e mais validações, estamos à disposição em nossos canais de atendimento para lhe apoiar no que for possível. E por hoje é isso Desenvolvedor, espero que tenha gostado do POST e que o conteúdo tenha agregado ao seu conhecimento. Qualquer dúvida estou à disposição, e até mais!
  8. Olá Arícia, bom dia! O custo do tráfego entre TecnoSpeed e VAN, fica como responsabilidade nossa. Atenciosamente.
  9. Fala DEV, beleza? Meu nome é Guilherme Borges, sou consultor técnico aqui na operação PlugBank da TecnoSpeed, e em uma das novas validações aplicadas pelo Banco Sicoob em seus arquivos, a instituição financeira passou a validar as mensagens de instrução contidas nos títulos enviados para o banco. Portanto, se você estiver com algum erro em sua validação de remessa como “erro de mensagem a ser impressa” ou “valor informado difere do default definido para o banco”, fique comigo aqui neste POST que vou demonstrar como você pode solucionar esse problema na API de boletos da TecnoSpeed. Bem DEV, a correção do problema é bem simples, basta inserir no seu JSON de inclusão de boletos o campo TituloTipoImpressaoMensagem, e preenchê-lo com o valor de 3, conforme o print abaixo: Realizando este procedimento, o banco acatará todas as mensagens contidas no boleto, e sua remessa será validada normalmente. Precisando de qualquer outro apoio, permanecemos à disposição em nossos canais de atendimento. Por hoje é isso, e até a próxima DEV!
  10. Fala DEV, beleza? Meu nome é Guilherme Borges, sou consultor técnico aqui na operação PlugBank da TecnoSpeed, e uns dos recentes erros mais retornados pelo Banco do Brasil em suas validações de remessa, é o “CRTA/VRC não localizada para o cedente”. Portanto, se você está com esse problema em seu arquivo, fique comigo aqui neste POST que eu vou lhe demonstrar como ajustar esse problema na API de boletos da TecnoSpeed. Primeiramente DEV, é importante ressaltar que este erro é retornado quando o banco não identifica a carteira em questão para o CNPJ de cedente que está sendo utilizado nas emissões, portanto, o primeiro passo é consultar se a carteira informada está realmente correta. Contudo, na maioria dos casos, o erro ocorre por conta da falta de preenchimento do campo TituloVariacaoCarteira no JSON de inclusão de boletos. Basicamente, este campo é uma informação bancária repassada pelo banco, e serve como um complemento a carteira, realizando o preenchimento desse dado, provavelmente o erro vai parar de ocorrer e seu arquivo será validado com sucesso. Nesse sentido, vou estar deixando nossa documentação de preenchimento desse campo, caso surjam mais dúvidas com relação ao preenchimento do mesmo: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360033735733-Como-informar-a-variação-da-carteira-para-o-Banco-do-Brasil Precisando de qualquer outro apoio, permanecemos à disposição em nossos canais de atendimento. Por hoje é isso, e até a próxima DEV!
  11. Fala Desenvolvedor, beleza? Você recebeu o erro “Lote Não Aceito - Totais do Lote com Diferença” em sua remessa do Bradesco e não sabe o que fazer? Caso sua resposta seja sim, fique comigo nesse POST que vou dar mais detalhes sobre essa rejeição. Este erro geralmente acontece quando os totais dos valores dos pagamentos contidos no arquivo de remessa, não batem com os valores que foram inseridos nas posições responsáveis por essa informação no arquivo. Com isso, para solucionar o problema é necessário se atentar aos tópicos abaixo: Verificar no trailer de lote, nas posições de 18 a 23, se o somatório dos registros informados está preenchido corretamente. Verificar no trailer de lote, nas posições de 24 a 41, se o valor total do lote está correto em relação ao valor total dos pagamentos. Verificar no trailer do arquivo, nas posições de 18 a 23, se a quantidade de lotes está correta. Verificar no trailer do arquivo, nas posições de 24 a 29, se a quantidade de registros informados está correta em relação ao total de linhas no arquivo de remessa. Caso todas essas informações estejam corretas, porém, mesmo assim, o erro permaneça acontecendo, é recomendável submeter esse arquivo a uma análise do setor de remessas do Bradesco. E basicamente por hoje seria isso DEV, qualquer dúvida estamos à disposição em nossos canais de atendimento. Até mais! 👊
  12. Fala Desenvolvedor, beleza? Meu nome é Guilherme, sou consultor técnico na operação Plug Bank da TecnoSpeed, e hoje venho aqui para tirar uma dúvida muito comum entre os usuários que integram nossa API de pagamentos com o Banco Bradesco. Por medidas de segurança e para evitar equívocos no momento da transferência bancária, alguns clientes preferem que seus títulos enviados fiquem pendentes para aprovação de um responsável no internet banking, para alguns bancos, isso é definido contratualmente, porém, o Bradesco disponibiliza um campo que pode te ajudar a definir essa configuração. Você já sabe como fazer este processo? Caso a resposta seja não, fique comigo nesse POST que vou te mostrar como você pode implementar isso em suas rotinas de transmissão de remessas de pagamentos para o Bradesco. Bora lá? Bem Desenvolvedor, resumidamente, este processo será definido em nossa API pelo campo movimentCode, e seu preenchimento fica da seguinte maneira: Se o campo não for preenchido, por padrão ele é enviado como ‘00’ pela nossa API, o que indica que o pagamento não ficará pendente de aprovação no internet banking. Se você quiser que os pagamentos fiquem pendentes para aprovação, é necessário preencher o campo em questão com ‘09’. Fazendo isso, todos os títulos emitidos já vão ficar pendentes de aprovação no internet banking para algum usuário responsável. E basicamente por hoje seria isso DEV, qualquer dúvida estamos à disposição em nossos canais de atendimento. Até mais! 👊
  13. Fala Dev, beleza? Meu nome é Guilherme, sou Consultor Técnico aqui na TecnoSpeed, e durante o processo de geração de remessas do tipo PIX transferência para o banco Itaú, é necessário sempre preencher a chave PIX do beneficiário, que em nossa aplicação é mapeada como a pixKey. Contudo, você sabe as orientações de como deve ser preenchida cada chave? Se sua resposta foi não, fique comigo aqui neste POST que vou dar mais detalhes sobre o processo a seguir. Bora lá? Basicamente, a chave PIX para remessas do banco Itaú podem ser de 5 tipos diferentes: Telefone, E-mail, CPF, CNPJ e Chave Aleatória. A seguir, seguem as orientações do banco com relação ao preenchimento de cada uma: Telefone📱: Deve ser iniciado com o "+" acompanhado do código do país, em sequência é preciso inserir o DDD, e por fim o número de celular com 9 dígitos. Formato: +XXXXXXXXXXXXX E-mail ✉️: Deve possuir o @ em sua composição, e ter no máximo 77 caracteres. Formato: xxxxxxxx@xxxxxxx.xxx CPF 🤵: Contém os 11 dígitos, porém, precisa ser preenchido sem sua máscara, ou seja, apenas os números sem os traços e pontuações. Formato: XXXXXXXXXXX CNPJ 🏬: Contém 14 dígitos, e também deve ser preenchido sem sua máscara. Formato: XXXXXXXXXXXXXX Chave aleatória ⁉️: Número hexadecimal de 32 posições, divido em 5 blocos separados por um “-“. Deve ser informado com os traços, ou seja com as 36 posições totais. Formato: XXXXXXXX-XXXX-XXXXXXXX-XXXXXXXXXXXX Lembrando DEV, todas as informações foram retiradas dos manuais disponibilizados pelo próprio Itaú, e havendo qualquer dúvida estamos à disposição em nossos canais de atendimento e também aqui no fórum. Por hoje seria isso, até mais Dev! 👊
  14. Fala Desenvolvedor, beleza? Meu nome é Guilherme Borges, sou Consultor Técnico na operação PlugBank da TecnoSpeed, e considerando que recentemente implementamos em nossa API de pagamentos a possibilidade de gerar um PIX via arquivo de remessa, vim aqui neste POST demonstrar para vocês como é possível realizar a geração deste pagamento em nosso produto. Bora lá? Antes de começarmos DEV, é importante salientar que para realizar os processos demonstrados nessa material, é preciso que seu pagador e sua respectiva conta e convênio já estejam devidamente cadastrados em nossa aplicação, conforme as documentações disponibilizadas abaixo. Combinado? Cadastrar Pagador 💸: https://docs.pagamentobancario.com.br/#tag/payer/operation/createPayer Cadastrar Conta Bancária 🏦: https://docs.pagamentobancario.com.br/#tag/account Então já que o pagador e a conta Bancária já estão cadastrados, vamos partir para a geração deste pagamento tipo PIX. Primeiramente, para gerar este título, vamos utilizar a rota de "Diversos" em nossa aplicação, que pode ser consumida através das seguintes URLs: Homologação: https://staging.pagamentobancario.com.br/api/v1/payment/various Produção: https://api.pagamentobancario.com.br/api/v1/payment/various Como se trata apenas de uma demonstração, estarei utilizando o ambiente de homologação nos exemplos demonstrados a seguir. Além disso, para realizar as devidas autenticações em nossa API, o processo é exatamente o mesmo da geração de outros pagamentos, basta enviar nos Headers o CNPJ de Software House, Token de Software House, e o CNPJ do pagador cadastrado. Exemplo no Insomnia: * Todos os dados demonstrados acima são fictícios, e foram utilizados apenas com o intuito de demonstração! Agora que já possuímos nossa URL e Headers de autenticação montados, vamos para os campos necessários em nosso JSON de envio para criar um PIX de Transferência: accountHash 🔒: Este é o Hash da conta cadastrada para o pagador em questão, este valor deve ser repassado em formato de String e é devolvido pela nossa API no momento do cadastro da conta e também em uma consulta das contas cadastradas. Documentação de consulta de contas: https://docs.pagamentobancario.com.br/#tag/account/operation/fetchAccount paymentForm 🔼: Este código, que também precisa ser repassado em formato de String, define a forma de pagamento que você vai utilizar para o título em questão que esta sendo gerado. Em nossa aplicação, para utilizar o tipo PIX, é necessário preencher o campo com 45 (Transferência) ou 47 (QRCode). paymentDate📅: Aqui você preenche com a data que o pagamento deve ser realizado. Formato: AAAA-MM-DD dueDate📅: Data de vencimento. Formato: AAAA-MM-DD. amount 💰: Valor do pagamento, passar em formato de Number. pixType ⁉️: Define o tipo de chave PIX que você vai utilizar na transação, podendo ser repassado com os seguintes valores: pixKey 🗝️: Campo onde é repassado a chave PIX do Beneficiário. Atualmente, utilizado apenas para o Itaú. ispbCode 🏦: Atualmente este campo só é utilizado pelo Bradesco, e determina que deve ser passado nele o código do banco do beneficiário. Consulte o código aqui: https://globalfinanceiro.com.br/codigos-ispb-e-compe-dos-bancos/ registrationComplement 🖋️: Atualmente este campo só é utilizado pelo Bradesco, e determina o tipo da conta utilizada na transferência em questão: Dados de Beneficiário 🤵: Necessário criar um Array, igual ao apresentado no exemplo abaixo, contendo as informações bancárias do beneficiário: Agora que todos os campos foram apresentados, vou demonstrar a seguir dois JSONs utilizados para a geração de um PIX de Transferência para o Itaú e para o Bradesco: Itaú: { "accountHash": "SeuHashAqui", "paymentForm": "45", "description": "teste", "paymentDate": "2023-05-30", "amount": 1, "pixType": "01", "pixKey": "44998984040", "beneficiary": { "name": "Teste Fornecedor", "cpfCnpj": "12345678910", "bankCode": "237", "agency": "1324", "agencyDigit": "5", "accountNumber": "589632" } } Bradesco: { "accountHash": "youHash", "paymentForm": "45", "description": "teste", "dueDate": "2023-06-29", "paymentDate": "2023-05-30", "registrationComplement": "01", "amount": 1, "ispbCode": "60746948", "beneficiary": { "name": "Teste Fornecedor", "cpfCnpj": "12345678910", "bankCode": "237", "agency": "1324", "agencyDigit": "5", "accountNumber": "589632" } } Realizando o POST destas informações, em caso de sucesso, o response da API será algo parecido com isso: "uniqueId": "UNIQUEID", "status": "CREATED", "paymentType": "8", "accountHash": "yourHash", "description": "TECNOSPEED HOMOLOGAÇÃO", "paymentForm": "45", "paymentDate": "2023-05-30", "dueDate": "", "amount": 1, "rebateAmount": 0, "interestAmount": 0, "discountAmount": 0, "fineAmount": 0, "movimentCode": "", "complementaryCode": "", "compromiseType": 0, "transmissionParam": 0, "pixType": 1, "pixKey": "44998984040", "pixUrl": "", "pixTxid": "", "ispbCode": "", "registrationComplement": "", "tags": [] } Em caso de erro, um response como este deve ser retornado: { "code": 422, "message": "Unprocessable Entity", "errors": [ { "message": "Conta não encontrada", "internalCode": 4007 } ] } Por fim, agora vou demonstrar como pode ser gerado um PIX por QRCode em nossa API. Resumidamente, os campos referentes ao AccountHash, Forma de pagamento, Data de pagamento, valor do pagamento e o Array dos dados do Beneficiário se mantém. Contudo, nesta modalidade são necessários apenas mais dois campos referentes ao PIX: pixUrl 🤔: Chave de endereçamento do PIX. pixTxid 🧐: Código de identificação do QRCode Um JSON de exemplo que pode ser citado tanto para o Bradesco quanto para o Itaú, é este: { "accountHash": "yourHash", "paymentForm": "47", "description": "teste", "dueDate": "2023-06-29", "paymentDate": "2023-05-30", "amount": 1, "pixUrl": "1s1ds2a3sad1asdasda", "pixTxid": "1sadasdasdasdasdad", "beneficiary": { "name": "Teste Fornecedor", "cpfCnpj": "12345678910", "bankCode": "237", "agency": "1324", "agencyDigit": "5", "accountNumber": "589632" } } E por hoje seria isso Dev, vou estar deixando a seguir o link da nossa documentação, caso deseje ter acesso a mais informações e exemplos. Além disso, também estamos à disposição em nossos canais de atendimento. Até mais! 👊 Documentação: https://docs.pagamentobancario.com.br/#tag/payment/operation/variousPayment
  15. Olá Jairo, boa tarde! Com relação ao erro de CEP, ele ocorre quando o banco não consegue localizar um determinado CEP em sua base, por exemplo, em um dos boletos rejeitados o CEP repassado foi o 13295000, ao consultarmos esse valor no site do correios, a informação devolvida é esta: Link para consulta: https://buscacepinter.correios.com.br/app/endereco/index.php Diante disso, no caso deste erro seria necessário alinhar com o banco a utilização deste CEP, ou passar um CEP geral da cidade que seja possível de ser consultado. Com relação ao segundo erro, diversos de nossos clientes que utilizam juros para o Itaú estão enfrentando o mesmo problema, visto que, encaminhamos ao banco os juros preenchidos, porém, eles consideram que o valor esta zerado. Abaixo temos um teste feito diretamente na API do banco: Como é possível identificar na imagem, estamos passando o campo com valores, porém, mesmo assim o Itaú retorna que o campo esta zerado. Nessas situações, estamos pegando o payload de envio de alguns boletos e encaminhando para os clientes, de modo que eles possam abrir chamados de verificação dos envios junto ao Itaú, e também que a ocorrência desse impasse possa ser explicada pelo banco. Se tiver algum ID de exemplo, já posso estar lhe disponibilizando o payload. Qualquer dúvida estou à disposição. Atenciosamente.
  16. Fala Desenvolvedor, beleza? Meu nome é Guilherme Borges, sou consultor técnico da operação PlugBank da TecnoSpeed, e hoje vou estar apresentando para vocês como pode ser corrigido um famoso problema que acontece durante as integrações de envio por WebService do Bradesco: Contrato não encontrado. Bora lá? Resumidamente DEV, este erro acontece quando o Banco não localiza o contrato de cobrança para o CNPJ de cedente que esta sendo utilizado nas emissões de boletos. Desse modo, a recomendação para quando este erro acontecer, é verificar se o cadastro do cedente esta correto em nossa API, e confirmar se o valor do CNPJ presente neste cadastro é o mesmo que consta no contrato com a instituição financeira, visto que, qualquer diferença entre estes dois ambientes pode resultar no erro que estamos tratando por aqui, principalmente no caso dos sacados que possuem CNPJs para matriz e filial. Caso você confirme que o cadastro esta correto, o contato com o banco será necessário, para averiguar se falta a assinatura de algum contrato ou liberação para que o cedente possa emitir os boletos via WebService. E por hoje seria isso Dev, qualquer dúvida estou à disposição, e até mais!
  17. Olá Alexandre, boa tarde! Neste caso, seria o sequencial de remessa e não o número de convênio. Neste Post, eu apresento como você pode atualizar este número: Atenciosamente.
  18. Olá Alexandre, bom dia! Tentei gerar uma remessa por aqui, e o erro devolvido pela API foi este: É preciso preencher o campo "Número Atual" lá no cadastro do convênio, neste campo você vai inserir o sequencial de remessa a ser seguido nos seus envios. Atenciosamente.
  19. Olá Alexandre, boa tarde! Posso tentar gerar uma remessa de teste por aqui, utilizando estas credenciais, por gentileza? Atenciosamente.
  20. Olá Alexandre, boa tarde! Em teoria era para deixar gerar a remessa sim. Consegue validar se a rota realmente esta em homologação, e se os headers estão corretos também, por gentileza? Atenciosamente.
×
×
  • Create New...