DMS : Nasazení OCR BarCode software

21.2.2014 16:29 | Přečteno: 1539× | plky | poslední úprava: 14.9.2014 14:50

Před delší dobou bylo nasazeno DMS jedné firmy. Požadavky byly, aby šlo propojit se SAPem a s naším IS, umělo podepisovat dokumenty, umožňovalo workflow (hlavně pro schvalování faktur) a v poslední řadě také automatizované zpracovávání naskenovaných faktur.

Princip vkládání faktur do DMS

Máme faktury a faktury mívají přílohy. Proces importu faktur do DMS je následovný :

• Slečna přilepí na každou fakturu do pravého horního rohu čárový kód a vytvoří "prázdný" záznam v DMS systému.
• Faktury se musí seskládat, aby šlo za sebou faktura+přílohy+faktura+přílohy. Ve finále má tedy slečna kopičku, kde je faktura s kódem ABC00001, pod ní jsou tři přílohy, pod nima je faktura s kódem ABC00002 a pod ní přílohy k té faktuře atd.
• Kopičku vloží do skenu (Canon DR-M160) a dá naskenovat, výsledkem je vícestránkový tiff s více fakturami a přílohami, které jdou pěkně za sebou tak, jak si to předtím slečna seskládala. Skenuje se v 300dpi, v 200dpi bývá občas problém detekovat správně čárový kód (obzvláště, když je pootočený)
• Výsledný tiff si slečna může prohlédnout, zda je vše ok a následně spustí baťák, který soubor přesune na sdílěný disk.
• Když dojde k úspěšnému přesunu tiff souboru na vzdálený disk, tak tam běží File Watcher Simple, který reaguje na změny v adresáři. Jakmile tedy dojde k vytvoření, nebo přejmenování na tiff, tak se spustí QuickScan, což je OCR SW (údajná cena na jeden PC asi kolem 20kkč), který umí číst čárové kódy z tiffu.
• QuickScan čte tiff, jakmile narazí na čárový kód, tak vytvoří nové pdf a do něj láduje všechny ostatní stránky dokud nenarazí na další čárový kód. Výsledkem jsou tedy pdf soubory a každý pdf soubor obsahuje fakturu a všechny její přílohy + se soubor jmenuje podle čárového kódu
• PDF soubor je vytvořen v adresáři, který checkuje script DMS systému (resp. na oracle se spouští job v nějakých intervalech a čumí do toho adresáře) a pdf z něj načítá a láduje/páruje je podle jména souboru do DMS.
• Spárovaný dokument je následně posílán do workflow a začne procházet procesy schvalování apod.

PDF jde k záznamu v DMS párovat i ručně, nebo načíst z PC. Celý proces vypadá docela složitě, ale na druhou stranu je mnohem jednodušší, jak kdyby vše kolovalo v papírové formě a je to rozhodně přehledné. Taktéž se do DMS ukládají dokumenty, které jsou v SAPu, nebo v našem IS. DMS tedy spíš nefunguje jako takový SharePoint, ale jako čistě backend pro uložiště dokumentů. Ona firma i konečně dodává plugin do MS Office, aby šlo dokumenty upravovat přímo z DMS (něco jako má SharePoint), prostě ťuknu ve web ksichtu na dokument, otevře se word, upravím ho a dám "commit to dms" a je tam včetně nové revize. Nojo, za toto chce ta firma asi 40kkč :), takže zatím fakt ne a nelze tedy DMS uživatelsky takovým způsobem používat, což je docela škoda :-/.

Problém s QuickScanem

Největší problém tohoto řešení je skenování dokumentů, resp. QuickScan. Tento sw dělá tři nemilé věci :

• Velikost výsledného pdf je 6x i víckrát větší, než původně naskenovaný tiff a nelze s ním moc hnout
• Když na stránce najde jiný čárový kód, tak ho načte. I přesto, že máme definován náš vlastní prefix. Tzn., že náš čárový kód začíná třeba ABC+číslo a on najde na dokumentu čárový kód XXXXXXXX a vyskočí varovné okno, abychom si vybrali ten správný. Díky tomu ten sw nemůže běžet na serveru, protože potřebuje takovouto uživatelskou pravidelnou akci :-/.
• Předchozí problém se částečně vyřešil tak, že se definovala oblast na dokumentu, kde má čárový kód hledat a ostatní části dokumentu ignorovat, tím se snížil počet kolizí, ale nějaké stále jsou. Horším problémem je to, že když nějaká příloha faktury obsahuje v tomto místě čárový kód, tak jej načte, založí nový soubor a na nic se už neptá (jelikož se nejedná o kolizi čárových kódů, tak ho prostě načte). Jinými slovy vzniká spousta nenapárovaných dokumentů a co je horší, výsledné "pravé faktury" neobsahují všechny přílohy, jelikož z nich se stala fake faktura s šíleným číslem a spadla do nenapárovných.

(program se spouští jako baťák s parametry : IF EXIST C:\scan-qs-dms\*.tif. ("C:\Program Files (x86)\EMC Captiva\QuickScan\QuickScn.exe" /scan profile=01-BW,overwrite=overwriteall))

Jinými slovy, QuickScan nám kazí celý proces. Náš dodavatel tvrdí, že se supportem není kloudná řeč, že to nehodlají opravovat a možná už se QuickScan nebude dál vyvíjet. Znají OCR sw, který toto umí, ale stojí třeba 40kkč i více.

Nabízí se tedy otázka, zda někdo nezná lepší způsob, jak toto řešit. Nebo zda někdo nezná "levnou" náhradu za QuickScan, popř. i opensourcovou? :). Já to vidím tak, že nám firma dodala nefunkční řešení (QuickScan), tudíž to je na jejich bedrech. Osobně ale neznám pozadí (smlouvy apod. věci), takže jelikož jsem byl požádán o návrh řešení (samozřejmě jsem reagoval ve stylu, že to by měla navrhnout ona firma), tak sonduji. Nevadí, když to bude placený pro win, nebo pro lin, hlavní je funkčnost a cena :). Samozřejmě bych dal přednost nějakému OSS řešení.

Požadavky tedy jsou :
- schopnost číst čárový kód (třeba i pootočený)
- na základě čárového kódu vyjmout z tiff souboru všechny stránky tak, jak jdou za sebou a převést je do pdf do té doby, než narazí na další čárový kód, poté vytvořit nový soubory zase do něj nasypat všechny stránky, co jsou za ním atd.
- umožnit filtrování čárových kódů (nejlépe tedy podle začátku - prefixu a podle délky, prostě tak, aby nedocházelo k neřešitelným kolizím)

Závěr

Pro zajímavost, přemýšlelo se jednu dobu i nad Alfresco DMS, který má SAP connector, ale jednak by to vyšlo ve výsledku asi i dráž, ale hlavně se hledělo na to, aby nám to byla schopna rozchodit nějaká firma, co s podobnými procesy má zkušenosti a má ověřené funkční řešení, tedy nic, co by někdo řešil za pochodu. Pokud by měl někdo dotazy v podobnéch duchu, tak věřte, že budou nezodpovězeny, jelikož já jsem malý červ a výběr řešení a další věci připadli někomu jinému, takže ani nevím, co vše bylo ve hře, z čeho všeho se vybíralo atd.

Zdar Max

UPDATE : Nedávno jsem pronikl do dalších postupů v účtárně a na fakturaci a zjistil, že díky nasazení DMS se objem tisku rapidně zvýšil, protože v účtárně už nepouštějí faktury z ruky a fakturantky tak musí vše z DMS tisknout a obíhat všechny uživatele, aby fakturu rozepsali, protože chtít to po nich v rámci DMS je prý nemožné. Stejně tak je 100x rychlejší kontrola faktury tak, že fakturantka si propiskou zkontrolované položky odškrtává, což v rámci DMS (pdf) nemá, tudíž by se brzo ztratila.        

Komentáře

[alfonz]

Tohle se docela často používá, je to hodně dobré v kombinaci s QRkódy. Umí to i ostatní. https://github.com/zxing/zxing

Při propojení s pdftk, přímým generování pdf a Pythonem, by neměl být problém to dát dohromady. A při propojení s RST2PDF by se to dalo ještě vylepšit o úvodní rozpoznané stránky s metadaty, případně uložit metadata do PDF.

[Max]

Ahoj, jsem rád, že jsi mi doporučil zrovna toto, jelikož jsem na tento projekt při googlování narazil. Původně jsem se díval na Tesseract, ale ve foru i ve FAQ mají napsáno, že je určen pro text, nikoli pro čárové kódy, ale někdo někde v diskusi právě doporučil "zxing".
Vím, že programů je tuna, ale funkčních už né tolik, proto sonduji, co se vyplatí vyzkoušet a co ne.
Zdar Max

[Josef Kufner]

Zxing má i aplikace pro Android na skenování QR kódů. Tu používám docela dlouho a funguje pěkně. Umí to i různé 1D čárové kódy, ale ty QR kódy se chytají snadněji a jsou méně náchylné na otáčení a zkosení.

Btw, zkoušeli jste používat barevné samolepky a před hledáním kódu začernit vše jiné než černou a zvolenou barvu?

[Max]

Jop, viděl jsem na jejich stránkách, že BarCode scanner je vlastně z tohoto projektu. Osobně taktéž používám.
Zdar Max

[Max]

Ohledně barevných samolepek. Jaký je rozdíl v tom, co popisuješ a v tom, že by skenovací slečna přelepila/přečmárla jiné čárové kódy nacházející se v danné oblasti? Tady jde o to, aby nemusela dělat ani ň navíc, protože těch papírů je obrovská kvanta.
Zdar Max

[stativ]

Možná se mýlím, ale řekl bych, že předřečník to myslel tak, že už samotný čárový kód by měl jinou barvu. Tj. teď slečna vezme černo-bílou nálepku s čárovým kódem a tu na fakturu nalepí. Po navrhované úpravě by slečna vzala černo-zelenou nálepku s čárovým kódem a tu nalepila. Tj. jediná změna by byla v tom, že čárové kódy by se netiskly na bílý papír ale na barevný.

[Josef Kufner]

Přesně tak.

[Max]

Tak to zní zajímavě, to bychom mohli zkusit.
Díky
Zdar Max

[sigma]

Bude třeba asi zkombinovat víc nástrojů. Na OCR čárových kódů už tu nějaký návrh byl. Samotné rozdělení TIFFu do několika PDF, když budu vědět čísla stránek z toho OCR, by mohl zvládnout i obyčejný imagemagick/convert, případně tiff2ps a ghostscript.

[David Kredba]

Dovolím si připomínku, ne "díky", ale "kvůli": Kvůli tomu ten sw nemůže běžet na serveru, protože potřebuje takovouto uživatelskou pravidelnou akci :-/.

[Max]

Významově je to ekvivalentní, spisovně netuším.
Zdar Max

[Josef Kufner]

Významově ekvivalentní to není. "Díky" potřebuje k ekvivalenci s "kvůli" přidat trochu ironie.

[Max]

Což v případě nefunkčnosti oné věci přeci jako ironie vyznívá, ne?
Zdar Max

[Josef Kufner]

Dost často ne a spousta lidí si to při použití těchto slov neuvědomuje. V tomto konkrétním případě mi přijde, že to je celkem jedno, ale asi bych napsal "kvůli".

[pan Klobouk]

Copak baťák, ale takovej maršbaťák nebo dokonce marškumpačka...

[xkucf03]

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.

[Max]

Tuto tvou teorii můžeš aplikovat úplně na všechno ostatní. Vlastně jen říkáš, že kdyby lidi nebyli blbý, mohli být víc vepředu. Hmmm, kdyby, kdyby...
Zdar Max

[Nobody]

Take jsem videl podobny system v akci a zarazilo mne to uplne stejne. To neni ani nevyuziti potencialu technologie, je to jeste daleko horsi; efektivni, strojove urychlene mrhani.
A co je obsahem tech faktur, to radsi ani nevedet.

[xxxxxxxxxxx]

Těhle věcí na světě je... Ber to z pozitivního úhlu. Naprogramuj to a zkus na tom vydělat prachy. Jenže to by většina lidí, včetně tebe nesměla být: 1) totálně dementní, 2) totálně lína... )

[Josef Kufner]

Lenost je zrovna v tomto ohledu přínosná. Díky té vývoj vůbec probíhá. Ale v kombinaci s blbostí to je špatné.

[xxxxxxxxxxx]

Jo to je taky pravda. )

[K42]

Neviděl bych to tak černě. Prostě v některejch firmách ještě lidem nedošlo, že el. komunikace je lepší a levnější

Velký firmy si tyhle data (objednávky, faktury atp.) vyměnujou elektronicky poměrně běžně(EDIFACT, XML, Pyšvejcův výměnný formát...)

[amazon]

byl jsem u toho, kdyz ve firme rozhodovali, jestli taky nasadi ty scannery. Nakonec se rozhodli to delat po staru - pani v IS systemu zalozi na jedno kliknuti novou 'obalku' a vsechny dokumenty vlozi pak do takove A4-slozky s cervenou barvou. Ta slozka ma vyriznute male okenko, ve kterm je videt identifikace te slozky - to je proste papir, ktery se pri zalozeni te slozky take hned vytiskne. Jine firemni procesy maji zase jinou barvu. Tahle slozka pak obiha firmou a skonci nakonec v registrature. Tam se ten obsah obalky vyjme, sepne a ulozi do poradace. Ta cervena slozka pak zase beha po firme s jinym obsahem.

Zkouseli, jestli je vhodne mit tu identifikaci jako carovy kod (aby to nemusel referenz znovu zadavat) a zjistili, ze se to nevyplati.

Velkou vyhodou te manualni metody je, ze se referent muze vsechny podklady vylozit najednou na stul a nemusi na monitoru neustale hledat , kde je ta spravna priloha. Smozrejme se setri ten cely cirkus jak ho popsal autor.

Místo aby jedna firma poslala druhé třeba jednoduché XMLko

Nekdo 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ávkou

tohle vyzaduje umelou inteligenci - to je proste v praxi u vetsiny firem nemozne. Jeste tak v pripadech, kdy je predmetem obchodu jedna polozka.

[xkucf03]

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ávky¹, 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ávky² – 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}

[Max]

Co vím, tak přes EDI a hafo dalších věcí nám běží elektronické objednávky, možná i faktury, zas tak moc do toho nevidím, implementovalo se hodně způsobů el. komunikace.
Papírové faktury řešíme jen ty příchozí, my odesíláme většinu věcí elektronicky, ale je pravda, že je to "napůl alektronické", jelikož většina z toho jsou podepsané pdf generované z našeho IS, což je zrovna pro nás šuma fuk, ale adresát pak musí datlovat.
Zdar Max

[Josef Kufner]

A co brání v přibalení podepsaného XML vedle stávajícího PDF? Asi to skoro nikdo nevyužije, ale třeba se pár firem po chvilce chytne a začne to dělat taky. A pokud si s nima posíláte faktury obousměrně, máte kus práce oba pryč.

[Dreit]

Otázka je jak bude vypadat trh práce, když zničehonic příjdou o práci stovky opisovačů

[User682]

zdravim,

zeptam se: Co si predstavujete pod pojmem "automatizovane zpracovani faktur" ?

Tak trochu nechapu, proc se na faktury lepi stitky. Podle me (nejsem znaly pomeru ve Vasi firme) je toto uloha na nejake vytezovani dat/textu z faktur, nasledne zpracovani, sparovani,..... Neco jako dela treba ABBY Flexi Capture.

gf

[Max]

Faktury musí mít nějaký universální identifikátor. Tím identifikátorem je čárový kód ve formátu ABC1234567890.
Štítky se lepí na faktury proto, jelikož :
1) při zadávání prázného záznamu se použije čtečka čárových kódů - uživatel identifikátor nedatluje, jen informace ohledně faktury (metadata).
2) ten samý kód, ze kterého je čten identifikátor se nalepí na fakturu a opět, ulehčí to práci, jelikož nikdo nemusí ručně naskenovaný dokument někam přiřazovat/uploadovat, jelikož se to udělá "samo".
"ABBY Flexi Capture" vypadá zajímavě, otázkou je cena, spolehlivost a počáteční datlování, než se to naučí aspoň pár základních stovek druhů faktur.
Zdar Max

[jekub]

Pro podobný účel jsme kdysi (cca 8 let zět) použili http://www.bardecode.com/en1/ a napsali si vlastní řešení.

Časem to chřadlo a chřadlo až úplně uchřadlo. Protože * vydané faktury už není potřeba papírovat a dá se kdykoli vytisknout originál * přijatých papírových fakur také podstatně ubylo, takže stačí k záznamu v IS kliknout na přípojit - scan.

[Max]

Ano, také jsem na tento toolkit narazil při hledání. Jinak osobně nevím, jak moc el. faktury ubyly, ale v našem odvětví zas tak moc asi ne. Dokonce před půl rokem nám O2 nechtělo posílat elektronické vyúčtování, jen v papírové podobě. Za elektronické vyúčtování chtěli peníze, což se zlepšilo s novým výběrovým řízením a novýma podmínkama. Nicméně, co jsem slyšel, tak sice už posílají elektronickou fakturu, ale také i papírovou (má to asi kolem 250 stránek).
My třeba všem posíláme podepsané el. faktury, nicméně jsou stále firmy, které vyžadují papírovou formu.
Zdar Max

[Bhua]

Misto carovych kodu vlozte mezi faktury prazdnou stranku s nejakym patternem.

[Bedňa]

Čiarový kód je dosť ľahko identifikovateľný, ale ešte lepšie je na tom asi QR kód a hlavne sa tam dá nacpať ďaleko viac info. Podľa mňa je kopec slobodného softu čo s čiarovým kódom nemá problém, asi väčšina. Nerobím to profi ako to máte vo firme, ale stačila by hocijaká vecička s Androidom čo zosníma čiarový kód (Barcode Scaner to robí pootočené z ruky) a k tomu už len napojiť to čo máte.

[jekub]

Příloha:

• 1.bmp (156782 bytů)

pokud vám přibíhá pdf, tiff, cokoli s čárovým kódem elektronickou cestou, tak vám žádná fidloprcička nepomůže.

[jekub]

Příloha:

• 2.bmp (96886 bytů)

zkoušel jsem něco svobodného najít a nic moc. Aspoň jsem vyzkoušel novou verzi.

[Bedňa]

Příloha:

• bs.jpg (32291 bytů)

Úplne v pohode a ešte som ho o pár stupňov pootočil aby to nemal také jednoduché.

[xxxs]

aka je aspon subjektivna chybovost pri takom hnusne vytlacenom kode?

[Bedňa]

Ja to nepoužívam profesionálne, ale moja skúsenosť je 100% úspech u slobodných aplikácií spomínaných aj v komentároch pod týmto blogom. Tak napr aj slabý GOCR sa dá nastaviť na 100% detekciu a pokiaľ znak nerozpozná hodí tam podtržítko, alebo znak podľa nastavenia, takže vieš že sa stala chyba. Nestane sa chybná detekcia, ešte som sa s tým nestretol, ale ako som písal QR kód mi príde lepší, vďaka koordinačným bodom je antidebilný na otočenie.

Mať zadanie ako Max, tak prejdem na QR kód, to potom tá teta môže nalepiť hore nohami a funguje to výborne.

[Kvakor]

Mně celkem dobře fungoval ZBar, umí vytáhnou kód jak z obrázku, tak z třeba z webkamery a snese i nějaké to natočení (případně umí ibnteraktivně ukazovat stav načítání na monitoru). A umí číst i QR kódy (což jsem ale moc nezkoušel).

[Dreit]

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.

[Dreit]

K požadavkům:

- zbar, volitelně imagemagick

- imagemagick

- grep, wc, možná sed

....a všechno samozřejmě poslepovat pořádným lepidlem - BASH.

[Sandokan]

Zdravím,

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.

[Max]

Bohužel, ten program by to měl umět, ale neumí, prefix prostě ignoruje a buď přečte čárový kód, nebo ne. Když jsou dva kódy v oblasti, tak přečte oba a dá na výběr, který se má použít, ale pokud přečte jeden, třeba i se špatným prefixem, tak smůla. Fa, co nám to rozjížděla to řešila s výrobcem SW a bez úspěchu. Volby a všechno okolo to prostě má, ale ignoruje :-/.
Zdar Max

[Sandokan]

JJ, rozumím, myslel jsem místo čárového kódu na štítku rozpoznávat normální text toho kódu, to by snad OCR program mohl umět. I když z nějakého důvodu tam třeba ten text nemáte nebo to prostě nejde z jiného důvodu.

Jinak, to dělení dokumentu je fakt dobrá finta.