Export do Pohody (DO_POHODY)¶

Stav k 2026-06-21

Architektura integrace¶

Směr: eshop → Pohoda, přes FTP. Eshop zapíše XML soubor, Pohoda si ho stáhne přes FTP — žádné API, žádná HTTP komunikace z naší strany.

Pohoda ERP běží na Windows, stahuje z DO_POHODY/IMPORT/ přes FTP.

Proces exportu¶

Admin spustí export (manuálně nebo cron)
Vyberou se objednávky: exportovano='0' a status='O'
Přidělí se sekvenční číslo: MAX(export) + 1 → 7místné číslo
Nastaví se exportovano=1, export={číslo} na vybraných objednávkách
Šablonou (Stormware XML schema v2.0) se vygeneruje obsah
Uloží se DO_POHODY/PM{číslo}.xml (CZ) nebo SK{číslo}.xml (SK)
Pokud XML obsahuje produkt s kódem → kopie i do DO_POHODY/IMPORT/

Soubory bez produktů (samé kupóny) se do IMPORT/ nekopírují, Pohoda je tedy nebere.

XML formát¶

Stormware XML v2.0, namespace http://www.stormware.cz/schema/version_2/, typ receivedOrder. IČO 27114295 v root elementu. Každá objednávka = jeden <dat:dataPackItem>.

Co se exportuje / vylučuje¶

Kategorie položky	Chování
Normální produkt	standardní export
`PHE` / `BARVA`	vylučuje se
kód začíná `FOXDP`	vylučuje se (dárkové poukazy)
`doprava` + `platba`	sloučí se do jedné položky
slevový kupón	exportuje se, sklad `Vouchery`

Mapování skladů¶

Sklad se odvozuje z pohoda_rada objednávky:

Rada	Sklad (`ids`)	Výjimka
`OPH`, `OSK`	`SZLAT`	pokud `komise=1` → `KOM`
`EHY`	`Hypernova`
`ESE`	`SESTKA`
`ELE`	`Letnany`
`EKA`	`Karolina`
ostatní	`SZLAT`	fallback

Mapování dopravy a platby¶

Křehké řešení — matching dle textového názvu

Všechna mapování (dopravce, sklad, forma úhrady, výdejní místo) jsou regex/substring podmínky nad textovým názvem metody z eshop_platebni_metody. Přejmenování metody v adminu (nebo jiná diakritika, jiné pořadí slov) tiše rozbije mapování — objednávka dostane špatný Pohoda kód nebo padne na fallback OSOB bez jakékoliv notifikace.

Zdroj: lib/eshop/class.export-data-objednavky.php, metody kod_dopravy(), kod_carrier(), forma_uhrady(), dopravaVyzvednuti()

Dopravce (carrier) — detekce přes preg_match na strtolower(utf2ascii($name)):

Podmínka	Pohoda kód (příklady)
obsahuje `gls` + `sk` + výdejní místo	`GLS SK PP D` / `GLS SK PP U`
obsahuje `gls` + `sk`	`GLS SK D` / `GLS SK U`
obsahuje `gls` + výdejní místo	`GLS CZ PP D` / `GLS CZ PP U`
obsahuje `gls`	`GLS CZ D` / `GLS CZ U`
obsahuje `dpd` + `sk` + výdejní místo	`Geis SKOO D` / `Geis SKOO`
obsahuje `dpd` + `sk`	`Geis SKD` / `Geis SKPP`
obsahuje `dpd` + výdejní místo	`Geis OOD` / `Geis OO`
obsahuje `dpd`	`Geis D` / `Geis U`
obsahuje `eu`	`ČPEU1`–`ČPEU4` (dle číslice v názvu)
obsahuje `balikovna`	`ČESKÁ POŠTA BD` / `ČESKÁ POŠTA B`
obsahuje `balik na postu`	`ČESKÁ POŠTA BNPD` / `ČESKÁ POŠTA BNP`
obsahuje `cesk[ea] post[ay]` nebo `ceskou postou`	`ČESKÁ POŠTA D` / `ČESKÁ POŠTA U`
nic nesedí	`OSOB` — tiše, bez logu

DPD kódy nesou prefix Geis — historický pozůstatek změny přepravce, Pohoda to tak má nakonfigurované.

Forma úhrady — stejný princip, preg_match na název platby:

Podmínka	Pohoda kód
`hotove`	`hotově`
`paypal`	`paypal`
`kartou`, `karten`, `card`, `online`, `ihned`	`plat.kartou`
`bank`, `prevod`, `vopred`, `home credit`	`Příkazem`
`dobie?rk`, `deliver`	`dobírkou`
nic nesedí	prázdný řetězec

Výdejní místa¶

Session dependency — export funguje jen ze živého checkoutu

Celý blok pro výdejní místa čte $_SESSION['objednavka']['udaje']. Session existuje jen při exportu spuštěném bezprostředně po checkout — cron nebo manuální re-export historické objednávky nemá session → adresy výdejního místa budou prázdné nebo null.

Typ	Zdroj adresy	Poznámka
GLS Pickup	`$_SESSION`	BUG: `$zeme_dod_iso2 = substr($point->id, 0, 2)` — `$point` není v této větvi definován, bude null/error
DPD SK	tabulka `doruceni_dpd`	funguje, `$point` se nastaví z DB
DPD CZ	`$_SESSION`	BUG: komentář `"DPD CZ uz nebezi z DB"` — přestaly jít z DB, ale `$point->id` se stále čte, `$point` je null
Balíkovna	`$_SESSION`	město parsováno regexem `preg_replace('/.*-/', '', $name)` — fragile pokud formát řetězce není `PSC - Mesto`
ČP Balík na poštu	tabulka `doruceni_posty`	funguje, `$posta` z DB

DPH logika¶

CZ standardní: high / low dle dph na položce
SK OSS: historyHigh / historyLow + percentVAT (Pohoda dopočítá sazbu pro datum)
B2B bez DPH (bez_dph=1): payVAT=false, rateVAT=none

CENOVE-AKCE¶

Směr: eshop → Pohoda, přes FTP. Pohoda si sama stahuje soubor z adresáře DO_POHODY/CENOVE-AKCE/ přes FTP. Na rozdíl od objednávkových XML není sekvenční — soubor se vždy přepíše, Pohoda čte vždy aktualni.csv.

Spouští se cronem (cron/akce_export.php), třída AkceExport.

Obsah souboru¶

Jeden řádek = jeden produkt v jedné akci na jednom skladu. Produkt v 5 skladech → 5 řádků.

{titulek akce};{akce_id};{A=aktivní/N=neaktivní};{od};{do};{sleva %};{produkt_id};{kod};{sklad_id};{sklad_zkratka};{cena_puvodni};{cena_akce};{akce_procent}

Příklad:

Black Friday plastiky 15%;421;A;2024-01-01;2030-12-31;15;524269;79609005;4;SZLAT;689.00;586.00;15

Neaktivní akce se exportují také (příznak N), ale bez produktových řádků — jen hlavička akce s prázdnými poli.

Podmínka exportu produktu¶

WHERE akce_id = ? AND cena_eshop = ROUND(cena_b * (100 - akce_procent) / 100)

Exportují se jen produkty kde aktuální cena_eshop odpovídá výpočtu ze slevy. Produkt přiřazený k akci, ale s ručně přepsanou cenou nebo jinou výjimkou, se do exportu nedostane.

Dopad na Sylius¶

Pohoda bude tento feed potřebovat i po migraci. Sylius bude muset generovat aktualni.csv ve stejném formátu — zdroj dat se změní (Sylius Promotion nebo ChannelPricing místo eshop_akce), ale struktura souboru musí zůstat kompatibilní.

Dopad na Sylius¶

FTP integrace — závislost na FTP přístupu

Pohoda stahuje XML přes FTP. Při migraci musí být FTP přístup k DO_POHODY/IMPORT/ zachován, nebo přejít na Stormware XMLDataServer (HTTP API na straně Pohody — eshop volá API při exportu objednávky, nevyžaduje FTP).

Mapování musí přežít migraci

Tato data musí Sylius umět exportovat do Pohody:

pohoda_rada → číselná řada v Pohodě (FV, ZF, OPH, OSK…)
sklad podle řady (SZLAT, KOM, Hypernova, SESTKA, Letnany, Karolina)
dopravní kódy (GLS CZ/SK, ČP, DPD/Geis…)
SK OSS DPH s historyHigh/historyLow

PHE/RP v exportu

PHE položky se aktuálně do Pohody neexportují. V Sylius musí platit stejné pravidlo — kategorie nebo příznak na položce objednávky k vynechání z exportu.

Řešení text-matchingu — Sylius má code

Sylius ukládá ShippingMethod::code a PaymentMethod::code jako string identifikátory (např. gls_cz, dpd_sk, platba_kartou). Pohoda exporter bude mapovat přímo přes config array:

$shippingMap = ['gls_cz' => 'GLS CZ U', 'gls_cz_dobirka' => 'GLS CZ D', ...];
$paymentMap  = ['kartou' => 'plat.kartou', 'prevod' => 'Příkazem', ...];

Přejmenování metody v adminu nic nerozbije. Přidání nové metody = přidání řádku do configu.

Výdejní místa — custom field na Shipment

Aktuální $_SESSION závislost zmizí. Při checkoutu se pickup point ID a adresa uloží jako custom atribut na Shipment (nebo Order). Data jsou persistentní v DB — re-export historické objednávky funguje stejně jako čerstvé.

Sylius pickup point nativně nepodporuje. Možnosti: Setono/SyliusPickupPointPlugin, nebo jednodušeji vlastní custom field — stačí pro potřeby Pohoda exportu.

Merge doprava + platba

V Pohoda exporteru se bude explicitně načítat Order::getShipments() a Order::getPayments() a sloučí se do jedné XML položky. Čistší než průchod přes kategorie == 'doprava' v poli položek košíku.