FELTNOTATER / Inventar og kanaler

Hvordan synkronisere lageret? Først, klargjør SKU-er og tilgjengelig lager for salg

Start fra SKU, tilgjengelig lager, oppdateringsretning og retry-regler for å unngå "koblet til API" men med uoverensstemmende lagerdata.

Ansatte i kjedebutikker bruker håndholdte skannere og nettbrett for å sjekke og overføre kartonger. Blå hevede hyller, overleveringsvogner og lasteganger viser fraktscener fra flere butikker, sceneillustrasjoner
Lageroppfylling og butikkfordeling · Sceneillustrasjon

Se først på konklusjonen.

Når butikk- og nettbutikklageret synkroniseres, bør SKU-er og lagre først være samlet, slik at systemet som er ansvarlig for produkter og mengder, deretter defineres salgbart lager, synkroniseringsretning og unntakshåndtering. Salgbart lager må ta hensyn til opptatt og midlertidig utilgjengelig lager. AllinWebPOS tilbyr butikkprodukt- og lagerstyring og kan planlegge OpenCart-integrasjon eller Shopify tilpasset integrasjon etter forretningsbehov.

Ta prosessen ut i butikken

Butikken legger inn forespørsel, hovedkontoret bekrefter omfanget, lageret forbereder varen etter overføringslogg, og både utsendte og mottatte mengder kan verifiseres.

  1. Butikk

    Legg inn varebestilling

    Organiser spesifikke varer, spesifikasjoner og mengder basert på salg og lager.

  2. Hovedkontor

    Bekreft overføringen

    Bekreft leveringsoppsettet denne gangen i henhold til butikkområde og godkjenningsfordeling

  3. Lager

    Plukk og send ut varer

    Sammenlign overføringsposter, plukk og dobbeltsjekk, og registrer utsendte mengder.

  4. Butikk

    Kvitteringsbekreftelse

    Sjekk mottatte spesifikasjoner og mengde, noter avvik og overlever videre behandling.

Samle først produktidentifikasjon.

Samme modell i forskjellige farger eller størrelser må bruke unike SKU-er. Lag en kobling mellom butikkens SKU og nettbutikkens produktspecifikasjoner, sjekk kombinasjonsprodukter, gaver og utgåtte produkter. Samme navn kan ikke brukes som en pålitelig unik identifikator, strekkode og eksternt produktnummer bør også kontrolleres for unikhet og tilhørighet.

Tilgjengelig lager er ikke bare en enkel eksisterende mengde

Nåværende lager kan inkludere reserverte, ventende kvalitetskontroll eller uselgelige varer. Forretningsfolk bør forklare hvordan salgbart lager beregnes, hvilke lager som selger til nettbutikk, og om butikkene holder sikkerhetslager. Bruk reglene på et sett med ekte varer for å sammenligne antall sett butikkene og nettbutikken ser.

For eksempel, Shopify deler beholdningen i tilgjengelig, forpliktet og utilgjengelig. Mengder som allerede er brukt av ordre eller midlertidig ikke kan selges, skal ikke telles som tilgjengelig igjen; på vei-mengder må også vurderes separat fra tilgjengelige mengder etter ankomst. Offisielle ressurser nedenfor kan hjelpe teamet å sammenligne med gjeldende nettbutikkbeholdning.

Velg oppdateringsretning og håndter konkurranse

Når begge sider kan endre lagerbeholdning, må det være klart hvem som har prioritet ved konflikt. Når bestilling, betaling, kansellering og retur skjer, må fradrag eller retur skje i henhold til regler. Masse-synkronisering kan overskrive nye bestillinger under synkroniseringen og skape feil i lagerbeholdningen; hendelses- eller versjonslogg bør beholdes.

Behandle feil som en formell prosess

List opp hvordan man håndterer grensebegrensninger på grensesnitt, utløpte autorisasjoner, manglende produktkartlegging og duplikathendelser. Synkronisering bør kunne prøves på nytt, og gjentatt utførelse bør unngå dobbel reduksjon. Sett til side poster som krever manuell bekreftelse, og sjekk mot lagerendringer på eksterne plattformer, ikke bare interne oppgavesuksesser.

Plan butikktilgang basert på driftsprosesser

Tilgang til nettbutikken bør starte fra din faktiske driftsprosess og klargjøre hvordan produkter, salg, kanselleringer og returer kobles mellom de to systemene. For handelsfolk som allerede har OpenCart eller Shopify-nettbutikker, kan dere gi oss plattformversjon og forretningsbehov, og sammen planlegge produktsammenkobling, ordrebehandling og lageroppdateringsomfang.

Bruk ett produkt med to varianter for å verifisere lagerstatus.

Ta to farger av samme ryggsekk som eksempel: Lageret har ti grå og seks grønne, hvorav to grå er reservert for nettbutikkordrer. Hvis avtalt, trekkes tilgjengelig beholdning fra reserverte, så er grå tilgjengelig for salg åtte. Hvis det holdes en sikkerhetsbeholdning på to for butikken, bør nettbutikkens visning være seks. Tallene her brukes bare for å forklare, de er ikke systemets standardregler.

La butikken selge en ekstra grå ryggsekk, sjekk når butikkregistrering og nettbutikkmengde endres. Etter kansellering av reserverte bestillinger bør de relevante mengdene gjenopprettes, og dette bør også skrives som forventet resultat.

Hvilke anomalier er mest verdt å teste først?

Test først SKU-er uten kartlegging, nye ordre under synkronisering, dupliserte ordre av samme ordre, samt utløpt autorisasjon på eksterne plattformer. Tenk deretter på ulike lagre, kombinasjonsprodukter og returinnlagring. Når du tester, behold originale systemhendelser, interne behandlingslogger og den endelige mengden på eksterne plattformer, slik at du kan finne ut om problemet ligger i kartleggingen, lagerberegningen eller API-kallet.

Hvis oppgaveloggen viser suksess, men det eksterne antallet ikke endres, bør du ikke overskrive data gjentatte ganger. Sjekk først om kallet faktisk ble utført, om riktig produkt og lager ble besøkt, og om plattformen godtar oppdateringen. Sammenlign samtidig med nettbutikkens produktmengde for å bekrefte at oppdateringsresultatet samsvarer med butikkens lagerstandard.

Hvorfor la manuell sjekk ha en inngang?

Noen forskjeller kommer fra virkelig virksomhet: ødelagte varer, midlertidig flytting av varer, justering av lagerbeholdning eller varer som ikke returneres etter refusjon. Disse situasjonene kan ikke løses kun gjennom 'automatisk synkronisering'. Å beholde årsak til avvik, opprinnelig ordrenummer og hvem som har behandlet det, hjelper med å avgjøre om forretningsregistrene må korrigeres eller om grensesnittoppgaven må kjøres på nytt.

Før butikkkampanjer bør det arrangeres en avstemming: trekk ut produkter med forskjellige spesifikasjoner, etter-salg og lagerjusteringer, og sammenlign fysiske varer, systemregistreringer og tilgjengelige mengder i nettbutikken. Reglene for å håndtere avvik bør være forståelige for både lagerpersonell, butikkledere og teknikere, og ikke bare finnes som kommentarer i utviklerkoden.

Avtal først lagernivå

Avtal beholdningskriterier først · Referanse for forretningsvurdering
KonseptBetydningSpørsmål som må bekreftes
Eksisterende lagerNåværende registrerte fysiske antallHvilke lager og status er inkludert?
ReserveinventarMengde tildelt ufullførte ordreNår reserveres og frigjøres?
SikkerhetslagerBehold kvote for drift på stedetEr det satt etter butikk eller kanal?
Tilgjengelig lagerMengden som skal leveres til kanalen etter avtaleHvordan beregne, og hvem oppdaterer?

Landingssjekkliste

  • Etabler en unik kartlegging for hver spesifikasjon
  • Avtalt lager og salgbart lagergrunnlag
  • Bekreft fradrag, refusjoner og konfliktregler
  • Bekreft plattformresultater og prøv igjen ved feil

Referanser

La driftsforslag brukes i butikken din

AllinWebPOS Business Guide fokuserer på de daglige utfordringene innen detaljhandel og servering. Vil du vite hvordan prosessene beskrevet i denne artikkelen kan anvendes i din virksomhet?Kontakt oss for å avtale produktdemo。

Videre lesning:Varer og lager · Online og offline drift