Válaszok az ajánlattevői kérdésekre

Butlers Hungary (Vidámnyik Kft.) --- Ajánlattételi felhívás: E-kereskedelmi fulfillment és webáruház-platform szolgáltatások

v1.0 --- 2026. október 2. --- BIZALMAS --- minden meghívott ajánlattevő részére

Bevezetés

A felhívás 7. fejezete szerint az ajánlattevői kérdéseket 2026. szeptember 18-ig fogadtuk. Négy ajánlattevőtől összesen 86 kérdés érkezett. A jelen dokumentum minden kérdést és választ minden ajánlattevőnek megküld, az alábbi szabályok szerint:

• A kérdések anonimizáltak: a kérdező nincs megnevezve, az ajánlattevő-specifikus részletek általánosítva vannak. Az azonos tárgyú kérdéseket összevontuk, a többrészes kérdéseket szükség szerint szétbontottuk vagy átfogalmaztuk.
• Minden válasz minden ajánlattevőre egyformán vonatkozik, függetlenül attól, ki tette fel a kérdést.
• Ahol a válasz a felhívás szövegét módosítja, ezt kifejezetten jelezzük. Ilyen módosítás: a hűségprogram (5.2 pont --- lásd G-03 és a csatolt pontosítás), a termékadat-modell („B" melléklet B.2 2. pont --- lásd G-02), az árfolyamszabály (7. fejezet --- lásd G-04) és a „C" melléklet (v1.1, csatolva).
• A kérdéseknek azonosítót adtunk (G-xx általános pontosítások, L1-xx az 1. rész, L2-xx a 2. rész).
• Az eljárás többi eleme változatlan: ajánlattételi határidő 2026. október 16., shortlist-prezentációk október negyedik hetében illetve november első hetében (online vagy személyes időpontokat ennek ismeretében egyeztetünk), döntés novemberben.

Mellékletek ehhez a válaszlevélhez:

1. loyalty-clarification.docx --- Hűségprogram: a felhívás 5.2 pontját felváltó pontosítás (magyar és angol nyelven).
2. loyalty-api-trimmed.docx --- A jelenlegi hűségprogram CRM API-jának kivonata (a releváns függvények).
3. annex-c-response-pricing-v1.1.hu.docx / .en.docx --- „C" melléklet v1.1 (módosított 5.2.1--5.2.2 sorok, C.4 16--19. sorok, C.0 árfolyamszabály).
4. annex-b4-monthly-close-sample.xlsx --- A havi könyvelési zárás szerkezeti mintája (fiktív értékekkel).
5. beforg-feed-sample.json + beforg-feed-fields.docx --- A Társaság termékadat-hubjának (Beforg) kimeneti mintája és mezőlistája.

G --- Általános pontosítások (minden ajánlattevőnek)

G-01 Rendelés-átadás és rendelésminőség

Ma minden rendelést a webshop-csapat ellenőriz és továbbít kézzel a fulfillment felé. Az új platformon ezzel az üzemmóddal szeretnénk indulni (kézi ellenőrzési sor), majd később fokozatosan --- ha minden stabilan működik --- átkapcsolni teljesen automatikus továbbításra. A két üzemmód közötti váltásnak és a szabályoknak a webshop-csapat által, fejlesztő nélkül állíthatónak kell lennie. Automatikus módban a szabályoknak megfelelő rendelés emberi beavatkozás nélkül továbbmegy, és csak a problémás (hiányos, gyanús, fizetésre váró, kézi ellenőrzést igénylő) rendelés akad meg. Hiányos rendelés egyik üzemmódban sem kerülhet a fulfillment-partnerhez. A vevői felületnek a szükséges adatokat kötelezően be kell kérnie (pl. telefonszám nélkül ne lehessen rendelést leadni; piaconként eltérő kötelező mezők). Kérjük, az ajánlatban mutassák be a rendelés-ellenőrzési és szabálymotor-képességeket, és a C.4-ben jelezzék, ha ez külön fejlesztést igényel.

G-02 Termékadatok: a Beforg-feed (felváltja a „B" melléklet B.2 2. pontját)

A Társaság a német feedet saját maga dolgozza fel: a kiválasztott platform kizárólag a Társaság termékadat-hubjából (Beforg) kap adatot, JSON formátumban. Az ajánlattevő a német feedet semmilyen formában nem dolgozza fel; ez a szabály minden ajánlattevőre egyformán vonatkozik, és a „B" melléklet B.2 2. pontjában említett kétforrású modellt felváltja.

A Beforg beszállításonként egy fájlt ad át: egy beszállítás-fejlécet (szállítmány-hivatkozás, várható beérkezés, raktár, árfolyam) és minden beszállított cikkről egy teljes cikkrekordot a saját beszállítási tételével. Ez a teljes adatkör; ha a folyamat igényli, ugyanebből a struktúrából részhalmazok (pl. beszállítás nélküli cikkfrissítés) is előállíthatók.

A cikkrekord tartalma: cikkszám, EAN, magyar és német nevek, német leírás (ahol a márkatulajdonos honlapján létezik), webes variánscsoport, kategória/taxonómia, attribútumok, méretek és csomagolási egységek, származás és vámtarifaszám, magyar fogyasztói ár, áfa és nettó beszerzési ár, státusz, képek; a beszállítási tétel: mennyiség és nettó egységköltség. A mennyiség tájékoztató jellegű: a fulfillment-oldal a bevételezéskor megerősíti vagy módosítja, a platform a számolt mennyiséget könyveli a tétel egységköltségén; törlés nincs. Az átadás a szállítólevél beárazásakor, a fizikai beérkezés előtt 2--3 nappal történik.

Nem része a feednek: készlet (a platform készletkönyve a forrás), akciós árak (a marketing a platformon állítja be), magyar/cseh/szlovák leírások (a Társaság csapatai a platformon tartják karban; a német forrásszöveget ehhez a feed szállítja). Átvitel (pull vagy push) és gyakoriság a szerződéskötéskor kerül rögzítésre. A Beforg-oldali fejlesztést a Társaság saját erőből, saját költségén végzi. A minta (a 2026. szeptember 28-i beszállítás 12 cikke) és a mezőlista a jelen válaszlevél melléklete, hogy az árazás pontos alapon készülhessen.

G-03 Hűségprogram (felváltja a felhívás 5.2 pontját)

A hűségprogramra vonatkozó valamennyi kérdést (bolti működés, kasszák, üzleti szabályok, pontegyenlegek, időzítés, árazás) a csatolt „Hűségprogram --- a felhívás 5.2 pontját felváltó pontosítás" dokumentum válaszolja meg, a „C" melléklet v1.1-gyel és a CRM API kivonatával együtt. Összefoglalva: a program vagy jelenlegi formájában marad, vagy megszűnik (döntés a nyertes kihirdetésekor); az átállás alatt nincs újratervezés; a bolti oldal nem változik; tagadatok és pontegyenlegek migrációja nincs, a CRM marad az elsődleges nyilvántartás; a jelenlegi program integrációja külön árazandó („C" melléklet 16. sor), a platform saját hűségmechanizmusai az 5.2.2 sorban és a 17. soron mutatandók be. Ha egy ajánlattevő a jelenlegi programot nem tudja megvalósítani, az nem kizáró ok.

G-04 Ár-deviza és összehasonlító árfolyam (pontosítja a 7. fejezetet)

Az ajánlat HUF-ban vagy EUR-ban is megadható, az ajánlaton belül egységesen. Az összehasonlításhoz az EUR-árakat az ajánlattételi határidő napján (2026. október 16.) érvényes MNB-középárfolyamon számítjuk át HUF-ra. Ez a szabály a felhívás 7. fejezetének árfolyam-mondatát pontosítja, és a „C" melléklet v1.1 C.0 2. pontjában is szerepel.

G-05 Ütemezés, go-live, kötelező induló tartalom

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, és azt szolgáltatói felmondás vagy szerződésmegszűnés sem kényszeríti ki; a felelősen vállalt go-live dátum az ajánlat része és az értékelés szempontja. A platform a go-live napjától az online készlet és a számlázás elsődleges nyilvántartása --- egyetlen átkapcsolással. A három piacnak együtt kell indulnia. Marketplace-kapcsolat az induláshoz nem szükséges, de a csatlakozási képességet és annak árazását az ajánlatnak tartalmaznia kell (C.4, 7. sor) --- a TCO-ban az 1. évre, opciós sorként. A mobil-megközelítés (5.1.8) ajánlott megoldását a C.4 12. sorában kérjük beárazni; az éles indulásnak nem feltétele. A hűségprogramra a G-03 vonatkozik.

G-06 A válaszok terjesztése

Minden kérdés és válasz minden ajánlattevőhöz eljut anonimizálva (a kérdező nincs megnevezve); az ajánlattevő-specifikus kereskedelmi részletek általánosítva, az azonos kérdések összevonva, a többrészes kérdések szükség szerint átfogalmazva.

L1 --- 1. rész: Fulfillment

L1-01 Van-e olyan igény, amelyet a jelenlegi szolgáltatás nem elégít ki teljes mértékben?

A bútorszállítás, a szezon alatti szolgáltatási minőség és az előre egyeztetett kapacitásbővítés voltak problémás pontok a múltban. Elvárás a garantált kapacitás a szezonban (október 15. -- december 15.), hibátlan és gyors szolgáltatással: beszállítás és 2 napos bevételezés a szezonban is.

L1-02 A csomagküldéshez kapcsolódó reklamációk kezelése --- beleértve a futárszolgálatokkal való egyeztetést --- a fulfillment-szolgáltató feladata?

Igen. A vevő felé a kommunikációt a Társaság webshop-csapata végzi, de a futárszolgálatokkal szembeni ügyintézés (elveszett, sérült, késett csomag kivizsgálása, kárigény érvényesítése) a fulfillment-szolgáltató feladata, mivel a futárszerződéseket ő tartja. Az ehhez szükséges 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.

L1-03 Az 1 napon belüli készletre vétel az alapszolgáltatás része?

Elvárásunk, hogy 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-04 Elvárás a csomagolóanyagok rendelésenkénti, vonalkódos nyomon követése?

Nem elvárás. Az elvárás az, hogy a csomagolóanyag-költség a C.3 szerinti egységárakon, méretosztály vagy rendelés szerint átláthatóan és a havi elszámolásban tételesen ellenőrizhetően jelenjen meg.

L1-05 Felszámítható díj új cikkszám rendszerbe vételéért?

Igen, amennyiben azt a C.3 árlapon külön egységár-sorként (pl. „új cikkszám törzsadat-felvétele") transzparensen feltüntetik. Az értékelés a teljes költséget nézi; rejtett vagy utólag bevezetett díjtételek nem fogadhatók el. Tájékoztatásul: évente kb. 1 500--2 500 új cikkszám kerül felvételre.

L1-06 Vállal-e a Társaság határozott időtartamú együttműködést, és milyen időtávra?

A Társaság nem ír elő szerződéses időtartamot: az ajánlattevő javasolja a futamidőt, a felmondási és kilépési feltételeket, valamint az ár-felülvizsgálati mechanizmust (4.4). A szerződéses rugalmasság és a kilépési feltételek értékelési szempontok; az összehasonlítás 3 éves TCO-alapon történik. Határozott időtartamú konstrukció ajánlható, ha a hozzá tartozó ár- és kilépési feltételek egyértelműek. (Ugyanez vonatkozik a 2. részre --- lásd L2-42.)

L1-07 Elvárás minél több belföldi és külföldi futárintegráció?

Nem elvárás a jelenlegi futármix teljes lefedése. Elvárás egy egészséges mix: nagy és kisebb futárszolgálatok, valamint csomagátvételi pontok mindhárom országban (HU/CZ/SK). Kérjük, az ajánlatban sorolják fel az élesben működő futár-integrációkat piaconként, és jelezzék, futárváltás esetén milyen átfutással állítható át egy szolgáltatás.

L1-08 Fontosak a díjmentes szolgáltatáselemek (díjmentes tárolási időszak, bevételezés)?

Nem elvárás. Az értékelés a C.5 referenciahónap-árazás és a 3 éves TCO alapján a teljes költséget hasonlítja össze. A díjmentes elemeket az egységárakban és a feltételeikben (mire, meddig, milyen limittel) egyértelműen kérjük feltüntetni, hogy összehasonlíthatók legyenek.

L1-09 Hogyan kell igazolni a rendelés pontos teljesítését vevői reklamáció esetén?

Elvárás, hogy a szolgáltató rendelésenként visszakereshetően igazolni tudja a komissiózást és a csomagolást: tételes vonalkód-szkennelés csomagoláskor, csomagsúly-ellenőrzés, a csomagoló azonosítója és időbélyeg; fotódokumentáció opcióként. Kérjük, írják le a standard bizonyítási módszert és annak esetleges díját, valamint hogy ezek az adatok API-n/exporton elérhetők-e (4.3.10).

L1-10 Mi az elvárt válaszidő ticketen vagy e-mailben leadott megkeresésekre?

Kérjük, az ajánlatban adják meg a support-vállalásukat (munkaidő, reakció- és megoldási idő súlyosság szerint). Elvárásunk: kiszállítást akadályozó ügyben (hibás vagy 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-11 Adható tárolási ajánlat m², polcfolyóméter vagy kapacitás-foglaltság alapján is?

Az összehasonlíthatóság érdekében a C.3 (darab/hó, méretosztályonként) és a C.5 referenciahónap-árazás kitöltése ezen a bázison kötelező. Ezen felül alternatív modell (m², polcfolyóméter, kapacitás-alapú) is megadható külön lapon, a feltételeivel együtt. A nem optimális tárolási elrendezésből eredő kapacitás- és költségkockázat a szolgáltatót terheli; a méretosztály-besorolás alapját a mért adatok adják (lásd L1-13).

L1-12 Hasznos-e további termékadatok (gyártási szám, szín, csomagolástípus) kezelése a raktári rendszerben?

Nem elvárás --- a terméktörzs bejövő forrása a Társaság termékadat-hubja (Beforg), ezt követően a hivatalos forrás a Webshop rendszer lesz (az adatok beérkeztetésének pontos menete a Lot1 és Lot2 nyertesek közötti megbeszélés tárgya, a Társaság aktív részvételével, igény szerint a Beforg rendszer módosításával); a raktári rendszernek a cikkszám/EAN/megnevezés/méret-súly/méretosztály adatokra van szüksége. A csomagolástípus (régi/új) vagy eltérő EAN-változatok megkülönböztetése ugyanakkor a gyakorlatban hasznos lehet; opcióként bemutatható, a felmerülő költséggel együtt.

L1-13 Elvárás a beérkező termékek lemérése és a mért adatok megőrzése?

Igen. Mivel az árazás méretosztály-alapú, az első bevételezéskor mért méret- és súlyadatot cikkszámonként rögzíteni kell, a Társaság számára API-n/exporton folyamatosan elérhetővé kell tenni (4.3.10), a szerződés teljes ideje alatt meg kell őrizni és kilépéskor át kell adni. A méretosztály-viták rendezésének alapja ez a mért adat.

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

2.1 Platform, ajánlati modell és értékelés

L2-01 Nyílt forráskódú, a Társaság tulajdonába kerülő platform (pl. Shopware, Magento) az 5.1.1 szerinti kategóriába tartozik, vagy külön lock-in indoklás alá esik?

A nyílt forráskódú, a Társaság tulajdonába kerülő platform nincs kizárva, az 5.1.1 szerinti kategóriába tartozhat. Az 5.3.8 szerinti lock-in értékelésnél ilyenkor nem a licenc, hanem az ajánlattevőtől való függés számít: az egyedi fejlesztések dokumentáltsága, más szállító általi átvehetősége, a hosting és az üzemeltetés átadhatósága --- kérjük ezeket bemutatni.

L2-02 Elfogadható kétlépcsős ajánlat: fix díjas tervezési projekt, majd indikatív ársáv a kivitelezésre?

A felhívás teljes körű, kötelező érvényű ajánlatot vár (C.4 + 3 éves TCO). A kétlépcsős szállítás (tervezés → kivitelezés) projektmódszertanként elfogadható, de az ajánlatnak a kivitelezésre is tartalmaznia kell kötelező árat vagy világos feltételezésekkel alátámasztott, felső korláttal rendelkező ársávot, amely a TCO-ba beszámít; a 90 napos ajánlati kötöttség a teljes ajánlatra vonatkozik. Csak a tervezésre szóló ajánlat nem hasonlítható össze a többi ajánlattal, ezért a döntés a teljes scope-ra születik. A C.4-ben a tervezési fázist külön sorként, a kivitelezést munkacsomagonként tételezve kérjük.

L2-03 Milyen költségkerettel számol a Társaság?

A Társaság nem tesz közzé költségkeretet. Kérjük, a C.4 szerint árazzanak; az értékelés a 3 éves TCO-t és az ár-érték arányt veszi figyelembe. Lekötött havi fejlesztési keret nem elvárás (az eseti fejlesztéseket óra-/napidíjon kérjük); a supportot egységes elvárások mentén hasonlítjuk össze (lásd L2-40).

L2-04 A platformlicenc a TCO-ban gyártói listaáron vagy továbbszámlázott áron szerepel?

A továbbszámlázott, az ajánlatban szereplő áron. Tájékoztatásul kérjük a gyártói listaárat és a feltételezett csomagot/szintet is feltüntetni, hogy az árváltozási kockázat megítélhető legyen.

L2-05 Mi az elvárt éles indulási dátum?

Lásd G-05: nincs rögzített dátum, a felelősen vállalt go-live dátum az ajánlat része és az értékelés szempontja.

2.2 Volumenek, fizetés, számlázás

L2-06 Mit tartalmaznak az „A" melléklet volumenadatai, és milyen növekedéssel kell számolni?

Az „A" melléklet csomagszámai a fulfillment-szolgáltató tényleges 2025-ös feladásain alapulnak: minden, az online raktárból kiküldött csomag, a feladás előtt törölt rendelések nélkül; az át nem vett és visszaküldött csomagok benne vannak, arányukat külön közöljük --- ezek teljes számok. Az árbevétel-adatok részletes összetételét (szállítási díj, visszatérítések, nettó/bruttó bontás) ebben a szakaszban nem tesszük közzé. Növekedési célt nem teszünk közzé; a TCO-hoz a 2025-ös volumeneket kérjük alapul venni, a volumenfüggő tételek skálázását pedig bemutatni.

L2-07 Mekkora a látogatottság piaconként, milyen csúcsok jellemzők, hogyan változik a cikkszám- és vevőállomány?

Látogatottság (GA4, „összes felhasználó", 2025): Magyarország havi 48--60 ezer felhasználó szezonon kívül, 70--120 ezer a szezonban (október 70 ezer, november 106 ezer, december 119 ezer); Csehország 26--38 ezer szezonon kívül, 48--59 ezer szezonban; Szlovákia 4--9 ezer szezonon kívül, 11--14 ezer szezonban. Éves összesen: HU 672 ezer felhasználó / 15,3 ezer vásárló / 17,3 ezer e-kereskedelmi vásárlás; CZ 404 ezer / 11,1 ezer / 11,6 ezer; SK 87 ezer / 2,1 ezer / 2,2 ezer. A csúcs a november--decemberi időszak (a HU forgalom ~2,5-szerese az alapszintnek); napon belüli vagy órás kampánycsúcs-adat nem áll rendelkezésre --- a platformnak a Black Friday-jellegű kampánynapokat kell terhelés nélkül kiszolgálnia. Az aktív cikkszámok száma érdemben nem változik (évente kb. 1 500--2 500 új cikk, hasonló számú kifutó); marketplace-listázásokat fokozatosan tervezünk hozzáadni; vevőszám-előrejelzést nem teszünk közzé.

L2-08 Céges vásárlók aránya, B2B-folyamat, egyedi árlisták?

A webáruház B2C-működésű; a céges vásárlók normál webshopos vásárlóként, céges számlázási adatokkal vásárolnak --- számukra az átutalásos fizetés releváns (a rendelés a jóváírás után kerül továbbításra). Vevőnkénti egyedi á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.

L2-09 Fizetési módok és szolgáltatók piaconként; megtartandók-e; díjak és devizakezelés?

Fizetési szolgáltatónk mindhárom piacon (HU/CZ/SK) a Globalpay, amelyet megtartanánk, hacsak nincs nagyon nyomós indok és ösztönző a váltásra. Elérhető fizetési módok: online kártyás fizetés, utánvét (arányok az „A" mellékletben), átutalás; bolti fizetés és halasztott fizetés nincs, bevezetését nem tervezzük. Szeretnénk Apple Pay és Google Pay fizetést bevezetni. A rendelésszám és az árbevétel fizetési módok szerinti megoszlását, valamint a jelenlegi szolgáltatói díjakat és szerződéses feltételeket nem tesszük közzé; az ajánlatban a platform fizetési integrációit és azok költségét kérjük szerepeltetni. A bevételek piaconként külön bankszámlára érkeznek (HUF, illetve EUR); devizaváltási feladat sem a platformra, sem a fulfillment-partnerre nem hárul.

L2-10 Ki az eladó és a számlakibocsátó piaconként; továbbszámlázás; szamlazz.hu; részleges visszatérítés és egyeztetés?

Az eladó és a számlakibocsátó mindhárom piacon a Vidámnyik Kft.; a CZ/SK online értékesítést a Társaság utólag utalja tovább a cseh, illetve szlovák társaságnak --- ehhez a platformnak piaconkénti (HU/CZ/SK) bontású értékesítési és zárási riportokat kell adnia (5.1.4, B.4), a továbbszámlázás maga nem a platform feladata. A szamlazz.hu megtartása nem kötelező: NAV-kompatibilis számlázás bármely megoldással elfogadható (szamlazz.hu/Billingo-integráció vagy közvetlen NAV Online Számla kapcsolat), ha a teljes számla-életciklust (számla, helyesbítő és sztornó számla, részleges visszatérítés, utánvét-kezelés) lefedi, a számlaarchívumhoz a Társaság bármikor teljes hozzáférést és exportot kap, és a megoldást a NAV-sémaváltozásokhoz karbantartják. Az automatizált részleges visszatérítés és számlakorrekció, valamint a fizetések és az utánvét-elszámolások rendelésekhez párosítása elvárás. Marketplace-rendeléseknél egyes platformoknál (pl. Allegro) a vevői számlát a platformnak kell kiállítania, amelyet a marketplace továbbít --- ezt a képességet is elvárjuk.

L2-11 Elfogadható a platform által üzemeltetett közvetlen NAV Online Számla 3.0 integráció szamlazz.hu vagy Billingo nélkül?

Igen, az L2-10-ben leírt feltételekkel (teljes bizonylat-életciklus, teljes archívum-hozzáférés és export, sémaváltozások követése). A szamlazz.hu megtartása nem kötelező.

2.3 Termékadatok (Beforg)

L2-12 Elérhető-e a Beforg-feed specifikációja és mintája; a két feedmodell közül melyik áll készen; melyik igényel fejlesztést, ki végzi és mikorra?

Lásd G-02. Egyik korábbi modell sem: a Társaság egyetlen konszolidált JSON-feedet ad; a minta és a mezőlista csatolva. A Beforg-oldali fejlesztést a Társaság végzi saját erőből, az átállási ütemtervhez igazítva.

L2-13 Teljes-e a feed mindhárom nyelven; ki tartja karban a CZ/SK szövegeket?

A CZ/SK termékszövegeket a Társaság cseh csapata a platformon tartja karban (AI-támogatott fordítómodul opcióként, emberi ellenőrzéssel, üdvözölt). A feed a magyar és német neveket, valamint a német forrásleírást szállítja --- lásd G-02.

L2-14 Tartalmaz-e a feed méret- és súlyadatot cikkenként?

Igen --- a Beforg-feed a márkatulajdonostól kapott méreteket, súlyt és csomagolási egységeket cikkenként tartalmazza, így a platformnak a német feedhez nem kell nyúlnia. A Beforg az új cikkek, nevek, árak és költségek webshopba juttatásának eszköze; készletet nem vezet --- a készlet a platform készletkönyve.

L2-15 Várható beszállítások: formátum, időzítés, deviza, korrekciók és törlések?

A beszállítások nincsenek előre tervezve: a szállítólevél a fizikai beérkezés előtt 2--3 nappal ér hozzánk, miután az áru a német raktárt elhagyta. A Beforg beárazza és lefordítja, és a platformnak beszállításonként egy JSON-fájlt ad át (fejléc: szállítmány-hivatkozás, várható beérkezés, raktár, árfolyam; cikkenként teljes rekord a mennyiséggel és a HUF-ban megadott nettó egységköltséggel). 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. Lásd a csatolt mintát és mezőlistát.

L2-16 Ki határozza meg a kampánykedvezményeket: a marketing a platformon, vagy a Beforg akciós árakkal?

A marketing a platformon. A Beforg csak fogyasztói árakat (és beszerzési árakat) hordoz, akciós árakat nem, és ma csak a magyar piacra.

L2-17 Ki definiálja a csomagajánlatokat (bundle) és a kuponokat a célállapotban?

A platform csapata, a platformon. A raktárban fizikailag összeállított készletek/szettek önálló cikkek (összeállításuk mozgásként jelenik meg a havi zárásban); külön szinkronizáció bundle-ökre vagy kuponokra nem tervezett.

2.4 Készletkönyv, fulfillment-interfész, átállás

L2-18 Kik az 1. rész ajánlattevői, hogy a konnektor-lefedettség pontosan megadható legyen? Megosztott odaítélésnél a konnektor költsége utólag egyeztethető?

Az 1. rész ajánlattevőinek listáját az ajánlattételi szakaszban nem tesszük közzé. Kérjük, sorolják fel az élesben üzemeltetett fulfillment-konnektoraikat (magyar és regionális 3PL-ek), és az 1. rész konnektorát egy tipikus REST API illesztés fejlesztési költségével árazzák; az 1. rész nyertesét a 2. rész szerződéskötése előtt közöljük, és a konnektor-tétel felülvizsgálható, ha az integráció érdemben bonyolultabbnak bizonyul --- ezt nem várjuk.

L2-19 Egy ajánlattevő csatolta éles fulfillment-konnektorának folyamatleírását (bevételezés várható tételek alapján, rendelésátadás utánvéttel és futárszolgáltatással, bolti gyűjtőcsomagok, készletmozgatások, korrekciók okkóddal, visszáru-ellenőrzés). Elfogadható-e ez a felelősségmegosztás a két rész között, és megosztható-e az 1. rész nyertesével?

A bemutatott munkamegosztás megfelel a felhívás 3. fejezetének és a „B" melléklet B.3 pontjának, és kiindulási alapnak tekinthető. A végleges interfészről az 1. rész nyertesének bevonásával, a szerződéskötési szakaszban döntünk; a folyamatleírás ekkor referenciaként megosztható vele.

L2-20 Hogyan kerül megállapításra a nyitókészlet az átálláskor?

Teljes fizikai leltárral 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-21 Milyen gyakoriságú leltárt várunk, és ki dönt az eltérésről?

Ez az 1. rész nyertesétől függ, a fizikai leltár az ő felelőssége. A visszáruk készletkezelése és hasonló kérdések részleteit a nyertesekkel közösen dolgozzuk ki. A visszáruk beszerzési értéken kerülnek vissza készletre.

L2-22 Utánvét-elszámolások: formátum, gyakoriság, automatikus párosítás?

Az utánvétet a futárok szedik be a fulfillment-szolgáltató szerződései alapján, és rendeléshivatkozásokat tartalmazó kimutatással utalják át. Heti, géppel olvasható kimutatást (CSV/XLSX vagy API) várunk, amelyet a platform automatikusan párosít a rendelésekhez, a nem párosítható vagy hiányos tételeket a pénzügy számára megjelölve.

L2-23 Bolti gyűjtőcsomagok és bolti átvétel: ki állítja össze, hogyan rögzítik a beérkezést, átvételt és visszárut POS-integráció nélkül? Mozognak-e áruk raktár és boltok között készletmozgatásként, és ki indítja?

Jelenleg a fulfillment-partner állítja össze a bolti gyűjtőcsomagokat, de nyitottak vagyunk a mechanizmus megváltoztatására: a jelenlegi eljárás nem skálázható és nem elég megbízható. Kérjük minden ajánlattevőt, hogy saját megoldási javaslatát --- beárazva --- rögzítse az ajánlatban; a nyertesek megoldásai alapján alakítjuk ki a minden félnek megfelelő folyamatot. Elvárásunk, hogy a bolti térben egy webshop-alkalmazáson keresztül visszajusson a vásárlóhoz, hogy a rendelése megérkezett a boltba, az átadás ugyanígy rögzíthető legyen, és a bolti visszáru kezelésére is legyen megoldás. Rendelésbontás és részszállítás admin-oldali funkció speciális esetekre, vevői oldalról nem támogatjuk; utólagos módosításra ritkán van szükség, de valamilyen metódusnak léteznie kell. Online raktár és boltok közötti készletmozgatás ritka, különleges eset (pl. boltban leadott visszáru); ezeket a platformról indítjuk, a kapcsolódó ERP-adminisztrációt kézzel végezzük.

2.5 Számvitel és ELÁBÉ

L2-24 Elfogadható, ha a beszerzésiár-tárolás, az ELÁBÉ-számítás és a zárási riportok külön riporting rétegben (adattárház, BI) készülnek?

Elfogadható, ha a külön réteg felhasználói élménye kielégíti a könyvelés igényeit. Ennek fejlesztése, telepítése és üzemeltetése ugyanúgy a költségek elbírálása alá esik, és a lock-in elkerülésének szellemével is összhangban kell lennie.

L2-25 Milyen készletértékelési módszert alkalmazzon a platform az online készletkönyvre: FIFO, súlyozott átlag vagy a beszállításkori ár? Elfogadható egyetlen módszer az online csatornára?

Az ELÁBÉ-számítással kapcsolatban rossz tapasztalataink vannak: havi és éves zárások után változó költségek, hetekig tartó kivizsgálások és NAV-felé benyújtott helyesbítések. A rendszer ezen részének megbízhatónak kell lennie: kezelnie kell a havi zárásokat és a vevői visszárukat, ellenőrzést kell állnia, és a lehető legjobban kell segítenie a könyvelést. Elméletben az offline FIFO és az online súlyozott átlag együtt is alkalmazható (a magyar szabályozás ezt külön készletek esetén megengedi), de ez súrlódási és hibaforrás a számvitel amúgy is kényes területén --- kérjük, ezt a megoldás kialakításakor vegyék figyelembe. A Beforg a készletnyilvántartástól független: a beérkező beszállítások kezelésének eszköze, készletről nincs és nem is kell, hogy naprakész képe legyen. A tender egyik fő célja, hogy minden területen egyetlen elsődleges nyilvántartás legyen.

L2-26 Megosztható a havi zárási riport mintája egy kitöltött hónappal?

A havi zárási riport szerkezeti mintája (minden oszlop, mozgásnem és egység, fiktív értékekkel) a jelen válaszlevél melléklete; valós, kitöltött hónapot csak a szerződéskötés után adunk át.

L2-27 Egységek közötti mozgatások: mely egységek léteznek az online csatornán, hogyan értékeljük és ki igazolja az átadást?

Az online csatorna egyetlen egység: a fulfillment-partner raktára. Bútort esetenként a boltokban tartunk bemutatódarabként vagy raktárban --- ez a fulfillment-hatókörön kívül esik a kiszállítás kivételével, és nem mozog egységek között. Az online raktár és a boltok közötti mozgatás ritka, különleges eset; ezeket a platformról indítjuk, a kapcsolódó ERP-adminisztrációt kézzel végezzük (egy ERP által feldolgozható export segítene, de nem elvárás). A mozgások beszerzési értéken kerülnek elszámolásra. Mivel ilyen eddig nem volt, a folyamatot a kiválasztott partnerekkel közösen alakítjuk ki.

L2-28 Milyen árfolyamon könyvelje a platform a beszerzési értéket?

Preferenciánk, hogy a Beforg a nettó egységköltséget már HUF-ban adja át, a Társaság számviteli politikája szerint a szállítói számlára irányadó árfolyamon átszámítva, így a platform maga nem alkalmaz árfolyamot. Ha a platformnak mégis át kell számítania, a bevételezés napjának MNB-árfolyama irányadó.

2.6 Migráció

L2-29 Milyen exportot biztosít a jelenlegi szolgáltató; szerződésileg biztosított az együttműködése? Hány vevői fiók, tartalmi oldal és URL érintett; nyitott rendelések, visszáruk kezelése; fiók-újraaktiválás?

Migrálandó adatkör: ~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, valamint a SEO-szempontból fontos URL-ek átirányítási térképe; rendeléstörténet migrációja nem elvárás (archiválásra kerül). A jelenlegi szolgáltató az átadásban együttműködik, de teljes körű migrációs projektvezetést nem vállal --- ez az ajánlattevő feladata. Rendelkezésre álló források: API-hozzáférés (regisztrált felhasználók, teljes rendeléstörténet); teljes XML-export (minden termék, kategóriák, képek); további, nem szabványos exportok (kuponkódok a sablonjaikkal, a regisztrált felhasználók jelszó-hash-ei a használt algoritmussal, régi URL-ek átirányítási listája). Az online ajándékkupon-egyenlegek és -kódok a kuponexport részeként kerülnek átadásra. A kezdeti export utáni változásokat az átálláskor megismételt, végleges exporttal kezeljük. Az átálláskor nyitott rendeléseket a jelenlegi rendszer zárja le; az új platform az új rendelésekkel indul, a korábbi rendelések visszáruját és visszatérítését egy kifutási időszakban a jelenlegi rendszerben kezeljük.

L2-30 Elfogadható a jelszó-visszaállítás alapú fiókátvétel?

A jelenlegi szolgáltató a jelszó-hash-eket és a használt algoritmust átadja, ezért elsődlegesen a jelszó-visszaállítás nélküli átvételt kérjük megvizsgálni. Ha a célplatform az adott hash-algoritmust nem fogadja, a jelszó-újraállítás alapú átvétel elfogadható.

L2-31 Ajándékkártyák és kuponok: állomány devizánként, exportálhatóság, bolti használat, többszöri felhasználás, megtartandó kuponszabályok, könyvelés?

Ajándékkártyák (fizikai) csak a boltokban vásárolhatók és válthatók be, online nem; ezen egyelőre nem változtatunk. Online ajándékkuponok léteznek: 5 000 / 10 000 / 15 000 / 20 000 HUF címletek, összesen ~15M HUF kint lévő értékkel, a szlovák oldalon ~2 000 EUR; cseh kupon nincs. Kód alapúak, a kosár oldalon adhatók hozzá, csak online válthatók be; jelenleg egy összegben, egy rendelésben egy kupon használható fel, és más kuponokkal nem kombinálhatók --- az új platformon a részleges beváltást, több kupon együttes felhasználását és a promóciós kuponokkal való kombinálhatóságot elvárjuk. Könyvelés: az online kuponok értékesítéskor, áfa felszámítása nélkül kerülnek könyvelésre (az áfa a beváltáskor keletkezik). A kódok, egyenlegek és lejáratok a jelenlegi rendszerből exportálhatók. Születésnapi kuponok: automatikusan kiküldött, névre szóló, egyszer használatos kedvezménykuponok. Promóciós kuponjaink vannak, de élő promóció az átálláskor nem lesz; az elérhető promóciós mechanizmusokat kérjük az ajánlatban részletezni.

L2-32 Működtet a Társaság affiliate programot, és része-e a 2. résznek?

Nem működtetünk affiliate programot.

2.7 Marketplace-ek

L2-33 Mely marketplace-eken van aktív fiók; meglévő működés átvétele vagy új csatornák építése; ki végzi a feltöltést és a napi kezelést; milyen middleware fut ma?

Jelenleg nincs élő marketplace-csatornánk; mindhárom (eMAG, Temu, Allegro) új csatorna felépítését jelenti, amellyel megvárjuk a tender lezárását. Az eMAG-csatlakozás képessége elvárás és az ajánlatban árazandó (C.4, 7. sor), de nem az induláshoz; az Allegro és a Temu a stabil indulás után következik --- mindhárom Allegro-oldallal (hu/cz/sk) és mindhárom országra vonatkozó Temu-programmal kérjük számolni, marketplace-enként az útvonal és az ár megadásával. Munkamegosztás: 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ást és kiszállítást a fulfillment-partner (kivéve bolti készletből működő csatornák, mint a Wolt, amely a tender hatókörén kívül esik). Ma BaseLinker middleware-t használunk feed-alapon; ez lecserélhető, ha natív integráció elérhető --- előny, ha minél több marketplace-hez natívan tudunk kapcsolódni. Az adatkapcsolat (termék-, ár- és készletszinkron, rendelés-beolvasás) és az induló termékfeltöltés/kategória-megfeleltetés technikai támogatása az ajánlattevő feladata.

L2-34 Marketplace-számlázás: a marketplace vagy a platform állítja ki a vevői számlát?

Egyes esetekben (pl. Allegro) a platformnak kell kiállítania a számlát, amelyet a marketplace továbbít --- ez a képesség elvárás.

L2-35 Kell-e a marketplace-készletet közel valós időben frissíteni?

Igen.

2.8 Marketing, analitika, e-mail

L2-36 Mailchimp: mely funkciók vannak használatban, hány feliratkozó piaconként; elfogadható-e beépített hírlevélmotor a Mailchimp helyett? Mi lesz a jelenleg futó feliratkozó/pop-up eszközzel (SALESmanago)?

Ma a Mailchimp funkcióinak csak kis részét használjuk, de ezt bővíteni kívánjuk. A Társaság évek óta a Mailchimpet használja, jelentős adat- és kampány-know-how-val; ezért a platformnak képesnek kell lennie a teljes Mailchimp-integrációra (audience-szinkron, e-commerce események, kosárelhagyás, szegmentációs adatok) arra az esetre, ha a Társaság a Mailchimp megtartása mellett dönt. Az ajánlattevő ezen felül bemutathatja és külön árazhatja saját e-mail-marketing megoldását. Feliratkozók ma: kb. 40 000 (HU), 27 000 (CZ), 4 000 (SK). A SALESmanago-hoz nem kötődünk, nem használjuk aktívan; kivezethető --- a feliratkozás- és pop-up-funkciót a platform marketing-eszközei (5.1.7) váltják ki.

L2-37 Milyen kampánytípusokat futtat a marketing; adhatók példák a demóhoz?

Online kommunikációs eszköztárunk jelenleg meglehetősen korlátozott, de bővíteni kívánjuk. Bannerek, pop-upok, kategória-merchandising és landing oldalak biztosan szerepelni fognak a jövőbeni kampányokban. Kérjük az ajánlattevőket, hogy az ezen a téren elérhető megoldásaikat mutassák be.

L2-38 Létezik GA4-property és Google Ads / Meta fiókstruktúra; van preferált consent-kezelő?

GA4-property és Google Ads / Meta fiókok léteznek, ezeket kell bekötni (a fiókstruktúrát a marketing-csapat pontosítja); 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ó; konkrét eszközt nem írunk elő.

L2-39 Keresés: van szinonimalista vagy problémás kifejezések listája; hány keresés van havonta?

Szinonima- vagy problémás-kifejezés-lista ma nincs, és az oldalon belüli keresések száma nem mért: a jelenlegi analitikai beállítás a webáruház keresési paraméterét nem rögzíti, így megbízható havi szám nem adható. Mindkettőt az új platformon kell felépíteni --- a keresési analitika (volumen, leggyakoribb és találat nélküli kifejezések) az 5.1.4 szerinti mérési alap része, a szinonimalistát a Társaság webshop-csapata a platform keresőeszközeiben tartja karban (5.1.7).

2.9 Support, üzemeltetés, átvétel

L2-40 Milyen support-időablakot, rendelkezésre állást, reakció- és helyreállítási időt várunk; mekkora fejlesztési kapacitást tervezzünk; milyen nyelven?

Az átállás intenzív időszakát leszámítva standard munkaidős (CET, hétfő--péntek) support-ablakot várunk; munkaidőn kívüli vagy szezonális ügyelet nem elvárás. Rendelkezésre állási vállalást, reakció- és helyreállítási időt súlyosság szerint az ajánlattevő adja meg (5.3). Lekötött havi fejlesztési kapacitás nem elvárás: a cél, hogy az alapvető változtatásokat a csapat házon belül végezze a kezdő funkciókészlet gazdagságára támaszkodva; az eseti fejlesztéseket megbízás alapján, óra- vagy napidíjon árazzák. Nyelvek: magyar és angol (a cseh csapat számára a cseh előny).

L2-41 Hány felhasználónak kell hozzáférés, milyen szerepkörökkel és oktatással?

Jelenleg piaconkénti jogosultság-szétválasztás létezik, ennél szofisztikáltabbra nincs igényünk, potenciálisan a pénzügy kivételével. Felhasználóink: 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). Kérjük, legalább 15 névre szóló felhasználóval számoljanak; ha az árazás felhasználószám-függő, ezt a C.4-ben jelezzék. Oktatás: legfeljebb egy központi, angol nyelvű oktatás után a többit házon belül intézzük, az online dokumentáció részletességétől függően.

L2-42 Vannak számszerű átvételi feltételek (teljesítmény, Core Web Vitals, akadálymentesség, mérési lefedettség); ki végzi az üzleti átvételt?

Számszerű átvételi küszöböket a felhívás nem rögzít; kérjük, az ajánlatban tegyenek javaslatot (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 Társaság webshop-csapata végzi és hagyja jóvá, a CZ/SK piacokat a cseh csapat bevonásával, az ajánlattevő által biztosított tesztforgatókönyvek alapján.

2.10 Design és storefront

L2-43 A butlers.com sablonjának mely verziója, egyedi módosításai és komponensei kerülnek átadásra; mely funkciók támaszkodnak külön appra; elérhető-e a márkatulajdonos design-nyelve nem-Shopify ajánlatokhoz?

Átadásra kerül a butlers.com teljes téma-exportja (2026-08-05-i állapot): Sleek téma (FoxEcom) 2.0.0 verzió, Modiva preset, Shopify Online Store 2.0 (JSON-sablonok, theme block-ok), a márkatulajdonos testreszabásaival együtt: egyedi section-ök (elállási űrlap, mátrix-kapcsolatfelvételi űrlap), 9 egyedi theme block (termékkereső kvíz, Stilfinder, bento-rácsok, kollekció-kártyák és -slider, rich-text oszlopok), custom.js/custom.css, mintegy 30 oldal- és terméksablon, valamint metamező-alapú tartalmak (termékbiztonsági/GPSR adatok, szállítási idő, SEO-szövegek, breadcrumb). A téma egyszeri licencét (kb. 350 USD/áruház) a magyar áruházra meg kell vásárolni. Külön appra vagy külső rendszerre támaszkodó funkciók, amelyek NEM kerülnek átadásra: e-mail/SMS marketing és feliratkozó űrlapok (Klaviyo), cookie-consent (Pandectes GDPR), teljesítmény-optimalizálás (Speed Kit), termékértékelések (Loox), üzletkereső (Stockist widget) --- ezek funkcióit az ajánlattevő által javasolt, a felhívásnak megfelelő eszközök váltják ki, külön árazva. Minden más --- mega menü, quick view, lookbook, csomagajánlatok, visszaszámláló, pop-up, kedvencek, előrejelző keresés, ajándékcsomagolás --- a téma natív funkciója. A téma a HU/CS/SK storefront-fordításokat tartalmazza (kb. 97%-os lefedettség). A téma-export a shortlistre került ajánlattevők számára a titoktartási nyilatkozat alapján elérhető, és nem-Shopify ajánlatok esetén is ez a facelift design-referenciája (section-könyvtárral és oldalsablonokkal); formális brand guideline vagy Figma-anyag jelenleg nem áll rendelkezésre.

L2-44 Mely oldalak tartoznak a facelift hatókörébe; ki hagyja jóvá a designt?

Általános facelift-ként értelmezzük (minden fő sablon). Az új designt a marketing-csapat hagyja jóvá.

L2-45 Push-értesítések: milyen felhasználási esetek és milyen gyakorisággal?

Elsősorban promóciók. A push-képesség érdeklődésre számot tartó lehetőség, nem kötelező követelmény --- az ajánlás és az indikatív költség számít (5.1.8).

2.11 Kereskedelmi feltételek és eljárás

L2-46 HUF vagy EUR árazás; melyik MNB-árfolyam az összehasonlítás alapja?

Lásd G-04.

L2-47 Hároméves futamidő éves indexálással a referenciaeset; elvárt-e az első évi árrögzítés?

A Társaság nem ír elő futamidőt vagy árrögzítést: javasolják a futamidőt, az indexálási mechanizmust és az esetleges rögzítési időszakot a feltételeikkel együtt. A szerződéses rugalmasság és a kilépési feltételek értékelési szempontok; az összehasonlítás 3 éves TCO-alapon történik. (Az 1. részre ugyanez vonatkozik --- lásd L1-06.)

L2-48 A válaszok a kérdésekkel együtt, anonimizálva kerülnek körbeküldésre?

Igen --- lásd G-06.

L2-49 Mikor és milyen formában zajlanak a shortlist-prezentációk és az admin-demó?

Október negyedik hetében, illetve november első hetében szeretnénk az összes prezentációt megtartani; ennek ismeretében egyeztetünk online vagy személyes időpontokat.

Kapcsolat minden kérdésben: Dobó Krisztián (krisz@butlers.hu) és Scharbert Edina (edina.scharbert@butlers.hu).