Q & A 

Zákon definuje, aké doklady sa budú vyhotovovať v XML formáte.
Jedná sa o faktúru (aj súhrnnú), dobropis, ťarchopis a daňový doklad k prijatej zálohovej platbe. Je možné vystavovať aj tzv. self billing doklady.

Na zodpovedanie tejto otázky je potrebné poznať spôsob realizácie danej funkcionality v ERP zákazníka. Konkrétne riešenie sa navrhne počas implementácie.

Na zodpovedanie tejto otázky je potrebné poznať spôsob realizácie danej funkcionality v ERP zákazníka. Konkrétne riešenie sa navrhne počas implementácie.

Systém dokáže pracovať s dokladmi uvedenými v položke Typy dokladov (riadok 20).
Špecifické požiadavky je potrebné riešiť individuálne.

Funkcionalita pripojenia prílohy bude k dispozícii.

Pri účtovaní faktúry sa vytvorí tzv. e-dokument a až následne dochádza k odoslaniu ručným pokynom alebo naplánovaným jobom. Faktúra sa odosiela v stave, v akom sa v danom momente nachádza. Ak bola pred tým stornovaná e-dokument sa zruší a nebude sa dať odoslať.

Povinnosť vystaviť XML faktúru je definovaná zákonom o DPH (XML faktúry sa budú posielať aj neplátcom DPH, dôležitá je existencia DIČ,nie IČ DPH), ale systém nedokáže z dostupných údajov vždy posúdiť túto povinnosť napr. nevie, či predmetom dodania sú utajované skutočnosti, preto konečné rozhodnutie je na človeku.

Všetky MLS správy súvisiace s prenosom dokladu (aj TDD pre Finančnú správu) budú automatizovane prenesené a evidované v SAPe k danému dokladu.

Naše riešenie pracuje so self-billing faktúrami vo formáte BIS Self-billing 3.0, ktorý spĺňa normu EN16931 a je možné ich prenášať cez sieť Peppol. EDI self-billing faktúry by sa museli konvertovať do uvedeného formátu.

Ak je váš systém je aktualizovaný a updatovaný a ak vaša spoločnosť používa štandardné procesy SD, FI nepotrebujeme rozsiahle úpravy systému.
Pre každého zákazníka však budú potrebné minimálne úpravy napr. pri mapovaní polí, kalkulačných schémach, znakoch dane, formulároch … a zohľadnenie konkrétneho nastavenia systému v našom kóde.
Budeme potrebovať preniesť naše vývoje na Váš systém.

Naše riešenie je Zákaznícke API, podľa štandardov SAP –
neohrozuje budúce upgrade.
Ak upgrade zmení použitú komponentu, bude potrebné prispôsobenie kódu (platí všeobecne pre upgrady SAP).

Na zodpovedanie tejto otázky je potrebné poznať spôsob realizácie danej funkcionality v ERP zákazníka.
Konkrétne riešenie sa navrhne počas implementácie. V každom prípade súčasťou knižnice API rozhraní sú aj REST APIs a teda v princípe je týmto spôsobom možné napojiť aj roboty.

V SAP systémoch budú XML a PDF (ak je súčasťou XML) archivované v SAP.
V nonSAP systémoch si archiváciu súborov (XML) rieši zákazník svojpomocne, my ich tam len pošleme.

Zo strany Access Pointu je výkon škálovateľný podľa požadovaných objemov prenášaných dokumentov.
Odosielanie zo SAP je samostatný proces a nespomalí hromadné spracovanie.

Ak sa zmení technická norma XML, pôjde o pomerne zásadnú zmenovú požiadavku. Nami navrhovaný režim podpory umožní riešiť aj riadenie zmien, v tomto prípade sa však naozaj bude jednať skôr o projekt, nakoľko táto zmena sa dotkne aj komunikácie s obchodnými partnermi a bude treba riešiť fázovanie (dobeh pôvodných XML, nábeh zmenených).

Áno, ale až v ďalšej fáze, zatiaľ len Slovensko.
ČR a prípadne V4 až v ďalších fázach podľa potreby.

Áno, plánujeme informačný portál s potrebnými informáciami.

Odosielanie TDD dokumentov na Acces Point Finančnej správy je povinná funkcionalita, ktorú musí spĺňať Access Point a je predmetom certifikácie zo strany organizácie Open Peppol.
Jej funkčnosť nie je závislá na konkrétnom zákazníkovi.

Zabezpečujeme 99,5% dostupnosť nášho systému. Vzhľadom na zákonné lehoty vystavovania faktúr a dátumy pre výkazy DPH je táto dostupnosť dostatočná pre opakované odoslanie.
Riešenie umožňuje využívať automatizáciu procesov, ale táto možnosť nie je súčasťou štandardného riešenia.

mib:Cockpit je napojený na vlastné (nezávislé tabuľky), do ktorých sa načítavajú dáta priamo zo SAP tabuliek

Áno, poskytujeme aj službu nasadenia riešenia SAP DRC u zákazníka. Okrem implementácie sme schopní zabezpečiť aj licencovanie, nakoľko sme SAP VAR partnerom (v Čechách obdobne naša sesterská spoločnosť MIBCON a.s.).

Áno, je však potrebné zohľadniť skutočnosť, že sa jedná o rozšírenie základného rozsahu štandardnej implementácie.

Toto je možné až po prijatí faktúry do SAPu (pred jej zaúčtovaním), ale nie je to možné v Access Pointe prijímateľa, pretože ten nemá potrebné informácie.

BT-13 (referencia na objednávku) nie je povinné pole, takže ak nebude zadané, validátor nevráti chybu a faktúra bude doručená. Reklamovať neúplnú faktúru z biznisového pohľadu musíte mimo siete Peppol. Opravy faktúr zatiaľ nie sú na Slovensku povolené (uvažuje sa o zmene). Táto požiadavka by sa dala riešiť tým, že budete na objednávkach uvádzať položku „Buyer Reference“, ktorá bude obsahovať číslo objedávky. Buyer Reference (BT-10) tiež nie je samostatne povinná, ale aspoň jedna z položiek BT-10 a BT-13 musí byť zadaná. Ak by nebola vo faktúre vyplnená aspoň jedna z položiek, validátor faktúru vráti.

Táto situácia sa na Slovensku musí riešiť komunikáciou s dodávateľom (e-mail, telefonicky), ktorý musí cez Peppol zaslať dobropis k danej faktúre. Úspešne prenesenú faktúru nie je možné meniť ani zrušiť, len dobropisovať /ťarchopisovať.

Implementačné náklady sú spojené s nasadením riešenia. Jeho aktívne používanie je spoplatnené licenciou SaaS / rok, ktorej výška je podľa typu Plánu (Basic Plan 0-1.000 prenesených dokladov ročne, Professional Plan 10.000 – 29.999 prenesených dokladov ročne, Enterprise Plan – 30.000 – 299.999 prenesených dokladov ročne) plus je spoplatnená nadspotreba nad tieto limity. Klienti, ktorí to začnú používať už počas roka 2026, platia len proporčnú časť od sprístupnenia – napríklad používanie len v poslednom štvrťroku 2026 cena bude 1/4 z ročnej licencie.

Nie, takýto typ zásadnej zmeny – t.j. zmena noriem XML v SK/EU – nie je zahrnutá v základnej cene. Ak v budúcnosti k takej zmene dôjde, máme v úmysle včas oznámiť zákazníckej klientele dopad aktualizácie a na základe spätnej väzby spravodlivo rozdeliť náklady spojené s jej zabezpečením.

Aktuálne sa pochopiteľne zameriavame na Slovensko, následne ho chceme rolovať pre Česko aj pre viaceré ďalšie členské krajiny organizácie OpenPeppol, kde podnikajú aj naši CZ a SK zákazníci.
Ďalšie krajiny nášho CEE regiónu s výnimkou Rakúska zatiaľ nie sú členmi OpenPeppol, preto v prípade Maďarska a Poľska budeme môcť z nášho riešenia využiť len časť riešenia v prostredí SAP, pretože platforma digitálnej komunikácie je iná.

Krajiny s priamym nasadením PEPPOL (Belgicko, Slovensko, Lotyšsko, Dánsko, Nórsko, Estónsko, Rakúsko, Slovinsko, Luxembursko) používajú sieť Peppol priamo ako infraštruktúru pre prenos faktúr.
Krajiny s národnými sytémami (Taliansko – SDI/FatturaPA, Poľsko – KSeF, Maďarsko – NAV Online) si vybudovali vlastné clearingové platformy nezávislé od PEPPOL, hoci PEPPOL môžu používať pre cezhraničné transakcie.

Fiškálna archivácia musí byť zabezpečená v prostredí SAP (respektíve vo všeobecnosti v ERP systéme). V prostredí mib:Peppol sú archivované len XML súbory a MLS odpovede.

Áno, prezentácia z webinára je aj v angličtine. Jej súčasťou sú aj porovnania oboch riešení.