Plata ramburs (COD)¶

Plata ramburs (COD, cash on delivery) permite unui client al magazinului web să plătească o comandă în numerar (sau cu cardul) în momentul predării coletului, în loc să plătească online la finalizarea comenzii. Deoarece o singură comandă de vânzare poate fi expediată în mai multe livrări separate — o rută de depozit cu mai mulți pași, o comandă restantă pentru un produs fără stoc, o livrare parțială — suma de încasat la fiecare livrare trebuie calculată individual, iar riscul reprezentat de un client COD nesigur trebuie verificat înainte de confirmarea comenzii. eYssen acoperă ambele probleme prin două module specializate: unul calculează suma COD corectă pentru fiecare livrare, pentru integrările cu transportatorii, iar celălalt condiționează metodele de plată de tip ramburs la finalizarea comenzii în raport cu baza de date comună de fraudă utanvet-ellenor.hu.

Vezi și

Metode de plată în funcție de livrare — cum sunt filtrați furnizorii de plată pe metodă de livrare și experiența de finalizare a comenzii cu COD
Integrarea GLS, Integrarea Foxpost și Integrarea MPL — integrările cu transportatorii care apelează calculul COD
Livrarea condiționată de plată — reținerea livrărilor până la plata unei comenzi

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.

Funcționalități cheie¶

Calcul COD dinamic, pentru fiecare livrare. Fiecare livrare de ieșire primește propria sumă COD, proporțională cu mărfurile pe care le conține efectiv, astfel încât livrările parțiale și cele cu mai mulți pași să nu încaseze niciodată de la client o sumă prea mare sau prea mică.
Un singur calcul, comun tuturor transportatorilor. GLS, Foxpost și MPL apelează aceeași metodă de bază la construirea cererii pentru eticheta de expediere, astfel încât regula de business se află într-un singur loc, în loc să fie duplicată pentru fiecare transportator.
Verificare comună în baza de date de fraudă la finalizarea comenzii. Furnizorii de plată pot fi marcați individual pentru a fi ascunși clienților cu o reputație slabă în baza de date comună Utánvét Ellenőr, chiar înainte ca comanda să fie plasată.
Fail-open implicit. Dacă API-ul de verificare a fraudei nu este accesibil, finalizarea comenzii nu este blocată, cu excepția cazului în care un administrator optează explicit pentru politica mai strictă.
Raportare în circuit închis. Livrările reușite și cele eșuate/anulate sunt raportate înapoi către Utánvét Ellenőr în mod asincron, astfel încât baza de date comună să rămână exactă pentru fiecare comerciant care o utilizează.

Cum se calculează suma COD¶

Modulul eyssen_delivery_cod adaugă un câmp cod_amount doar pentru citire pe Transferuri (stock.picking) și o singură metodă, _compute_dynamic_cod(), pe care integrările cu transportatorii o apelează la pregătirea unei expedieri. Aceasta nu este declanșată automat — GLS (eyssen_delivery_gls), Foxpost (eyssen_delivery_foxpost) și MPL (eyssen_delivery_mpl) depind fiecare de eyssen_delivery_cod și apelează metoda cu ID-ul XML al propriului furnizor „Plată la livrare” atunci când construiesc cererea pentru eticheta de expediere a unei ridicări.

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.

Metoda calculează o sumă numai când ultima tranzacție de plată a comenzii de vânzare se află la furnizorul „Plată la livrare” propriu al acelui transportator; pentru orice altă metodă de plată returnează 0.0 și înregistrează un avertisment în jurnal. Când se aplică, suma este construită astfel:

Valoarea mărfurilor din această livrare — pentru fiecare mișcare de stoc din ridicare care este legată de o linie de comandă de vânzare, prețul unitar al liniei (price_total ÷ product_uom_qty, adică cu taxe incluse) este înmulțit cu cantitatea expediată efectiv în această ridicare.
Valoarea mărfurilor deja expediate — același calcul este repetat pentru fiecare altă ridicare de pe aceeași comandă care are deja un cod_amount setat, adică livrările expediate mai devreme.
Liniile de servicii — liniile de comandă care nu sunt produse stocabile/consumabile și nu sunt plată în avans (de exemplu, suprataxele de transport) sunt adăugate integral la totalul cumulat.
Plățile în avans facturate — liniile de comandă de tip plată în avans cu cantitate facturată sunt calculate cu taxe (prin tax_id.compute_all) și scăzute din totalul cumulat.
Suma deja încasată — suma cod_amount de pe ridicările înrudite care au fost deja expediate este scăzută din ținta cumulată, pentru a obține suma datorată în continuare.
Plafonul totalului comenzii — rezultatul este plafonat astfel încât suma a tot ce a fost încasat în toate livrările comenzii să nu depășească niciodată amount_total al comenzii.

Notă

Deoarece ținta cumulată include liniile de servicii începând cu primul calcul, iar fiecare livrare ulterioară scade ceea ce au încasat deja cele anterioare, în practică clientul plătește pentru liniile de servicii o singură dată — odată cu prima livrare expediată.

Suma rezultată este stocată în stock.picking.cod_amount și afișată, doar pentru citire, pe formularul livrării, imediat după câmpul Transportator (ascunsă cât timp este zero). Fiecare modul de transportator folosește apoi această sumă pentru a completa câmpul „încasare la livrare” din propria cerere de etichetă. Unii transportatori impun suplimentar propriul plafon strict peste acest calcul — de exemplu, Foxpost refuză generarea unei etichete peste 150 000 HUF.

Important

eyssen_delivery_cod nu are un ecran de configurare propriu. Devine activ numai după instalarea unui modul de transportator care depinde de el (GLS, Foxpost sau MPL) și când clientul plătește prin metoda „Plată la livrare” proprie acelui transportator.

Verificarea de fraudă Utánvét Ellenőr la finalizarea comenzii¶

Modulul utanvetellenor integrează baza de date comună de reputație a clienților utanvet-ellenor.hu, alimentată cu rezultatele livrărilor de mai multe magazine web maghiare. Se conectează la două puncte ale ciclului de viață al comenzii: filtrarea metodelor de plată la finalizarea comenzii și raportarea ulterioară a rezultatului livrării.

Filtrarea furnizorilor de plată la finalizarea comenzii¶

Modulul extinde căutarea furnizorilor de plată compatibili, astfel încât orice Furnizor de plată cu Verificare Utánvét Ellenőr activată este oferit doar clienților a căror reputație depășește pragul configurat.

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.

Dacă niciun furnizor activat nu are verificarea pornită, modulul nu face nimic — nu există niciun cost de performanță pentru magazinele care nu îl folosesc.
Înainte de a apela API-ul, modulul verifică dacă partenerul de la finalizarea comenzii este fie partenerul propriu al utilizatorului curent, fie un contact din aceeași entitate comercială, fie că apelantul este un utilizator intern — aceasta împiedică utilizarea endpoint-ului pentru a sonda reputația unui client arbitrar.
E-mailul, telefonul (normalizat în format E.164 prin phone_validation când este instalat), codul țării, codul poștal și adresa clientului sunt trimise către endpoint-ul /request împreună cu pragul de reputație configurat; numele, datele de plată și codurile fiscale nu sunt niciodată trimise.
Verdictul este păstrat în memorie, în cache, pentru fiecare proces worker, timp de cinci minute, având drept cheie compania, partenerul, write_date al partenerului, pragul și modul — astfel, orice modificare locală a datelor de contact ale partenerului invalidează imediat verdictul din cache.
Răspunsul HTTP al API-ului este tradus într-o decizie: un rezultat blocked, un 204 (căsuță poștală temporară/inexistentă), un e-mail lipsă sau un 404 (client necunoscut, întotdeauna permis) sunt toate tratate explicit. 401 (chei greșite) și 402 (cotă epuizată) sunt înregistrate în jurnal, dar nu blochează niciodată, singure, finalizarea comenzii — doar eșecurile reale de transport (timeout, eroare de conexiune, 5xx) și erorile de cotă sunt supuse politicii de rezervă de mai jos.

Important

Când clientul este blocat sau apare o eroare de transport/cotă în timp ce Variantă de rezervă la eroare API este setată la Blochează plata, fiecare furnizor care are activat Verificare Utánvét Ellenőr este eliminat din lista metodelor de plată oferite la finalizarea comenzii. Furnizorii care nu participă — de exemplu o metodă de plată cu cardul — nu sunt niciodată afectați.

Fiecare apel API care duce la o blocare sau la o eroare poate fi înregistrat ca notă internă pe client, controlat de setarea Nivel de detaliu în chatter:

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.

Nota înregistrează modul, pragul, starea HTTP, numărul de evaluări bune/rele ale API-ului, reputația numerică și motivul literal — niciodată cheile API.

Raportarea rezultatului înapoi¶

După ce o livrare de ieșire legată de o comandă de vânzare plătită printr-un furnizor protejat este validată sau anulată, modulul pune în coadă un semnal, astfel încât baza de date comună să afle rezultatul:

validarea transferului (_action_done) pune în coadă rezultatul 1 (Livrare reușită (+1));
anularea transferului (action_cancel) pune în coadă rezultatul -1 (Eșuată / refuzată (-1)).

Un rând din coadă este creat numai dacă ridicarea este de ieșire, legată de o comandă de vânzare, iar acea comandă are o tranzacție în starea done la un furnizor cu Verificare Utánvét Ellenőr activată. O constrângere a bazei de date garantează cel mult un rând pe ridicare și pe rezultat, iar o ridicare revalidată nu poate pune niciodată în coadă un rezultat contradictoriu după ce unul a fost deja trimis.

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.

Rândurile din coadă sunt vizibile în Site web ‣ Configurare ‣ Semnale Utánvét Ellenőr, codificate prin culoare după Stare (În așteptare, Trimis, Eșuat). O acțiune programată, Utánvét Ellenőr: trimite semnalele în așteptare, rulează la fiecare 10 minute și procesează până la 100 de rânduri scadente la fiecare rulare, reîncercând apelurile eșuate de până la trei ori, cu un interval de așteptare de 5 minute, apoi de 30 de minute, apoi de 2 ore, înainte de a marca un rând ca Eșuat. Un administrator poate reseta un rând eșuat cu butonul Reîncearcă, pentru ca cron-ul să îl preia din nou.

Configurare¶

eyssen_delivery_cod nu necesită nicio configurare: instalați-l ca dependență a unui modul de transportator, iar calculul COD rulează automat pentru comenzile plătite prin metoda „Plată la livrare” a acelui transportator.

Pentru a configura verificarea Utánvét Ellenőr:

Instalați utanvetellenor.
Accesați Site web ‣ Configurare ‣ Setări ‣ Magazin - Proces de finalizare comandă ‣ Utánvét Ellenőr și setați:
- Mod — Sandbox sau Producție;
- perechea de chei publică/privată corespunzătoare modului respectiv;
- Prag de reputație — o valoare între -1.0 și +1.0 (implicit 0.5);
- Variantă de rezervă la eroare API — Permite plata (implicit) sau Blochează plata;
- Timp de expirare API (s) — timeout-ul HTTP folosit pentru fiecare apel (implicit 5);
- Nivel de detaliu în chatter — Toate apelurile API, Clienți blocați și doar erori (implicit) sau Doar erori.
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.
Pentru fiecare furnizor de plată care trebuie condiționat (de obicei o metodă de plată ramburs sau prin transfer bancar), deschideți fila Configurare, grupul Disponibilitate și activați Verificare Utánvét Ellenőr.

Important

Integrarea este un acord de partajare a datelor între operatori asociați: trimite e-mailul, telefonul, codul poștal, codul țării și linia de adresă ale clientului către o terță parte. Semnați acordul Utánvét Ellenőr privind operatorii asociați de date și actualizați politica de confidențialitate a magazinului înainte de a activa verificarea în modul Producție.

Notă

Cheile API de sandbox și de producție sunt stocate în text simplu pe înregistrarea companiei; widgetul de parolă din Setări maschează valoarea doar pe ecran. Accesul la Setări este restricționat la grupul Administration / Settings (base.group_system), iar același grup este necesar pentru a deschide coada de semnale și pentru a vedea cheile API — nu reduceți niciodată această restricție. Folosiți perechi de chei diferite pentru sandbox și producție, astfel încât o cheie de test scursă să nu poată fi reutilizată împotriva bazei de date reale.

Utilizare¶

Un client finalizează o comandă pe site-ul web. Dacă oricare furnizor de plată oferit are Verificare Utánvét Ellenőr activată, modulul caută (sau reutilizează din cache) verdictul de reputație pentru acel client și ascunde furnizorii protejați dacă clientul este blocat sau dacă API-ul a eșuat, iar politica de rezervă este setată la Blochează plata. Celelalte metode de plată rămân disponibile în ambele cazuri.
Comanda este confirmată, iar depozitul procesează livrarea, într-o singură expediere sau în mai multe, în funcție de rută și de disponibilitatea stocului.
Când modulul de transportator (GLS, Foxpost sau MPL) generează eticheta de expediere pentru o ridicare plătită prin propria metodă „Plată la livrare”, apelează _compute_dynamic_cod() pentru a stabili exact cât trebuie încasat la acea livrare și stochează suma în câmpul Sumă ramburs al ridicării.
După ce transferul este validat (livrat) sau anulat, un semnal este pus automat în coadă și trimis către Utánvét Ellenőr de acțiunea programată în aproximativ 10 minute, astfel încât baza de date comună de reputație să reflecte rezultatul real pentru verificările viitoare — ale acestui magazin și ale fiecărui alt comerciant care folosește serviciul.

Domeniu de aplicare și module¶

eyssen_delivery_cod — calculează suma COD dinamică, pentru fiecare livrare (expedieri parțiale, linii de servicii, plăți în avans, plafonul totalului comenzii), comună integrărilor cu transportatorii.
utanvetellenor — integrează baza de date comună de fraudă utanvet-ellenor.hu la finalizarea comenzii (filtrarea furnizorilor de plată) și în raportarea de după onorarea comenzii (coada de semnale și cron-ul de reîncercare).