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.
Note
Interessegrupper for 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.
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. |
Til dato (FuturesDate) og Forsinket til klokkeslett (FuturesTime) |
| Ønsket avgangstid | RequestedIssueTime |
Datoen for problemet som brukeren ber om og er angitt i administrasjon av forsyningskjede. 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 utgivelsesdatoen som justeres av planleggingsoptimalisering. Hvis dette tidspunktet faller i fortiden når planleggingsoptimalisering kjøres, flyttes det til den første ledige dagen som ikke er tidligere enn i dag. Hvis klokkeslettet er merket som blokkert i kalenderen, justeres det i stedet til den første åpne dagen før denne datoen. |
Behovsdato (ReqDate) og Behovstid (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 administrasjon av forsyningskjede (i tabellen ReqTrans eller ReqPO) |
|---|---|---|---|
| Planlagt tilgjengelighetstid | PlannedAvailabilityTime |
Datoen da mottaket er planlagt å være tilgjengelig. |
Behovsdato (ReqDate) og Behovstid (ReqTime) |
| Planlagt mottakstid | PlannedReceiptTime |
Datoen da kvitteringen ankommer lokasjonen. |
Til dato (FuturesDate), Forsinket til-klokkeslett (FuturesTime) og Leveringsdato (ReqDateDlv) eller Ønsket dato (ReqDateDlvOrig) hvis orden ikke er frigitt ennå. |
| Nødvendig tilgjengelighetstid | RequiredAvailabilityTime |
Den nødvendige tilgjengelighetsdatoen som justeres med planleggingsoptimalisering. |
Behovsdato (ReqDate) og Behovstid (ReqTime) |
| Forventet mottakstid | ExpectedReceiptTime |
Forventet mottaksdato for et frigitt mottak. Brukeren angir verdien i administrasjon av forsyningskjede. Verdien er ikke justert i planleggingsoptimalisering. Denne parameteren gjelder bare for frigitte mottak. |
Ønsket dato (ReqDateDlvOrig) |
| Nødvendig mottakstid | RequiredReceiptTime |
Den nødvendige mottaksdatoen som justeres av planleggingsoptimalisering. |
Behovsdato (ReqDate) og Behovstid (ReqTime) |
| Planlagt bestillingstid | PlannedOrderingTime |
Bestillingsdatoen som planleggingsoptimalisering beregner. |
Ordredato (ReqDateOrder) og Ordretid (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) (FuturesDays) og Forsinket til klokkeslett (FuturesTime) |
Eksempler på datoparameterbruk ved planleggingsoptimalisering
Planene i illustrasjonene nedenfor er på dagnivå, men planleggingsoptimalisering kjører 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. Dette eksemplet bruker de samme innstillingene som eksempel 3, men planleggingsdatoen flyttes 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. Dette eksemplet bruker de samme innstillingene som eksempel 6, men planleggingsdatoen flyttes 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.)
