A Little Background
Recently, I encountered a "problem" reported in an application. The barcode reader wasn't working correctly—the value it captured was different from what was on the document. In this article, I'll share the journey I took to understand and resolve this issue.
Spoiler: The problem was related to a specific rule in barcode generation set by FEBRABAN, the Brazilian Federation of Banks, so the issue might be more relevant to the Brazilian context, but it might still offer some valuable insights. Let's dive in!
The Problem
As mentioned, the value captured by the camera was always different from what was on the document. Up until that point, the issue seemed to be with the application, because when we manually entered the number, our backend worked just fine.
With the document below, we can simulate the problem.
Reading Result:
Captured by the camera:
84620000001468501622024081048000000800872166
The difference lies in the check digits. Take a look:
846200000012468501622020408104800003008008721667
For a while, I thought the issue was with the reader itself, or perhaps the quality of the device's camera. Interestingly, the reader worked with other documents, but not with this specific type. After various attempts, I accepted that the problem might be in the application and started digging deeper.
Hypotheses and Investigations
The package we were using for barcode reading was qr_mobile_vision. I experimented with alternatives like simple_barcode_scanner and flutter_barcode_scanner, but all of them had limitations in customizing the camera display, and they all suffered from the same reading issue. Not seeing an obvious solution, I decided to delve into the qr_mobile_vision package.
I discovered that qr_mobile_vision uses Firebase's ML Kit to read codes. After exploring the documentation and running tests, I identified that the barcode type for this document is ITF. Without enabling this type, the reader would not capture anything.
So I dug deeper and ended up finding a sample project from Google using ML Kit, but the same reading issue occurred. That's when I started to question whether the problem was actually with the reader.
A Light at the End of the Tunnel
As my research progressed, I started to consider that the issue might not be within our app. I investigated how these documents are generated and found the document "Layout Padrão de Arrecadação/Recebimento com Utilização do Código de Barras" (Standard Layout for Collection/Receipt Using Barcodes).
I learned something important:
Number Position | Number of Characters | Meaning
01 – 01 | 1 | Product Identification
02 – 02 | 1 | Segment Identification
03 – 03 | 1 | Identification of the Real Value or Reference
04 – 04 | 1 | General Check Digit (module 10 or 11)
05 – 15 | 11 | Value
16 – 19 | 4 | Company/Agency Identification
20 – 44 | 25 | Free Field for Company/Agency Use
I noticed that none of these fields mention check digits. In the following pages of this document, there's an explanation of how to calculate them, and that's where I cracked the case: The highlighted values above weren't read because they weren't present in the barcode, not due to an issue with the package, device, or operating system.
Solution
After discussing the root cause with the leadership, we agreed that the backend would receive the information as read by the camera and handle the verification logic on their side.
Conclusion
It was quite an adventure to reach the solution to this problem, but I learned a lot along the way. I hadn't found many resources on this specific issue in the Brazilian banking system at the time of writing this article, but I hope it helps anyone facing a similar challenge.
That's it, folks. Thanks for reading!
Top comments (0)