Red Flags: Informačný systém elektronickej fakturácie (IS EFA)

Názov: Informačný systém elektronickej fakturácie (IS EFA)

Garant: Ministerstvo financií SR

Stručný opis: Cieľom navrhovaného projektu je zabezpečiť, aby verejní obstarávatelia a obstarávatelia (VO/O) prijímali a spracúvali elektronické faktúry, ktoré sú v súlade s európskou normou pre elektronickú fakturáciu (Smernica Európskeho parlamentu a Rady 2014/55/EÚ). Projekt sa bude týkať cca. 7900 subjektov verejnej správy a približne 876 000 faktúr ročne.

Náklady na projekt: Štúdia uskutočniteľnosti 5 038 375 EUR (s DPH)

Aktuálny stav projektu: Realizácia projektu

Čo sa práve deje:

  • realizuje sa scenár B2G inhouse kapacitami MF SR
  • pripravuje sa štúdia uskutočniteľnosti pre scenár B2B

Zhrnutie hodnotenia Red Flags: Projekt zavedenia elektronickej fakturácie je vyvolaný európskou legislatívou a má opodstatnenie. Zvolený prístup implementácie však považujeme za nevhodný. V projekte boli umelo vyradené alternatívy, ktoré by v maximálnej miere využívali existujúce komponenty (ÚPVS), podkopáva sa tým architektúra informatizácie a vytvára sa nový (a duplicitný) centrálny komponent bez rešpektovania predpísaných postupov na jeho zavedenie. Ekonomická analýza má zásadné nedostatky predovšetkým na strane nákladov (expertné odhady, premrštené sadzby, nezapočítanie nákladov tretích strán).

Stanovisko Slovensko.Digital: Projekt má podľa nášho názoru zásadné nedostatky a odporúčame ho zastaviť a prepracovať.

:triangular_flag_on_post: HODNOTENIE RED FLAGS

I. Prípravná fáza


Reforma VS :star::star::grey_star::grey_star:

Reforma je popísaná v rámci reformného zámeru. Obsahovo sa však ide o tradičný projekt informatizácie, ktorý neprináša žiadnu zásadnú reformu procesov, iba ich elektronizuje. To považujeme za zásadný nedostatok.


Merateľné ciele (KPI) :star::star::star::grey_star:

KPI sú nastavené aj na úrovni reformného zámeru aj v štúdii uskutočniteľnosti. Na úrovni reformného zámeru sú niektoré KPI úplne nevhodné a kopírujú “staré” projekty informatizácie. Napríklad:

V samotnej štúdii uskutočnoteľnosti sú už len KPI, ktoré reálne vyjadrujú ciele projektu a považujeme ich za dobre navrhnuté:



Postup dosiahnutia cieľov :star::star::grey_star::grey_star:

Projekt je z hľadiska zavedenia rozdelený na 3 fázy

  • zapojenie verejných obstarávateľov a obstarávateľov na ústrednej úrovni (24 organizácií)
  • zapojenie pre verejných obstarávateľov a obstarávateľov na nižšej ako ústrednej úrovni
  • podpora pri rolloute end to end integrácií pre organizácie a konzultačná podpora

Projekt je realizovaný waterfall prístupom a chýba mu agilita (nie je plánovaný proof of concept a otestovanie riešenia v malom rozsahu).

Veľké riziko vidíme v legislatíve. Projekt je závislý na legislatívnej príprave (nový zákon o elektronickej fakturácii). Aj vzhľadom na skúsenosti z OPIS sa domnievame, že legislatíva by v čase schvaľovania štúdie mala byť minimálne vo fáze “schváleného legislatívneho zámeru”. To v tomto prípade neplatí, aj keď legislatíva podmieňuje zavedenie projektu.

V projekte vôbec nie je zabezpečené to, že jedna z cieľových skupín - t.j. dodávatelia, budú schopní prejsť na navrhované riešenie. Pričom v samotnom reformnom zámere MF SR priznáva, že je to najčastejší dôvod, prečo elektronická fakturácia zlyháva.

Druhá cieľová skupina (OVM) sa bude na nové riešenie musieť integrovať, resp. začať ho používať. Projekt odhaduje náklady na strane OVM na úrovni 2 mil. EUR. Ich záväzok (a jeho finančné krytie) však nie je v projekte zabezpečný.


Súlad s KRIS (nie je zatiaľ vyhodnotený)


Biznis prínos :star::star::grey_star::grey_star:

Projekt má jasný prínos (súlad so Smernicou EÚ) a je logické, prečo ho realizuje práce MF SR. Niektoré funkcionality sú však umelo pridané a tým sa riešenie zbytočne predražuje. Bližšie sa tomu venuje časť Alternatívy a CBA.


Príspevok v informatizácii :grey_star::grey_star::grey_star::grey_star:

Myšlienka projektu prispieva k cieľom informatizácie. Technické riešenie však podkopáva logiku ÚPVS ako centrálneho bodu doručovania a vytvára nový bod pre doručovanie špecifického typu dokumentov. Zavádza sa tým pádom nový centrálny blok architektúry ISVS. Nebol však splnený postup pre analýzu/odôvodnenie/vytvorenie nového centrálneho komponentu podľa dokumentu NKIVS Strategická priorita Rozvoj agendových informačných systémov a využívanie centrálnych spoločných blokov. Ministerstvo financií podľa nášho názoru nedostatočne zvážilo variant maximálneho využitia existujúcej infraštruktúry (ÚPVS) a predložený projekt vzišiel z analýzy ako najvhodnejšie riešenie len na základe umelého doplnenia kritérií, ktoré nesúvisia s cieľmi projektu.


Štúdia uskutočniteľnosti :star::star::grey_star::grey_star:

ŠÚ existuje, ale má nedostatky, predovšetkým v časti vyhodnotenia alternatív a analýze efektívnosti.


Alternatívy :star::grey_star::grey_star::grey_star:

Alternatívy sú popísané. MCA (multikriteriálna analýza) má však zásadné nedostatky. Ako požiadavky sú použité “priania” MF SR, ktoré nie sú naviazané na ciele projektu (napr. požiadavka aby riešenie umožnilo správu obchodných prípadov, na základe ktorých sa realizuje fakturácia). Tieto fiktívne požiadavky eliminujú iné alternatívy a zbytočne nafukujú funkcionalitu systému.

Nezvažuje sa alternatíva, pri ktorej by boli do maximálnej miery využité existujúce riešenia (ÚPVS), t.j. alternatíva, pri ktorej by sa zaviedol nový typ podania cez ÚPVS na manuálny upload a využilo by sa súčasné API na automatizovaný upload.

Vyhodnotenie MCA nie je v súlade s duchom metodiky pre ŠÚ a CBA (kritériá nemajú váhy, všetky sú de facto považované za KO kritériá).

Štúdia neobsahuje zhodnotenie alternatívy, keby sa riešenie nakupovalo ako služba - aj keď takéto riešenia fungujú v iných krajinách EU (kedže táto povinnosť sa ich týka plošne).


Kalkulácia efektívnosti :star::grey_star::grey_star::grey_star:

CBA má zásadné nedostatky.

  • na strane prínosov - gro prínosov projektu pramení z automatizácie, ktorá však nie je primárnym cieľom projektu a dá sa dosiahnuť aj v iných alternatívach, ktoré však boli vyradené na základe nesprávnej MCA. CBA obsahuje negatívne prínosy v podobe investičných nákladov OVM na integráciu, ale nie je jasné, kto ich zaplatí a aký je záväzok OVM tieto náklady pokryť. Chýba vyčíslenie prínosov z elektronického zadávania faktúr do systému - toto na rozdiel od automatizácie je core cieľom projektu, ale napriek tomu nie je vyčíslený.
  • na strane nákladov - rozpočet človekodní je počítaný formou expertných odhadov. Bez vysvetlenia. To považujeme za fatálny nedostatok CBA. Sadzby za človekodeň sú tiež mimo realitu, nakoľko pochádzajú len z odhadov firiem na trhu, ktorý je dlhodobo považovaný za skartelizovaný. Dávame do pozornosti becnhmarking sadzieb v Českej republike, ktorý bol vykonaný na podstatne väčšej vzorke zmlúv s verejnou správou, z ktorého vychádzajú jednotkové sadzby často zásadne nižšie, ako tie, použité v projekte. Napríklad za testera chce ministerstvo zaplatiť 670 eur na deň, pričom napríklad v Čechách je priemerná sadzba za testera v štátnom IT okolo 400 eur. Nepovažujeme za vhodné argumentovať sadzbami na iných projektoch v rezorte MF SR bez toho, aby sa sadzby porovnali aj s komerčným sektorom alebo okolitými krajinami. Náklady dodávateľov na zavedenie systému nie sú súčasťou projektu, aj keď na strane prínosov sa predpokladá, že tieto integrácie umožnia rýchlejší upload eFaktúr a prínosy sú do projektu započítavané.

Participácia na príprave projektu :star::star::grey_star::grey_star:

Štúdia uskutočniteľnosti aj reformhý zámer boli zverejnené, bolo možné k nim predložiť pripomienky. Kľúčové pripomienky však ostali nezapracované. Z vyjadrenia MF SR je zrejmé, že dialóg s dodávateľmi ekonomických SW, ktorých sa tento projekt bude týkať (na úrovni alternatívneho riešenia - nákup služby, resp. na úrovni dopadov v podobe integrácií) neprebehol v dostatočnej miere.


:file_folder: Dokumenty


:clock2: Aktivity

V tomto projekte už prebehli nasledovné dôležité aktivity / míľniky:

  • 5.9.2018 Štúdia uskutočniteľnosti bola predložená na pripomienkovanie
  • 14.9.2018 verejné prerokovanie projektu (verejný híring)
  • 24.9.2018 schválenie reformného zámeru
  • 11.10.2018 - schválenie štúdie uskutočniteľnosti
  • 23.4.2019 - vyhlásená výzva na predkladanie žiadosti o NFP
  • 9.7.2019 - predložená žiadosť o NFP
  • 19.11.2019 - schválená žiadosť o NFP
  • 20.12.2019 - podpísaná zmluva o NFP (https://www.crz.gov.sk/index.php?ID=4376480&l=sk)
  • 1.11.2020 - začiatok realizácie EŠIF projektu (30 mesiacov, t.j. do 31.5.2023)

Keďže sa jedná o aplikáciu Smernice EU, myslíte si, že je potrebný nový IS a že teraz každý členský štát začne budovať samostatný systém pre elektronickú fakturáciu s následnými integráciami do vlastných ekonomických systémov?

1 Like

v skratke: nie, myslíme si, že sú aj jednoduchšie alternatívy, ale neboli adekvátne vyhodnotené :slight_smile:

Nestudoval som studiu, ale mam otazku. smernica hovori o zabezpeceni fakturacie smerom k VO, ale v skutocnosti vybudovanie takehoto systemu de facto vytvori podporeny standard na obeh elektronickej faktury. V takom pripade su prinosy radovo vyssie, Zrejme ich ale zmerat je takmer nemozne a tak snaha dosiahnut overitelne cisla vedie k neuplnym odhadom.
Ale ak sa to podari spravit, tak bingo. Sem s tym.
A k alternativam, ak to ma mat dosah ako narodne dorucovanie faktur tak to naozaj inak nejde. A alternativa nakupit to ako sluzbu ? To by automaticky znamenalo rezignovat na OPII projekt, takato sluzba sa inak ako OPEX z rozpoctu neda platit. Dala by sa vypisat sutaz na monopolneho prevadzkovatela pripadne vymysliet ci by to nemohla byt sluzba dana zakonom a nechat ich zarabat na poskytovani sluzby podnikatelom. Ale ani jedno by nemohlo ist do OPII a vysledok je otazny.

A obecne, SU by mala dat HORNY odhad nakladov, skutocne ceny generuje sutaz. Akes u tam sadzby ? Ak pouzili bezne sadzby na MF, tak to je podla mna OK. Ak sutaz vygeneruje lepsie ceny, rozdiel sa vrati do OPII, 5 mil sa mi zda na prvy pohlad na velky pocet subjektov rozumne.

Skor ziadat vyssie ambicie aby sa tam mohli pripojit vsetci, nie len OVM a firmy co dodavaju OVM.

Ciste teoreticky k tomu netreba ani IS, staci vydat usmernenie pre OVM ze musia byt schopni prijmat elektronicke faktury, v standardoch zaviest ako vyzera XML faktury a hotovo. A dopadlo by to bezne slovensky, normalne by prisli do schranky, vytlacili sa a dalej by sa nic nezmenilo.
O elektronickej fakturacii sa hovori desatrocia, dokonca este pred tym ako sa objavilo slovo XML, tak bola snaha zaviest vymenny format EDI fact, ale nikdy sa to masovo nerozsirilo. A prinosy by boli enormne.
Ale pravda je ze okrem faktur chodia aj dalsie dokumenty, elektronicke faktury potesia uctovnicky ale naprikad dodacie listy su pre vacsie firmy este dolezitejsie.

1 Like

a este snad poznamka, tieto hodnotenia sa mi zdaju velmi formalne. Ak existuju rozumne alternativy, ktore by podla nazoru zvonku mali byt zvazene, tak za prve tento proces nie je vhodne nastaveny. Mal by existovat bod, nieco ako prvy draft v case ked vznika SU a ten by mal obsahovat kratke zhrnutie cielov a alternativy ktore budu naozaj posudzovane. A zvonku doplnit navrh dalsich. Pretoze par dni pred hodnotenim sa uz ziadne alternativy nebudu doplnat, to je kazdemu jasne. A ak nahodou ano, tak tak aby vypadli. A tak kazde hodnotenie moze obsahovat genericku kritiku ze alternativy su nedostatocne.

1 Like

Priznam sa, ze som si otvoril tu studiu, ked sa tu o tom uz tolko rozprava a pri ten analyze alternativ som skoro odpadol. Nielen, ze su tie kriteria zvolene velmi podivnym sposobom, ale navyse su pre prvu alternativu aj zle zodpovedane.

Ak sa bavime o elektronizacii faktur, tak to je uplne jasny kandidat na standardizaciu, zasadne standardizacna komisia, vyberie (asi existujuci standard) a koniec. Existuje tu trh s fakturacnymi softami a taketo centralne riesenie ho defacto uplne znici a zanikne konkurencny tlak na kvalitu a cenu, ktory v tomto zrelom segmente existuje. Sanca, ze sa tento standard rozsiri do B2B teda tiez bude miziva.

Toto su vyslovene vymyslene bludy, ktore su presne naopak. Pri cistej standardizacii nikto nebrani toto do hocijakeho softveru dorobi a vela z nich to uz davno dnes ma.

Jedina vyhoda centralneho riesenia je centralna evidencia a teda statistika, co sa da robit centralnym zberom (kedze mame standardizaciu!).

Tymto pozdravujem to obrovske kvantum odbornikov na uradoch a konzultackach, ktorym toto preslo cez ruky a vysledkom toho procesu je tabulka, ktora klame a jej dosledkom to, ze ideme stavat na zelenej luke X-ty fakturacny softver, na ktory sa bude integrovat X systemov namiesto toho, aby sa povedalo, ze bude sa pouzivat standard X, ci prinajhorsom spravila sutaz na nejaky existujuci a do dodavatel neho dorobil, import/export na dany standard a koniec.

Samozrejme od roku t4 je to 400k na udrzba rocne. Neskusal niekto zavolat povedzme do KROSu alebo POHODA, ze kolko by stalo dorobenie importu/exportu a rocna licencia? iKONEKT ukončenie | KROS

Neuveritelna hanba toto.

1 Like

Čisto zo zvedavosti jedna otázka: ako bude zabezpečené, že sa akákoľvek faktúra vytvorená v akomkoľvek systéme dostane do “Centrálneho fakturačného softvéru”? Ja by som hádal, že Centrálny fakturačný softvér bude musieť poskytnúť integračné rozhranie, ktorého súčasťou bude jednotný formát elektronickej faktúry.

Podľa môjho skromného dohadu tento softvér vyžaduje na vstupe to, čo má dodať na výstupe. Najjednoduchšou implementáciou je teda FTP server.

To si nepochopil, biznis predstava (predpokladam od dodavatela) je ocividne ta, ze vsetky faktury sa budu evidovat v tomto novom systeme. Uz ziadny iny fakturacny softver netreba.

Ja to chápem tak, že faktúra sa vystavuje buď ručne, alebo automaticky na základe objednávky z objednávkového systému. Ak nebudú chcieť prísť o automatické vystavovanie faktúr, tak fakturačný systém musí vystaviť rozhranie, v ktorom im tá faktúra de facto príde na základe nejakej objednávky.

Takže - jasné, že faktúry sa budú evidovať v tomto systéme. Ale otázka je, v ktorom systéme sa budú generovať.

1 Like

Áno, pýtaš sa úplne tie isté otázky ako ja. Tá centrála ak vôbec má na niečo slúžiť, tak je to len zber dát, ktorý sa bude potom niekde analyzovať. Dát je tak málo, že to môžu bežať snáď úplne na hocičom.

OK, ale v tom prípade treba kritérium “Postup dosiahnutia cieľov” hodnotiť na 0 %. Pretože touto implementáciou sa pôvodné ciele nedosiahnu. Práve naopak: takýto systém vyžaduje, aby sa vyriešila najprv tá požiadavka, ktorú má údajne vyriešiť.

1 Like

Je to tam napisane dost natvrdo, ze cielom je prijimanie el. faktur, ocividne nikoho velmi netrapi ako vyzera ten proces end-to-end lebo toto sice prinesie benefit na strane objednavatela, ale nie na strane dodavatela.

Inak tie alternativy ma ju v sebe dieru, takto tam su napisane.
A: Zavedieme standard a koniec.
B: Zavedieme standard a umoznime dorucovanie faktur aj cez vseobecnu agendu UPVS (LOL).
C: Vybudujeme kompletne novy fakturacny soft, kde budu vsetci povinne zadavat faktury (manualne) alebo sa na to integrovat (cize oproti B ziadna zmena).

Inak by ma zaujimalo by ako tento problem riesil @ius, lebo toto je presne EUROPSKE RIESENIE, ktore defacto zavadza povinnost pouzivat strukturovane formulare. Dufam, ze uz sa chapeme, kde to zmysel ma a kde nie.

Konecne daco aj pre @ius -a. Ide skutocne o PDF s vlozenym XML…

1 Like

Nemas nejaky odkaz na to? Naozaj ma zaujima ta cast ako sa garantuje ze v tom XML (co spracuje system) je to iste ako v PDF (co vidi user).

kde sa hovori o PDF ? Rad by som sa dozvedel viac. Uz par rokov sa nezaoberam toutou temou, ale takto to bolo kedysi :
Na posielanie faktur a dalsich dokumentov v hospodarskom styku je uz davno existujuci celosvetovy standard EDI, ten vznikol v davnych casoch samostatne v US a jeho dnesna podoba je zjednotenie medzi US a EU,
dnes existuje jeho xml podoba, ale inak slo o format z cias salovych pocitacov, s velmi presne az obmedzujuco definovanymi datovymi formatmi a to ostalo do dnes.
Do PDF sa daju vlozit metada, co moze casto nahradit XML, v pripade faktury urcite ale obecne to nejde, neda sa vlozit akekolvek XML. To co sa robi je mat XML a vizualizacnu schemu ktora generuje PDF ale potom posielas aj PDF aj XML. Nie je to uplne dotiahnute.

A k projektu, aj smernica to hovori, snaha je povzbudit elektronicku vymenu udajov a kedze sa neda prikazat aby to firmy pouzivali, tak to tlaci v procese VO kde ma dosah.
Dnesny stav je teda taky ze mame standard ale male firmy ho nepouzivaju. Ciel projektu je vytvorit statny hub pre vymenu faktur so statom co povedie k upravam existujucich sw a ako backup pre tych co nemaju ani sw tam bude moznost nahrat fakturu rucne.
Mne to dava zmysel, idealne by bolo poskytnut hub aj pre ine ucely ale to by zrejme malo dopad na trh, likvidovalo by to dnesnych prevadzkovatelov EDI sluzieb. Ale urcite by to rozbehlo vymenu dokumentov

pozri ZUGFERD

1 Like

Ok toto sa ma tykat iba fakturacii v ramci verejneho obstaravania. Ale nemalo by to zabit konkurenciu v komercnej sfere

ano, ale uprimne zmysel by to davalo aj ako statny hub, kedze doteraz to konkurencia nevyriesila. Ale chapem ze to projekt nemoze takto slubit. Ale VO znamena ze ide o 90 percent faktur do verejnej spravy, co je uz vysoky trhovy podiel.

Ale mozno by sa dalo nieco vymysliet, napriklad ze sa spravi zdruzenie vsetkych co ponukaju elektronicku fakturaciu, budu prispievat na prevadzku a budu potom predavat pristup na hub. Ako rychly napad.

A k ZUGFERD, to je jedna z konkurecnych iniciativ k EDIFACTu, bohuzial ciste nemecka. A tam je to presne PDF kde su vlozene metadata.

A len pre doplnenie obrazu preco nie UPVS a co hovori smernica:
Zatiaľ čo odosielateľ elektronickej faktúry by mal mať naďalej možnosť zaručiť pravosť pôvodu a integritu obsahu faktúry viacerými spôsobmi, a to aj prostredníctvom elektronického podpisu, európska norma pre elektronickú fakturáciu by v záujme zabezpečenia súladu so smernicou 2006/112/ES nemala ako jeden zo svojich prvkov obsahovať požiadavku na elektronický podpis.

Na základe tejto smernice by mali byť povinní prijímať a spracúvať elektronické faktúry len príjemcovia faktúry, teda verejní obstarávatelia, centrálne obstarávacie organizácie a obstarávatelia. Touto smernicou by nemalo byť dotknuté právo odosielateľa faktúry vybrať si medzi predložením faktúry v súlade s európskou normou pre elektronickú fakturáciu, v súlade s vnútroštátnymi alebo inými technickými normami alebo v papierovej podobe. Touto smernicou by sa však členským štátom nemalo brániť v tom, aby určili, že v rámci verejného obstarávania sa môžu predkladať len elektronické faktúry. V prípade, ak sa odosielateľ rozhodne predložiť faktúru podľa európskej normy pre elektronickú fakturáciu, povinnosť príjemcu prijať a spracovať by mala platiť len vtedy, ak je faktúra v jednej zo syntaxí zahrnutých v zozname syntaxí, ktoré uverejnila Komisia v Úradnom vestníku Európske únie. Tým by nemalo byť dotknuté právo odosielateľa využiť služby tretej strany na preklad z jeho vlastnej syntaxe do jednej zo syntaxí v zozname.

Okrem toho by Komisia a členské štáty mali vynaložiť všetko úsilie na minimalizovanie nákladov spojených s európskou normou pre elektronickú fakturáciu vznikajúcich jej používateľom, najmä mikropodnikom, malým a stredným podnikom, aby sa uľahčilo jej zavádzanie v celej Európskej únii.

(41)

Členské štáty by pri vykonávaní tejto smernice mali zohľadniť potreby malých a stredných podnikov, ako aj menších verejných obstarávateľov a obstarávateľov, a verejným obstarávateľom, obstarávateľom, ako aj dodávateľom by mali poskytnúť nevyhnutnú podporu, aby mohli využívať európsku normu pre elektronickú fakturáciu. Okrem toho by sa mali naplánovať aj opatrenia týkajúce sa odbornej prípravy najmä pre malé a stredné podniky.

(42)

S cieľom uľahčiť technické a procesné úpravy, ktoré musia vykonať všetky strany zapojené do verejného obstarávania, aby sa zabezpečilo úspešné vykonanie tejto smernice, by členské štáty mali podľa možností sprístupniť pomoc zo štrukturálneho fondu všetkým oprávneným verejným obstarávateľom, obstarávateľom a malým a stredným podnikom.

Ja tam vidim 4 veci:

  1. standard
  2. centralny reporting
  3. centralne dorucovanie
  4. centralny fakturacny soft (case management, vytvaranie faktur…)

Prvy je bez debaty. Druhy ked chcu, tak ok chapem ze to je vynikajuci zdroj dat, ale nech ma pouzity (lubovolny) fakturacny soft obstaravatela povinnost zasielat faktury aj na centralny reporting. Ano vyriesit to v kombinacii s nejakym centralnym zarucenym dorucovanim (nie nutne nutnost el. podpisu) je lakave - ale na to snad uz nejake sluzby existuju https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/What+is+eDelivery+-+Overview

3 a 4 su z mojho pohladu nice to have a ich prinosy ako zasadne velmi nevidim.