Synkronisering av salg, lager og priser fra POS til ERP
POS til ERP: salg, lager og priser holdes i takt
Salg og returer posteres fra hver butikk, lager- og prisendringer sendes tilbake, og dagens sluttsummer avstemmes.
Blueprint
Rull sidelengs for å se hele tegningen.
POS til ERP: hvert salg posteres én gang
Salgsflyten fra kassene til ERP som hendelser, og priser og lager flyter tilbake. En butikk som går offline, fortsetter å selge og tar igjen det tapte. En postering som feiler, forsøkes på nytt og overleveres deretter til en person.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 8 steg
Forløpet, steg for steg
- Fra POS-terminaler til Butikk- eller POS-skyserver: Salg, returer og annulleringer (hovedforløp).
- Fra Butikk- eller POS-skyserver til Integreringslag: Salgshendelser og dagssluttotaler, gjennom en hendelseskø, over REST/JSON (asynkron).
- Fra Integreringslag til ERP: Salgs- og lagerbevegelser postert, over OData · REST/JSON (hovedforløp).
- Fra ERP til Integreringslag: Priser, kampanjer og varedata, via API eller fileksport, over REST/JSON (hovedforløp).
- Fra Integreringslag til Butikk- eller POS-skyserver: Pris- og lageroppdateringer, over REST/JSON (hovedforløp).
- Fra Integreringslag til Kø for nye forsøk: Postering feilet (unntaksbane).
- Fra Kø for nye forsøk til Integreringslag: Forsøkt på nytt (unntaksbane).
- Fra Kø for nye forsøk til Butikkdriftsteam: Feiler fortsatt: varsel med detaljene (unntaksbane).
Oversikt
Dette er flyten mellom kassene i butikkene dine og ERP-systemet bak dem. Salg, returer og annulleringer går opp til ERP. Priser, kampanjer, varedata og lager går ned igjen. Når de to kommer ut av takt, selger butikkene til feil pris, lagertallene slutter å bli trodd på, og økonomiavdelingen bruker månedsslutt på avstemming.
Referansedesignet sender hver butikktransaksjon som en hendelse gjennom et integreringslag med kø. Laget mapper hver hendelse til ERP-systemets salgs- og lagerdokumenter og posterer den nøyaktig én gang. I motsatt retning sendes endringer i ERP til butikkene som trenger dem, slik at hver kasse arbeider med de samme dataene.
Butikker mister forbindelsen, og designet forutser det. Butikken eller POS-skyserveren fortsetter å selge og tar igjen det tapte når linjen er tilbake. En postering som feiler, forsøkes på nytt, og en som fortsetter å feile, overleveres til en person med detaljene i stedet for å forsvinne.
Slik fungerer flyten
Selg i kassen
Hvert salg, hver retur og hver annullering registreres på POS-terminalen med en unik identifikator, butikken, kassen og tidspunktet.
Hold i butikken
Butikken eller POS-skyserveren samler transaksjonene og sender dem videre som hendelser, og holder dem trygt mens butikken er frakoblet.
Poster til ERP
Integreringslaget mapper hver hendelse til salgs- og lagerbevegelser og posterer den til ERP, og kontrollerer identifikatoren slik at ingenting posteres to ganger.
Send priser og varer
Varedata, priser og kampanjer publiseres fra ERP når de endres, med datoen og butikkene hver endring gjelder for.
Oppdater hver butikk
Laget leverer hver endring til butikkene den gjelder for, og registrerer hvilke butikker som har bekreftet den.
Når noe feiler
En postering feiler
Midlertidige feil forsøkes på nytt med økende ventetid. En postering som fortsatt feiler, går til en dead-letter-kø, og butikkdriftsteamet varsles med transaksjonen og feilen.
En butikk går frakoblet
Butikken fortsetter å selge på sine lokale data. Transaksjoner holdes tilbake og sendes i rekkefølge når forbindelsen er tilbake, og en butikk som er stille for lenge, utløser et varsel.
En transaksjon kommer to ganger
Hver transaksjon har en unik identifikator. Laget gjenkjenner en gjentakelse og ignorerer den, slik at en ny sending etter en driftsstans aldri dobler et salg.
Butikkens og ERP-summer avviker
Dagens sluttsummer fra hver butikk sammenlignes med det ERP mottok. En differanse åpner en gjennomgang med de manglende eller ekstra transaksjonene listet opp.
Standarder og systemer
- Data og analyse
- Apache Kafka
- ERP-systemer
- SAP S/4HANA
- Oracle NetSuite
- Microsoft Dynamics 365 Business Central
- Odoo
- Integrasjon
- REST
- Webhooks
- RabbitMQ
Spørsmål og svar
Skal salg posteres i sanntid eller satsvis?
Vanligvis som hendelser nær sanntid, fordi lager- og salgstall da er oppdaterte i løpet av dagen. Enkelte ERP-er eller lisenser gjør hyppige posteringer kostbare, så laget kan også gruppere hendelser i sammendrag per butikk og periode. Vi velger sammen med deg ut fra hvilke beslutninger som trenger oppdaterte data, og hva ERP-en håndterer godt.
Hvordan avstemmes sluttsummene for dagen?
Hver butikk sender sluttsummene for dagen fordelt på betalingsmåte og avdeling. Laget sammenligner dem med transaksjonene ERP-en mottok for samme butikk og dag. Stemmer de, lukkes dagen. Hvis ikke, viser gjennomgangen hvilke transaksjoner som mangler eller er ekstra, slik at teamet ditt kan rette årsaken i stedet for å postere en justering.
Kan kampanjer og prisendringer planlegges på forhånd?
Ja. Hver pris- eller kampanjeendring sendes med dato og hvilke butikker den gjelder, i forkant, slik at kassene bytter til rett tid uten at noen i butikken gjør noe. Laget registrerer hvilke butikker som bekreftet endringen, og flagger dem som ikke gjorde det.
Hvordan ruller dere dette ut i mange butikker?
Vi starter med en pilot i noen butikker og sammenligner summene deres med dagens prosess hver dag. Når summene stemmer, ruller vi ut i grupper, i et tempo butikkdriftsteamet ditt kan følge. Den gamle prosessen er tilgjengelig for hver butikk til den nye flyten er bevist.
Hvilke POS- og ERP-systemer fungerer dette med?
Løsningen fungerer med alle POS-systemer som kan eksportere transaksjoner via et API, hendelser eller filer, og med ERP-er som SAP S/4HANA, Oracle NetSuite, Microsoft Dynamics 365 Business Central og Odoo. Vi bekrefter grensesnittene til din POS og ERP i starten. At et produkt nevnes, betyr ikke at det er et partnerskap med leverandøren.
Hvem håndterer mislykkede posteringer når løsningen er i drift?
Det avtales før idriftsettelse. Vanligvis håndterer butikkdriften eller økonomiteamet ditt forretningsfeil, som en ukjent vare, fra en gjennomgangsliste, og det tekniske teamet håndterer feil i selve flyten. Vi kan levere denne tekniske støtten som del av en løpende avtale, med driftshåndboken delt med teamet ditt.
Start med en samtale, ikke en kontrakt.
Fortell oss hva du trenger å bygge, koble sammen eller sikre. En arkitekt går gjennom det med deg og anbefaler deretter hvor du bør starte.
Hva skjer videre
Avtale tid
Teamet vårt sender deg en e-post for å avtale tid til samtalen.
Forhåndssamtale
En gratis forhåndssamtale på 30 minutter på nett: vi går gjennom målene, systemene og begrensningene dine.
Modenhetsvurdering
I en gratis modenhetsvurdering innen 48 timer kontrollerer en ledende arkitekt prosjektet ditt mot definisjonen av klar (6 punkter) og anbefaler sporet som passer.
Valg av spor
Prosjekter med definert omfang får et bindende forslag innen 3 til 5 virkedager. Prosjekter i konseptfasen starter i Blueprint Studio. Et system i drift som svikter, er udokumentert eller trenger integrasjon, starter med en diagnose på 1 til 2 uker. Blueprint Studio og diagnosen har hver en fastpris som angis i forslaget.