techone --pruvodce=b2b-portal
B2B portál: když zákazník přestane chtít posílat objednávky e-mailem
Průvodce B2B portálem napojeným na ERP. Co řešit při návrhu, jak ho integrovat, časté chyby z praxe.
Aktualizováno:
Ve zkratce
- O čem to je
- B2B portál pro samoobslužné zákazníky: firemní odběratel se přihlásí, vidí svůj sortiment, ceny dle smlouvy, otevřené objednávky a fakturaci. Mid-market scénář, kde EDI dává smysl jen u části partnerů.
- Klíčové vrstvy
- Role a oprávnění, paralelní state management objednávek, datový model (referenční / konfigurační / transakční), REST API integrace s ERP, validační vrstvy, audit a monitoring.
- Tři cesty
- Hotová B2B platforma s ERP konektorem, vlastní vývoj přes REST API, nebo portál jako modul existujícího ERP. Volba závisí na rozsahu úprav, době do produkce a velikosti týmu.
- Časový rámec
- Analytický návrh 4-8 týdnů. Hotová platforma 2-4 měsíce do produkce, vlastní vývoj 4-6 měsíců, modul ERP záleží na vendor roadmapě.
- Náklady
- Závisí na cestě (platforma vs vývoj), počtu uživatelů, customizaci a ERP. Řekneme po úvodní konzultaci.
Anatomie B2B portálu: 6 vrstev architektury
B2B portál není jedna aplikace s pár obrazovkami. Je to architektura ve vrstvách, kde každá vrstva může selhat samostatně. Pochopení vrstev rozhoduje o tom, jestli portál bude fungovat za 6 měsíců, nebo bude druhý systém na ruční přepisování.
Pokud řešíš automatizovanou B2B komunikaci s velkými partnery (OEM, retail, EDIFACT), patří to do EDI integrace pro výrobce. Tady jsme zaměřeni na portál pro samoobslužné zákazníky.
1. Role a oprávnění
Externí role: zákazník, jeho schvalovatel u větších objednávek. Interní role: obchodník (spravuje smlouvu, ceník, dostupnost), validátor (kontroluje realizovatelnost), administrátor (parametry, uživatelé). Každá role má jiný workflow a jiný pohled na data. Špatně navrhnutá oprávnění jsou nejčastější důvod, proč se portál po 3 měsících přestává používat.
2. Paralelní state management objednávky
Objednávka nemá jeden lineární stav. Má víc os, které neběží synchronně. Procesní průběh (přijata → ve validaci → potvrzena → v expedici → dodána), validační stav (čeká na kontrolu → schválená → zamítnutá) a platební cyklus (proforma → částečná úhrada → plně zaplaceno). Objednávka může být potvrzená procesně, ale neschválená validátorem. Validovaná, ale nezaplacená. Stavy je potřeba modelovat jako tři osy s definovanými vazbami, ne jako lineární průchod.
3. Datový model: referenční, konfigurační, transakční
Tři typy dat, každý s jinou autoritou. Referenční data (artikly, ceník, smlouvy zákazníka, sklad) přicházejí z ERP a v portálu je jen zrcadlíš, nikdy needituješ. Konfigurační data (uživatelské role, schvalovací pravidla, parametry) vedeš v portálu, ne v ERP. Transakční data (objednávky, audit log, history) vznikají v portálu a po validaci se zapisují do ERP. Smíchání těchto tří typů je root cause většiny portál projektů, které se po roce přepisují.
4. ERP integrace přes REST API
Portál komunikuje s ERP přes definované endpointy: GET pro referenční data (katalog, cena, sklad, smlouva), POST pro transakce (založení objednávky, změna stavu). Klíčový je error handling: když ERP neodpovídá, portál nesmí zamrznout ani ztratit data. Retry policy s exponential backoff, dead-letter queue pro zprávy, které se opakovaně nedoručí, audit log každé operace. Pro Microsoft Dynamics máme zaběhnutý vzor, viz <a href="/sluzby/erp-integrace">ERP integrace</a>.
5. Validační vrstvy
Validace neběží na jedné úrovni. Vrstvy jsou čtyři: data integrita (povinná pole, formáty, IČO, IBAN), obchodní pravidla (limit zákazníka, dostupnost, minimální množství, slevy), finance (kreditní limit, platební historie, blokace), logistika (paletové množství, dispoziční lhůta, vychystávání z více skladů). Každá vrstva může objednávku zastavit z jiného důvodu a zákazník musí dostat srozumitelnou zpětnou vazbu, ne "validation error 4032".
6. Audit a monitoring
B2B portál není transakční vetřelec, který nikdo nesleduje. Audit log zachycuje kdo, kdy a jak změnil objednávku. Monitoring sleduje dobu odezvy API volání, chybovost a zpoždění fronty (kolik zpráv čeká na ERP zápis). Bez monitoringu se chyby objeví až při auditu nebo když se zákazník začne ptát, kde má fakturu.
Tři cesty, jak postavit B2B portál
Když firma zvažuje B2B portál, typicky předpokládá, že "to vyvineme od nuly". Ve skutečnosti jsou tři reálné cesty a každá má svůj kontext. Správná volba závisí na rozsahu úprav, době do produkce a kapacitě týmu.
Hotová B2B platforma + ERP konektor
Pro standardní B2B workflow s rychlým nasazením. Do produkce 2-4 měsíce, maintenance má vendor, dobré UX bez úprav. Cena: měsíční licence per uživatel a omezené možnosti úprav. Příklady: Shopware B2B, BigCommerce B2B, Sana Commerce. Volba závisí na ERP, který používáš.
Vlastní vývoj + REST API integrace
Pro specifické workflow, multi-vendor ERP a potřebu plné kontroly nad UX. Žádné licence per uživatel, plná kontrola, úpravy bez kompromisů. Cena: delší doba do produkce (4-6 měsíců) a maintenance je na tobě. Stack typicky React/Vue + .NET nebo Node backend + REST API na ERP. Tudy jdeme typicky my, viz <a href="/sluzby/aplikace-na-miru">aplikace na míru</a>.
Portál jako modul existujícího ERP
Pro plnou integraci dat s omezenými UX požadavky. Žádná samostatná integrace, jeden zdroj pravdy v ERP, jednodušší údržba. Cena: UX je obvykle slabší než dedikovaný portál, omezené možnosti úprav, závislé na ERP roadmapě. Funguje pro firmy, kde portál je sekundární kanál.
EDI nebo portál: rozhodovací mřížka
Mid-market výrobní nebo distribuční firma má typicky oboje. EDI pro velké partnery, portál pro mid/small zákazníky. Otázka není "buď, anebo", ale "kde se hranice".
Velikost odběratele
EDI: velký partner (OEM, retail řetězec, automotive). Portál: mid/small zákazník, kde se očekává samoobsluha přes UI.
Frekvence komunikace
EDI: vysoká, denní nebo hodinová. Portál: nepravidelná, sezónní, ad-hoc objednávky.
Standardizace
EDI: pevná podle specifikace partnera (EDIFACT, EANCOM, VDA). Portál: flexibilní, UI workflow se přizpůsobuje uživateli.
Lidský zásah
EDI: žádný, system-to-system bez UI. Portál: plný, uživatel klikne, schvaluje, doplňuje data.
Time-to-market
EDI: 4-8 týdnů per partner. Portál: 2-6 měsíců na první nasazení, pak další zákazníci samoobslužně.
Čtyři chyby, které vidíme v B2B portál projektech
Tyhle patterny vidíme opakovaně. Některé jsou viditelné už ve fázi návrhu, jiné se projeví až po nasazení.
1. Portál bez aktualizace cen z ERP
Ceny dle smlouvy zákazníka jsou v ERP. Pokud portál táhne ceny ručně nebo přes nightly batch, nejsou aktuální. Zákazník vidí jinou cenu než fakturu, vznikne reklamace, podpora má hodiny zbytečné práce. Real-time API volání nebo eventový push z ERP je nutnost.
2. Login bez SSO a 2FA
B2B portál není B2C e-shop. Uživatel je interní zaměstnanec firmy s vlastním directory (Active Directory, Google Workspace). SSO přes SAML nebo OIDC je standard, ne nadstavba. 2FA ochrání přístup, který má dopad na fakturaci.
3. Žádný auditní záznam
Když zákazník popře, že objednávku zadal, audit log je jediný důkaz. Kdo se přihlásil, kdy, z jaké IP. Která pole změnil. Jaký response API vrátilo. Bez auditu je portál právně rizikový a nelze řešit incidenty.
4. Mobilní rozhraní jako afterthought
B2B nákupčí často objednává z terénu nebo na cestě. Pokud portál vypadá na mobilu jako desktop zmenšený, používání rapidně klesne. Mobile-first design pro klíčové scénáře (vytvořit objednávku, sledovat dodávku, schválit nákup) je standard.
Často kladené otázky
Kolik stojí B2B portál?
Závisí na zvolené cestě (hotová platforma vs vývoj), počtu uživatelů, rozsahu úprav a ERP. Hotová platforma má měsíční licenci per uživatel, vývoj jednorázovou cenu plus maintenance. Konkrétní rozpočet umíme říct po úvodní schůzce nad analytickým návrhem.
Jak dlouho trvá analytický návrh B2B portálu?
Analytická fáze typicky 4-8 týdnů. Výstupem je dokument popisující role, oprávnění, scénáře použití, datový model, REST API specifikaci a validační pravidla. Slouží přímo jako vstup pro vývojový tým bez nutnosti vracet se na business stranu.
Funguje to s naším ERP (K2 ERP, Helios, ABRA)?
Ano, pokud ERP má REST API nebo databázový přístup. Pro Dynamics 365 Business Central i F&O máme zaběhnutý vzor integrace. K2 ERP, Helios a ABRA Flexi typicky napojujeme přes API nebo souborovou výměnu. U starších systémů bez API najdeme cestu přes databázové triggery.
Jak řešíte vychystávání z více skladů a paletové množství?
Závisí na business rules. Picking strategy (FEFO, FIFO, nejbližší sklad) konfigurujeme dle požadavků. Paletové množství kontrolujeme ve validační vrstvě: pokud zákazník objednává nestandardní množství, portál buď nabídne dorovnání na celé palety, nebo zobrazí příplatek.
Co s mobilní podporou? Stačí responzivní web?
Pro klíčové scénáře (objednávka, status, schválení) doporučujeme mobile-first design responzivního webu. PWA je často lepší volba než nativní aplikace - funguje offline, push notifikace, instalace přes prohlížeč. Nativní aplikace má smysl při čtečce čárových kódů nebo hlubokém offline využití.
Jak vypadá auditní záznam prakticky?
Každá změna objednávky (založení, schválení, zamítnutí, úprava) má záznam: timestamp, uživatel, IP, before/after stav, korelace s API voláním do ERP. Logy jsou immutable, uchovávají se min. 5 let dle účetních povinností. Audit dashboard umožňuje filtrovat podle uživatele, období, zákazníka.
Kam dál
ERP integrace (služba)
Napojení ERP na e-shop, CRM, sklad. EDI s obchodními partnery, REST API integrace.
EDI integrace pro výrobce
Automatizovaná B2B komunikace s velkými partnery. EDIFACT, ORDERS, DESADV, INVOIC.
Aplikace na míru (služba)
B2B portály, firemní aplikace, mobilní řešení napojené na ERP.
Řešíte B2B portál?
Analytický návrh, vývoj nebo integrace s existujícím portálem. Z naší práce s ERP integracemi vám řekneme, kde se to typicky zasekne.
Domluvit konzultaci