Zaloge in povezave z dobavitelji
Zaloga dobavitelja: kako določiti količino za prodajo v spletni trgovini
Če dobaviteljeva datoteka navaja 12 kosov, to še ne pomeni, da jih spletna trgovina lahko ponudi 12. Del zaloge je lahko rezerviran, namenjen drugemu prodajnemu kanalu ali zadržan kot varnostna zaloga, podatek pa se lahko nanaša na drugo velikost oziroma skladišče. Pred izdelavo povezave določite pomen številke, trenutek rezervacije in odziv trgovine, ko vir zamuja.
Ekipa SVS Digital · Objavljeno
Začnite tukaj
Za vsako različico izdelka in lokacijo določite glavni vir posamezne vhodne količine ali izrecno pravilo združevanja ter jasno preslikajte identifikatorje. Količino za prodajo izračunajte samo iz podatkov, katerih pomen in svežino lahko preverite. Odštejte le rezervacije in varnostno zalogo, ki jih izvorna količina še ne upošteva, nato določite najdaljšo sprejemljivo starost podatkov in nadomestni postopek ob nedosegljivem ali nepopolnem viru. Pred spremembo celotnega kataloga preizkusite naročila, preklice, ponovljene posodobitve in izpade.
1. Povežite pravi izdelek, različico in lokacijo
Začnite z identiteto, ne s količino. Pripravite tabelo, ki povezuje identifikator različice v trgovini, interno šifro, dobaviteljevo šifro in, če je na voljo, GTIN. Vsako kombinacijo velikosti, barve, pakiranja in stanja obravnavajte kot ločeno različico, kadar ima lahko svojo razpoložljivost. Ujemanje zgolj po podobnem nazivu ni zanesljivo; neznano šifro uvrstite na seznam za ročni pregled.
GS1 opredeljuje GTIN kot enolični identifikator trgovinske enote, ki ji določimo ceno, jo naročimo ali zanjo izdamo račun. GTIN pomaga pri ujemanju, ne nadomesti pa preslikave, kadar dobavitelji uporabljajo lastne šifre ali različne ravni pakiranja. Shopify ločuje kupcu vidno različico izdelka od zalogovne postavke, količine pa vodi po lokacijah. Te razlike zapišite v specifikacijo izmenjave podatkov.
- Identifikator različice v trgovini in interna šifra.
- Šifra izdelka pri dobavitelju ali v ERP-ju.
- Velikost, barva, pakiranje in druge lastnosti, povezane z zalogo.
- Lokacija ali skladišče, ki ga predstavlja zapis.
- Odgovorna oseba in postopek za neznano ali podvojeno šifro.
2. Ločite fizično zalogo od količine, ki jo smete prodati
Zapišite pomen vsakega vhodnega polja. Fizična zaloga, razpoložljiva zaloga, pričakovana dobava in količina, ki jo trgovina lahko obljubi, niso ista vrednost. Shopifyjev model na primer ločuje razpoložljivo, že dodeljeno, rezervirano, poškodovano, varnostno zalogo in zalogo v kontroli kakovosti. Rezervacije ne odštejte dvakrat, če jo dobaviteljevo polje »razpoložljivo« že upošteva.
Uporabite formulo, ki jo ekipa lahko razloži, na primer: količina za prodajo = izvorna količina – rezervacije, ki v njej še niso upoštevane – varnostna zaloga, ki v njej še ni upoštevana. Če vir posreduje le fizično stanje, določite, katere potrjene rezervacije oziroma odprta naročila ga še ne zmanjšujejo, in odštejte samo te. Če prednaročil ne omogočate, rezultat omejite na najmanj 0; za prednaročila določite ločeno pravilo. Določite tudi merske enote in zaokroževanje. Kosov, paketov in kartonov ne mešajte brez izrecne pretvorbe.
- Natančna opredelitev izvorne količine.
- Ali so rezervacije že vključene ali izključene.
- Pravilo varnostne zaloge po izdelku ali skupini.
- Merske enote in pretvorba pakiranj.
- Obravnava negativnih in nenavadno velikih vrednosti.
3. Določite trenutek rezervacije v vseh prodajnih kanalih
Če naročila sprejemajo spletna trgovina, prodajna ekipa in spletna tržnica, občasno kopiranje zaloge ne zazna povpraševanja, ki še ni doseglo izvornega sistema. Izberite dogodek, ki rezervira kos. Rezervacija že ob dodajanju v košarico lahko po nepotrebnem zadrži zalogo, rezervacija šele ob odpremi pa pušča daljše obdobje, v katerem lahko več kanalov proda isti kos. Primeren dogodek je lahko potrditev naročila, odobritev plačila ali drug poslovni dogodek, vendar morajo vsi kanali uporabljati med seboj usklajeno pravilo.
Microsoft opisuje mehke rezervacije kot način vzdrževanja skupnega pregleda nad količino, ki je na voljo za rezervacijo v več sistemih za sprejem naročil: kanal zahteva rezervacijo, storitev zmanjša razpoložljivost za rezervacijo, mehko rezervacijo pa je treba pozneje izravnati, ko se naročilna vrstica fizično rezervira ali se posodobi fizična količina zaloge. Odoo ponuja več možnih trenutkov rezervacije, zato ni splošno veljavnega privzetega trenutka. Preklic, potek rezervacije in neuspešno plačilo opredelite enako skrbno kot nastanek rezervacije.
- Dogodek, ki ustvari rezervacijo.
- Sistem, ki preveri razpoložljivost.
- Oznaka, ki poveže rezervacijo z vrstico naročila.
- Dogodki, ki rezervacijo porabijo, prekličejo ali sprostijo.
- Pravilo, ko prodajni kanal ne doseže rezervacijske storitve.
4. Določite mejo svežine in odziv ob izpadu
Določite, kako star je lahko zadnji uspešno prejeti podatek, preden ga obravnavate kot zastarelega. Meja naj upošteva hitrost sprememb, običajni interval prenosa in posledice napačne obljube kupcu. Shranite časovni žig vira, če je na voljo, in čas obdelave v integraciji. Datoteka, prejeta danes, lahko vsebuje včerajšnji posnetek stanja.
Nadomestni postopek določite vnaprej. Glede na izdelek lahko za kratek čas ohranite zadnjo preverjeno količino, jo zmanjšate, ustavite prodajo, prikažete daljši dobavni rok ali zahtevate ročni pregled. Manjkajoča vrstica še ne dokazuje ničelne zaloge, nepopolna datoteka pa ne sme nastaviti zaloge celotnega kataloga na nič. V opozorilu imenovani odgovorni osebi navedite razlog, obseg težave in čas zadnjega uspešnega prenosa.
- Običajen interval in najdaljša sprejemljiva starost podatka.
- Čas iz vira in čas obdelave.
- Najmanjše pričakovano število zapisov v datoteki.
- Rezervni odziv glede na tveganje in hitrost prodaje.
- Prejemnik opozorila in čas za stopnjevanje težave.
5. Spremembe naj bodo sledljive in varne ob ponovni obdelavi
Pri vsaki spremembi količine zabeležite vir, izdelek, lokacijo, prejšnjo in novo vrednost, vhodne podatke izračuna, čas ter rezultat. Shopifyjev API omogoča, da spremembi dodate URI sklica na dokument, ki jo poveže z izvornim sistemom ali poslovnim dogodkom. Mehanizem je odvisen od platforme, načelo pa je splošno: zaposleni mora znati pojasniti, zakaj se je razpoložljivost spremenila.
Vsakemu uvozu ali dogodku dodelite enolični, nespremenljivi identifikator, da se ob ponovni obdelavi ista sprememba ne uporabi dvakrat. Absolutni posnetek stanja in relativna sprememba količine zahtevata različno obravnavo. Napačne vrstice zavrnite pred zapisom, neuspešne postavke ločite od uspešno obdelanih in omogočite primerjavo stanja v trgovini z glavnim virom ali dogovorjenim rezultatom združevanja.
- Enolična oznaka uvoza, dogodka ali dokumenta.
- Stara in nova količina z vhodnimi podatki izračuna.
- Ponovitev brez podvojene spremembe.
- Ločena števila posodobljenih, nespremenjenih, zavrnjenih in manjkajočih zapisov.
- Poročilo o neusklajenih razlikah.
6. V pilotu preizkusite napake, ne le pravilnega poteka
Za pilot izberite majhno skupino, ki vključuje preproste izdelke, več različic, vsaj en izdelek z nizko zalogo in vsaj eno zahtevno preslikavo. Preizkusite običajno prodajo, dve skoraj sočasni naročili, preklic, vračilo, neznano šifro, podvojeno datoteko, zamudo, delno datoteko, izpad vira in ponovni uvoz. Vsak rezultat primerjajte z glavnim virom ali dogovorjenim rezultatom združevanja, oseba, odgovorna za izjeme, pa naj sama izvede postopek obnove.
Periodična integracija sama po sebi ne zagotavlja, da je prikazana razpoložljivost ves čas pravilna: prodaja lahko nastane med posodobitvama, dobaviteljev podatek je lahko napačen, sistem pa nedosegljiv. Pogostejša sinhronizacija skrajša zamik, ne odpravi pa nejasnega lastništva procesa in neusklajenih rezervacij. Obseg povečajte šele, ko lastnik procesa sprejme preostalo tveganje ter potrdi nadzorni in ročni nadomestni postopek.
- Potrjena formula za izdelke v pilotu.
- Preizkušeni dogodki rezervacije in sprostitve.
- Preizkušeni zastareli, delni in podvojeni vhodi.
- Primerjava brez nepojasnjenih razlik.
- Imenovan lastnik opozoril in ročnih popravkov.