02 — Követelmények

Származtatott dokumentum — a docs/discovery/ anyagból. Frissítsd a requirement-handling skill-lel, ne kézzel a forrásokból.

Források: 02-tender-v1.0.hu, 00-annex-b-architecture-v1.0.hu, 01-annex-c-response-pricing-v1.0.hu, 04-annex-c-response-pricing-v1.1.hu, 05-beforg-feed-fields, 07-butlers-tender-answers-hu, 08-loyalty-api-trimmed, 09-loyalty-clarification

Funkcionális követelmények

1. rész — E-kereskedelmi fulfillment

• FF-01 Áruátvétel (inbound): heti beszállítás fogadása a Butlers Germany-től (vegyes raklapok/kartonok; ~30 raklap/hó). A Beforg beszállításonként egy JSON-fájlt ad át (szállítmány-hivatkozás, tételek mennyiséggel és egységnyi beszerzési árral) a szállítólevél beárazásakor, a fizikai beérkezés előtt 2–3 nappal; a mennyiség tájékoztató jellegű, a fulfillment-oldal a bevételezéskor megerősíti vagy módosítja, törlés nincs; a bevételezés ezekkel szemben kerül visszaigazolásra, a platform a számolt mennyiséget a tétel egységköltségén könyveli. (Válaszlevél: G-02, L2-15)
• FF-02 Raktározás: ~22 000–31 000 darab készleten (szezonális); méretosztályok: XS 41% / S 39% / M 17% / L–XXL ~2,6%; erősen long-tail szortiment kisbútorral és törékeny áruval (üveg, kerámia).
• FF-03 Komissiózás és csomagolás: ~34 000 csomag/év HU/CZ/SK piacokon; erős Q4 csúcs (december = az átlagos hónap 3,4-szerese).
• FF-04 Futárátadás és kiszállítás: az ajánlattevő saját futárszerződéseivel; csomag + terjedelmes/bútor kiszállítás. Elvárt lefedettség: házhozszállítás + csomagautomata/átvevőpont-hálózatok mindhárom piacon.
• FF-05 Terjedelmes és túlméretes áru: alapkövetelmény, nem szélsőséges eset. Max ~80 kg / 200 cm. Újracsomagolási modell szükséges (egyes termékek, pl. székek, a gyárból párosával vagy szállításra alkalmas csomagolás nélkül érkeznek).
• FF-06 Törékeny áru: üveg, kerámia, porcelán — a szortiment jelentős hányada. Cél: törés <1%.
• FF-07 Utánvét-kezelés: HUF, CZK, EUR beszedés és átutalás.
• FF-08 Visszáru-feldolgozás: ellenőrzés, visszakészletezés/leírás, riportolás.
• FF-09 Bolti átvételi gyűjtőcsomagok: konszolidált csomagok 4 budapesti üzletbe + átvételi pontok Prágában (3) és Pozsonyban (1) — alacsony volumen (~40 rendelés/hó összesen). Jelenleg a fulfillment-partner állítja össze a gyűjtőcsomagokat, de ez nem skálázható és nem elég megbízható; minden ajánlattevő saját, beárazott megoldást javasol (lásd 07-questions.md → REQ-16). (Válaszlevél: L2-23)
• FF-10 Értéknövelt szolgáltatások: díszcsomagolás / csomagbetétek (szezonális); elfekvő készlet selejtezésének/kiárusításának támogatása.
• FF-11 Rendszerintegráció: rendelésfogadás, státusz-visszajelzés és készletriport API-n keresztül. Éles webshop-platform konnektorok megjelölése elvárt (Shopify, UNAS, egyéb).
• FF-12 Készletpontosság és leltár: az ajánlattevőnek be kell mutatnia a leltározási módszertant. Jelenlegi referenciaérték: közel nulla eltérés az éves leltárban.
• FF-13 SLA — futárátadás D+2-n belül: a rendelés átvételétől számított 2 munkanapon belül.
• FF-14 Q4 csúcskapacitás: december ≈ az éves árbevétel 25%-a, Q4 ≈ 40%+. Igazolni kell, hogy a Q4-et az SLA romlása nélkül tudják kiszolgálni.
• FF-15 Biztosítás és felelősség: felelősségi modell és biztosítási fedezet a raktári készletre és az úton lévő árura.
• FF-16 Átállás: nem zavarhatja a Q4-es értékesítést; a ~2027. január 15-i időpont a fejlesztés tényleges kezdete, nem az éles átállásé (lásd NF-08).
• FF-17 Adathozzáférés: bármely és minden adat, API + export, bármikor és megszűnéskor, külön díj nélkül.
• FF-18 Garantált szezonális kapacitás: a szezonban (október 15. – december 15.) garantált kapacitás, hibátlan és gyors szolgáltatás: beszállítás és 2 napos bevételezés a szezonban is. A múltbeli problémás pontok: bútorszállítás, szezon alatti szolgáltatási minőség, előre egyeztetett kapacitásbővítés. (L1-01)
• FF-19 Készletre vétel: a heti németországi szállítmányok a beérkezést követő 2 munkanapon belül eladható készletként jelenjenek meg. (L1-03)
• FF-20 Méret- és súlyadat rögzítése: az első bevételezéskor mért méret- és súlyadat cikkszámonként rögzítendő, API-n/exporton folyamatosan elérhető, a szerződés teljes ideje alatt megőrzendő és kilépéskor átadandó; ez a méretosztály-viták alapja. (L1-13)
• FF-21 Futárreklamációk kezelése: az elveszett, sérült, késett csomag kivizsgálása és a kárigény érvényesítése a fulfillment-szolgáltató feladata (nála vannak a futárszerződések); a státusz- és bizonyítékadatokat (átadás, csomagsúly, kézbesítési igazolás, fotó) a Társaság számára elérhetővé kell tenni. A vevő felé a kommunikációt a Társaság webshop-csapata végzi. (L1-02)
• FF-22 Rendelés-teljesítés igazolása: rendelésenként visszakereshető igazolás: tételes vonalkód-szkennelés csomagoláskor, csomagsúly-ellenőrzés, csomagoló azonosítója és időbélyeg; fotódokumentáció opció; az adatok API-n/exporton elérhetők. (L1-09)
• FF-23 Futármix: nem elvárás a jelenlegi futármix teljes lefedése; elvárás egy egészséges mix (nagy és kisebb futárok, csomagátvételi pontok) mindhárom országban; az élő futár-integrációk piaconkénti felsorolása és a futárváltás átfutási ideje. (L1-07)
• FF-24 Support-vállalás (1. rész): a szállítást akadályozó ügyben (hibás/hiányzó rendelés, blokkolt csomag) munkanapon belüli reakció; egyéb megkeresésre legkésőbb a következő munkanapon érdemi válasz. (L1-10)
• FF-25 Díjtranszparencia: a csomagolóanyag-költség a C.3 szerinti egységáron, tételesen ellenőrizhetően jelenik meg a havi elszámolásban (nem elvárás a rendelésenkénti vonalkódos nyomon követés); új cikkszám felvételéért külön, átlátható egységár-sor számítható fel (évente ~1 500–2 500 új cikkszám); rejtett vagy utólag bevezetett díj nem fogadható el; a díjmentes elemeket feltételeikkel jelezni kell. Alternatív tárolási modell (m², polcfolyóméter) külön lapon adható, de a C.3/C.5 kitöltése kötelező. (L1-04, L1-05, L1-08, L1-11)
• FF-26 Utánvét-elszámolás: a futárok a fulfillment-szolgáltató szerződései alapján szedik be az utánvétet, rendeléshivatkozásokkal ellátott kimutatással utalják át; heti, géppel olvasható kimutatás (CSV/XLSX vagy API) várt, amelyet a platform automatikusan párosít a rendelésekhez, a nem párosítható tételeket a pénzügynek megjelöli. (L2-22)
• FF-27 Nyitókészlet az átálláskor: teljes fizikai leltár az 1. rész szolgáltatója által, nyitóegyenlegként importálva; az úton lévő áru és a visszaúton lévő visszáru külön listázva; az átállás a jelenlegi fulfillment-partner együttműködésével történik. (L2-20)

2. rész — Webáruház-platform és szolgáltatások

• WP-01 Platform: határozott preferencia elterjedt, széles körben támogatott kereskedelmi platformra (pl. Shopify vagy UNAS). Más platformra épülő ajánlat is befogadható, ha a lock-in aggályokat kezeli. A nyílt forráskódú, a Társaság tulajdonába kerülő platform nincs kizárva; a lock-in értékelésnél az ajánlattevőtől való függés számít (egyedi fejlesztések dokumentáltsága, más szállító általi átvehetőség, hosting és üzemeltetés átadhatósága). Kétlépcsős szállítás (tervezés → kivitelezés) módszertanként elfogadható, de a kivitelezésre is kötelező ár vagy felső korláttal rendelkező ársáv szükséges, és a döntés a teljes scope-ra születik. A platformlicenc a TCO-ban továbbszámlázott áron szerepel (a gyártói listaár tájékoztatásul). (L2-01, L2-02, L2-04)
• WP-02 Migráció: ~5 000 aktív cikkszám (történeti katalógus- és rendeléstörténet-migráció nincs); vevői fiókok; URL/SEO-megőrzés; három lokalizált piaci shop (HU/CZ/SK, három deviza). CZ/SK tartalom elosztott csapattal, szerepkör-alapú hozzáféréssel. Migrálandó: ~55 000 regisztrált vevői fiók, 100 alatti tartalmi oldal, az aktív katalógus (~5 000 cikk) képekkel és kategóriákkal, aktív kuponkódok (az online ajándékkupon-egyenlegekkel együtt), valamint a SEO-szempontból fontos URL-ek átirányítási térképe; a rendeléstörténet migrációja nem elvárás (archiválás). A jelenlegi szolgáltató az átadásban együttműködik (API, teljes XML-export, kupon-export, jelszó-hash-ek az algoritmussal, átirányítási lista), de migrációs projektvezetést nem vállal — ez az ajánlattevő feladata. A kezdeti export utáni változásokat az átálláskor megismételt, végleges export kezeli; az átálláskor nyitott rendeléseket a jelenlegi rendszer zárja le, az új platform új rendelésekkel indul, a korábbi rendelések visszáruját/visszatérítését kifutási időszakban a régi rendszerben kezelik. Elsődlegesen a jelszó-visszaállítás nélküli fiókátvétel vizsgálandó; ha a célplatform a hash-algoritmust nem fogadja, a jelszó-újraállítás elfogadható. (L2-29, L2-30)
• WP-03 Design és korszerűsítés (facelift): strukturált design-átvilágítás és korszerűsítés a bevezetés részeként. Shopify-ajánlatnál: a butlers.com Shopify sablonja rendelkezésre áll.
• WP-04 NAV-számlázás: NAV-kompatibilis számla-kiállítás (Online Számla adatszolgáltatás); pl. szamlazz.hu vagy Billingo integrációval. A platform állítja ki a számlákat — a fulfillment-szolgáltatónak nincs számlázási feladata.
• WP-05 Termékfeed-fogadás: kizárólag a Társaság termékadat-hubjából (Beforg), JSON formátumban, beszállításonként egy fájlban (beszállítás-fejléc + teljes cikkrekord a saját beszállítási tétellel); a német feedet a platform semmilyen formában nem dolgozza fel (ez felváltja a „B" melléklet B.2 2. pontjának kétforrású modelljét). Tartalom: cikkszám (18 jegyű kanonikus forma, elsődleges kulcs; 8 jegyű ERP-cikkszám a meglévő cikkeknél), EAN, magyar és német nevek, német leírás (ahol létezik), webes variánscsoport, kategória/taxonómia, attribútumok, méretek, súly és csomagolási egységek, származás és vámtarifaszám, magyar fogyasztói ár, áfa, nettó beszerzési ár (HUF), státusz, képek. Nem része a feednek: készlet (a platform készletkönyve a forrás), akciós árak (a marketing állítja be a platformon), HU/CZ/SK leírások (a Társaság csapatai a platformon tartják karban; a német forrásszöveget a feed szállítja). Átvitel (pull/push) és gyakoriság a szerződéskötéskor rögzítendő; a Beforg-oldali fejlesztést a Társaság végzi. (05-beforg-feed-fields; G-02, L2-12–16; lásd 07-questions.md → REQ-08)
• WP-06 Fulfillment-konnektor: rendelés-átadás, státusz-visszajelzés, készletfrissítések — lehetőleg bizonyított konnektor, ennek híján dokumentált API.
• WP-07 Fizetés és utánvét: fizetési szolgáltatók integrációja az utánvétes folyamatokkal együtt.
• WP-08 E-mail marketing (Mailchimp): teljes integráció — közönség-szinkron, e-kereskedelmi események, kosárelhagyási folyamatok, szegmentációs adatok. Tranzakciós/rendszerüzeneteket a platformnak kell kezelnie. Feliratkozók ma: ~40 000 (HU), ~27 000 (CZ), ~4 000 (SK); a Mailchimp funkcióinak ma csak kis részét használják, de bővíteni kívánják. A teljes integráció arra az esetre elvárás, ha a Társaság a Mailchimp megtartása mellett dönt; az ajánlattevő saját e-mail-marketing megoldása külön árazva bemutatható. A SALESmanago nem aktív, kivezethető — a feliratkozás- és pop-up-funkciót a platform marketing-eszközei váltják ki. (L2-36)
• WP-09 Analitika: GA4 e-kereskedelmi mérés, hozzájárulás-kezelés (consent management), viselkedéselemző eszközök (hőtérképek / session-elemzés). A GA4-property és a Google Ads / Meta fiókok léteznek, ezeket kell bekötni; a jelenlegi beállítás nem tartalmaz e-commerce szintű mérést, ezt a platformnak az első naptól biztosítania kell. Platform-natív consent-banner elfogadható, ha támogatja a Google Consent Mode v2-t, a piaconkénti nyelveket és a részletes consent-naplózást; dedikált CMP opcióként javasolható; viselkedéselemzésre a Microsoft Clarity elfogadható. (L2-38)
• WP-10 Számvitel és COGS: cikkszám-szintű beszerzési ár tárolása (Beforg feedből); havi könyvelési zárást kiszolgáló riportok/exportok: értékesítés ELÁBÉ-val és árréssel (termék és szolgáltatás/szállítás elkülönítve); bevételezések; készletmozgások; selejtezés; hó végi készletérték beszerzési áron. Piaconkénti bontás (HU/CZ/SK) és összesítve is kötelező.
• WP-11 Marketplace-kapcsolatok: Jelenleg nincs élő marketplace-csatorna; mindhárom (eMAG, Temu, Allegro) új csatorna. Az eMAG-csatlakozás képessége elvárás és árazandó (C.4, 7. sor), de nem az induláshoz kell (az 1. évre opciós sorként a TCO-ban); az Allegro (hu/cz/sk oldal) és a Temu (három ország) a stabil indulás után következik, marketplace-enként az út és az ár megadásával. Natív platform-integráció előnyben (ma BaseLinker fut feed-alapon, ez lecserélhető); middleware elfogadható. A készlet közel valós időben frissítendő; az adatkapcsolat (termék-, ár-, készletszinkron, rendelés-beolvasás) és az induló feltöltés/kategória-megfeleltetés technikai támogatása az ajánlattevő feladata; egyes marketplace-eknél (pl. Allegro) a vevői számlát a platformnak kell kiállítania. Az árazást, listázást és elérhetőség-kezelést a Társaság webshop-csapata végzi a seller centerben; a csomagolás és kiszállítás a fulfillment-partner feladata (a bolti készletből működő csatornák, pl. Wolt, scope-on kívül). Piacok a márkalicenc alapján HU/CZ/SK-ra korlátozottak. (L2-33–35, G-05; lásd 07-questions.md → REQ-12, REQ-15)
• WP-12 Ajándékkártyák és kuponok: e-mailes ajándékutalványok és promóciós/születésnapi kuponkampányok mindhárom piacon (három devizában). Folytonossági terv szükséges a már eladott ajándékkártyákra (egyenlegek, kódok, deviza, áfa/NAV-kezelés). A válaszlevél szerint: a fizikai ajándékkártyák csak a boltokban vásárolhatók/válthatók be (online nem, ez nem változik); online ajándékkuponok léteznek (5 000 / 10 000 / 15 000 / 20 000 HUF, összesen ~15 M HUF kint lévő érték; SK oldalon ~2 000 EUR; cseh kupon nincs), kód alapúak, csak online válthatók be. Ma egy rendelésben egy kupon használható fel egy összegben, más kuponnal nem kombinálható — az új platformon a részleges beváltás, több kupon együttes felhasználása és a promóciós kuponokkal való kombinálhatóság elvárás. Az online kuponok értékesítéskor, áfa nélkül könyvelendők (az áfa a beváltáskor keletkezik). Születésnapi kupon: automatikusan kiküldött, névre szóló, egyszer használatos. Élő promóció az átálláskor nem lesz; az elérhető promóciós mechanizmusokat az ajánlatban részletezni kell. (L2-31; a „három piac" állítással való eltérés: lásd 07-questions.md → REQ-14)
• WP-13 Marketing-önkiszolgálás: bannerek, popupok, CTA-k, promóciós landing oldalak, visszaszámlálók, termékcímkék (badge), merchandising, A/B-tesztelés, e-mail-cím gyűjtés — fejlesztői közreműködés nélkül, a házon belüli marketingcsapat által kezelve. Élő demó elvárás a shortlist-körben.
• WP-14 Oldalon belüli keresés: natív vagy app-alapú; magyar nyelvi sajátosságok kezelése (ékezetek, szinonimák, elütés-tűrés); találatok hangolása és merchandising. Szinonima- vagy problémás-kifejezés-lista ma nincs, a keresések száma nem mért (a jelenlegi analitika a keresési paramétert nem rögzíti) — a keresési analitika (volumen, leggyakoribb és találat nélküli kifejezések) a mérési alap része, a szinonimalistát a webshop-csapat tartja karban a platform keresőeszközeiben. (L2-39)
• WP-15 Mobil-megközelítés: alapelvárás a kiváló reszponzív áruház; ezen felül PWA / wrapper-app / natív opciók bemutatása indikatív költségekkel. Kiemelten érdekes a push-értesítési képesség: főként promóciókra, érdeklődésre számot tartó lehetőség, nem kötelező követelmény. A mobil-megközelítés ajánlott megoldását a C.4 12. sorában kell beárazni; az éles indulásnak nem feltétele. (L2-45, G-05)
• WP-16 Front-end minőség: szemantikus HTML, strukturált adatok (schema.org Product, Offer, Breadcrumb, Organization), Core Web Vitals, akadálymentesség, AI/SEO-olvashatóság (szerveroldalon renderelt terméktartalom, tiszta crawlolhatóság).
• WP-17 Folyamatos szolgáltatás: hoszting/SaaS-adminisztráció, support vállalt reakcióidőkkel, fejlesztési retainer, admin-képzés (3 fő). Rendelésstátusz- és követési nézet vevőknek és munkatársaknak; integrált futárkövetés. Support: standard munkaidő (CET, hétfő–péntek), munkaidőn kívüli vagy szezonális ügyelet nem elvárás (az átállás intenzív időszakát leszámítva); rendelkezésre állási vállalást, reakció- és helyreállítási időt súlyosság szerint az ajánlattevő ad; lekötött havi fejlesztési kapacitás nem elvárás (eseti fejlesztés megbízás alapján, óra- vagy napidíjon); nyelv: magyar és angol (a cseh előny). Oktatás: legfeljebb egy központi, angol nyelvű oktatás, a többit házon belül intézik az online dokumentáció alapján. (L2-40, L2-41)
• WP-18 Hűségprogram-támogatás: a platform támogassa a pontgyűjtő programot (pontok, szintek, kuponok, tagsági árazás, wallet-kártyák); valós idejű online/bolti elérhetőség (API a kasszaoldali lekérdezéshez, offline beváltható kuponkódok). Módosítva a válaszlevéllel (felváltja a felhívás 5.2 pontját): a program vagy jelenlegi formájában marad, vagy megszűnik (a döntés a nyertes kihirdetésekor születik); az átállás során nincs újratervezés. Ha marad: a CRM (Laurel) marad a tagok, pontok és szintek elsődleges nyilvántartása, a kasszák nem változnak, tagadat-migráció nincs; a platform a CRM API-n integrálódik (előre nyomtatott kártyák aktiválása és online igénylés, kártya–webshop-fiók összekapcsolás, szint-lekérdezés és automatikus kedvezmény, pontjóváírás vásárlás után) — külön árazva (C.4, 16. sor, az 1. soron kívül). Minden 2. részre ajánlatot tevő bemutatja a platformja saját hűségmechanizmusait (C.2.1, 5.2.2; indikatív ár: C.4, 17. sor). Ha az ajánlattevő a jelenlegi programot nem tudja megvalósítani, az nem kizáró ok. (lásd 07-questions.md → REQ-10; 09-loyalty-clarification, 08-loyalty-api-trimmed)
• WP-19 Vevőkommunikáció: minden tranzakciós kommunikáció (rendelés-visszaigazolás, szállítási értesítés, számla) a platform küld, Butlers domainről.
• WP-20 Lock-in mérséklés: adathordozhatóság (teljes export-formátumok), tulajdon vs. bérlet tisztázása, kilépési támogatás, adathozzáférés bármikor és megszűnéskor.
• WP-21 Rendelésellenőrzés és szabálymotor: ma minden rendelést a webshop-csapat ellenőriz és továbbít kézzel; az új platformon is kézi ellenőrzési sorral indulnak, később — ha minden stabilan működik — fokozatosan automatikus továbbításra váltanak. Az üzemmód közötti váltás és a szabályok a webshop-csapat által, fejlesztő nélkül állíthatók. Automatikus módban a szabályoknak megfelelő rendelés emberi beavatkozás nélkül továbbmegy, csak a problémás (hiányos, gyanús, fizetésre váró) akad meg; hiányos rendelés egyik üzemmódban sem kerülhet a fulfillment-partnerhez. A vevői felület kötelezően bekéri a szükséges adatokat (pl. telefonszám nélkül ne lehessen rendelni; piaconként eltérő kötelező mezők). Ha ez külön fejlesztést igényel, a C.4-ben jelezni kell. (G-01)
• WP-22 Fizetési módok: a fizetési szolgáltató mindhárom piacon a Globalpay, amelyet megtartanak, hacsak nincs nyomós indok és ösztönző a váltásra; online kártyás fizetés, utánvét, átutalás (céges vásárlóknál a rendelés a jóváírás után kerül továbbításra); bolti fizetés és halasztott fizetés nincs, nem tervezik. Apple Pay és Google Pay bevezetése kívánatos. A bevételek piaconként külön bankszámlára érkeznek (HUF, illetve EUR); devizaváltási feladat nincs. Az ajánlatban a fizetési integrációkat és költségüket kell szerepeltetni. (L2-08, L2-09)
• WP-23 Felhasználó- és szerepkör-kezelés (admin): szerepkör-alapú hozzáférés piaconkénti jogosultság-szétválasztással; felhasználók: webshop-csapat, marketing, ügyfélszolgálat, pénzügy/könyvelés (riportok, csak olvasás), cseh csapat (CZ/SK tartalom és árak, piaconként korlátozva). Árazáshoz legalább 15 névre szóló felhasználóval kell számolni; felhasználószám-függő árazást a C.4-ben jelezni kell. A szerepkörök pontos mátrixa a kiválasztott platform képességei alapján véglegesítendő. (lásd 07-questions.md → REQ-01; L2-41; korábban IMP-01)
• WP-24 Számlázási életciklus: eladó és számlakibocsátó mindhárom piacon a Vidámnyik Kft.; a CZ/SK online értékesítést a Társaság utólag továbbszámlázza a cseh, illetve szlovák társaságnak — ehhez piaconkénti (HU/CZ/SK) értékesítési és zárási riportok kellenek, a továbbszámlázás nem a platform feladata. A szamlazz.hu megtartása nem kötelező: bármely NAV-kompatibilis megoldás (szamlazz.hu/Billingo vagy közvetlen NAV Online Számla 3.0) elfogadható, ha lefedi a teljes bizonylat-életciklust (számla, helyesbítő és sztornó számla, részleges visszatérítés, utánvét-kezelés), a Társaság bármikor teljes archívum-hozzáférést és exportot kap, és a NAV-sémaváltozásokat követik. Elvárás: automatizált részleges visszatérítés és számlakorrekció; a fizetések és az utánvét-elszámolások rendelésekhez párosítása; marketplace-rendelésnél a platform állítja ki a vevői számlát, ha a marketplace így kéri. (L2-10, L2-11, L2-34)
• WP-25 Akciók, kuponok, csomagajánlatok: a webáruház B2C-működésű; a céges vásárlók normál vásárlóként, céges számlázási adatokkal vásárolnak; vevőnkénti árlista, szerződéses ár és mennyiségi kedvezmény nincs, külön B2B-folyamat nem elvárás. Az akciók, kuponok és hűségkedvezmények kombinálhatósági szabályait a platformnak konfigurálhatóan kell kezelnie. A kampánykedvezményeket a marketing állítja a platformon (a Beforg akciós árat nem hordoz); a csomagajánlatokat (bundle) és kuponokat a platform csapata definiálja; a raktárban fizikailag összeállított szettek önálló cikkek (az összeállítás mozgásként jelenik meg a havi zárásban). Affiliate programot a Társaság nem működtet. (L2-08, L2-16, L2-17, L2-32)
• WP-26 Átvételi kritériumok: a felhívás számszerű küszöböt nem rögzít; az ajánlattevők javasolnak (pl. Core Web Vitals „jó" tartomány mobilon a fő sablonokon, WCAG 2.1 AA, GA4 e-commerce eseménylefedettség), ezek a szerződés részévé válnak. Az üzleti átvételi tesztet a webshop-csapat végzi és hagyja jóvá (CZ/SK a cseh csapat bevonásával), az ajánlattevő által adott tesztforgatókönyvek alapján. (L2-42; lásd 07-questions.md → REQ-18)
• WP-27 Design-hatókör és sablon: általános facelift (minden fő sablon); az új designt a marketing-csapat hagyja jóvá. Átadásra kerül a butlers.com teljes téma-exportja (2026-08-05-i állapot; Sleek/FoxEcom 2.0.0, Modiva preset, Shopify Online Store 2.0, egyedi section-ök és theme block-ok, ~30 oldal-/terméksablon, metamező-alapú tartalmak; HU/CS/SK fordítás ~97%); a téma egyszeri licencét (~350 USD/áruház) a magyar áruházra meg kell vásárolni. NEM kerülnek átadásra a külön appra épülő funkciók (Klaviyo, Pandectes, Speed Kit, Loox, Stockist) — ezeket az ajánlattevő által javasolt eszközök váltják ki, külön árazva. A téma-export a shortlistre került ajánlattevőknek titoktartási nyilatkozat alapján érhető el, nem-Shopify ajánlatnál is design-referencia; formális brand guideline vagy Figma nincs. (L2-43, L2-44)

Cél-architektúra — rendszermodell

Jelmagyarázat: a piros keretű elem (Webáruház-platform) a 2. rész — az online csatorna elsődleges nyilvántartása. A szaggatott nyíl visszafelé áramló adatot (mozgásjelentések) jelöl. A szürke elemek külső vagy belső rendszerek, amelyek nem képezik a tender tárgyát.

Forrás: 00-annex-b-architecture-v1.0.hu — B.2 Célmodell

Nem-funkcionális követelmények

• NF-01 Q4 csúcskapacitás: a decemberi csomagvolumen a nyári szint 3,5–4-szerese (~6 900 csomag/hó vs. ~1 850 júliusban). Az SLA nem romolhat a csúcsidőszakban.
• NF-02 SLA futárátadás: D+2 (a rendelés átvételétől számított 2 munkanapon belül).
• NF-03 Törésarány: <1% cél a törékeny áru esetén.
• NF-04 Készletpontosság: közel nulla eltérés az éves leltárban (jelenlegi referenciaérték).
• NF-05 Rendelkezésre állás (uptime): a platform rendelkezésre állási vállalást kell hogy adjon (SLA).
• NF-06 Adatvédelem / GDPR: EU-n belüli adattárolás előnyben; adatfeldolgozási megállapodás szerződéskötés előfeltétele; vevőadat-migráció jogszerűen, örökölt másolatok törlésével.
• NF-07 Adathozzáférés: bármely és minden adat, API + export, bármikor és megszűnéskor, díjmentesen.
• NF-08 Átállás: nem zavarhatja a Q4-es értékesítést; a ~2027. január 15-i időpont a fejlesztés tényleges kezdete, nem az éles átállásé; kötelező befejezési határidő nincs — a felelősen vállalt go-live dátum az ajánlat része és értékelési szempont; a három piacnak együtt kell indulnia; a platform a go-live naptól az online készlet és a számlázás elsődleges nyilvántartása (egyetlen átkapcsolással). (G-05)
• NF-09 Front-end teljesítmény: Core Web Vitals erős értékek, szemantikus HTML, strukturált adatok, akadálymentesség.
• NF-10 Biztosítási fedezet: raktári készletre és úton lévő árura (fedezeti szintek, kárrendezés).
• NF-11 Többpiacos működés: HU/CZ/SK egyidejű kiszolgálás három devizában, lokalizált tartalommal.
• NF-12 Terhelés- és kampánycsúcsok: a HU forgalom csúcsa a november–decemberi időszak (~2,5-szerese az alapszintnek; 2025-ben HU 48–60 ezer felhasználó/hó szezonon kívül, 70–120 ezer szezonban); a platformnak a Black Friday-jellegű kampánynapokat terhelés nélkül kell kiszolgálnia (napi/órás csúcsadat nem áll rendelkezésre). (L2-07)

Implicit követelmények

Az alábbiak nem szerepelnek kifejezetten a discovery anyagban, de a rendszer működéséhez szükségesek:

• IMP-01 Felhasználó- és szerepkör-kezelés (admin): döntés született (REQ-01), a követelmény áthelyezve: lásd WP-23.
• IMP-02 Audit napló: a számviteli riportolás, GDPR-megfelelés és készletmozgás-nyilvántartás igényli, hogy minden érdemi művelet naplózott legyen. (lásd 07-questions.md → REQ-02)
• IMP-03 Backup és disaster recovery: SaaS/hoszting környezetben a rendelkezésre állási vállalás implicit feltétele a rendszeres mentés és helyreállítási terv. (lásd 07-questions.md → REQ-03)
• IMP-04 Környezetek (staging / production): a migráció, design-átvilágítás és folyamatos fejlesztés feltételezi, hogy van staging/teszt környezet az éles mellett. (lásd 07-questions.md → REQ-04)
• IMP-05 Transzport-biztonság (HTTPS / TLS): webáruház, API-kommunikáció és fizetési tranzakciók esetén alapelvárás. (lásd 07-questions.md → REQ-05)
• IMP-06 Monitoring és alerting: SLA-vállaláshoz (uptime, válaszidő) szükséges a rendszer-monitorozás és riasztás. (lásd 07-questions.md → REQ-06)
• IMP-07 Termékadat-verziókezelés: a Beforg feed heti frissítésével és a többnyelvű tartalom-szerkesztéssel egy időben biztosítani kell, hogy az árak és tartalom nem kerülnek inkonzisztens állapotba. (lásd 07-questions.md → REQ-07)

Tisztázandó

• A Beforg-feed formátuma eldőlt (JSON, beszállításonként egy fájl; lásd REQ-08), de az átviteli mód (pull/push), a gyakoriság és az autentikáció szerződéskötéskor rögzítendő. — REQ-08
• A készletértékelési módszer (FIFO vs. súlyozott átlag) az új felállásban — a Társaság könyvelésével egyeztetendő; az egyetlen elsődleges nyilvántartás elve és a beszerzési értéken történő visszáru/mozgás eldőlt. — REQ-09
• A hűségprogram megmarad-e vagy megszűnik — a nyertes kihirdetésekor dől el; az átállás alatt nincs újratervezés, a CRM marad az elsődleges nyilvántartás. — REQ-10
• A CZ/SK bolti átvételi pontok (Prága 3, Pozsony 1) pontos helyszínei és üzemeltetési modellje. — REQ-11
• Marketplace-enként (eMAG, Temu, Allegro) a konkrét integrációs út — az ajánlattevők javaslata alapján; a sorrend eldőlt (eMAG képesség árazandó, Allegro/Temu stabil indulás után). — REQ-12
• Ajándékkártya/kupon piaci lefedettsége: a felhívás mindhárom piacot említi, a válaszlevél szerint online kupon csak HU/SK-n létezik (WP-12). — REQ-14
• A BaseLinker jelenlegi használata vs. „nincs élő marketplace-csatorna" (WP-11). — REQ-15
• Bolti gyűjtőcsomag, átadás-rögzítés és bolti visszáru folyamata (FF-09). — REQ-16
• Végleges fulfillment-interfész, leltárgyakoriság és eltérés-kezelés — az 1. rész nyertesével egyeztetendő (FF-12, FF-27). — REQ-17
• Számszerű átvételi küszöbök (WP-26) — az ajánlattevők javaslata alapján. — REQ-18