Parametere for dato og klokkeslett som ikke brukes av planleggingsoptimalisering
Denne artikkelen gir informasjon om dato- og klokkeslettparameterne som planleggingsoptimalisering bruker under operasjonen.
Mens den avskrevne hovedplanleggingsmotoren bruker transaksjonsdatoer i alle beregninger, fungerer planleggingsoptimalisering med dato- og klokkeslettverdier som konverteres til datoer. Denne forskjellen i virkemåte kan føre til situasjoner der for eksempel prognosetransaksjoner som opprettes ved midnatt på dagen når hovedplanlegging kjøres, ikke tas med, fordi planleggingsoptimalisering tar hensyn til at de ble opprettet før gjeldende dato.
Parametere for avgangs- og behovstransaksjoner
Tabellen nedenfor viser parameterne som planleggingsoptimalisering bruker når det behandler avgangs- og behovstransaksjoner.
| Parameter | Parameternavn i planleggingsoptimalisering | Beskrivelse | Tilsvarende felt i Microsoft Dynamics 365 Supply Chain Management (i ReqTrans-tabellen) |
|---|---|---|---|
| Planlagt avgangstid | PlannedIssueTime |
Datoen som avgangen er planlagt for. | To date () ogFuturesDateForsinket til time ( FuturesTime) |
| Ønsket avgangstid | RequestedIssueTime |
Dato for avgangen som ble forespurt av brukeren og angitt i Supply Chain Management. Denne parameteren gjelder bare for frigitte eller godkjente planlagte bestillinger. For planlagte bestillinger er det tomt som standard. | Ønsket dato (ReqDateDlvOrig) |
| Nødvendig avgangstid | RequiredIssueTime |
Den nødvendige avgangsdatoen som er justert ved hjelp av planleggingsoptimalisering. Hvis den ønskede avgangstiden er i fortiden når planleggingsoptimalisering kjøres, blir den nødvendige avgangstiden justert til den første åpne dagen som ikke er tidligere enn dagens dato. Hvis den ønskede avgangstiden er merket som blokkert i kalenderen, justeres den nødvendige avgangstiden til den første åpne dagen før den datoen. | Kravdato (ReqDate) og kravtid (ReqTime) |
| Forsinkelse for avgang | IssueTimeDelay |
Tidsforskjellen mellom den planlagte avgangstiden og enten ønsket avgangstid for godkjente og frigitte ordrer eller den nødvendige avgangstiden. | Forsinkelse (i dager) (FuturesDays) |
Parametere for mottaks- og forsyningstransaksjoner
Tabellen nedenfor viser parameterne som planleggingsoptimalisering bruker når det behandler mottaks- og forsyningstransaksjoner.
| Parameter | Parameternavn i planleggingsoptimalisering | Beskrivelse | Tilsvarende felt i Supply Chain Management (i tabellen ReqTrans eller ReqPO) |
|---|---|---|---|
| Planlagt tilgjengelighetstid | PlannedAvailabilityTime |
Datoen da mottaket er planlagt å være tilgjengelig. | Kravdato (ReqDate) og kravtid (ReqTime) |
| Planlagt mottakstid | PlannedReceiptTime |
Datoen når mottaket ankommer lokasjonen. | Til-dato (FuturesDate), Forsinket til tidspunkt (FuturesTime) og Leveringsdato (ReqDateDlv) eller Forespurt dato (ReqDateDlvOrig) hvis bestillingen ikke er frigitt ennå. |
| Nødvendig tilgjengelighetstid | RequiredAvailabilityTime |
Den nødvendige tilgjengelighetsdatoen som er justert ved hjelp av planleggingsoptimalisering. | Kravdato (ReqDate) og kravtid (ReqTime) |
| Forventet mottakstid | ExpectedReceiptTime |
Forventet mottaksdato for et frigitt mottak. Verdien angis av brukeren i Supply Chain Management og justeres ikke ved hjelp av planleggingsoptimalisering. Denne parameteren gjelder bare for frigitte mottak. | Ønsket dato (ReqDateDlvOrig) |
| Nødvendig mottakstid | RequiredReceiptTime |
Den nødvendige mottaksdatoen som er justert ved hjelp av planleggingsoptimalisering. | Kravdato (ReqDate) og kravtid (ReqTime) |
| Planlagt bestillingstid | PlannedOrderingTime |
Bestillingsdatoen som er beregnet ved hjelp av planleggingsoptimalisering. | Bestillingsdato (ReqDateOrder) og bestillingstid (ReqTimeOrder) |
| Planlagt starttid for aktivitet | PlannedActivityStartTime |
Datoen når aktiviteten for dette mottaket skal starte. | Startdato (SchedFromDate) |
| Tidsforsinkelse for mottak | ReceiptTimeDelay |
Tidsdifferansen mellom den planlagte mottakstiden og den nødvendige mottakstiden. | Forsinkelse (dager) () ogFuturesDaysforsinket til tid ( FuturesTime) |
Eksempler på datoparameterbruk ved planleggingsoptimalisering
Planene i følgende illustrasjoner er på dagnivå, men planleggingsoptimaliseringen kjøres på et mer detaljert nivå. Fordi marginer for eksempel kan være i timer, kan planleggingsordretiden være 22. januar, 2021, 11:35 og så videre.
Eksempel 1: Enkelt scenario
Én salgsordre som har et forespurt avgangstid 22. januar, dekkes av én bestilling. Følgende innstillinger brukes:
- Ingen leveringstid
- Ingen kalendere (Alle dager er åpne.)
- Ingen marginer
Illustrasjonen nedenfor viser dette scenarioet. (Velg illustrasjonen for å åpne en større versjon.)
Eksempel 2: Leveringstidsscenario
Én salgsordre som har et forespurt avgangstid 22. januar, dekkes av én bestilling. Følgende innstillinger brukes:
- Tre dager med leveringstid
- Ingen kalendere (Alle dager er åpne.)
- Ingen marginer
Illustrasjonen nedenfor viser dette scenarioet. (Velg illustrasjonen for å åpne en større versjon.)
Eksempel 3: Marginscenario
Én salgsordre som har et forespurt avgangstid 22. januar, dekkes av én bestilling. Følgende innstillinger brukes:
- Tre dager med leveringstid
- Bestillingsmargin på fire dager
- Femdagers tilgjengelighetsmargin
- Ingen kalendere (Alle dager er åpne.)
Illustrasjonen nedenfor viser dette scenarioet. (Velg illustrasjonen for å åpne en større versjon.)
Eksempel 4: Forsinkelsesscenario
Én salgsordre som har et forespurt avgangstid 22. januar, dekkes av én bestilling. I dette eksemplet brukes de samme innstillingene som eksempel 3, men planleggingsdatoen er flyttet til 15. januar. Planlegging bakover (røde indikatorer) mislykkes, fordi planlagt bestillingstid må være før dagens dato. Hovedplanleggingen må derfor planlegges fremover og gi forsinkelser.
Illustrasjonen nedenfor viser dette scenarioet. (Velg illustrasjonen for å åpne en større versjon.)
Eksempel 5: Overføringsscenario
Én salgsordre fra lager 1 som har en forespurt avgangstid den 22. januar, dekkes av én overføringsordre fra lager 2, som er dekket av et bestillingsforslag. Følgende innstillinger brukes:
- Tre dager med overføringstid (lager 1)
- To dager med leveringstid for innkjøp (lager 2)
- Ingen kalendere (Alle dager er åpne.)
Illustrasjonen nedenfor viser dette scenarioet. (Velg illustrasjonen for å åpne en større versjon.)
Eksempel 6: Leveringstid med kalenderscenario
Én salgsordre som har et forespurt avgangstid 22. januar, dekkes av én bestilling. Følgende innstillinger brukes:
- Tre dager med leveringstid
- Avgangskalender (lukket på fredag)
- Tilgjengelighetskalender (lukket på torsdag og fredag)
- Mottakskalender (lukket på tirsdag, onsdag og søndag)
- Leveringstidskalender (lukket på torsdag og fredag)
- Bestillingskalender (åpen på mandag og lørdag)
Illustrasjonen nedenfor viser dette scenarioet. (Velg illustrasjonen for å åpne en større versjon.)
Eksempel 7: Forsinkelse med kalenderscenario
Én salgsordre som har et forespurt avgangstid 22. januar, dekkes av én bestilling. I dette eksemplet brukes de samme innstillingene som eksempel 6, men planleggingsdatoen er flyttet til 13. januar. Planlegging bakover (røde indikatorer) mislykkes, fordi planlagt bestillingstid må være før dagens dato. Hovedplanleggingen må derfor planlegges fremover og gi forsinkelser.
Illustrasjonen nedenfor viser dette scenarioet. (Velg illustrasjonen for å åpne en større versjon.)
