Az eMAG új API-verziója és miért most kell stabil ERP↔eMAG kapcsolat
Ha Ön Magyarországon árul az eMAG-on, valószínűleg már találkozott vele: az integrációja egyik reggel működik, másnap pedig hibát dob egy ártól vagy egy rendeléstől, ami eddig rendben átment. Nem Ön rontotta el. Az eMAG Marketplace API-ja a v4.5.1 verzióval szigorúbb lett, és a régebbi logikára épülő kapcsolatok ezt most érzik meg.
A szigorítás logikus, és valójában jó hír annak, akinek rendben van a háttérrendszere. Annak viszont, aki kézzel vagy egy összetákolt szkripttel tartja életben az eMAG-kapcsolatot, most jön el a számla.
Mi változott az eMAG API-ban
A v4.5.1 nem felületi ráncfelvarrás. A kérések formátuma kötöttebb lett, és az eMAG kevésbé bocsát meg.
- Szigorúbb kérésformátum. Minden hívás payloadját egy {"data":[...]} burokba kell csomagolni, a válaszban pedig az isError:false jelzi, hogy a művelet rendben lefutott. A validáció szorosabb, mint a korábbi verziókban: ami régen átcsúszott, az most elakad.
- Árak ÁFA nélkül, kötelező min/max. Az árakat ÁFA nélkül (nettóban) kell küldeni, és minden ajánlathoz kötelező egy minimum és egy maximum eladási ár. Ezek nélkül az ajánlat nem megy fel. Az ÁFA-kulcsokat a vat/read adja.
- Két út a publikáláshoz. A teljes terméklistázás a product_offer/save hívással történik, a könnyebb készlet- és árfrissítés viszont az offer/save hívással, ami gyorsabb és kevésbé terheli a kvótát.
- A rendeléseket le kell kérni és vissza kell igazolni. A rendeléseket az order/read lekérdezi, és minden új rendelést vissza kell igazolni az order/acknowledge hívással. Az eladónak nagyjából 48 órája van a feldolgozásra.
- A fuvarlevelet az eMAG generálja. Az awb/save hívásra az eMAG állítja elő az AWB-számot, és lezárja a rendelést. A már kiállított számla PDF-jét az order/attachments/save csatolja egy URL alapján.
- Korlátok és hitelesítés. Rendelésekre nagyjából 12 kérés/másodperc, a többi erőforrásra körülbelül 3/másodperc a keret. A belépés Basic auth, és a szerver IP-címét előzetesen engedélyezni kell.
Egyik elem sem bonyolult önmagában. A baj ott kezdődik, amikor mindezt egyszerre, hibamentesen, napi több ezer terméken és rendelésen kell betartani, akkor is, amikor az eMAG lassan válaszol vagy átmenetileg elérhetetlen.
Miért most számít ez Önnek
Egy szigorúbb API egy dolgot tesz nyilvánvalóvá: a házilag összerakott vagy karbantartás nélkül hagyott kapcsolatok csendben hibáznak. A rendelés, amit nem igazol vissza időben, kicsúszik a 48 órás ablakból. Az ár, ami min/max nélkül megy fel, elutasításra kerül. A készlet, ami nem frissül elég gyorsan, túlértékesítéshez vezet, és a túlértékesítés az eMAG-on értékelést és büntetést von maga után.
Ezek nem elméleti kockázatok. Valódi pénz, és a legrosszabbkor csapnak le: a forgalmas időszakban, amikor a rendszerek a leginkább terheltek.
Hogyan tartja stabilan a kapcsolatot a MEGZO Vortex
A megközelítésünk egyszerű kimondani, és a részleteken áll vagy bukik: az Ön ERP-je marad az egyetlen igazságforrás, a Vortex pedig kétirányban szinkronizál vele. A katalógus, a készlet és az ár kifelé megy az eMAG felé, a rendelések pedig befelé jönnek az ERP-be. Ön egy helyen dolgozik, nem kettőben.
Amit ezen felül adunk, az a robusztusság, vagyis hogy a rendszer akkor is helyesen viselkedjen, amikor valami félresikerül:
- Túlértékesítés-védelem biztonsági pufferrel. A készletet egy pufferrel csökkentve küldjük ki, így nem fordul elő, hogy az utolsó darabot két csatorna egyszerre adja el. Egy napi egyeztetés kiszűri az elcsúszást.
- Nincs duplikált rendelés. Minden eMAG-rendelésből pontosan egy ERP sales order lesz. A folyamat idempotens, így ha egy hívás újra lefut, vagy egy rendelés kétszer érkezik be, akkor sem keletkezik második rekord.
- Automatikus újrapróbálkozás a korlátok tiszteletben tartásával. Amikor az eMAG lassú vagy elutasít, a rendszer növekvő várakozással újrapróbálja, betartva a 12/s és 3/s kereteket. Ami végleg elakad, az egy dead-letter queue-ba kerül riasztással, és onnan visszajátszható. Semmi nem vész el csendben.
- Napi egyeztetés. Egy söprés naponta összeveti a rendeléseket, kiszűri a készlet- és árelcsúszást, és megkeresi az árvává vált rekordokat, mielőtt azok problémává válnának.
- AWB és számla automatikusan. A fuvarlevél és a már kiállított számla átadása magától megtörténik.
Egy dologban érdemes tisztának lenni: mi nem állítunk elő adóügyi számlát. Csak azt a számlát csatoljuk, amelyet az Ön ERP-je már létrehozott. A számlázás és az adózás az Ön rendszerénél marad, ahol a helye van.
A háttérben minden ügyfél elkülönítve fut, a hozzáférési adatok titkosítva pihennek, és minden szinkron nyomon követhető. Ha valami félrement, megmondjuk, mi és mikor.
ERP-rendszerek, amelyeket eMAG-hoz kötünk
- SmartBill
- Oblio
- FGO
- Facturis
- SoftOne
- Nexus ERP
- Charisma
- Senior ERP
- WinMentor
- Wizrom
- Acumatica
- Odoo
- SAP
- Microsoft Dynamics 365
Hol kezdje
Ha az eMAG-integrációja törékenynek érződik, vagy egy régebbi API-verzióra épül, érdemes átnézni, mielőtt a következő csúcsidőszak kiveti a hibákat. Mondja el, milyen ERP-t használ és mit szeretne szinkronban tartani, mi pedig megmutatjuk, hogyan néz ki ez élesben az Ön rendszerén. Kezdje itt: vortex.megzo.biz/start/.