← Uživatelská příručka

EDI — základ

Společný základ každého připojení EDI a Peppol — evidence EDI zpráv, jejich stavy, odesílání a příjem a nastavení partnerů, která sdílejí všichni poskytovatelé.

K čemu slouží

Každý elektronický doklad, který Odoo vyměňuje s obchodním partnerem přes poskytovatele EDI — objednávka, potvrzení objednávky, avízo o expedici, faktura, elektronická faktura Peppol nebo obchodní odpověď — se eviduje jako jedna EDI zpráva. Modul poskytuje tuto evidenci a vše kolem ní:

• seznam EDI → Messages (zprávy), ve kterém se uchovávají všechny přijaté i odeslané doklady všech poskytovatelů včetně původního XML;
• stavy, kterými zpráva prochází, a tlačítka, která ji posouvají dál;
• způsob, jakým se odchozí zpráva předá poskytovateli a jak se příchozí doklady vyzvednou, uloží a zpracují;
• GLN každého kontaktu a přepínač automatického odesílání pro jednotlivé odběratele.

Sám se nikam nepřipojuje. Přenos zajišťuje modul poskytovatele:

Co se děje s objednávkami, dodávkami a fakturami, popisují návody pro stranu prodeje edi_base_sale, stranu nákupu edi_base_purchase a elektronickou fakturaci Peppol edi_base_peppol.

Uživatelské rozhraní je přeloženo do češtiny; anglické názvy polí a tlačítek uvedené v tomto návodu (v závorce nebo kurzívou) odpovídají anglické verzi.

Nastavení

1. Přidělte přístup. Nabídku EDI vidí jen členové dvou skupin, které se nastavují na uživateli (Nastavení → Uživatelé):

Administrátor ve výchozím stavu není v žádné z nich — nejprve přidejte sebe. Odeslání faktury přes Peppol vytváří EDI zprávu, proto ten, kdo ji odesílá, potřebuje skupinu EDI Manager (viz Peppol). 2. Zadejte vlastní GLN na kontaktu vaší společnosti (pole GLN, záložka Nákup a Prodej) a GLN každého partnera, se kterým si vyměňujete doklady EDIFACT. Připojení Peppol identifikují strany podle Peppol adresy — viz návod k Peppolu. 3. Nainstalujte a nastavte poskytovatele. Jeho nastavení najdete v Nastavení → EDI nebo přes EDI → Configuration → Settings (jen pro správce systému).

Kontakty

Na formuláři kontaktu, záložka Nákup a Prodej:

Další dvě pole patří poskytovatelům EDIFACT a jsou popsána níže.

Evidence zpráv

EDI → Messages zobrazuje všechny zprávy od nejnovější. Červené řádky jsou chybné, oranžové mají upozornění nebo pocházejí z testovacího prostředí, šedé jsou vyřízené. Filtry: Inbound (přijaté), Outbound (odeslané), Test Mode, Production, Errors (chyby), Pending (koncept, připravené nebo přijaté), Done, Peppol BIS3; seskupení podle poskytovatele, typu zprávy, směru, stavu nebo partnera.

Formulář zprávy obsahuje:

XML se vždy uloží jako příloha zprávy; doklady do 1 MB se zobrazují i přímo ve formuláři. Vazby na objednávku, dodávku, fakturu či přijatou fakturu doplňují moduly pro prodej, nákup a Peppol, které zároveň přidají na tyto doklady záložku EDI Messages.

Zpráva patří společnosti dokladu, ke kterému vznikla, ne společnosti, ve které uživatel zrovna pracoval, a jménem této společnosti se také odesílá a zpracovává.

Stavy

Co přesně Sent a Done dokazují, závisí na poskytovateli. U ePošťáku Sent znamená, že přístupový bod doklad převzal k přenosu, a teprve Done, že jej přijal přístupový bod příjemce.

Odesílání

Odchozí zprávy vytvářejí moduly poskytovatelů z dokladů — automaticky při potvrzení či zaúčtování dokladu, je-li automatické odesílání zapnuté, nebo tlačítkem poskytovatele. Zprávu můžete odeslat nebo znovu odeslat i sami:

• tlačítkem Send na formuláři zprávy (EDI Manager) u odesílaných zpráv ve stavu Draft, Ready, Queued nebo Error;
• hromadně: označte zprávy v seznamu a zvolte Akce → Send (queue dispatch). Dialog nejprve ukáže, co se odešle a co se přeskočí (přijaté zprávy, zprávy již odeslané či vyřízené).

Odeslání smaže předchozí chybu, přesune zprávu do stavu Queued a zapíše na objednávku, dodávku nebo fakturu řádek „… queued for dispatch via …“.

Jak zpráva opustí frontu

Každý poskytovatel určí jeden ze dvou způsobů:

• Fronta úloh. Ze zprávy se stane úloha na pozadí ve frontě úloh OCA (queue_job), kterou se zprávou propojí modul edi_base_queue_job. Takto pracují konektory Editel a GRiT, které ho také instalují. Zpráva s úlohami má tlačítko Queue Jobs; na úloze otevře zprávu tlačítko Related a seznam úloh lze podle zprávy filtrovat. Úloha se zkouší nejvýše pětkrát.
• Naplánovaná akce. EDI: send queued messages (no job runner) běží každé 2 minuty a odešle nejvýše 100 zpráv ve frontě od poskytovatelů, kteří se k ní přihlásili — mezi nimi je ePošťák. Každá zpráva se odesílá samostatně: při dočasném selhání (poskytovatel nedostupný, překročený limit požadavků) zůstane ve stavu Queued s varováním v Error Details a časem Retry Not Before: Retry-After poskytovatele, jinak pauza, která se s každým pokusem zdvojnásobí (2, 4, 8 … minut, nejvýše hodina). Po pěti dočasných selháních — překročený limit se nepočítá — přejde do stavu Error s posledním důvodem; při jiném selhání hned. Opětovné odeslání začne počítat znovu. Jedna neodeslatelná zpráva ostatní nezastaví ani nevrátí zpět a výsledek každé zprávy se uloží před odesláním další, takže přerušený běh si ponechá to, co poskytovatel už převzal. Když běh vyčerpá svůj čas, zbytek zůstane ve frontě na další běh.

O způsobu rozhoduje poskytovatel, ne databáze, takže ani v databázi, kde jsou oba, se jedna zpráva neodešle dvakrát.

Příjem

Každý poskytovatel má vlastní naplánovanou akci, která vyzvedává nové doklady. Pro každý doklad platí:

1. Pokud už od téhož poskytovatele přišla zpráva se stejným ID zprávy, doklad se přeskočí jako duplicita (a potvrdí se). Skupina poskytovatelů to může zpřísnit: u Peppolu se musí shodovat i odesílatel, příjemce a druh dokladu — viz příjem dokladů Peppol.
2. Jinak se nejprve uloží i s XML jako zpráva ve stavu Received.
3. Poté se zpracuje — vznikne objednávka, doklad, zaznamená se odpověď — a zpráva přejde do stavu Done. Pokud zpracování selže, zpráva přejde do stavu Error s důvodem v Error Details; doklad se neztratí.
4. Doklad se poskytovateli potvrdí, aby ho nedoručil znovu.

Hlásí-li poskytovatel, že čekají další doklady, vyzvednutí se spustí znovu hned, ne až v dalším intervalu.

Reprocess (EDI Manager, přijaté zprávy ve stavu Received nebo Error) spustí krok 3 znovu — typicky poté, co jste založili chybějící produkt nebo doplnili GLN kontaktu.

Párování produktů

Řádky přijatých objednávek a avíz se párují na produkty v tomto pořadí:

1. čárový kód — v podobě, jak přišel, bez úvodních nul a doplněný na 8, 12, 13 a 14 číslic, protože partneři se v doplňování EAN neshodují;
2. vlastní kód odesílatele pro produkt (Kód produktu dodavatele v řádku dodavatele na produktu), je-li odesílatel znám;
3. interní reference produktu.

Pokud řádek nespáruje nic, celá přijatá objednávka standardně selže a chyba vypíše všechny nespárované řádky (EAN, množství, cenu, názvy a kódy) s radou založit produkty a zprávu znovu zpracovat. Modul edi_base_sale_pending to mění, viz čekající řádky.

Variabilní symbol

Kde zpráva nese variabilní symbol — bankovní údaje dodavatele v odchozí INVOIC, hrazená faktura v REMADV — je to symbol, jaký používá český nebo slovenský platební příkaz: jen číslice, nejvýše deset. Je to Variabilní symbol z l10n_cssk_payment_symbols, je-li nainstalován; jinak číslice pole Payment Reference, jinak čísla faktury (u přijaté faktury čísla dodavatele), a ponechá se posledních deset. Z INV/2026/00012 vznikne 202600012. Není-li tam ani jedna číslice, prvek se vynechá.

Identita stran EDIFACT (GS1)

Modul edi_base_gs1, který se instaluje s poskytovateli Editel a GRiT, přidává nastavení stran GS1, která potřebuje EDIFACT, a Peppol ne:

Omezení

• Data a časy v dokladech EDIFACT se čtou a zapisují v časovém pásmu ze systémového parametru edi.timezone (výchozí Europe/Bratislava).
• U dokladů EDIFACT se duplicity rozpoznávají jen podle ID zprávy (interchange) a poskytovatele; Peppol přidává odesílatele, příjemce a druh dokladu (viz omezení Peppolu).
• Zprávy nelze z uživatelského rozhraní smazat; právo mazat je nemá nikdo.