Ordering Scope (konto, program, tidscyklus)

Dette dokument beskriver den aktuelle runtime-resolvering af bestillingskontekst for klientkonti i Shop. Fokus er nuværende adfærd i kode, ikke ønsket fremtidig adfærd.

Grundbegreber

Program-opslag

Effektiv prisgruppe

Resolveres i ShopClientAccountInfo.ComputeEffectivePriceGroupId i to trin:

  1. Traverser konto -> forfædre og find første ShopClientAccount.ClientPriceGroupId.
  2. Hvis ingen findes, traverser igen konto -> forfædre og find første ShopProgram.DefaultPriceGroupId.
  3. Hvis stadig ingen, er effektiv prisgruppe null.

Konsekvens: konto-specifik prisgruppe vinder altid over program-standard.

Program-styrede begrænsninger (betaling, levering, kategorier)

ShopProgramAvailabilityUtils bruger kontoens aktuelle program (ingen forfader-traversering her):

Hvis program ikke findes, returneres ingen program-afgrænsning.

Levering/fakturering via overkonto og selvbestilling

ShopClientAccountInfo beregner bl.a.:

Tidscyklus-scope til Repeat Ordering onboarding

RepeatOrderingOnboardingRestEndpointContributor.ResolveScope bruger program + forfaderfallback:

  1. Traverser valgt konto -> forfædre.
  2. For hver konto med CurrentProgramId: læs ShopProgram.
  3. Første program med DefaultOrderingTimeCycleId vælges.
  4. Tidscyklussen er kun anvendelig hvis ShopTimeCycle har:
    • IsProductNeedsEnabled == true eller
    • IsSubscriptionOrderingEnabled == true.
  5. Hvis anvendelig: scope = time_cycle.
  6. Ellers: scope = global_program (hvis program blev fundet) eller none.

Konsekvens: onboarding-timecycle kan komme fra forfaderkontoens program, ikke kun den valgte konto.

Udbyder-afdeling (ProviderDepartment) resolution

Udbyder-kontekst for en klientkonto starter med provider_account_id-relationen:

  1. Platformen finder konto med provider-registrering (AccountWithProviderRegistration), som kan være:
    • den valgte konto, eller
    • en forfaderkonto (hvis den valgte konto ikke selv har provider-tilknytning).
  2. Hvis den fundne konto har ProviderAccountId, opløses ForcedProviderDepartmentId fra provider-kontoens DepartmentId.
  3. Hvis ingen konto i kæden har provider-tilknytning, er ForcedProviderDepartmentId = null.

Konsekvens:

Når ForcedProviderDepartmentId er null, er der ikke en kontobaseret tvungen provider-afdeling. Det betyder ikke nødvendigvis fri adgang i praksis: