Versions Compared

Old Version 1

changes.mady.by.user pontus Carme

Saved on

compared with

New Version Current

changes.mady.by.user Ellen Fransson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduktion

Panel
borderColor#dbdbdb

Detta dokument beskriver hur integrationen med POS (point of sale, eller kassasystemet) Shopbox 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. 

Övergripande beskrivning.

2. Förväntade inleveranser

Extend 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. 
När Ongoing har kvitterat mottagningen av inleveransen så kommer Extend att uppdatera den förväntade inleveransen i Extend 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 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 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. 
När ordern är klar i Ongoing så kommer ordern att uppdateras i Extend. (Här finns en del fördjupad beskrivning längre ner)

4. Saldo

Saldot på produkterna uppdateras kontinuerligt via ovan beskrivna processer. Men Extend gör även en kontroll saldo mot saldo mellan Extend 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 läser av ett saldo från Ongoing så kommer Extend att hantera det som det riktiga saldot. Skillnad mellan Extends saldo och Ongoings saldo kommer att hanteras såsom en saldojusterings transaktion i Extend. (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.  Extend kan stödja denna metod. Om det är aktiverat så kommer Extend att skapa returorders i Extend 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 samt Oaviserade mottagningar i Ongoing. Här måste man bestämma vilken process man vill stödja som varuägare. 
  • i butik, som registreras i Shopbox skall synkas med Extend Commerce Backend. Med detta menas att alla transaktioner (kassakvitton) blir registrerade som enskilda orders i Extend Commerce Backend. Syftet med detta är två, dels att i realtid kunna följa lagersaldot i butiken, samt att kunna få en ekonomsikt kontering / uppföljning på varje transaktion via Extend till bokföringssystemet
  • Synka artiklar. En artikel i Extend Commerce Backend, som lagerläggs mot butikslagret. kommer att etableras i POS systemet. Syftet med detta är att man inte skall behöva registrera nya artiklar i POS systmet, utan artikelnummer, namn, streckkod etc. bara behöver registreras i Extend Commerce Backend.
  • Generella priser. Vi synkar generella priser så att en förändring av ett pris, en kampanj, ett tillfälligt pris kan registreras i Extend Commerce Backendoch pushas ut till en eller flera POS system. Underhåll av priser kan ske centralt i Extend Commerce Backend.
  • Kända kunder, en kund som har ett kundnummer kan ange detta i butiken. POS systemet Shopbox kommer då att i realtid hämta just den kundens unika priser, samt info om kunden får handla mot faktura och till vilka belopp.
  • Fakturakunder. Om kunden har godkänd kreditlimit för faktura köp, så kommer POS att hantera försäljningen i butik, men rapportera in försäljningen till Extend som kommer att hantera detta som ett fakturaköp, och skapa och distribuera fakturan enligt vanliga Extend Commerce Backend rutiner.
  • Returer. En retur in till butiken kommer att dels hanteras finansiellt som en kredit, både i POS och i Extend. Men även saldot av en retur kommer att hanteras automatiskt, med negativ cost of sold gods.
Panel
borderColor#dbdbdb

Det är Shopbox som hämtar och lämnar information hos Extend Commerce. Extend Commerce är den passiva parten i denna integration.

Syftet med integrationen är.

  • Försäljningen

  1. Produkter

Alla produkter som finns på det lager i Extend som är kopplat till Ongoing kommer att skapas upp av Extend i Ongoing. Det finns inget som hindrar att produkten redan är skapad i Ongoing. Men med denna process säkerställs att Extend inte kommer skicka ner transaktioner till Ongoing på produkter som inte finns. 
Produktnummer i Extend kommer att hanteras som "artikelnummer/article number" i Ongoing. 
(Det finns ex möjlighet att hantera Extends produktnummer såsom"Product code" i Ongoing, men det är inte standard och kräver anpassad mappning från Extend.) Nedan ex på produktdata som synkas till Ongoing. 

Extendsynkas till i Ongoing
ProduktnrArticleNumber
ProduktnamnArticleName, samt ArticleDescription
EANBarcode
Produkt kategoriArticle group name
UrsprungslandCountry of origin
TullkodStatisticsNumber samt TaricNumber
Ytterförp enhet 1 antalQuantity per package
EnhetArticleUnitCode
Vikt (transport)Weight
Längd (transport)Length
Bredd (transport)Width
Höjd (transport)Height

Att ta beslut om

Panel
borderColor#dbdbdb

Följande saker måste de som hanterar lagret OCH varuägaren du som varuägare ta beslut om innan integrationen kan aktiverasoch förbereda i Extend Commerce Backend. 

Saldo synkningen.

Det finns två saldon som kan synkas mot Extend, 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. 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.
Extends projektledare eller Extends kundtjänst måste få information om detta innan integrationen kan aktiveras.  

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 kan hantera ordern som färdig på någon av dessa statusar. Standard är att Extend 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. 

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

  • Extend automatiskt annullerar diffen.
    (obs detta gäller ju enbart på de rader som Extend skickat till Ongoing för plock, om Extend 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)
  • Extend 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. 
    • Extend skapar en delleverans, utan krav på manuellt beslut.
    Det som inte skickades hanteras som delleverans och när Extend ser att det finns saldo igen på produkten så kommer raden att skickas för plock. (dock kommer vanliga restorderprinciperna på kunden i Extend att gälla)

    Returorder processen

    Extend 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 Extend vilken process man vill / kan stödja innan integrationen kan starta.  

    Transporttjänster

    När en order skickas från Extend 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.

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

    Image Removed

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

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

    Extend hanterar normalt sett ett eller flera lager, Extend 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 Extend 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. 

    Instruktioner till lagret

    Panel
    borderColor#dbdbdb

    När en integration mellan ett ordersystem (Extend) 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 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. 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.  

    Aktivering / rättigheter

    Panel
    borderColor#dbdbdb

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

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

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

    Frågor till varuägaren

    Panel
    borderColor#dbdbdb
    På denna sida:toc


    Kund som generella priser skall hämtas från

    När POS frågar Extend Commerce Backend om vilka generella priser som skall användas så frågar man efter priser med ett kundnummer som villkor. Priser i Extend Commerce Backend byggs ihop per kund, baserat på många olika prislistor, rabattlistor, kampanjer etc. gör att varje dag så byggs en ny generell prisbild upp, som skall vara publik i butiken. Så man behöver fastställa en kund (kundnummer) i Extend Commerce Backend, från vilken POS skall hämta generella priser från. 


    Lager som motsvarar respektive butik.

    När POS skall rapportera in försäljning så behöver POS informera Extend Commerce Backend om vilken butik som försäljningen skett på, detta motsvarar ett lager i Extend Commerce Backend. Så för varje butik behövs ett motsvarande lager i Extend Commerce Backend och identiteten på detta lager (shortname) behöver POS känna till.


    Artikel för Mixed Payment

    Mixed payment innebär att en kund betalar en order med olika betalsätt. Tex att man köper för 300 kr, betalar 200 med ett presentkort och resterande med kreditkort. En sådan delad betalning "Mixed payment" kräver en speciell tjänsteartikel i Extend Commerce Backend som används för att hantera detta. Denna artikel skall ha artikelnummer "MIXEDPAYMENT-01" Detta skall vara en tjänsteartikel och den skall ha en försäljningsenhet och finnas kopplad till prislistor till den generella kund som beskrivs i detta dokument. Den kan ha 0kr i pris på sin prislista.

    Namn på denna artikel kan ni välja själva, det är artikelnummret som är det viktiga.

    Inställningar i Shopbox

    Panel
    borderColor#dbdbdb

    För att aktivera en koppling mellan Extend Commerce Backend och Shopbox så gör du så här i din Shopbox

    Image Added


    1. Ange ett client id som identifierar dig som varuägare i Extend Commerce Backend. Detta värde hittar du under övriga inställningar – Klientinställningar. Det fältet som heter Klientinformation innehåller detta värde.

    Image Added

    2 och 3. Här skall du ange ett användarnamn och ett lösenord.
    Denna användare är en användare i Extend Commerce Backend, och det måste vara en API användare. Du hämtar ut användarnamn och lösenord från sidan Användarinställningar i Extend Commerce Backend. Här är det viktigt att det är en API användare du skapar (glöm ej att tilldela denna användare rättigheter...)

    Image Added

    Tip

    Läs mer information om API användare: 'Instruktioner & Handledning' för Skapa API användare'.


    4. Här skall du ange kundnummer på den kund som skall "bära" standardpriser i Extend Commerce Backend. Detta beskrevs ovan.

    5. Här skall du ange ett fraktsätt som skall sättas på alla orders som kommer från Shopbox. Extend Commerce Backend behöver ett fraktsätt på alla orders. I detta fallet när försäljningen skett i butik, så rekommenderas att detta fraktsätt heter Hämtas eller liknande. Detta fraktsätt som anges här måste finnas aktivt i Er Extend Commerce installation.

    6. Här anges identiteten på lagret i Extend Commerce Backend som representerar butiken. Gå in på Lager, och gå till Lagerinställningar. Där hittar ni denna identitet i fältet "Kort namn".

    Image Added


    7. Här skall ni ange en URL till er Extend Commerce installation.
    Denna adress kan skilja sig åt mellan kunder till Extend Commerce Backend. För att hitta din egen så logga in i Extend Commerce Backend, titta i URL fältet och kopiera ut det som står fram till och med extend.se/

    Det som är gulmarkerat i denna bild

    Image Added

    Övrigt att tänka på

    Panel
    borderColor#dbdbdb

    Alla betalsätt som ni kommer att använda i butiken, behöver finnas upplagda i Extend Commerce Backend.

    Lägg till saldo automatisk, och tillåt ökning.... är två inställningar på lagerinställningarna i Extend Commerce Backend som behöver vara aktiva. 

    Image Added



    På denna sida:

    Table of Contents

    Include Page
    Google Analytics
    Google Analytics