Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Brug en efterspørgselsprognose til at tage højde for forventet efterspørgsel i din masterplanlægning. Du kan manuelt oprette en efterspørgselsprognose, importere den eller generere den ved at bruge efterspørgselsprognosefunktionen i Microsoft Dynamics 365 Supply Chain Management. Yderligere oplysninger om behovsprognose finder du i Oversigt over behovsprognose.
Bemærkning
Planlægningsoptimering understøtter ikke separat prognoseplanlægning. Den har indstillingen Aktuel prognoseplan på siden Varedisponeringsparametre ingen effekt, når du bruger Planlægningsoptimering.
Oprette en behovsplan, der omfatter en behovsprognose
For at konfigurere en masterplan, så den indeholder en efterspørgselsprognose, følger du disse trin:
Gå til Varedisponering>Opsætning>Planer>Behovsplaner.
Vælg en eksisterende plan, eller opret en ny plan.
I oversigtspanelet Generelt skal du indstille følgende felter:
- Prognosemodel – Vælg den prognosemodel, der skal anvendes. Denne model tages i betragtning, når et udbudsforslag genereres til den aktuelle masterplan.
- Medtag behovsprognose – Angiv denne indstilling til Ja for at medtage behovsprognosen i den aktuelle behovsplan. Hvis du sætter den til Nej, er efterspørgselsprognosetransaktioner ikke inkluderet i masterplanen.
- Metode, der bruges til at reducere prognosekrav – Vælg den metode, der skal bruges til at reducere prognosekravet. Lær mere i afsnittet om Prognosereduktionsnøgler senere i denne artikel.
På FastTab Tidshegn i dage skal følgende felter angives, hvilken periode efterspørgselsprognosen er inkluderet i:
- Hovedplan – Angiv denne indstilling til Ja for at tilsidesætte den hovedplanstidshorisont, der stammer fra de enkelte disponeringsgrupper. Angiv værdien til Nej for at bruge værdierne fra de enkelte disponeringsgrupper for den aktuelle behovsplan.
- Prognoseperiode – Hvis du angiver indstillingen Hovedplan til Ja, skal du angive det antal dage (fra dags dato), som behovsprognosen skal gælde for.
Vigtigt!
Planlægningsoptimering understøtter ikke indstillingen af Forecast-planen .
Oprette en disponeringsgruppe, der omfatter en behovsprognose
For at konfigurere en dækningsgruppe til at inkludere en efterspørgselsprognose, følg disse trin:
Gå til Master Planning>Setup>Plans>Dækningsgrupper.
Vælg en eksisterende disponeringsgruppe, eller opret en ny gruppe.
I oversigtspanelet Andet skal du indstille følgende felter:
Prognos plan tidsafgrænse – Indtast antallet af dage (fra dagens dato), som efterspørgselsprognosen skal gælde for. Du kan tilsidesætte denne værdi ved at bruge muligheden Forecast plan på masterplanen, som beskrevet i det forrige afsnit.
Reduktionsnøgle – Vælg den reduktionsnøgle, der skal anvendes. Læs mere i afsnittene Lav og opsæt en prognosereduktionsnøgle og brug en reduktionsnøgle senere i denne artikel.
Reducer prognose med – For behovsplaner, hvor feltet Metode, der er brugt til at reducere prognosebehovet er angivet til Transaktioner – reduktionsnøgle eller Transaktioner – dynamisk periode, skal du angive, hvilke transaktioner der skal reducere prognoses. Vælg en af følgende værdier:
- Alle transaktioner – Alle transaktioner reducerer prognosen.
- Ordrer – Kun salgsordrer reducerer prognosen.
Bemærkning
Hvis du vælger Alle transaktioner, betragter systemet transaktioner, der har både udbud og efterspørgsel i samme lagerdimensioner, som neutrale, og ignorerer dem under prognosereduktionen. For eksempel, hvis planlægningsdimensionen er sat til kun lokation og ikke lager, ignorerer systemet en overførselsordre mellem sted 1, lager 11 og sted 1, lager 13, og det reducerer ikke den resterende efterspørgselsprognose.
Medtag interne ordrer – Angiv denne indstilling til Ja, hvis der skal inkluderes interne ordrer, når prognosen reduceres. Ellers skal du angive den til Nej.
Medtag debitorprognose i behovsprognosen – Angiv, om en debitorprognose skal medtages i den overordnede prognose. Denne indstilling bestemmer, hvordan faktisk efterspørgsel reducerer den estimerede efterspørgsel. Brug det til at sikre, at masterplanlægningen dækker udbuddet af varer, som specifikke kunder køber.
- Angiv denne indstilling til Ja for at medtage en kundeprognose i den overordnede prognose. I dette tilfælde reducerer det faktiske kundebehov både debitorprognosen og den overordnede prognose. Varedisponering genererer kun ordreforslag til dækning af den overordnede prognosemængde.
- Angiv denne indstilling til Nej for ikke at medtage en kundeprognose i den overordnede prognose. I dette tilfælde reducerer det faktiske kundebehov kun debitorprognosen. Behovsplanlægning genererer ordreforslag til dækning af både den samlede budgetmængde og prognosen for hver debitormængde.
Prognosereduktionsnøgler
Dette afsnit giver information om de forskellige metoder, der reducerer kravene til prognoser. Det omfatter eksempler på de enkelte metoders resultater. Det beskriver endvidere, hvor du opretter, konfigurerer og anvender en prognosereduktionsnøgle. Visse metoder anvender en prognosereduktionsnøgle til at reducere prognosekrav.
Metoder til at reducere prognosekrav
Når du inkluderer en prognose i en masterplan, skal du vælge, hvordan du reducerer prognosekravene, når den faktiske efterspørgsel indregnes. Masterplanlægning udelukker tidligere forudsigelseskrav, hvilket betyder, at alle prognosekrav før dagens dato er blevet udeladt.
For at inkludere en prognose i en masterplan og vælge metoden til at reducere prognosekravene, gå til Master planning>Setup>Plans> Masterplaners. Vælg en prognosemodel i feltet Prognosemodel. I feltet Metode, der anvendes til at reducere prognosekrav skal du vælge en metode. Følgende valgmuligheder er tilgængelige:
- Ingen
- Procent – reduktionsnøgle
- Transaktioner – reduktionsnøgle
- Transaktioner – dynamisk periode
I de følgende afsnit finder du flere oplysninger om hver indstilling.
Ingen
Hvis du vælger Ingen, reduceres prognosekravene ikke i forbindelse med behovsplanlægningen. I dette tilfælde opretter varedisponeringen de planlagte ordrer for at opfylde det forventede behov (prognosekrav). Disse planlagte ordrer indeholder det foreslåede antal uafhængigt af andre behovstyper. Hvis der eksempelvis indløber salgsordrer, opretter varedisponeringen yderligere planlagte ordrer for at opfylde salgsordrene. Antallet af prognosekrav reduceres ikke.
Procent – reduktionsnøgle
Hvis du vælger Procent-reduktionsnøgle, reducerer systemet prognosekravene i henhold til de procenter og perioder, som reduktionsnøglen definerer. I dette fælde opretter varedisponeringen de planlagte ordrer, såfremt antallet beregnes i henhold til forventet antal × reduktionsnøgle for hver periode. Hvis der findes andre typer efterspørgsel, skaber masterplanlægning også planlagte ordrer til at dække denne efterspørgsel.
Eksempel: procent – reduktionsnøgle
Dette eksempel viser, hvordan en reduktionsnøgle reducerer kravene til efterspørgselsprognoser i henhold til de procenter og perioder, som reduktionsnøglen definerer.
I dette eksempel skal du medtage følgende behovsprognose i en masterplan.
| Måned | Behovsprognose |
|---|---|
| Januar | 1,000 |
| Februar | 1,000 |
| Marts | 1,000 |
| April | 1,000 |
På siden Reduktionsnøgler skal du konfigurere følgende linjer.
| Change | Enhed | Procent |
|---|---|---|
| 1 | Måned | 100 |
| 2 | Måned | 75 |
| 3 | Måned | 50 |
| 4 | Måned | 25 |
Du tildeler reduktionsnøglen til varens dækningsgruppe. Dernæst vælger du Procent - reduktionsnøgle på siden Masterplaner i feltet Metode, der anvendes til at reducere prognosekrav.
I dette tilfælde, hvis du kører prognoseplanlægning den 1. januar, forbruger systemet efterspørgselsprognoserne i henhold til de procenter, du har sat på siden for reduktionsnøgler . Følgende behovsantal overføres til behovsplanen.
| Måned | Planlagt ordreantal | Beregning |
|---|---|---|
| Januar | 0 | = 0 % × 1.000 |
| Februar | 250 | = 25 % × 1.000 |
| Marts | 500 | = 50 % × 1.000 |
| April | 750 | = 75 % × 1.000 |
| Maj-december | 1,000 | = 100 % × 1.000 |
Transaktioner – reduktionsnøgle
Hvis du sætter feltet Metode, der bruges til at reducere prognosekrav, til Transaktioner - reduktionsnøgle, reducerer systemet prognosekravene med de kvalificerede efterspørgselstransaktioner, der finder sted i de perioder, som reduktionsnøglen definerer.
Feltet Reducer prognose med på siden Dækningsgrupper angiver den kvalificerede efterspørgsel. Hvis du angiver feltet Reducer budget pr. felt til Ordrer, betragtes kun salgsordreposteringer som værende kvalificeret efterspørgsel. Hvis du angiver den til Alle transaktioner, betragtes eventuelle lagerposteringer for ikke-interne afgange som kvalificerede behov. Hvis der skal inkluderes interne ordrer, når prognosen reduceres, skal indstillingen Medtag interne ordrer angives til Ja.
Prognosereduktion starter med den første (tidligste) efterspørgselsprognosepost i reduktionsnøgleperioden. Hvis mængden af kvalificerede lagertransaktioner er større end mængden af efterspørgselsprognoselinjer i samme reduktionsnøgleperiode, bruges saldoen af lagertransaktioner til at reducere mængden af efterspørgselsprognosen i den foregående periode (hvis der er uforbrugt prognose).
Hvis der ikke er nogen uforbrugt prognose tilbage i den forrige reduktionsnøgleperiode, reducerer mængden af lagertransaktioner prognosen i den næste måned (hvis der er en uforbrugt prognose).
Værdien i feltet Procent på reduktionsnøglelinjerne bruges ikke, når den metode, der bruges til at reducere budgetbehovsfeltet, er angivet til Transaktioner - reduktionsnøgle. Kun datoerne definerer reduktionsnøgleperioden.
Bemærkning
Systemet ignorerer enhver prognose, du poster på eller før dagens dato, og bruger den ikke til at oprette planlagte ordrer. For eksempel, hvis du genererer din efterspørgselsprognose for måneden den 1. januar og kører en masterplanlægning, der inkluderer efterspørgselsprognoser den 2. januar, ignorerer beregningen efterspørgselsprognosen, der er dateret 1. januar.
Eksempel: transaktioner – reduktionsnøgle
Dette eksempel viser, hvordan faktiske ordrer, der opstår i de perioder, som reduktionsnøglen definerer, reducerer efterspørgselsprognoserne.
I dette eksempels skal du vælge Transaktioner - reduktionsnøgle i feltet Metode, der anvendes til at reducere prognosekrav på siden Masterplaner.
Der findes følgende linjer i efterspørgselsprognosen den 1. april.
| Date | Antal budgetterede enheder |
|---|---|
| 5. april | 100 |
| 12. april | 100 |
| 19. april | 100 |
| 26. april | 100 |
| 3. maj | 100 |
| Maj 10 | 100 |
| Maj 17 | 100 |
Der findes følgende salgsordrelinjer i april.
| Date | Antal anmodede enheder |
|---|---|
| 27. april | 240 |
Følgende behovsantal overføres til behovsplanen, når der køres behovsplanlægning den 1. april. Som du kan se, blev budgetposterne i april reduceret med behovet på 240 i en rækkefølge med udgangspunkt i den første af disse posteringer.
| Date | Antal krævede enheder |
|---|---|
| 5. april | 0 |
| 12. april | 0 |
| 19. april | 60 |
| 26. april | 100 |
| 27. april | 240 |
| 3. maj | 100 |
| Maj 10 | 100 |
| Maj 17 | 100 |
Antag nu, at du importerer nye ordrer for perioden maj.
Der findes følgende salgsordrelinjer i maj.
| Date | Antal anmodede enheder |
|---|---|
| Maj 4 | 80 |
| Maj 11 | 130 |
Når du kører masterplanlægning den 1. april, overfører systemet følgende kravmængder til masterplanen. Som du kan se, reducerer efterspørgselsmængden på 240 april-prognosetransaktionerne i en rækkefølge, startende fra den første af disse transaktioner. Dog reducerer efterspørgselsmængden 210 maj-prognosetransaktionerne, startende med den første efterspørgselsprognosetransaktion i maj. Totalerne pr. periode er bevaret (400 i april og 300 i maj).
| Date | Antal krævede enheder |
|---|---|
| 5. april | 0 |
| 12. april | 0 |
| 19. april | 60 |
| 26. april | 100 |
| 27. april | 240 |
| 3. maj | 0 |
| Maj 4 | 80 |
| Maj 10 | 0 |
| Maj 11 | 130 |
| Maj 17 | 90 |
Transaktioner – dynamisk periode
Hvis du vælger Transaktioner - dynamisk periode, reducerer faktiske ordretransaktioner, der sker i den dynamiske periode, prognosebehovene. Den dynamiske periode dækker de aktuelle budgetdatoer og slutter ved starten af det næste budget. I dette tilfælde opretter varedisponeringen de planlagte ordrer for at opfylde det forventede behov (prognosekrav). Men når du placerer faktiske ordretransaktioner, reducerer de prognosekravene. De faktiske transaktioner forbruger dele af prognosekravene.
Når du bruger denne mulighed, opstår følgende adfærd:
- Der stilles ikke krav om reduktionsnøgler, og de finder ej heller anvendelse.
- Hvis prognosen reduceres helt, bliver prognosekravene for den aktuelle prognose 0 (nul).
- Hvis der ikke er nogen fremtidig prognose, reducerer systemet prognosekravene fra den sidste prognose, du indtastede.
- Tidshorisonter medtages i beregningen af budgetreduktionen.
- Positive dage medtages i beregningen af budgetreduktionen.
- Hvis de faktiske ordreposteringer overstiger budgetbehovet, overføres de resterende posteringer ikke til den næste budgetperiode.
Eksempel 1: transaktioner – dynamisk periode
Her er et simpelt eksempel, der viser, hvordan Transactions - dynamic period-metoden fungerer.
I dette eksempel skal du medtage følgende behovsprognose i en masterplan.
| Date | Behovsprognose |
|---|---|
| 1. januar | 1,000 |
| 1. februar | 1,000 |
Du kan ligeledes oprette følgende salgsordrer.
| Date | Salgsordremængde |
|---|---|
| 15. januar | 200 |
| 15. februar | 400 |
I dette tilfælde skaber systemet følgende planlagte ordrer.
| Dato for behovsprognose | Quantity | Forklaring |
|---|---|---|
| 1. januar | 800 | Prognosekrav (=1.000 – 200) |
| 15. januar | 200 | Krav til salgsordrer |
| 1. februar | 600 | Prognosekrav (=1.000 – 400) |
| 15. februar | 400 | Krav til salgsordrer |
Eksempel 2: transaktioner – dynamisk periode
I de fleste tilfælde konfigureres systemerne, således at transaktionerne reducerer behovsprognosen i specifikke prognoseperioder: uger, måneder osv. Disse perioder er defineret i reduktionsnøglen. Men tiden mellem to linjer i behovsprognosen kan også omfatte en periode.
I dette eksempel skal du oprette en behovsprognose for følgende datoer og antal.
| Date | Behovsprognose |
|---|---|
| 1. januar | 1,000 |
| 5. januar | 500 |
| 12. januar | 1,000 |
Bemærk, at der i denne prognose ikke er en tydelig periode mellem prognosedatoerne. Mellem første og anden date er der en periode på fire dage, og mellem anden og tredje date er der syv dage. Disse intervaller er dynamiske perioder.
Du kan ligeledes oprette følgende salgsordrelinjer.
| Date | Salgsordremængde |
|---|---|
| 15. december forrige år | 500 |
| 3. januar | 100 |
| 10. januar | 200 |
Salgsordrerne reducerer prognosen på følgende måder:
- Da den første salgsordre ikke indgår i nogen periode, reducerer den ikke prognoserne.
- Da den anden salgsordre ligger mellem den 1. og 5. januar, vil den reducere prognosen for den 1. januar med 100.
- Da den tredje salgsordre ligger mellem den 5. og 12. januar, vil den reducere prognosen for den 5. januar med 200.
Derfor skaber systemet følgende planlagte ordrer.
| Dato for behovsprognose | Quantity | Forklaring |
|---|---|---|
| 15. december forrige år | 500 | Krav til salgsordrer |
| 1. januar | 900 | Prognosekrav for perioden 1. til 5. januar (= 1.000 – 100) |
| 3. januar | 100 | Krav til salgsordrer |
| 5. januar | 300 | Prognosekrav for perioden 5. til 10. januar (= 500 – 200) |
| 12. januar | 1,000 | Prognosekrav for perioden 12. januar til slut |
Opret og konfigurer en prognosereduktionsnøgle
En prognosereduktionsnøgle anvendes af metoderne Transaktioner - reduktionsnøgle og Procent - reduktionsnøgle til at reducere prognosekrav. Følg følgende fremgangsmåde for at oprette og konfigurere en reduktionsnøgle:
Gå til Hovedplanlægning>Opsætning>Dækning>Reduktionsnøgler.
Vælg Ny for at oprette en reduktionsnøgle.
I feltet Reduktionsnøgle indtastes en unik identifikator for prognosereduktionsnøglen. Dernæst indtastes et navn i feltet Navn.
Fastsæt perioderne og reduktionsnøgleprocenterne for hver periode:
- Feltet Ikrafttrædelsesdato angiver datoen for, hvornår periodens start blev oprettet. Når indstillingen Anvend ikrafttrædelsesdatoen er angivet til Ja, starter perioderne på den pågældende dato. Når indstillingen er angivet til Nej, starter perioderne, når varedisponeringen køres.
- Angiv de perioder, hvor prognosereduktionen skal finde sted.
- Angiv for en bestemt periode de procentandel, som prognosekravene bør reduceres med. Indtast positive værdier for at mindske kravene eller negative værdier for at øge kravene.
Anvend en reduktionsnøgle
Der skal tildeles en prognosereduktionsnøgle til elementets dækningsgruppe. Følg disse trin for at tildele en reduktionsnøgle til et elements dækningsgruppe.
Gå til Varedisponering>Opsætning>Dækning>Dækningsgrupper.
I feltet Reduktionsnøgle i oversigtspanelet Andre vælges den reduktionsnøgle, der skal tildeles dækningsgruppen. Reduktionsnøglen gælder derefter for alle elementer, der tilhører den pågældende dækningsgruppe.
Hvis du vil bruge en reduktionsnøgle til at beregne prognosereduktionen i løbet af behovsplanlægningen, skal du definere denne indstilling under opsætningen af prognoseplanen eller masterplanen. Gå til en af følgende placeringer:
- Masterplanlægning>Opsætning>Planer>Prognoseplaner
- Masterplanlægning>Opsætning>Planer>Masterplaner
I feltet Metode, der anvendes til at reducere prognosekrav i oversigtspanelet Generelt på siden Prognoseplaner eller Varedisponering vælges enten Procent - reduktionsnøgle eller Transaktioner - reduktionsnøgle.
Reducer en prognose med transaktioner
Når du vælger Transaktioner - reduktionsnøgle eller Transaktioner - dynamisk periode som en metode til at reducere prognosekrav, kan du præcisere de transaktioner, der skal reducere prognosen. I feltet Reducer prognose med i oversigtspanelet Andre på siden Disponeringsgrupper skal du vælge Alle transaktioner, hvis alle transaktioner skal reducere prognosen, eller Ordrer, hvis alene salgsordrer skal reducere prognosen.
Overvej kunde, kundegruppe, påkrævet stykliste og påkrævet rute ved reduktion af efterspørgselsprognose
Hver efterspørgselsprognoselinje kan specificere en kunde, en kundegruppe, en påkrævet stukliste og en påkrævet rute. Når du slår Consider BOM til og ruter supply- og demandprognosereduktion med funktionen Planlægningsoptimering i Feature management, respekterer Planning Optimization alle fire dimensioner, når den beslutter, om en eksisterende efterspørgselstransaktion (såsom en salgsordrelinje) reducerer en prognoselinje.
Forudsætninger
Før du kan bruge stykktelisten og ruteprognosereduktionsadfærden, som er beskrevet i dette afsnit, skal dit system opfylde følgende krav:
- Du skal køre Microsoft Dynamics 365 Supply Chain Management version 10.0.49 eller nyere.
- Funktionen kaldet Overvej stykkliste og rute i reduktion af udbuds- og efterspørgselsprognoser med planlægningsoptimering skal aktiveres i funktionsstyring.
Matchningsprincippet
Adfærden følger et enkelt princip:
En transaktion reducerer kun en prognoselinje, når transaktionen for hver dimension, som prognoselinjen angiver, enten matcher den værdi eller ikke angiver en værdi for den dimension. En transaktion, der angiver en anden værdi end prognoselinjen for en hvilken som helst dimension, kan ikke reducere den prognoselinje.
Med andre ord kan en transaktion være på samme specificitet som prognoselinjen eller mindre specifik, men den kan ikke være specifik på en anden måde.
Specificitetsregler for efterspørgselsprognoselinjer
Princippet fører til følgende regler. I hver regel refererer transaktion til en salgsordrelinje (eller, når dækningsgruppen er sat til Alle transaktioner, enhver kvalificeret udstedelseslagertransaktion), som ellers ville reducere prognosen.
- En prognoselinje, der angiver både en påkrævet stukliste og en påkrævet rute, reduceres kun af transaktioner, der angiver den samme stykkliste og den samme rute, eller som lader en eller begge værdier stå tomme.
- En prognoselinje, der angiver en obligatorisk stykliste, men ingen obligatorisk rute, reduceres af transaktioner, der angiver den samme stykliste (uanset rute), og af transaktioner, der ikke angiver nogen stykliste.
- En prognoselinje, der angiver en påkrævet rute, men ingen påkrævet stykliste, reduceres af transaktioner, der angiver den samme rute (uanset stykliste), og af transaktioner, der ikke angiver en rute.
- En prognoselinje, der hverken angiver en påkrævet stykliste eller en påkrævet rute, reduceres med enhver transaktion, der ellers opfylder betingelserne.
- En transaktion, der hverken specificerer en stukliste eller en rute, kan reducere enhver prognoselinje, uanset hvor specifik den prognoselinje er.
Det samme princip gælder for kundens og kundegruppens dimensioner på prognoselinjen: en salgsordre for en specifik kunde kan reducere en prognoselinje, der specificerer den samme kunde, eller som kun angiver den kundegruppe, kunden tilhører, eller som angiver, at der ikke er nogen kunde eller kundegruppe. En salgsordre for en anden kunde kan ikke reducere en kundespecifik prognoselinje.
Følgende tabel opsummerer matchningsadfærden for BOM- og rutedimensionerne. Et Ja angiver, at transaktionen reducerer prognoselinjen. Et nej indikerer, at transaktionen ikke reducerer prognoselinjen, fordi den angiver en modstridende værdi.
| Prognoselinje specificerer | Tx (B1, R1) | Tx (B1, R2) | Tx (B2, R1) | Tx (B1, –) | Tx (–, R1) | Tx (–, –) |
|---|---|---|---|---|---|---|
| krævet BOM = B1, påkrævet Rute = R1 | Ja | Nej | Nej | Ja | Ja | Ja |
| krævet BOM = kun B1 | Ja | Ja | Nej | Ja | Ja | Ja |
| krævet Rute = kun R1 | Ja | Nej | Ja | Ja | Ja | Ja |
| Ingen af dem specificerede | Ja | Ja | Ja | Ja | Ja | Ja |
Bemærkning
Denne specificitetslogik er uafhængig af Inkluder kundeprognosen i efterspørgselsprognose-muligheden på dækningsgruppen. Den mulighed styrer stadig, om en kundespecifik prognose også reducerer (og bidrager til) den samlede prognose. Reglerne i dette afsnit bestemmer, hvilke transaktioner der er berettigede til at reducere en given prognoselinje i første omgang.
Eksempel: To efterspørgselsprognoselinjer med forskellige påkrævede styklister (BOM)
Du har en vare, der har følgende efterspørgselsprognoselinjer.
| Model | Date | Quantity | Enhed | Kunde | Kundegruppe | Påkrævet BOM | Påkrævet rute | Websted | Lagersted |
|---|---|---|---|---|---|---|---|---|---|
| CurrentF | 10/10/22 | 10 | styk | B1 | 1 | 11 | |||
| CurrentF | 10/10/22 | 10 | styk | B2 | 1 | 11 |
Der findes en salgsordrelinje for en mængde på 15 ea med BOM B2, dateret inden for samme prognoseperiode.
Systemet fungerer forskelligt afhængigt af, om funktionen Tag højde for stykliste og rute i reduktion af udbuds- og efterspørgselsprognoser med Planlægningsoptimering er aktiveret:
- Når funktionen slås fra – Salgsordren reducerer efterspørgselsprognosen i den rækkefølge, linjerne mødes, uden at tjekke styklisten. Den første linje reduceres til 0, den anden linje reduceres til 5, og Planlægningsoptimering opretter en planlagt ordre til at dække de resterende 5 ea af prognosen på den anden linje.
- Når funktionen er aktiveret – Kun den anden linje matcher salgsordrens stykkliste. Salgsordren reducerer den anden linje til 0 og efterlader den første linje på 10. Planlægningsoptimering opretter derefter en planlagt ordre til at dække de resterende 10 ea med BOM B1, plus en planlagt ordre til at dække de 15 ea af salgsordreefterspørgsel med BOM B2.
Eksempel: Kombineret kunde, kundegruppe, påkrævet stykktest og påkrævet rute
Du har en vare, der har følgende efterspørgselsprognoselinjer. Kunde Cust-1 tilhører kundegruppen CG-1. Kunde-Cust-2 tilhører ikke kundegruppen CG-1.
| Linje | Quantity | Kunde | Kundegruppe | Påkrævet BOM | Påkrævet rute |
|---|---|---|---|---|---|
| L1 | 10 | Cust-1 | CG-1 | B1 | R1 |
| L2 | 10 | CG-1 | B1 | ||
| L3 | 10 | R1 | |||
| L4 | 10 |
Følgende salgsordrelinjer findes for samme vare, sted og lager inden for samme prognoseperiode.
| Salgsordre | Quantity | Kunde | Stykliste | Rute |
|---|---|---|---|---|
| SO-A | 5 | Cust-1 | B1 | R1 |
| SO-B | 5 | Cust-1 | B1 | |
| SO-C | 5 | Cust-2 | B1 | R1 |
| SO-D | 5 |
Med funktionen aktiveret evaluerer Planlægningsoptimering hver salgsordre i forhold til hver prognoselinje. Når en salgsordre kan reducere mere end én prognoselinje, anvender Planlægningsoptimering reduktionen på den mest specifikke matchende linje først, så mindre specifikke prognoselinjer forbliver tilgængelige for at dække anden efterspørgsel.
- SO-A (Cust-1, B1, R1) matcher alle dimensioner af L1. Det matcher også L2 (kunden tilhører CG-1, stykklisten matcher, og L2 begrænser ikke ruten), men L1 er mere specifik, så det reducerer L1 med 5.
- SO-B (Cust-1, B1, ingen rute) matcher kunden og BOM for L1 og er mindre specifik om ruten, så det reducerer også L1 med 5. L1 er nu fuldt opbrugt.
- SO-C (Cust-2, B1, R1) kan ikke reducere L1 eller L2, fordi Cust-2 ikke matcher L1's kunde og ikke tilhører L2's kundegruppe. Den matcher L3 på ruten (og må være mere specifik end prognoselinjen på de andre dimensioner), så den reducerer L3 med 5.
- SO-D (ingen kunde, ingen stykkteliste, ingen rute) er fuldstændig uspecificeret, så den kan reducere enhver resterende prognoselinje. Planlægningsoptimering anvender det på den mest specifikke linje, der stadig har åben mængde, nemlig L2, og reducerer L2 med 5.
De resterende efterspørgselsprognoser er L1 = 0, L2 = 5, L3 = 5 og L4 = 10. Planlægningsoptimering skaber planlagte ordrer for at dække denne resterende efterspørgsel sammen med salgsordrebehovet.
Bemærkning
Når funktionen er slået til, gælder samme stykkliste- og rutematching også for efterspørgselstransaktioner, der allerede er behandlet inden for prognoseperioden – for eksempel fakturerede salgsordrer. Den stykliste og rute, der er angivet på den oprindelige salgsordre, følges, når ordren reducerer en prognoselinje, ligesom for åbne salgsordrer.
Reduktion af allerede behandlede transaktioner styres selv af en separat feature management-funktion: Inkluder fakturerede og leverede ordrer under reduktion af udbuds- og efterspørgselsprognoser for planlægningsoptimering. Denne funktion skal også slås til, for at behandlede ordrer overhovedet kan deltage i prognosereduktion. Funktionen Consider BOM og rute i udbuds- og efterspørgselsprognosereduktion med Planning Optimization-funktionen styrer derefter, hvordan stykklisten og ruten på de behandlede ordrer matches.
De samme regler gælder for udbudsprognoser. Lær mere i Overvej delstykliste og delrute ved reduktion af forsyningsprognose.
Budgetmodeller og undermodeller
I dette afsnit beskrives, hvordan du kan oprette budgetmodeller, og hvordan du kan kombinere flere budgetmodeller ved at konfigurere undermodeller.
En budgetmodel navngiver og identificerer et bestemt budget. Når du har oprettet prognosemodellen, kan du tilføje prognoselinjer til den. Brug siden Behovsprognoselinjer til at tilføje budgetlinjer for flere varer. Brug siden Frigivne produkter til at tilføje budgetlinjer for en bestemt valgt vare.
En budgetmodel kan inkludere budgetter fra andre budgetmodeller. For at opnå dette resultat tilføjes andre prognosemodeller som delmodeller af en overordnet prognosemodel. Du skal oprette hver relevant model, før du kan tilføje den som undermodel til en overordnet budgetmodel.
Den struktur, der fås som resultat, giver dig mulighed for at styre budgetter på en effektiv måde, da du kan kombinere (samle) input fra flere individuelle budgetter. Fra et planlægningssynspunkt er det derfor let at kombinere budgetter til simuleringer. Du kan f.eks. konfigurere en simulering, der er baseret på kombinationen af et almindeligt budget med budgettet for en forårskampagne.
Undermodelniveauer
Du kan tilføje ubegrænsede delmodeller til en forældreprognosemodel. Strukturen kan dog kun være ét niveau dyb. Det vil sige, at en budgetmodel, der er en undermodel af en anden budgetmodel, ikke kan have egne undermodeller. Når du føjer undermodeller til en budgetmodel, kontrollerer systemet, om den pågældende budgetmodel allerede er en undermodel til en anden budgetmodel.
Hvis der ved behovsplanlægningen findes en undermodel med egne undermodeller, får du vist en fejlmeddelelse.
Eksempel på undermodelniveauer
Budgetmodel A har budgetmodel B som undermodel. Budgetmodel B kan derfor ikke have egne undermodeller. Hvis du forsøger at føje en undermodel til budgetmodel B, får du følgende fejlmeddelelse: "Budgetmodel B er en undermodel til model A".
Samle budgetter på tværs af budgetmodeller
Systemet samler prognoselinjer, der forekommer samme dag, på tværs af deres prognosemodel og dens delmodeller.
Eksempel på sammenlægning
Budgetmodel A har budgetmodel B og C som undermodeller.
- Budgetmodel A inkluderer en behovsprognose på 2 stk. den 15. juni.
- Budgetmodel B inkluderer en behovsprognose på 3 stk. den 15. juni.
- Budgetmodel C inkluderer en behovsprognose på 4 stk. den 15. juni.
Den resulterende efterspørgselsprognose er en enkelt efterspørgsel på 9 pcs (2 + 3 + 4) den 15. juni.
Bemærkning
Hver undermodel bruger sine egne parametre, og ikke parametrene i den overordnede budgetmodel.
Oprette en budgetmodel
For at skabe en prognosemodel følger du disse trin:
Gå til Master Planning>Opsætning>Efterspørgselsprognoser>Prognosemodeller.
Gå til handlingsruden, og vælg Ny.
Angiv følgende felter for den nye budgetmodel:
- Model – Angiv et entydigt id for modellen.
- Navn – Angiv et sigende navn til modellen.
- Stoppet – Normalt skal du angive denne indstilling til Nej. Angiv kun til Ja, hvis du vil forhindre redigering af alle budgetlinjer, der er tildelt modellen.
Bemærkning
Feltet Medtag i likviditetsbudgetter og felterne i oversigtspanelet Projekt er ikke relateret til behovsplanlægning. Du kan derfor ignorere dem i denne sammenhæng. Overvej dem kun, når du arbejder med prognoser til modulet Project management and accounting.
Tildele en prognosemodel undermodeller
For at tildele delmodeller til en prognosemodel, følg disse trin:
Gå til Lagerstyring>:Opsæt>prognoser>,prognosemodeller.
Vælg den budgetmodel, som du vil oprette en undermodel til, i listeruden.
I oversigtspanelet Undermodel skal du vælge Tilføj for at føje en række til gitteret.
Angiv følgende felter i den nye række:
- Undermodel – Vælg den budgetmodel, der skal tilføjes som undermodel. Denne budgetmodel skal allerede findes, og den må ikke have egne undermodeller.
- Navn – Angiv et sigende navn til undermodellen. Dette navn kan f.eks. angive undermodellens relation til den overordnede budgetmodel.