Del via

Tips for Inventory Visibility

  • Artikkel

Notat

Azure Active Directory er nå Microsoft Entra ID. Få mer informasjon

Her er noen tips du bør vurdere når du definerer og bruker tillegget for lagersynlighet:

  • For øyeblikket støtter tillegget for lagersynlighet bare Microsoft Dataverse-miljøer som ble opprettet ved å bruke Microsoft Dynamics Lifecycle Services. Hvis Dataverse-miljøet ble opprettet på en annen måte (for eksempel ved å bruke Power Apps-administrasjonssenteret), og hvis det er koblet til Dynamics 365 Supply Chain Management-miljøet ditt, må du først be produktgruppen i lagersynlighet om å løse tilordningsproblemet. Du kan kontakte teamet på inventvisibilitysupp@microsoft.com. Gruppen gir deg beskjed når miljøet er klart til å installere Lagersynlighet.
  • Hvis du har mer enn ett Lifecycle Services-miljø, oppretter du et annet Microsoft Entra program for hvert miljø. Hvis du bruker samme program-ID og leie-ID til å installere tillegget for lagersynlighet for forskjellige miljøer, vil det oppstå et tokenproblem for eldre miljøer. Bare den siste forekomsten av tillegget for lagersynlighet som ble installert, er gyldig.
  • Lagersynlighet støttes for øyeblikket ikke for skybaserte miljøer. Den støttes bare for Nivå 2+-miljøer.
  • API (Application Programming Interface) tillater at flere verdier for SiteID og LocationID angis i hver spørring. Maksimumsgrensen defineres av følgende ligning: NumOf(SiteID) × NumOf(LocationID) ≤ 100.
  • Datakilden fno er reservert for Supply Chain Management. Hvis tillegget for lagersynlighet er integrert med et Supply Chain Management-miljø, anbefaler vi at du ikke sletter konfigurasjoner som er relatert til fno i datakilden.
  • Lagersynlighet kan ikke endre noen data for fno-datakilden. Dataflyten er enveisveis, som betyr at alle antallsendringer for datakilden fno må komme fra Supply Chain Management-miljøet. Derfor kan du ikke bruke API til å sende lagerendrings- og reserveringsforespørsler for fno-datakilden.
  • Hvis du legger til ett eller flere nye mål i Supply Chain Management-miljøet, bør du også legge dem til i Lagersynlighet. Men alle antallsendringer for nye mål må komme fra Supply Chain Management-miljøet.
  • En partisjonskonfigurasjon styrer hvordan data distribueres. Operasjoner som utføres innenfor samme partisjon, gir bedre ytelse, til lavere kostnad, enn operasjoner som krysser partisjoner. Som standard settes partisjonskonfigurasjon automatisk opp og skal ikke tilpasses.
  • Basisdimensjoner som er reservert i partisjonskonfigurasjonen (settnummer 0), skal ikke inkluderes i de andre beholdningsindekskonfigurasjonene.
  • Din beholdningsindekskonfigurasjon må inneholde minst én tilgjengelig beholdningsindeks i tillegg til partisjonskonfigurasjonen (settnummer 0). Hvis du ikke er interessert i å spørre etter spesifikke dimensjonskombinasjoner, kan du sette opp en indeks som bare har én basisdimensjon, Empty. Ellers mislykkes spørringene, og du får følgende feilmelding: "Ingen indekshierarki er angitt."
  • Datakilden @iv er en forhåndsdefinert datakilde, og de fysiske målene som er definert i @iv med prefiks @, er forhåndsdefinerte mål. Disse målene er en forhåndsdefinert konfigurasjon for fordelingsfunksjonen, så ikke endre eller slett dem, ellers vil du sannsynligvis oppleve uventede feil når du bruker fordelingsfunksjonen.
  • Du kan legge til nye fysiske mål i det forhåndsdefinerte beregnede målet @iv.@available_to_allocate, men du må ikke endre navnet.
  • Hvis du gjenoppretter en Supply Chain Management-database, kan den gjenopprettede databasen inneholde data som ikke lenger er konsekvent med data som tidligere er synkronisert med Lagersynlighet til Dataverse. Denne datainkonsekvensen kan forårsake systemfeil og andre problemer. Det er derfor viktig at du alltid renser alle relaterte lagersynlighetsdata fra Dataverse før du gjenoppretter en Supply Chain Management-database. Hvis du vil ha mer informasjon, kan du se Rens lagersynlighetsdata fra Dataverse før gjenoppretting av Supply Chain Management-databasen.