Scanarea actului de identitate de pe telefon nu mai rămâne blocată

Într-un centru de reciclare, predarea deșeurilor de la o persoană fizică cere identificarea ei: numele, CNP-ul, adresa trec pe documentul de predare, așa cum cer regulile. Varianta clasică e greoaie: operatorul citește manual actul de identitate și transcrie datele, cu tot riscul de eroare pe care îl are orice transcriere sub presiunea unei cozi de clienți.

În VanaGreen, pasul ăsta se face de pe telefon: operatorul fotografiază actul, iar un motor OCR (recunoaștere optică de caractere) citește automat numele, CNP-ul și adresa, direct în formular. Nu e nevoie de un scanner dedicat sau de un dispozitiv suplimentar de întreținut. Telefonul pe care oricum îl are la el face treaba.

Ce se strica, de fapt

De curând, funcția asta a primit deja o reparație. Motorul OCR rula printr-o bibliotecă externă (tesseract.js) care își descărca fișierele de recunoaștere de pe un CDN public, iar politica de securitate a serverului bloca acele cereri. Rezultatul era un eșec tăcut, la fiecare scanare. Am rezolvat asta găzduind motorul complet local, fără nicio dependență de rețea externă, o decizie fermă pentru orice atinge date personale ca actul de identitate.

Odată reparat pasul ăsta, a apărut o problemă nouă, mai subtilă: scanarea funcționa, dar putea rămâne blocată la nesfârșit pe mesajul „Se citesc datele…". Nu era o eroare afișată, era o adevărată înghețare a ecranului. Testat live, în condiții deliberat nefavorabile (poză pe orizontală, făcută rapid, fără grijă la cadru), telefonul rămânea agățat acolo, iar singura soluție era să închizi și să reiei scanarea de la zero.

De ce se întâmpla

Doi factori se combinau. Primul: o poză făcută direct cu camera telefonului are, de regulă, 3000-4000 de pixeli pe lățime și câțiva megabytes, mult mai mult decât are nevoie motorul de recunoaștere ca să citească textul. Cu o poză atât de mare, motorul (care rulează integral în browser, prin WebAssembly) putea să macine mult mai mult timp decât normal, uneori fără să mai termine deloc.

Al doilea factor era lipsa unui plafon de timp. Aplicația aștepta pur și simplu ca operația de citire să se termine. Dacă nu se termina niciodată, nici aplicația nu avansa. Nu exista niciun mecanism care să spună „gata, am așteptat destul, mergem mai departe".

Ce s-a schimbat

Rezolvarea are două părți, gândite să lucreze împreună. Înainte ca poza să ajungă la motorul de recunoaștere, aplicația o redimensionează automat, la maximum 1800 de pixeli pe latura lungă, suficient pentru ca textul să rămână lizibil, dar mult mai rapid de procesat. Ca beneficiu secundar, redimensionarea corectează și orientarea pozei (o poză făcută pe lateral nu mai ajunge cu pixelii răsuciți la motorul de citire).

A doua parte e un timeout explicit de 20 de secunde: indiferent ce se întâmplă cu recunoașterea propriu-zisă, operatorul ajunge garantat la ecranul de confirmare în cel mult 20 de secunde de la momentul scanării. Dacă motorul a reușit să citească datele, ele apar precompletate; dacă nu, operatorul le introduce manual, fără să fi pierdut timp așteptând un ecran înghețat.

De ce contează pentru un operator

Diferența nu se vede în cifre mari, ci în frecvența cu care se întâmplă. Scanarea actului de identitate e un pas zilnic, la fiecare predare de la o persoană fizică. Un blocaj ocazional, chiar dacă rezolvabil prin reluare, înseamnă coadă la centru, un operator frustrat și, la limită, tentația de a renunța la scanare și de a reveni la transcrierea manuală, exact ce funcția asta trebuia să elimine.

Cu redimensionarea automată și timeout-ul de siguranță, scanarea de pe telefon devine ce trebuia să fie de la început: un pas rapid și previzibil, indiferent cât de bună sau de proastă e poza făcută în grabă la ghișeu.