Arch - bolt IV mód­ra?

Az elmúlt 10 évben jó pár webáruház projekten dolgoztam. Az egyik első Drupal projektem is egy nyíregyházi, borárusítással foglalkozó üzlet webáruháza volt. Aztán amikor Debrecenben a ShopRenteren kezdtem dolgozni, hirtelen több ezer magyar vállalkozás e-kereskedelemmel kapcsolatos elképzeléseire és igényeire kaptam rálátást. Később még volt egy Magentós projektem, mielőtt az IV-be sodortak a szelek. Amikor először beszélgettünk, azt kértem PP-től és Kulcsitól, hogy ha egy mód van rá, e-kereskedelemmel most egy darabig nem szeretnék foglalkozni.

Akkoriban az a kép alakult ki bennem, hogy a magyar jog- és adószabályok rapid változásai, együtt a magyar kiskereskedelemben tapasztalható marketing stratégiákkal és sokszor teljesen ad-hoc-nak tűnő árképzéssel egy olyan problématér, amit az elérhető nyílt forrású megoldásokkal én képtelen vagyok összeegyeztetni.

Két példát szeretnék felemlegetni, amik szerintem jól illusztrálják ezen projektek komplexitását.

Árkezelés: A termékeket bruttó beszerzési árral szeretném Excelből importálni, amiből számoljon a rendszer nettó listaárat, és a három vevőcsoportomnak külön-külön kedvezményt jelenítsen meg. De ha “csúnya” az ár (értsd 97 forint 56 fillérre jön ki) akkor szeretném felületről átírni az értéket. A rendeléskor az ERP-be és a számlázórendszerbe fillérre pontosan menjen át a listaár, a kedvezmény mértéke és az eladási ár is. Ja, és bármikor változhatnak az ÁFA szabályok. És EU-n kívülre is szeretnék értékesíteni az aktuális euró vagy USD árfolyamon.

Raktárkészlet: A cégnek több telephelye van, különböző méretű raktárakkal. Van olyan termékem, ami csak az egyikben szokott lenni, van, ami mindegyikben. Van olyan raktáram, ami kizárólag kiskereskedelmi forgalmat szolgál ki, van olyan, ami csak a nagyker partnerekkel áll kapcsolatban, de a központi raktár bármilyen rendelést fogad. A vásárló számára rejtsük el azt az információt, hogy melyik raktárban mekkora készlet van, csak egy összdarabszámot mutassunk, annyit, amennyihez a számára hozzáférhető raktárakon keresztül hozzáfér. Jó lenne, ha vásárlói csoportonként más-más raktárprioritást tudnánk kezelni.

Egy ideig mások is osztoztak az ellenérzéseimen, de egy idő után be kellett lássuk, be kellett lássam, hogy csapatként igenis lehet érték abban, hogy megküzdjünk egy ilyen projekttel is.

Először természetesen elővettük a Drupal ökosziszémában de facto szabványnak számító Commerce-t és a millió kapcsolódó projektet. Egy darabig tudtuk kezelni a komplexitást, de mindig eljött a pont, amikor a rengeteg contrib modul valahogy úgy kezdett el működni, hogy napokig tartó nyomozások árán tudtuk csak kibogozni, mi is okozza a problémát.

Aztán a D8 váltással azzal szembesültünk, hogy nincs stabil Commerce modul. De a következő időszakra szánt két húzóprojektnek fontos eleme volt a működő terméklistázó és rendeléskezelő rendszer. Így párhuzamosan két projekten lecsupaszítottuk a problémákat: a termékeket tartalomként (node) kezeljük, az árakat és a raktárkészletet egy ERP-ből szinkronizáljuk, a kosár tartalmát sessionben tároljuk, a checkout folyamat pedig egy nagy Drupal form, aminek a végén létrehozunk egy egyedi Order entitást és azon melegében írjuk is vissza az ERP API-ra.

A két projektet megoldottuk, teszik a dolgukat, de azért mind éreztük, hogy a megoldás mégis csak egy patchwork. 

Aztán, amikor bejött a Stageshop, gondoltam egyet, és a két korábbi megoldásból az alap funkcionalitást belapátoltam egy különálló, belső használatra szánt modulba. 

A fejlesztés elején azt tűztem ki célként, hogy az alapfunkciók listája a lehető legrövidebb legyen, de minden olyan problémára adjon egy alapmegoldást, amikkel korábban küzdöttünk.

Az volt az elképzelésem, hogy lehessen több árat megadni egy termékhez, több raktárkészletet és termékváltozatot kezelni, illetve egyedi checkout űrlapot összerakni.

Az alábbiakban bemutatom röviden, hogy miként valósultak meg ezek a szempontok.

Egy termék, több ár

Ahhoz, hogy a több ár problémát kezelni tudjuk, először végig kellett gondolni, hogy jellemzően milyen dimenziók befolyásolják egy termék árát. A korábbi tapasztalatok alapján arra jutottunk, hogy a nettó/bruttó és a pénznem mellett szükséges az ÁFA kategóriát is rögzíteni egy-egy árhoz, valamint, hogy mi az az időszak, amikor alkalmazható az adott ár. Ezekből a dimenziókból pedig kirajzolódott egy új fogalom, ez lett az ártípus. Egy ártípussal ezeket az adatokat lehet előre definiálni. Ezen kívül erre a kategorizálásra építettünk egy jogosultságkezelést is. Így a Drupal jogosultságrendszerén keresztül be tudom azt állítani, hogy a nagykereskedők a nagyker árat láthatják, míg a többi felhasználó a kisker árat. Az időszaklimitáció segítségével akár előre, másodperc pontosan lehet időzíteni leárazásokat is.

Az áfakulcs változását pedig úgy tudom lekövetni, hogy az ártípusnál átírom az értéket, és onnantól a rendszer ezzel kalkulál nettó árból bruttót és vice versa. 

Raktárkészlet

A több raktárkészlet kezelése a nagyobb kereskedelmi vállalkozások számára lehet praktikus. Akinek erre a funkcióra szüksége van, annak – tapasztalatunk szerint – már van valamilyen ERP rendszere használatban, ahol követi, kezeli a raktárkészlet változását. A raktárak készletének szabályozását az ártípushoz hasonlóan a Drupal jogosultsági rendszerével oldottuk meg.

Termékcsoportok, termékváltozatok

Talán a legtöbbet a pólóboltot emlegetjük, amikor a termékváltozatok kezelésének szükségessége kerül szóba. Egy pólónak lehet mérete, színe, mintája. A terméklistában csak a minták alapján szeretném látni a termékeket, de szeretném hagyni a vásárlónak, hogy kiválaszthassa, hogy melyik színt szeretné és milyen méretben. Erre mi bevezettük a Termékcsoport fogalmát, aminek van egy Vezérterméke, ami megjelenik a listákban. A termékoldalon pedig megjelenítünk egy változatválasztó mátrixot, aminek segítségével lehet a csoport egyes termékei között navigálni. 

Checkout projektre szabása

Dobozos megoldások használata esetén az volt a tapasztalatunk, hogy ez az a rész, amire hatványozottan igaz, hogy egészen addig nincs probléma, amíg nem szeretnénk eltérni a szállított működéstől. Amint komplexebb szállításiár-kalkulációra van szükség, vagy olyan összefüggéseket kell kezelni, hogy melyik országba, melyik logisztikai partnerrel küldünk csomagot, akkor a fejlesztés komplexitása azonnal megugrik.

Üzletileg teljesen érthető döntés, ha egy kereskedő más-más futárcéggel szeretné bonyolítani a szállítást magyarországi címekre, az EU-n belül és az EU-n kívül. Vagy ha bizonyos termékcsoportok, vagy adott kosárérték alatt nem szeretné engedélyezni az utánvétes fizetést.

Ezeket figyelembe véve egy olyan megoldás felé vittük a fejlesztést, ahol kinyitjuk a fejleszők számára a lehetőséget, hogy olyan checkout folyamatot és űrlapot építsenek, amilyet az adott projekt megkíván.

Bár a projekt tartalmaz egy one page checkout megoldást külön modulként, az elképzelés az volt, hogy ezt az egész problémát nem szeretnénk előre megoldani.

Így itt azt az utat választottuk, hogy a fejlesztők definiálhatnak egy CheckoutType plugint, amivel együtt létrehozhatnak egy űrlapot, amit úgy épít fel mindenki, ahogy az adott projekt éppen megkívánja. Így teljes a szabadság a megjelenítési, validálási és a rendelés rögzítése körüli teendőkre vonatkozóan.

De miért Arch?

A belső használatra szánt moduljaink nevét általában prefixeljük az IV előtaggal. Így amikor az első változatot el kellett nevezni rutinszerűen írtam le, hogy IV Bolt. Mindenféle szóvicceken és vicces képeken edződött (köszi Nevergone) elmém, gyorsan kapcsolt, hogy ha ezt a két szót megcseréljük, azt kapjuk, hogy boltív. Az meg angolul Arch. Hát így lett a Chocapic.

És, hogy miért is ez a hosszú írás erről a projektről? Kis gondolkodás után arra jutottunk, hogy mivel a sok contrib modul formájában már mi is sokat kaptunk a közösségtől, visszaosztjuk a saját eredményeinknek legalább egy kis részét. Így az Arch projektet Drupal.org-on publikáltuk pár napja. Nem titok, hogy ez egyúttal egy felszólítás keringőre: ha van visszajelzésed, tanácsod, ötleted, vagy úgy gondolod, hogy van még alap funkció, amire nem gondoltunk, vagy írnál egy-két tesztet az elkészült kódhoz, minden segítséget szívesen fogadunk.