Přihlášený zákazník uvidí na úvodní stránce, co ho zajímá: faktury po splatnosti, zásilky na cestě, poslední objednávku, produkty, které objednává pravidelně, naposledy zobrazené a novinky ve svém sortimentu. Každý blok je samostatný dotaz. Skládá se z jiných funkcí, sama o sobě přidává tři endpointy.
B2B web je celý za přihlášením, takže homepage jako u B2C nemá smysl. Nástěnka odpovídá na otázky, se kterými odběratel přichází: dlužím něco, kde je zboží, co jsem objednával, co mám doobjednat. Stará B2B nástěnka ukazuje jen počty objednávek, zásilek a faktur.
Kam patří. Obálka: tři endpointy nástěnky v obálce backendu, nástěnka ze sedmi bloků v obálce SFX. Co nástěnka ukazuje, je per klient, proto jádro NE. Rozhodl produkt PragueBest. Jádro: doklady a zásilky (D1, D2 v rozdělení prací) a bloky z F01, F05, F06 se použijí tak, jak jsou.
K1 mění rozsah bloku doporučení, ostatní neblokují. Blok se dá dodat později, nástěnka bez něj funguje.
| # | Otázka a náš návrh |
|---|---|
| K1 | Doporučení z BigData v B2B: mikroslužba umí doporučit jen podle produktu nebo kategorie, ne podle zákazníka. Kalkulace má položku BigData v tvorbě e‑shopu. Návrh pro fázi 1: na nástěnce blok „Novinky ve vašem sortimentu" bez BigData, pásy BigData jen na detailu produktu a v košíku jako u B2C. Chce ALBI investovat do úpravy mikroslužby, aby uměla „pro vás"? (P3) |
| K2 | Blok „Objednáváte pravidelně": z jakého období počítat? Návrh: posledních 12 měsíců, řazeno podle počtu objednávek, ve kterých produkt byl, max. 8 produktů. |
| K3 | Faktury po splatnosti vidí i podúčet? Dnes je vidí celý uzel firmy. Návrh: počet ano (může blokovat objednávání), detail jen hlavní účet. |
| # | Otázka |
|---|---|
| D1 | Faktury: FrontAPI endpoint dokumentů čte tabulku documents, kterou u ALBI nikdo neplní. Splatnost a stav jsou v orders_documents ze synchronizace AlbiLine. Navrhujeme nový endpoint nad orders_documents, ne most do documents. Souhlas? |
| D2 | Seznam objednávek ve FrontAPI nemá parametr řazení. Pro „poslední objednávku" je potřeba ověřit výchozí pořadí, nebo přidat sort. |
| D3 | „Objednáváte pravidelně" agreguje položky objednávek uzlu za 12 měsíců. U velkých odběratelů jsou to tisíce řádků. Počítat na dotaz s cache, nebo denně do pomocné tabulky? |
| D4 | Souhrnný endpoint s počty volá čtyři dotazy. Stačí jeden endpoint, nebo raději čtyři malé, ať se blok nezdrží? Navrhujeme jeden pro počty, samostatné pro seznamy. |
/ po přihlášení vede sem. Nepřihlášený na ní NIKDY není, vidí přihlášení.orders_documents. Vše ostatní existuje.Pořadí shora dolů. Sloupec Zdroj říká, odkud data přijdou a co se pro to musí postavit.
| # | Blok | Co ukazuje | Zdroj dat | Stav |
|---|---|---|---|---|
| 1 | Hlavička účtu | Oslovení, firma, aktivní doručovací adresa, název ceníku, role (hlavní účet / podúčet). | GET /api-users/users/auth + adresy. Role a uzel firmy dnes FrontAPI nevydává → do souhrnu (blok 2). | rozšířit |
| 2 | Tři čísla | Faktury po splatnosti (počet, s částkou), zásilky na cestě (počet), poslední objednávka (číslo, částka, datum). | Nový GET /api-b2b/dashboard/summary nad orders_documents a orders. | nový |
| 3 | Upozornění na účtu | Pruh, když je účet v AlbiLine označený jako špatný plátce nebo blokovaný. Text: objednávat nejde, ozvěte se zástupci. | Příznaky uzlu ze synchronizace (is_bad_payer, is_blocked) → součást souhrnu. | v souhrnu |
| 4 | Objednáváte pravidelně | Až 8 produktů, které se nejčastěji opakují v objednávkách za 12 měsíců, s posledním objednaným množstvím. Tlačítko „Doobjednat vše" naplní košík. | Nový GET /api-b2b/frequently-ordered. Naplnění košíku přes endpoint z F01 s tělem items[]. | nový |
| 5 | Naposledy zobrazené | Až 8 karet. | F05, existující endpoint. | existuje |
| 6 | Oblíbené | Až 4 karty + odkaz na celý seznam a na sledované kategorie. | F06, nový endpoint tam. | F06 |
| 7 | Novinky ve vašem sortimentu | Až 8 produktů z povoleného sortimentu zákazníka, seřazených od nejnovějšího. | Existující výpis produktů s řazením podle data přidání. Zavřený katalog aplikuje jádro. | existuje |
Co záměrně chybí: pásy BigData („mohlo by se vám líbit", „trendy"). Mikroslužba vrací produkty podle produktu nebo kategorie, ne podle zákazníka, a obálka albi.eu na ni není napojená. Na nástěnce by pás ukazoval totéž všem. Doporučení na detailu produktu a v košíku jsou samostatná položka kalkulace, ne tato funkce.
items[]. Výsledkové okno je stejné jako u F01.Nesahat na homepage SFX jádra ani albi.eu. B2B obálka SFX přepíše šablonu Homepage vlastní nástěnkou. Anonymní homepage v B2B neexistuje.
Obálka SFX přepíše šablonu Homepage. Rozvržení podle prototypu, obrazovka Nástěnka. Design system ALBI.
| Blok | Načítání | Prázdný |
|---|---|---|
| Tři čísla | Kostra tří karet | Nuly. Karta poslední objednávky: „Zatím žádná objednávka" s odkazem do katalogu. |
| Objednáváte pravidelně | Kostra karet | Blok se nevykreslí. Nový zákazník ho uvidí až po prvních objednávkách. |
| Naposledy zobrazené | Kostra karet | Věta „Zatím nic. Otevřete si detail produktu v katalogu." |
| Oblíbené | Kostra karet | Věta „Srdíčkem u produktu si ho uložíte." s odkazem do katalogu. |
| Novinky ve vašem sortimentu | Kostra karet | Blok se nevykreslí. |
Nové je vše kromě produktových karet a navigace. Podúčet vidí totéž bez odkazu Faktury a s objednávkami jen na své adresy.
Nové endpointy vznikají v obálce backendu ve skupině /api-b2b/, vzor obálka albi.eu (#[AsRoute], vlastní DTO, registrace tagu). Všechny vyžadují JWT zákazníka a respektují viditelnost objednávek podle uzlu a adres.
| Endpoint | Stav | K čemu |
|---|---|---|
GET /api-b2b/dashboard/summary | nový | Jeden dotaz pro hlavičku a tři čísla. Viz příklad níže. D4 |
GET /api-b2b/frequently-ordered?months=12&limit=8 | nový | Produkty z objednávek zákazníka (uzel, nebo adresy podúčtu) za období, seřazené podle počtu objednávek s produktem. Vrací produktové karty + lastCount, lastOrderedAt, ordersCount. Jen produkty aktuálně viditelné a prodejné. D3 |
GET /api-b2b/documents?type=invoice&state=overdue | nový | Faktury a zásilky nad orders_documents ze synchronizace AlbiLine: documentCode, type, state, dueDate, totalWithoutVat, unpaidAmount, carrierCode, shippedDate, order {code, hash}. Filtr type (invoice, consignment), state. Používá i sekce Faktury a Zásilky. D1 |
POST /api-carts/carts/{cartToken}/reorder | F01 | S tělem { "items": [ { "productId", "count" } ] } místo orderHash. Stejná odpověď. Definice v F01. |
GET /api-users/users/auth | existuje | Jméno, e‑mail, ceník. Nevrací roli ani uzel, proto je role v souhrnu. |
GET /api-orders/orders/{userId}?perPage=1 | existuje | Poslední objednávka, pokud je výchozí řazení od nejnovější. D2 Jinak ji vrátí souhrn. |
GET /api-recently-viewed/products | existuje | Blok 5, viz F05. |
GET /api-products/… výpis s řazením od nejnovějšího | existuje | Blok 7. Zavřený katalog aplikuje jádro. Parametr řazení podle data přidání ověřit ve výpisu produktů. |
GET /api-b2b/dashboard/summary
{
"account": { "isMaster": true, "nodeId": 4821, "isBadPayer": false, "isBlocked": false,
"deliveryAddress": { "id": 12, "label": "Lípová 12, Praha 2", "priceListLabel": "Velkoobchod B" } },
"invoicesOverdue": { "count": 1, "unpaidAmount": 4820, "currencyCode": "CZK", "oldestDueDate": "2026-09-17" },
"consignmentsOnTheWay": { "count": 2 },
"lastOrder": { "code": "2026-1013", "hash": "a91f…", "totalWithoutVat": 7783, "currencyCode": "CZK", "createdAt": "2026-09-23T14:02:00+02:00" },
"favouritesCount": 3
}UnsettledOverDue. Stejné pravidlo jako starý B2B, ne výpočet z data splatnosti.Nic nepřibývá. Bloky nejsou konfigurovatelné, pořadí a počty jsou v kódu SFX. Klient o nastavení nežádal.