Page Comparison

Detta dokument beskriver hur integrationen med Lagersystemet Ongoing Warehouse fungerar. Det finns ett par beslut / inställningar som måste göras för att en integration skall fungera, dessa beskrivs även med vilka alternativ som finns.

Slutligen finns även ett avsnitt som är instruktion till lagret, det finns vissa saker som man INTE får göra i Ongoing när man har ett integrerat system aktiverat, detta beskrivs även.  

Det är Extend Commerce Backend som hämtar och lämnar information hos Ongoing. Ongoing är en passiv part i denna integration. 

Hela syftet med integrationen är att Ongoing skall hantera den operativa lagerprocessen utifrån data (transaktioner) som kommer från Extend Commerce Backend. De processer som stöds i integrationen är följande:

1. Produkter

Alla produkter som finns på det lager i XTND i  Extend Commerce Backend som är kopplat till Ongoing kommer att skapas upp av Extend Commerce Backend i Ongoing. Det finns inget som hindrar att produkten redan är skapad i Ongoing. Men med denna process säkerställs att Extend Commerce Backend inte kommer skicka ner transaktioner till Ongoing på produkter som inte finns.

Produktnummer i Extend Commerce Backend kommer att hanteras som "artikelnummer/article number" i Ongoing. 

(Det finns ex möjlighet att hantera Backend's produktnummer såsom"Product code" i Ongoing, men det är inte standard och kräver anpassad mappning. Kontakta Kundtjänst & Support för detta)

Nedan är exempel på produktdata som synkas till Ongoing:

2. Förväntade inleveranser

Extend Commerce Backend kommer att skicka ner alla förväntade inleveranser till lagret till Ongoing. Förväntade inleveranser är tex. gjorda inköp, flytt mellan lager, aviserade returer.

Alla förväntade inleveranser, i ongoing benämnda "in-orders", skapas i Ongoing med status "Aviserad". 

När Ongoing har kvitterat mottagningen av inleveransen så kommer Extend Commerce Backend att uppdatera den förväntade inleveransen i Extend Commerce Backend med att den är mottagen. 

När det gäller returer så gäller detta för förväntade returer som är aviserade från Extend Commerce Backend till Ongoing. Det finns en separat process för hur man hanterar oaviserade returer som kommer till lagret, den processen beskrivs nedan.

3. Orders

Alla orders som skall plockas och skickas från lagret kommer att skickas från Extend Commerce Backend till Ongoing. (vanliga kundorders, men det kan även vara en flytt mellan lager order). Detta sker utifrån de normala reservations och plocktids beräkningar som sker i Extend Commerce Backend. 

När ordern är klar i Ongoing så kommer ordern att uppdateras i Extend Commerce Backend. (Här finns en del fördjupad beskrivning längre ner)

Lägsta intervallet vid synk utav orderkvittens är 1 timme.

4. Saldo

Saldot på produkterna uppdateras kontinuerligt via ovan beskrivna processer. Men Extend Commerce Backend gör även en kontroll saldo mot saldo mellan Extend Commerce Backend och Ongoing. Detta dels för att det finns inga andra "transaktioner" från ongoing för saldojusteringar och dels för att säkerställa att alla transaktioner har hanterats. När Extend Commerce Backend läser av ett saldo från Ongoing så kommer Extend Commerce Backend att hantera det som det riktiga saldot. Skillnad mellan XTND mellan  Extend Commerce Backend saldo och Ongoings saldo kommer att hanteras såsom en saldojusterings transaktion i Extend Commerce Backend. (Det finns således ingen skillnad på om en diff är pga en skrotning, svinn, internt skadat eller liknande. Alla diffar i saldo kommer hanteras såsom saldojustering)

5. Returorder

Returorder där returordern kommer till lagret oaviserat, och mottagning sker i Ongoing utan att det finns en avisering från Extend Commerce Backend. Extend Commerce Backend kan stödja denna metod. Om det är aktiverat så kommer Extend Commerce Backend att skapa returorders baserat på vad som är mottaget i Ongoing. Det går INTE ha en integration där man både kan hantera aviserade returer i Extend Commerce Backend samt Oaviserade mottagningar i Ongoing.

Här måste man bestämma vilken process man vill stödja som varuägare.

Följande saker måste de som hanterar lagret OCH varuägaren ta beslut om innan integrationen kan aktiveras. 

Saldo synkningen.

Det finns två saldon som kan synkas mot Extend Commerce Backend, vilket som skall användas beror på om varuägaren kommer att tillåta att fler system, eller om man tillåter manuella orders, får skicka orders till ongoing lagret eller om alla orders kommer att hanteras via Extend Commerce Backend. Detta beslut måste fattas av varuägaren för det påverkar hur och när man bokför lagervärden och har uppföljning på vad som sker på lagret. I de flesta fall är det lämpligast att använda den fullsynk av saldo som jämför tillgänligt saldo och inte fysiskt saldo. Detta då den även stödjer att order ligger plockade men inte skickade under tiden saldosynken görs.

Vidare finns  även möjlighet att synkronisera blockerat saldo, f.n. ligger det som ett option att aktivera och är inte del av standard.

Er projektledare hos oss eller Kundtjänst & Support måste få information om detta innan integrationen kan aktiveras. 

Att synkronisera saldo för stora mängder artiklar är tidskrävande. Normalt sett sätts saldosynk upp på ett schema, med en fullsynk per dygn. Det går också sätta upp synkronisering på timbasis. Vi rekommenderar då att man gör en "partial synchronization", vilket innebär att man bara synkroniserar artiklar där saldot har ändrat sedan föregående synkroniseringstillfälle. Detta reducerar kraftigt antal artiklar som måste stämmas av.  

Not: Partial synchronization synkroniserade ursprungligen alla ändrade produkter sedan förra synkroniseringstillfället, men ändrades sedemera till att synkronisera rena inventeringstransaktioner. Denna synk tar inte hänsyn till t.ex. manuella inleveranser, varför den ofta inte är tillräcklig för att hållla ett korrekt saldo. T.ex. lägga partial synk varje timma + fullsynk en gång per dygn får effekten att manuella inleveranser inte synkroinseras förrän vid fullsynk

Orderstatus

En order har olika status i Ongoing. För att göra det enkelt kan vi här säga att det finns två olika statusar som vi hanterar. En order kan vara Plockad eller så kan den vara Transportkvitterad. Extend Commerce Backend kan hantera ordern som färdig på någon av dessa statusar. Standard är att Extend Commerce Backend kommer att hantera ordern först när den är Transportkvitterad, detta för att då kommer vi även att kunna få transportinformation (sändningsnr etc. ) Så här behöver inget beslut tas såvida inte ordern skall hanteras redan vid status plockad. 

Avvikelse på plock

När det sker en avvikelse på plocket, tex. att man skulle skicka 4 st men lagret kvitterade inte ut 4 st (0 – 3 st kvitterades) så kommer inte Ongoing att tala om vad som skall hända med resten. Detta är något som hanteras i Extend Commerce Backend. 

I en sådan här situation så behövs en regelverk i Extend Commerce Backend. Det finns 3 alternativ och varuägaren behöver ta beslut om vilket alternativ man vill använda. 

1. Extend Commerce Backend automatiskt annullerar diffen.
   (obs detta gäller ju enbart på de rader som Extend Commerce Backend skickat till Ongoing för plock, om XTND om  Extend Commerce Backend har delleverans på ordern och skickat iväg delar av ordern så kommer resterande rader att hanteras, denna annullering gäller ju bara de diffar som kommer från det som Ongoing INTE skickade såsom planerat)
2. Extend Commerce Backend skapar en delleverans, med krav på manuellt beslut.
   Det som inte skickades hanteras som delleverans, men den raden får en status som är att manuellt beslut krävs. dvs den rest som blev kommer INTE att skickas för plock igen förrän någon har tagit manuellt beslut om detta. 
3. Extend Commerce Backend skapar en delleverans, utan krav på manuellt beslut.
   Det som inte skickades hanteras som delleverans och när Extend Commerce Backend ser att det finns saldo igen på produkten så kommer raden att skickas för plock (dock kommer vanliga restorderprinciperna på kunden i Extend Commerce Backend att gälla).

Returorder processen

Extend Commerce Backend kan stödja två olika retur order processer i förhållande till Ongoing. Antingen är returerna aviserade till lagret, eller så tillåter man kunderna att returnera varor till lagret utan att det är aviserat. Det går inte att hantera dessa två olika processer parallellt. Varuägaren behöver ta ett beslut och meddela projektledare eller Kundtjänst & Support vilken process man vill / kan stödja innan integrationen kan starta.  

Transporttjänster

När en order skickas från Extend Commerce Backend till Lagret så kommer en kod att skickas med, denna kod identifierar transportsättet. Ni som varuägare behöver bestämma vilka transportsätt som kommer användas och meddela lagret vilka koder som respektive transportsätt kommer ha.

Ni kan hitta information om vilka koder som kommer användas från de generella inställningarna i Extend Commerce Backend.

den kolumnen som heter Identifierare innehåller den kod som Ongoing lagret behöver känna till.

Om Lagret inte av någon anledning kan hantera dessa koder måste ni kontakta Kundtjänst & Support för diskussion om det skall tillföras speciella transporttjänster.

Lagret i Extend Commerce Backend (fråga till Varuägaren)

Extend Commerce Backend hanterar normalt sett ett eller flera lager, Extend Commerce Backend behöver veta vilket av era lager det är som skall kopplas ihop med ett fysiskt Ongoing lager. Om det är ett nytt lager, eller om det är ett existerande lager som flyttar / byter till ett Ongoing lager. Detta behöver vi få information om innan integrationen kan starta. Om det är ett befintligt lager som byter till Ongoing så måste varuägaren säkerställa att INGA pågående eller öppna transaktioner finns på det lagret vid tidpunkt för aktivering. 

När en integration mellan ett ordersystem (Extend Commerce Backend) och ett lagersystem (Ongoing) görs så finns det beteenden / funktioner i Lagersystemet som man INTE får göra/utföra. Om man gör det så kommer det att orsaka fel som behöver rättas.   

Aggregerat saldo

I Ongoing finns en möjlighet att aggregera saldot på en order. Tex. om en order kommer in med två rader, och det är samma produkt på bägge raderna. Rad 1 säger plocka 2 äpplen, och rad 2 säger plocka 4 äpplen. Då finns det en funktion i Ongoing som kan slå ihop detta till en rad där det står plocka 6 äpplen. Denna funktion FÅR INTE användas. Standard inställning i Ongoing är att denna funktion inte är aktiverad, men om det är gjort måste lagret stänga av funktionen. 

Kopiera en order.

Lagret får aldrig kopiera en order i Ongoing. 

Fältet beställt antal

Lagret får aldrig ändra fältet beställt antal. Det går att göra en inställning i Ongoing som inte tillåter detta. Vi rekommenderar att detta görs i Ongoing. Det är fältet plockat antal som lagret skall justera, inte beställt anta.

Byte av artikel

Det är ej tillåtet att byta artikel på ordern i Ongoing. Tekniskt är det möjligt att ändra artikelnummer på en order i Ongoing, men det får inte göras. 

Orderstatus

Sätt aldrig en order till klar / transportbokad innan plocket faktiskt skett. (i Ongoing är det möjligt att göra en transportbokning och kvittera det innan man har kvitterat raderna) Om detta sker kommer Extend Commerce Backend att tolka detta som att ordern är klar, transportbokad o skickad, men alla rader är 0 kvitterade.

Makulering av order.

Detta är mest för info, men om hela ordern makuleras makuleras i Ongoing, så kommer den att makuleras även i Extend Commerce  Backend. Detta kan användas om varuägaren säger att det är ok, men använd inte makulera funktionen om ni inte vet att varuägare accepterar att ordern blir makulerad även i Extend Commerce Backend.

Lagret som använder Ongoing måste ge Extend Commerce användaruppgifter till Ongoings API. 

Det finns en sida i Ongoing som beskriver detta, följ den och skicka uppgifterna till Extend Commerce

https://docs.ongoingwarehouse.com/Manuals/API-Access

GetOrdersByQuery

GetOrderStatusReports

GetInOrdersByQuery

GetInventoryByQuery

SetInventoryChangesToReported

GetInventoryChanges

ProcessOrder

ProcessInOrder

ProcessArticle

Integrationen går mot Ongoings SOAP API.