Časté chybové hlásenia pri odosielaní faktúr s príčinami a riešeniami.
Pri odosielaní faktúry cez platformu eConnect sa môže stať, že dostanete chybové hlásenie. Väčšina chybových hlásení súvisí s chýbajúcimi alebo nesprávnymi údajmi vo faktúre. Nižšie nájdete časté hlásenia, ich príčinu a spôsob riešenia.
Toto všeobecné chybové hlásenie je spustené pre-odosielacou validáciou v rozhraní platformy. Platforma pred odoslaním kontroluje, či hodnota identifikátora (napr. OINO, IČO) zodpovedá očakávanému formátu. Ak táto kontrola zlyhá, zobrazí sa toto chybové hlásenie.
Podávanie cez AFAS / E-verbinding: na otázku „môžem odoslat’ znova z AFAS alebo E-verbinding?“ je odpoveďou zvyčajne znova odoslat’ prostredníctvom platformy (Odoslaná pošta > Znovu odoslat’), nie znova vygenerovat’ v AFAS -- pokiaľ je dokument už v odoslanej pošte. Červená chyba „Neznáma chyba pri volaní udalosti aplikácie“ pri opakovanom odoslaní je takmer vždy rovnaká validácia schémy/hodnoty ako vyššie, nie samostatná poruch AFAS. Pozri tiež sekciu „Znovu odoslat’ faktúru s opraveným odkazom“ nižšie.
Častý príklad: schemeID 0190 (OINO) vyžaduje presne 20 číslic. Ak hodnota obsahuje prefix — napr. NL:OINO:00000001001932779000 namiesto len 00000001001932779000 — validácia zlyhá.
Poznámka: táto chyba sa môže vyskytnúť aj pri faktúrach vytvorených cez API, nielen pri ručne vytvorených faktúrach.
Riešenie: skontrolujte hodnoty identifikátora a odstráňte prípadné prefixy alebo neplatné znaky. Hodnota musí presne zodpovedať očakávanému formátu pre schemeID (napr. 20 číslic pre OINO, 8 číslic pre IČO).
Všeobecné pravidlo -- zadajte iba číselnú hodnotu; platforma prida prefix schemeID automaticky. Platí pre všetky identifikačné schémy, nielen OINO. Ak používateľ zadá aj prefix (napr. 0088:1234567890123, pričom schéma je už nastavená na GLN/0088), validácia formátu zlyhajú. Príklad GLN (schemeID 0088, GS1): vyberte schému GLN a do poľa hodnoty zadajte iba číslice GLN -- bez 0088: na začiatku.
Ak dodávateľ umiestni apostrof pred číslo OIN v XML (známy artefakt Excelu), Peppol routing zlyhá. Legacy systém faktúru rozpozná a doručí ju interne — príjemca nevidí faktúru vo svojej schránke záväzkov, ale dostane e-mail s oznámením s odkazom.
Riešenie: požiadajte dodávateľa, aby v XML uviedol číslo OIN bez apostrofu a skontroloval nastavenia exportu Excelu.
Platforma validuje každú faktúru podľa platných štandardov Peppol a NLCIUS pred jej odoslaním. Kódy chýb začínajúce na BR (Business Rule) ukazujú, ktoré pravidlo nebolo dodržané.
Vaša organizácia (dodávateľ) nie je správne vybraná vo faktúre. Toto sa stane, keď bolo pole dodávateľa manuálne zmenené alebo keď organizácia ešte nie je aktivovaná.
Riešenie: Kliknite na ikonu ceruzky vedľa "Dodávateľ" a znovu vyberte svoju organizáciu. Ak Vaša organizácia ešte nie je aktivovaná, urobte to najprv cez Pridanie a aktivácia organizácie.
Pridali ste prílohu s typom MIME, ktorý nie je povolený v aktuálnej validácii Peppol BIS Billing V3. Povolené typy príloh sú (BT-125):
application/pdf)image/png)image/jpeg)text/csv)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet)application/vnd.oasis.opendocument.spreadsheet)application/xml nie je povolený ako typ MIME prílohy v aktuálnej validácii BIS Billing V3. XML ako príloha patrí do EN 16931-1:2026 a budúcej verzie Peppol (pravdepodobne BIS Billing 4.0) — nepridávajte XML prílohu ako riešenie BR-CL-24.
Častá príčina (Business Central a iné ERP): ERP automaticky vkláda prílohy pridané k zaučtovanej faktúre. Príloha s nepovoleným typom (napr. dokument Word) spôsobí BR-CL-24.
Riešenie:
Vyhľadávacie varianty: "BR-CL-16", "Payment means in an invoice MUST be coded using UNCL4461 code list", "PaymentMeansCode prázdne", "UNCL4461", "BT-81 neplatné".
BR-CL-16 nastane, keď Payment means type code (BT-81, cbc:PaymentMeansCode v cac:PaymentMeans) je prázdne, obsahuje voľný text, alebo nie je uvedené v zozname kódov UNCL4461. Doslovná chybová správa znie okrem iného: "Payment means in an invoice MUST be coded using UNCL4461 code list".
Riešenie: nastavte PaymentMeansCode na platný kód UNCL4461, napr. 30 (bankový prevod), 49 (inkaso), 58 (SEPA prevod) alebo 59 (SEPA inkaso). Ide o opravu v zdrojovom UBL u odosielateľa -- pri prijatej a ďalej odoslanej faktúre (InvoiceReceived) je PaymentMeans 1:1 priechodné, takže opätovné odoslanie bez opravy nepomôže. Overte vopred pomocou Document Validatora.
Jednotka, ktorú ste zadali pri riadku faktúry, nie je rozpoznaná ako platný UN/ECE kód. Toto sa stane, ak použijete skratku alebo vlastný názov.
Riešenie: Použite štandardnú jednotku z výberového zoznamu, ako napríklad "Kusy" (EA), "Hodiny" (HUR) alebo "Dni" (DAY).
Typ identifikátora pri "OrganisatieID" sa líši od typu identifikátora pri "Odoslať cez". Napríklad: OrganisatieID je nastavené na OIN, ale "Odoslať cez" je nastavené na IČO.
Riešenie: Uistite sa, že obe polia používajú rovnaký typ identifikátora. Fakturujete vládnej organizácii? Nastavte obe na OIN/OINO. Fakturujete spoločnosti? Použite pri oboch IČO (0106).
Číslo DPH dodávateľa chýba vo faktúre.
Riešenie: Vyplňte svoje číslo DPH v nastaveniach organizácie.
Ak vaša organizácia nemá číslo DPH (napríklad nadácia, verejný subjekt alebo poskytovateľ zdravotnej starostlivosti poskytujúci výlučne služby oslobodené od DPH)? Nepoužvájte zástupnú hodnotu NL000000000B01. Namiesto toho zvoľte kategóriu DPH 'O' — mimo rozsahu DPH pri vystavovaní faktúry. Pri kategórii 'O' odpadá povinnosti vyplniť číslo DPH a faktúra spĻaňa štandard Peppol.
Nadácie, niektoré verejné subjekty a poskytovatelia zdravotnej starostlivosti poskytujúci výlučne služby oslobodené od DPH nemá číslo DPH. Pri vytváraní faktúry na platforme sa zobrazí pożiadavok na uvedení čísla DPH dodávateľa.
Riešenie: Zvoľte kategóriu DPH 'O' — mimo rozsahu DPH (kód UNCL5305 O, "Services outside scope of tax") vo formulári faktúry. Pri kategórii 'O' odpadá pożiadavok rozhrania na pole čísla DPH a faktúra môže byť odoslaná bez čísla DPH dodávateľa.
Nepoužvájte fiktívne čísla DPH ako NL000000000B01 — to nie je určené riešenie pre tento scenár. Kategória 'O' je správnou voĺbou pre organizácie bez povinnosti k DPH.
Rozdiel 'E' a 'O': Kategória DPH 'E' (Exempt from VAT) je určená pre plátcöv DPH fakturujúcich konkrétne oslobodené plřnèenie. Kategória 'E' vyżaduje číslo DPH. Kategória 'O' je pre organizácie bez akéjkoĺvek povinnosti k DPH.
Pri kategórii O nevypĺňajte do poľa čísla DPH náhradnú hodnotu. Hodnoty ako nvt, n/a, NA alebo pomlčka nie sú platné číslo DPH a aj tak spôsobia chybu validácie. Organizácia štrukturálne nemá číslo DPH? Zvoľte kategóriu O a ponechajte pole čísla DPH prázdne — nič doň nevpisujte.
Varianty vyhľadávania: "Typ DPH je povinný na položke faktúry", "I18N_INV.UI.VALUE_MISSING", "prázdny rozbaľovací zoznam DPH položka faktúry", "koncept faktúry nemožno uložiť DPH", "SnelStart XML koncept kategória DPH".
Táto správa sa zobrazí, keď kategória DPH (rozbaľovací zoznam DPH) zostala prázdna aspoň na jednej položke faktúry. Správa blokuje ako Uložiť, tak aj Odoslať. Toto sa často vyskytuje pri XML dodanom cez Emailového príjemcu (napríklad zo SnelStart), ktoré príde ako koncept bez platnej kategórie DPH na položku.
Riešenie:
BE0665904901 pre Belgicko), pozri BR-CO-09 nižšie.Štrukturálne pri dodaní ERP/XML: neúplný export z účtovného alebo fakturačného softvéru vedie k nespoľahlivému automatickému odosielaniu (auto-send). Dodávateľ softvéru musí dodať platnú kategóriu DPH na položku faktúry v XML.
Pozri tiež "Pole Dodávateľ je rozbaľovací zoznam, nie pole pre voľný text" a BR-CO-09 vyššie, a Emailový príjemca pre auto-send XML (len s platným XML).
Pri fakturácii holandskej Rijksoverheid (Basisfactuur Rijk, cez Digipoort) je IBAN povinný.
Riešenie: Vyplňte svoje IBAN v platobných údajoch faktúry. Vo všeobecnosti sa odporúča vždy uviesť IBAN na faktúre, pretože táto povinnosť sa bude v budúcnosti rozširovať.
Táto chyba nastane, keď CompanyID (pole PartyLegalEntity v UBL) obsahuje číslo DPH namiesto IČO alebo OIN. To nie je povolené: validácia NLCIUS vyžaduje, aby holandské strany vždy používali IČO (schemeID 0106) alebo OIN (schemeID 0190) ako CompanyID. NL-R-003 platí pre dodávateľa, NL-R-005 pre zákazníka.
Zámenou vzniká preto, že EndpointID (Peppol adresa používaná na smerovanie) môže obsahovať číslo DPH (schemeID 9944). Faktúra s číslom DPH ako EndpointID sa teda na sieti Peppol doručí bez problémov, ale bude zamietnutá, ak je rovnaké číslo DPH aj v CompanyID.
Technicky: EndpointID a CompanyID sú dve oddelené polia s vlastným účelom. EndpointID určuje smerovanie cez Peppol a akceptuje každý typ z EAS kódovej listiny (vrátane 9944 pre čísla DPH). CompanyID identifikuje právnickú osobu a pre holandské strany musí byť vždy IČO (0106) alebo OIN (0190).
Riešenie: Skontrolujte UBL, ktorú Váš systém generuje, a uistite sa, že CompanyID obsahuje IČO alebo OIN, aj keď EndpointID obsahuje číslo DPH. Obe polia musia odkazovať na rovnakú organizáciu, ale môžu mať rôzny typ identifikátora.
Tip: Legislatíva ViDA postupne sprísňuje vzťah medzi EndpointID a CompanyID. Uistite sa, že Vaša integrácia je už teraz správne nastavená, aby Vás neprekvapili budúce zmeny pravidiel.
Varianty vyhľadávania: "OP-T10-R008", "Party Company Identifier Scheme", "schemeID NL:KVK", "schemeID NL:VAT", "písmenový kód schemeID CompanyID", "CompanyID scheme neplatný".
OP-T10-R008 (Party Company Identifier Scheme) nastáva, keď atribút schemeID na poli Party CompanyID (PartyLegalEntity/CompanyID alebo PartyIdentification) obsahuje historický písmenový kód, ako NL:KVK alebo NL:VAT, namiesto numerického kódu PEPPOL. To nie je povolené: validácia vyžaduje scheme z oficiálneho zoznamu identifikácie strán PEPPOL.
Písmenový kód NL:KVK je Peppol Service Bus (PSB) považovaný za smerovací alias scheme 0106, to sa však nevzťahuje na toto pole UBL -- ide o dva odlišné kontexty.
Riešenie: nahraďte písmenový kód numerickým kódom EAS, napríklad schemeID="0106" pre holandské IČO:
<cbc:CompanyID schemeID="0106">12345678</cbc:CompanyID>
Prázdne pole CompanyID spadá pod iné pravidlo -- pozri "NL-R-005 / NL-R-003" vyššie. Viac informácií o typoch identifikátorov a schemeID: Party identifiers.
Varianty vyhľadávania: "BR-AE-10", "SOAP:CLIENTBR-AE-10", "Reverse charge shall have a VAT exemption reason", "BT-120", "BT-121", "chýba dôvod oslobodenia prenesenie daňovej povinnosti", "faktúry zamietnuté reverse charge".
BR-AE-10 nastane, keď kategória DPH AE (Reverse Charge) v rozpise DPH (BG-23) neobsahuje dôvod oslobodenia: chýba BT-121 (kód) aj BT-120 (text, napríklad "DPH prenesená" alebo "Reverse charge"). Ide o chybu v dodanom UBL z ERP alebo fakturančného softvéru -- eConnect faktúru validuje, ale polia AE automaticky neupravuje.
Riešenie:
Pozrite tiež Prenesenie daňovej povinnosti: kódy K, AE a G pre úplné vysvetlenie kódov prenesenia daňovej povinnosti.
Tieto validačné pravidlá EN 16931 kontrolujú, či sú rozpad DPH a celkové sumy faktúry vzájomne konzistentné. Hodnoty vypočítava odosielajúci softvér — nie sú to polia, ktoré by sa dali opraviť v rozhraní eConnect.
Vyhľadávacie varianty BR-CO-12 / BR-E-01: "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "súčet príplatkov nesedí", "poštovné chýba na riadku faktúry", "Shipping costs AllowanceCharge", "chýba rozpad Exempt".
BR-CO-12 nastáva, keď súčet príplatkov na úrovni faktúry nezodpovedá súčtu jednotlivých príplatkov dokladu — napríklad keď je poštovné uvedené ako samostatný AllowanceCharge na úrovni faktúry (ChargeIndicator=true, dôvod "Shipping costs" / kód FC). Ide o platné UBL; pozri Príplatky a zľavy pre štruktúru. BR-E-01 nastáva, keď riadok faktúry, príplatok alebo zľava dokladu s kategóriou DPH 'Oslobodené od DPH' (E) nemá zodpovedajúci rozpad Exempt v súhrne DPH.
Častá príčina: zaokrúhľovanie DPH na každom riadku namiesto podľa sadzby DPH alebo nesúlad medzi sumami riadkov a zľavami na úrovni faktúry.
Riešenie: kontaktujte dodávateľa odosielajúceho softvéru pre opravu. eConnect nemôže tieto hodnoty opraviť, pretože výpočet je pevne daný v dodanom XML.
Varianty vyhľadávania: „Invalid payload BR-S-08“, „Delivery Failed BR-S-08“, „súhrn DPH nesedí“, „riadok faktúry bez množstva“, „chýba množstvo na riadku faktúry“, „BT-116“, „VAT category taxable amount“.
Okrem zaokrúhľovania zlyháva BR-S-08 aj vtedy, keď riadok faktúry nemá množstvo (alebo má prázdne množstvo) (Invoiced quantity / BT-129). V takom prípade nesedí suma riadku bez DPH (množstvo x jednotková cena plus prirážky riadku mínus zľavy riadku), čo spôsobí, že súčet riadkov sa odchýli od VAT category taxable amount (BT-116) v rozpade DPH pre Standard rated. Doslovná chybová hláska často vyzerá takto: Invalid payload. [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is Standard rated, the VAT category taxable amount (BT-116)....
Rozdiel oproti chybám xs:decimal: v časti „'nie je platným xs:decimal'“ vyššie samotné pole sumy nie je platné desatinné číslo (prázdne alebo vedecká notácia). Pri BR-S-08 je pole sumy platné číslo, ale výpočet medzi sumami riadkov a rozpadom DPH nesedí.
Kontrolný zoznam prvej línie (pred eskaláciou na dodávateľa softvéru):
Kategória DPH E vs. O: nemá organizácia číslo DPH (nadácia, verejný subjekt, zdravotníctvo)? Použite kategóriu O (mimo rozsahu DPH) — pozri časť »Organizácie oslobodené od DPH: kategória O« vyššie. Kategória E vždy vyžaduje číslo DPH.
Varianty vyhľadávania: „Processing is not possible“, „We were unable to process the UBL invoice in the attachment“, „BR-CO-18“, „BR-Z-01“, „BR-Z-05“, „Zero rated“, „nulová sádzba UBL“, „chýba rozpis DPH BG-23“, „XML + PDF odoslané spolu“, „UBL zamietnutý PDF aj tak spracovaný“, „potlačenie chybového hlásenia XML“, „ditch the XML“.
Zero rated (Z, 0 % DPH) nie je synonymom pre oslobodenie (kategória E) alebo prenos daňovej povinnosti DPH (kategória AE) -- riadky, sádzby a súmy DPH musia byť vzájomne konzistentné:
Kombinácia XML + PDF v jednom e-maile (dual-path): ak príde e-mail s prílohou XML aj PDF a XML je zamietnutý na jednom z týchto pravidiel, e-mail platformy môže zobraziť „Processing is not possible“ alebo „We were unable to process the UBL invoice in the attachment“ -- zatiaľ čo PDF bolo spracované a nachádza sa v doručenej pošte. Nejde o dvojité zlyhanie: obe prílohy sú posudzované osobitne a chybové hlásenie týkajúce sa XML nemožno potlačiť, kým sú prítomné iné úspešne spracované prílohy.
Všetky tieto chyby sú v odoslanom UBL od odosielateľa alebo jeho softvéru. eConnect neupravuje polia DPH v odoslanom XML; opakované odoslanie rovnakého, chybného XML nič nerieši -- je potrebná nová, opravená faktúra. Vopred možno overiť pomocou Document Validator.
Riešenie (vyberte jednu z týchto štruktúrnych ciest):
Ak faktúra ide cez Peppol alebo natívny UBL, možnosť 1 je jediným štruktúrnym riešením -- PDF tam nie je náhradou za platný UBL.
Varianty vyhľadávania: „Chyba Peppol“, „stav doručenia“, „stav doručenia vo vlastnom softvéri“, „zaokrovľDŽovanie v čase“, „dve desatinné miesta zdrojový softvér“, „sumy bez DPH nesprávne“, „nová dávka rovnaká chyba“.
Triage pri viacerých možných príčinách („Chyba Peppol“ / stav doručenia ERP): rovnaký tiket môže obsahovať tak výpočtovú chybu R120, ako aj chybu schémy EndpointID. Postupujte v tomto poradí:
Táto chyba je hlásená aj ako chyba „sum invoice line". R120 je výpočtové pravidlo, ktoré kontroluje, či LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + prirážky − zľavy. R120 výslovne nezakazuje záporné sumy; validácia zlyhá, keď výpočet nesedí. To sa často stáva, keď riadková zľava (AllowanceCharge na úrovni riadku) prevyšuje cenu položky, napríklad v dobropise s vysokou zľavou.
Oprava patrí odosielaciemu softvéru (programu, v ktorom bola faktúra vytvorená), nie eConnect: eConnect neupravuje sumy v odoslanom XML.
Riešenie: použite čistú čiastku dobropisu priamo ako PriceAmount a vynechajte element AllowanceCharge na riadku. Podrobnosti a príklad XML nájdete v článku o príplatkoch a zľavách. Vyžiadanie súboru XML faktúry je potrebné len ako hĺbková analýza pri neobvyklom vzore, nie ako prvý krok.
Opakované odoslanie R120 nerieši. Odoslať znova v odoslanej pošte opravuje polia smerovania a referencií (ako EndpointID alebo číslo objednávky) — nie sumy riadkov ani riadkové zľavy. Pri R120 nemá opakovanie toho istého dokumentu zmysel: opravte výpočet v odosielacom softvéri alebo vytvorte nový doklad.
Faktúra vytvorená priamo na platforme (žiadny externý XML z ERP)? Vytvorte novú predajnú faktúru — doklad v odoslanej pošte je len na čítanie a nedá sa vymazať. Uistite sa, že množstvo × cena za jednotku sa rovná sume riadku pre každý riadok, bez samostatnej riadkovej zľavy prevyšujúcej cenu položky; v prípade potreby zadajte priamo čistú cenu. Znovu vyberte príjemcu a odošlite cez Peppol. Neúspešný doklad môže zostať v odoslanej pošte; označenie ako duplikátu nie je problém.
Opravná faktúra z AFAS (cez eVerbinding) nedorazila. Keď opravná faktúra odoslaná cez AFAS a eVerbinding spustí R120, text chyby nemusí R120 priamo pomenovať: stav potom zobrazuje „doručenie zlyhalo" alebo „document format not supported by receiver", často po neúspešnej transformácii NLCIUS na Peppol BIS. Ide o dôsledok chyby validácie obsahu, nie dôkaz, že príjemca je nedostupný alebo faktúru odmieta.
Poradie diagnostiky: najprv logy, XML len pre hĺbkovú analýzu.
eConnect nekonvertuje množstvá ani ceny. Pri správnom kreditnom alebo opravnom riadku sa očakáva záporné množstvo a kladná cena za jednotku (celková suma je potom záporná). eConnect nemení znamienko množstiev ani cien zo záporného na kladné ani naopak — R120 zlyhá na výpočte v odoslanom XML zo zdrojového systému (napr. AFAS). Skutočnosť, že rozhranie platformy zobrazuje iba PDF bez samostatného zobrazenia XML, neznamená, že eConnect prepisuje sumy.
Aj bez riadkovej zľavy (čistý nesúlad množstvo × cena). R120 zlyhá aj vtedy, keď na riadku nie je žiadne AllowanceCharge, ale Quantity × (PriceAmount / BaseQuantity) nezodpovedá LineExtensionAmount. To zvyčajne naznačuje desatinnú chybu alebo chybu faktora 100 v cene alebo sume riadku vo zdrojovom XML, napríklad 200 × 5,14 = 1028,00 namiesto 10,28. V takom prípade prekontrolujte polia XML ručne -- nielen súhrny zobrazené v rozhraní.
Súhrny na obrazovke sú správne, ale R120 stále zlyháva. Klient môže uviesť, že sumy na obrazovke návrhu sú správne; to R120 nevylučuje. R120 kontroluje polia v XML (Quantity, PriceAmount, BaseQuantity, LineExtensionAmount, AllowanceCharge), nie to, čo je zobrazené na obrazovke. Ak faktúra návrhu alebo dodané zdrojové XML stále zlyháva na R120, opravte to v zdrojovom systéme a odošlite nový alebo opravený dokument. Ručná úprava OrganisationID alebo jednotky R120 nevyrieši -- ide o iné validačné pravidlá.
Tieto tri chybové kódy sa zobrazujú, keď bola faktúra technicky odoslaná, ale príjemca alebo validátor odmieta obsah na základných poliach v UBL/XML. Príčina je v samotnom XML súbore, nie v pripojení Peppol, Peppol ID alebo spôsobe doručenia odberateľovi.
cbc:CustomizationID (BT-24)urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0::2.1) -- to nepatrí doslovne do CustomizationID. Pozri BIS Billing 3.0 pre úplnú štruktúru typu dokumentu.cbc:ProfileID (BT-23)urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 (štandardná faktúra/dobropis)Unknown, prázdna alebo akýkoľvek text naznačuje nerozpoznaný profil Peppol billing v zdrojovom softwari. Nejde o poruchu na strane eConnect.Riešenie: upravte príslušné polá v softwari, v ktorom sa faktúra vytvára -- CustomizationID a ProfileID sú pevné hodnoty pre daný typ dokumentu, nie nastavenie na platforme eConnect. Ak chýba BuyerReference aj OrderReference, doplnte jedno z nich pred opakovaným odoslaním faktúry.
Upozornenie k R007 a iným BIS profilom: predvolená hodnota v tabuľke platí pre bežnú faktúru/dobropis. Self-billing a ďalšie profily Peppol BIS (napr. self-billing invoicing) majú svoj vlastný, odlišný ProfileID. Nevynútte predvolenú hodnotu na faktúrách, ktoré vedome používajú iný BIS profil -- najprv skontrolujte, aký profil sa použije, skôr než túto FAQ použijete.
Nezamšťať s: chýbajúcou registráciou Peppol u príjemcu, nesprávnym EndpointID, výpadkom Access Pointu alebo hlásením "žiadne validačné pravidlá k dispozícii" (pozri príslušnú sekciu nižšie) -- tieto prípady majú iné symptómy ako táto kombinácia špecifikácie, profilu a referencií.
Zdroj: ticket #15272547 (2026-07-28).
Vyhľadávacie varianty: "P0112", "invoice type code 326 or 384 is only allowed when both buyer and seller are German organisations", "typový kód 326", "čiastočná faktúra", "kde zmeniť typ faktúry", "zmena kódu typu faktúry v portáli", "nevidím pole pre typ faktúry", "384 francúzske predajné faktúry", "debet a kredit na tej istej faktúre Francúzsko", "opravná faktúra nie vo Francúzsku", "obe strany nesídlia vo Francúzsku", "obe strany nie sú v krajine X", "InvoiceTypeCode 384 FR", "P0112 Francúzsko", "mixed debit credit BIS 3.0", "rozdelenie 380 381".
Táto chyba sa objavuje, keď cbc:InvoiceTypeCode (BT-3) má hodnotu 326 (čiastočná faktúra) alebo 384 (opravná faktúra), zatiaľ čo dodávateľ a príjemca nie sú obaja nemecké organizácie. Pravidlo Peppol BIS Billing 3.0 PEPPOL-EN16931-P0112 povoľuje 326 a 384 len, ak sú obe strany nemecké.
Žiadne FR-špecifické pravidlo: text chyby alebo vlastná interpretácia o "obe strany nesídlia vo Francúzsku" alebo "nie sú v krajine X" je nesprávna parafráza. P0112 testuje výhradne Nemecko (dodávateľ a príjemca), nie krajinu faktúry alebo sídlo francúzskych strán. Odchodzýci francúzsky subjekt s typovým kódom 384 na BIS Billing 3.0 naráža na rovnaké obmedzenie DE→DE -- neexistuje samostatná cesta "FR opravná faktúra".
UI portálu: výber typu faktúry je vpravo na koncepte faktúry. Klientske štítky zahŕňajú okrem iného čiastočná faktúra (vedla štandardných termínov "opravná faktúra" a "obchodná faktúra") -- ľahko previdýteľné.
Riešenie (portál, faktúra NL alebo nie-DE, vrátane FR/BIS 3.0):
Zdroj: Peppol BIS Billing 3.0 -- PEPPOL-EN16931-P0112.
Táto chyba sa vyskytuje na riadku (riadkoch) faktúry s kategóriou DPH Dodánie v rámci Spoločenstva / Intra-community supply (K, BT-151), keď chýba povinný údaj o DPH. Pri kategórii K sú povinné: DPH dodávateľa (seller VAT, BT-31) alebo DPH daňového zástupcu (seller tax representative VAT, BT-63), a DPH kupujúceho (buyer VAT, BT-48). Chýbajúce údaje sa nachádzajú v údajoch strany (organizácie alebo odberateľa), nie na samotnom riadku faktúry. Chybové hlásenie neukazuje na jedno konkrétne číslo riadku -- pravidlo sa spustí, hneď ako jeden z riadkov faktúry použije kategóriu K.
Riešenie:
Belgické Peppol ID môžu mať dve formy:
0208:9925:BE + 10 číslic; BE1xxxxxxxxx je platné od roku 2025)Formát čísla DPH: BE nasledované presne 10 číslicami (pridať úvodné nuly ak treba). Overte číslo DPH prostredníctvom nástroja VIES Európskej komisie (ec.europa.eu/taxation_customs/vies).
Možnosť Peppol sa nezobrazuje pre belgického odberateľa? Skontrolujte, s akým typom identifikátora je odberateľ registrovaný na Peppol. Niektoré belgické organizácie sú registrované len cez 0208: (KBO), nie cez 9925: (DPH). V takom prípade skúste číslo KBO: číslo DPH bez BE na začiatku (napr. pre BE0123456789 je číslo podniku 0123456789; pre BE1xxxxxxxxx je to 1xxxxxxxxx -- oba prefixy sú platné).
Ostatné: záporné cenové riadky nie sú v belgických faktúrach povolené; použite záporné množstvo s kladnou cenou.
Kódy chýb BR-DE-* sú nemecké validačné pravidlá špecifické pre XRechnung.
Chýbajúci Leitweg-ID (EAS 0204): časté pri fakturácii nemeckým vládnym orgánom. Vyžiadajte Leitweg-ID od zmluvného úradu a pridajte ho ako identifikátor so schemeID 0204.
PDF neprijaté: od 1. januára 2025 platí v Nemecku povinnosť prijímať e-faktúry. Prostý PDF často už nestačí. Odošlite faktúru ako XRechnung alebo ZUGFeRD.
Odmietnutie KSeF: často spôsobené neplatným formátom XML FA_VAT. PSB eConnect normálne zabezpečuje správnu transformáciu do poľského formátu KSeF.
Chyby certifikátov: môžu sa vyskytnúť, ak certifikáty KSeF nie sú správne nainštalované alebo vypršali.
Obmedzenie rýchlosti: KSeF uplatňuje limity na počet požiadaviek. eConnect používa dávkové spracovanie, aby tomu predišiel.
UWV uplatňuje vlastné validačné pravidlá nad rámec štandardnej validácie Peppol/NLCIUS.
0000000419177124900000000004172892677000Riešenie podľa kódu UWV: doplňte chýbajúce pole na faktúre. Séria UWV001 sa týka povinných polí dodávateľa; séria UWV002 identifikačných prvkov.
Toto hlásenie sa zobrazí v Odoslanej pošte, keď faktúru nebolo možné doručiť príjemcovi cez sieť Peppol. Možné príčiny:
Pri zlyhanom doručení môžete faktúru odoslať znova a pritom opraviť EndpointID.
Pole dodávateľa neobsahuje žiadne údaje. Toto sa stane, ak Vaša organizácia nie je vybraná alebo ak organizácia nie je aktivovaná.
Riešenie: Kliknite na ikonu ceruzky vedľa poľa dodávateľa a vyberte svoju organizáciu. Ak Vaša organizácia ešte nie je aktivovaná, postupujte podľa krokov v časti Pridanie a aktivácia organizácie.
Číslo DPH musí byť zadané bez medzier, bodiek alebo pomlčiek, vrátane kódu krajiny. Správny formát pre Holandsko je NL123456789B01. Belgické čísla DPH musia byť zadané ako BE nasledované presne 10 číslicami, bez oddeľovačov.
Ak zadaná suma zmizne, keď prejdete na ďalší krok, pole pravdepodobne obsahuje znaky, ktoré nie sú povolené. Pole sumy akceptuje len čísla s čiarkou ako desatinným oddeľovačom. Sumy zadávajte ako 100,00, nie ako € 100,00 alebo 100.00.
Varianty vyhľadávania: "červená ikona stop odoslanie", "červené kolečko odoslanie", "faktúru nemožno odoslať", "odosielanie zlyháva", "ikona stop faktúra", "poznámka k faktúre povinná", "IBAN bankový účet povinný", "viac informácií poznámka k faktúre", "platobné údaje IBAN prázdne", "povinné polia odoslanie faktúry".
Pri odosielaní ručnej predajnej faktúry sa môže zobraziť červená ikona stop: faktúra sa neodošle. Príčinou je validácia formulára na strane klienta -- nejde o chybu Peppol ani siete, ani o chybu platformy. Odberateľ/OIN, dosiahnuteľnosť cez Peppol a číslo objednávky môžu byť už v poriadku, zatiaľ čo odoslanie napriek tomu zlyháva, pretože iné povinné pole zostalo prázdne.
Skontrolujte tieto dve polia:
Rozdiel oproti iným blokáciám:
Odosielanie stále zlyháva aj po vyplnení oboch polí? Vyžiadajte si snímku obrazovky s presnou chybovou správou, nielen s ikonou stop.
Varianty vyhľadávania: "číslo bankového účtu nie je správne formátované", "bankový účet nie je správne formátovaný", "IBAN nie je správne formátovaný", "chyba formátu IBAN", "medzery v IBAN", "formátovanie IBAN platobné údaje", "chyba IBAN pri odosielaní ručnej faktúry".
Pri odosielaní ručnej predajnej faktúry sa môže zobraziť správa, že číslo bankového účtu alebo IBAN nie je správne formátované, aj keď je číslo obsahovo správne. Príčinou je validácia formátu pred odoslaním pre IBAN alebo bankový účet v sekcii Platobné údaje -- nejde o chybu Peppol ani siete. Medzery, pomlčky alebo iné oddeľovače (alebo chýbajúci kód krajiny) spôsobia, že kontrola zlyhá.
Riešenie:
NL00BANK0123456789).NL.Rozdiel oproti iným blokáciám:
Správa sa stále zobrazuje? Vyžiadajte si presný obsah poľa (vrátane medzier alebo znakov) a doslovnú chybovú správu alebo snímku obrazovky.
Varianty vyhľadávania: "tlačidlo odoslať nereaguje", "obrazovka načítavania sa zasekne pri odosielaní", "čudný text na faktúre", "čudné meno dodávateľa", "nelogická jednotka na faktúre", "organizácia zobrazuje čudný text", "opakované prihlásenie pre uloženie", "znovu prihlásiť sa pre odoslanie", "polí faktúry preložené", "preklad prehliadača pri vytváraní faktúry", "nemôžem sa prihlásiť", "čudný text na prihlasovacej stránke".
Ak tlačidlo odoslať nereaguje alebo obrazovka načítavania zostáva zaseknutá pri odosielaní faktury Peppol a vidíte nepreloženú syntax šablóny ako {{invoice.data.supplierDetails.name}} namiesto vyplnených hodnôt, príčinou je pravdepodobne automatický preklad prehliadača.
Rovnaký vzor sa môže vyskytnúť pri vytváraní (novej) faktúry: nelogické alebo "preložené" popisky/hodnoty polí, okrem iného pri dodávateľovi, organizácii a jednotke, kde uloženie alebo odoslanie sa podarí až po opakovanom prihlásení. Má to rovnakú príčinu ako zástupné symboly na tlačidle odoslať -- nejde o chybu produktu a nie je dôvod na opätovnú inštaláciu klientskeho softvéru (platforma je len prehliadačová).
Rovnaký problém sa vyskytuje na prihlasovacej stránke platform.econnect.eu a inde v UI: texty zástupných symbolov alebo surové i18n kľúče (napríklad {{lang.text}} alebo I18N_COLLABRR_WS.*) namiesto bežných popiskov. Používatelia to často hlásia ako „nemôžem sa prihlásiť“. Pozri tiež Prihlásenie a 2FA.
Automatický preklad prehliadača (automatický preklad stránky v Chrome alebo Edge) zasahuje do DOM platformy. Tým tlačidlá prestávajú správne reagovať a zástupné symboly šablóny alebo i18n, prípadne nelogické popisky polí, zostávajú viditeľné.
Riešenie (poradie first-line):
platform.econnect.eu).Varianty vyhľadávania: "chyba pri odosielaní", "prerobovaná chyba portálu", "po reštarte to funguje", "chyba odoslania bez detailov", "chybová správa bez obsahu".
Niekedy užívateľ nahlási chybu pri odosielaní cez platformu bez konkrétneho textu chyby alebo screenshotu. Bez tohto obsahu nie je dostatočné množstvo informácií pre spoľahlivú diagnózu; nejde o známy rozšírený výpadok.
Možný prvý krok (nepotvrdená príčina):
Nezamáňať s:
SentRetry alebo SentError po akceptovaní -- pozri sekciu o automatickom opätovnom doručení Peppol ďalej na tejto stránke; ide o mechanizmus opakovania na strane servera, nie o problém s cache prehliadača.Vyhľadávacie varianty: „Uveďte platné ID subjektu dodávateľa“, platné ID subjektu dodávateľa, ID subjektu dodávateľa, ID subjektu dodávateľa správne.
Toto hlásenie sa týka Dodávateľ / Party ID -- vášho vlastného identifikátora organizácie na faktúre (predvolené NL: IČO, 8 číslic, schéma 0106), nie odberateľa. Príčinou býva prázdny alebo neplatný výber Dodávateľa, ručne zapísaný text namiesto rozbaľovacieho zoznamu, alebo identifikátor bez zapnutého prepínača Odosielanie.
Riešenie: kliknite na ikonu ceruzky pri Dodávateľ a znova vyberte vlastnú organizáciu z rozbaľovacieho zoznamu. Potom skontrolujte v Organizácie → vaša organizácia → Detaily, že aspoň jeden identifikátor má zapnutý prepínač Odosielanie. Pozri tiež Party identifiers § Party ID.
Dvojitý symptóm (často pri verejnej správe): objavuje sa toto hlásenie spolu s „iba e-mail“ alebo „Peppol nemožno vybrať“ pri odosielaní verejnému odberateľovi? Ide o dve samostatné príčiny jedného konceptu:
0190:. Chýbajúca možnosť Peppol znamená, že príjemca použije e-mailové doručenie (nejde o výpadok), nepoužívajte IČO. Pozri „not available“ pri (testovacom) odosielaní príjemcovi nižšie a „Fakturácia holandskej verejnej správe“ v znalostnej báze.Uložte a znova Odoslať po oprave oboch bodov; Peppol by sa mal potom objaviť pri dostupnom OIN.
Toto hlásenie sa zobrazí, keď nahrajte XML faktúru manuálne a v súbore chýba pole EndpointID dodávateľa. V rozhraní platformy ide o pole "Partij-ID" pod "Dodávateľ".
Riešenie: vyberte z rozbaľovacieho zoznamu hodnotu z vlastnej organizácie. Ak zoznam nezobrazuje správny výsledok, znovu vyberte dodávateľa, aby sa obnovilo prepojenie.
Varianty vyhľadávania: „Neboli nájdené žiadne identifikátory aktivované na odosielanie pre spoločnosť dodávateľa“, identifikátory aktivované na odosielanie, „overenie dodávateľa ešte nie je vykonané“, odoslanie faktúry nová administrácia, dve organizácie s a bez s.r.o., neoverené identifikátory.
Táto správa, a fráza zákazníka „overenie dodávateľa ešte nie je vykonané“ pri prvej faktúre alebo novej administrácii, zvyčajne neukazuje na samostatný krok KYC dodávateľa. Príčina je takmer vždy jeden z týchto štyroch bodov.
Kontrolný zoznam (v poradí):
Ak správa pretrváva aj po týchto štyroch krokoch, pošlite faktúru znova po oprave údajov organizácie alebo faktúry.
Ak faktúru nie je možné odoslať a zostáva v priečinku "Koncepty", skontrolujte dve veci:
Vyhľadávacie varianty: "faktúra ERPx nie je v odoslanej pošte", "stav spracovania doručenia eConnect", "kontrola protokolu Unit4 eConnect", "faktúra z ERPx nie je viditeľná eConnect", "ERPx odoslané nič v eConnect", "protokoly eConnect číslo faktúry ERPx", "Unit4 ERPx stav spracovania doručenia", "e-faktúra ERPx neprišla eConnect".
E-faktúra vytvorená v Unit4 ERPx neprichádza do Odoslanej pošty eConnect, hoci kmeňové údaje odberateľa v ERPx vypadajú správne (metóda odoslania e-fakturácia, formát Peppol, vyplnené OIN/schéma). ERPx pri faktúre niekedy zobrazuje stav spracovania "spracováva sa".
Postup prvej linky:
Presný význam stavu ERPx "spracováva sa" vo vzťahu k doručeniu do eConnect nie je stanovený ako produktový fakt -- používajte tento stav iba ako signál od klienta, nie ako dôkaz, že faktúra už prišla do eConnect.
Platforma eConnect niekedy používa prefix menného priestoru v generovaných UBL faktúrach (napr. <urn:Invoice xmlns:urn="...">). Obe formy — s prefixom aj bez — sú technicky platné XML.
Príjemca odmietajúci faktúry kvôli prefixu menného priestoru nie je Peppol-kompatibilný. Prefix menného priestoru nie je konfigurovateľný pre jednotlivých príjemcov.
Komunikácia zákazníkovi: faktúra je technicky správna. Príjemca musí používať správny XML parser, ktorý spracováva menné priestory s prefixom aj predvolené. Odmietanie na základe prefixu menného priestoru nie je v Peppol povolené.
Kódy chýb EBMS ako EBMS:0003 a EBMS:0004 sú chyby transportu AS4 v komunikácii medzi prístupovými bodmi. Zákazníci vidia SentError alebo SentRetry na platforme — samotný EBMS kód nie je viditeľný v zákazníckom rozhraní.
Akcia: presmerujte zákazníka na TechSupport. TechSupport môže zobraziť podrobnosti chyby prostredníctvom auditnej stopy a Application Insights.
Kód chyby status 40 znamená, že dokument nebol úspešne spracovaný. Dve možné príčiny:
Diagnostika: zamestnanec eConnect musí preskúmať v CloudWatch, akými krokmi spracovania dokument prešiel.
Varianty vyhľadávania: "opraviť EndpointID znovu odoslať", "faktúra odoslaná na nesprávne Peppol ID resend", "Peppol ID zmenené príjemca znova doručiť", "znovu odoslať PeppolID", "faktúra znova s iným PeppolID", "Znovu odoslať Upraviť PeppolID", "zvislá výpustka znovu odoslať", "ponuka riadku znovu odoslať odoslaná pošta", "faktúra Doručené klient nevidí nič", "returnedMessageId príjemca chýbajúca faktúra".
Prostredníctvom možnosti Znovu odoslať v odoslanej pošte môžete znova odoslať už odoslanú faktúru. Pred skutočným odoslaním môžete ešte upraviť polia ako je odkaz (číslo objednávky, OrderReference). Faktúra sa potom odošle znova s rovnakým číslom faktúry, ale s opraveným odkazom.
Podávanie cez AFAS / E-verbinding: ak je dokument už v odoslanej pošte, opakované odoslanie prostredníctvom Znovu odoslat’ na platforme je správna cesta -- nie opätovné generovanie v AFAS alebo E-verbinding. Ak táto akcia vráti červenú chybu udalosti aplikácie, najprv skontrolujte kombináciu schéma/hodnota identifikátora príjemcu (pozri sekciu „Neznáma chyba pri volaní udalosti aplikácie“ vyššie). Ak dokument ešte nie je v odoslanej pošte, príčina leží v kanáli podávania (ERP/E-verbinding) -- opakované odoslanie sa v tomto prípade nevzt’ahuje.
Stav Doručené nepotvrdzuje, že príjemca vidí faktúru vo svojom vlastnom účtovníctve. Technicky Doručené znamená, že prístupový bod dlžánika dokument prijal. Ak dlžánik stále uvádza, že nič nedostal, poskytnite klientovi returnedMessageId ako referenčný identifikátor pre otvorení u vlastného poskytovateľa Peppol príjemcu (pozri sekciu „Stav 'doručené' ale príjemca faktúru nedostal“ nižšie).
Toto je odporúčaný postup, keď príjemca odmietne faktúru kvôli nesprávnemu číslu objednávky alebo inej chybe odkazu. Vyhnete sa tak nutnosti vytvoriť dobropisy a novú faktúru.
V súčasnom Peppol BIS Billing 3.0 a NLCIUS je podporovaný iba 1 odkaz na objednávku (OrderReference) na faktúru. Ide o obmedzenie vyplývajúce z európskej normy EN 16931. Ak faktúra pokrýva viac objednávok, musí dodávateľ odoslať samostatné faktúry.
AdditionalDocumentReference môže obsahovať dodatočné odkazy iných typov (projekt, zmluva alebo odkaz kupujúceho), nie však viacnásobné OrderReference.
Budúcnosť: Revidovaná EN 16931-1:2026 (formálne schválená CEN dňa 13. marca 2026) pridáva podporu pre viacero nákupných objednávok na faktúru. Očakáva sa, že bude zapracovaná v budúcom vydaní štandardu Peppol (možno BIS Billing 4.0). Dovtedy platí súčasné obmedzenie 1 OrderReference na faktúru v BIS Billing 3.0 a NLCIUS.
Vyhľadávacie varianty: "OrderReferentieNummer", "KopersReferentieNummer", "OrderReferentieNummer vs KopersReferentieNummer", "objednávky nenapojené v ERPx", "PO iba v BuyerReference".
Ak je faktúra odmietnutá kvôli chýbajúcemu alebo neznámemu číslu objednávky, je potrebné rozlíšiť dve úrovne.
1. Odkaz je povinný podľa EN 16931. Odkaz -- číslo objednávky alebo iný odkaz (BuyerReference, odkaz na zmluvu alebo projekt) -- je požadovaný. Faktúra bez akéhokoľvek odkazu nesplní základné pravidlá normy.
2. eConnect štandardne neodmieta na základe obsahu odkazu. Jedinou situáciou, keď platforma odmieta v tomto bode, je prípad, keď nie je prítomný žiadny odkaz.
3. Konfigurácia špecifická pre zákazníka môže byť prísnejšia. Skutočné odmietnutie závisí od konfigurácie príjemcu. V konkrétnej konfigurácii môže byť faktúra odmietnutá, ak je odkaz u daného príjemcu neznámy. To závisí od konfigurácie a nie je štandardným správaním platformy eConnect.
Názvy polí platformy, nezamieňať. Na platforme sa BT-13 (OrderReference/ID) nazýva OrderReferentieNummer a BT-10 (BuyerReference) KopersReferentieNummer. Pre párovanie objednávok v ERP (napr. Unit4 ERPx) patrí číslo nákupnej objednávky do OrderReferentieNummer -- KopersReferentieNummer je vlastný odkaz kupujúceho a nenahrádza zhodu PO. Faktúra môže byť platná podľa EN 16931 s vyplneným iba KopersReferentieNummer (norma vyžaduje aspoň jedno z oboch), zatiaľ čo párovanie objednávky v ERP napriek tomu zlyháva: platnosť podľa EN neznamená úspešnú zhodu objednávky. Ak bola hodnota PO omylom uvedená iba v KopersReferentieNummer, nechajte dodávateľa presunúť ju do OrderReferentieNummer; KopersReferentieNummer môže zostať vyplnené aj naďalej.
Akcia:
Faktúra s konečným stavom InvoiceSentError (po chybe validácie 4xx) nepodniká ďalšie pokusy o doručenie. Iba chyby 5xx sa opakujú (maximálne 8 pokusov, približne 35 hodín). Pri chybe 4xx sa vykoná iba jeden pokus; príjemcovi sa neposiela nič ďalšie.
Neexistuje žiadny DELETE endpoint pre predajné faktúry (salesInvoice). Odoslaná alebo odmietnutá predajná faktúra je udalosťou relevantnou pre audit a zostane dostupná v auditačnej stope po dobu 90 dní. Ak bola faktúra nesprávna, vydajte dobropis alebo opravnú faktúru podľa štandardného účtovného postupu.
Validačné chyby ako TaxInclusiveAmount '-1.336061E6' nie je platným xs:decimal sa vyskytujú preto, že zdrojový systém serializuje číselnú sumu vo vedeckej notácii (napr. -1.336061E6 pre -1 336 061,00). Položky sumy UBL sú typu xs:decimal, ktorý nepovolí notáciu E.
Častá príčina: zdrojový systém uchováva sumy interne ako double/float a používa výchozí konverziu reťazca, ktorá automaticky prepína na exponenciálnu notáciu pre veľmi veľké alebo veľmi malé hodnoty.
Riešenie na strane zákazníka: aktualizovať zdrojový systém tak, aby boli sumy vždy zapisované ako bežný desíatkový reťazec (napr. prostredníctvom typov decimal/BigDecimal alebo desíatkového vzoru nezávislého od lokálnych nastavení, bez oddeľovačov tisícok a bez notácie E).
Na strane eConnect: nie je možné opraviť automaticky -- hodnota je už nesprávna v dodanom XML. Postúpiť dodávateľovi softvérového balíka.
Stav Doručené znamená, že prístupový bod príjemcu (poskytovateľ služieb Peppol dlužníka) dokument technicky prijal a toto prijatie potvrdil. eConnect obdrží returnedMessageId (formát GUID@econnect.eu): dôkaz, že faktúra dorazila na prístupový bod príjemcu.
Ak dlužník tvrdí, že faktúru nedostal, keď stav zobrazuje 'Doručené', bol dokument doručený na prístupový bod dlužníka, ale v jeho vlastnom softvéri alebo účtovníctve nie je zatiaľ viditelný. Ide o problém nadväzujúceho spracovania na strane príjemcu.
Postup riešenia:
returnedMessageId: s týmto identifikátorom môže prístupový bod príjemcu dokument vyhľadať.Varianty vyhľadávania: „pridat organizáciu“ pri faktúre, portál dodávateľa, názov organizácie + IČO vpravo hore, nemožno upraviť existujúci riadok organizácie, nemožno premenovať existujúc organizáciu, screenshot organizácie zákazníka vpravo hore, hlásenie o identifikátore pri pridávaní organizácie (dodávateľ), pridať vlastnú organizáciu samostatne, dlžník ako vlastná organizácia, pridať príjemcu faktúry do prostredia, aktivovať organizáciu dlžníka verejnej správy, príjemca musí byť v prostredí, registrácia pod vlastným OIN obce, OIN zákazníka ako vlastná organizácia, fakturácia obci s vlastným OIN, OIN príjemcu nie je vlastný identifikátor, schéma 0190 dlžník.
Noví používatelia -- zvlášť tí, ktorí prechádzajú z iných služieb elektronické fakturácie -- sa niekedy snažia pri odosielaní faktúry pridať príjemajucu organizáciu ako vlastnú organizáciu na platforme. To nie je potrebné a vedie k chybovému hláseniu.
Na odoslanie faktúry príjemcovi táto organizácia nemusí byť na vašom vlastnom účte: pri vytváraní faktúry vyberte príjemcu prostredníctvom poľa vyhľadávania dlužníka. Môžete hľadať podľa čísla obchodného registra, názvu spoločnosti alebo čísla OIN.
Varianty vyhľadávania: „žiadna organizácia nenájdená“, „žiadne organizácie nenájdené Francúzsko“, „príjemca nenájdený podľa názvu“, „vyhľadávanie dlžníka zlyháva“, „vyhľadávanie podľa názvu dlžníka“, „nie je možné vyhľadať podľa Peppol ID“, „faktúra cez GLN“, „manuálne zadať dlžníka“, „obchodný register nie je Peppol“, „zahraničný príjemca nie je vo výsledkoch“, „organizáciu nie je možné vybrať“, „vyhľadávanie DPH FR konceptu faktúry“, „vyhľadávanie DPH FR prázdne“, „0225 SIREN Odoslať cez“, „OrganisationID SIREN“.
Podstata: vyhľadávanie dlžníka podľa názvu prehľadáva obchodný register, nie Peppol. Hlásenie „žiadna organizácia nenájdená“ pri názve organizácie alebo francúzskom IČ DPH teda neznačí, že príjemca nie je registrovaný na Peppol, ani že vyhľadávanie podľa Peppol ID je nemožné -- nevypovedá nič o online/offline stave príjemcu na Peppol.
Riešenie:
0088, označenia GS1/EAN): nastavte Odoslať cez na GLN a do OrganisationID zadajte iba číslice, bez prefixu 0088: (pozri všeobecné pravidlo iba-číslice vyššie pri formátovaní identifikátorov).0225 (SIREN/FR CTC) a do OrganisationID zadajte iba hodnotu SIREN, bez prefixu 0225: (čistých 9 číslic, alebo rozšírený formát SIREN_SUFFIX/SIREN_SIRET). Nezadávajte tu francúzske IČ DPH -- to je samostatná schéma (9957). Pozri Party identifiers.Varianty hľadania: "enabled for Peppol sending", "additional Peppol activation", "is sending already enabled", "ÄalÅ¡ia aktivácia odosielania", "University of Luxembourg", "9938", "scheme zahraniÄného prÃjemcu".
Pri aktivovanej organizácii je odosielanie predvolene zapnuté -- je súÄasÅ¥ou Å¡tandardného pripojenia. Neexistuje samostatný krok «Peppol send enable» nad rámec aktÃvneho stavu organizácie. Pozri Registrácia na Peppol pre úplný aktivaÄný postup.
PrÃjemcu (naprÃklad zahraniÄnú Peppol stranu ako luxemburskú univerzitu) zadajte iba na faktúre, cez pole na vyhľadávanie dlžnÃka (ID organizácie + OdoslaÅ¥ cez). PrÃjemcu nepridávajte ako vlastnú organizáciu na úÄte -- pozri aj sekciu «Zmatok: pokus pridaÅ¥ prÃjemcu ako vlastnú organizáciu» vyššie.
Stále dostávate chybové hlásenie, ktoré tu nie je popísané? Kontaktujte nás cez support.econnect.eu.
Kontaktovať podporu