888wholesale

Kiindulás

A 888wholesale B2B ruházati nagykereskedés és saját márkás ruhagyártás. A 888Studios Kft. vállalkozása, amelyet társalapítóként építettünk fel, és ma is mi üzemeltetünk. Az oldal 2026 júniusa óta fut élesben a 888wholesale.co címen.

Két üzletága két különböző vevőt szolgál ki. A streetwear-nagykereskedés viszonteladóknak, webshopoknak, márkáknak és forgalmazóknak gyárt és értékesít, fazononként 100 darabtól. A vállalati ellátás egyenruhát, munkaruhát és láthatósági ruházatot szállít, szerződésenként 300–5000 darabot. A nagykereskedelmi termékkatalógus mindenkinek nyitva áll, az árat viszont csak a bejelentkezett vevő látja.

A két vevő máshogy keres, és máshogy dönt. A viszonteladó a minimális rendelési mennyiséget és az egységárat hasonlítja össze, és akár aznap rendel. Egy facility management cég vagy egy gyár beszerzője 3–9 hónapos pályázati ciklusban gondolkodik, és azt nézi, ki tudja évekig ellátni a dolgozóit. Egy egyszerű webshop csak az első vevőnek elég.

A harmadik szereplő a gyár. A partnergyárak a gyártási sorrendet és a szállítást látják, az árakat nem. Nekik saját portál kellett.

A platform egy olyan szolgáltatást is kiszolgál, amelyet ritkán kínál ruházati beszállító: a konszignációs raktározást. A 888 tartja a vevő biztonsági készletét, és a lehívott mennyiséget 24–48 órán belül kiszállítja. A keresőben erre alig van versenytárs, ezért ez kapta a legnagyobb súlyt a növekedési tervünkben: saját oldalt, saját kulcsszócsoportot és saját szoftvert.

A rendszer felépítése

A nyilvános oldal angolul és magyarul fut, és mögötte négy belső felület dolgozik ugyanabból az adatbázisból.

Felület	Kinek szól	Terjedelem
Nyilvános oldal	látogatók és keresők	49 oldal, közülük 19 magyarul
Ügyfélportál	viszonteladók és vállalati vevők	37 oldal
Admin	a 888 munkatársai	81 oldal
Gyártói portál	partnergyárak	2 oldal
888 WMS	a vevő raktára és a gyár	Windows-alkalmazás

A kód Next.js 16-on fut, az adatbázis Postgres, amelyet Prismával kezelünk. A rendeléstől a raktári mozgásig 88 adatmodell és 55 felsorolás írja le a céget. A fizetést a Stripe, a számlát a Számlázz.hu, a leveleket a Resend intézi. A fájlok hét tárolóban vannak, közülük négy privát, és ezekből egy fájl csak a szerveren át, aláírt linken nyílik meg.

A jogosultságot több réteg ellenőrzi, egymástól függetlenül. A peremen futó első szűrő után minden oldal újra lekérdezi a felhasználó szerepét az adatbázisból, a szerveroldali műveletek pedig a vevőt mindig az adatbázisból azonosítják, soha a böngésző által küldött adatból. Az adatbázis sorszintű védelme minden táblán be van kapcsolva, így az automatikusan generált REST-felület kívülről semmit nem ad vissza.

A nehezebbik fele

Ebben a részben azok a megoldások szerepelnek, amelyeken a legtöbb munka volt, és amelyektől a rendszer üzemeltethető.

Számla a fizetés állapotából

Magyarországon a pénzmozgás és a számla két külön világ. A pénzt a Stripe mozgatja, a NAV felé bejelentett számlát a Számlázz.hu állítja ki, és a kettőnek minden helyzetben egyeznie kell. Erre egy állapotgépet írtunk.

1. Visszaigazoláskor pontosan egy dokumentum készül. Halasztott fizetésnél normál számla, előre fizetésnél díjbekérő.
2. Az 50 százalékos előlegre előlegszámla jár. A végszámla automatikusan levonja az előleget, és az összeget a kiállított számlák nyilvántartásából számolja.
3. Visszatérítéskor sztornó vagy helyesbítő számla készül. Teljes visszatérítésnél sztornó, részlegesnél helyesbítő.
4. Egy előleget soha nem számlázunk kétszer. Ha egy rendeléshez már van előlegszámla, a normál számla automatikusan végszámlává válik.

Az áfakulcs a vevőhöz igazodik. Belföldön 27 százalék, uniós cégnek fordított adózás jár az EU-s adószámával, amelyet a VIES rendszerében ellenőrzünk, harmadik országba pedig exportszámla megy. Az euróban kiállított számla az MNB napi árfolyamával számol. Fizetni kártyával, átutalással és Magyarországon készpénzzel is lehet, és mindhárom ugyanabba az egyenlegbe fut.

A fizetendő összeget mindig a szerver számolja. Ha a számlázás valamiért nem sikerül, a fizetés ettől nem akad el. A rendelés megjegyzésébe ilyenkor dátumozott figyelmeztetés kerül, és az admin pótolja a számlát. A Stripe értesítéseit eseményazonosító szerint naplózzuk, így egy kétszer megérkező értesítés sem könyvel kétszer.

Készlet több raktárban, egy API-n

A vevők és a partnergyárak raktárai egy 24 végpontos valós idejű készletkezelő API-n kapcsolódnak a platformhoz. Úgy terveztük, hogy egy hibás vagy kétszer elküldött kérés se ronthassa el a készletet.

• Minden író kérés egy raktárhoz kötött, 24 óráig érvényes ismétlésvédelmi kulcsot visz, így egy hálózati hiba utáni újraküldés nem könyvel duplán.
• Ha egy kérésben ugyanaz a cikkszám többször szerepel, a változásokat írás előtt összeadjuk, ezért a készlet nem mehet mínuszba.
• Az áruátvétel elutasítja az ismeretlen vagy kétszer szereplő cikkszámot.
• Minden készletmozgás megjelöli a terméket, és a riasztásokat egyetlen ellenőrző folyamat kezeli. Ezt egy júniusi hiba után egységesítettük.
• A partnereknek küldött értesítések HMAC-aláírást kapnak. Küldés előtt a rendszer a feloldott IP-címet is megnézi, és belső hálózati címre nem küld, akkor sem, ha a domain csak a kapcsolódás pillanatában fordul át oda.

Kétféle tárolás létezik. Ha a készlet a vevőnél van, a fogyás gyártást indít, ha a 888 tárolja, lehívást. A kiszállított rendelés egy tranzakcióban jóváírja a vevő készletét és levonja a központi készletből, egy egyszer használható jelzővel, hogy egy újbóli kiszállítás se írjon jóvá kétszer.

Előrejelzés, amelyből gyártási rendelés lesz

A beszerzési előrejelzés az előző teljes félév eladásaiból, kiadásaiból és selejtjéből számolja a keresletet. A fedezet a vevő saját készletének, a 888 központi készletének és az úton lévő szállítmányoknak az összege. Ha a fedezet egy hónapnyi fogyás alá esik (a határ beállítható), a rendszer negyedéves és féléves javaslatot készít a minimális gyártási mennyiségre kerekítve, és jelzi, mennyire friss adatból számolt.

A javaslatot a vevő cégvezetője hagyja jóvá, és ebből lesz a gyártási rendelés vagy a lehívás. Amikor a készlet helyreáll, a kör magától bezárul. Egy raktárszintű adatbázis-zár megakadályozza, hogy két párhuzamos futás dupla javaslatot írjon, egy feltételes frissítés pedig azt, hogy egy javaslatot kétszer hagyjanak jóvá.

A gyárak saját portálja

A partnergyár egy munkalistát lát, amelyben csak a kifizetett rendelések szerepelnek, előleggel vagy teljes összeggel, árak nélkül. Minden tételt maga léptet tovább: megrendelve, gyártásban, legyártva, elküldve. A szállításhoz szállítási értesítőt indít. Az admin A4-es raklapcímkét nyomtat a szállítmány QR-kódjával, a vevő a raktárban beolvassa a WMS-ben, és a jóváírás meg az eltérés egy lépésben rögzül.

888 WMS: Windows-alkalmazás a vevő raktárában

A 888 WMS telepíthető raktárkezelő a vevőknek és a gyáraknak. 2026 júniusában Electronról Tauri 2-re költöztettük, a háttere Rustban íródott, a felülete React. Június 10. és július 1. között 12 verziót adtunk ki, az 1.1.0-tól az 1.3.3-ig.

• Minden hálózati hívás a Rust oldalon fut, egyetlen közös klienssel, így a böngésző korlátai nem érvényesek rá.
• A háttérben is figyel. Fókuszban percenként, a tálcán ötpercenként kérdez le, hibánál egyre ritkábban, és csak az újonnan kritikussá vált cikkszámokról küld értesítést.
• A gépet és a belépést is azonosítja. Minden kérés viszi a gép ujjlenyomatát, amely az operációs rendszer gépazonosítójából és egy fordításkor beégetett titokból képzett SHA-256. A kérést egy belépésenként kapott titok HMAC-aláírja, és ezt a titkot a Windows DPAPI őrzi. A gépek nyilvántartásban vannak, a számuk korlátozható.
• A frissítés kötelező és aláírt. A program telepítés előtt ellenőrzi a frissítés aláírását. Ha a frissítési szerver 8 másodpercen belül nem válaszol, a régi verzió indul el, így egy kiesés soha nem teszi használhatatlanná.
• Kapcsolat nélkül is dolgozik. A közben rögzített mozgásokat titkosítva sorba állítja, és amint van hálózat, egyszer, ismétlésvédelmi kulccsal küldi el.

A felület a szerephez igazodik. A cégvezető 10 fület lát, a raktári dolgozó kettőt, a gyár egyet.

Két nyelv, amely nem rontja a keresést

A magyar oldalak egy külön /hu mappában élnek, nyelvi útvonalszegmens és nyelvi köztes réteg nélkül. A nyilvános oldal nyelvét az URL dönti el, így az oldalak statikusak maradnak. A portál nyelve sütiből jön, de egy hamisíthatatlan fejléc mögött, így egy magyar portálbeállítás soha nem kerülhet egy angol oldal gyorsítótárába.

A termékek fordítása mezőnként visszaesik az angolra, és soronként kapcsolható. Egy termék csak akkor kap magyar oldalt, hreflangot és sitemap-sort, ha a fordítása elkészült. Minden buildnél négy ellenőrzés fut:

1. A kulcsok és a helyőrzők egyeznek a két nyelvben.
2. Egy szkript minden magyar oldalt összevet az angol párjával, és jelzi, ha angol szöveg maradt benne.
3. Egy statikus vizsgálat megtalálja a kódba égetett szövegeket.
4. A nyelvi linkek a saját nyelvükre mutatnak.

Nyelvenként 2121 szövegkulcs van. Az angolról fordított vásárlói vélemények mellett ott áll, hogy „Angolról fordítva”.

Ár, amelyet csak a vevő és a Google lát

A nagykereskedelmi ár csak bejelentkezett vevőnek jelenik meg, egy vendég oldalának HTML-jében egyáltalán nincs benne. A Google robotja viszont látja. A robotot a böngészőazonosítója mellett fordított és visszaigazolt DNS-lekérdezéssel ellenőrizzük, és az eredményt egy órára megjegyezzük. A strukturált adat jelzi, hogy az oldal egy része regisztrációhoz kötött, és megadja, melyik része. A Google zárt tartalomra pontosan ezt a mintát írja le, így ez nem számít álcázásnak. Az ár sávja data-nosnippet jelzést kap, hogy a találati listában se jelenjen meg.

Így lesz a keresésből rendelés

Minden URL egy keresőkifejezést céloz. A nyilvános oldal egy elosztóból és két üzletági központból áll, alattuk a témák oldalai. Az egymással versengő oldalakat egy külön körben szétválasztottuk, a címeket és a főcímeket a vevők szavaihoz igazítottuk.

A cég egyetlen entitás. A schema.org-leírás 52 típust használ egyetlen modulból, és minden entitásnak egy azonosítója van az egész oldalon, amit egy buildkori szkript ellenőriz. A név, a cím és a telefonszám egyetlen forrásból jön, és egyezik a hitelesített Google Cégprofillal. A közösségi profilok listájából kivettük azokat, amelyek nem léteztek.

A Google gyorsan értesül. A sitemap minden sorában hreflang van, a dátumokat a git-előzményből vesszük, mentéskor IndexNow-jelzés megy, naponta pedig újraküldés. Az llms.txt és az llms-full.txt a nyelvi modelleknek írja le a céget.

A belépés nem akadály. A regisztráció azonnali. A nyitóoldal fő gombja a mintarendelés, és konzultációt belépés nélkül is lehet foglalni. Az elrejtett ár helyén a mintarendelés és a mennyiségi kedvezmény táblázata kínálkozik.

A kedvezmény őszintén számol. A mennyiségi lépcső 250, 500 és 1000 darabnál 5, 10 és 15 százalék. A pénztár előtti ajánlat az egységár csökkenését és a végösszeg növekedését egyszerre mutatja, és soha nem írja azt, hogy a vevő spórol. A hűségprogram nyolc szintje közül a legfelső saját árcsoportot kap.

Minden érdeklődés a CRM-be kerül. Egy új érdeklődő e-mail-cím, majd cégnév és domain szerint összevonva kerül a beépített CRM-be, egy új üzlettel és egy másnapi teendővel. Az első érintés forrása (UTM, hivatkozó oldal, érkezési oldal) ott marad a vevőn, az ajánlatkérésen, a konzultáción és a mintarendelésen is. A Google Analytics csak hozzájárulás után tölt be.

Az ütemezett folyamatok visszahozzák a vevőt. A 12 ütemezett folyamat emlékeztet a konzultációra és a fizetendő egyenlegre, visszahívja az elhagyott kosarat, értékelést kér, és újraindítja az állandó rendeléseket. Automatikus hírlevelet nem küldünk, és új automatizmust is csak külön döntés után indítunk.

Egy nagykereskedelmi platform akkor bírja a növekedést, ha a gyártási javaslattól a végszámláig minden lépés ugyanabból az adatból dolgozik.

Amit ebből Önnek érdemes tudni

Ha az Ön cégénél a rendelés, a számla és a készlet külön programban él, és a kettő között valaki kézzel másol, egy ilyen rendszer ezt a munkát kiváltja. Az egyedi szoftverfejlesztésről külön oldalon írunk, a munka menetéről pedig az Így dolgozunk oldalon.