Szakmai cikk

ERP-integráció mobil rendelési rendszerhez: így marad kezelhető a működés

2026. febr. 21.

• ERP
• Vendéglátás
• Weclapp

Egy mobil rendelési alkalmazás kívülről katalógusnak, kosárnak és beküldőgombnak látszik. A háttérben ügyféltörzs, egyedi ár, készlet, adózás, teljesítési szabály és az üzleti csapat által használt ERP-állapot dolgozik.

Ha az integráció csak a mobilfelület megtervezése után kezdődik, a két adatmodell későn találkozik. Az alkalmazás könnyen azt feltételezi, hogy minden terméknek egy ára van, és minden kosárból azonnal rendelés lesz. Az ERP közben vevőspecifikus kondíciót, csomagolási egységet vagy kézi jóváhagyást várhat.

A rendelés állapotait a képernyők előtt tervezzük meg

Írjuk le az utat az üres kosártól a teljesítésig. A „beküldve” szó ne takarjon több különböző tényt.

Egy valós állapotmodell megkülönböztetheti:

• a készüléken mentett kosarat;
• a szervernek elküldött kérést;
• a rendelési szolgáltatás által átvett adatot;
• az ellenőrzésre váró rendelést;
• az ERP által elfogadott rendelést;
• a kézi ellenőrzésre küldött rendelést;
• az indoklással elutasított tételt;
• a teljesítésre visszaigazolt, részben teljesített vagy lezárt rendelést.

Az ügyfélnek nem kell minden belső állapotot látnia, de pontos visszajelzést kell kapnia. ERP-leállás közben a „Rendelés visszaigazolva” félrevezető lehet. A „Rendelését átvettük, a visszaigazolást hamarosan küldjük” őszinte állapotot ad, amíg a rendszer újrapróbál vagy ellenőrzést kér.

Legyen egyértelmű az adatok gazdája

Az ERP kezelheti a termékazonosítót, az ügyfélfiókot, az adózást, a hitelkeretet és a rendelési előzményt. A részletes termékleírás és kép jöhet más katalógusból. A mobilalkalmazás felel a kosárért és az interakció ideiglenes állapotáért.

Az árazás külön figyelmet kér. A gyorsítótárazott listaár eltérhet a szerződéses ártól, a mennyiségi kedvezménytől vagy az aktuális promóciótól. Határozzuk meg, mikor mutathat az alkalmazás végleges árat, mikor kell tájékoztató értéket jeleznie, és mi történik, ha az ERP az ellenőrzésnél más összeget ad.

A mértékegység és a csomagolás hasonlóan fontos. A felületen szereplő „egy doboz” az ERP-ben tizenkét darab lehet. Az átalakítás legyen dokumentált, és maradjon visszakereshető az eredeti ügyfélválasztás.

Az adatok frissessége igazodjon a döntéshez

Nem minden mező igényel valós idejű szinkront. Egy leírás frissülhet ütemezetten, a blokkolt ügyfélfiókot viszont célszerű a beküldés előtt ellenőrizni. A készletadat gyorsan változhat, és több raktár eltérő állapotát takarhatja.

Adatcsoportonként rögzítsük a forrást, az irányt, az elfogadható kort, a forrás kiesésekor követett viselkedést és az inaktív rekordok kezelését. A szinkronfolyamatokhoz tartozzon időbélyeg, feldolgozott darabszám és látható hibalista.

A beküldés legyen biztonságosan megismételhető

A mobilhálózat megszakadhat a kérés feldolgozása után, de még a válasz megérkezése előtt. Az ügyfél ilyenkor ismét megnyomhatja a gombot. A szervernek fel kell ismernie, hogy ugyanarról a rendelési szándékról van szó.

Minden beküldés kapjon stabil kliensazonosítót, és a rendelés létrehozása legyen idempotens a teljes érintett láncon. Az integráció őrizze meg a kérést az ERP hívása előtt. Időtúllépés után ismert azonosító alapján egyeztessen, mielőtt új rekordot hozna létre.

Az átmeneti hálózati hiba újrapróbálható. Az ismeretlen ügyfél, hibás termékmegfeleltetés vagy hitelkeret-blokkolás emberi döntést vagy ügyféloldali javítást kér. A folyamatos automatikus újraküldés itt csak szaporítja a hibákat.

Az ügyfélazonosítás és a hozzáférés is maradjon összhangban

A B2B-rendelésben gyakran több vevő tartozik egy céghez, ügyfélspecifikus katalógusokkal és jóváhagyási limitekkel. Döntsük el, hogy az ERP ügyfélszáma vállalatot, szállítási helyet vagy személyt jelöl-e. Rögzítsük, ki láthat árakat, ki küldhet be rendelést, és ki fér hozzá a rendelési előzményekhez.

A fiók-összevonásokhoz és a munkatársi változásokhoz kezelt folyamat kell. A távozó felhasználó veszítse el a hozzáférését az ERP-előzmények módosítása nélkül. Duplikált ERP-ügyfélrekord miatt pedig ne válhassanak láthatóvá másik szervezet árai vagy feltételei.

Az üzleti csapat kapjon egyeztető nézetet

Az integráció drága marad, ha minden kivételhez fejlesztő kell. Egy célzott nézet mutassa meg az ügyfelet és a hivatkozást, a mobil- és ERP-állapotot, a hiba üzleti okát, az érintett tételeket, a korábbi próbálkozásokat és a biztonságosan elérhető műveleteket.

Az értékesítés és a teljesítés fogalmait használjuk. A nyers válaszok és részletes technikai hibanyomok maradhatnak elérhetők a mérnökök számára, de ne ezek legyenek az elsődleges kezelőfelület.

Valós ügyféltípusokkal induljon a pilot

Teszteljünk normál visszatérő vevővel, egyedi árazással, inaktív termékkel, szokatlan egységgel, részleges elérhetőséggel és blokkolt fiókkal. A pilot alatt hasonlítsuk össze a mobilos beküldést az ERP-ben létrejött rendeléssel és a teljesítési folyamattal. Kövessük a kézi javításokat, elutasított tételeket, duplikált kísérleteket és a visszaigazolási időt.

A Weclapp B2B rendelési rendszer ezt a felosztást követi: a mobiltermék rövidebb újrarendelési utat ad, a katalógus-, ügyfél- és rendelési adatokért pedig továbbra is a Weclapp felel. A hibák láthatók maradnak, így duplikált rendelés nélkül lehet helyreállítani a folyamatot.

A jól működő mobilos rendelés nem pusztán kosarat ad át. Az ügyfél hiteles állapotot kap, az operatív csapat pedig minden fontos helyzetből ismert úton tud továbblépni.