med hjälp av APPS
LAGER &
TRANSPORTER

Business Central expert
Detta är nr 5 av 8 artiklar om hur du kan täcka hela ditt företag med BUSINESS CENTRAL
– utan kundtillägg
– använder endast APPS
Uppfyll alla dina behov för att hantera WAREHOUSE och SHIPMENTS i BUSINESS CENTRAL.
I den här artikeln förklarar vi vad du bör kräva, hur du undviker anpassningar och vilka APPS du ska använda.
Warehouse Management handlar i grunden om att hantera processerna i lagret. I allmänhet handlar lagerhantering i ERP om att hantera artiklar, varianter, kvantiteter och platser, och när vi introducerar Warehouse Management handlar det också om leverans- och mottagningsdokument och fack.
Normalt vet vi bara att vi har 10 artiklar i lager, men med Warehouse Management vet vi att det finns 4 artiklar på hylla A och 6 artiklar på hylla B.
» Mål för WMS

Det är viktigt att känna till skillnaden mellan en plats och ett fack i Business Central. En plats är en geografisk plats, t.ex. ett tyg eller en anläggning. Den specifika platsen är indelad i många fack.
Det imponerande med att införa en lagerhanteringslösning är hur snabbt allt faller på plats. Vi träffar regelbundet företag som vill införa en lagerlösning och som kommer från en situation utan fack. När de väl kommer igång håller systemet reda på allt.
Vi behöver bara reda ut terminologin, eftersom lagerhantering betyder flera saker i ERP-världen.
NIVEAU 1: FINANSIELL LAGERHANTERING
Att hålla reda på kvantiteten och värdet av varje artikel är det traditionella finansiella och kvantitativa sättet att se på lagerhantering. Det är grunden för att vi ska kunna hålla reda på artiklarna i vårt ERP-system. Det gör att vi kan köpa en vara och lägga in den i lagret, och vi kan också sälja den och ta ut den från lagret.
NIVÅ 2: VARULAGERHANTERING MED LAGERFACK
Med ett Warehouse Management System – kommer artiklar per lagerfack in i bilden. Systemet känner inte bara till kvantiteten, utan håller också reda på i vilka fack en artikel är placerad. Det kan finnas tolv enheter på en hylla och tre på en annan; varje gång vi flyttar artikeln – fysiskt – måste vi genast berätta det för ERP-systemet, så att allt förblir under kontroll. Det krävs en helt ny nivå av registrering, vilket kräver en skannerlösning.
» Lösning för registrering
Interna lagerprocesser
Vi har en mottagningszon, en plockzon, en leveranszon och en backend-zon. När en lastbil anländer får vi snabbt in varorna i mottagningszonen och registrerar dem, men vi har inte tid att ställa undan dem än. Då behöver vi smart logik som kan hjälpa till med var varorna ska placeras.
Vi placerar hela pallar i backend-zonen och sedan fyller vi på plockzonen, där vi tar från backend och flyttar ut i plockzonen. Det kan också vara så att vi flyttar varor från höglagret till plockzonen.
Vi måste kunna genomföra lagerinventeringar och reglera lagret. Om varor saknas eller är trasiga måste vi minska lagret. Lagerhantering kräver räkning per fack, och det är ett jobb som vi måste kunna göra med en scanner.
När varorna ska skickas gör vi i ordning en lagersändning och plockar varorna för transport.
Försändelser – externa processer
Shipments handlar om att hantera den del av försändelsen som sker utanför lagret. Vi har kvitton som kommer till lagret och försändelser som lämnar lagret.
Vi måste hantera vilka försändelser vi förväntar oss att få in och planera hur vi ska skicka försändelserna till kunderna. Vi måste hantera fraktsedlar och speditörer.

Om det är en hel container med varor som vi tar emot på lagret, så vill vi gärna ha verktyg för att ta emot varorna på ett enkelt sätt. Vi behöver veta vilka artiklar som ska finnas i containern och vi behöver kunna verifiera att vi har fått det vi förväntar oss.

Plock och leverans
Artiklarna kan plockas för försäljningsorder eller för produktionsorder. Vi skapar ett plock så att medarbetarna kan plocka varorna på lagret, och i packzonen packar vi varorna i de optimala lådorna och skickar dem med speditören.

Vi måste hålla reda på antal, volym och vikt, och vi måste skriva ut etiketter till lådorna. Det är i den här processen som vi går från att fokusera på varor och kvantitet – till lådor som ska skickas, och vi måste hålla reda på vad alla lådor innehåller.
Vi måste kunna schemalägga sändningar så att speditörerna kommer vid olika tidpunkter och hämtar sändningarna, och vi måste kunna schemalägga plockning och packning så att de matchar sändningarna. När vi har plockat och packat varorna ska de placeras i leveranszonen i den ordning som de hämtas av speditören.


Plockning är förmodligen den största matematiska utmaningen. Vi måste plocka de order där vi har alla artiklar i lager. Försäljningsorderna måste prioriteras, både i förhållande till kunderna och i förhållande till leveransen, och samtidigt måste vi planera en effektiv rutt i lagret för plockning, och vi måste beräkna vilka lådor varorna måste packas i.
Ofta plockas artiklarna på en vagn, men det smartaste är att plocka direkt i lådan. Detta förutsätter att Business Central kan tala om vilken storlek på låda plockaren måste välja.
3PL och konsignationslager
Vi kan också ha lager placerade på annat håll, till exempel hos återförsäljare som har varor i konsignation, så när vi vill fylla på deras lager måste vi kunna göra det med omlastningsorder.
Det kan också vara i ett lagerhotell, som ansvarar för vår lagerhantering och utskick av våra varor till kunder. Det kräver en hel del integration.

MÅL FÖR WMS
Vi har fyra fördelar som vi vill uppnå med Warehouse Management, och de är följande:
- Finansiell förutsägbarhet
- Högre servicenivå
- Minimerad lagerbindning
- Optimerad plockning
Om du inte redan har en lagerlösning bör du förbereda dig noga. Du bör till exempel titta på följande:
- hur stort ditt lager är
- hur många val du har
- vilken typ av val du behöver
- om du vill plocka för flera kunder samtidigt
- om du vill plocka för en kund över försäljningsorder eller inte
- om du vill hantera volymen och dimensionerna på artiklarna
- om du vill ha möjlighet att välja artiklar i olika måttenheter
- om artiklarna levereras i förpackningar med olika kvantiteter och om de har olika märkningar och ID:n
- om du har plockmaterial i udda storlekar, t.ex. en 2 meter lång kvast som inte får plats i en pappkartong
- om du har streckkoder överallt där de behövs
Det är mycket arbete som ligger bakom att gå från papper till en IT-lösning för lagerhantering. Låt oss gå igenom de fyra fördelar som vi bör se till att vi får när vi inför en lagerlösning.
Fördel 1: Finansiell förutsägbarhet
Den första fördelen är att vårt lager alltid är korrekt – i motsats till den traditionella modellen där vi måste genomföra en lagerräkning flera gånger om året, vilket kräver att vi blockerar flera dagar i kalendern för att summera alla våra varor … bara för att hitta en mycket stor avvikelse.
Med en lagerlösning är det lättare att hålla lagret ständigt uppdaterat så att vi aldrig bygger upp en stor avvikelse.
Det fina är att det här är en fördel som kommer av sig själv. När vi går för att plocka en vara och den inte finns där, registrerar vi helt enkelt en justering. På så sätt räknas det kontinuerligt per fack, i stället för periodiskt per artikel.
Den första fördelen är alltså den finansiella förutsägbarheten.
I den traditionella situationen, där vi räknar lagret flera gånger per år, håller alla andan i flera dagar när vi räknar, eftersom ingen vet om avvikelsen kommer att bli positiv eller negativ.
Hur stora är lageravvikelserna för närvarande? Och vad är målet med införandet av en lagerlösning?
Om vi plötsligt får en skillnad på flera miljoner kommer det att få en direkt påverkan på rörelseresultatet och ge upphov till en del bekymrade miner på ekonomiavdelningen.
Fördel 2: Högre servicenivå
När lagret är mer exakt blir det också lättare att höja servicenivån och den perfekta orderuppfyllnadsgraden som vi erbjuder kunderna.
Om en vara är trasig kan vi skrota den direkt. När något inte står rätt till kan vi justera det direkt istället för att vänta på en räkning.
Perfect Order Fulfilment handlar om hur många försäljningsorder vi levererar till kunderna på ett perfekt sätt, på avtalad tid, till avtalat pris och utan reklamationer. Självklart vill vi att våra kunder ska vara nöjda – och det blir de om de får vad de vill ha, när de vill ha det. Det är själva sinnebilden av en hög servicenivå.
Det räcker faktiskt inte med att leverera vid den bekräftade tidpunkten. Om man utgår från SCOR (Supply Chain Operations Reference) bör den “verkliga” servicenivån mätas mot vad kunderna vill ha. Om vi kan leverera det är vi bra på det vi gör.
Om vår servicenivå är för låg handlar det förmodligen om varor som vi har svårt att få tag på i tid, eftersom planeringen inte är tillräckligt rigorös eller eftersom vi har en kort leveranstid ut och en lång leveranstid in, till exempel om vi köper varor i Kina och leveransen tar 6 månader, men kunden förväntar sig att kunna köpa varan med en dags varsel.
Så vi har en utmaning. I den här situationen måste vi ha full kontroll över vår planering.
Men… utöver denna traditionella utmaning måste vi också tänka på lagerhanteringen.
Om vi tror att varan finns i lager och säljer den, men det visar sig att lagret är tomt, har vi en stor utmaning framför oss.
För att uppnå en bra servicenivå är det viktigt att lagersaldot stämmer. Det är därför vi behöver lagerhantering med realtidsuppdatering.
Fördel 3: Minimerad lagerbindning
Samtidigt gör en lagerlösning att vi kan minska mängden kapital som binds i lager.
Det är en evig fråga om prioriteringar: ska man höja servicegraden genom att öka lagernivåerna eller minimera kapitalbindningen och leva med en lägre servicegrad eller högre kostnader för ombeställningar.
Detaljerad lagerstyrning ger oss större möjligheter att få igenom vår vilja på båda fronterna.
Om vår lagerhantering är rörig och vi inte kan vara säkra på om det finns avvikelser i vårt lager, måste vi köpa större kvantiteter för att vara säkra på att ha tillräckligt i lager – vilket ökar likviditetsbindningen.
När vi kan hantera lagret med större precision kan vi göra mer genomtänkta inköp och därmed minska lagervärdet utan att det påverkar servicenivån.
Fördel 4: Optimerad plockning
En av de saker som företag lägger störst vikt vid när de inför en lagerlösning är orderplock – möjligheten att plocka i lagret och att bli guidad runt i lagret i en optimal plockrutt. Ett optimalt plock handlar om den kortaste och smartaste rutten som möjligt.
Det finns många olika modeller för strukturering av plock. Vi måste därför vara tydliga med vilka krav som ERP-lösningen ska ta hänsyn till när vi organiserar val. Det finns vanligtvis många olika scenarier att ta hänsyn till.
Om vi har ett stort antal försäljningsorder, många av dem för samma kund – till exempel om vi levererar till en stor detaljhandelskedja och har tio olika öppna försäljningsorder för dem, varav några är restorder, några är för i morgon och några var för i går, bör lagerlösningen på ett intelligent sätt sätta ihop ett plock över försäljningsorderna.
Vi kanske vill göra ett “bulkplock”, dvs. plocka 20 olika försäljningsorder till olika kunder på en gång, eftersom det är relativt små order; när vi kommer fram till expeditionsområdet separerar vi artiklarna och lägger dem i lådor. Detta kallas “bulkplock”.
Det kan också vara så att vi vill arbeta med “boxplock”, där vi plockar direkt i leveransförpackningen. Om vi måste plocka till fyra försäljningsorder kommer lagerlösningen att be oss att plocka i fyra olika lådor.
Systemet måste hålla reda på volymen och måste i förväg ha räknat ut hur stora dessa lådor måste vara. På så sätt slipper vi packa om varorna i expeditionen, eftersom vi har plockat direkt från hyllan till transportförpackningen. Detta kallas för “boxplock” eller “pallplock” beroende på vilken typ av förpackning det handlar om.
Dessutom kanske vi vill plocka allt som ska till utlandet före klockan 9, eftersom det är då transportören kommer för att hämta försändelser till utlandet. Lagerlösningen måste därför se till att organisera plockningen så att vi inte plockar alla order till lokala adresser, som sedan tar upp plats i lastkajen, när lastbilen till utlandet anländer.
När det gäller plockning finns det många olika krav som är avgörande för att vi ska kunna optimera lagret. Naturligtvis behöver plockaren inte oroa sig för allt detta. Handterminalen ska bara vägleda plockaren längs den bästa rutten.
“Ta en vagn med två lådor i storlekarna 3 och 5. Plocka artiklarna på den här rutten. Systemet ska organisera allt detta för plockaren.
När en order har plockats ska lagerlösningen skapa fraktdokumenten och integreras med transportörerna.
Det viktiga är att lösningen tar hand om bokningen av transportören och överför all nödvändig information så att ingen manuell bearbetning krävs.

REGISTRERINGSLÖSNING
Vissa företag kan klara sig utan scannerterminaler, men bara för att de har ett litet lager och arbetar med fasta fack.
Det första paradigmet i en lagerlösning är därför att vi måste registrera allt som händer i lagret; i praktiken är detta ofta bara möjligt med en skannerregistreringslösning.
De flesta företag behöver enheter för att utföra registreringar på lagret. Det kan handla om dyra handterminaler, truckscanners eller bara smartphones som kör en mobil version av ERP-systemet Business Central.
Om vi har ett litet lager kan detta göras ganska enkelt, direkt från en mobil klient till Business Central. Men någon form av registreringslösning är ett måste.
Online eller offline
Och det första beslutet som måste fattas är om vi ska arbeta online i ERP-systemet eller offline. Med andra ord, om vi vill att våra registreringar ska uppdateras i ERP-systemet utan dröjsmål (online) eller i batch-läge (offline).
Om allt är uppdaterat online i affärssystemet kan en säljare skapa en försäljningsorder som direkt skickas till lagret, där ordern kan plockas omedelbart.
I många lagerlösningar genereras plock på morgonen, när ett batchjobb i systemet räknar ut hur mycket vi ska plocka under dagen; det skapar sedan alla plock, och vi får ett arbetsblad som visar vad vi måste göra idag.
Nyare system skapar ett plock i taget. När plockaren är ledig eller har plockat färdigt trycker han på en knapp på sin terminal för att få information om nästa plock, varpå systemet skapar nästa plock åt honom. Det innebär att om en ny försäljningsorder med högsta prioritet precis har kommit in, kommer den att vara nästa order att plockas.
Det kan också hända att varor har anlänt för bara en stund sedan, och systemet kan nu se att den här varan är tillgänglig och börja tillåta att den inkluderas i urvalen. Debatten om huruvida registreringen ska ske online eller offline är mycket viktig. Realtidsplanering av plock har naturligtvis vissa fördelar, men det betyder inte att det alltid är den bästa lösningen.
Vi måste till exempel ta hänsyn till hur bra vår nätverkstäckning är. Online kräver naturligtvis oavbruten tillgång till internet. Accesspunkter brukar sättas upp runt om i lagret, och det är enkelt så länge vi befinner oss i ett vanligt inomhuslager.
Vi rekommenderar normalt att vi arbetar online så mycket som möjligt, men om vi inte har oavbruten internettäckning måste vi arbeta offline.
Utrustning
De val som diskuteras ovan kan avgöra vilken typ av handterminalutrustning vi behöver, men annars:
Om vi har många plock och många plockare i ett stort lager finns det oftast ett bra affärsmässigt argument för att välja ordentliga scannerterminaler med många funktioner – sådana som tål oavbruten användning och att bli överkörda av en gaffeltruck.
Om vi har ett relativt litet lager och bara vill göra enstaka registreringar kanske vi kan nöja oss med en surfplatta eller mobiltelefon som är direkt ansluten till affärssystemet. Dessa är mycket billigare men också betydligt mer ömtåliga.
Volymen är det som främst avgör valet av utrustning.

FÖRPACKNINGAR, STRECKKODER OCH BREAK-BULK
Låt oss titta närmare på några av de funktionskrav som ofta utgör utmaningar i en ny lagerlösning.
Förpackningar
Vi säljer en vara, t.ex. en colaburk, per styck och det finns en streckkod på varje colaburk, men de är förpackade sex stycken per förpackning.
Ska vi därför ha en annan streckkod på utsidan av förpackningen, eller ska det vara samma streckkod – och måste vi i så fall komma ihåg att registrera 6 enheter när vi skannar en förpackning?
Om 6-packet packas i en låda med totalt 24 förpackningar, får då även den lådan en ny streckkod?
Om det nu finns olika streckkoder på colan, och systemet kan känna igen kvantiteten, gäller samma princip för alla andra artiklar. Annars är det oundvikligt att det blir felplock. Om vi ska kunna hantera den här utmaningen på ett bra sätt i affärssystemet måste systemet stödja en artikelstruktur med förpackningar i olika kvantiteter.
Annars blir det besvärligt att hantera – antingen i artikelstrukturen i ERP-systemet eller i scanningssituationen på lagret. Vi måste ha bra koll på vilka förpackningar och kvantiteter vi plockar in.
Streckkoder
När vi inför en ny lagerlösning är det mest tidskrävande att lägga in streckkoderna i vårt ERP-system, sätta upp fack och fästa etiketter på alla hyllor i lagret där vi vill använda handterminaler för skanning.
Det har inte så mycket med själva ERP-lösningen att göra; det är ett lågteknologiskt jobb som måste göras. Tyvärr finns det många företag som inte har streckkoder på alla sina artiklar och alla sina småsaker.
Om vi till exempel är ett livsmedelsföretag och köper ett parti blomkål kommer det inte att levereras med en streckkod på varje blomkålshuvud. Så hur registrerar vi dem? Måste vi ha koden för en blomkål i huvudet, eller måste vi gå över till en tavla någonstans och bläddra fram till bilden av en blomkål så att vi kan skanna en streckkod?
Det här problemet är inte begränsat till livsmedelsindustrin. Streckkodsläsning är en utmaning inom många sektorer.
Alternativa icke-linjära måttenheter
Det finns en annan stor utmaning för ERP-system på lagret: olika måttenheter. De flesta ERP-system hanterar enhetskoder helt okej. Vi lagerför cola på burk per enhet, men vi har den också i 6-pack och 24-pack.
Vi hanterar detta genom att skapa relationer mellan enhetskoder i ERP-systemet. Vi har alltså enheter, förpackningar, ramar, lådor, kollin och så vidare. De flesta ERP-system hanterar detta på ett bra sätt.
Den svåra delen är icke-linjära måttenheter.
Ett klassiskt exempel kan vara frysta kycklingar. Vi säljer frysta kycklingar i lådor om 20 stycken. Det är 20 i en låda när vi köper in dem också, men avräkningen, både för försäljning och för inköp, sker med verklig vikt.
Vi beställer en pall, det vill säga 40 lådor, från vår leverantör. Vi registrerar mottagandet av 40 lådor på inköpsraden i affärssystemet och räknar själv ut att det blir 800 enheter.
Men i praktiken, när vi skannar in dem på lagret, kan vi skanna varje låda separat och registrera vikten, som kan visa sig vara färre kilo än vad köparen trodde. Kycklingar kan variera mycket i vikt, och vi vill hantera detta i ERP också.
I slutändan måste allt regleras enligt vikt, så ERP-systemet måste hålla reda på flera icke-linjära måttenheter för samma artikel. Vi kallar detta för alternativa enhetskoder, eller “andra måttenhet” i ERP-terminologi.
Om vi importerar skinkor från Italien och köper dem i kvantitet kan det bli stora variationer. Skinkorna väger mellan 1,2 och 3,5 kilo styck. Vår kund beställer 3 skinkor och får 3 levererade, men betalningen måste ske per vikt. I den här situationen är det avgörande att vårt ERP-system håller reda på enheterna.
Utmaningen för affärssystemet är som regel inte att måttenheterna ändras mellan inköp och försäljning. Det är ganska lätt att hantera om måttenheterna är linjära, där 1 kg motsvarar t.ex. 8 enheter.
ERP-systemet arbetar med en basenhet, vanligtvis den som används för inventering och den som artiklarna lagerförs i, ekonomiskt sett. Även om vi köper 100 kg kommer systemet att lagra det i form av basenheten, som en kvantitet på 800.
När förhållandet är icke-linjärt finns det dock inte alltid en naturlig basenhet, och då börjar det bli svårt i affärssystemet.
Det är inte så kul att ha 100 meter plankor i lager om de alla bara är 20 cm långa eftersom de är spillbitar från timmer som sågats i längd till kunder. Vilken enhet ska vi räkna plankorna i om vi behöver göra en lagerinventering? “Flera” är förmodligen det bästa svaret.
ERP-mässigt krävs ett separat inmatningssystem för att hantera de olika enhetskoderna bakom kulisserna.
Vi vill inte att detta ska specialutvecklas i vårt ERP-system, eftersom det är ett stort åtagande. Vi vill att lagerhanteringslösningen ska hantera det.
Breakbulk
Kanske behöver vi också hantera breakbulk i lagret. Vi kan se att vi har 10.000 burkar cola i lager, men vi kanske inte kan se vilket breakbulk de är i. Hur många är förpackade i 6-pack eller i 24-pack?
I exemplet med skinkorna ovan kan en kund beställa 3 skinkor som var och en väger minst 2,8 kg. Borde vårt system kunna tala om för oss om vi kan leverera? Det kan mycket väl vara så att vi kan leverera 3 enheter, och att vi också kan leverera 8,4 kilo, men det betyder inte nödvändigtvis att vi kan leverera 3 enheter på minst 2,8 kilo vardera.
Om vi driver en brädgård och köper in plankor i fasta längder, hur många detaljer måste affärssystemet hålla reda på? Vi kanske kan se att vi har 400 meter i lager, fördelat på 200 plankor, men inte vilka längder de har.
Om en kund beställer 100 plankor på 3 meter kan vi ha tillräckligt i lager både vad gäller längd och kvantitet, men om många av dem skärs upp i små bitar är det inte säkert att vi har 100 längder på 3 meter.
Om vi vill veta vilka plankor vi faktiskt kan välja måste ERP-systemet ha full kontroll över både breakbulk- och enhetskoderna.
SPÅRNING AV ARTIKLAR
Spårning av artiklar – antingen hantering av utgångsdatum eller hantering av vanliga parti- eller serienummer – är en klassisk fråga. Business Central måste stödja detta på ett elegant sätt (och ja, det finns många oeleganta sätt att hantera detta på).
Det finns många branscher där spårning av artiklar nu antingen är relevant eller ett absolut krav.
Parti- och serienummer
I huvudsak finns det spårning av lotnummer (även kallat spårning av batchnummer) och spårning av serienummer.
Skillnaden är att serienumret är unikt för enheten. Det är alltid en kvantitet på 1 enhet som har ett unikt serienummer. Serienummer är mycket vanliga inom t.ex. elektronikindustrin.
Lotnummer används när en vara tillverkas i en batch och alla enheter i den batchen får ett lotnummer så att de kan identifieras. Det kan gälla flytande produkter som kan tappas av eller vanliga varor som kan plockas. Det kan definitivt gälla artiklar som produceras i kvantitet men som får ett lot-nummer eftersom de produceras i satser.
Du kan till exempel ha 5.000 brickor med paté som tillverkas på en gång och därför får samma partinummer. Eller en kubikmeter plastprylar etc.
Ett av kriterierna för att välja serienummerhantering är att serienumret måste finnas på den enskilda artikeln. Annars är det inte meningsfullt.
Det finns också vissa industrier som sätter både partinummer och serienummer på samma artikel för att visa att ett visst serienummer har producerats i en viss serieproduktion.
Business Central vet hur man hanterar parti- och serienummer. När en artikel har konfigurerats för att visa om den har ett parti- eller serienummer hanterar Business Central det på ett snyggt sätt genom hela hierarkin.
Om vi till exempel ska tillverka 5 000 brickor paté och köper kött och mjölk registrerar vi ett partinummer på de inköpta varorna i kvittona.
Och om vi inte får något partinummer från leverantören kan vi skapa ett eget, som består av ett datum och ett ID-nummer. På så sätt vet vi när den enskilda råvaran togs emot och från vilken leverantör.
Varje gång vi hanterar råvarorna i lagret anger vi lotsnumret på de artiklar du tar ut. När råvarorna ingår i en produktion av en färdig produkt eller kanske ett halvfabrikat registrerar vi de ingående lot-numren och resultatet av produktionsordern tilldelas ett nytt spårbart lot-nummer.
En bricka med paté blir på så sätt en hierarki av partinummer, vilket gör att vi kan gå ner i hierarkin och spåra alla råvaror som ingår i en specifik bricka med paté.
Om vi identifierar en råvara som utgör ett problem kan vi navigera uppåt i hierarkin och spåra alla slutprodukter som innehåller den problematiska råvarans lotnummer.
Detta är traditionell artikelspårning, något som ERP-systemet kan stödja mycket enkelt.
Det är uppenbart att artikelspårning kräver fler registreringar på lagret och i produktionen, men vi bör se till att strukturen i ERP-systemet inte gör det svårare. Vi ska alltid kunna “skanna oss ut”. Vi bör minimera manuella registreringar.
Ingen manuell inmatning
Normalt har vi antingen lot-numret på våra råvaror eller skriver ut etiketter med lot-numret när vi producerar artikeln.
Om vi t.ex. tillverkar en artikel som systemet automatiskt tilldelar ett partinummer, måste systemet kunna skriva ut det så att det visas på en etikett med streckkod och därmed lätt kan skannas.
Ingenting ska behöva knappas in manuellt. Vi ska kunna hantera artikeln enbart med hjälp av scannerterminalen. Detta kan ställas in i de flesta lagerlösningar.
Vi kan mycket väl ha vissa artiklar som spåras och andra som inte gör det. Mjölken och köttet till patén spåras med hjälp av partinummer, men salt och peppar kanske inte gör det. De flesta system kan hantera detta.
HANTERING AV UTGÅNGSDATUM
Hantering av utgångsdatum
Utmaningar uppstår ofta på Business Central när det gäller hantering av utgångsdatum. När vi köper en vara står det på den när den går ut, och det måste vi kunna registrera i affärssystemet.
Och när vi producerar en artikel måste vi kunna välja en formel för utgångsdatum på artikelkortet så att systemet beräknar ett datum, t.ex. 1 år från produktionsdatumet, och stämplar det specifika utgångsdatumet i systemet.
Detta är i sig ganska enkelt för de flesta ERP-system
Det blir lite knepigare när vi tänker på “återstående hållbarhetstid” (RSL).
Återstående hållbarhetstid
När vår kund köper en vara vars hållbarhetstid går ut 1 år efter tillverkningsdatumet kan kunden ställa krav på hur lång hållbarhetstid som ska återstå. När varan når butikshyllan kan butiken kräva att den återstående hållbarheten ska vara minst 75%.
Kravet på återstående hållbarhetstid uttrycks inte alltid i dagar, utan kan vara en procentandel av varans totala hållbarhetstid.
Våra kunder har normalt olika krav på återstående hållbarhetstid, och det kan vara mycket svårt att hantera detta och få ERP-systemet att ta hänsyn till det vid beräkning av lagerplock.
Till att börja med bör plockalgoritmen vara så smart att den plockar artiklar till de kunder som har de minst restriktiva kraven, så att de får de äldsta artiklarna. På så sätt kan vi vara säkra på att kunna uppfylla de återstående kraven på hållbarhetstid för så många order som möjligt.
Våra kunder kan också göra saker och ting lite mer komplicerade genom att ange “single batch”, vilket innebär att kunden insisterar på att hela försändelsen ska ha samma partinummer, eller “single-layer batch”, där alla lager i en pall måste ha samma partinummer.
Många kunder ställer den här typen av krav eftersom de inte vill skanna många olika batchnummer med olika kvantiteter i sitt ankomstområde.
“Single batch” gör det mycket enklare för kunden – men mer komplext för vårt ERP-system.
Om vi har en kund som lägger en stor order med krav på “single batch” måste affärssystemet förmodligen plocka för den här kunden först för att vara säkert på att kunna leverera. Men detta kan orsaka konflikter.
Om en annan kund bara kräver 50 % återstående hållbarhetstid vill vi verkligen plocka till den kunden först, eftersom vi då kan ta den äldsta varan. Men om det här plocket delar upp ett parti kanske vi inte alls kan leverera den stora ordern med ett enda parti.
I verkligheten behöver vi därför ofta överväga dem med de mest restriktiva kraven på “enstaka order” först och överväga den återstående hållbarheten därefter.
Detta blir snart en matematisk övning där affärssystemet måste jonglera med alla krav och kombinera artiklar så att så många order som möjligt blir plockade.
Om inte annat kräver detta att inventeringen är 100% korrekt.
Och det kräver en Warehouse Management-lösning som är bra på att planera plock enligt alla de kriterier som kunderna ställer upp.