Leonardo

A remessa sera o meio de comunicação onde os bancos irão entender que gostaria de criar um registro para o seu titulo emitido. Nele estará todas as informações referente ao boleto que será registrado na base bancária, como por exemplo o valor, vencimento, multas e juros caso tenha sido informado.... Já referente a obrigatoriedade, existem diferentes formas para que este registro ocorra, para isso deixo esta documentação onde explicamos as três diferentes formas que temos homologado atualmente em nossa API Entendendo os modos de registro

Olá Alexandre! Esta falha ocorre devido a uma falta de informação no cadastro do convênio em nossa API. Para que consiga executar este endpoint será necessário adicionar um valor no campo Numero Atual( Remessa ), Ou no caso de uam conta do Banco do Brasil o campo Reiniciar número da remessa diariamente pode ser informado como True Deixo nossa documentação de dicas de preenchimento caso ache necessário: Dicas de preenchimento para o BB Caso esteja usando nossa GUI Web, segue o campo onde deverá ser corrigido Se estiver realizando os cadastros através das requisições via API, segue os os campos para ser informado na edição do seu convênio Alterando um convênio ConvenioReiniciarDiariamenteboolean ConvenioNumeroRemessastring No mais, estaremos a disposição. Forte abraço.

Continuous Integration ( Integração contínua ) é uma prática de desenvolvimento utilizada com frequência no mundo da programação, nela serão realizadas as junções de códigos feitas pelos desenvolvedores em um repositório central onde builds e testes são executadas. Um dos principais benefícios é poder detectar erros rapidamente e localizá-los com mais facilidade. Como cada mudança introduzida é tipicamente pequena, haverá menos esforço para identificar o que foi introduzido no código e então corrigi-lo. Gostou do conteúdo? Siga para mais!

Fala dev! Para este post, comentaremos um pouco sobre as principais formas de estarmos realizando um deploy. Podemos estar listando as seguintes opções para um bom deploy: Manual, Parcialmente Automática, Completamente automática. Manual A opção manual, é uma das formas mais populares, porém um tanto trabalhosa. Como exemplo de um deploy manual é o Protocolo de transferência de arquivos - FTP onde será permitido que dois computadores com acesso a internet troquem arquivos. Usando este tipo de deploy, será acompanhado de alguns problemas. Podemos esquecer de algumas etapa, levaremos mais tempo que o necessário em uma atividade que poderia ser mais automatizada, conflitos nas trocas de arquivos que podem ocorrer caso duas ou mais pessoas realizarem o deploy ao mesmo tempo. Parcialmente automática Quando atualizamos um repositório GIT, por exemplo, estamos realizando um deploy parcialmente automático Ele recebe essa classificação pois, apesar de alguns comandos precisarem ser realizados por humanos, o push para a master que ocorre através de um pequeno hook que atualiza o servidor, é totalmente automática. Outra grande vantagem deste deploy é o controle de versionamento do GIT. Completamente Automática Para esta opção de deploy, certamente é o mais moderno e completo até o momento. Quando utilizamos esta opção, temos mais segurança, qualidade e eficiência no processo, pois será utilizado o chamado Continuous Integration - CI. Algumas ferramentas que ajudam nesta automatização do seu deploy: Jenkins, Travis CI, GitLab, Azure Pipelines, Circle CI, entre outros. Gostou do conteúdo? Siga para mais novidades!

Olá pessoal! Para este post, comentaremos um pouco sobre o que são as URLs, URIs e URNs. Diariamente são realizadas mais de 3 bilhões de consultas em todo o mundo, com isso, são acessados diversos endereços para que tenha o resultado esperado. Mas o que constrói esta consulta para que tenhamos o resultado esperado? Na construção de um endereço de pesquisa, temos as seguintes siglas envolvidas: URL, URI e URN. URI: Uniform resourse identifier - Identificador de recursos uniforme É uma sequência de numéricos, letras e caracteres especiais utilizados para identificar documentos. Exemplo: https://tecnospeed.com.br/boleto/#conheca URL: Uniform Resource Locator – Localizador padrão de recursos Uma URL é o endereço de um recurso na internet e refere-se a um subconjunto de URIs. Ele realiza a identificação de um recurso, bem como o protocolo usado para acessa-lo. Uma URL pode ser composta por até cinco partes O protocolo – usado para acessar o recurso A localização do servidor – (Endereço IP ou nome do domínio) Porta do servidor – (opcional) Localização do recurso na estrutura de diretórios do servidor (caminho) Um identificador de fragmento – (opcional) Esta URL como exemplo é composta por 3 partes https://tecnospeed.com.br/boleto/ https: Sendo o protocolo tecnospeed.com.br: Sendo o host DNS boleto: nome do recurso URN: Uniform resource name – Nome Uniforme de Recurso Realiza a identificação de um recurso através de um nome estático mesmo se os seus dados forem movidos para outro local. Uma URN não informa qual protocolo deve ser utilizado pra localizar algo na internet. Exemplo: urn:isbn:45254585 urn:publishing:Test

Olá pessoal! Neste post estarei demonstrando como podemos extrair a chave pública do certificado digital. Caso seja necessário o envio de uma chave para que o banco possa homologar os dados. Para os passos abaixo, serão feitos a partir do sistema operacional Windows. primeiramente, precisamos acessar o painel de controle e localizar a opção Opções da Internet. Em seguida acesse a aba Conteúdo e selecione a opção Certificados. Ao selecionarmos a opção Certificados, será aberta uma nova janela com a aba Pessoal. Nela será listadas todos os certificados que estão instalados em sua máquina. Selecione o certificado que deseja exportar a chave e selecione a opção Exportar... Logo em seguida, seguiremos alguns passos para exportar esta chave Selecione a opção Avançar Selecione a opção "Não, não exportar a chave privada" (ela exportará apenas a chave publica) e clique no botão "Avançar" Em seguida X.509 binário codificado por DER (*.cer) Clique no botão "Procurar...". Indique o diretório onde será salvo o arquivo e nomeie o arquivo em seguida, selecione a opção "Salvar". Logo após clique no botão "Avançar". Por fim, selecione botão "Concluir"

Olá Dev como estão? Para este post, estaremos descrevendo um dos modelos para que posa acessar os campos de um JSON utilizando JavaScript. O objetivo deste post é mostrar uma forma simples e rápida de fazermos essa tarefa. Abaixo temos um JSON de envio retornado pela nossa API de pagamentos relacionado ao cadastro de uma conta: { "accounts": [ { "bankCode": "104", "accountHash": "mwauoMy-FP", "agency": "9999", "agencyDigit": "", "accountNumber": "1111", "accountNumberDigit": "", "accountDac": "", "convenioAgency": "", "convenioNumber": "19191919", "remessaSequential": 1 } ] } Para o exemplo acima, temos apenas um nível de acesso em nosso JSON, desta forma podemos navegar entre os campos para estarmos recuperando o valor desejado. Como exemplo, estaremos recuperando o valor do campo accountHash referente a identificação única da nossa conta. A primeira etapa é recuperarmos toda a resposta devolvida pela API. const response = await fetch("https://staging.pagamentobancario.com.br/api/v1/account", options) const retorno = await response.json() Tendo todo o conteúdo do retorno, podemos filtrar os campos que desejamos utilizando o acesso das propriedades. let accountHash = retorno.accounts[0].accountHash Basicamente no exemplo estamos criando uma variável que receberá o valor de identificação da conta. Para isso os campos utilizados se referem á: retorno: Contém todos os dados de retorno da requisição; accounts[0]: Estará pegando o objeto no índice 0 em nosso Array accountHash: filtra somente o valor contido no campo: Exemplo retornado: mwauoMy-FP

Olá Devs, como estão? Para os usuários que utilizam as integrações através da OCX ( componente ) pode ter se deparado com a seguinte falha: Socket Error # 10060. Desta forma, este post servirá para listar alguns pontos a qual podem estar ligadas. O que seria este erro? O problema ocorre ao usar servidores proxy e quando o tempo para carregar a página da Web online não é suficiente. Em algumas situações, a conexão atinge o tempo limite e o erro será retornado. Primeiramente, identifique se ainda esta utilizando a URL de comunicação contendo a porta 8080, como por exemplo: Homologação: http://homologacao.cobrancabancaria.tecnospeed.com.br:8080 Produção: http://cobrancabancaria.tecnospeed.com.br:8080 Caso esteja utilizando, altere-as para: Homologação: http://homologacao.cobrancabancaria.tecnospeed.com.br Produção: http://cobrancabancaria.tecnospeed.com.br Esta alteração será necessária, pois a porta 8080 foi bloqueada em nossa aplicação, sendo assim, caso tente enviar alguma requisição para a nossa API, ela será bloqueada. Outros pontos a serem analisados seriam as: Porta bloqueada proxy bloqueando a porta 80 web: Será necessário criar uma configuração de exceção para as url's Configurações incorretas da conexão de dados Quando a configuração de conexão do proxy da web não permite tempo suficiente para receber uma resposta do site de destino e, portanto, o tempo limite da conexão é excedido. Problemas de registro Infecção viral Em caso de dúvidas, estamos a disposição.

Olá! Relacionado a modalidade de cobrança, não há esta necessidade de gerar um certificado, o Santander requisita um certificado A1 ( geralmente são usados nas emissões de notas fiscais ). Qualquer coisa, deixo esta documentação para que possa averiguar o fluxo de solicitação: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360015311773-Utilizando-o-registro-via-Web-Service-Bancário-com-o-Santander Já referente a modalidade PIX, até o presente momento não temos uma comunicação desenvolvida junto ao banco Santander. Desta forma, ainda não temos o conhecimento de como esta ocorrendo as liberações das credenciais. Para que possa acompanhar os bancos que estão sendo homologados, deixo esta documentação: https://docs.pix.tecnospeed.com.br/#tag/accounts Espero ter auxiliado em sua dúvida. Forte abraço.

Olá Devs, como estão? Para este post, estarei demonstrando como podemos estar realizando a ativação do WebService bancário junto ao banco Itaú. Precisamos realizar algumas etapas antes de estarmos ativando este processo de comunicação. Para isso, seguem as orientações. Instalações: 1 - Ter em sua máquina o OpenSLL instalado Precisamos dele para rodarmos alguns comandos para a geração do nosso certificado. 2- Instalar o GitBash em sua máquina. Estaremos utilizando este terminal, pois foi o que mais apresentou sucesso nas gerações de certificados. 3 - Baixar a collection do postman disponibilizado pelo Itaú: https://devportal.itau.com.br/assets/certificado_dinamico_postman_fa4467d91c.zip Com as instalações, podemos seguir para a próxima etapa. Solicitar as credenciais ao banco Itaú: Para que a nossa aplicação consiga se comunicar junto a API do banco Itaú precisamos de algumas chaves de autenticação. Para ter acesso às informações será necessário acessar os canais de suporte, combinados com o seu representante comercial Itaú. Solicite ao suporte bancário os seguintes dados: ClientID : Chave utilizada para autenticar na API do Itáu Token temporário: Chave que será utilizada para gerarmos um certificado digital OBS: Caso o representante comercial disponibilize as seguintes chaves: ClientID; Token temporário; Chave Sessão; Solicite que seja realizada a descriptografia destas informações; Para que o banco realize a geração das credenciais, será solicitado ao titular da conta dois arquivos private.pem public.pem Estes arquivos podem ser gerados utilizando o seguinte comando openssl genpkey -out private.pem -algorithm RSA -pkeyopt rsa_keygen_bits:2048 openssl rsa -in private.pem -pubout -out public.pem Na etapa de descriptografia, caso o representante informe que desconhece este passo, apresente a documentação abaixo na sessão: 1.2 - Decifrar credenciais https://devportal.itau.com.br/certificado-dinamico#obter-chaves Como segunda opção de descriptografia realize estes passos: Será necessário: Script para ser executado script.rar Ter o JAVA instalado em sua máquina. CMD para a execução do script. Tendo todos os itens instalados, execute o seu CMD dentro da pasta onde se encontra o script com o comando java -cp . Criptografia Ao executar, será solicitado os seguintes dados ClientId: <ClientId presente no e-mail> Token temporário: <Token temporário presente no e-mail> Chave sessão: <Chave sessão presente no e-mail> Caminho absoluto da chave privada: <C:/Users/.../.../private.pem> (obtida através do procedimento de geração de par de chaves (public.pem e private.pem)> finalizando o script será apresentados o ClientID e o Token Temporário Ao solicitar, será encaminhado no e-mail contendo os seguintes dados Processo de Decriptografia Client id decifrada com a chave de sessao AES: [e26f2f89-0ead-4ca6-8bc3-dd44b4ab3cc7] Token decifrado com a chave de sessao AES: [eyJraWQiOiJhZTYxYWIxZi0yNTRhLTQ5ZWQtODMzNC05ZDJlN2E0MzZiNGQuaG9tLmdlbi4xNTk3NjAwMzM2OTkyLmp3dCIsImFsZyI6IlJTMjU2In0.eyJzdWIiOiJlMjZmMmY4OS0wZWFkLTRjYTYtOG JjMy1kZDQ0YjRhYjNjYzciLCJhdXQiOiJNQVIiLCJ2ZXIiOiJ2MS4wIiwiaXNzIjoiaHR0cHM6XC9cL29wZW5pZC5pdGF1LmNvbS5iclwvYXBpXC9vYXV0aFwvdG9rZW4iLCJBY2Nlc3NfVG9rZW4iOiIyY WEzZmU5NS43OGM2YjhmNS1lZWJjLTQxMzQtYmJlZS1hZDAzMjZmMTRmM2EiLCJzb3VyY2UiOiJFWFQiLCJlbnYiOiJIIiwic2l0ZSI6ImRldiIsInVzciI6Im51bGwiLCJtYmkiOiJ0cnVlIiwidXNlcl9p ZCI6ImUyNmYyZjg5LTBlYWQtNGNhNi04YmMzLWRkNDRiNGFiM2NjNyIsInNjb3BlIjoiZXNjb3BvX2RlZmF1bHQiLCJleHAiOjE2MTg5NDIyMTIsImlhdCI6MTYxODUxMDIxMiwiZmxvdyI6IkNDIn0.ZEI GYAUu-8-aCirhuClcp4F4qpL9L0KFh0pQJggXieUSCEasX-3I5QLvp5BkKcE2RhwvRfW2dUuiXJGaDqK_Mri6wZ8gVVdeHaP3ctwm8_4WBdHzxVPsAQKv2MAi8IWvHaFLFLUFcF7Z9- fpTkve_8SBnnJb4L_O7SYzXgxg3zpYSCFwMr4SrBvidq2plajEbytcDXikAXyibAWr2OH5Aijq8yfIc6dbMbH2ueA1V3mft7b_eueBQlihF1PHbytVWah6RleR5He9FLbjygcZ-F- 1ygx5yTSl_DMCGn4uCYmH5IfkZa9jC9A2-t4jlIlvFZHeGVl_c2-xaWFBd_9ryQ] Gerando um certificado CSR e KEY com o OpenSLL: Ótimo, se chegou até aqui, provavelmente possui as credenciais disponibilizadas pelo banco, agora precisamos gerar um certificado para que possamos ter acesso a outros dados que o banco estará disponibilizando. Certificado CRT ClientSecret Para recebermos este dados, estaremos utilizando as seguintes ferramentas; GitBash OpenSLL Collection do Postman Crie uma pasta para salvarmos os arquivos que serão gerados, após isso, abra o seu terminal GItBash e execute o seguinte comando: Para Windows: openssl req -new -subj "//CN=CLIENTID\OU=tecnospeed\L=CIDADE\ST=ESTADO\C=BR" -out ARQUIVO_REQUEST_CERTIFICADO.csr -nodes -sha512 -newkey rsa:2048 -keyout ARQUIVO_CHAVE_PRIVADA.key Para Ubuntu: openssl req -new -subj "/CN=ClientID/OU=tecnospeed/L=CIDADE/ST=ESTADO/C=BR" -out ARQUIVO_REQUEST_CERTIFICADO.csr -nodes -sha512 -newkey rsa:2048 -keyout ARQUIVO_CHAVE_PRIVADA.key Lembre-se de alterar alguns dados conforme os dados do titular da conta CN = ClientID disponibilizado via e-mail OU = Deixe preenchido como tecnospeed L = Cidade onde se localiza a Agência do cliente ESTADO = onde se localiza a Agência do cliente C = País onde se localiza a Agência do cliente ARQUIVO_REQUEST_CERTIFICADO.csr = Dê um nome ao seu certificado csr que será gerado ARQUIVO_CHAVE_PRIVADA = Dê um nome a chave Key vinculada ao certificado Ao executar o comando em seu terminal, temos os seguintes arquivos gerados em sua pasta Perfeito, temos nosso certificado gerado, agora estaremos utilizando a collection do postman que baixamos no início deste post. Assim que importar, iremos acessar a pasta Ativação Certificado Dinâmico e utilizaremos o methodo POST 3 - Envio de arquivo .csr No body da requisição, insira o certificado.csr em formato texto que foi gerado anteriormente. Para ter o texto deste certificado, abra em um editor de texto de sua preferência. Exemplo de como precisa estar na requisição para o banco Na mesma requisição, adicione também o token temporário retornado pelo banco Como resposta teremos os seguintes dados Tendo estes dados, salve o campo Secret separado do certificado em sua pasta com a extensão .txt e o conteúdo do certificado salve com a extensão .crt Ao realizar todos os passos, precisamos realizar a conversão para .pfx. Com isso, voltamos ao nosso terminal e executaremos o seguinte comando: openssl pkcs12 -export -out certificado_convertido.pfx -inkey certificadoKey.key -in certificadoGerado.crt OBS: como recomendação, acesse a documentação: Nela, demonstramos como converter utilizando o Ubuntu Após isso, siga com a nossa documentação para realizar os cadastros em nossa API: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/4413913645591-Utilizando-o-registro-via-Web-Service-Bancário-com-o-Itaú-v2

Olá Dev, como vai? Para este post, comentaremos sobre a seguinte falha retornada ao tentarmos emitir um boleto através do WebService do Unicred. Erro inesperado ao gerar boleto para Unicred WS: OOM command not allowed when used memory > 'maxmemory' Esta falha será apresentada, pois a nossa API estará tentando se comunicar com a aplicação bancária, porém, a memória máxima de processamento do banco foi atingida. Para estar solucionando esta falha, será recomendado que busque o suporte bancário para que possa ser analisado internamente este cenário. Assim que for solucionado, volte para a sua aplicação e tente emitir um novo boleto. Caso tenha alguma dúvida, estaremos à disposição.

Hoje estaremos demonstrando como realizar uma requisição HTTP utilizando a aplicação web Bubble Primeiramente precisamos criar um plugin, onde iremos montar a requisição. Estaremos acessando a opção “My Plugins” e em seguida “New Plugin”, após isso, será requisitado o nome do seu plugin. Assim que for preenchido teremos acesso ao nosso ambiente de desenvolvimento. Ao acessarmos, teremos acesso a algumas configurações, mas para este exemplo estaremos utilizando a opção “API calls”. Caso tenha seguido os passos, teremos uma tela similar a esta. Tendo nosso ambiente iremos simular uma comunicação de autenticação em nossa API PlugPIX. Neste ambiente, temos a possibilidade de definir qual o tipo de autenticação estaremos utilizando. No momento deixaremos o padrão já preenchido “None or self-handled” Após isso, teremos a opção “Add another call” para criarmos a nossa requisição. Referente aos campos que precisamos preencher, deixaremos com o seguintes dados Name: Um nome de sua preferência Use as: Data Data type: Json Method: POST URL: https://pix.tecnospeed.com.br/oauth2/token Headers: Authorization: Basic dGVzdGUxMjM6dGVzdGUxMjM User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Body Type: JSON Body: { "grant_type": "<client>", "role": "<sh>" } Body parameters: sh : software_house client: client_credentials Tendo todos os campos preenchidos, podemos estar realizando a chamada selecionando a opção: Initialize call OBS: por ser dados fictícios, teremos a seguinte resposta {"code":401,"message":"invalid credentials"} Caso tenha curiosidade em conhecer nossa aplicação PIX, deixo a documentação https://docs.pix.tecnospeed.com.br/

Olá dev! Hoje comentaremos sobre a rejeição retornada pelo banco Itaú ao emitirmos um PIX: falha na validação do certificado filter failed. Esta rejeição está sendo acusada pelo Itaú por estar faltando alguma identificação de autenticação assim que a nossa API tenta se comunicar com o banco. Deixamos como exemplo os seguintes campos preenchidos no cadastro de um certificado extension : CSR accountId: id da conta onde será vinculado o certificado file: o arquivo .CRT gerado pelo banco Itaú Por estar faltando uma informação a comunicação será rejeitada pelo banco Desta forma adicionaremos o campo key: arquivo da chave gerada pelo banco Itaú Após subir o certificado, tente gerar um novo PIX Para uma melhor visualização nos campos e rotas de comunicação, acesse a documentação: https://docs.pix.tecnospeed.com.br/#operation/Upload certificado Caso tenha alguma dúvida estamos a disposição.

Olá, Dev! Para este post, comentaremos um pouco sobre as requisições realizadas através da aplicação Bubble. Se você utiliza esta aplicação para desenvolver suas aplicações, possivelmente possa ter se deparado com a seguinte falha Raw response for the API Status code 403 <html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> </body> </html> Esta falha ocorre devido a falta do campo User-agent nos headers da requisição. Para que possa corrigir este cenário, informe nos headers o campo User-Agent Exemplo: User-Agent : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 Precisando de auxílio estamos à disposição.

Olá Dev, como vai? Em nossos posts anteriores, entendemos um pouco sobre o processo de Onboarding em uma empresa, como estruturamos…. Até o momento, temos todo um processo mapeado onde o cliente terá uma atenção durante todo o seu processo de utilização. Mas, quem irá atuar nestes acompanhamentos? Para que o processo possa fluir, precisamos escalar uma pessoa para atender as necessidades dos clientes, para isso, é recomendado que seja escalado uma pessoa que tenha um nível de conhecimento alto sobre o que será acompanhado e também analisar se esta pessoa possui as características para repassar conhecimento e conversar com outras pessoas. Precisamos disso, pois, precisamos levar em consideração que o cliente final não tem conhecimento algum de como será utilizado, para isso, esta pessoa responsável precisar ser o mais claro possível. Caso precisem de algo, estamos à disposição.

Olá Dev, como vai? Em nosso post anterior entendemos o que seria o processo de Onboarding, caso não tenha visualizado, deixo o link caso tenha curiosidade: Para que serve o Onboarding? Entendemos o que é este processo, mas como posso estar utilizando em minha empresa? Primeiramente, precisamos analisar o produto que está sendo ofertado ao cliente, quais as etapas ele precisa seguir para que a utilização do produto seja realizada? Tendo isso estruturado, você já pode montar um passo-a-passo de acompanhamento. Podemos exemplificar com o cenário a seguir: realizamos a venda de um componente, onde o cliente precisa desenvolver para ser utilizado as funcionalidades. O que eu preciso fornecer para que o desenvolvimento ocorra? Documentação; Vídeos explicando o processo de utilização; Como ele(a) estará buscando auxílio; marcar reuniões para esclarecer dúvidas; Ótimo, já temos um norte, agora precisamos acompanhar se o que passamos do principal fluxo está correndo tudo bem. Se surgir dúvidas, estaremos à disposição.

Olá Dev, tudo certo? Para este post comentaremos um pouco sobre o processo de Onboarding nas empresas. Afinal, o que seria este processo? Para que serve? O Onboarding nada mais é do que um processo de acompanhamento de algo contratado pelo cliente, onde são dadas todas as orientações necessárias para que este cliente tenha uma boa experiência na utilização do produto, onde estaremos sempre a disposição e dando o “Norte”. Podemos exemplificar em uma empresa de Tecnologia. Ao realizar a contratação de um produto, há todo um fluxo por trás, onde acompanhamos a evolução do cliente durante o desenvolvimento da aplicação. Neste processo, identificamos se há algo travado na evolução, caso haja, o Onboarding estará lá para dar todas as orientações ao cliente. Caso tenha alguma dúvida, estaremos à disposição.

Olá Dev, tudo certo? Para este post, comentaremos um pouco sobre a rejeição no boleto Formato do Código de Estação inválido. Formato: X(04) Esta rejeição retornada para o boleto, se refere a uma comunicação de forma instantânea junto ao banco Santander. Para entendermos melhor sobre a rejeição, precisamos entender ao que se refere este código. Este código de estação nada mais é do que uma identificação que o banco Santander gera para identificar cada um dos seus clientes, que utilizarão o registro via webservice. Entendendo este código, podemos comentar sobre a rejeição. Ela nada mais é do que uma informação que esta indo de forma incorreta ao banco, onde eles não identificam este código. De acordo com a própria mensagem entendemos que há de errado ocorreu com este código, mas e este formato? Este formato nada mais é do que a limitação de campos que serão aceitos pelo banco, ou seja em um campo alfa numérico indicado pela letra 'X' e o valor 04 indicando quantas posições este código deve ter. Para corrigi-lo, será necessário que entre em contato com o seu gerente de contas, para que seja analisado qual seria realmente o código aguardado pelo sistema bancário. Após a correção, insira este novos dados e emita um novo boleto. Em caso de dúvidas, estamos a total disposição.

Olá Devs, tudo certo? Para este post, estaremos comentando um pouco sobre a VAN bancária, ou a transmissão automática de arquivos e retorno. VAN (Value Added Network) é um simples processo de automação, onde as empresas podem estar contratando para facilitar os meios de comunicação bancária, ou seja, os envios dos seus arquivos ficam mais simples e totalmente automatizados. Qual a vantagem? Em um processo "Manual" de envio dos arquivos, será disponibilizado o conteúdo e em seguida será necessário acessar o internet banking para realizar o upload dos seus arquivos. Já com a VAN, este processo deixa de existir, pois, todos os arquivos processados através da aplicação, terão um envio automatizado para a instituição bancária. Em nossas APIs PlugBoleto e Pagamentos, disponibilizamos esta funcionalidade para tornar o seu ERP mais automatizado, ou seja, a TecnoSpeed realizará uma comunicação direta com a instituição bancária para os envios de remessas e também para a recepção dos arquivos de retorno, tornando o seu fluxo de conciliação mais fácil. Caso tenha mais curiosidade sobre este processo, estaremos a disposição. Abraço.

Olá desenvolvedor(a) Neste post estaremos comentando sobre a rejeição apontada no registro via webservice do banco Sicredi: 20001 - ORA-20001: ECCRL0238 : Título já cadastrado Como já comentado em outros post relacionado ao banco Sicredi para o tratamento do nosso número no banco. Este sequencial se relaciona ao identificador único de um boleto que esta sendo registrado junto ao sistema bancário, ou seja, este sequencial precisa ser único e exclusivo do boleto. Para mais detalhes, clique aqui Tendo as informações do que é o nosso número, o banco possui algumas validações para impedir que o mesmo boleto seja registrado. Junto a utilização do registro via webservice do Sicredi, quando retornado a rejeição, estará informando da seguinte forma: 20001 - ORA-20001: ECCRL0238 : Título já cadastrado Apesar do tamanho da rejeição, o banco esta apenas retornando para o emissor, de que este boleto não pode ser registrado, pois um boleto com o mesmo nosso número foi registrado no sistema bancário. Para evitar esta rejeição junto ao banco, é aconselhado a verificações de qual sequencial do nosso número esta aguardando, e a partir deste valor, os próximos boletos tenham o valor incrementado. evitando assim a rejeição de duplicidade do boleto. Em caso de dúvidas, estamos a total disposição.

Olá desenvolvedor(a)! Neste post estarei comentando sobre o processo de validação dos arquivos de remessa. Para entendermos este processo, a grande parte dos bancos solicitam que seja enviados alguns arquivos de teste contendo um boleto para que eles possam estar verificando se todos os dados estão de acordo com o que foi parametrizado no cadastro e que esta sendo aguardado pelo sistema bancário. Este processo de validação é de extrema importância estar sendo realizado, pois isso acusa possíveis rejeições e inconsistências que os arquivos podem ter, e evita que estes erros sejam transferidos para o ambiente de produção. Para a realização deste processo, o banco encaminha algumas requisições para que seja encaminhado a eles. Em média é solicitado 10 arquivos de remessa, e 10 PDF de impressão, para boletos diferentes, para que seja feita as devidas validações nos dados que serão encaminhados nos arquivos. Relacionado aos arquivos de remessas, os bancos tem como padrão os layouts 240 e 400. Ou seja, para cada layout será feito um tipo de validação de acordo com o que é esperado pelo sistema bancário. Atualmente a TecnoSpeed trabalha com mais de 30 bancos homologados, onde realizamos algumas pré-validações em possíveis campos onde os bancos podem acusar as rejeições, permitindo que seja corrigido antes mesmo de estar encaminhando este arquivo ao banco, evitando o tempo padrão de processamento do banco de até um dia útil. Qualquer dúvida, estamos a disposição.

Olá Desenvolvedores. Este post estará comentando sobre a rejeição retornada pelo banco do Brasil: Entrada Rejeitada, Entrada para Título já Cadastrado Esta rejeição acusada pela instituição bancária, ocorre pois já contém um boleto com a mesma identificação do nosso número, registrado na base de dados do banco. Relacionado ao nosso número, esta identificação faz com que os bancos tenham o controle sobre os registros de cada título encaminhado via remessa, ou através do registros instantâneos Como evito esta rejeição? Para evitar esta rejeição, o indicado seria realizar a automação de incremento deste valor, para cada boleto emitido no sistema, ou até mesmo cadastrar junto ao banco a carteira escritural, para que o baco realize este controles internamente. Outra dica, é sempre averiguar junto ao seu gerente de contas, qual o próximo sequencial a ser registrado. Pois assim, a sequencia de registros irá estar de acordo com o solicitado. A TecnoSpeed pode me auxiliar com este controle? Sim, em nosso produto PlugBoleto, possuímos um controle onde não iremos permitir a emissão de um boleto contendo o mesmo nosso número, vinculado a conta emissora. Ou seja, o risco de rejeições por duplicidade do nosso número é reduzido. Caso tenha alguma dúvida, estaremos a disposição.

Olá desenvolvedor! Neste post estrei comentando sobre os arquivos de retornos disponibilizados pelo banco após o processamento do seu boleto. Um retorno basicamente se refere a todos os dados que o banco processou internamente, retornando assim as informações para o boleto, como por exemplo: - Se o seu boleto foi registrado com sucesso; - Se o boleto foi processado pelo banco, porém rejeitado por alguma inconsistência; - Os dados de liquidação do boleto, caso tenha sido pago; Entendendo o que é este arquivo Para podemos seguir para a análise do mesmo é necessário entender a estrutura do arquivo de retorno, que é dividido em linhas e posições pré-definidas. O primeiro passo é identificar qual o banco e CNAB que está sendo utilizado. Isto é facilmente identificado olhando os 3 primeiros dígitos do arquivo, e a quantidade de caracteres em cada uma das linhas. Usaremos como base um arquivo da Caixa, CNAB 240. Pesquisaremos no site do banco pela documentação da remessa, e ao localizarmos, procuraremos no manual as informações das tabelas de "Retorno", conforme imagem abaixo: Agora, com o manual em mãos, basta localizar nele a informação que desejamos, e junto ao arquivo buscar as informações. No layout da Caixa CNAB 240, podemos ver que as informações do retorno encontram-se no "Segmento T" e "Segmento U" do arquivo de retorno. Agora, iremos até as tabelas com as descrições de cada campo para localizar as informações que desejamos. Como exemplo, vamos supor que desejamos saber qual o valor pago por um determinado boleto. Portanto, de acordo com a documentação, procuraremos o campo "Valor Pago pelo Pagador", que se encontra nas posições 78 a 92 do segmento U. Faremos isso para cada campo que você deseja fazer a leitura. Ou seja, identificamos no manual a posição em que se encontra a informação, e na sequência, fazemos a leitura da mesma no arquivo de retorno. É importante lembrar que apesar deste layout variar bastante entre cada banco e entre cada CNAB, a lógica por trás é sempre a mesma: precisamos localizar no manual as informações que queremos, e na sequencia, fazemos a leitura no arquivo disponibilizado pelo banco. Como posso facilitar esta verificação? Nossa aplicação de emissão de boletos possui toda a leitura do retorno para diferente bancos homologados, sendo necessário apenas a inclusão deste arquivo em nossa aplicação. Com isso será feito uma leitura de todos os campos necessários para que você apenas consulte o seu boleto emitido, para ter acesso aos movimentos e ocorrências do boleto. Caso tenha alguma dúvida, estamos a disposição.

Olá Desenvolvedor! Neste post estarei comentando sobre as notificações via Webhook. O que é um webhook? Um webhook nada mais é do que uma notificação em tempo real voltada a eventos, ou seja, assim que for identificada alguma alteração em determinada informação, é possível encaminhar estas alterações juntamente dos dados que achar necessário ao cliente, como por exemplo, uma notificação de registro de um boleto, onde você será notificado, quando o boleto assumir uma situação pré-definida e esperada pelo seu sistema. Por que utilizar este recurso? Este modelo de notificação pode ser muito útil para as APIs, permitindo um controle de informações maior, como por exemplo identificar se um boleto foi pago. A utilização do webhook pode lhe trazer um automação maior ao seu sistema, sem a necessidade de verificar se houve alguma alteração. A TecnoSpeed possui este modo de envio das notificações? Sim, nos da TecnoSpeed temos desenvolvido em nossa aplicação o envio de notificações via webhook, e ela é bastante útil em clientes que utilizam a "Transmissão automática das remessas e retornos". Nesta forma de registro, o envio das remessas e recepção dos retornos é feita automaticamente pela Tecnospeed, sem necessidade de operações manuais dos clientes. E é neste fluxo que o webhook é bastante interessante, pois, em nossa integração é possível configurar um webhook quando o arquivo de retorno for recepcionado por nós, vindo do banco, ou seja, conseguimos notificar as Software Houses sempre que um boleto é Liquidado, por exemplo, ou caso ele assuma qualquer outra situação. Desta forma, a Software House não precisa consultar diariamente todos os boletos que possuem, basta apenas aguardar a nossa notificação, indicando que houve alguma atualização em seus boletos! Para alguns exemplos que a nossa aplicação pode estar encaminhado ao seu servidor, temos uma lista, clicando aqui Caso tenha alguma dúvida, estamos a disposição.

Olá Desenvolvedor! Neste post, estarei comentando sobre a espécie do documento na qual é necessário informar ao gerar um boleto. A espécie do documento ou espécie do título listado em alguns manuais, esta referindo-se a qual será o tipo de cobrança do título que o cedente estará emitindo para o pagamento. Relacionado a estas espécies, são disponibilizados diversas siglas e códigos para a inclusão em um boleto. Podemos destacar algumas utilizadas para estas emissões: DM - Duplicata mercantil: um título de crédito em que o comprador se obriga a pagar dentro do prazo a importância representada na fatura, este prazo precisa ser igual ou superior a 30 dias. DR - Duplicata Rural: vendas a prazo de quaisquer bens de natureza agrícola, extrativa ou pastoril, quando efetuadas diretamente por produtores rurais ou por suas cooperativas, poderá ser utilizada também, como título do crédito NP - Nota promissória: é um documento que funciona como promessa de pagamento de uma dívida. NF - Nota Fiscal: um documento oficial que registra as vendas da sua empresa. Estas espécies precisam ser utilizadas de acordo com o tipo de documento que for emitido para o seu pagamento, ou caso o seu banco solicite uma espécie em especifico. Pois ela irá garantir a segurança e também qual a finalidade deste boleto. Visando uma padronização, a TecnoSpeed possui diversas espécies homologadas na aplicação, sendo necessário apenas informar o código mapeado e iremos realizar a conversão para o formato que o seu banco aceite. Temos disponível também todas as espécies mapeadas em uma documentação, tendo como objetivo uma facilidade de integração dos seus boletos: https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360014970654-Espécie-do-documento Caso tenham alguma dúvida, estamos a disposição.