Při odesílání faktury přes platformu eConnect se může stát, že obdržíte chybovou hlášku. Většina chybových hlášek souvisí s chybějícími nebo nesprávnými údaji ve faktuře. Níže najdete nejčastější hlášky, jejich příčinu a jak je vyřešit.

Tato obecná chybová hláška je spuštěna pre-odesílací validací v rozhraní platformy. Platforma před odesláním kontroluje, zda hodnota identifikátoru (např. OINO, IČO) odpovídá očekávanému formátu. Pokud tato kontrola selže, zobrazí se tato chybová hláška.

Podání přes AFAS / E-verbinding: na otázku „mohu odeslat znovu z AFAS nebo E-verbinding?“ je odpověděí obvykle znovu odeslat prostřednictvím platformy (Odchozí pošta > Znovu odeslat), nikoli znovu vygenerovat v AFAS -- pokud je dokument již v odchozí poště. Červená chyba „Neznámá chyba při volání události aplikace“ při opakovaném odeslání je téměř vždy stejná validace schématu/hodnoty jako výše, nikoli samostatná porucha AFAS. Viz také sekci „Znovu odeslat fakturu s opraveným odkazem“ níže.

Častý příklad: schemeID 0190 (OINO) vyžaduje přesně 20 číslic. Pokud hodnota obsahuje prefix — např. NL:OINO:00000001001932779000 místo pouhého 00000001001932779000 — validace selže.

Poznámka: tato chyba se může vyskytnout i u faktur vytvořených přes API, nejen u ručně vytvořených faktur.

Řešení: zkontrolujte hodnoty identifikátoru a odstraňte případné prefixy nebo neplatné znaky. Hodnota musí přesně odpovídat očekávanému formátu pro schemeID (např. 20 číslic pro OINO, 8 číslic pro IČO).

Všeobecné pravidlo -- zadejte pouze číselné hodnotu; platforma přidá prefix schemeID automaticky. Platí pro všechna identifikační schémata, nejen OINO. Zadá-li uživatel prefix i růně (např. 0088:1234567890123, přičemž schéma je již nastaveno na GLN/0088), validace formátu selhe. Příklad GLN (schemeID 0088, GS1): vyberte schéma GLN a do pole hodnoty zadejte pouze číslice GLN -- bez 0088: na začátku.

Pokud dodavatel umístí apostrof před číslo OIN v XML (známý artefakt Excelu), Peppol routing selže. Legacy systém fakturu rozpozná a doručí ji interně — příjemce nevidí fakturu ve své schránce závazků, ale obdrží e-mail s oznámením s odkazem.

Řešení: požádejte dodavatele, aby v XML uvedl číslo OIN bez apostrofu a zkontroloval nastavení exportu Excelu.

Platforma validuje každou fakturu podle platných standardů Peppol a NLCIUS, než ji odešle. Kódy chyb začínající BR (Business Rule) udávají, které pravidlo nebylo dodrženo.

Vaše vlastní organizace (dodavatel) není správně vybrána ve faktuře. K tomu dochází, když bylo pole dodavatele ručně upraveno, nebo když organizace ještě není aktivována.

Řešení: Klikněte na ikonu tužky vedle "Dodavatel" a znovu vyberte Vaši organizaci. Pokud Vaše organizace ještě není aktivována, proveďte to nejprve přes Přidání a aktivace organizace.

Přidali jste přílohu s typem MIME, který není povolen v aktuální validaci Peppol BIS Billing V3. Povolené typy příloh jsou (BT-125):

application/xml není povolen jako typ MIME přílohy v aktuální validaci BIS Billing V3. XML jako příloha patří do EN 16931-1:2026 a budoucí verze Peppol (pravděpodobně BIS Billing 4.0) — nepřidávejte XML přílohu jako řešení BR-CL-24.

Častá příčina (Business Central a jiné ERP): ERP automaticky vkládá přílohy přidané k zaknihované faktuře. Příloha s nepovoleným typem (např. dokument Word) pak způsobí BR-CL-24.

Řešení:

1. Zkontrolujte, které přílohy jsou přiřazeny faktuře v ERP (Business Central: Zaknihovaná prodejní faktura > Přílohy).
2. Odeberte nebo nahradte přílohy s nepovoleným typem — např. převeďte dokument Word do PDF.
3. Odešlete fakturu znovu.

Vyhledávací varianty: "BR-CL-16", "Payment means in an invoice MUST be coded using UNCL4461 code list", "PaymentMeansCode prázdné", "UNCL4461", "BT-81 neplatné".

BR-CL-16 nastane, když Payment means type code (BT-81, cbc:PaymentMeansCode v cac:PaymentMeans) je prázdné, obsahuje volný text, nebo není uveden v seznamu kódů UNCL4461. Doslovná chybová hláška zní mimo jiné: "Payment means in an invoice MUST be coded using UNCL4461 code list".

Řešení: nastavte PaymentMeansCode na platný kód UNCL4461, např. 30 (bankovní převod), 49 (inkaso), 58 (SEPA převod) nebo 59 (SEPA inkaso). Jde o opravu ve zdrojovém UBL u odesílatele -- u přijaté a přeposlané faktury (InvoiceReceived) je PaymentMeans 1:1 průchozí, takže opětovné odeslání bez opravy nepomůže. Ověřte předem pomocí Document Validatoru.

Jednotka, kterou jste vyplnili u řádku faktury, není rozpoznána jako platný kód UN/ECE. K tomu dochází, pokud použijete zkratku nebo vlastní název.

Řešení: Použijte standardní jednotku z nabídky, jako "Kusy" (EA), "Hodiny" (HUR) nebo "Dny" (DAY).

Typ identifikátoru u "OrganisatieID" se liší od typu identifikátoru u "Odeslat přes". Například: OrganisatieID je nastaven na OIN, ale "Odeslat přes" je nastaven na IČO.

Řešení: Ujistěte se, že obě pole používají stejný typ identifikátoru. Fakturujete vládě? Nastavte obě na OIN/OINO. Fakturujete firmě? Použijte u obou IČO (0106).

DIČ dodavatele chybí ve faktuře.

Řešení: Vyplňte Vaše DIČ v nastavení organizace.

Pokud vaše organizace nemá DIČ (například nadace, veřejný subjekt nebo poskytovatel zdravotní péče, který poskytuje výlučně služby osvobozené od DPH)? Nepoužvávejte zástupnou hodnotu NL000000000B01. Místo toho zvolte kategorii DPH 'O' — mimo rozsah DPH při vystavení faktury. Při kategorii 'O' odpadá povinnost vyplnit DIČ a faktura splňuje standard Peppol. Viz také Přenos daňové povinnosti a kategorie DPH O pro vysvětlení kódů kategorií DPH.

Nadace, některé veřejné subjekty a poskytovatelé zdravotní péče poskytují výlučně služby osvobozené od DPH a nemá DIČ. Při vytváření faktury na platformę se zobrazí pożadavek na uvedení DIČ dodavatele.

Řešení: Zvolte kategorii DPH 'O' — mimo rozsah DPH (kód UNCL5305 O, "Services outside scope of tax") ve formuláři faktury. Při kategorii 'O' odpadá pożadavek rozhraní na pole DIČ a faktura můże být odeslána bez DIČ dodavatele.

Nepoužvávejte fiktivní DIČ jako NL000000000B01 — to není určené řešení pro tento scenář. Kategorie 'O' je správnou volbou pro organizace bez povinnosti k DPH.

Rozdíl 'E' a 'O': Kategorie DPH 'E' (Exempt from VAT) je určena pro plné plakní k DPH, kteří fakturují konkrétní osvobozené plřnění. Kategorie 'E' vyżaduje DIČ. Kategorie 'O' je pro organizace zcela bez danńové povinnosti k DPH.

U kategorie O nevyplňujte do pole DIČ zástupnou hodnotu. Hodnoty jako nvt, n/a, NA nebo pomlčka nejsou platné DIč a staále způsobí chybu validace. Nemá organizace strukturálně DIč? Zvolte kategorii O a ponechte pole DIČ prázdné — nic do něj nevypisujte.

Varianty vyhledávání: "Typ DPH je povinný na položce faktury", "I18N_INV.UI.VALUE_MISSING", "prázdný rozbalovací seznam DPH položka faktury", "koncept faktury nelze uložit DPH", "SnelStart XML koncept kategorie DPH".

Tato zpráva se zobrazí, pokud kategorie DPH (rozbalovací seznam DPH) zůstala prázdná alespoň na jedné položce faktury. Zpráva blokuje jak Uložit, tak Odeslat. Toto se často vyskytuje u XML dodaného přes Emailový příjemce (například ze SnelStart), který přichází jako koncept bez platné kategorie DPH na položku.

Řešení:

1. Přejděte na Prodejní faktury → Koncepty faktur a otevřete příslušný koncept.
2. Pro každou položku faktury zvolte správnou kategorii DPH v rozbalovacím seznamu. Nevybírejte sazbu na základě předpokladu -- zvolte kategorii odpovídající skutečnému plnění.
3. Zkontrolujte také ostatní povinná pole: datum faktury, Dodavatele a Odběratele. Pokud je některé z těchto polí neplatné, použijte ikonu tužky k opětovnému výběru strany ze seznamu místo ručního zadání názvu.
4. Zkontrolujte DIČ z hlediska kódu země a oddělovačů (například BE0665904901 pro Belgii), viz BR-CO-09 níže.
5. Uložte a odešlete fakturu.

Strukturální při dodání ERP/XML: neúplný export z účetního nebo fakturačního softwaru vede k nespolehlivému automatickému odesílání (auto-send). Dodavatel softwaru musí dodat platnou kategorii DPH na položku faktury v XML.

Viz také "Pole Dodavatel je rozbalovací seznam, ne pole pro volný text" a BR-CO-09 výše, a Emailový příjemce pro auto-send XML (pouze s platným XML).

Při fakturaci nizozemské vládě (Basisfactuur Rijk, přes Digipoort) je IBAN povinný.

Řešení: Vyplňte Váš IBAN v platebních údajích faktury. Je doporučeno vždy uvádět IBAN na faktuře, tato povinnost se v budoucnu rozšíří.

Tato chyba nastává, když CompanyID (pole PartyLegalEntity v UBL) obsahuje DIČ místo IČO nebo OIN. To není povoleno: validace NLCIUS vyžaduje, aby nizozemské strany vždy používaly IČO (schemeID 0106) nebo OIN (schemeID 0190) jako CompanyID. NL-R-003 platí pro dodavatele, NL-R-005 pro zákazníka.

Záměna vzniká tím, že EndpointID (Peppol adresa používaná pro směrování) může obsahovat DIČ (schemeID 9944). Faktura s DIČ jako EndpointID tedy dorazí v síti Peppol v pořádku, ale přesto bude zamítnuta, pokud je stejné DIČ také v CompanyID.

Technické: EndpointID a CompanyID jsou dvě oddělená pole s vlastním účelem. EndpointID určuje směrování přes Peppol a akceptuje jakýkoli typ z kódového seznamu EAS (včetně 9944 pro DIČ). CompanyID identifikuje právní subjekt a u nizozemských stran musí vždy obsahovat IČO (0106) nebo OIN (0190).

Řešení: Zkontrolujte UBL, které Váš systém generuje, a ujistěte se, že CompanyID obsahuje IČO nebo OIN, i když EndpointID obsahuje DIČ. Obě pole musí odkazovat na stejnou organizaci, ale mohou mít odlišný typ identifikátoru.

Tip: Legislativa ViDA postupně zpřísňuje vztah mezi EndpointID a CompanyID. Ujistěte se, že Vaše integrace je již nyní správně nastavena, abyste nebyli překvapeni budoucími změnami pravidel.

Varianty vyhledávání: "OP-T10-R008", "Party Company Identifier Scheme", "schemeID NL:KVK", "schemeID NL:VAT", "písmenný kód schemeID CompanyID", "CompanyID scheme neplatný".

OP-T10-R008 (Party Company Identifier Scheme) nastává, když atribut schemeID na poli Party CompanyID (PartyLegalEntity/CompanyID nebo PartyIdentification) obsahuje historický písmenný kód, jako NL:KVK nebo NL:VAT, místo numerického kódu PEPPOL. To není povoleno: validace vyžaduje scheme z oficiálního seznamu identifikace stran PEPPOL.

Písmenný kód NL:KVK je Peppol Service Bus (PSB) považován za směrovací alias scheme 0106, to se ale nevztahuje na toto pole UBL -- jde o dva odlišné kontexty.

Řešení: nahraďte písmenný kód numerickým kódem EAS, například schemeID="0106" pro nizozemské IČO:

<cbc:CompanyID schemeID="0106">12345678</cbc:CompanyID>

Prázdné pole CompanyID spadá pod jiné pravidlo -- viz "NL-R-005 / NL-R-003" výše. Více informací o typech identifikátorů a schemeID: Party identifiers.

Varianty vyhledávání: "BR-AE-10", "SOAP:CLIENTBR-AE-10", "Reverse charge shall have a VAT exemption reason", "BT-120", "BT-121", "chybí důvod osvobození přenesení daňové povinnosti", "faktury zamítnuty reverse charge".

BR-AE-10 nastává, když kategorie DPH AE (Reverse Charge) v rozpisu DPH (BG-23) neobsahuje důvod osvobození: chybí BT-121 (kód) i BT-120 (text, například "DPH přenesena" nebo "Reverse charge"). Jde o chybu v dodaném UBL z ERP nebo fakturačního softwaru -- eConnect fakturu validuje, ale pole AE automaticky neupravuje.

Řešení:

1. Zkontrolujte, že každý řádek faktury nebo příplatek s kategorií DPH AE má sazbu DPH 0 %.
2. V UBL exportu zdrojového systému vyplňte pole TaxExemptionReason (BT-120) a/nebo kód (BT-121) pro každý AE rozpis.
3. Fakturu předem validujte přes Document Validator.
4. Odešlete opravenou fakturu znovu -- opětovné odeslání původního, chybného XML toto neřeší.

Viz také Přenos daňové povinnosti: kódy K, AE a G pro úplné vysvětlení kódů přenesení daňové povinnosti.

Tato validační pravidla EN 16931 kontrolují, zda jsou rozpad DPH a celkové částky faktury vzájemně konzistentní. Hodnoty vypočítává odesílající software — nejsou to pole, která lze opravit v rozhraní eConnect.

Varianty vyhledávání BR-CO-12 / BR-E-01: "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "součet příplatků nesedí", "poštovné chybí na řádku faktury", "Shipping costs AllowanceCharge", "chybí rozpad Exempt".

BR-CO-12 nastává, když součet příplatků na úrovni faktury neodpovídá součtu jednotlivých příplatků dokladu — například když je poštovné uvedeno jako samostatný AllowanceCharge na úrovni faktury (ChargeIndicator=true, důvod "Shipping costs" / kód FC). Jde o platné UBL; viz Příplatky a slevy pro strukturu. BR-E-01 nastává, když řádek faktury, příplatek nebo sleva dokladu s kategorií DPH 'Osvobozeno od DPH' (E) nemá odpovídající rozpad Exempt v souhrnu DPH.

Častá příčina: zaokrouhlování DPH na každém řádku místo dle sazby DPH nebo neshoda mezi částkami řádků a slevami na úrovni faktury.

Řešení: kontaktujte dodavatele odesílajícího softwaru pro opravu. eConnect nemůže tyto hodnoty opravit, protože výpočet je pevně dán v dodaném XML.

Varianty vyhledávání: „Invalid payload BR-S-08“, „Delivery Failed BR-S-08“, „souhrn DPH nesedí“, „řádek faktury bez množství“, „chybí množství na řádku faktury“, „BT-116“, „VAT category taxable amount“.

Kromě zaokrouhlení selhává BR-S-08 také, když řádek faktury nemá množství (nebo má prázdné množství) (Invoiced quantity / BT-129). V takovém případě nesedí částka řádku bez DPH (množství x jednotková cena plus příplátky na řádku minus slevy na řádku), takže součet řádků se odchyluje od VAT category taxable amount (BT-116) v rozpadu DPH pro Standard rated. Doslovná chybová hláška často vypadá 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)....

Rozdíl oproti chybám xs:decimal: v části „'není platným xs:decimal'“ výše samotné pole částky není platné desetinné číslo (prázdné nebo vědecká notace). U BR-S-08 je pole částky platné číslo, ale výpočet mezi částkami řádků a rozpadem DPH nesedí.

Kontrolní seznam první linie (před eskalací na dodavatele softwaru):

1. Zkontrolujte u všech řádků faktury vyplněné množství a částku řádku bez DPH.
2. Částka řádku = množství x jednotková cena (plus příplátky na řádku, minus slevy na řádku); žádná prázdná pole částky.
3. Nechte znovu přepočítat souhrny DPH ve zdrojovém systému.
4. Odešlete opravenou fakturu přes Peppol. Opětovné odeslání stejného dokumentu bez opravy BR-S-08 nevyřeší -- Odeslat znovu v odchozí poště neupravuje částky řádků ani DPH (stejný rozsah opětovného odeslání jako u R120 výše).
5. Chyba se stále opakuje při úplných množstvích? Pak jde o chybu zaokrouhlení nebo jinou výpočetní chybu v ERP nebo exportu UBL -- předejte dodavateli softwaru.

Kategorie DPH E vs. O: nemá organizace DIČ (nadace, veřejný subjekt, zdravotnictví)? Použijte kategorii O (mimo rozsah DPH) — viz část »Organizace osvobozené od DPH: kategorie O« výše. Kategorie E vždy vyžaduje DIČ.

Varianty vyhledávání: „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á sazba UBL“, „chybí rozpad DPH BG-23“, „XML + PDF odeslány spolu“, „UBL odmítnut PDF přesto zpracován“, „potlačení chybové zprávy XML“, „ditch the XML“.

Zero rated (Z, 0% DPH) není synonymem pro osvobození (kategorie E) nebo přenos daňové povinnosti DPH (kategorie AE) -- řádky, sazby a souhrny DPH musí být vzájemně konzistentní:

• BR-CO-18: pro každou použitou kombinaci kategorie DPH, sazby, důvodu osvobození a kódu položky musí faktura obsahovat alespoň jeden rozpad DPH (BG-23). Chybí nebo je neucelený -- zamítnutí.
• BR-Z-01: pokud je kategorie Z použita na řádku faktury, příplatku nebo slevě dokumentu, rozpad DPH musí obsahovat alespoň jeden řádek s kategorií Z („alespoň jeden“, ne „přesně jeden“).
• BR-Z-05: pokud je kategorie DPH Z, sazba DPH musí být 0.

Kombinace XML + PDF v jednom e-mailu (dual-path): pokud přijde e-mail s přílohou XML i PDF a XML je odmítnut na jednom z těchto pravidel, e-mail platformy může zobrazit „Processing is not possible“ nebo „We were unable to process the UBL invoice in the attachment“ -- zatímco PDF bylo zpracováno a nachází se ve schránce doručených zpráv. Nejde o dvojíté selhání: obě přílohy jsou posuzovány odděleně a chybovou zprávu týkající se XML nelze potlačit, dokud jsou přítomny jiné úspěšně zpracované přílohy.

Všechny tyto chyby jsou v odeslaném UBL od odesílatele nebo jeho softwaru. eConnect neupravuje pole DPH v odeslaném XML; opakované odeslání stejného, chybného XML nic neřeší -- je potřeba nová, opravená faktura. Předem lze ověřit pomocí Document Validator.

Řešení (vyberte jednu z těchto strukturalních cest):

1. Opravit UBL u zdroje: dodavatel nebo software doplní rozpad DPH (kategorie Z s odpovídajícím rozpadem, sazba 0, konzistentní řádky a souhrny).
2. Vynechat XML: odeslat pouze PDF, bez přílohy XML ve stejném e-mailu (vhodné pouze pro cestu odeslání e-mailem, není náhradou za odeslání přes Peppol).
3. Email Receiver pouze na PDF: podpora může nastavit Email Receiver zákazníka tak, aby přijímal pouze digitální faktury (PDF), takže XML se již nevalí.

Pokud faktura jde přes Peppol nebo nativní UBL, je možnost 1 jedinou strukturalní řešením -- PDF tam není náhradou za platný UBL.

Varianty vyhledávání: „Chyba Peppol“, „stav doručení“, „stav doručení ve vlastním softwaru“, „zaokrouhlování v čase“, „dvě desetinná místa zdrojový software“, „částky bez DPH nesprávné“, „nová dávka stejná chyba“.

Triage při více možných příčinách („Chyba Peppol“ / stav doručení ERP): stejný tiket může obsahovat jak výpočetní chybu R120, tak chybu schématu EndpointID. Postupujte v tomto pořadí:

1. Nejprve zkontrolujte literální kód nebo text chyby v odchozí poště eConnect (platform.econnect.eu) -- nejen stav v ERP nebo účetním softwaru klienta (např. „doručení“ nebo „chyba“). Stav ERP není totozž ný se stavem platformy eConnect.
2. Ukazuje chyba na „sum invoice line“, zaokrouhlování nebo dvě desetinná místa ve zdrojovém softwaru? Pak se jedná o tento výpočet řádku R120 -- oprava leží na straně odesílajícího softwaru.
3. Jde o neplatný EndpointID se schématem 0190 (nizozemské OIN) u belgického odběratele? Použijte pak schéma 0208 (belgické číslo podniku, 10 číslic bez teček) nebo schéma, na kterém je příjemce skutečně registrován na Peppol -- viz sekce o belgickém čísle podniku níže.
4. Nová dávka selhává znovu? To se stává pouze tehdy, pokud stejná základní příčina (výpočet R120 a/nebo schéma EndpointID) je stále v XML -- ne z důvodu samotného typového štítku dávky.

Tato chyba je hlášena také jako chyba „sum invoice line". R120 je výpočetní pravidlo, které kontroluje, zda LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + příplatky − slevy. R120 výslovně nezakazuje záporné částky; validace selže, když výpočet nesedí. K tomu často dochází, když řádková sleva (AllowanceCharge na úrovni řádku) přesahuje cenu položky, například u dobropisu s vysokou slevou.

Oprava přísluší odesílajícímu softwaru (programu, ve kterém byla faktura vytvořena), nikoli eConnect: eConnect neupravuje částky v odeslaném XML.

Řešení: použijte čistou kreditní částku přímo jako PriceAmount a element AllowanceCharge na řádku vynechte. Podrobnosti a příklad XML najdete v článku o přirážkách a slevách. Vyžádání souboru XML faktury je třeba pouze jako hloubková analýza při neobvyklém vzorci, nikoli jako první krok.

Opětovné odeslání R120 nevyřeší. Odeslat znovu v odchozí poště opravuje pole směrování a reference (jako EndpointID nebo číslo objednávky) — nikoli částky řádků ani řádkové slevy. U R120 nemá opakování stejného dokumentu smysl: opravte výpočet v odesílajícím softwaru nebo vytvořte nový doklad.

Faktura vytvořená přímo na platformě (žádný externí XML z ERP)? Vytvořte novou prodejní fakturu — doklad v odchozí poště je pouze pro čtení a nelze jej smazat. Ujistěte se, že množství × cena za jednotku se rovná částce řádku pro každý řádek, bez samostatné řádkové slevy přesahující cenu položky; v případě potřeby zadejte přímo čistou cenu. Znovu vyberte příjemce a odešlete přes Peppol. Neúspěšný doklad může zůstat v odchozí poště; označení jako duplikátu není problém.

Opravná faktura z AFAS (přes eVerbinding) nedorazila. Když opravná faktura odeslaná přes AFAS a eVerbinding spustí R120, text chyby nemusí R120 pojmenovat přímo: stav pak zobrazuje „doručení se nezdařilo" nebo „document format not supported by receiver", často po neúspěšné transformaci NLCIUS na Peppol BIS. Jde o důsledek chyby validace obsahu, nikoli důkaz, že příjemce je nedostupný nebo fakturu odmítá.

Pořadí diagnostiky: nejprve logy, XML jen pro hloubkovou analýzu.

1. Nejprve otevřete logy odesílatele nebo stav odchozí pošty dokladu a hledejte doslovný kód R120, text „Invoice line net amount MUST equal" nebo hlášenou chybu transformace NLCIUS na BIS.
2. Pouze pokud to neposkytne jasno: otevřete fakturu v odchozí poště a pomocí rozbalovací nabídky Stáhnout XML zobrazte odeslaný XML. Vyžádání souboru XML od zákazníka je volitelný hloubkový krok, nikoli první akce, když logy chybu již zobrazují.

eConnect nepřevádí množství ani ceny. U správného kreditního nebo opravného řádku se očekává záporné množství a kladná cena za jednotku (celková částka je pak záporná). eConnect nemění znaménko množství ani cen ze záporného na kladné ani naopak — R120 selže na výpočtu v odeslaném XML ze zdrojového systému (např. AFAS). Skutečnost, že rozhraní platformy zobrazuje pouze PDF bez samostatného zobrazení XML, neznamená, že eConnect přepisuje částky.

Také bez řádkové slevy (čistý nesoulad množství × cena). R120 selhává i tehdy, když na řádku není žádné AllowanceCharge, ale Quantity × (PriceAmount / BaseQuantity) neodpovídá LineExtensionAmount. To obvykle ukazuje na desetinnou chybu nebo chybu faktoru 100 v ceně nebo částce řádku ve zdrojovém XML, například 200 × 5,14 = 1028,00 místo 10,28. V takovém případě prověřte pole XML ručně -- nejen souhrny zobrazené v rozhraní.

Souhrny na obrazovce jsou správné, ale R120 stále selhává. Klient múfže uvést, že částky na obrazovce konceptu jsou správné; to R120 nevylučuje. R120 kontroluje pole v XML (Quantity, PriceAmount, BaseQuantity, LineExtensionAmount, AllowanceCharge), nikoli to, co je zobrazeno na obrazovce. Pokud konceptová faktura nebo dodané zdrojové XML stále selhává na R120, opravte to ve zdrojovém systému a odešlete nový nebo opravený dokument. Ruční úprava OrganisationID nebo jednotky R120 nevyřeší -- jde o jiná validační pravidla.

Tyto tři chybové kódy se zobrazují, když byla faktura technicky odeslána, ale příjemce nebo validátor odmítá obsah na základních polích v UBL/XML. Příčina je v samotném XML souboru, ne v připojení Peppol, Peppol ID nebo způsobu doručení k odběrateli.

Řešení: upravte příslušná pole v softwaru, ve kterém je faktura vytvářena -- CustomizationID a ProfileID jsou pevné hodnoty pro daný typ dokumentu, ne nastavení na platformě eConnect. Pokud chybí BuyerReference i OrderReference, doplňte jedno z nich před opakovaným odesláním faktury.

Upozornění k R007 a jiným BIS profilům: výchozí hodnota v tabulce platí pro běžnou faktura/dobropis. Self-billing a další profily Peppol BIS (např. self-billing invoicing) mají svůj vlastní, odlišný ProfileID. Nevynucujte výchozí hodnotu na fakturach, které vědomě používají jiný BIS profil -- nejprve zkontrolujte, jaký profil se použije, než tuto FAQ použijete.

Nezaměňovat s: chybějící registrací Peppol u příjemce, nesprávným EndpointID, výpadkem Access Pointu nebo hlášením "žádná validační pravidla k dispozici" (viz příslušnou sekci níže) -- tyto případy mají jiné symptomy než tato kombinace specifikace, profilu a referencí.

Zdroj: ticket #15272547 (2026-07-28).

Vyhledávací varianty: "P0112", "invoice type code 326 or 384 is only allowed when both buyer and seller are German organisations", "typový kód 326", "dílčí faktura", "kde změnit typ faktury", "změna kódu typu faktury v portálu", "nevidím pole pro typ faktury", "384 francouzské prodejní faktury", "debet a kredit na stejné faktuře Francie", "opravná faktura ne ve Francii", "obě strany nesídlí ve Francii", "obě strany nejsou v zemi X", "InvoiceTypeCode 384 FR", "P0112 Francie", "mixed debit credit BIS 3.0", "rozdělení 380 381".

Tato chyba se objevuje, když cbc:InvoiceTypeCode (BT-3) má hodnotu 326 (dílčí faktura) nebo 384 (opravná faktura), zatímco dodavatel a příjemce nejsou oba německé organizace. Pravidlo Peppol BIS Billing 3.0 PEPPOL-EN16931-P0112 povoluje 326 a 384 pouze, pokud jsou obě strany německé.

Žádné FR-specifické pravidlo: text chyby nebo vlastní interpretace o "obě strany nesídlí ve Francii" nebo "nejsou v zemi X" je nesprávná parafráze. P0112 testuje výhradně Německo (dodavatel a příjemce), ne zemi faktury nebo sídlo francouzských stran. Odchozí francouzský subjekt s typovým kódem 384 na BIS Billing 3.0 naráží na stejné omezení DE→DE -- neexistuje samostatná cesta "FR opravná faktura".

UI portálu: výběr typu faktury je vpravo na konceptu faktury. Klientské štítky zahrnují mimo jiné dílčí faktura (vedle standardních termínů "opravná faktura" a "obchodní faktura") -- snadno přehlédnutelné.

Řešení (portál, faktura NL nebo ne-DE, včetně FR/BIS 3.0):

1. Přejděte na Prodejní faktura → vytvořit fakturu (koncept).
2. Vpravo na konceptu: zkontrolujte typ faktury -- dávejte pozor na štítek dílčí faktura.
3. Vyberte Obchodní faktura (typový kód 380) místo dílčí faktury (326) nebo opravné faktury (384), pokud nejde o skutečnou opravu a odesílatel i příjemce jsou německí.
4. Pro opravu k ne-německému příjemci: použijte dobropis nebo zápornou 380 plus novou faktura -- viz Varianty dobropisu. Nepoužívejte typový kód 326/384 mimo DE→DE.
5. Při opravě s debetními i kreditními řádky na stejné faktuře mimo DE→DE: rozdělte na dva dokumenty -- 380 (debet) a 381 (kredit) -- nebo použijte jednu 380 s kreditními řádky jako záporné množství a kladnou cenu.

Zdroj: Peppol BIS Billing 3.0 -- PEPPOL-EN16931-P0112.

Tato chyba se vyskytuje na řádku (řádcích) faktury s kategorií DPH Dodání v rámci Společenství / Intra-community supply (K, BT-151), když chybí povinný údaj o DPH. U kategorie K jsou povinné: DPH dodavatele (seller VAT, BT-31) nebo DPH daňového zástupce (seller tax representative VAT, BT-63), a DPH kupujícího (buyer VAT, BT-48). Chybějící údaje se nacházejí v datech strany (organizace nebo odběratele), ne na samotném řádku faktury. Chybové hlášení neukazuje na jedno konkrétní číslo řádku -- pravidlo se spustí, jakmile jeden z řádků faktury použije kategorii K.

Řešení:

1. Určete, který řádek (řádky) faktury používá kategorii DPH K (dodání v rámci Společenství).
2. Vyplňte DIČ dodavatele (seller VAT) v nastavení organizace, nebo vyplňte daňového zástupce (seller tax representative VAT).
3. Vyplňte DIČ klienta (buyer VAT) v údajích odběratele.
4. Odešlete fakturu znovu. Dokument v Poštovní schránce Výstup je pouze pro čtení -- při chybě je nutné vytvořit novou prodejní fakturu.

Belgická Peppol ID mohou mít dvě formy:

Formát DIČ: BE následované přesně 10 číslicemi (přidat vedoucí nuly pokud potřeba). Ověřte DIČ prostřednictvím nástroje VIES Evropské komise (ec.europa.eu/taxation_customs/vies).

Možnost Peppol se nezobrazuje pro belgického odběratele? Zkontrolujte, s jakým typem identifikátoru je odběratel registrován na Peppol. Některé belgické organizace jsou registrovány pouze přes 0208: (KBO), nikoli přes 9925: (DIČ). V takovém případě zkuste číslo KBO: DIČ bez BE na začátku (např. pro BE0123456789 je číslo podniku 0123456789; pro BE1xxxxxxxxx je to 1xxxxxxxxx -- oba prefixy jsou platné).

Ostatní: záporné cenové řádky nejsou v belgických fakturách povoleny; použijte záporné množství s kladnou cenou.

Kódy chyb BR-DE-* jsou německá validační pravidla specifická pro XRechnung.

Chybějící Leitweg-ID (EAS 0204): časté při fakturaci německým vládním orgánům. Vyžádejte Leitweg-ID od smluvního úřadu a přidejte ho jako identifikátor se schemeID 0204.

PDF nepřijato: od 1. ledna 2025 platí v Německu povinnost přijímat e-faktury. Prostý PDF často již nestačí. Odešlete fakturu jako XRechnung nebo ZUGFeRD.

Odmítnutí KSeF: často způsobeno neplatným formátem XML FA_VAT. PSB eConnect normálně zajišťuje správnou transformaci do polského formátu KSeF.

Chyby certifikátů: mohou se vyskytnout, pokud certifikáty KSeF nejsou správně nainstalovány nebo vypršely.

Omezení rychlosti: KSeF aplikuje limity na počet požadavků. eConnect používá dávkové zpracování, aby tomu předešel.

UWV uplatňuje vlastní validační pravidla nad rámec standardní validace Peppol/NLCIUS.

• UWV Velký peněžní tok (reintegrace, školení, dávky): OIN 00000004191771249000
• UWV Malý peněžní tok (správa): OIN 00000004172892677000

Řešení dle kódu UWV: doplňte chybějící pole na faktuře. Řada UWV001 se týká povinných polí dodavatele; řada UWV002 identifikačních prvků.

Tato hláška se zobrazí v Odeslané poště, když fakturu nebylo možné doručit příjemci přes síť Peppol. Možné příčiny:

• Příjemce není registrován na Peppol: příjemce nemá aktivní Peppol registraci. Platforma v takovém případě automaticky nabídne záložní odeslání e-mailem.
• EndpointID nesprávné: Peppol adresa příjemce nesouhlasí. Zkontrolujte IČO nebo OIN, které jste vyplnili jako odběratele.
• Přijímající strana má technický problém: faktura byla správně odeslána, ale nemohla být zpracována systémem příjemce. To je mimo Váš vliv, kontaktujte příjemce.

Při selhaném doručení můžete fakturu odeslat znovu a přitom opravit EndpointID.

Pole dodavatele neobsahuje žádné údaje. K tomu dochází, když Vaše organizace není vybrána nebo když organizace není aktivována.

Řešení: Klikněte na ikonu tužky vedle pole dodavatele a vyberte Vaši organizaci. Není Vaše organizace ještě aktivována? Postupujte podle kroků v Přidání a aktivace organizace.

DIČ musí být vyplněno bez mezer, teček nebo pomlček, včetně kódu země. Správný formát pro Nizozemsko je NL123456789B01. Belgická DIČ musí být vyplněna jako BE následované přesně 10 číslicemi, bez oddělovačů.

Pokud zadaná částka zmizí, když přejdete na další krok, pole pravděpodobně obsahuje znaky, které nejsou povoleny. Pole pro částku akceptuje pouze číslice s čárkou jako desetinným oddělovačem. Zadávejte částky jako 100,00, ne jako € 100,00 nebo 100.00.

Varianty vyhledávání: "červená ikona stop odeslání", "červené kolečko odeslání", "fakturu nelze odeslat", "odeslání selhává", "ikona stop faktura", "poznámka k faktuře povinná", "IBAN bankovní účet povinný", "více informací poznámka k faktuře", "platební údaje IBAN prázdné", "povinná pole odeslání faktury".

Při odesílání ruční prodejní faktury se může zobrazit červená ikona stop: faktura se neodešle. Příčinou je validace formuláře na straně klienta -- nejde o chybu Peppol ani sítě, ani o vadu platformy. Odběratel/OIN, dosažitelnost přes Peppol a číslo objednávky mohou být již v pořádku, zatímco odeslání přesto selhává, protože jiné povinné pole zůstalo prázdné.

Zkontrolujte tato dvě pole:

1. Poznámka k faktuře (sekce Více informací) -- vyplňte krátkou poznámku nebo referenci, například číslo objednávky nebo referenci dohodnutou se zákazníkem.
2. IBAN bankovní účet (sekce Platební údaje) -- vyplňte IBAN, na který má platba dorazit, v případě potřeby přes Změnit. IBAN na úrovni organizace je nepovinný, ale prázdný IBAN na samotné faktuře může přesto blokovat odeslání.

Rozdíl oproti jiným blokacím:

• Tlačítko odeslání nereaguje nebo zobrazuje zástupné texty: viz "Tlačítko Odeslat Peppol nereaguje" níže (automatický překlad prohlížeče).
• Faktura zůstává v konceptech: viz příslušná sekce (nastavení organizace nebo chybějící "Odeslat přes").

Odesílání stále selhává i po vyplnění obou polí? Vyžádejte si snímek obrazovky s přesnou chybovou zprávou, nejen s ikonou stop.

Varianty vyhledávání: "číslo bankovního účtu není správně formátováno", "bankovní účet není správně formátován", "IBAN není správně formátován", "chyba formátu IBAN", "mezery v IBAN", "formátování IBAN platební údaje", "chyba IBAN při odesílání ruční faktury".

Při odesílání ruční prodejní faktury se může zobrazit zpráva, že číslo bankovního účtu nebo IBAN není správně formátováno, i když je číslo obsahově správné. Příčinou je validace formátu před odesláním pro IBAN nebo bankovní účet v sekci Platební údaje -- nejde o chybu Peppol ani sítě. Mezery, pomlnky nebo jiné oddělovače (nebo chybějící kód země) způsobí, že kontrola selhá.

Řešení:

1. Otevřete fakturu a přejděte na Platební údaje (IBAN nebo bankovní účet).
2. Zadejte celý IBAN jako jeden souvislý řetězec: kód země následovaný číslicemi/písmeny, bez mezer, pomlnek nebo jiných oddělovačů (tvar: NL00BANK0123456789).
3. Nepoužívejte staré číslo účtu bez kódu země -- nizozemské účty začínají na NL.
4. Uložte a fakturu znovu odešlete.

Rozdíl oproti jiným blokacím:

• Prázdné pole IBAN s červenou ikonou stop u povinných polí -- viz "Červená ikona stop při odesílání" výše.
• "ID není správně formátováno" se týká formátu identifikátoru/schemeID, ne bankovního účtu -- viz sekce o neznámých chybách/validaci identifikátoru výše.

Zpráva se stále zobrazuje? Vyžádejte si přesný obsah pole (vďetně mezer nebo znaků) a doslovnou chybovou zprávu nebo snímek obrazovky.

Varianty vyhledávání: "tlačítko odeslat nereaguje", "obrazovka načítání se sekne při odesílání", "divný text na faktuře", "divné jméno dodavatele", "nelogická jednotka na faktuře", "organizace zobrazuje divný text", "opakované přihlášení pro uložení", "znovu přihlásit pro odeslání", "pole faktury přeložená", "překlad prohlížeče při vytváření faktury", "nemohu se přihlásit", "divný text na přihlašovací stránce".

Pokud tlačítko odeslat nereaguje nebo obrazovka načítání zůstává zaseknutá při odesílání faktury Peppol a vidíte nepřeloženou syntaxi šablony jako {{invoice.data.supplierDetails.name}} místo vyplněných hodnot, příčinou je pravděpodobně automatický překlad prohlížeče.

Stejný vzor se může objevit při vytváření (nové) faktury: nelogické nebo "přeložené" popisky/hodnoty polí, mimo jiné u dodavatele, organizace a jednotky, kdy uložení nebo odeslání se podaří až po opakovaném přihlášení. Má to stejnou příčinu jako zástupné symboly na tlačítku odeslat -- nejde o chybu produktu a není důvod přeinstalovávat klientský software (platforma je pouze prohlížecová).

Stejný problém se objevuje na přihlašovací stránce platform.econnect.eu a jinde v UI: texty zástupných symbolů nebo syrové i18n klíče (například {{lang.text}} nebo I18N_COLLABRR_WS.*) místo běžných popisků. Uživatelé to často hlásí jako „nemohu se přihlásit“. Viz také Přihlášení a 2FA.

Automatický překlad prohlížeče (automatický překlad stránky v Chrome nebo Edge) zasahuje do DOM platformy. Tím tlačítka přestávají správně reagovat a zástupné symboly šablony nebo i18n, případně nelogické popisky polí, zůstávají viditelné.

Řešení (pořadí first-line):

1. Vypněte automatický překlad v prohlížeči pro platformu eConnect (včetně platform.econnect.eu).
2. Tvrdé obnovení (Ctrl+F5) a znovu se přihlaste; pokud je potřeba, znovu otevřete nebo vytvořte fakturu.
3. Stále nefunguje? Vymažte cache prohlížeče a/nebo zkuste jiný prohlížeč.
4. Problém trvá? Vyžádejte si snímek obrazovky stránky faktury včetně prohlížeče a jeho verze.

Varianty vyhledávání: "chyba při odesílání", "přerušovaná chyba portálu", "po restartu to jde", "chyba odeslání bez detailů", "chybová zpráva bez obsahu".

Někdy uživatel nahlásí chybu při odesílání přes platformu, aniž by uvedl konkrétní text chyby nebo snímek obrazovky. Bez tohoto obsahu není dost informací pro pevnou diagnózu; nejde o známý rozsáhlý výpadek.

Možný první krok (nepotvrzená příčina):

1. Vymažte cache prohlížeče a/nebo zkuste jiný prohlížeč.
2. Pokud to nepomůže, vyžádejte si více kontextu: konkrétní chybovou zprávu nebo snímek obrazovky, čas a číslo faktury.

Nezaměňovat s:

• Tlačítko odeslat nereaguje, obrazovka načítání se sekne, nebo nelogické popisky/zástupné symboly -- viz "Tlačítko Odeslat Peppol nereaguje" výše (automatický překlad prohlížeče, s vlastním pořadím first-line).
• Stav SentRetry nebo SentError po přijetí -- viz sekce o automatickém opětovném doručení Peppol dále na této stránce; jde o mechanismus opakování na straně serveru, ne o problém cache prohlížeče.

Vyhledávací varianty: „Uveďte platné ID subjektu dodavatele“, platné ID subjektu dodavatele, ID subjektu dodavatele, ID subjektu dodavatele správně.

Tato hláška se týká Dodavatel / Party ID -- vašeho vlastního identifikátoru organizace na faktuře (výchozí NL: IČO, 8 číslic, schéma 0106), ne odběratele. Příčinou bývá prázdný nebo neplatný výběr Dodavatele, ručně zapsýbaný text místo rozbalovacího seznamu, nebo identifikátor bez zapnutého přepínače Odesílání.

Řešení: klikněte na ikonu tužky u Dodavatel a znovu vyberte vlastní organizaci z rozbalovacího seznamu. Poté zkontrolujte v Organizace → vaše organizace → Detaily, že alespoň jeden identifikátor má zapnutý přepínač Odesílání. Viz také Party identifiers § Party ID.

Dvojítý symptom (často u veřejné správy): objevuje se tato hláška společně s „pouze e-mail“ nebo „Peppol nelze vybrat“ při odeslání veřejnému odběrateli? Jde o dvě samostatné příčiny jednoho konceptu:

1. Dodavatel/Party ID (vlastní organizace) -- oprava jako výše.
2. Veřejný odběratel nedostupný přes Peppol -- u NL veřejné správy musí být Odeslat přes nastaveno na OIN/OINO a ID Organizace musí být přesné 20mistné OIN, bez prefixu 0190:. Chybějící možnost Peppol znamená, že příjemce použije e-mailové dorčení (nejde o výpadek), nepoužívejte IČO. Viz „not available“ při (testovacím) odeslání příjemci níže a „Fakturace nizozemské veřejné správě“ ve znalostní bázi.

Uložte a znovu Odeslat po opravě obou bodů; Peppol by se pak měl objevit u dostupného OIN.

Tato hláška se zobrazí, když ručně nahrajete XML fakturu a v souboru chybí pole EndpointID dodavatele. V rozhraní platformy jde o pole "Partij-ID" pod "Dodavatel".

Řešení: v rozbalovacím seznamu vyberte hodnotu z vlastní organizace. Pokud seznam nezobrazí správný výsledek, znovu vyberte dodavatele, aby se obnovilo propojení.

Varianty vyhledávání: „Nebyly nalezeny žádné identifikátory aktivované pro odesílání pro společnost dodavatele“, identifikátory aktivované pro odesílání, „ověření dodavatele ještě není provedeno“, odeslání faktury nová administrace, dvě organizace s a bez s.r.o., neověřené identifikátory.

Tato zpráva, a fráze zákazníka „ověření dodavatele ještě není provedeno“ u první faktury nebo nové administrace, obvykle neukazuje na samostatný krok KYC dodavatele. Příčina je téměř vždy jeden z těchto čtyř bodů.

Kontrolní seznam (v pořadí):

1. Byla vybrána správná organizace dodavatele? Při dvou podobných organizacích (např. stejný název s a bez „s.r.o.“) mohla být vybrána nesprávná. Pomocí ikony tužky vyberte organizaci s ověřenými identifikátory -- organizace bez ověřených identifikátorů nemůže odesílat.
2. Je organizace aktivována? Ještě není aktivována: nejprve ji aktivujte pomocí Přidání a aktivace organizace.
3. Je zapnutý přepínač „Odesílání“? Přejděte na Organizace → vaše organizace → Detaily a zkontrolujte, zda alespoň jeden identifikátor (nejlépe IČO) má zapnutý přepínač Odesílání. U aktivované organizace je to obvykle již zapnuto.
4. Je DIČ správné? Zkontrolujte DIČ dodavatele i odběratele -- kód země a oddělovače -- viz BR-CO-09 výše. Chyba formátu DIČ se může objevit souběžně s touto zprávou.

Pokud zpráva přetrvává i po těchto čtyřech krocích, pošlete fakturu znovu po opravě údajů organizace nebo faktury.

Pokud fakturu nelze odeslat a zůstane ve složce "Koncepty", zkontrolujte dvě věci:

1. Odesílání povoleno: zkontrolujte v nastavení organizace, zda je aktivováno "Odesílání dokumentů". Pokud tato funkce není zapnutá, kontaktujte podporu.
2. Odeslat přes nastaveno: u odběratele musí být vedle OrganisatieID také vybrána možnost "Odeslat přes". Bez tohoto nastavení fakturu nelze odeslat.

Vyhledávací varianty: "faktura ERPx není v poštovní schránce výstup", "stav zpracování dodání eConnect", "zkontrolovat protokol Unit4 eConnect", "faktura z ERPx není viditelná eConnect", "ERPx odesláno nic v eConnect", "protokoly eConnect číslo faktury ERPx", "Unit4 ERPx stav zpracování dodání", "e-faktura ERPx nedorazila eConnect".

E-faktura vytvořená v Unit4 ERPx nedorazí do Poštovní schránky Výstup eConnect, přičemž kmenová data odběratele v ERPx vypadají správně (metoda odeslání e-fakturace, formát Peppol, vyplněné OIN/schéma). ERPx u faktury někdy zobrazuje stav zpracování "zpracovává se".

Postup první linie:

1. Vyžádejte si číslo faktury (plus datum faktury, organizaci/agendu eConnect a případný chybový kód nebo časové razidlo ERPx). Bez čísla faktury není možné spolehlivě vyhledat v protokolu nebo v Poštovní schránce Výstup.
2. Vyhledejte číslo faktury v Poštovní schránce Výstup (a konceptech) a v protokolech eConnect.
   • Nenalezeno v Poštovní schránce Výstup ani v protokolech eConnect: dokument nedorazil do eConnect. Odkažte klienta zpět na konzultanta ERPx/Unit4 -- příčina je pak na straně odeslání nebo konektoru ERPx, nikoliv u eConnect.
   • Nalezeno: postupujte podle standardní cesty stavu Poštovní schránky Výstup na této stránce (dodání se nezdařilo, koncept, duplicita nebo úspěšně zpracováno).
3. Při plně vyplněných kmenových datech odběratele bez důkazu o doručení nepředpokládejte okamžitě problém s dosažitelností Peppol nebo EndpointID odběratele. Rozhodující je důkaz o doručení do eConnect (číslo faktury dohledatelné v Poštovní schránce Výstup nebo protokolu), nikoliv stav kmenových dat odběratele.

Přesný význam stavu ERPx "zpracovává se" ve vztahu k doručení do eConnect není stanoven jako produktový fakt -- používejte tento stav pouze jako signál od klienta, nikoliv jako důkaz, že faktura již dorazila do eConnect.

Platforma eConnect někdy používá prefix jmenného prostoru v generovaných UBL fakturách (např. <urn:Invoice xmlns:urn="...">). Obě formy — s prefixem i bez — jsou technicky platné XML.

Příjemce odmítající faktury kvůli prefixu jmenného prostoru není Peppol-kompatibilní. Prefix jmenného prostoru není konfigurovatelný pro jednotlivé příjemce.

Komunikace zákazníkovi: faktura je technicky správná. Příjemce musí používat správný XML parser, který zpracovává jak jmenné prostory s prefixem, tak výchozí. Odmítání na základě prefixu jmenného prostoru není v Peppol povoleno.

Kódy chyb EBMS jako EBMS:0003 a EBMS:0004 jsou chyby transportu AS4 v komunikaci mezi přístupovými body. Zákazníci vidí SentError nebo SentRetry na platformě — samotný EBMS kód není viditelný v zákaznickém rozhraní.

Akce: přesměrujte zákazníka na TechSupport. TechSupport může zobrazit podrobnosti chyby prostřednictvím auditní stopy a Application Insights.

Kód chyby status 40 znamená, že dokument nebyl úspěšně zpracován. Dvě možné příčiny:

1. Chyba zpracování IDR: IDR nemůže dokument zpracovat a vrátí status 40.
2. Odmítnutí platformou: IDR dokument zpracoval, ale platforma ho poté nastaví na status 40 (např. kvůli validační chybě po konverzi).

Diagnostika: zaměstnanec eConnect musí prověřit v CloudWatch, jakými kroky zpracování dokument prošel.

Varianty vyhledávání: "opravit EndpointID znovu odeslat", "faktura odeslána na špatné Peppol ID resend", "Peppol ID změněno příjemce znovu doručit", "znovu odeslat PeppolID", "faktura znovu s jiným PeppolID", "Znovu odeslat Upravit PeppolID", "svislá výpustka znovu odeslat", "nabídka řádku znovu odeslat odchozí pošta", "faktura Doručeno klient nevidí nic", "returnedMessageId příjemce chybějící faktura".

Prostřednictvím možnosti Znovu odeslat v odeslané poště můžete znovu odeslat již odeslanou fakturu. Před faktickým odesláním můžete ještě upravit pole jako je odkaz (objednávkové číslo, OrderReference). Faktura je pak znovu odeslána se stejným číslem faktury, ale s opraveným odkazem.

Podání přes AFAS / E-verbinding: pokud je dokument již v odchozí poště, opakované odeslání prostřednictvím Znovu odeslat na platformě je správná cesta -- nikoli opětovné generování v AFAS nebo E-verbinding. Pokud tato akce vrátí červenou chybu události aplikace, nejprve zkontrolujte kombinaci schéma/hodnota identifikátoru příjemce (viz sekci „Neznámá chyba při volání události aplikace“ výše). Pokud dokument ještě není v odchozí poště, příčina leží v kanálu podání (ERP/E-verbinding) -- opakované odeslání se v tomto případě nevztahuje.

Stav Doručeno nepotvrzuje, že příjemce vidí fakturu ve svém vlastním účetnictví. Technicky Doručeno znamená, že přístupový bod dlužníka dokument přijal. Pokud dlužník stále uvádí, že nic neobdržel, poskytněte klientovi returnedMessageId jako referenční identifikátor pro dotaz u vlastního poskytovatele Peppol příjemce (viz sekci „Stav 'doručeno' ale příjemce fakturu neobdržel“ níže).

Toto je doporučený postup, když příjemce zamitá fakturu kvůli nesprávnému číslu objednávky nebo jiné chybě odkazu. Vyhnete se tak nutnosti vytvářet dobropis a novou fakturu.

V současném Peppol BIS Billing 3.0 a NLCIUS je podporován pouze 1 odkaz na objednávku (OrderReference) na fakturu. Jde o omezení vyplývající z evropské normy EN 16931. Pokud faktura pokrývá více objednávek, musí dodavatel odeslat samostatné faktury.

AdditionalDocumentReference může obsahovat dodatečné odkazy jiných typů (projekt, smlouva nebo odkaz kupujícího), nikoli však více OrderReference.

Budoucnost: Revidovaná EN 16931-1:2026 (formálně schválená CEN dne 13. března 2026) přidává podporu pro více nákupních objednávek na fakturu. Očekává se, že bude zapracována v budoucí verzi standardu Peppol (možná BIS Billing 4.0). Do té doby platí současné omezení 1 OrderReference na fakturu v BIS Billing 3.0 a NLCIUS.

Vyhledávací varianty: "OrderReferentieNummer", "KopersReferentieNummer", "OrderReferentieNummer vs KopersReferentieNummer", "objednávky nenapojené v ERPx", "PO pouze v BuyerReference".

Pokud je faktura zamítnuta kvůli chybějícímu nebo neznámému číslu objednávky, je třeba rozlišit dvě úrovně.

1. Odkaz je povinný podle EN 16931. Odkaz -- číslo objednávky nebo jiný odkaz (BuyerReference, odkaz na smlouvu nebo projekt) -- je vyžadován. Faktura bez jakéhokoli odkazu nesplňuje základní pravidla normy.

2. eConnect standardně nezamítá na základě obsahu odkazu. Jedinou situací, kdy platforma zamítá v tomto bodě, je případ, kdy není přítomen žádný odkaz.

3. Konfiguraci specifická pro zákazníka může být přísnější. Skutečné zamítnutí závisí na konfiguraci příjemce. V konkrétní konfiguraci může být faktura zamítnuta, pokud je odkaz u daného příjemce neznámý. To závisí na konfiguraci a není standardním chováním platformy eConnect.

Názvy polí platformy, nezaměňovat. Na platformě se BT-13 (OrderReference/ID) nazývá OrderReferentieNummer a BT-10 (BuyerReference) KopersReferentieNummer. Pro párování objednávek v ERP (např. Unit4 ERPx) patří číslo nákupní objednávky do OrderReferentieNummer -- KopersReferentieNummer je vlastní odkaz kupujícího a nenahrazuje shodu PO. Faktura může být platná podle EN 16931 s vyplněným pouze KopersReferentieNummer (norma vyžaduje alespoň jedno z obou), zatímco párování objednávky v ERP přesto selhává: platnost podle EN neznamená úspěšnou shodu objednávky. Pokud byla hodnota PO omylem uvedena pouze v KopersReferentieNummer, nechte dodavatele přesunout ji do OrderReferentieNummer; KopersReferentieNummer může zůstat vyplněno i nadále.

Akce:

• Znovu odešlete fakturu použitím možnosti Znovu odeslat (viz výše) s platným odkazem.
• Pokud je číslo objednávky neznámé, kontaktujte příjemce ohledně požadovaného postupu.

Faktura s konečným stavem InvoiceSentError (po chybě validace 4xx) nepodniká další pokusy o doručení. Pouze chyby 5xx se opakují (maximálně 8 pokusů, přibližně 35 hodin). U chyby 4xx je proveden jen jeden pokus; příjemci není odeslaná nic dalšího.

Neexistuje žádný DELETE endpoint pro prodejní faktury (salesInvoice). Odeslaná nebo zamítnutá prodejní faktura je událostí relevantní pro audit a zůstává dostupná v auditové stopvě po dobu 90 dnů. Pokud byla faktura nesprávná, vystavte dobropis nebo opravné fakturáci podle standardního účetního postupu.

Validace chyby jako TaxInclusiveAmount '-1.336061E6' není platným xs:decimal se vyskytují protože zdrojový systém serializuje číselné částky ve vědecké notaci (např. -1.336061E6 pro -1 336 061,00). Pole částky UBL jsou typu xs:decimal, který nepovolí notaci E.

Častá příčina: zdrojový systém uchovává částky interně jako double/float a používá výchozí konverzi řetězce, která automaticky přepíná na exponenciální notaci pro velmi velké nebo velmi malé hodnoty.

Řešení na straně zákazníka: aktualizovat zdrojový systém tak, aby byly částky vždy zapisovány jako obyčejný desetinný řetězec (např. prostřednictvím typů decimal/BigDecimal nebo desetinného vzoru nezávislého na lokálním nastavení, bez oddělovačů tisíců a bez notace E).

Na straně eConnect: nelze opravit automaticky -- hodnota je již nesprávná v dodávaném XML. Předat dodavateli softwarového balíčku.

Stav Doručeno znamená, že přijímající přístupový bod (poskytovatel služeb Peppol dlužníka) dokument technicky přijal a toto přijetí potvrdil. eConnect obdrží returnedMessageId (formát GUID@econnect.eu): důkaz, že faktura dorazila na přístupový bod příjemce.

Pokud dlužník tvrdí, že fakturu neobdržel, přičemž stav zobrazuje 'Doručeno', byl dokument doručen na přístupový bod dlužníka, ale v jeho vlastním softwaru nebo účetnictví není dosud viditelný. Jedná se o problém navazujícího zpracování na straně příjemce.

Postup řešení:

1. Potvrdit zákazníkovi, že faktura byla úspěšně odeslána na Peppol přístupový bod dlužníka a že eConnect obdržel potvrzení o doručení.
2. Poradit zákazníkovi, aby požádal dlužníka, aby kontaktoval svého vlastního poskytovatele služeb Peppol. Lze poskytnout returnedMessageId: s tímto identifikátorem může přijímající přístupový bod dokument dohledat.
3. Další řešení leží na straně přístupového bodu dlužníka; eConnect jako odesílající strana nemá přístup za bod doručení.

Varianty hledání: „přidat organizaci“ u faktury, portál dodavatele, název organizace + IČO vpravo nahoře, nelze upravit existující řádek organizace, nelze přejmenovat existující organizaci, screenshot organizace zákazníka vpravo nahoře, hlášení o identifikátoru při přidávání organizace (dodavatel), přidat vlastní organizaci samostatně, dlužník jako vlastní organizace, přidat příjemce faktury do prostředí, aktivovat organizaci dlužníka veřejné správy, příjemce musí být v prostředí, registrace pod vlastním OIN obce, OIN zákazníka jako vlastní organizace, fakturace obci s vlastním OIN, OIN příjemce není vlastní identifikátor, schéma 0190 dlužník.

Noví uživatelé -- zejména ti, kteří přecházejí z jiných služeb elektronické fakturace -- se někdy snaží při odesílání faktury přidat přijímající organizaci jako vlastní organizaci na platformě. To není potřebné a vede k chybové hlášce.

Pro odeslání faktury příjemci tato organizace nemusí být na vašem vlastním účtu: při vytváření faktury vyberte příjemce prostřednictvím pole pro vyhledávání dlužníka. Můžete hledat podle čísla obchodního rejstříku, názvu společnosti nebo čísla OIN.

Varianty hledání: „žádná organizace nenalezena“, „žádné organizace nenalezeny Francie“, „příjemce nenalezen podle názvu“, „vyhledávání dlužníka selhává“, „vyhledávání podle názvu dlužníka“, „nelze vyhledat podle Peppol ID“, „faktura přes GLN“, „ručně zadat dlužníka“, „obchodní rejstřík není Peppol“, „zahraniční příjemce není ve výsledcích“, „organizaci nelze vybrat“, „vyhledávání DIČ FR konceptu faktury“, „vyhledávání DIČ FR prázdné“, „0225 SIREN Odeslat přes“, „OrganisationID SIREN“.

Podstata: vyhledávání dlužníka podle názvu prohledává obchodní rejstřík (živnostenský rejstřík apod.), ne Peppol. Hláška „žádná organizace nenalezena“ u názvu organizace nebo francouzského DIČ tedy neznačí, že příjemce není registrován na Peppol, ani že je vyhledávání podle Peppol ID nemožné -- nevypovídá nic o online/offline stavu příjemce na Peppol.

Řešení:

1. Dlužník nenalezen v obchodním rejstříku? Zadejte dlužníka manuálně s údaji příjemce (název, adresa, země, identifikátor).
2. Je znám Peppol identifikátor příjemce?
   • Často GLN (schema 0088, označení GS1/EAN): nastavte Odeslat přes na GLN a do OrganisationID zadejte pouze číslice, bez prefixu 0088: (viz obecné pravidlo pouze-číslice výše u formátování identifikátorů).
   • Francie / CTC: nastavte Odeslat přes na 0225 (SIREN/FR CTC) a do OrganisationID zadejte pouze hodnotu SIREN, bez prefixu 0225: (čistých 9 číslic, nebo rozšířený formát SIREN_SUFFIX/SIREN_SIRET). Nezadávejte zde francouzské DIČ -- to je samostatné schema (9957). Viz Party identifiers.
3. Nevytvářejte příjemce prostřednictvím Přidat organizaci -- tato funkce je pro vlastní organizaci, ne pro příjemce faktury (viz sekci „Zmatek: pokus přidat příjemce jako vlastní organizaci“ výše).
4. Zadal klient endpoint, ale není dosažitelný? Nejprve potvrďte formát schema/hodnoty; pokud se ukáže, že příjemce ještě nemá aktivní registraci příjmu, francouzský příjemce musí dokončit registraci 0225, než testovací faktura úspěšně projde.

Varianty hledání: "enabled for Peppol sending", "additional Peppol activation", "is sending already enabled", "další aktivace odesílání", "University of Luxembourg", "9938", "scheme zahraničního příjemce".

U aktivované organizace je odesílání ve výchozím nastavení zapnuté -- je součástí standardního připojení. Neexistuje samostatný krok «Peppol send enable» nad rámec aktivního stavu organizace. Viz Registrace na Peppol pro úplný aktivační postup.

Příjemce (například zahraniční Peppol stranu jako lucemburskou univerzitu) zadejte pouze na faktuře, přes pole pro vyhledávání dlužníka (ID organizace + Odeslat přes). Příjemce nepřidávejte jako vlastní organizaci na účtu -- viz také sekci «Zmatek: pokus přidat příjemce jako vlastní organizaci» výše.

Stále dostáváte chybovou hlášku, která zde není popsána? Kontaktujte nás přes support.econnect.eu.