Fyra system, ett flöde: EDI-integration med Ongoing WMS och Fortnox

Livsmedelskedjorna kräver EDI. Lagret – ofta en tredjepartslogistiker – arbetar i Ongoing WMS. Ekonomin sköts i Fortnox. Tre system som var för sig fungerar utmärkt, men som inte är byggda för att prata med varandra. Så ser vardagen ut hos många växande livsmedelsföretag, och så såg den ut hos flera av våra kunder innan CloudOffice® blev navet som binder ihop allt till ett enda flöde.

I den här artikeln beskriver vi hur en EDI-integration binder ihop fyra system – och hur många gånger någon behöver skriva in ordern för hand. Svaret är noll.

Utgångsläget: en djurpark av system

Det är sällan någon som medvetet väljer att ha tre osammanhängande system. Det bara blir så. Kedjan – ICA, Dagab/Axfood eller Coop – ställer krav på EDI för att man över huvud taget ska få leverera. Lagret väljer sitt WMS utifrån sina behov, och Ongoing är vanligt bland svenska 3PL-lager. Fortnox har man haft sedan företaget startade, och revisorn vill gärna att det förblir så.

I bästa fall finns en koppling mellan Ongoing och Fortnox. Men EDI-ordrarna landar hos någon som får skriva in dem manuellt – i Fortnox, i lagrets system eller i båda. Följesedlar och fakturor skapas av en person som jämför utskrifter. När lagret plockat 47 kolli i stället för beställda 48 upptäcks skillnaden först när kedjan avvisar fakturan.

EDI i sig är sällan problemet – själva meddelandeutbytet går att lösa på många sätt. Kedjorna har egna leverantörsportaler, som hos ICA och Coop, och det finns oberoende EDI-tjänster där man tar emot ordrar och skickar bekräftelser, leveransaviseringar och fakturor via ett webbgränssnitt. Gemensamt för dem är att en människa hanterar dokumenten för hand: läser ordern i portalen, skriver in den i lagrets system och i Fortnox, och knappar sedan in leveransen och fakturan tillbaka. Meddelandena är elektroniska – arbetet är det inte. Det som saknas är inte EDI, utan orkestreringen: att order, plock, leverans och faktura hänger ihop över alla system utan handpåläggning.

Ett flöde – från butiksorder till bokföring

Med CloudOffice som nav ser samma order ut så här. Varje steg utlöses av det föregående, och ingen information skrivs in två gånger.

Steg	Var det sker	Vad CloudOffice gör
1. Butiken beställer	EDI (ORDERS)	Tar emot ordern, skapar en kundorder och skickar ett ordererkännande (ORDRSP) tillbaka till kedjan.
2. Ordern går till lagret	Ongoing WMS	Överför ordern automatiskt till lagret – direkt eller via Fortnox, beroende på uppsättning.
3. Lagret plockar	Ongoing WMS	Hämtar antal, batchnummer, bäst-före-datum och pallnummer (SSCC) från lagret.
4. Leveransen bekräftas	EDI (ORDRSP, DESADV)	Justerar kundordern efter det som faktiskt plockats, skickar orderbekräftelse och leveransavisering med full pallinformation.
5. Fakturan skapas	Fortnox + EDI (INVOIC)	Fakturan skapas i Fortnox på levererat antal och skickas som EDI-faktura till kedjan.
6. Krediteringar	Fortnox + EDI	En kreditnota i CloudOffice blir en kreditfaktura i Fortnox med referens till originalet – och en kredit-INVOIC till kedjan.

Även små detaljer följer med hela vägen. Pant är ett bra exempel: den ligger med i ordern från kedjan, går vidare till Fortnox och hamnar på fakturan – utan att någon behöver lägga till den för hand.

Det som levereras är inte alltid det som beställdes

Det är här de flesta integrationer faller. Att skicka en order från A till B är enkelt. Det svåra är allt som händer efteråt: en batch räcker inte, ett kolli är skadat, ett bäst-före-datum är för kort. Lagret plockar det som finns.

I flödet ovan är det lagrets verklighet som styr. När Ongoing rapporterar vad som faktiskt plockats – per artikel, batch och pall – uppdaterar CloudOffice kundordern och skapar utleveransen utifrån det. Orderbekräftelsen (ORDRSP) till kedjan visar de riktiga antalen, leveransaviseringen (DESADV) innehåller pallnummer, batcher och datum, och fakturan i Fortnox stäms av mot utleveransen innan den går som INVOIC.

Resultatet är att kedjans mottagning, följesedeln och fakturan säger samma sak. Det låter självklart, men för många leverantörer är avvisade fakturor och kreditkaruseller en återkommande post i månadsavslutet.

Samma princip, olika uppsättningar

Flödet ovan är en av flera varianter vi har i drift. Hos en kund går kundordern först till Fortnox och därifrån vidare till Ongoing, eftersom lagret redan hade en koppling dit. Hos en annan går ordern direkt från CloudOffice till Ongoing, och Fortnox får bara fakturorna. Vilken kedja som beställer spelar mindre roll – ICA, Dagab eller någon annan – så länge kommunikationen går via EDI.

Ordrarna behöver inte heller komma enbart via EDI. I flera projekt kompletteras EDI-flödet med AI som läser inkommande ordermejl och skapar kundordrar. Slutresultatet är detsamma: en kundorder i CloudOffice som följer samma väg till lager, kedja och bokföring.

Det som gör detta möjligt är att CloudOffice är byggt för att vara navet – med färdiga EDI-profiler för de svenska kedjorna, en färdig Fortnox-koppling och ett öppet API för lager- och andra system.

När ingenting händer är det ett gott tecken

Målet med uppsättningen är att systemet ska sköta sig självt. Ordrar kommer in, går till lagret, bekräftas, aviseras och faktureras – utan att någon behöver öppna ett program. I praktiken fungerar det som en svart låda.

Användarna loggar in i CloudOffice när något kräver ett beslut: en artikel som kedjan beställt men som inte finns i sortimentet, en leverans som behöver delas, en kreditering som ska godkännas. Då finns hela kedjan av dokument samlad på ett ställe – kundorder, utleverans, fraktsedel, faktura – med spårbarhet till både EDI-meddelandet och lagrets rapport.

Så fungerar EDI-integration i CloudOffice

EDI-kopplingen till ICA, Dagab/Axfood och Coop ingår som standard, med stöd för ORDERS, ORDRSP, DESADV och INVOIC enligt kedjornas specifikationer. Fortnox-integrationen synkroniserar kundordrar och/eller fakturor beroende på hur ni vill arbeta. Ongoing WMS är anslutet via API, och samma princip gäller för andra lager- och transportsystem – eller för CloudOffice egen lagerhantering om ni sköter lagret själva.

Fem frågor att ställa om ditt eget flöde

1. Hur många gånger skrivs en order in innan den är fakturerad?

2. Vad händer när lagret plockar färre kolli än beställt – vem uppdaterar orderbekräftelsen, följesedeln och fakturan?

3. Går batchnummer, bäst-före-datum och SSCC från lagret automatiskt in i leveransaviseringen?

4. Stämmer fakturan i bokföringen mot det som faktiskt levererats, eller mot det som beställdes?

5. Kan ni byta lager eller lägga till en ny kedja utan att bygga om hela flödet?

Vill du se hela flödet i praktiken?

Vi visar gärna hur en EDI-order går från butik till bokföring i en verklig miljö – med ert lager och er Fortnox-uppsättning som utgångspunkt.

Boka en demo

Företagsuppgifter och referenser lämnas på begäran.