Pólónagyker

A Pólónagyker Magyarország egyik ismert reklámtextil-nagykereskedése. A webshopjukat és a mögötte futó rendszert a Milcomp építette, a korábbi tees.hu márkanévről 2026 nyarán váltottak a polonagyker.hu-ra.

A kihívás

Egy reklámtextiles nagyker nem hagyományos webshop. Ugyanaz a póló létezik többféle méretben és színben, az árat pedig nem a termék határozza meg, hanem az, hogy ki vásárol és mennyit: más árat lát a kiskereskedő, mást a nagyker, és mást az, aki nagy tételben rendel. Ehhez jön, hogy a megrendelések jelentős része nem sima vásárlás, hanem hímzett vagy nyomott logóval készül, tehát a rendeléshez tartozik egy grafikai fájl és egy egyeztetési kör is.

A régi rendszer egy Ruby on Rails alapú shop volt, ami már nem tudta kiszolgálni ezt a működést, és a márkaváltás sem oldható meg egy domain átirányításával, ha az egész terméktörzs URL-jei megváltoznak.

A megoldás

Laravel alapokon építettünk új webshopot, Laravel Nova adminfelülettel. A terméktörzs háromszintű: alaptermék, termék és termékváltozat, méret- és színattribútumokkal, hogy egy pólócsalád ne ezer külön termékként létezzen. Az árazás többsávos, és a sávok raktárkészlethez, pénznemhez és vevőtípushoz kötöttek.

A logós rendelésekhez saját beküldőfelület tartozik: az ügyfél feltölti a grafikát, megadja a technológiát, az elhelyezést, a darabszámot és a határidőt, a beérkezett anyagok pedig védett letöltési linken keresztül jutnak el az adminhoz. Az utánrendelés külön jelölést kap, mert ott a grafika már megvan.

Partner API és AI-asszisztens

A viszonteladók nem kattintgatni akarnak, hanem szinkronizálni. Ezért a shop mellé partner REST API került: terméktörzs, változatok, készlet, kategóriák és márkák. A kulcs itt az, hogy minden API-partnerhez tartozik egy saját kulcs, egy percenkénti hívási limit, egy nyelv, és egy rögzített árszint - a partner az API-n át pontosan azt az árat kapja, amit szerződés szerint kapnia kell, és nem tud átnézni a másik sávba. Az API-kulcsokat a partner a saját profilján kezeli.

Az oldalon AI-asszisztens is fut, amely kizárólag a webshop saját tudásbázisából dolgozik: vektoros keresés a feltöltött dokumentumokon, és olyan rendszerutasítás, amely tiltja a témán kívüli válaszokat és a kitalálást. Ha valamit nem tud, azt mondja, nem pedig kitalálja.

Technológia

Laravel és Laravel Nova, Livewire-rel épített interaktív felületekkel, Tailwind alapú frontenddel. Többnyelvű tartalom és több pénznem, a euróár napi MNB-árfolyamból számolva, háromlépcsős visszaeséssel arra az esetre, ha az árfolyamszolgáltatás nem elérhető. Tranzakciós e-mailek MJML sablonokból, hibafigyelés Sentryvel, tömeges termékimport és -export Excelből és CSV-ből.

A márkaváltás, ami nem tört el

A tees.hu-ról polonagyker.hu-ra váltás azért nehéz, mert a régi shop terméklinkjei éltek: külső oldalak, hirdetések és mentett könyvjelzők mutattak rájuk. Ezért a régi terméklistát végigpárosítottuk az újjal, és 440 tételes Cloudflare Bulk Redirect került az él elé: statikus oldalak, 427 ellenőrzött termékpár, és útvonal-szintű tartalék arra, ami egyedileg nem volt párosítható. A párosítás nem gépi tipp volt: a régi shopból kiolvasott slugokból egzakt transzformációval és kézzel mintavételezett közelítéssel állt össze a lista.

Ugyanezért maradt a szerveren a régi webroot-, adatbázis- és CDN-név, és ezért nevet kapott át a meglévő Jenkins-job ahelyett, hogy újat hoztunk volna létre: egy márkaváltás során a legrosszabb, amit tehetsz, hogy az infrastruktúrát is átnevezed, és utána nem tudod, mi hova épült.

Amit ebből érdemes elvinni

A többsávos árazásnál a döntő kérdés nem az, hogy hogyan tárolod az árakat, hanem hogy ki melyiket láthatja - és ezt az API-n is ugyanúgy kell érvényesíteni, mint a webshopban. Ha a partner az API-n át tetszőleges ármezőt kérhetne le, a teljes árazási struktúrád nyilvános.

A migrációnál pedig: a 301-ek minősége az, ami eldönti, hogy egy márkaváltás megtartja-e az organikus forgalmat. Egy globális átirányítás a főoldalra formálisan működik, gyakorlatilag mindent eldob.