Sistema, kuri iš nufotografuotos sąskaitos ar CMR padaro paruoštą importą į buhalterinę programą.
Rašau ją vienas. Repo aplankas vadinasi invisible-extractor, nes taip pavadinau pradžioje ir nekeičiau.
Vežėjas su 15 iki 40 vilkikų per mėnesį gauna kelis šimtus popierinių dokumentų. Sąskaitos, CMR, kuro kvitai. Jie ateina kaip nuotraukos iš kabinos, suglamžyti skenai ir PDF, dažnai po kelių dienų.
Tada kažkas juos perrašinėja ranka. Tiekėjas, dokumento numeris, data, suma be PVM, PVM, iš viso. Dvi iki keturių minučių už dokumentą. Ten atsiranda klaidos, ir ten dingsta laikas.
nuotrauka arba PDF
-> OCR
-> parseris ištraukia laukus
-> validatoriai patikrina
-> .EIP importas į Rivile
arba
-> žmogaus peržiūros eilė, jei kas nors nesueina
Demo dokumentas: numestas į stebimą aplanką, rezultatas archyve po 31 sekundės, visi laukai teisingi.
Ištraukia: tiekėją, kliento kodą, dokumento numerį, datą, sumą be PVM, PVM, bendrą sumą, valiutą,
eilutes. Išveda Rivile GAMA .EIP, i.SAF PVM žurnalą, i.VAZ e. važtaraštį ir eFTI.
Modelis neliečia skaičių. Modelis verčia vaizdą tekstu. Viską po to daro paprastos taisyklės: suma be PVM plius PVM turi lygti bendrai sumai, data turi būti reali, tiekėjas turi rastis kliento sąraše, PVM tarifas turi būti teisėtas.
Taip padariau, nes buhalterė turi galėti pasakyti, iš kur atsirado skaičius. „Modelis taip nusprendė" nėra atsakymas nei jai, nei mokesčių inspekcijai.
Abejotinas dokumentas eina žmogui, ne į eksportą. Jei nepraeina bent viena taisyklė, dokumentas keliauja į peržiūros eilę su parašyta priežastimi lietuviškai. Ne su procentu, ne su „low confidence", o su sakiniu, ką tiksliai reikia pataisyti.
OCR sukasi lokaliai.
Kliento buhalterija neišeina iš kliento. Naudoju deepseek-ocr per Ollama. Debesų OCR būtų buvę
paprasčiau, bet tada dokumentai keliautų pas trečią šalį.
Gaudo dublikatus ir pasikeitusį IBAN. Tą patį dokumentą atsiuntus du kartus, antras nueina į šoną. Jei tiekėjo IBAN skiriasi nuo praeitos sąskaitos, sistema tai pasako. Tai dažniausia sąskaitų sukčiavimo forma vežėjų srityje.
Sistema turi stebimą aplanką ir raktu užrakintą HTTP endpointą, todėl ją galima iškviesti vienu žingsniu iš n8n arba Power Automate:
n8n / Power Automate -> numeta failą į stebimą aplanką
Vairas -> OCR, parseris, validacija
n8n / Power Automate -> paima rezultatą, įrašo eilutę, praneša
Be rakto endpointas atsako 404, su neteisingu raktu 403.
| Sluoksnis | Kas |
|---|---|
| Skaitytuvas | deepseek-ocr per Ollama, lokaliai |
| Backend | Python, FastAPI |
| Duomenys | SQLite, atskira kiekvienai įmonei |
| Programa | Tauri |
| Eksportai | Rivile GAMA .EIP, i.SAF, i.VAZ, eFTI, Peppol |
Nėra realių klientų. Sistema veikia su demo įmone, pravaryta per visus ekranus, testai žali, bet prieš pirmą tikrą klientą reikia duomenų tvarkymo sutarties. Man 17, todėl ją turės pasirašyti suaugęs. Tai popierių, ne kodo, klausimas.
Ranka rašyto teksto nė vienas modelis iki 20 GB neskaito patikimai, todėl ranka rašyti dokumentai visada eina į peržiūrą, o ne spėjami.
py -3.12 -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -r requirements-dev.txt
ollama pull deepseek-ocr
.\.venv\Scripts\python.exe tools\gate.py # testai, lint, teksto taisyklės
powershell -File tools\start_demo.ps1 # visas stackas su demo įmonetools/gate.py yra vienintelis „žalia" apibrėžimas. Praleistas testas nėra praėjęs testas.
Kodas viešas, kad būtų galima perskaityti. Naudoti negalima, žr. LICENSE.
Klausimai: domantas.kazl@gmail.com