Um pouco de contexto
Recentemente, me deparei com um "problema" relatado em uma aplicação. O leitor de código de barras não estava funcionando corretamente: o valor lido era divergente do que constava no documento. Neste artigo, vou compartilhar um pouco dessa jornada para entender e resolver a questão.
Spoiler: O problema estava relacionado a uma regra específica na geração de códigos de barras da FEBRABAN (Federação Brasileira de Bancos). Portanto, o caso pode ser mais relevante para o contexto brasileiro, mas talvez possa oferecer insights valiosos para você. Vamos lá!
O problema
Como mencionado, o valor capturado pela câmera era sempre diferente do informado no documento. Até aquele momento, a culpa parecia ser da aplicação, já que ao digitar manualmente o número, nosso backend funcionava corretamente.
Veja um exemplo:
Documento
Resultado da leitura:
84620000001468501622024081048000000800872166
A diferença está nos dígitos verificadores. Veja só:
846200000012468501622020408104800003008008721667
Por um bom tempo, achei que o problema era do leitor ou até da qualidade da câmera do dispositivo. Curiosamente, o leitor funcionava com outros documentos, mas não com esse tipo específico. Após diversas tentativas, aceitei que o problema poderia estar na aplicação e comecei a investigar mais a fundo.
Hipóteses e investigações
O pacote utilizado para leitura era qr_mobile_vision. Experimentei alternativas como simple_barcode_scanner e flutter_barcode_scanner, mas todos apresentavam limitações na customização da exibição da câmera, além de sofrerem do mesmo problema de leitura. Sem encontrar uma solução óbvia, decidi me aprofundar no pacote qr_mobile_vision.
Descobri que o qr_mobile_vision utiliza o ML Kit do Firebase para realizar a leitura de códigos. Após explorar a documentação e realizar testes, identifiquei que o tipo de código de barras desse boleto é ITF. Sem habilitar esse tipo, o leitor não capturava nada.
Então fui mais fundo e acabei encontrando um projeto exemplo do Google usando o ML Kit, mas o mesmo problema de leitura ocorreu. Foi então que comecei a questionar se o problema realmente estava no leitor.
Uma luz no fim do túnel
Conforme as pesquisas avançavam, comecei a considerar que o problema poderia não estar na nossa aplicação. Investiguei como esses documentos são gerados e encontrei o documento “Layout Padrão de Arrecadação/Recebimento com Utilização do Código de Barras”.
E nele aprendemos algumas coisas bem legais:
Posição dos números | Quantidade de caracteres | Significado
01 – 01 | 1 | Identificação do Produto
02 – 02 | 1 | Identificação do Segmento
03 – 03 | 1 | Identificação do valor real ou referência
04 – 04 | 1 | Dígito verificador geral (módulo 10 ou 11)
05 – 15 | 11 | Valor
16 – 19 | 4 | Identificação da Empresa/Órgão
20 – 44 | 25 | Campo livre de utilização da Empresa/Órgão
Percebi que em nenhum desses campos é mencionado os dígitos verificadores. Nas páginas seguintes do documento, há uma explicação de como calculá-los, e foi aqui que descobri o ponto-chave: os dígitos destacados acima não foram lidos porque não estavam presentes no código de barras, e não devido a um problema no pacote, dispositivo ou sistema operacional.
Solução
Após alinhar com a liderança sobre a causa do problema, decidimos que o backend receberá a informação como foi lida pela câmera e realizará as lógicas de verificação necessárias.
Conclusão
Foi uma aventura e tanto até chegar à solução deste problema, mas aprendi bastante durante o processo. Não encontrei muitos recursos sobre esse problema específico do sistema bancário brasileiro, mas espero que este artigo possa ajudar quem estiver passando por algo semelhante.
É isso, pessoal. Tmj e vlw!
Top comments (0)