A rendelésszinkron esetében a weboldalunkra leadott rendelésekről beszélünk, amikor is a felhasználó lead egy igényt, amely a webshopból az ERP-nkbe kerül a termékek és készletek szinkronizálásával összhangban.
Mi mindenre keressük a választ?
- Ismerjük a saját rendszerünket?
- Tudjuk, hogy hogyan áramlanak a megrendelések és a készletek adatai rendszereinkben?
- Mindig tiszta és egyértelmű logikák mentén épülnek fel az adatcsomagjaink?
- Szinkronban működnek rendszereink, azonos paraméterezés mentén?
- Kampány időszakban is bírja a terhelést és elosztást a rendszerünk?
- Esetleg szükség lenne szabályozókra, kiigazítókra?
Ez a néhány kérdés mindössze töredéke azoknak a felvetéseknek, amelyekre pontos választ kell tudnunk adni, igaz nem magunktól, hanem e-kereskedelmi szakértőkkel közösen működve. Ennek legegyszerűbb és legjobb módja egy már bevált módszer alkalmazása, amely az OANDER Connect központi hubra csatlakoztatott webáruház és ERP rendszer felhőalapú együttműködése.
Mire figyeljünk az összekapcsolásnál?
Ahhoz, hogy megértsük mennyi mindenre kell figyelni, itt egy kis szemléltetés. A következő adat paraméterekkel kell rendelkeznünk:
rendelés azonosító, rendelés státusz, boltnézet azonosító, számlázási adatosító (ezen belül: azonosító, felhasználói csoport, vezetéknév, keresztnév, e-mail, telefonszám, cím, ország, város, irányítószám stb.), szállítási adatok (az előzőhöz hasonlóan), szállítási mód, rendelt termékek (rendelt mennyiség, SKU vagy más azonosító, ár, kedvezmény).
A végére hagytuk a lényeget, azaz a megrendelt termékeket. Sokan azt gondolják, hogy ez a legfontosabb információ, azonban ebben a műveletben nem működhetünk hatékonyan egyik információ hiányában sem. Ráadásul vannak nehezítő tényezők, például folyamatosan változó, nyitott mezők, ahol extra, előre nem definiálható változatokat kapunk, a vásárlók egyedi jelzései alapján (minimum megjegyzés rubrika).
Leggyakoribb problémák és megoldásaik
Készlet elosztás
Több nagyobb kereskedőnél előfordul, hogy az online rendelt mennyiséget el kell osztani a raktárak (vagy boltok) között, egy rendelés kiszolgálása több fizikai központból történik. A Connect előre meghatározott logika mentén prioritási sorrendeket hoz létre, alá-fölérendeltségi viszonyokat. Példa: A főraktár a személyes átvételi hely, a listában második helyen szereplő raktár pedig a második legnagyobb raktárunk. Szeretnénk egy minimális alap készletet minden termékből a személyes átvételi pontnál, így hiába érhető el a termék, mégis megyünk tovább a lista második raktárára/boltjára.
Termékek szétválogatása
Nem ritka eset az sem, hogy a termékek bár egy megrendelésen futnak be, technikailag szét kell osztanunk őket az ERP rendszerünkben, vagy a boltjaink között. A megfelelő paraméterezés után ez nem probléma. Példa: Egyszerre értékesítünk egy terméket és hozzá egy szolgáltatást, mondjuk beszerelést. Bár a két értékesítés egy összegben, egy megrendelésben realizálódik, rendszereinkben külön kezeljük a szolgáltatás és a termékeladás értékesítését.
Rendelés törlés és várakoztatás
Tipikus eset, hogy a vásárló meggondolja magát és törli a megrendelését, amit mi már valamilyen úton módon feldolgoztunk. Amennyiben a rendelés törölt státusszal érkezik, akkor ennek a státusznak megfelelően továbbítjuk az adatokat az ERP irányába. Mivel előfordulhat az is, hogy a rendelés rögtön annak leadása után kerül törlésre a felhasználó által, ezért számolnunk kell azzal az esettel, hogy a rendelést még nem dolgoztuk fel teljes egészében, az még nem létezik ERP oldalon, ekkor lép életbe az üzleti logika és a köztes réteg. Példa: Leadott megrendelés után a vásárló rájön, hogy még szeretne kiegészítő szolgáltatásokat megrendelni, illetve még több kiegészítő terméket, de nem fizetne érte plusz kiszállítást. A rendelést törli, majd újat ad le. A rendszerben hemzsegnek az adatok, szükség van rá, hogy tisztán, érthetően leírjuk az adatok feldolgozásának idejét és módját.
Paraméterek boltnézethez kötése
Speciális eset, amikor egyes kiszolgáló egységeink máshogy működnek, mint akár a legnagyobb egységünk. Ilyenkor külön paraméterezésre van szükség. A rendelési adatoktól függően választjuk ki, hogy mely bolt és milyen módon szolgálja ki az adott megrendelést.
Vendégvásárlók azonosítása
Amennyiben az ERP kezel vásárlókat és a rendelésben át kell adni a vásárlók ERP oldali azonosítóját, felmerülhet a kérdés, hogy vendég vásárlók esetén mi történjen. A köztes réteg adatai között megkeresi a legoptimálisabb rögzítési formát, és a korábbi adatokkal összefésülve megpróbálja a legjobb megoldást nyújtani a vállalkozás számára. Példa: Az ügyfél nem szeretne regisztrálni, de adatait elmentette a telefonja és már visszatérő, ötödik alkalommal adott le rendelést. Nem szeretnénk öt különböző ERP azonosítóval terhelni rendszerünket, összefésüljük az adatokat, és egy customer ID alatt kezeljük őket.
Sebesség optimalizálás
Kissé kilóg a korábbi üzleti előnyökből, de a rendelés szinkronja és kezelése esetén fontos kitérni a sebesség kérdésére is. A szinkron sebessége egy alap integrációban is minimum 3 tényezős, amely a küldő fél (maga a webshop), a köztes réteg (OC) és a fogadó fél (jellemzően ERP) rendelkezésre álló erőforrásaitól és aktuális terheltségétől függ. Ennek kiszámítása és optimalizálása egy fontos task minden szinkronizálási feladat kapcsán.
Technikai adatok
A megfelelő adatok mellett fontos tényező a szinkronizálásnál a kapcsolati tényező. Jelenleg az OANDER Connect köztes réteg három féle kapcsolattal képes adatot fogadni. A kapcsolat típusa meghatározza azt is, hogy az adatok feldolgozása mikor kezdődik.
- HTTP GET / POST – az érkezés pillanatában eseményvezérelten
- HTTP adatletöltés – megszabott időközönként
- FTP fájl feltöltés – az érkezés pillanatában eseményvezérelten
Ami pedig a formátumokat érinti, a Connect központi hub-unk JSON, XML vagy CSV formátumokkal dolgozik leggyakrabban.
