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 átadásának pillanatában, ahelyett, hogy a pénztárnál online fizetne. Mivel egyetlen értékesítési rendelés több különálló szállítmányban is kiszállítható — többlépcsős raktári útvonal, készlethiány miatti visszarendelés vagy részleges kiszállítás miatt —, a minden egyes szállítmányon 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.

Lásd még

Szállítási módhoz kötött fizetési módok — a fizetési szolgáltatók szállítási módonkénti szűrése, valamint az utánvétes fizetési folyamat a pénztárnál
GLS integráció, Foxpost integráció és MPL integráció — az utánvét-számítást meghívó fuvarozói integrációk
Fizetéshez kötött szállítás — a szállítások visszatartása a rendelés kifizetéséig

screenshot: cash-on-delivery-checkout-payment-methods

menu: Website app ‣ open the shop ‣ add a product to the cart ‣ proceed to checkout ‣ reach the Payment step
shows: The website checkout payment step for a logged-in customer whose reputation is above the configured threshold, showing the "Payment on Delivery" option next to the other payment methods.
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

Főbb funkciók¶

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.

Az utánvét-összeg kiszámítása¶

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.

screenshot: cash-on-delivery-picking-cod-amount

menu: Inventory app ‣ Transfers ‣ open the outgoing delivery for a COD sale order (after it has produced a shipping label)
shows: An outgoing delivery transfer form for an order paid through a carrier's "Payment on Delivery" method, with the read-only COD Amount field visible next to the Carrier field.
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

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:

Ennek a csomagnak az áruértéke — a mozgásban szereplő, értékesítési rendelési sorhoz kapcsolódó minden készletmozgás esetén a sor egységára (price_total ÷ product_uom_qty, azaz adóval együtt) megszorzódik az ebben a mozgásban ténylegesen kiszállított mennyiséggel.
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, amelyen már be van állítva a cod_amount, vagyis a korábban kiszállított csomagokra.
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.
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.
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.
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 Fizetési szolgáltató, 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.

screenshot: cash-on-delivery-provider-check-toggle

menu: Website app ‣ Configuration ‣ Payment Providers ‣ open "Payment on Delivery" ‣ Configuration tab ‣ Availability group
shows: A "Payment on Delivery" payment.provider form (e.g. the one created by eyssen_delivery_gls) with the Configuration tab open on the Availability group, showing the "Utánvét Ellenőr Check" checkbox.
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

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:

screenshot: cash-on-delivery-partner-chatter-log

menu: Contacts app ‣ open a customer that has placed a webshop order paid by a guarded provider ‣ chatter / Log note history
shows: A res.partner (Contacts) form with the chatter open, showing an internal note logged by the module after a blocked or errored check (Mode, Threshold, HTTP status, Good/Bad, Reputation, Blocked, Reason lines).
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

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.

screenshot: cash-on-delivery-signal-queue-list

menu: Website app ‣ Configuration ‣ Utánvét Ellenőr signals
shows: The Utánvét Ellenőr signals list view with a few rows in different states, showing the green/red/grey state decorations and the Retry button on a failed row.
module: eyssen_delivery_cod, utanvetellenor
notes: English UI, light theme, 1440px width.

A sorba állított tételek a Website ‣ Configuration ‣ Utánvét Ellenőr jelzések menüpont alatt láthatók, Állapot szerint színkódolva (Függőben, Elküldve, Sikertelen). 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 Sikertelen á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:

Telepítse az utanvetellenor-t.
Nyissa meg a Website ‣ Configuration ‣ Settings ‣ Shop - Checkout Process ‣ Utánvét Ellenőr menüpontot, és állítsa be:
- Utánvét Ellenőr környezet — Sandbox (teszt) vagy Éles;
- 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.
screenshot: cash-on-delivery-settings
menu
Website app ‣ Configuration ‣ Settings ‣ Shop - Checkout Process section ‣ Utánvét Ellenőr
shows
The Website Settings page scrolled to the "Shop - Checkout Process" block, with the "Utánvét Ellenőr" collapsible setting expanded showing Mode, key fields, Reputation Threshold, Fallback on API Error, API Timeout and Chatter Verbosity.
module
eyssen_delivery_cod, utanvetellenor
notes
English UI, light theme, 1440px width.
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 Éles (é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¶

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.
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.
Amikor a fuvarozói modul (GLS, Foxpost vagy MPL) legenerálja a szállítási címkét egy olyan mozgáshoz, amelyet a saját „Utánvétes fizetés” módján fizettek, meghívja a _compute_dynamic_cod() metódust, hogy pontosan kiszámítsa, mennyit kell beszedni azon a szállításon, és az eredményt a mozgás COD Amount mezőjében tárolja el.
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).