A return-merchandise authorization (RMA) az a feature, amit mindenki elhalaszt, mig az emailes 'szeretnem visszakuldeni' kerelmek nem tobbszorozodnek a tamogatasi ticketekben. Egy kozepes B2C webshopnal a returnek aranya 4-12% kozott mozog, eletmedan webshopnal akar 25%-ig is felmehet. Itt van, hogyan epitettuk az RMA flow-t a Netorigo Logistics-ben.
Vasarlo self-service portal
A vasarlo a rendelese alatt rakattint a 'visszakuldes inditasa' linkre, es egy 4-lepeses formot kap:
- Melyik tetelt? (multi-select az ordere SKU-ibol).
- Miert? (dropdown: hibas, masmilyen, nem felelt meg, masolat-rendelés, egyeb).
- Allapot? (bontatlan, bontott-hasznalt, serult).
- Foto feltoltes (opcionalis a 'serult' es 'hibas' kategoriaknal kotelezo).
A form a return_requests tablaban land egy pending_approval allapotban. Az automatikus jovahagyas a partner tenant-config alapjan tortenik: ha a SKU return_policy.auto_approve = true es a vasarlas <30 napos es az osszeg <50.000 HUF, automatikus jovahagyas. Egyebkent a partner ugyfelszolgalata kezzel jovahagyja a 24-48 oran belul.
Pre-paid label generation
Jovahagyas utan automatikusan generalodik egy pre-paid visszakuldesi cimke. A carrier valasztasa a partner config alapjan tortenik (foleg GLS vagy MPL Magyarorszagon), es a koltseget a 'return_label_cost' kontoba konyveljuk. A vasarlo egy PDF-cimket kap email-ben, a kozeli Foxpost automataba vagy a postara viszi a csomagot.
Receiving inspection a raktarban
A visszaerkezett csomag a raktarban kulonleges RMA receiving muveletbe esik (nem az altalanos receiving wave-be). A pickere a PWA-n megnyitja a return_request rekordot, scan-eli a beerkezett SKU-kat, es egyenkent dokumentalja az allapotot:
as_new: bontatlan, eredeti csomagolasban. Vissza a polcraavailablestockkent.usable: bontott, de hasznalhato.outletstockkent.damaged: serult.quarantinestockkent, supervisor donti el a sorsat.not_returnable: a vasarlo rosszat kuldott vissza, vagy hianyzik valami. Areturn_requestrejected statusszal jelolve, ugyfelszolgalat ujra kontaktal.
Minden allapotbecsleshez kotelezo egy foto a return_inspection_photos-ba. Vita eseten (vasarlo: 'jo allapotban kuldtem'; raktar: 'serulten erkezett'), a foto a tabla.
Refund/exchange decision
A receiving inspection utan a return_request awaiting_resolution allapotba esik. Ha a vasarlo refund-ot kert, a Finance modul credit_note-ja automatikusan generalodik (a Logistics modul rest API-jat hivva), es a kifizetes a Payment modul refund muveletevel megy a vasarlo eredeti fizetes-modjara. Ha exchange-t kert (masolatra cserelve), a Logistics modul uj orderet generalja az eredeti fizetessel.
A restocking fee logikaja per tenant es per SKU konfiguralhato. Egy elektronikai partnerunk 15% restockolasi dijat szed minden bontott visszakuldesnel, mert az outlet-csatornan a margin szukebb. Az auto-approve-ot ez a partner deliberaltan kikapcsolta, igy az ugyfelszolgalat case-by-case dont.
A legkemenyebb resz: cross-warehouse returnek
A vasarlo a 18-as raktarbol vasarolt, vissza a 33-as raktarba kuldott (kozelebb hozza). A 18-as kapja vissza a tetelt logikailag? Nem feltetlenul. Ha a vasarlo store credit-et kert (nem refund-ot), es a 33-as raktar inventoryja lookup-onkent magasabb prioritasu, akkor a tetel a 33-asban marad. Ha refund-ot kert, akkor a cross_stock_request automatikusan generalodik a 18-as fele, a kovetkezo inter-warehouse hullamban megy at. Ez a logika a WarehouseReceivingPolicyService-ben el.
Finance integracio
A credit_note generalas a Finance modul /api/v1/credit-notes endpoint-jat hivja, a tenant-aware JWT-vel. A response landol vissza a return_requests.credit_note_id mezojebe, igy mindketto modulon at lehet drillodni az auditok soran. NAV-szempontbol a credit-note ZARO osszege egyezni kell az eredeti szamla osszegevel - ha resz-refund-ot adunk (pl. nem mind a hat tetel jott vissza), a credit-note csak a visszakuldott tetelek osszeget tartalmazza.