Operațional multichannel: stoc, comenzi și retururi pe canale

Al doilea canal nu adaugă doar un dashboard. Adaugă încă o copie a catalogului, încă un loc în care se poate vinde ultima unitate, alte stări ale comenzii, alte documente și alt traseu al returului. Dacă fiecare canal își păstrează propriul adevăr, magazinul ajunge să opereze firme paralele care concurează pentru același stoc.

Arhitectura sănătoasă nu începe cu numele unui conector. Începe cu proprietarul fiecărei entități și cu contractul de date: cine creează SKU-ul, cine decide stocul disponibil, ce eveniment rezervă unitatea, unde se emite factura, cine închide returul și cum refaci fluxul după o cădere. Abia apoi alegi dacă execuția este manuală, prin fișier, API, ERP, OMS sau WMS.

Catalogul master păstrează identitatea fiecărui SKU

Canalele au modele diferite de catalog. Marketplace-ul poate asocia oferta sellerului la o fișă comună, comparatorul citește un feed, iar magazinul propriu afișează produsul și conținutul controlat de brand. Aceste diferențe nu justifică trei identități interne pentru aceeași unitate fizică.

Catalogul master trebuie să păstreze:

• SKU intern unic, stabil și neverosimil de reutilizat;
• GTIN/EAN sau motivul documentat pentru absență;
• brand, model și cod de producător;
• familia, variantele și relația părinte–copil;
• unitatea de măsură și cantitatea din pachet;
• greutatea și dimensiunile produsului și coletului;
• cerințele de siguranță, etichetare și documentele aplicabile;
• costul și statutul comercial;
• compoziția bundle-urilor;
• maparea către identificatorul ofertei din fiecare canal.

Separă produsul de ofertă. Produsul descrie obiectul; oferta adaugă preț, stoc publicat, termen, taxă de transport și statut pentru un canal. Un titlu adaptat sau un ID extern nu creează un SKU nou. Maparea poate arăta astfel:

Compari cere ca Identifier să fie unic și constant. Documentația Altex API separă produsele de oferte și publică operații pentru creare și actualizare. Acestea susțin modelarea, dar catalogul intern rămâne proprietarul identității.

Nu lăsa conectorul să inventeze mapări la prima trimitere fără să le salveze. Un export repetat poate crea dubluri ori poate lega oferta de o variantă greșită. Pentru fiecare mapare păstrezi data, sursa, statusul și ultima confirmare din canal. La respingere, cauza se atașează aceleiași entități, nu creezi un SKU „curat” care ocolește istoricul.

Bundle-ul este testul arhitecturii. Dacă vinzi un set format din două componente, o comandă a setului trebuie să rezerve ambele componente. Disponibilitatea bundle-ului se calculează din componenta limitativă. Un „stoc 10” introdus manual pentru pachet, fără legătură cu componentele, poate rămâne public după ce una dintre ele s-a epuizat.

Conținutul și conformitatea au propriul flux de aprobare. Conectorul poate transporta titlul și atributele, dar nu trebuie să rescrie automat avertismentele, responsabilul economic ori documentele de siguranță. Pagina Comisiei Europene despre siguranța produselor este un reper de verificare, nu o listă completă pentru orice categorie.

Versionează schema și valorile controlate. Dacă înlocuiești denumirea unei culori, unitatea ori taxonomia unei categorii, canalele pot accepta, respinge sau crea alte asocieri. Publică întâi pe un lot de control, citește răspunsul și abia apoi extinde. Pentru atributele derivate, salvează regula: titlul canalului poate fi compus din brand, model și variantă, dar sursele rămân câmpurile master.

Stabilește și procesul de retragere. Un produs blocat pentru conformitate sau siguranță trebuie oprit în toate ofertele, indiferent de stoc și campanie. Semnalul de blocare are prioritate asupra feedului comercial, produce alertă și cere confirmarea fiecărei destinații. Reactivarea necesită o aprobare nouă; nu dispare automat când conectorul vede din nou stoc pozitiv.

Sursa de stoc publică disponibilul cu un buget de latență

„Stoc sincronizat” nu este o stare binară. Între vânzarea pe un canal și actualizarea celorlalte există captură, import, validare, rezervare, export, procesare externă și confirmare. Chiar dacă fiecare pas funcționează, ultima unitate poate fi vizibilă simultan în două locuri.

Într-o arhitectură cu mai multe canale, miezul nu este o formulă repetată în fiecare conector, ci registrul mișcărilor. Recepția, rezervarea, anularea, pickingul, transferul, ajustarea și verdictul unui retur sunt tranzacții cu ID, SKU, locație, cantitate, motiv și timp. Disponibilul este rezultatul acelui registru la o versiune, nu un număr tastat în mai multe dashboarduri.

Un singur serviciu are dreptul să accepte ori să refuze rezervarea. Două comenzi pentru ultima unitate pot ajunge aproape simultan; ambele canale nu trebuie să citească „1” și să scadă ulterior. Operația de rezervare verifică și modifică aceeași versiune atomic, iar comanda care pierde primește un rezultat explicit. Conectorii nu decid singuri că stocul există.

ERP-ul, WMS-ul ori OMS-ul poate găzdui această autoritate, dar contractul este mai important decât acronimul. El definește cine scrie fiecare tip de mișcare, ce locații sunt vandabile, cum se calculează oferta fiecărui canal și ce confirmare înseamnă „publicat”. Storefrontul și marketplace-urile păstrează copii temporare. O corecție făcută direct acolo este ori interzisă, ori importată ca tranzacție separată; altfel următorul ciclu o va șterge fără explicație.

Pentru propagare folosești o ieșire tranzacțională: în aceeași operație în care se salvează rezervarea, sistemul înregistrează evenimentul ce trebuie trimis. Un worker îl publică, salvează răspunsul și îl poate relua. Astfel nu rămâi cu stoc scăzut intern și fără mesaj către canale doar fiindcă procesul s-a oprit între două salvări.

Documentează bugetul de latență pentru fiecare traseu:

Nu scrie „real time” dacă nu ai măsurat capetele fluxului. Unele destinații bazate pe feed preiau fișierul după propria cadență; Compari publică pe pagina curentă un moment de descărcare și un timp de procesare. Ghidul despre feedul de produse explică proiecția catalogului; aici tratăm consecința operațională a întârzierii.

Protecția comercială se aplică în stratul de publicare, după registru. Poți rezerva cantități pe canal, opri ultima unitate în destinațiile lente sau păstra o rezervă operațională. Regula nu modifică fizicul și nu se copiază ca stoc nou; produce o cantitate publicabilă pentru destinația respectivă și are termen de reevaluare.

În multi-depozit, fiecare unitate are locație și stare. Recepția, carantina, service-ul, returul și transferul există în registru, dar numai locațiile aprobate intră în promisiune. Transferul scade din sursă, intră „în tranzit” și crește destinația abia la recepție. Dacă îl numeri la ambele capete, creezi disponibil fantomă chiar cu API-uri perfect funcționale.

Testul este concurent și end-to-end. Trimiți două comenzi pentru ultima unitate, un bundle care consumă componente, o anulare după rezervare, un retur în carantină și un transfer întârziat. Verifici registrul, decizia de rezervare, evenimentul de ieșire, confirmarea fiecărui canal și cantitatea observată. Snapshotul egal la final nu este suficient dacă, între timp, ai acceptat o promisiune imposibilă.

Inventarul ciclic produce ajustări cu motiv și referință la numărătoare. Nu suprascrie soldul. Analiza tranzacțiilor explică dacă diferența vine din recepție, picking, transfer, retur sau mapare, iar reconstrucția la un moment dat rămâne posibilă. Aceasta este granița față de rutina eMAG din articolul dedicat: acolo urmărești oferta și indicatorii unui cont; aici construiești registrul comun care alimentează toate conturile.

Comenzile intră într-o coadă comună și rămân idempotente

O comandă importată nu trebuie să fie procesată de două ori dacă marketplace-ul retrimite notificarea sau dacă jobul este reluat după eroare. Cheia este idempotenta: aceeași combinație canal + ID comandă produce aceeași comandă internă, nu o copie nouă.

Fluxul minim este:

1. primești notificarea ori interoghezi canalul;
2. salvezi payloadul brut și momentul recepției;
3. verifici dacă ID-ul extern există;
4. validezi maparea SKU, cantitatea, adresa, plata și promisiunea;
5. creezi ori actualizezi comanda internă conform unei tranziții permise;
6. rezervi stocul într-o operație controlată;
7. confirmi procesarea sau lași evenimentul pentru retry;
8. publici noul disponibil către celelalte canale.

Nu transforma direct stările canalului în stări interne. Creează un model canonic și un tabel de mapare. De exemplu, „nouă”, „acceptată”, „pregătită”, „predată”, „livrată”, „anulată”, „retur deschis” și „retur închis” pot fi suficiente intern, dar fiecare canal poate avea stări intermediare și reguli diferite.

Păstrează payloadul brut chiar dacă lucrezi cu un conector. El este dovada a ceea ce a venit și permite re-procesarea când maparea a fost greșită. Datele personale se păstrează numai cât este necesar și cu acces controlat; jurnalul tehnic nu trebuie să devină o copie nelimitată a datelor clientului.

Comanda multiprodus și split shipment cer identificatori la nivel de linie și colet. O linie poate fi anulată, alta livrată, iar plata refundată parțial. Dacă sistemul are numai un status de antet, operațiunile și finanțele vor discuta despre comenzi diferite cu același număr.

Coada are trei rezultate: procesată, retry automat și intervenție umană. Erorile temporare de rețea pot fi reluate cu backoff. SKU necunoscut, adresă imposibilă ori tranziție contradictorie nu trebuie reluate la infinit; intră într-o coadă de excepții cu proprietar.

Ordinea evenimentelor nu este garantată pe toate integrările. Anularea poate ajunge înaintea notificării inițiale, iar confirmarea poate veni după un timeout. Folosește versiunea externă, timestampul sursei și regulile de tranziție, nu numai ora locală a recepției. Evenimentul vechi rămâne în jurnal, dar nu inversează o stare finală mai nouă fără o regulă explicită.

Păstrează o coadă moartă pentru mesajele care au epuizat retry-ul și un instrument de replay pe ID. Operatorul vede cauza, impactul și versiunea codului care a procesat. După corecție, replay-ul trece prin aceeași validare ca fluxul normal; editarea directă a bazei este ultimă soluție, aprobată și auditabilă.

Plățile, facturile și deconturile se reconciliază pe identificatori

Canalul de vânzare, procesatorul plății și emitentul facturii pot fi entități diferite. Marketplace-ul poate încasa și deconta net de taxe, magazinul poate încasa prin card sau ramburs, iar ERP-ul emite documentul. Integrarea trebuie să păstreze identitatea tranzacției dintre aceste lumi.

Pentru fiecare comandă urmărești:

• ID comandă extern și intern;
• ID plată, captură, ramburs și refund;
• număr de factură/storno și data fiscală;
• sumă produse, transport, TVA și discount pe baza validată;
• monedă și curs;
• comision, servicii și alte rețineri;
• sumă de încasat și suma virată;
• data decontului și diferența nereconciliată.

Nu marca „plătită” doar fiindcă marketplace-ul spune că plata clientului a fost acceptată. Pentru operațiune poate fi suficient să eliberezi comanda, dar financiar rămâne o creanță până la decont și bancă. La fel, plata ramburs poate fi livrată înainte să apară în extras.

Construiește trei reconcilieri:

Diferențele nu se distribuie automat „proporțional” ca să se închidă luna. O taxă la nivel de comandă urmează comanda. Un abonament și o penalitate rămân la canal. O ajustare veche se leagă de cohorta veche dacă există referință. Calculatorul de contribuție pe canal folosește aceste valori; MKT-21 se asigură că sunt complete și trasabile.

Factura și storno trebuie să urmeze regula fiscală a firmei și capacitățile canalului. Nu crea documente duplicate când webhookul este reluat. Salvează numărul rezultat și răspunsul emitentului, apoi fă retry numai pentru o cerere idempotentă ori după verificarea stării.

Pentru cross-border, moneda comenzii, moneda facturii și moneda decontului pot diferi. Păstrează suma originală, cursul și sursa cursului. Conversia unică într-o monedă managerială vine în raport, nu șterge valorile tranzacției.

Tratează refundul ca o tranzacție separată, legată de captură și de linia returnată. Poate fi total, parțial, inițiat, confirmat ori respins. Dacă platforma rambursează clientul înaintea decontului sellerului, sistemul financiar trebuie să păstreze creanța și taxa în starea corectă, nu să marcheze automat banca.

La închiderea perioadei, compari totalurile pe canal și apoi investighezi excepțiile. Numărul comenzilor, suma brută, TVA-ul, discounturile, refundurile, taxele și netul trebuie să poată fi reconstruite. Diferența de rotunjire are o categorie separată; nu devine recipient pentru documente lipsă.

AWB-ul și pickingul respectă promisiunea fiecărui canal

O coadă comună nu înseamnă că toate comenzile au aceeași prioritate. Fiecare păstrează promisiunea de livrare, cutoff-ul, serviciul, metoda de fulfilment și restricțiile canalului. OMS-ul traduce aceste cerințe într-un termen intern de picking și predare.

Separă momentele:

1. comanda este acceptată;
2. stocul este rezervat;
3. comanda este lansată în picking;
4. produsele sunt scanate și validate;
5. coletul este ambalat și etichetat;
6. AWB-ul este creat;
7. coletul este predat fizic;
8. trackingul este confirmat în canal;
9. livrarea ori excepția vine de la curier.

Crearea AWB-ului nu dovedește predarea, iar predarea nu dovedește că trackingul a ajuns în marketplace. Păstrează timestamp și actor pentru fiecare. Sănătatea contului eMAG are indicatori legați de performanță și estimarea livrării; detaliile complete cer cont, deci pragurile trebuie citite din dashboardul sellerului, nu copiate dintr-un ghid.

Pickingul folosește identificatorul intern și scanarea produsului, nu titlul din marketplace. Titlurile pot fi similare, trunchiate sau traduse. Pentru seriale, loturi și termene de expirare, scanarea leagă unitatea fizică de linia comenzii și permite un retur corect.

Regulile de rutare trebuie să fie explicabile. Alegi depozitul după disponibil vandabil, termen, cost, restricții și capacitate. Dacă o comandă ar necesita două colete, sistemul poate păstra împreună, împărți ori escalada. Decizia nu se schimbă opac de la o rulare la alta.

Ambalarea și etichetarea pot diferi pe canal. Creează profiluri: tip colet, documente incluse, etichetă, curier, serviciu și interdicții. Profilul este selectat din reguli, iar operatorul vede clar ce trebuie făcut. Nu pune instrucțiuni critice într-o notă liberă pe care conectorul o poate pierde.

La final, confruntă promisiunea publicată cu performanța observată. Dacă DeliveryTime din feed promite mai repede decât poate depozitul, corectezi oferta. Dacă depozitul îndeplinește, dar trackingul nu ajunge în canal, repari integrarea. Același simptom extern are cauze diferite.

Capacitatea se planifică pe valuri și cutoff-uri. Comenzile intrate după termenul unui curier pot avea altă zi promisă; cele urgente nu trebuie să sară o verificare obligatorie. Înaintea campaniei, testezi volumul prin coadă, imprimare, scanare, ambalare și predare, nu doar viteza API-ului.

Păstrează dovada predării: manifest, scanare, număr de colete și răspunsul curierului. Dacă canalul primește tracking, dar coletul rămâne fizic în depozit, clientul și indicatorii vor vedea o expediere fictivă. Reconcilierea zilnică AWB creat versus colet predat identifică aceste cazuri înainte să devină întârzieri.

Returul închide simultan fluxul financiar și inventarul

Returul nu este o comandă inversată printr-un singur buton. Are autorizare, transport, recepție, inspecție, decizie de stoc, refund, document fiscal și reconciliere. Ordinea contează: o unitate nu revine în disponibil înainte să fie verificată, iar un refund nu trebuie executat de două ori.

Modelul canonic include:

• ID retur intern și extern;
• comanda și linia originală;
• cantitatea și motivul solicitat;
• dreptul/politica aplicabilă și aprobarea;
• AWB retur și traseul coletului;
• data recepției și persoana care a inspectat;
• stare: sigilat, vandabil, recondiționabil, deteriorat, lipsă;
• locația de carantină ori stoc;
• suma de refund, metoda și documentul;
• taxele recuperate și costurile nerecuperate;
• momentul închiderii.

Returul parțial cere stare pe linie. Pentru bundle, inspecția confirmă componentele; nu adaugi automat setul complet în stoc când lipsește o piesă. Pentru schimb, creezi un retur și o expediere nouă legate, nu modifici retrospectiv produsul livrat.

Separă două aprobări. Operațiunile decid starea fizică și locația. Finanțele ori regula comercială decide refundul conform drepturilor și politicii. Sistemul poate coordona, dar nu trebuie să deducă automat „vandabil = refund integral” ori „deteriorat = fără refund” fără analiza aplicabilă.

Evenimentele trebuie să fie idempotente. Același mesaj „retur recepționat” nu adaugă stoc de două ori. Același callback de refund nu emite două storno-uri. Folosești ID-ul returului, versiunea și jurnalul răspunsurilor.

Păstrează carantina ca locație reală. Produsul recepționat nu devine publicabil până când verdictul este final. După verdict, tranzacția de stoc mută unitatea în vandabil, recondiționare sau pierdere. Apoi sistemul central recalculează disponibilul și îl publică tuturor canalelor.

Motivele de retur se mapează într-o taxonomie internă. Marketplace-urile pot folosi etichete diferite, iar clientul poate descrie liber. Nu pierde textul sursă, dar raportează cauza internă: produs, conținut, picking, transport, așteptare sau răzgândire. Astfel MKT-20 poate calcula costul, iar echipa de catalog poate repara cauza.

Termenele returului sunt urmărite pe ceasuri diferite: cererea clientului, transportul, recepția, inspecția, refundul și documentul. O întârziere la curier nu este aceeași cu un produs uitat în carantină. Alerta trebuie să indice etapa și proprietarul. Pentru dispute, păstrezi fotografii ori probe numai conform politicii de securitate și perioadei necesare.

Refundul și restocarea nu se blochează reciproc fără motiv. Poți avea obligația de a rambursa înaintea finalizării unei recuperări logistice sau poți ține produsul în carantină după refund. Modelul păstrează cele două fluxuri legate, dar distincte, astfel încât finanțele să nu aștepte o stare de stoc care nu le aparține.

Drepturile de acces și jurnalul schimbărilor limitează erorile

Integrarea bună reduce editările manuale, dar nu elimină nevoia lor. Când un incident cere oprirea urgentă a unui SKU, cineva trebuie să poată interveni fără să distrugă sursa de adevăr.

Aplică roluri distincte:

Jurnalul schimbării păstrează actorul, momentul, valoarea veche, valoarea nouă, motivul, canalul și ID-ul corelat. Pentru joburi automate, actorul este serviciul și versiunea sa. Logul tehnic are și ID de eveniment, număr de încercări și răspuns extern.

Nu păstra parole sau date personale inutile în jurnal. Secretul conectorului stă într-un manager de secrete, cu rotație și acces minim. Logurile maschează tokenurile, adresele și datele de plată. Dreptul de audit nu înseamnă copiere nelimitată.

Modificările riscante folosesc „patru ochi”: mapări masive, prețuri, activarea unui canal, schimbarea sursei de stoc și replay pe interval. O corecție singulară, reversibilă, poate avea alt prag. Matricea se scrie înaintea incidentului.

Pentru o intervenție manuală, creezi o suprascriere cu expirare și motiv. Sistemul știe să nu o calce până la termen, apoi cere reconciliere. Editarea directă și tăcută în canal pare rapidă, dar următorul sync o poate inversa fără urmă.

Alertele descriu acțiunea umană, nu doar eroarea tehnică

O integrare poate fi „verde” și totuși greșită: jobul a trimis stoc zero pentru întreg catalogul, a asociat alt SKU sau a marcat returul vandabil prea devreme. Monitorizarea are nevoie de sănătate tehnică și reguli de business.

Semnalele utile includ:

• eveniment blocat peste bugetul de latență;
• comandă fără SKU mapat;
• duplicate cu payload diferit;
• stoc negativ ori salt neexplicat;
• diferență mare între intern și ofertă observată;
• comandă acceptată fără rezervare;
• AWB creat fără predare sau tracking neconfirmat;
• retur recepționat fără inspecție;
• refund fără document ori document fără refund;
• decont și bancă nereconciliate;
• creștere anormală a anulărilor pe canal.

Fiecare alertă are severitate, proprietar, termen și runbook. Mesajul rău spune „sync failed”. Mesajul util spune ce entitate, ce canal, ultima stare bună, ce comenzi sunt expuse și care este acțiunea sigură. Include link către jurnal, nu date personale în notificare.

Deduplică alertele după cauză. Dacă API-ul cade, nu trimite câte un mesaj pentru fiecare SKU. Deschizi un incident părinte și listezi impactul. Dacă numai o mapare este invalidă, o izolezi fără să oprești toate comenzile.

Pragurile se calibrează după operație. Un SKU cu viteză mare și stoc mic cere alertă mai devreme decât unul lent. O comandă care expiră azi are prioritate față de un raport de preț. Nu importăm timpi universali din materiale comerciale; îi luăm din promisiunea canalului și din capacitatea internă.

Închide alerta numai după remediere și reconciliere. Retry-ul reușit nu garantează că evenimentele intermediare au fost procesate. Verifici comanda, stocul și starea din canal, apoi notezi cauza și prevenția.

Măsoară alertele care nu au cerut nicio acțiune și incidentele care nu au alertat. Primele arată zgomot; celelalte, goluri de detecție. Revizia ajustează semnalul, nu doar pragul. O regulă simplă de business — comenzi noi fără rezervare — poate fi mai valoroasă decât monitorizarea tuturor răspunsurilor HTTP.

Canalul de notificare are rezervă. Dacă aceeași aplicație care rulează integrarea trimite și alerta, căderea ei poate ascunde incidentul. Un heartbeat extern verifică ultimul eveniment sănătos și poate anunța pe altă rută. Datele sensibile rămân în sistem; alerta transmite identificatorul și impactul.

Planul de avarie oprește promisiunile înainte să piardă comenzi

Integrarea va cădea cândva: API indisponibil, token expirat, limită de apeluri, fișier invalid, schimbare de schemă, ERP oprit sau rețea întreruptă. Planul de avarie decide ce rămâne activ și cât risc accepți.

Definește modurile:

Planul răspunde înainte de incident:

1. cine declară modul și cine îl închide;
2. ce canal sau familii se opresc;
3. cum protejezi ultima unitate;
4. unde se acumulează evenimentele;
5. ce date capturezi pentru replay;
6. ce operații manuale sunt permise;
7. cum comunici cu depozitul și suportul;
8. în ce ordine revii;
9. cum verifici că nu ai duplicate ori goluri.

Replay-ul se face după o limită clară de timp și ID. Reprocesezi evenimentele idempotent, întâi într-un mediu de test sau pe un eșantion, apoi verifici totalurile. Nu apeși „retry all” fără să știi dacă unele comenzi au fost deja facturate ori expediate manual.

Păstrează exporturi locale ale entităților necesare operației, conform politicii de securitate: comenzi deschise, rezervări, mapări, stoc și ultima confirmare. Backupul nu ajută dacă nu poate fi restaurat. Exersează scenarii: canal indisponibil, sistem central indisponibil, curier indisponibil, webhook duplicat și fișier corupt.

După incident, reconciliezi fizic și financiar înainte să revii la viteză normală. Stocul, comenzile, AWB-urile, facturile, refundurile și deconturile trebuie să aibă un verdict. Lecția intră în runbook, test și monitorizare, nu doar într-un mesaj intern.

Stabilește obiectivele de recuperare după consecință, nu după ambiție tehnică. Cât timp poți opera cu stoc înghețat? Câtă informație poți pierde și reconstrui din canal? Ce comenzi expiră înaintea revenirii? Răspunsurile determină frecvența exporturilor, retenția cozii și ordinea restaurării.

Exercițiul de avarie trebuie să includă oameni. Rulezi o simulare cu responsabilul indisponibil, acces expirat și o intervenție manuală deja pornită. Verifici cine declară stop-sell, cine comunică depozitului și cine autorizează replay-ul. Un document perfect pe care nimeni nu îl găsește în incident nu este plan.

Revizia săptămânală urmărește excepțiile și schimbă sistemul

Nu verifica manual fiecare comandă dacă integrarea poate demonstra traseul. Verifică excepțiile, eșantioanele și totalurile de control. Revizia săptămânală leagă operațiunile, catalogul, financiarul și tehnicul.

Agenda poate fi:

• comenzi fără mapare, rezervare, AWB sau confirmare;
• discrepanțe de stoc intern–canal și durata lor;
• anulări din lipsă de stoc ori promisiune ratată;
• retururi în carantină și refunduri/documente deschise;
• diferențe comandă–decont–bancă;
• retry-uri, duplicate și intervenții manuale;
• SLA intern și promisiune pe canal;
• schimbări de schemă, token, contract sau integrare;
• acțiunile săptămânii trecute și efectul lor.

Pentru fiecare excepție păstrezi entitatea, prima apariție, impactul, cauza, proprietarul, acțiunea și termenul. Grupezi după cauză, nu numeri numai simptome. O mapare greșită care afectează multe comenzi este un singur defect cu impact multiplu; un șir de ajustări manuale poate indica un proces lipsă.

Eșantionul trebuie să traverseze fluxul: o comandă din fiecare canal, una multiprodus, una anulată, una returnată și una cu plată/decont diferit. Urmărești payloadul, rezervarea, pickingul, AWB-ul, factura, livrarea și, unde este cazul, returul. Dacă nu poți explica o comandă concretă, dashboardul agregat nu este suficient.

Revizia produce decizii, nu doar status. Poți modifica bufferul, opri un SKU, reface o mapare, schimba ordinea de retry, adăuga o alertă sau cere o funcție furnizorului. Schimbarea primește test și dată de reevaluare.

Pe măsură ce canalele cresc, urmărește munca manuală pe comandă și pe excepție. Automatizezi cauza repetitivă numai după ce regula este stabilă. O excepție rară și riscantă poate rămâne umană; un task frecvent și determinist merită eliminat. Scopul sistemului multichannel este ca fiecare canal nou să folosească aceeași coloană vertebrală, nu să angajeze încă o echipă care împacă dashboarduri.

Adaugă o revizie lunară a contractului de date: câmpuri noi, stări noi, endpointuri depreciate, cerințe de conformitate și permisiuni. Schimbările canalelor nu trebuie descoperite prin comenzi eșuate. Ownerul conectorului documentează impactul, testul și data migrării, iar catalogul și operațiunile validează rezultatul observat.

Înaintea unui canal nou, treci o comandă de test completă și un retur complet. Confirmi identitatea, rezerva, factura, AWB-ul, trackingul, refundul, restocarea și decontul. Lansarea catalogului întreg începe numai după ce traseul minim poate fi explicat de la sursă la document.

Întrebări frecvente

Am nevoie de ERP, OMS și WMS separat?

Nu obligatoriu. Ai nevoie ca rolurile lor să fie acoperite și fiecare entitate să aibă un proprietar. Un singur produs software poate acoperi mai multe roluri, dar granițele de date și procedura de avarie rămân necesare.

Ce sistem trebuie să dețină stocul?

Sistemul care poate reconcilia stocul fizic, rezervările, alocările și mișcările. Canalele primesc stoc publicabil; corecțiile lor trebuie controlate și aduse înapoi în nucleu.

Sincronizarea trebuie să fie în timp real?

Trebuie să respecte bugetul de latență și riscul SKU-ului. Măsoară de la eveniment până la oferta confirmată. Pentru destinații batch, protejează stocul prin buffer și reguli de publicare.

Când readaug produsul returnat în stoc?

După recepție și inspecție, când există un verdict vandabil. Cererea de retur sau trackingul curierului nu dovedesc starea fizică a produsului.

Cum previn comenzile duplicate?

Folosește cheia canal + ID extern, operații idempotente, versiuni și jurnalul payloadurilor. Retry-ul trebuie să actualizeze aceeași entitate, nu să creeze alta.

Ce opresc prima dată când integrarea cade?

Promisiunea pe care nu o mai poți garanta. Izolează canalul afectat, protejează ultima unitate și păstrează evenimentele pentru replay. Planul concret depinde de tipul căderii și capacitățile canalului.