Utánvét (COD)

Az utánvét (COD) lehetővé teszi, hogy a webáruház vevője készpénzben (vagy kártyával) fizessen a rendelésért a csomag átvételekor, ahelyett hogy online fizetne a fizetéskor. Mivel egyetlen értékesítési rendelés több fizikai csomagban is kiszállítható lehet — egy többlépcsős raktári útvonal, egy készlethiány miatti visszamaradt szállítás, egy részleges kiszállítás miatt —, az egyes csomagokon külön-külön beszedendő összeget egyedileg kell kiszámítani, és a megbízhatatlan utánvétes vevő kockázatát a rendelés megerősítése előtt kell kiszűrni. Az eYssen két célzott modullal fedi le mindkét problémát: az egyik kiszámítja a helyes utánvét-összeget szállítmányonként a fuvarozói integrációkhoz, a másik a fizetéskor a közös utanvet-ellenor.hu csalásvédelmi adatbázis alapján szűri az utánvét jellegű fizetési módokat.

Key features

• Dinamikus, csomagonkénti utánvét-számítás. Minden kimenő szállítás megkapja a saját, a ténylegesen benne lévő áruval arányos utánvét-összegét, így a részleges és a többlépcsős szállítások soha nem terhelik túl vagy alul a vevőt.

• Egyetlen, minden fuvarozó által megosztott számítás. A GLS, a Foxpost és az MPL is ugyanazt az alap metódust hívja meg a szállítási címke kérésének összeállításakor, így az üzleti szabály egyetlen helyen él, nem duplikálódik fuvarozónként.

• Közös csalásvédelmi adatbázis-ellenőrzés a fizetéskor. A fizetési szolgáltatók egyedileg megjelölhetők úgy, hogy elrejtésre kerüljenek azon vevők elől, akiknek gyenge a reputációja az Utánvét Ellenőr közös adatbázisában, még a rendelés leadása előtt.

• Alapértelmezés szerint hibatűrő (fail-open). Ha a csalásellenőrző API nem érhető el, a fizetés nem kerül blokkolásra, kivéve ha egy adminisztrátor kifejezetten a szigorúbb szabályzatot választja.

• Zárt hurkú visszajelentés. A sikeres és a sikertelen/törölt szállítások aszinkron módon visszajelentésre kerülnek az Utánvét Ellenőr felé, így a közös adatbázis pontos marad minden azt használó kereskedő számára.

How the COD amount is computed

Az eyssen_delivery_cod modul egy csak olvasható cod_amount mezőt ad a Transfers (stock.picking) modellhez, valamint egyetlen metódust, a _compute_dynamic_cod()-ot, amelyet a fuvarozói integrációk hívnak meg egy szállítmány előkészítése közben. Ez nem indul el automatikusan — a GLS (eyssen_delivery_gls), a Foxpost (eyssen_delivery_foxpost) és az MPL (eyssen_delivery_mpl) mindegyike az eyssen_delivery_cod-tól függ, és a saját „Utánvétes fizetés” szolgáltatójának XML ID-jével hívja meg a metódust, amikor egy mozgáshoz szállítási címke kérést állít össze.

A metódus csak akkor számít összeget, ha az értékesítési rendelés utolsó fizetési tranzakciója az adott fuvarozó saját „Utánvétes fizetés” szolgáltatóján keresztül történt; minden más fizetési mód esetén 0.0-t ad vissza, és figyelmeztetést naplóz. Amikor érvényes, az összeg a következőképp épül fel:

1. Ennek a csomagnak az árukészlet-értéke — a mozgásban szereplő, egy értékesítési rendelés sorához kapcsolódó minden készletmozgáshoz a sor egységára (price_total ÷ product_uom_qty, azaz adóval együtt) megszorzódik az adott mozgásban ténylegesen kiszállított mennyiséggel.

2. Már kiszállított áru értéke — ugyanez a számítás megismétlődik az azonos rendeléshez tartozó minden másik mozgásra, amelyhez már be van állítva cod_amount, vagyis a korábban kiszállított csomagokra.

3. Szolgáltatás sorok — azok a rendelési sorok, amelyek nem raktározható/fogyó termékek, és nem előlegek (például szállítási felár), teljes egészében hozzáadódnak a kumulatív összeghez.

4. Számlázott előlegek — a számlázott mennyiséggel rendelkező előleg rendelési sorok adóval együtt kerülnek kiszámításra (a tax_id.compute_all segítségével), és levonásra kerülnek a kumulatív összegből.

5. Már beszedett összeg — a már kiszállított testvér-mozgások cod_amount értékeinek összege levonásra kerül a kumulatív célösszegből, hogy megkapjuk a még fennmaradó tartozást.

6. Rendelés-összeg felső korlátja — az eredmény felülről korlátozott, így a rendelés összes csomagján beszedett összegek összege soha nem haladja meg a rendelés amount_total értékét.

Megjegyzés

Mivel a kumulatív célösszeg az első számítástól kezdve már tartalmazza a szolgáltatás sorokat, és minden későbbi csomag levonja azt, amit a korábbi csomagok már beszedtek, a gyakorlatban a vevő csak egyszer fizet a szolgáltatás sorokért — az első kiszállított csomaggal együtt.

A kapott összeg a stock.picking.cod_amount mezőben tárolódik, és csak olvasható formában jelenik meg a szállítási űrlapon közvetlenül a Carrier mező után (nulla érték esetén elrejtve). Minden fuvarozói modul ezt az összeget használja fel a saját címkekérésének „utánvétként beszedendő” mezőjének kitöltéséhez. Egyes fuvarozók emellett saját szigorú felső korlátot is érvényesítenek e számítás felett — a Foxpost például megtagadja a címke generálását 150 000 Ft felett.

Fontos

Az eyssen_delivery_cod-nak nincs saját beállítási képernyője. Csak akkor lép működésbe, amikor egy tőle függő fuvarozói modul (GLS, Foxpost vagy MPL) telepítve van, és a vevő az adott fuvarozó saját „Utánvétes fizetés” módján keresztül fizet.

Az Utánvét Ellenőr csalásellenőrzés a fizetéskor

Az utanvetellenor modul integrálja az utanvet-ellenor.hu közös vevő-reputációs adatbázist, amelyet több magyar webáruház is táplál szállítási eredményekkel. Két ponton kapcsolódik a rendelés életciklusába: a fizetési módok szűrése a fizetéskor, valamint a szállítási eredmény utólagos visszajelentése.

Fizetési szolgáltatók szűrése a fizetéskor

A modul kiterjeszti a fizetési szolgáltató kompatibilis szolgáltatókat kereső logikáját úgy, hogy minden olyan Payment Provider, amelyen a Utánvét Ellenőr ellenőrzés be van kapcsolva, csak azoknak a vevőknek ajánlódik fel, akiknek a reputációja megfelel a beállított küszöbértéknek.

• Ha egyetlen engedélyezett szolgáltatón sincs bekapcsolva az ellenőrzés, a modul semmit nem tesz — nincs teljesítménybeli költsége azoknak a boltoknak, amelyek nem használják.

• Az API meghívása előtt a modul ellenőrzi, hogy a fizetési partner vagy az aktuális felhasználó saját partnere, vagy ugyanazon kereskedelmi egységhez tartozó kapcsolat, vagy hogy a hívó belső felhasználó — ez megakadályozza, hogy a végpontot tetszőleges vevő reputációjának lekérdezésére használják.

• A vevő e-mail címe, telefonszáma (a phone_validation telepítése esetén E.164 formátumra normalizálva), országkódja, irányítószáma és utcaneve kerül elküldésre a /request végpontnak a beállított reputációs küszöbértékkel együtt; a név, a fizetési adatok és az adószámok soha nem kerülnek elküldésre.

• A döntés worker-processzenként öt percig kerül gyorsítótárazva a memóriában, a cég, a partner, a partner write_date mezője, a küszöbérték és a környezet alapján kulcsolva — így a partner elérhetőségi adatainak bármilyen helyi módosítása azonnal érvényteleníti a gyorsítótárazott döntést.

• Az API HTTP válasza döntéssé alakul: egy blocked eredmény, egy 204 (átmeneti/nem létező postafiók), egy hiányzó e-mail cím, vagy egy 404 (ismeretlen vevő, mindig engedélyezett) mind explicit módon kerül kezelésre. A 401 (hibás kulcsok) és a 402 (kimerült kvóta) naplózásra kerül, de önmagukban soha nem blokkolják a fizetést — kizárólag a valódi átviteli hibák (időtúllépés, kapcsolódási hiba, 5xx) és a kvótahibák tartoznak az alábbi tartalék szabályzat hatálya alá.

Fontos

Ha a vevő tiltott, vagy átviteli/kvóta hiba történik, miközben az API hiba esetén beállítás értéke Fizetés tiltása, akkor minden olyan szolgáltató, amelyen a Utánvét Ellenőr ellenőrzés be van kapcsolva, eltávolításra kerül a fizetéskor felajánlott fizetési módok listájáról. Azok a szolgáltatók, amelyek nem csatlakoztak be — például egy bankkártyás fizetési mód —, ez soha nem érinti.

Minden olyan API hívás, amely tiltást vagy hibát eredményez, belső megjegyzésként naplózható a vevőnél, a Chatter naplózás részletessége beállítás vezérlésével:

A megjegyzés rögzíti a környezetet, a küszöbértéket, a HTTP státuszt, az API sikeres/sikertelen átvétel számlálóit, a számszerű reputációt és a szó szerinti indoklást — az API kulcsokat soha.

Az eredmény visszajelentése

Amint egy védett szolgáltatón keresztül fizetett értékesítési rendeléshez kapcsolódó kimenő szállítás validálásra vagy törlésre kerül, a modul egy jelzést sorba állít, hogy a közös adatbázis megismerje az eredményt:

• a mozgás validálása (_action_done) sorba állítja az 1 eredményt (Sikeres átvétel (+1));

• a mozgás törlése (action_cancel) sorba állítja a -1 eredményt (Meghiúsult / visszautasított (-1)).

Egy sorbeli tétel csak akkor jön létre, ha a mozgás kimenő, egy értékesítési rendeléshez kapcsolódik, és az adott rendelésnek van done állapotú tranzakciója egy olyan szolgáltatón, amelyen a Utánvét Ellenőr ellenőrzés be van kapcsolva. Egy adatbázis-megkötés garantálja, hogy mozgásonként és eredményenként legfeljebb egy tétel jöhet létre, és egy újra validált mozgás soha nem állíthat sorba ellentmondó eredményt, ha már küldtünk egyet.

A sorba állított tételek a Website ‣ Configuration ‣ Utánvét Ellenőr signals menüpont alatt láthatók, State szerint színkódolva (Pending, Sent, Failed). Egy ütemezett művelet, az Utánvét Ellenőr: send pending signals, 10 percenként fut, és futásonként legfeljebb 100 esedékes tételt dolgoz fel, a sikertelen hívásokat legfeljebb háromszor újrapróbálva 5 perces, majd 30 perces, majd 2 órás várakozással, mielőtt egy tételt Failed állapotúra jelölne. Egy adminisztrátor a Retry gombbal visszaállíthat egy sikertelen tételt, hogy a cron ismét felvegye.

Konfiguráció

Az eyssen_delivery_cod nem igényel beállítást: telepítse egy fuvarozói modul függőségeként, és az utánvét-számítás automatikusan lefut az adott fuvarozó „Utánvétes fizetés” módján keresztül fizetett rendelésekhez.

Az Utánvét Ellenőr ellenőrzés beállításához:

1. Telepítse az utanvetellenor-t.

2. Nyissa meg a Website ‣ Configuration ‣ Settings ‣ Shop - Checkout Process ‣ Utánvét Ellenőr menüpontot, és állítsa be:

   • Mode — Sandbox or Production;

   • az adott környezethez tartozó publikus/privát kulcspárt;

   • Reputációs küszöb — egy -1,0 és +1,0 közötti érték (alapértelmezett 0,5);

   • API hiba esetén — Fizetés engedélyezése (alapértelmezett) vagy Fizetés tiltása;

   • API időtúllépés (mp) — a minden híváshoz használt HTTP időtúllépés (alapértelmezett 5);

   • Chatter naplózás részletessége — Minden API hívás, Csak tiltott vevők és hibák (alapértelmezett) vagy Csak hibák.

   

3. Minden olyan fizetési szolgáltatónál, amelyet védeni kell (jellemzően egy utánvétes vagy banki átutalásos mód), nyissa meg a Configuration fület, a Availability csoportot, és kapcsolja be az Utánvét Ellenőr ellenőrzés opciót.

Fontos

Az integráció egy közös adatkezelői adatmegosztási megállapodás: elküldi a vevő e-mail címét, telefonszámát, irányítószámát, országkódját és utcanevét egy harmadik félnek. Írja alá az Utánvét Ellenőr közös adatkezelői megállapodását, és frissítse a bolt adatvédelmi szabályzatát, mielőtt bekapcsolná az ellenőrzést Production (éles) környezetben.

Megjegyzés

A sandbox és éles API kulcsok titkosítatlan formában tárolódnak a cég rekordján; a jelszó widget a Settings menüben csak a képernyőn takarja el az értéket. A Settings menühöz való hozzáférés az Adminisztráció / Beállítások (base.group_system) csoportra van korlátozva, és ugyanez a csoport szükséges a jelzéssor megnyitásához és az API kulcsok megtekintéséhez — ezt a korlátozást soha ne lazítsa. Használjon eltérő kulcspárokat a sandbox és az éles környezethez, hogy egy kiszivárgott teszt kulcsot ne lehessen az éles adatbázis ellen visszajátszani.

Használat

1. Egy vevő fizet a weboldalon. Ha bármelyik felajánlott fizetési szolgáltatón be van kapcsolva a Utánvét Ellenőr ellenőrzés, a modul lekérdezi (vagy újra felhasználja a gyorsítótárazott) reputációs döntést az adott vevőhöz, és elrejti a védett szolgáltatókat, ha a vevő tiltott, vagy ha az API meghibásodott és a tartalék szabályzat Fizetés tiltása értékre van állítva. A többi fizetési mód mindkét esetben elérhető marad.

2. A rendelés megerősítésre kerül, és a raktár feldolgozza a szállítást, egy vagy több csomagban, az útvonaltól és a készlet elérhetőségétől függően.

3. Amikor a fuvarozói modul (GLS, Foxpost vagy MPL) legenerálja a szállítási címkét egy a saját „Utánvétes fizetés” módján keresztül fizetett mozgáshoz, meghívja a _compute_dynamic_cod()-ot, hogy pontosan kiszámítsa, mennyit kell beszedni azon a csomagon, és eltárolja a mozgás COD Amount mezőjében.

4. Amint a mozgás validálásra (kiszállításra) vagy törlésre kerül, egy jelzés automatikusan sorba áll, és az ütemezett művelet körülbelül 10 percen belül elküldi az Utánvét Ellenőr felé, így a közös reputációs adatbázis a valós eredményt tükrözi a jövőbeli ellenőrzésekhez — mind ennél a boltnál, mind a szolgáltatást használó minden más kereskedőnél.

Hatókör és modulok

• eyssen_delivery_cod — kiszámítja a dinamikus, csomagonkénti utánvét-összeget (részleges szállítások, szolgáltatás sorok, előlegek, rendelés-összeg felső korlátja), amelyet a fuvarozói integrációk közösen használnak.

• utanvetellenor — integrálja az utanvet-ellenor.hu közös csalásvédelmi adatbázist a fizetési folyamatba (fizetési szolgáltató szűrés) és a teljesítés utáni visszajelentésbe (jelzéssor és újrapróbálkozó cron).