Navigace se soukromím CoMaps postavena nad OpenStreetMap je nově k dispozici v Google Play, App Store i F-Droid. Jedná se o komunitní fork aplikace Organic Maps.
Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
Máme faktury a faktury mívají přílohy. Proces importu faktur do DMS je následovný :
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 :-/.
Největší problém tohoto řešení je skenování dokumentů, resp. QuickScan. Tento sw dělá tři nemilé věci :
(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)
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
Tiskni
Sdílej:
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.