Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Notat
Interessegrupper i fellesskapet har nå flyttet fra Yammer til Microsoft Viva Engage. Hvis du vil bli med i et Viva Engage-fellesskap og delta i de siste diskusjonene, fyller du ut skjemaet Be om tilgang til Finance and Operations Viva Engage Community og velger fellesskapet du vil bli med i.
Når du går over fra den avskrevne innebygde hovedplanleggingsmotoren til planleggingsoptimalisering, kan du legge merke til forskjeller i planlagte ordrer, antall og datoer. Bruk denne artikkelen og de relaterte ressursene til å identifisere om et problem du opplever, skyldes en forventet forskjell, en funksjon som ikke støttes eller en parameterendring.
Identifiser problemtypen
Bruk tabellen nedenfor til å finne riktig ressurs for din situasjon:
| Problem | Ressurs |
|---|---|
| Planleggingsoptimalisering viser ulike planlagte ordreresultater, datoer, antall eller virkemåte | Forventede forskjeller (denne artikkelen) |
| En funksjon fungerer ikke eller mangler i planleggingsoptimalisering | Analyse for tilpasning av planleggingsoptimalisering |
| Dato- eller klokkeslettberegninger gir forskjellige resultater | Parametere for dato og klokkeslett som brukes av planleggingsoptimalisering |
| En hovedplanleggingsparameter ser ikke ut til å ha noen effekt | Parametere som ikke brukes av planleggingsoptimalisering |
| Du har spørsmål om når den avskrevne motoren fjernes | Oversikt over avskrevet hovedplanlegging |
| Du trenger veiledning om hele overføringsprosessen | Overføring til planleggingsoptimalisering |
Forventede forskjeller
Tabellen nedenfor viser spesifikke forskjeller mellom planleggingsoptimalisering og den avskrevne hovedplanleggingsmotoren som ikke er oppført på siden analyse av planleggingsoptimalisering .
| Funksjon | Hvordan Planleggingsoptimalisering er forskjellig fra avskreven hovedplanlegging |
|---|---|
| Prognoser for dagens dato | Planleggingsoptimalisering tar ikke hensyn til prognoser for dagens dato, selv om den utgåtte hovedplanleggingsmotoren tok hensyn til dem. |
| Filtrerte produksjonsutkjøringer | Hvis du vil ha mer informasjon, kan du se Produksjonsplanlegging – filtre. |
| Prognoseplanlegging | Prognoseplanlegging støttes ikke. Bruk hovedplanlegging der en prognosemodell er tilordnet hovedplanen. |
| Nummersekvenser for planlagte ordrer | Nummerserier for planlagte ordrer støttes ikke. Planleggingsoptimalisering bruker sin egen proprietære nummerserie for alle genererte planlagte ordrenumre, og det finnes ingen metode for å endre denne nummersekvensen. Innstillingen for planlagt bestillingsnummer for hovedplanlegging på fanen Nummerserier på hovedplanleggingsparametersiden har ingen effekt når du bruker planleggingsoptimalisering. Det planlagte ordrenummeret viser vanligvis 14 sifre, men sekvensen er faktisk bygget på 20 tegn, med seks sifre tildelt for antall planleggingskjøringer og 10 for antall planlagte ordrer. |
| Planlegg kopiering, slett plan og opprydding av planversjon | Under Hovedplanlegging For å vedlikeholde planer for hovedplanlegging >> i navigasjonsruten deaktiveres følgende elementer:
|
| Returordrer | Planleggingsoptimalisering vurderer ikke returordrer. |
| Planleggingsrelaterte funksjoner | Hvis du vil ha mer informasjon, kan du se Planlegging med uendelig kapasitet. |
| Fullføring av sikkerhetslager | Planleggingsoptimalisering bruker alltid Dagens dato + leveringstid for feltet Fyll opp minimum på siden Varedekning. Dette valget bidrar til å forhindre uønskede planlagte ordrer og andre problemer. Hvis innkjøpstiden ikke er inkludert for sikkerhetslageret, blir planlagte ordrer som opprettes for lite lagerbeholdning, alltid forsinket på grunn av ledetid. Finn ut mer i Sikkerhetslageroppfyllelse med den avskrevne hovedplanleggingsmotoren. |
| Utligning av sikkerhetslager og nettobehov | Kravtypen Sikkerhetslager er ikke inkludert og vises ikke på siden Nettobehov. Sikkerhetslager representerer ikke etterspørsel og har ikke en tilknyttet behovsdato. I stedet definerer det en begrensning for hvor mye lager som må finnes til enhver tid. Det tas imidlertid fremdeles hensyn til Minimum-feltverdien ved beregning av planlagte bestillinger under hovedplanleggingen. Undersøk kolonnen Akkumulert antall på siden Nettokrav for å se at denne verdien ble vurdert. Fordi pegging er annerledes, kan ulike handlinger foreslås. Finn ut mer i Sikkerhetslageroppfyllelse med den avskrevne hovedplanleggingsmotoren. |
| Transportkalendere | Verdien i kolonnen Transportkalender på siden Leveringsmåter ignoreres. |
| Minimum/maksimum dekningskode uten verdier | Med den avskrevne hovedplanleggingsmotoren når du bruker en minimums- eller maksimumskode der ingen minimums- eller maksimumsverdier er angitt, behandler planleggingsmotoren dekningskoden som et krav, og oppretter én ordre for hvert behov. Med planleggingsoptimalisering oppretter systemet én ordre per dag for å dekke hele beløpet for den dagen. |
| Nettobehov og manuelt opprettede planlagte ordrer | Med den avskrevne hovedplanleggingsmotoren vises manuelt opprettede forsyningsordrer for en vare blant nettobehovene for denne varen. Når du for eksempel oppretter en bestilling fra en salgsordre, vises bestillingen på siden For nettokrav uten å kreve noen tidligere handlinger. Denne virkemåten oppstår fordi den avskrevne hovedplanleggingsmotoren logger lagertransaksjoner i inventLogTTS tabellen og viser endringer på siden For nettokrav for dynamiske planer. Med planleggingsoptimalisering vises imidlertid ikke manuelt opprettede ordrer blant nettokravene til et element før du kjører planleggingsoptimalisering (ved hjelp av en plan som inneholder elementet), eller til du velger Oppdater > hovedplanlegging på handlingsruten på siden For nettokrav , som kjører hovedplanlegging for elementet. Hvis du vil ha mer informasjon om hvordan du arbeider med Nettobehov-siden, kan du se Nettobehov og utligningsinformasjon. |
| Nettobehov og eventuelle endringer i tilbud eller etterspørsel | Med den avskrevne hovedplanleggingsmotoren vises eventuelle endringer for tilbud eller etterspørsel for en vare blant nettobehovene for denne varen. Når du for eksempel øker antallet for en planlagt bestilling, vises bestillingen på siden For nettokrav uten å kreve noen tidligere handlinger. Denne virkemåten oppstår fordi den avskrevne hovedplanleggingsmotoren logger lagertransaksjoner i inventLogTTS tabellen og viser endringer på siden For nettokrav for dynamiske planer. Med planleggingsoptimalisering vises imidlertid ikke eventuelle endringer blant nettokravene til et element før du kjører planleggingsoptimalisering (ved hjelp av en plan som inneholder elementet), eller til du velger Oppdater > hovedplanlegging på handlingsruten på siden For nettokrav , som kjører hovedplanlegging for elementet. Finn ut mer om hvordan du arbeider med netkravsiden i Net-krav og informasjon om utligning. |
| Ressurstilordning | Når du arbeider med ubegrenset kapasitet, tilordner den avskrevne hovedplanleggingsmotoren alle planlagte bestillinger til den samme ressursen på en angitt ressursgruppe. Planleggingsoptimalisering forbedrer denne virkemåten ved å velge ressurser tilfeldig, slik at ulike produksjonsordrer kan bruke forskjellige ressurser. Hvis du vil bruke samme ressurs for alle planlagte ordrer, angir du ressursen i ruten. |
| Utvidede datatyper (EDTs) | Planleggingsoptimalisering støtter ikke endringer i presisjonen i utvidede datatyper. Denne prosessen støttes ikke offisielt og er ikke garantert å fungere. |
| Fullføring av sikkerhetslager | Planleggingsoptimalisering bruker alltid en Fyll opp minimum for Dagens dato + leveringstid. Dette valget forbereder systemet til å bruke et forenklet planleggingsoppsett i fremtiden, og gir et handlingsbart resultat. Hvis innkjøpstiden ikke er inkludert for sikkerhetslageret, blir planlagte ordrer som opprettes for lite lagerbeholdning, alltid forsinket på grunn av ledetid. Denne virkemåten kan føre til betydelig støy og uønskede planlagte bestillinger. Den anbefalte fremgangsmåten er å endre innstillingen slik at Dagens dato + leveringstid brukes. Oppdater hoveddata for å unngå advarsler. Finn ut mer i Sikkerhetslageroppfyllelse med den avskrevne hovedplanleggingsmotoren. |
| Bestillingsoppfyllelse | Når du oppfyller en bestilling, bruker systemet alltid en leveringstid og ignorerer den aldri, selv om parameteren Legg til forsinkelse i beregnet behovsdato er satt til Nei. Denne virkemåten skiller seg fra den avskrevne hovedplanleggingsmotoren, som vil angi en umulig dato i dette tilfellet. Hvis for eksempel i dag er 1. mars 2024, er ledetid 30 dager, og Legg til forsinkelse i beregnet kravdato er satt til Nei, oppretter den avskrevne motoren en innkjøpsordre med datoen 1. mars 2024, mens planleggingsoptimalisering oppretter den med datoen 1. april 2024 (i dag pluss 30-dagers ledetid). |
| Kopier statisk til dynamisk plan | Planleggingsoptimalisering kopierer ikke statiske planer til dynamiske planer, uavhengig av innstillingen på siden Parametere for hovedplanlegging. Denne operasjonen er generelt mindre relevant på grunn av hastigheten og fullføringsregenereringen som gis av planleggingsoptimaliseringen. Hvis du bruker to eller flere planer, utløser du hovedplanlegging for hver plan. |
| Negative dager | Planning Optimization always uses dynamic negative days, regardless of the setting of Bruk dynamiske negative dager i Parametere for hovedplanlegging. Innstillingen Bruk dynamiske negative dager på siden Hovedplanleggingsparametere har ingen innvirkning på denne virkemåten. Hvis du vil ha mer informasjon om hvordan du bruker negative dager, kan du se Forsinkelsestoleranse (negative dager) |
| Dagens datokalender | Planleggingsoptimalisering vurderer ikke dagens datokalenderinnstilling på hovedsiden for planlegging av parametere . Planleggingsoptimalisering bruker alltid gjeldende tid avrundet til neste hele time. I den avskrevne hovedplanleggingsmotoren definerte denne innstillingen starten på en låsningshorisont. Systemet bruker imidlertid fortsatt dagens datokalenderparameter til å avgjøre om en manuelt opprettet produksjonsordre er planlagt innenfor frysetidsgjerdet, selv når du bruker planleggingsoptimalisering. |
| Planlagte bestillinger i fortiden | Planleggingsoptimalisering planlegger aldri bestillinger i fortiden, uavhengig av innstillingen for Ønsket dato. Hvis du angir en forespurt dato som er i fortiden, beholder systemet innstillingen, men angir den nødvendige datoen til I dag. |
| Definisjon/betydning av sikkerhetslager | I Planleggingsoptimalisering er ikke sikkerhetslager den faktiske etterspørselen. For hver dekningsgruppe kan du angi hvor strengt systemet skal utligne sikkerhetslageret som etterspørsel mot den planlagte bestillingen som er opprettet for det. (Finn ut mer i alternativer for sikkerhetslagerbinding.) Dekningsgrupper som bruker streng binding av sikkerhetslager, fungerer akkurat som alle grupper i den avskrevne motoren der feltet Oppfyll minimum er satt til Dagens dato + innkjøpstid. I den avskrevne hovedplanleggingsmotoren er sikkerhetslager etterspørsel, den samme som andre behovstyper. Du kan angi når sikkerhetslageret skal være oppfylt. |
| Når sikkerhetslageret er oppfylt | I Planleggingsoptimalisering er sikkerhetslager alltid oppfylt på dagens dato + anskaffelsestid, uavhengig av innstillingen for varedekningen. I den avskrevne hovedplanleggingsmotoren inkluderer varedekningsinnstillingene et Fyll opp minimum-felt som definerer når sikkerhetsbeholdningen må oppfylles. (Les mer om oppfylling av sikkerhetslager med den utfasede hovedplanleggingsmotoren.) |
| Prognoseplanhorisont | Når du bestemmer hvilke behovs- og forsyningsprognoseoppføringer som skal tas i betraktning, tar planleggingsoptimalisering alltid det nedre av følgende to verdier: dekningstidsgjerde eller prognoseplantidsgjerde. Den avskrevne planleggingsmotoren bruker alltid tidsgjerde for prognoseplan. Planleggingsoptimalisering garanterer derfor at tilbudet dekker alle behovsprognoseoppføringer som er inkludert i en plan. |
| Avgangsmargin | Når utstedelsesmarginen kan oppfylles, bruker planleggingsoptimalisering verdien på mottakskravdatoen, ikke utstedelseskravdatoen. Hvis margen ikke kan oppfylles, skyver planleggingsoptimalisering utstedelseskravdatoen fremover. Den utgåtte planleggingsmotoren justerer alltid utstedelsesdatoen etter verdien av marginen for utstedelse. Planleggingsoptimalisering behandler derfor problemmarginen mer korrekt, som en forsendelsestidsbuffer som påvirker hvor langt på forhånd mottak er nødvendig. Finn ut mer i Sikkerhetsmarger. |
| Leveringstid for leverandørkalender | Planleggingsoptimalisering vurderer ikke lukkede dager fra leverandørens kalender når du beregner leveringsdatoer for leveringsdatoer. Den vurderer bare dekningsgruppekalenderen ved beregning av ledetider. Finn ut mer i kalendermatrisen for planleggingsoptimalisering. |
| Null positive dager | Hvis du angir positive dager til én i planleggingsoptimalisering, får du samme virkemåte som å angi positive dager til null i den avskrevne hovedplanleggingsmotoren. |
| Planlegging med negative lagerbeholdningsantall | Hvis systemet viser et negativt aggregert antall, behandler planleggingsoptimalisering det som antall 0 (null) for å unngå over forsyning. Finn ut mer i Planlegging med negative mengder. Den utdaterte hovedplanleggingsmotoren fylte i stedet opp det negative antallet. |
| Bekreftelser av manuelt planlagte produksjonsordrer | Ved oppstrammende planlagte produksjonsordrer som ble opprettet manuelt, utløser ikke planleggingsoptimalisering automatisk eksplosjon av elementer. Du må manuelt utløse elementeksplosjoner etter behov. |
| CTP med mager produksjon | Etterfyllingsstrategien for hendelses-Kanban-regelen med hendelsestypesalg som er satt til Automatisk med CTP, genereres ikke automatisk, og kanbaner legges ikke til i tidsplanen for salgsordrelinjer som bruker kontrollmetoden for CTP-leveringsdato. I stedet kan du fylle opp en planleggings-Kanban og bruke auto-firming. |