Korleis sender du ut ei prisendring til alle utsalsstader utan å redigere kvar kasse?

Du sender ut ei prisendring til alle utsalsstader ved å gjere endringa éin gong, i ein sentral katalog, og låte kvar kasse lese frå han. Det er heile svaret. Dersom systemet ditt i staden krev at du går til kvar enkelt kasse, koplar deg til seks bakromsdatamaskiner via fjernstyring eller lastar inn ei fil frå ein USB-penn, ligg ikkje prisen verkeleg i prislista di. Han ligg i maskinvara. Og ein pris som ligg i maskinvara må endrast der maskinvara står.

Kvifor tyder ei prisendring at du må redigere kvar kasse?

Fordi eldre POS-system behandlar kvar kasse som ein eigen liten database. Eininga lagrar ei lokal prisbok (kassa si lagra liste over varer og prisar), og kassen les frå denne lokale kopien. Hovedkontoret kan ha eit perfekt hovudrekneark, men kassen veit ikkje at det finst. Når kassen er sanningskjelda (kopien alle faktisk stolar på), må kvar kasse få beskjed om endringa individuelt.

Dette designet gav meining då kasser var fråkopla maskiner og internettsamband var ein luksus. Det slutta å gje meining for mange år sidan, men datamodellen overlevde i mange installerte system, og i nokre nyare som kopierte han. Resultatet er det same mønsteret som nattlege CSV-eksporter i staden for skikkeleg rapportering: tilsette som kjører ein permanent manuell rutine for å kompensere for kor dataa ligg.

Kva kostar prisredigering per kasse deg eigentleg?

Meir enn kvelden det tek. Dei føreseielege feila:

• Avvik mellom utsalsstader. Den same SKU-en (unik produktkode) slåast inn til ein pris i sentrum og ein annan på kjøpesenteret fordi éin kasse vart gløymd i mars. Ingen merkar det før ein kunde gjer det. Lagerregistreringar sprikjer alt på eiga hand; handkopierte prisar sprikjer raskare.

• Gløymde einingar. Ei kasse som var midt i eit sal, slått av eller rett og slett gløymd under oppdateringa, beheld den gamle prisboka, og ho vil gladelag ta den gamle prisen i vekevis.

• Hylleprisar og kvitteringar stemmer ikkje overeins. Kvar manuelle runde med redigeringar er ein ny sjanse for at den skanna prisen sluttar å stemme med etiketten på hylla, og ein kunde som oppdagar spriket stolar litt mindre på alle dei andre prisane i butikken din.

• Utydelege rapportar. Når eit produkt selst til tre ulike prisar i same veke, sluttar marginrapportar å ha noko særleg meining, og avstemming (å samordne rapportane dine med pengane som faktisk flytta seg) blir til arkeologi.

• Arbeid etter stengjetid. Redigeringar per kasse må vente til stengjetid, så dei enten kostar overtid eller så må dei vente. Når ein leverandørpris alt har gått opp, er kvar dag du ventar ein margin du gjev bort.

Kva naudløysingar held stand på eit system med redigering per kasse?

Dersom du sit fast med prissetjing per kasse i dag, er det nokre rutinar som sviktar sjaldnare enn andre:

1. Oppdater i bolkar, tast aldri inn på nytt. Hald på éi hovudprisfil og last han inn via eksport- og importverktøya til systemet, sjølv om du må gjere det eining for eining. Å taste inn tal på nytt på eit tastatur er der feil blir fødde.

2. Utnevn ei hovudkasse. Dersom systemet ditt kan kopiere konfigurasjonen frå éi kasse til dei andre, gjer ein enkelt eining til kjelde og klon ho. Halv synkronisering er betre enn inga.

3. Ta kontroll over endringsvindauget. Éin person, éi datert hovudfil, éi sjekkliste med kvar enkelt eining på. Mesteparten av avvika kjem av «Eg trudde du tok kasse 2».

4. Verifiser ved å skanne, ikkje ved å sjå. Etter oppdateringa slår du inn eit testsal for nokre endra varer på kvar utsalsstad. Eit innstillingsskjermbilde kan seie éin ting medan kassen slår inn noko anna.

5. Før ein logg over prisendringar. Når det dukkar opp avvik seinare, er ein datert logg skilnaden mellom ein diagnose og ei gjetting.

Ver ærleg om kva dette er: vedlikehald av ein designfeil. Det ligg i same kategori som å fjerne mva. manuelt for kvar mva.-fritatt kjøpar, ein person som gjer til evig tid det datamodellen burde ha gjort éin gong.

Korleis bør ei prisendring eigentleg fungere?

Prisen bør liggje på akkurat ein stad: ein sentral katalog i skya, der kvar kasse fungerer som ein klient for den katalogen i staden for å eige sin eigen kopi. Endra produktoppføringa, og det er ingenting å sende ut, fordi ingenting anna held på ein pris. Dette er kjerneargumentet for skysystem framfor tradisjonelle installasjonar, noko som er omtalt i POS-system for alle typar verksemder: Kva type passar for deg?

I Final POS er katalogen byggd på denne måten. Produkta ligg i éi produktliste i Merchant Hub, pris er eit felt på produktoppføringa, og utsalsstader (butikkane dine) styrer kor kvart produkt blir selt. Kvar stasjon på kvar utsalsstad les den same oppføringa, så å redigere prisen éin gong er heile jobben.

To ærelege atterhald. Ei kasse må framleis vere påkobla for å ta imot ei oppdatering, så verifiseringssteget krympar til å stadfeste at einingane er tilkopla, ikkje å taste inn tal på nytt. Og dersom du med vilje tek ulike prisar på ulike utsalsstader, er det ei prissetjingsavgjerd som høyrer heime i katalogen som ein regel, ikkje noko du skal gjenskape ved å la kasser gli frå kvarandre manuelt.

Så, korleis sender du ut ei prisendring til alle utsalsstader utan å redigere kvar kasse?

På eit system per kasse gjer du ikkje det. Du samlar endringane i bolkar, klonar dei der systemet tillèt det, og verifiserer med testskanningar, fordi designet ikkje tilbyr noko betre. På eit system med ein sentral katalog redigerer du produktet éin gong, og så er du ferdig. Tommelfingerregelen: dersom det å endre ein pris tyder at du må ta på maskinvare, eig kassene dine katalogen din i staden for omvendt. Dersom du vurderer eit nytt system, set «endre éin pris og vis meg at han nådde kvar kasse» på demomanuset ditt, og gå deretter gjennom ei sjekkliste for oppsett den første veka når du byter.