Dnešní velkoobchodní web umí 30 věcí, které běžný e‑shop albi.cz nemá. U každé z nich: co přesně dělá, kde se dnes nastavuje a co bude potřeba udělat, aby fungovala i na novém řešení.
Tři projekty, jeden směr. Tahle stránka popisuje jen fialovou část.
Většina B2B pravidel nevzniká v administraci e‑shopu, ale v AlbiLine. Z 28 funkcí se v adminu nastavuje jen zhruba třetina. Zbytek buď přichází z ERP (kdo je špatný plátce, kdo má jaký ceník, kdo smí vidět který produkt), nebo je natvrdo v kódu. Nové B2B tedy musí hlavně umět přijímat pravidla z AlbiLine.
Obálka albi.eu už toho pro B2B nese víc, než se čekalo. Napojení na AlbiLine tam má B2B větve záměrně zachované „pro budoucí B2B projekt". Několik věcí se proto nebude portovat ze starého webu, ale převezme z albi.eu - v tabulce jsou modře.
B2B weby zůstanou oddělené. Klient 7. 9. potvrdil (PBS 121587): čtyři samostatné e‑shopy - CZ, SK, PL a nový EN. Není to tedy model albi.eu, kde je jeden web se 17 trhy podle měny. Z albi.eu se proto přebírají moduly a napojení, ne nastavení webů.
Stránka se snaží mluvit lidsky, těmto osmi slovům se ale vyhnout nejde. Kdo je zná, může přeskočit.
Každý řádek je jedna věc, kterou dnešní B2B skutečně umí (ověřeno v kódu) a běžný e‑shop ne. Co má teprve přibýt, je v samostatné sekci níž. Čtyři sloupce: co to dělá · kde se to dnes nastavuje · co s tím na headlessu. Cesty do administrace jsou zatím bez domény - doplní se, až bude známá.
Na co odpovídá barevný štítek: kde ta funkce dnes existuje kromě starého webu - protože na starém webu funguje všech 30. Zelená = jádro FrontAPI, modrá = obálka albi.eu, oranžová = v jádře, ale bez FrontAPI, červená = jen ve starém webu.
Pozor na oranžové řádky. Kód v jádře opravdu existuje, takže v auditu vypadají hotově. Je ale napojený jen na starý frontend. Pro headless jsou to vždy dvě práce: nový endpoint a nový kus frontendu.
Štítek jádro označuje řádky, kde se musí sáhnout do jádra MasterShopu - tedy do kódu společného pro všechny klienty. Všechno ostatní se dá udělat v obálce ALBI.
| Funkce | Co to dělá a k čemu je | Kde se to dnes nastavuje | Kde to je kromě starého webu · co udělat |
|---|---|---|---|
| Přístup a účty | |||
| Login wall | Bez přihlášení není vidět vůbec nic - žádné produkty, žádné ceny, ani úvodní stránka. Nepřihlášený člověk uvidí jen přihlašovací formulář, žádost o registraci a zapomenuté heslo.Proč: velkoobchodní ceny a sortiment nemají být veřejné. | Nikde - seznam povolených stránek je natvrdo v kódu. | jen starý webFrontend zamkne všechny stránky kromě několika, jádro SFX dnes chrání jen stránky účtu. Přihlašování samotné jádro umí. |
| Registrace jako žádost | Zájemce vyplní formulář (firma, IČO, kontakt), ale účet mu nevznikne. Odejde jen e‑mail obchodníkovi a potvrzení zájemci. Účet pak založí obchodník ručně v administraci - nebo přijde z AlbiLine.Proč: ALBI si vybírá, komu velkoobchodní přístup dá. | /admint/options.php?section=b2bModuleSettingsE‑mail obchodníka a kódy šablon. Samotná žádost se nikam neukládá. | má albi.euOdesílání e‑mailů je v obálce albi.eu hotové. Zbývá endpoint a formulář ve frontendu. |
| Hlavní účet a podúčty | Jedna firma může mít víc přihlášení. Hlavní účet (třeba majitel) vidí všechno a spravuje ostatní. Podúčet (třeba skladník) může objednávat, ale nesmí měnit adresy, zakládat další účty ani opakovat cizí objednávky. | Nikde - kdo je hlavní účet, určuje AlbiLine. | v jádře bez FrontAPIJádro to má, ale bez FrontAPI. Nový endpoint na správu podúčtů + obrazovka ve frontendu. |
| Příznak „špatný plátce" | Firma, která dluží, dostane v AlbiLine příznak. E‑shop ho převezme. Co přesně s ním dělá (zablokuje objednávku? omezí platby?), se z kódu nepodařilo dohledat. | Nikde - přichází z AlbiLine. | v jádře bez FrontAPIPříznak už chodí i do albi.eu. Dohledat, co má blokovat, a propsat do endpointů. |
| Kódy obchodních zástupců | Ke každé adrese zákazníka patří jeho obchodní zástupce a oblastní manažer. Zobrazuje se u objednávky, aby bylo jasné, čí zákazník to je. | Nikde - přichází z AlbiLine. | jen starý webPřenést sloupce z adresy do dat, která FrontAPI vydává o objednávce. |
| Co zákazník vidí | |||
| Zavřený katalog | Úplně opačně než v e‑shopu: zákazník nevidí nic, dokud mu někdo něco nepovolí. Bez doručovací adresy nevidí ani jeden produkt. S adresou vidí jen ty produkty, které má na svém seznamu z AlbiLine - nebo všechno, když má zapnuté „povolit vše".Příklad: hračkářství vidí hry a hračky, papírnictví jen diáře a přání. | Seznam povolených produktů přichází z AlbiLine./admint/customers.php?activeTab=addresses&customers_action=edit&customers_id={id}U adresy jde jen omezit kategorie. | jen starý web jádro ověřenoKlasické jádro filtr má: výpis i kontrolu v košíku podle doručovací adresy. Na headlessu se ale neuplatní sám: hlavní účet si adresu přes FrontAPI nepřepne a výpis jde z UpSearch, který filtr nemá. |
| Skupiny zákazníků (whitelist) | Obchodník založí skupinu, třeba „Knihkupectví", a nastaví jí, které kategorie, bannery, články a způsoby dopravy vidí. Zákazníkovi se skupina přiřadí na adrese. Sedm záložek v administraci. | /admint/customerswhitelistgroups.phpPřiřazení skupiny k adrese: záložka Dodací adresy u zákazníka. | jen starý webCelý modul je jen ve starém webu. Portovat, dát mu endpointy a naučit frontend skupinu respektovat. |
| Filtrace plateb a doprav | Ne každý zákazník smí platit na fakturu nebo si nechat poslat zboží kurýrem. Které platby a dopravy uvidí, řídí jeho adresa (z AlbiLine) a jeho skupina. Bez adresy nedostane nabídnutou žádnou. | Podle adresy: AlbiLine./admint/customerswhitelistgroups.php?activeTab=transports…Podle skupiny: záložka Doprava. | jen starý webNabídku metod jádro vydá, ale filtr podle adresy a skupiny je jen ve starém webu. Portovat do obálky. |
| Ceny | |||
| Ceník na adrese | Velkoobchodní ceny se liší podle zákazníka. Ceník ale není přilepený k zákazníkovi, nýbrž k jeho doručovací adrese - jedna firma s dvěma pobočkami může mít dva ceníky. Přepnutí adresy = jiné ceny. | Přiřazení: AlbiLine./admint/pricelists.phpSpráva ceníků samotných. | jádro umíCeník se propisuje do každé ceny, kterou FrontAPI vydá. Ověřit, že bere ceník z adresy, ne ze zákazníka. |
| Ceny bez DPH + doporučená cena | Velkoobchod počítá bez DPH, takže hlavní cena je bez daně. Vedle ní se ukazuje doporučená maloobchodní cena, aby odběratel viděl, za kolik má prodávat dál. | Nikde - „bez DPH" je natvrdo v kódu, doporučená cena přichází z AlbiLine. | částečněCenu bez DPH vydává FrontAPI a má ji i index UpSearch. Frontend ji u produktu zahazuje, umí ji jen v souhrnu košíku. Doporučená cena není ve FrontAPI ani v indexu. |
| Cena objednávky se nepřepočítává | Když se po odeslání objednávky změní ceník, běžný e‑shop by cenu přepočítal. U B2B se to nesmí stát - co bylo objednáno za X, zůstane za X. Ve starém webu je to výslovně vypnuté. | Nikde - natvrdo v kódu. | jen starý webPřenést tu jednu výjimku z obálky. |
| Cost level (cenová hladina produktu) | Každý produkt má z AlbiLine kód „cenové hladiny". A seznam povolených produktů zákazníka je v AlbiLine zadaný právě těmito kódy, ne produkt po produktu. E‑shop pak spáruje: zákazník smí hladiny A a C → vidí všechny produkty s kódem A nebo C.Není to tedy ceník - je to klíč, kterým se otevírá zavřený katalog. | /admint/products.phpPole „Cost level" u produktu, i ve výpisu a filtru. Hodnota přichází z AlbiLine. | má albi.eu ověřenoSloupec i synchronizace jsou v obálce albi.eu. Bez řádku „Zavřený katalog" ale nic nedělá. Význam potvrdí klient (O9). |
| Katalog a množství | |||
| Nákup po baleních | Zboží se prodává po kartonech. Když je v balení 6 kusů a zákazník napíše 8, košík mu to zaokrouhlí na 12 a řekne proč. Velikost balení pro B2B je jiná než pro B2C. | Nikde - velikost balení přichází z AlbiLine. | jádro umíJádro zaokrouhlí a vrátí i varování. Frontend ho dnes nikde neukáže a pole množství nemá krok podle balení - dodělat. |
| Varianty vs. hlavní produkt | Produkt s variantami (třeba tři barvy) se B2B zákazníkovi ukazuje jinak než v e‑shopu - na pěti místech v kódu se chování větví. Přesná pravidla se nepodařilo dočíst. Klient navíc chce varianty ve výpisech sjednotit. | Nikde - natvrdo v kódu. | v jádře bez FrontAPINejdřív dočíst pravidla, pak rozhodnout se sjednocením variant, pak stavět. |
| B2B údaje u produktu | Věci, které maloobchodní zákazník nepotřebuje, ale odběratel ano: alergeny a složení (zákonná povinnost), celní sazebník, rozměry kartonu, soubory ke stažení jen pro přihlášené (bezpečnostní listy, certifikáty), štítky „křehké" nebo „poslední kusy". | /admint/products.php?activeTab=ingredients…/admint/lockedfilestemplates.php/admint/badges.phpRozměry a celní sazebník: AlbiLine. | má albi.euChráněné soubory a manuály obálka albi.eu má. Alergeny, sazebník a rozměry ověřit, chybějící přenést. |
| Checkout · celý B2B košík dnes ve FrontAPI vyhodí chybu (bloker 1) - řádky níž nejdou udělat, dokud se to nevyřeší (O1) | |||
| Vlastní číslo objednávky | Odběratel si napíše do objednávky svoje interní číslo (číslo jeho nákupní objednávky), aby si ji později spároval ve svém účetnictví. | Nikde - pole je natvrdo v kódu. | jen starý web jádroPřidat do dat objednávky a do formuláře. |
| Požadované datum dodání | Odběratel řekne, kdy nejdřív chce zboží - třeba až po inventuře. Datum se kontroluje a jde do AlbiLine. | Nikde - natvrdo v kódu. | jen starý web jádroPřidat do dat objednávky včetně kontroly data. |
| Přepínač doručovací adresy | Zákazník s víc pobočkami (hlavní zákazník a master) si v horní liště zvolí pobočku, pro kterou nakupuje. Tím se změní ceník i to, co smí vidět, protože obojí visí na adrese. Každá pobočka má vlastní košík. V košíku ani v pokladně se adresa NEvybírá. | Nikde - chování je v kódu. | jen starý webJádro bere ceník ze zákazníka, ne z adresy, a hlavní účet si přes FrontAPI pobočku nepřepne. Zadání S02. |
| Přepínatelná povinná pole | Obchodník může zapnout, jestli se v posledním kroku košíku kontrolují údaje zákazníka, nebo ne. Praktické, když data přicházejí z AlbiLine a zákazník je nemá měnit. | /admint/options.php?section=b2bModuleSettings„Validovat data zákazníka ve 3. kroku košíku". | jen starý webPřenést tu volbu a její kontrolu do obálky. |
| Uživatelská zóna (po přihlášení) | |||
| Faktury a počet po splatnosti | Zákazník si stáhne faktury a dodací listy. V menu vidí, kolik faktur má po splatnosti - jemná upomínka při každém přihlášení. | /admint/invoices.phpJen náhled. Splatnost přichází z AlbiLine. | v jádře bez FrontAPIStránku dokladů frontend má. Endpoint FrontAPI ale čte tabulku, kterou ALBI neplní. Nový endpoint nad doklady z AlbiLine + počet po splatnosti ve frontendu. |
| Zásilky | Samostatná sekce s přehledem, co už je na cestě a co ještě ne - u velkých objednávek rozdělených do víc balíků. | Nikde - data z AlbiLine. | v jádře bez FrontAPINový endpoint a sekce ve frontendu. |
| Import objednávky ze souboru | Místo klikání v katalogu zákazník nahraje tabulku „kód produktu, počet kusů" a košík se naplní sám. Velcí odběratelé objednávají stovky položek najednou. | /admint/options.php?section=b2bModuleSettingsUkázkový soubor ke stažení. | v jádře bez FrontAPINový endpoint pro nahrání souboru + obrazovka. |
| Kopie objednávky | Jedno kliknutí zopakuje minulou objednávku - typicky pravidelné doplnění stejného sortimentu. Jen pro hlavní účet. | Nikde - jen tlačítko v uživatelské zóně. | v jádře bez FrontAPINový endpoint + tlačítko. |
| Osobní XML feed | Odběratel s vlastním e‑shopem si nechá posílat sortiment a ceny strojově (XML) - jen to, co smí vidět, za jeho ceny. Adresu feedu má v uživatelské zóně. | /admint/xmlfeeds.phpŠablony feedu (produkty, ceny). | jen starý webVe starém webu je to vlastní kus routeru. Přenést do obálky. |
| Menu podle role účtu | Hlavní účet vidí v uživatelské zóně správu uživatelů, adresy a kopírování objednávek. Podúčet tyhle položky vůbec nemá. | Nikde - v kódu. | jen starý webFrontend rozliší roli. Závisí na řádku „Hlavní účet a podúčty". |
| Provoz a napojení | |||
| B2B část napojení na AlbiLine | To, co dělá B2B B2B: z AlbiLine chodí skupiny zákazníků, povolené produkty, ceníky na adresách, rezervace zboží a objednávky jdou zpět jiným překladačem než u e‑shopu. Běží to automaticky každou chvíli, bez zásahu člověka. | Nikde - běží z cronu, bez obrazovky v adminu./admint/cronmonitor.phpMožná přehled běhů (neověřeno). | má albi.eu ověřenoObálka albi.eu má B2B větve záměrně zachované a vypnuté. Zapnout je a doplnit dvě chybějící závislosti (skupiny zákazníků, sloupce na adresách). |
| B2B e‑mailové šablony | Pět e‑mailů, které běžný e‑shop neposílá: žádost o registraci obchodníkovi a zájemci, změna e‑mailu, žádost o novou adresu, fakturovaná objednávka. Každý česky, slovensky a polsky. | /admint/emailtemplates.phpKteré šablony se použijí: Nastavení → B2B. | jen starý webModul šablon albi.eu má, ale B2B texty ne. Přenést pět šablon × tři jazyky. |
| Web „ví", že je B2B | V databázi má každý web příznak b2c / b2b a podle něj se přepíná desítky míst v kódu - ceny bez DPH, balení, login wall. Bez toho příznaku by web nevěděl, že se má chovat velkoobchodně. | Nikde - mění se přímo v databázi. | jen starý web jádro ověřenoFrontAPI ten příznak nikde nečte ani nevydává. Frontend tedy dnes nemá jak zjistit, že je B2B. Práce v jádře (bloker 3). |
Věci, které dnešní B2B nemá, ale v novém se s nimi počítá. Nepatří do porovnání výš - tady jsou jen vyjmenované, bez odhadů. Tři zdroje: zadání klienta potvrzené vedením, scope dokument (únor 2026) a záložka Inovace v kalkulaci (březen 2026).
Šest bodů z ticketu PBS 121587. Vlevo, co klient chce; vpravo, co to pro projekt znamená a kde se to na stránce odráží.
| Klient chce | Co to znamená pro projekt |
|---|---|
| Co nejnovější technické řešení, aby vydrželo a šlo dál rozvíjet. | Headless architektura (FrontAPI + SFX) - to je předpoklad celé stránky, viz sekce 01. Cena za to: 14 funkcí se musí přenést a 3 blokery v jádře (sekce 05). |
| UX a design nechává na dodavateli, s ohledem na B2C Albi a grafický manuál. Důraz na doplňkový prodej - big data pásy, pásy v košíku, top produkty ve výpisech. | Nové pro B2B. Modul BigData v jádře je, ale podle únorového auditu bez FrontAPI endpointů - pro headless se musí dostavět. Design: vzor oddělení brandingu je hotový v albi.eu (příloha). |
| Pokud možno personalizace doplňkových prvků podle zákazníka. | Nové. Navazuje na předchozí bod a na zavřený katalog - pásy musí respektovat, co zákazník smí vidět. V kalkulaci jako „osobní dashboard" (P1) níže. |
| Zlepšení vyhledávání - UpSearch místo současného. Přijatelné i za cenu, že se obětuje zobrazení ceny podle ceníku zákazníka. | Nové pro B2B (dnes Sphinx). UpSearch jádro umí, SFX ho volá přímo. Klientův ústupek řeší ceny, ne viditelnost - výsledky vyhledávání musí dál respektovat zavřený katalog, jinak zákazník uvidí ve vyhledávání to, co v katalogu ne. K potvrzení s klientem. |
| Varianty produktů sjednotit do hlavních produktů - žádné „tapetování" výpisů variantami, ale zachovat snadný nákup variant. | Změna chování. Dnes B2B zobrazuje varianty jako samostatné produkty (řádek „Varianty vs. hlavní produkt" v sekci 03). Nový výpis ukáže jeden produkt, nákup varianty musí zůstat na jedno kliknutí. |
| Synchronizace s AlbiLine bez dramatických změn - zachovat všechny funkce současného e‑shopu. | Omezení, ne novinka. Splňuje se převzetím modulu AL z albi.eu, který má B2B větve zachované (modré řádky v sekci 03). Zůstává k dořešení: modul skupin zákazníků a B2B sloupce na adresách. |
Priorita 1 = běžné v moderních B2B, doporučeno pro spuštění · 2 = lze odložit · 3 = budoucí rozvoj. V uvozovkách komentář klienta.
Klient v kalkulaci odmítl: uložené nákupní seznamy, přehled zákazníků pro obchodní zástupce („máme jiný systém"), B2B API a EDI („oni si raději domluví EDI a my se přizpůsobíme"), automatické doplňování zásob, AI doporučení („pro B2B nebude funkční"), reaktivační program a health score („ručně").
Skoro všechno z tabulky se dá udělat v obálce ALBI, tedy bez ohledu na ostatní klienty. Tyhle tři ne - jsou v jádře a dotknou se všech klientů. Že patří do jádra, rozhoduje produkt PragueBest. Všechny tři jsou ověřené přímo v kódu.
Když je přihlášený zákazník velkoobchodní a web běží headless, jádro se ani nepokusí objednávku sestavit. V kódu je doslova: „FrontAPI pro B2B zákazníky ještě není hotové."
if ($customer->isB2B() && $isFrontApiEnabled) {
throw new RuntimeException(
'FrontAPI is not yet implemented for B2B customer types.');
}Dokud se to nedodělá, na headless B2B nikdo nic neobjedná. Scope dokument z února tvrdil opak.
Basket/src/models/Basket/BaseNBasket.php:239 (ukázka zkrácená)
Klasické jádro zavřený katalog umí: tabulka povolených produktů, filtr ve výpisu i kontrola v košíku. Řídí se ale doručovací adresou zákazníka a tu FrontAPI nastavuje až při odeslání objednávky. Výpis produktů na headlessu navíc nejde přes jádro, ale přes UpSearch.
Důsledek: jádrový filtr je potřeba zapojit do FrontAPI a výpis v UpSearch zavřít zvlášť (rozdělení prací, řádek Z2). Psát ho znovu není potřeba.
Products/…/BaseCategoryFilteringSqlHelper.php:297-313 · Basket/…/BaseBasketItem.php:271-281
Starý web se na desítkách míst ptá „jsem B2B?" a podle toho se chová. FrontAPI se to neptá ani jednou a příznak ani nevydává frontendu.
Frontend tak nemá jak zjistit, že má schovat DPH, zaokrouhlovat na balení a zamknout stránky.
Presentation/src/model/BasePresentations.php:70
Nová B2B repa v GitLabu existují, ale je to jen založené lešení - nic v nich není nastavené. Není to ani kopie albi.eu, jak se zdálo.
Jedna past pro vývoj. V napojení na AlbiLine (obálka albi.eu) platí: když v konfiguraci chybí přepínač „ladicí režim", bere se jako vypnutý - a synchronizace začne ostře zapisovat do ERP. Nová B2B obálka to musí mít nastavené dřív, než se synchronizace poprvé spustí. Druhá past: import z AlbiLine při každém běhu maže produkty, které z AlbiLine nevznikly.
Očíslovaná, aby se na ně dalo odkazovat, a seskupená podle toho, kdo je má rozhodnout. První dvě blokují nacenění.
| ID | Otevřený bod | Kdo rozhoduje |
|---|---|---|
| Blokují nacenění - rozhoduje produkt PragueBest | ||
| O1 blokuje | B2B košík ve FrontAPI - kdo ho dodělá a kde: v jádře pro všechny klienty, nebo výjimkou v obálce ALBI? | Produkt PragueBest · návrh: jádro |
| O2 blokuje | Zavřený katalog - filtr do jádra, nebo do obálky? Stejná otázka jako O1. | Produkt PragueBest · návrh: jádro |
| Potřebujeme od klienta | ||
| O9 | Cost level - v kódu je to kód cenové hladiny, kterým se otevírá zavřený katalog. Chce ho klient i zobrazovat, nebo má jen řídit viditelnost? | Klient |
| O16 | Zdrojem pravdy pro B2B pravidla je dnes AlbiLine, ne administrace e‑shopu. Má to tak zůstat i na novém B2B? Rozhoduje, jestli se vůbec stavět admin obrazovky. | Klient |
| O14 nové | „Zákaznické podněty" - ve scope jako požadavek, ve starém webu neexistuje (sekce Co má přibýt nového). Co tím klient myslí? | Klient |
| O8 | Předobjednávky - ve starém B2B vypnuté, ve scope s odhadem. Plánuje se předprodej? | Klient |
| O10 | Moduly zapnuté v databázi, ale schované v šablonách (slevy na kartu, recenze, diskuze, kupóny) - záměr, nebo pozůstatek? | Klient |
| Rozhodne vývoj PragueBest | ||
| O3 | Vzor pro B2B frontend - Harfasport (bližší rozsahem), nebo albi.eu (sdílí branding)? | Vývoj SFX |
| O5 | Kdo a kdy založí kostru v prázdném repu albi-b2b-sfx? | Vývoj SFX |
| O12 | Starý web má kaskádu šablon B2B → B2C. Potřebuje nový frontend něco podobného? | Vývoj SFX |
| O6 | Pročistit lešení albi-b2b-backend (název balíčku, cizí dokumentace) a rozhodnout, co z albi.eu se převezme jako základ. | Vývoj BE |
| O15 nové | Stav objednávky „fakturováno" - v kódu starého webu není (sekce Co má přibýt nového). Existuje v ostré databázi B2B, nebo je to nový požadavek? | Vývoj BE |
| O11 | Moduly bez B2B šablon (Lookbook, sídla firmy, kontaktní formulář, náhradní díly, affiliate) - ověřit na běžícím B2B, jestli se používají. | PB |
| O7 | Doklonovat zbývající repa - cron repa, vlastní kopie storefront-x. | Produkťák + vývoj |
| Uzavřeno | ||
| Rozsah nového B2B. Rozhodnuto 7. 9. (PBS 121587): čtyři samostatné e‑shopy CZ, SK, PL a nový EN. PIM / CPD je mimo rozsah B2B. | — | |
| Co ze sdílených částí už řeší albi.eu: napojení na AlbiLine ano (i s B2B větvemi), notifikace ano, e‑mailové šablony jen modul, XML feedy ne. | — | |
Struktura ve workspace - samostatný projekt projects/albi-b2b/. | — | |
Technické podklady k sekcím výš. Rozbal, co potřebuješ.
Administrace běží na https://{doména}/admint/{modul}.php. Doména není v kódu (bere se z databáze), proto jsou odkazy na stránce jen relativní. Tvary:
Výpis modulu: /admint/{modul}.php
Editace: /admint/{modul}.php?{modul}_action=edit&{modul}_id={id}
Konkrétní tab: /admint/{modul}.php?activeTab={tab}&{modul}_action=edit&{modul}_id={id}#{tab}
Nastavení: /admint/options.php?section={sekce}Názvy položek v menu adminu jsou v databázi, ne v kódu - před předáním klientovi je nutné je ověřit v ostrém adminu. Kompletní tabulka 33 funkcí s důkazy v kódu: knowledge/b2b-administrace-cesty.md.
| Oblast | B2C - albi.cz | B2B - b2b.albi.cz |
|---|---|---|
| Přístup | Otevřený e‑shop. | Login wall - nepřihlášený nevidí nic. |
| Katalog | Vidí všichni všechno. | Zavřeno, otevírá se adresou a povoleným seznamem z AlbiLine. |
| Registrace | Sám si založí účet. | Žádost, účet zakládá obchodník. |
| Ceny | S DPH, akce a slevy. | Bez DPH, ceník na adrese, doporučená cena vedle, bez přepočtu. |
| Množství | Po kusech. | Po baleních. |
| Checkout | Standardní kroky. | + interní číslo objednávky, požadované datum dodání. Doručovací adresa jen ke čtení, pobočka se volí předem v horní liště. |
| Doprava a platby | Podle košíku. | Filtrované podle adresy a skupiny. |
| Uživatelská zóna | Objednávky, adresy, nastavení. | + faktury, zásilky, import, kopie, podúčty, XML feed. |
| Účty | Jeden zákazník = jeden účet. | Hlavní účet + podúčty, příznak špatný plátce. |
| ERP | AlbiLine sync. | Tentýž sync + skupiny, povolené produkty, B2B překladač objednávek. |
Rozdíl B2B / B2C není vlastnost obálky ALBI, ale jádra MasterShopu. Jedno repo, jedna větev, dva servery.
presentation_type = b2b, jádrová metoda isB2BPresentationId(). Druhá varianta isCustomerTypeB2B() rozlišuje podle zákazníka.app/Modules/Presentation/src/model/BasePresentations.php:70b2b-cz/sk/pl proti production-cz/sk/pl. B2B má vlastní databázi, vyhledávací indexy, číselnou řadu objednávek a klíč shopType => 'B2B' v napojení na AlbiLine.configs/b2b-cz.config.phpcz-b2b → jádro cz-b2b → jádro cz-b2c. 95 šablon B2B proti 374 B2C.Local/Modules/Routing/src/models/Router.php:104-118gulp.config.b2b.js a gulp.config.b2c.js - jiné zdroje, jiné ikony.Vypnuté v databázi: množstevní slevy · mega menu · Web Page Builder · Instagram feed · předobjednávky (ale ve scope s odhadem - O8) · externí videa · licence · úrovně dopravy.
Zapnuté, ale v šablonách schované (O10): slevy na kartu CKM SYTS · zákaznické recenze · diskuze · slevové kupóny (vstup v košíku zakomentovaný).
Zapnuté bez B2B šablon - ověřit na běžícím webu (O11): Lookbook · sídla firmy · kontaktní formulář · náhradní díly · affiliate tracking.
Potvrzeně používané: akce a promoakce · dárky · newsletter · měření a e‑commerce tracking · GDPR dokumenty · výdejní místa · sledovací kódy zásilek.
Zdroj: audit databázového příznaku modulů a B2B šablon, únor 2026.
Z 94 modulů starého webu jich 79 jen upravuje jádro. Těchto 15 se muselo, nebo bude muset, přenést celých. Čtyři z nich už albi.eu přeneslo.
| Modul | Co dělá | Stav |
|---|---|---|
| AL | Napojení na AlbiLine, 105 souborů. | v albi.eu vč. B2B větví |
| AlbiNotificator | Notifikace vč. žádostí o registraci. | v albi.eu |
| LockedFilesTemplates, ManualsArchive, SparePartsForm | Chráněné soubory, manuály, náhradní díly. | v albi.eu |
| CustomersWhitelistGroups | Skupiny zákazníků. | jen starý web jen B2B |
| AlbiLine | Starší vrstva napojení. | nepřenášet nahradil ho AL |
| Migration | Datová migrace, překladač B2B dokumentů. | posoudit |
| SupportBox, KvidoFiles, ImageImport, TrackingCodes, TrackingPixel | Podpora, soubory Kvido, import obrázků, tracking. | bez B2B větvení |
| CompanyHeadquarters | Sídla firmy. | ověřit použití |
| CeneoTrustedReviews | Recenze Ceneo (PL). | jen B2C |
Backend albi.eu je stejná větev jádra jako B2B. Není to web pro EN a IT, jak se zdálo, ale jeden „rodičovský" EU web s 17 dětskými trhy podle měny; Itálie je sesterský projekt. Má 41 modulů a aktivně se vyvíjí (35 změn databáze za srpen 2026). Rozpracované: přebírání obsahu mezi trhy, provizorní trh DE, košík projde jen s testovacími daty.
Hotový vzor rozšíření FrontAPI: pět vlastních endpointů (manuály, náhradní díly, chráněné soubory), úprava dat vydávaných jádrem bez zásahu do jádra. Jedna nástraha: každý nový endpoint se musí zaregistrovat v seznamu tagů, jinak tiše zmizí i z dokumentace.
Frontend albi.eu je tenká nadstavba (404 souborů proti 1012 u Harfasportu). Přímo použitelné: oddělený branding, mapování vzhledu ze starého webu, validace IČO a DIČ. Nic pro B2B (login wall, skupiny, pole košíku) tam není - jako vzor rozsahu je vhodnější Harfasport (O3).
Detail: knowledge/albi-international-backend.md, knowledge/albi-headless-sfx.md.