ERP ali WMS kot glavni vir
Poslovni sistem izračuna zalogo po skladiščih, integracija pa dogovorjeno razpoložljivo količino objavi v obeh trgovinah.
Zaloga · več trgovin · nadzor
Kako sinhronizirati zalogo med dvema spletnima trgovinama?
Najvarnejša povezava zaloge ne prepisuje količin brez konteksta. Najprej določi centralni vir, povezavo med različicami in lokacijami, nato pa obravnava časovni zamik, rezervacije, preklice ter ponovne poskuse.
En vir resnice
Ne začnite s smerjo trgovina A proti trgovini B.
Neposreden prenos količine iz prve trgovine v drugo je primeren le v zelo omejenem procesu, kjer prva trgovina zares vodi celotno zalogo. Pogosteje oba kanala prodajata iz istega fizičnega skladišča, zaloga pa se vodi v ERP-ju ali skladiščnem programu. Tak sistem naj bo glavni vir, trgovini pa prejemnici prodajne količine.
Če centralnega sistema ni, lahko vmesna aplikacija vzdržuje tehnično evidenco začetne količine in odšteva potrjene dogodke iz obeh trgovin. To je večja poslovna odgovornost: določiti je treba začetno stanje, rezervacije, preklice, vračila, ročne popravke in način fizične inventure. Takšna evidenca ni samodejno enakovredna skladiščnemu programu.
Ena trgovina kot glavni vir
Primerno le, če druga trgovina ne ustvarja neodvisnih sprememb, ki bi jih moral prvi sistem poznati. Tok in posledice morajo biti jasno opredeljeni.
Vmesna zalogovna evidenca
Smiselna samo z natančnimi pravili vseh dogodkov, redno uskladitvijo in jasno odgovornostjo za fizično stanje.
SKU, različice in lokacije
Isti izdelek mora biti na vseh straneh nedvoumno povezan.
Naziv izdelka ni primeren ključ, ker se spreminja in se lahko razlikuje med kanali. Vsaka prodajna različica, na primer velikost ali barva, potrebuje svoj stabilen SKU. Integracija poleg SKU-ja shrani tudi notranje identifikatorje izdelka, različice, zalogovne enote in lokacije v vsakem sistemu.
Pri več skladiščih določimo, ali se za posamezno trgovino uporablja ena lokacija, seštevek več lokacij ali posebna formula. Iz skupne fizične zaloge lahko odštejemo rezervirano količino, nedostopno zalogo in varnostno rezervo. Pravilo mora biti enako pri vsakem osveževanju ter dovolj razumljivo, da ga naročnik lahko preveri.
- stabilen in enoličen SKU na ravni prodajne različice
- tabela povezav notranjih ID-jev vseh sodelujočih sistemov
- dogovorjena merska enota in ravnanje s paketi ali kompleti
- preslikava fizičnih skladišč na lokacije posamezne trgovine
- formula razpoložljive zaloge in varnostna rezerva
- pravilo za neznan, podvojen, neaktiven ali manjkajoč SKU
Kompleti, sestavljeni izdelki in večkratniki pakiranja zahtevajo dodatno zalogovno formulo. Ne obravnavamo jih kot navaden artikel brez posebne specifikacije.
Dogodek in kontrolni urnik
Hiter prenos sprememb dopolnimo z redno polno uskladitvijo.
Če izvorni sistem pošilja zanesljive dogodke, nova sprememba zaloge ustvari opravilo skoraj takoj. Kadar dogodkov ni ali niso popolni, integracija po urniku prebere zapise, spremenjene od zadnje uspešne točke. Pri večjem katalogu jih obdeluje paketno in upošteva omejitve obeh API-jev.
Dogodek se lahko izgubi, povezava je lahko začasno nedosegljiva ali uporabnik ročno spremeni stanje. Zato hitri inkrementalni tok dopolnimo s periodično kontrolno uskladitvijo. Ta primerja izvorno in ciljno količino ter popravi potrjene razlike. Pogostost določimo glede na tveganje preprodaje in zmogljivost sistemov.
- 01
Prejem spremembe
Webhook, API filter ali urnik zazna spremenjen artikel in ustvari enolično opravilo.
- 02
Izračun razpoložljivosti
Uporabijo se izbrana skladišča, rezervacije, nedostopna količina ter varnostna rezerva.
- 03
Zapis v kanale
Količina se prek uradnih API-jev zapiše na povezano različico in lokacijo vsake trgovine.
- 04
Potrditev in dnevnik
Shrani se rezultat vsakega cilja. Začasno neuspešen cilj ostane v čakalni vrsti za ponovni poskus.
- 05
Kontrolna uskladitev
Po urniku se preverijo razlike in odkrijejo izpuščeni dogodki ali ročni posegi.
Realna omejitev spletne prodaje
Nobena API povezava ne zagotovi popolnoma sočasnega stanja.
Med nakupom, posodobitvijo glavnega sistema in zapisom v drugi trgovini obstaja časovni zamik. Dva kupca lahko v tem oknu kupita zadnji kos. Integracija tveganje zelo zmanjša, ne more pa odpraviti fizikalnega zamika med neodvisnimi sistemi. To mora biti jasno zapisano v pričakovanjih.
Najpogostejša zaščita je varnostna rezerva: v kanal objavimo nekoliko manj od dejansko razpoložljive količine. Pomagajo tudi pogosti dogodkovni prenosi, zadržanje naročil ob neveljavni zalogi, omejevanje prodaje pri nizkem stanju in jasen proces, če izdelka vseeno ni mogoče dobaviti. Izbira je poslovna odločitev, ne samo tehnična nastavitev.
- dogovorjena varnostna rezerva po izdelku ali skupini
- nižja zgornja meja količine, prikazane posameznemu kanalu
- hitrejši prenos za izdelke z majhno ali hitro spreminjajočo se zalogo
- opozorilo pri negativni količini ali večjem odstopanju
- postopek potrditve naročila in obravnave izjem
Kontrolna plošča
Uporabnik mora videti, ali sta obe trgovini prejeli spremembo.
Osnovna kontrolna plošča prikaže stanje povezav, čas zadnje uspešne obdelave, velikost čakalne vrste in rezultate zadnjih zagonov. Po SKU-ju je mogoče poiskati izvorno količino, izračunano prodajno količino, ciljne zapise ter zadnji odgovor vsake trgovine.
Neuspeh ene trgovine ne sme izbrisati uspešnega rezultata druge. Vsak cilj ima svoje stanje in število poskusov. Ročni ponovni poskus je dovoljen šele po odpravi vsebinske napake ali ponovni dosegljivosti API-ja. Dnevnik ne prikazuje gesel, dostopnih žetonov ali nepotrebnih osebnih podatkov.
- zadnji uspešen inkrementalni in kontrolni zagon
- število prebranih, spremenjenih, nespremenjenih in neuspešnih SKU-jev
- iskanje po SKU-ju, trgovini, lokaciji in rezultatu
- razumljiv opis napake in varen ponovni poskus
- opozorilo ob nedosegljivosti, naraščajoči vrsti ali večji razliki
Postopen prehod
Začnemo z majhnim naborom in primerjavo rezultatov.
Najprej uskladimo SKU-je in lokacije ter pripravimo poročilo manjkajočih povezav. Nato za nekaj izdelkov preverimo ničelno, nizko in visoko zalogo, različice, neaktiven izdelek, rezervacijo, preklic in začasno napako enega cilja. Preverimo tudi ponovitev istega opravila.
Po potrditvi vključimo omejeno skupino izdelkov, spremljamo rezultate in šele nato razširimo obseg. Pred polnim zagonom se dogovorimo, ali začetna uskladitev samo poroča o razlikah ali jih tudi samodejno prepiše. Pri tveganem prehodu je prvi način varnejši.
Cene, opisi, naročila ali kupci niso samodejno del zalogovne integracije. Dodamo jih kot ločene module z lastnimi smermi, preslikavami in testi.
Pogosta vprašanja
Pogosta vprašanja o zalogi med trgovinama.
Možnosti vedno preverimo na konkretnih sistemih, licencah, dostopih in vzorčnih podatkih.
Ali se lahko zaloga prenaša neposredno iz ene trgovine v drugo?
Lahko v omejenem procesu, vendar je varneje uporabiti centralni ERP, WMS ali drug glavni vir. Sicer lahko neodvisne prodaje in ročni popravki povzročijo krožno ali napačno prepisovanje.
Kako hitro se zaloga posodobi?
Odvisno od dogodkov, urnika, količine zapisov ter omejitev API-jev. Dogovorimo ciljni interval, vendar upoštevamo, da med neodvisnimi sistemi vedno obstaja določen zamik.
Ali integracija popolnoma prepreči prodajo izdelka brez zaloge?
Ne more je absolutno zagotoviti, ker lahko dve prodaji nastaneta med osvežitvama. Tveganje zmanjšamo z varnostno rezervo, hitrim prenosom, kontrolno uskladitvijo in poslovnim postopkom za izjeme.
Kaj se zgodi, če ena trgovina ni dosegljiva?
Uspešen zapis v drugem kanalu ostane zabeležen, neuspešni cilj pa čaka na nadzorovan ponovni poskus. Ob daljši nedosegljivosti sistem pošlje opozorilo.
Ali lahko seštejete več skladišč?
Da, če je formula natančno določena in API zagotavlja potrebne podatke. Upoštevati je treba rezervacije, nedostopno zalogo, varnostno rezervo in povezavo skladišč z lokacijami trgovin.
Začetni tehnični pregled
Pošljite povpraševanje