Tady je to podáváno tak, že jedinou cestou elektronické fakturace je formát EDI a firma Editel jako zprostředkovatel komunikace. Z pohledu představitele této firmy je logické, že chce pro firmu získat kšeft. Současně to ale není tak, že by to byla jediná cesta.
Klidně lze elektronické faktury ve strojově zpracovatelném formátu posílat e-mailem místo těch PDF nebo současně s nimi (pro klid duše nebo pro vytištění k realizaci papírového firemního oběhu faktur, známého "kolečka", které se stále leckde praktikuje). Existuje totiž formát ISDOC (založený na jazyce UBL), který byl připraven SPIS (dnes ICT unie) ve spolupráci s ministerstvem financí.
Většina českých účetních softwarů ho umí generovat i zpracovávat. Málokdo ho však používá, i v řadě velkých firem (o malých nemluvě) stále upřednostňují ruční přepis z papírové nebo PDF podoby faktury, i když je s tím spousta práce a je to náchylné na chyby.
že raz budú tieto služby všetky online spravované štátnou firmou na štátnych serveroch - ako online účtovníctvo.
(Niečo na systém dátových schránok, ale logické, prehľadné, funkčné a bezplatné.)
A účtovný SW by mohol zostať aj naďalej pre internú potrebu (nejaké funkcie navyše), ale platné dáta by boli tie online. Kto by nemal pripojenie na internet, raz za čas by dáta mohol uploadovať napr. na daňovom úrade, kde by bol bezplatný internet.
Napr. niekto by vystavil faktúru cez HTML online formulár (alebo svoj účtovný SW) a odoslal na IČO/DIČ (ako ID) príjemcu, a jemu by sa hneď zobrazila na jeho účte.
nemůžu jinak, než souhlasit.. pobavilo mě toto: " Nemluvě o archivaci v podobě schraňování e-mailů...".. tak to už je fakt naprostá zoufalost z jeho strany.. jako kdyby snad firmy nearchivovaly e-maily tak jako tak, protože posledních deset let je to tzv. "rodinné stříbro" všech možných dat a skutečností.. a že nějaká faktura (dobře exportovaná do PDF) má cca 50 kb velikost.. tak se snad rozbrečí, že nemají místo na discích (i kdyby to byl RAID v serveru).. nebo na záložních zařízeních v době deduplikace apod. fines? :DD
Ubožák.. (s tímto argumentem)..
Nemohol by sa miesto elektronického podpisu používať len otisk - hash napr. SHA-256?
Ten, na rozdiel od podpisu, nikdy neexpiruje.
A bol by nejaký centrálny register takto podpísaných-hashovaných dokumentov, kde by to nebolo problém kedykoľvek overiť - aj o 100 rokov.
Už len tieto 2 údaje by zaručili autentičnosť: dátum vystavenia a hash.
zdravim,
v jedne veci s Vami budu souhlasit. S generovanim faktur pomoci TeX-u nejake napady byly. Nemam nic proti velmi dobre vypadajicim a prehlednym fakturam. Kdysi jsem mel nejakej napad neco takovyho programovat. Ale pochybuju, ze by o to byla moc poptavka. A nejsem si moc jistej tim,jak budu nekde u zakaznika instalovat veci pro TeX jeste k dalsim aplikacim. Nebo nekde na aplikacnim webserveru. + bezpecnost.
Co se tyce zbytku, tak se obavam, ze jste si jeste nezkusil moc praxe nebo nasazovani nejakych novych formatu.
Pokud jde o nejake parsovani datovych formatu, tak uz vidim "rybízky po prvních ročníku informatiky", jak programuji parsery, lexery, gramatiky a resi pripadne chyby generatoru Tex-u.
Asi je zbytecny Vam doplnovat znalosti, jak to v IT chodi a jak se zavadi nove technologie. To musite udelat sam a kdyz to budete nekde neco prezentovat a zavadet do praxe, tak se za to podepiste svym jmenem a prijmenim.
gf
EP i hash jsou založeny na nesymetrických šifrovacích algoritmech, jejichž konkrétní provedení (požadavky na sílu hesla) zaostávají s rostoucí úrovní techniky. Prostě hashování s heslem o n znacích v roce X nezaručuje, že někdo nebude schopen vytvořit stejný hash při stejném hesle pro dokument s jiným obsahem (cíleně změněným) v roce X+10. Přestože v roce X by podobná úloha požadovala miliony let strojového času. Podobně je to s délkou prvočísel v EP. Navíc někteří odborníci tvrdí, že až vylezou z plínek kvantové počítače, tak tyhle početní úkony budou schopny zvládnout pro nás nepředstavitelnou rychlostí. Mají-li pravdu tak tyto metody šifrování a ověřování půjdou do koše.
Pokud někdo umí vytvořit kolizní dokument, tj. se stejným hashem, není pro něj problém zachovat velikost souboru. V PDF souborech o velikosti desítky kB je spousta balastu, který se nastaví tak, aby kolize nastala, ve viditelné části byly jen požadované změny a velikost se nezměnila.
Centrální databáze je dobrá, dokud ji nezkompromituje útok adminů nebo něco podobného.
Doufejme, trochu bych o tom pochyboval.
Jde také vybudovat stínovou CA.
Ne každý při ověřování umí zkontrolovat a dělá to, že certifikát je na aktuálním seznamu CA, které mohou vydávat kvalifikované certifikáty v některé ze zemí EU.
Prostě běžný uživatel se spokojí s libovolným podpisem, pokročilejší se spokojí s "nápisy" v certifikátech a dále je to až příliš pracné.
Samozřejmě že nechtějí, zjednodušovat znamená připravovat se o práci. "Ideální" software je takový, pro jehož používání je třeba školení (které coby dodavatelé rádi za "přiměřené" peníze zajistíme, i certifikát každému vystavíme), po němž už bude možno ho používat, ovšem jen v míře nezbytně nutné pro to, aby od něj uživatel neutekl ke konkurenci. S čímkoliv "nadstandardním" pak rádi poradíme v rámci placené podpory.
Zřejmě ses v Alliante nedostal dál než za správu desktopu, Lukáši. Jednak jsou na archivaci nároky legislativní a jednak není v silách velké firmy dohledávat faktury v mailu. EDI není pro živnostníka, který pošle tři faktury měsíčně. Když něčemu nerozumíš, tak do toho neplkej.
Naše firma platí za desítky tisíc zpráv měsíčně méně než deset tisíc. K EDI jsem byl zpočátku skeptický, protože to není ani náhodou plug&play. Dnes nám nejen šetří, ale hlavně umožňuje držet krok s konkurencí.
Bez vámi zmíněných zpráv mimo klasické faktury bychom si nebyli schopni plánovat příjem na skladu. Takto se čety skladníků ani nefklákají, ani nejsou přetížené. Elektronické příjemky dodavatelům čistí fakturační proces a velkou většinu faktur už dostáváme na první dobrou. A pokud je problém, dostává dodavatel zprávu o zamítnutí hned a se zdůvodněním.
Zpracování tištěné faktury za dvě koruny je bohužel nesmysl. Já bych za tuhle částku byl šťastný, ale bohužel je to celkově víc než 20Kč. Ještě obtížněji se vyčísluje chybovost, která nás pak stojí peníze na ztracených skontech nebo jiných bonusech.
Je to jen o přístupu. Máme dodavatele, kteří prskali stejně jako vy a vymýšleli důvody, proč něco nejde. Většinou jsou to líní ITíci, kteří by buď přišli o práci nebo by museli sestoupit z trůnu vševědoucích. Běda ale, když tihle křiklouni nedostanou elektronickou objednávku. Pak prskají, protože přece musí vše dělat ručně a je to stojí peníze..
Ověřu je to ale člověk nějakým úředním postupem, což je mnoha způsoby manipulovatelné. Aktuální kauza - viz http://www.lupa.cz/clanky/symantec-vydal-falesny-certifikat-pro-google-com-i-www-google-com/
1. Nespletl.
2. Protože ten zdroják v TeXu vyplní patřičnými konkrétními údaji i mírně vycvičená opice (stačí vložit text mezi složené závorky za příslušným názvem položky), zatímco o XML bych si to říct netroufal, chybovost tam bude daleko větší.
3. Faktura má jasně daný seznam položek (adresa, IČO, bankovní spojení atd.), pro něž není problém vymyslet vhodné názvy (začínají zpětným lomítkem a nesmějí obsahovat nic jiného než písmena anglické abecedy) a za ně se do složených závorek {} vloží obsah, ten už může mít českou nebo jakoukoli jinou diakritiku. TeX to zpracuje na pěkně vypadající papírově založitelné PDF (pokyny pro vyhodnocení maker a příkazů za tímto účelem triviální nejsou, ale o nich nepředpokládám, že by je dělala sekretářka a stačilo by je udělat prakticky jednou pro vždy) a paralelně nějaký konvertor ten text projde a obsahy složených závorek za příslušnými názvy vloží do příslušných polí databáze. Ten konvertor by byl velmi triviální, protože by jen hledal příslušné řetězce znaků a následný text ve složených závorkách by bral jako jednu databázovou položku.
Ovšem, má to jednu zásadní nevýhodu: Je to příliš triviální ve vytvoření i následné údržbě na to, aby se na tom uživila nadnárodní firma s tisíci zaměstnanci.
Problémy jsou zde dva:
1. Absence důvěryhodné certifikační autority (protože autorita vlastněná státem nebo na něm alespoň silně závislá není to pravé ořechové pro spory soukromník versus stát - viz datové schránky a jejich povinné používání ke komunikaci se státem, kde se soukromník ocitá v asymetricky nevýhodné pozici).
2. Rychlá exspirace elektronického podpisu - některé faktury se musejí uchovávat pro kontrolu i více než deset let a potom je s nové a nové "balení" dokumentu do souboru s novým certifikátem složitější, pracnější a dražší než strčení orazítkovaného a podepsaného papíru do šanonu.
Elektronický podpis si v podstatě hraje na něco, co není, nebyl a z podstaty věci ani nemůže být: Na cosi, co by mělo dlouhodobě zajišťovat autenticitu dokumentů. Ve skutečnosti je to jen jakási "pečeť", která by měla příjemci garantovat pravost odesílatele, a která v podstatě momentem doručení může exspirovat..
Na věci, na něž se EP znásilňuje, by byl lepší nějaký "elektronický notář", garantující uložení dokumentu v nezměněné podobě dlouhá léta (nebo i staletí), což EP garantovat z podstaty sebe sama nemůže.
Shodou okolností jedna z větších prací, kterých jsem se dopustil, řešila něco podobného: V BASICu na PMD-85 jsem dělal testové zkoušení studentů. Otázky jsem musel "ručně komprimovat", tak, že často se vyskytující fráze byly nahrazeny značkami, a program si je vždy "rozvinul" pro tu zrovna vykreslovanou (dělal jsem to v grafickém modu, takže i s diakritikou) otázku a nabídnuté odpovědi. Čili parsoval text dost podobně jak si to představuji pro výše uvedený příklad. Byla to, pochopitelně, "nouzovka", protože dostatečný počet otázek v holém textu se prostě do paměti počítače nevlezl.
Je ovšem otázka, zda by někdo, odchovaný objektově orientovaným programováním byl schopen něco takového napsat. A pokud by se našel objektový jazyk s vhodnými knihovnami objektů, tak by nejspíš vzniklo mnohamegabytové monstrum a současně by programátor vůbec nevěděl (vzhledem k chabé dokumentaci většiny knihoven), co mu ten program vlastně dělá.
A vy plkate o cem? Kazda normalni firma pouziva nejaky SW, a faktury ma ulozeny jeho prostrednicvim v databazi. Nepotrebuje na to ani EDI ani ISDOC ani zadny dalsi obskurni format.
A vite jak se zdrojove faktury archivuji? Na desitkach a stovkach palet ve skladech.
Jenom prenos faktury pres EDI vyjde klidne na 8Kc/ks. Ucetni ji z papiru nebo mailu opise za 2Kc a za dalsi korunu vytiskne. (prenos + potvrzeni prijmu + potvrzeni zpracovani + potvrzeni akceptace, a to vse x2, protoze to zaplati jak prijemce, tak odesilatel).
Dobry den,
muzete me prosim rici, jak konkretne v TeX-u chcete resit jednotlive pole a tabulky na fakturach ? A standartizovane, aby to pouzivali nejaka vetsi cast trhu ?
Vcelku by me zajimalo kolik "to neni problem" zabere casu a jak bude spolehlivost ?
Vzhledem k tomu, ze mam vlastni document capture reseni, tak bych se rad poucil.
dekuji za odpoved
gf
zdravim,
pak reditel se tu divi, jaktoze se tady v Cechach nefakturuje dostatecne elektronicky.
Pridam par nazoru, co jsem za kratkou dobu okoukal, jak co funguje. Delam trosku sofistikovanejsi extrakce dat z dokumentu. Treba i z faktur.
0) dost casto firmy a to i vyvojarske nemaji predstavu, jak by to melo lepe fungovat.
1) kdyz prijdete s resenim, ktere usetri praci lidi, tak narazite na odpor. Mohlo by se treba propoustet.
2) Zakaznici chteji reseni co nejlevnejsi. Idealne zadarmo i s podporou. To, co neco umi, uz je za "tezke love" a firma si to nekoupi.
3) Mam pocit, ze dost systemu na fakturaci je dost slozitych na ovladani a jeste do toho pridejte dalsi vlastnost a zesloziti se to pro bezneho uzivatele.
4) mame tu ISDOC format. Kdyz zacnete neco pro nej implementovat, tak najednou Vam chybi rychle uchopitelne priklady[atributy pro statni spravu nepotrebuji], nejake hotove knihovny pro programovaci jazyky, nejaky online validator, moznost si bez nejakych registraci na netu ozkouset, ze to naimportujete do nejakeho ucetnictvi. Jak je na tom EDI, jsem nezkoumal, ale asi to nebude uplne ruzove. Nerikam, ze situace je vylozene spatna, ale pokud chci neco rozsirit, tak si ty vyvojare musim trochu hyckat.
5) Jeste jsem nevidel e-shop jako maly zakaznik, kde si stahnu fakturu v elektronickem formatu mimo HTML nebo PDF.
gf
blbci znali TeX, tak není problém tu fakturu poslat jako TeXový zdroják, ze kterého si příjemce udělá, pokud to bude potřebovat založit jako papír, pěkné PDF. Navíc není problém napsat program, který ten zdroják "vykuchá" a překlopí do nějakého databázového formátu, to je úkol pro "rybízka" po prvním ročníku informatiky. Prostě vymýšlejí něco, co je už dávno, a na podstatně lepší úrovni, vymyšleno.
ISDOC je skoro ve všech českých ERP a ÚP.
V tom článku je jasně vidět pohled "programátora v PowerPointu", který říká polopravdy a prosazuje pouze řešení jejich firmy o ničem jinym nemluví.
Účetní a CFO jsou rozumní v tom, že raději si ručně kontrolují obsah faktur než prostě spoléhat na "stroj".
Naprostá pitomost byly hlášky, že uživatelé mají elektronicky podepisovat své faktury a na druhé straně mají ověřovat a spoléhat na el. podpis. Jako by ti odborníci nikdy neslyšeli jak je snadné elektronický podpis zfalšovat.
To je trošku pomýlené. Sami taky ISDOC máme a kdyby fungoval, tak by to bylo docela hezké, ale je to bublina. Máme reálnou zkušenost, že když oslovíte stovku firem s českým ERP, tak budete mít velké štěstí, když jedna z nich bude mít systém na aktuální verzi ISDOC 6.0 vůbec připravena, natož aby ho chtěla. To vůbec nemluvě o nějaké snaze obchodovat z jinou než českou firmou.
Ale EDI navíc není jen elektronická faktura, ale taky objednávka a další doklady, je o několik levelů výš, globálně funguje pár desítek let a je to jistota. Navíc také samotné EDI můžete teoreticky provozovat bez providera, nechcete-li, ale mnohdy zjistíte, že se vám taková starost nevyplatí.
Zfalšovat elektronický podpis, povídej, to mě zajímá, co přesně tím myslíš?
Neznám jednoduchý způsob zfalšování elektronického podpisu, existují ale způsoby jak podvést člověka, nikoliv počítač. Buď podpis je pravý, ale vymyšlený je obsah faktury a nikdo to nezkontroluje nebo dojde k úniku privátních klíčů na straně vystavitele. V případě automatického zpracování takových dokumentů, dodržení řádné valice certifikátů, nevidím v tom nebezpečí.
Samozřejmě jsem v IT nováček, pokud se pletu, pouč mě, rád se dozvím něco nového.
Vrele doporucuji ... se cemukoli co ma v nazvu EDi vyhnout velkym obloukem, a kazdeho kdo s necim takovym prijde hnat bicem. Tento nepouzitelny pseudostandard je naprosto knicemu, nebot si jej kazdy implementuje jak se mu zlibi. Takze budete utracet nehorazne penize za provoz, a dalsi za neustale reimplementace pro kazdeho partnera zvlast.
Ze jde o standardni format je jedna velka LEZ. Format je tak leda extremne nabubrely, ve skutecnosti neexistuje zadna spolecnost, ktera by jej mela implementovany v celem rozsahu. Zcela bezne to pak vypada tak, ze jeden partner do pole X dava EAN, jiny nejake interni cislo, treti nazev zbozi. Misto aby vam partner posilal potvrzovaci zpravy (napriklad u tech faktur), tak vam mozna, pokud na nej budete hodne tlacit, posle jednou mesicne mail se seznamem prijatych faktur.
Misto aby jste kuprikladu usetrili za papirove dodaci listy, budete resit, proc je na papire neco jineho nez co se poslalo elektronicky a dohadovat se, co ma prednost. Ale parnetr bude vyzadovat oboji, takze to zaplatite 2x.
Neustale si taktez budete uzivat zabavu s resenim chaosu a doslova bordelu se vsemoznymi ILN.
Preji prijemnou zabavu.
Rozhovor kvalitou svého obsahu patří spíše na iDnes než na Lupu. Ano, působí dojmem reklamy na firmu editel.
EDIFACT je standard, ale rozhodně ho nestráží GS1. Ta stráží leda svůj EANCOM, který je z EDIFACT odvozen.
Formátů i způsobů přenosu, které lze využít, je mnohem víc. Taky není pravdou, že zasílání PDF je elektronizací jen napůl. PDF se dá vytěžit podobně jako strukturovaná data, i když ne tak komfortně. Prostřednictvm OCR lze přenést faktury z PDF do systému.
A co se týče zabezpečení, pan Mrvík asi neslyšel o "digitálním podpisu".