Portál AbcLinuxu, 30. dubna 2025 12:53
Už jsem podobné řešení viděl jinde, takže mne to ani moc nepřekvapuje, ale neodpustím si komentář: myslím, že tohle pěkně ukazuje, jak jde současný svět do prdele – máme rychlé připojení k Internetu resp. propojení skoro všech počítačů na planetě, máme rychlé mnohajádrové procesory, terabajtové disky, spousty GB operační paměti… a co s tím děláme? Tiskneme a posíláme si papírové faktury, zaměstnáváme člověka, který je strká do skeneru, OCRkujeme, rozpoznáváme čárový kód (který jsme předtím vytiskli a nalepili) a pak to stejně asi někdo opisuje z bitmapy do formuláře nebo minimálně kontroluje jestli se to OCRkovalo správně… Místo aby jedna firma poslala druhé třeba jednoduché XMLko opatřené elektronickým podpisem, na druhé straně se to automaticky spárovalo s objednávkou a automaticky nebo ručně schválilo a zadal se automaticky příkaz k proplacení. Tohle se mohlo dělat už v devadesátých letech na 486kách nebo dřív, kdyby lidi nebyli blbci a nepoužívali počítače jako psací stroje.
Místo aby jedna firma poslala druhé třeba jednoduché XMLkoNekdo uz zminil ten EDIFACT, tedy presne to co pisete. Je to bohuzel nezaplatitelne a kdo to nekdy zavadel vi, jak komplikovana zalezitost to je. Bezna praxe dnes je, ze mala firma posila i nadale papirovou fakturu a 'specializovany prostrednik' ma lidi, kteri to prectou a vytvori ta strukturovana data a ty pak posilaji dal. To samozrejme take neco stoji a zazil jsem pripady, kdy firma obchod s nejakym zakaznikem radeji vzdala, nez by platila tu 'infrastrukturu' pri zasilani faktury.
na druhé straně se to automaticky spárovalo s objednávkoutohle vyzaduje umelou inteligenci - to je proste v praxi u vetsiny firem nemozne. Jeste tak v pripadech, kdy je predmetem obchodu jedna polozka.
tohle vyzaduje umelou inteligenci - to je proste v praxi u vetsiny firem nemozne. Jeste tak v pripadech, kdy je predmetem obchodu jedna polozka.
Co mi chodí faktury (i od celkem malých obchodů) tak tam bývá kromě čísla faktury i číslo objednávky1, takže bych si to v pohodě spárovat mohl. A v ISDOCu je taky políčko pro odkaz na objednávku – příklad:
<OrderReferences> <!--Nepovinná hlavičková kolekce objednávek pro případnou vazbu --> <OrderReference> <!--Objednávka #1--> <SalesOrderID>OP-111222/2008</SalesOrderID> <!--Vlastní ident. objednávky přijaté u dodavatele--> <ExternalOrderID>OV-123111/2008</ExternalOrderID> <!--Ext.č.obj.přijaté, typicky obj.vydaná odběratele--> <IssueDate>2008-01-03</IssueDate> <!--Datum vystavení objednávky přijaté u dodavatele--> </OrderReference> <OrderReference> <!--Objednávka #2--> <SalesOrderID>OP-111223/2008</SalesOrderID> <ExternalOrderID>OV-123112/2008</ExternalOrderID> <IssueDate>2008-01-20</IssueDate> </OrderReference> </OrderReferences>
A pak jsou případy, kdy chodí faktury bez objednávky2 – např. pravidelné účty za elektřinu nebo telefon – a tam zase stačí nastavit pravidlo, že pokud se částka vejde do nějakého měsíčního limitu, tak se faktura automaticky schválí a zaplatí, jinak to dostane někdo k ručnímu schválení/revizi.
Tragikomické na tom je, že všechny potřebné údaje v těch počítačích máme, často i ve strojově čitelné formě v nějaké databázi, jen se pak cestou ta informace ztratí, převede na strojově nečitelnou – a pak se to na druhé straně musí zase pracně převádět zpět, aby tomu druhý informační systém rozuměl.
[1] které znám, protože jsem to objednával, akorát ho nemám zanesené v žádném systému, protože toho je málo a řeším vše ručně
[2] resp. tam zase může být číslo smlouvy, podle kterého se to spáruje
Otázka je jak bude vypadat trh práce, když zničehonic příjdou o práci stovky opisovačů
zbar - http://zbar.sourceforge.net/ - čtení čárových kódů mnoha typů. Umí číst jak ze souboru, tak ze zařízení (webkamera). Jednou dobou jsem webkamerou scanoval QR kódy z Androidu a funguje to na jedničku. Má to GUI, ale může běžet i v konzoli. Buď se ukončí po přečtení prvního kódu, nebo čte kontinuálně (natočím webkameru na další kód a ten se vypíše na konzoli).
Konkrétně QR kód jsem zkoušel vytisknout, naskenovat a předat obrázek programu. Pod 200dpi byly občas problémy se čtením, při 300dpi fungovalo čtení na jedničku i když jsem QR kód přečmáral propiskou. Myslím že by stálo za pokus zařadit do cesty imagemagick a skenovat jen výřez místa, kde by měl být kód - zbaru chvilku trvalo, než se tím obřím souborem prokousal.
K požadavkům:
- zbar, volitelně imagemagick
- imagemagick
- grep, wc, možná sed
....a všechno samozřejmě poslepovat pořádným lepidlem - BASH.
a nešlo by ty dokumenty dělit prostě jen podle toho prefixu. To OCR by mohlo rozeznávat znaky lépe než čárový kód, píšete, že jste omezili identifikační oblast, takže by mělo jít jen o dostatečně exotický prefix.
Jinak, to dělení dokumentu je fakt dobrá finta.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.