API

Denne siden beskriver hvordan identifikatorfelter i shipment request blir normalisert før validering og booking. Oppførselen her er basert på den nåværende pipelinen i api-repoet.

Rekkefølge

Shipment requests blir normalisert i denne rekkefølgen:

organizationId kan bytte tenant-kontekst til en underorganisasjon.
senderId og receiverId prøver å fylle sender og receiver.
organizationId kan fylle sender fra profilen til valgt organisasjon når sender og senderId mangler.
consignmentTemplateId eller auto-apply-template merges inn i requesten.
en tjenestespesifikk pickup-adresse kan fylle pickupAddress.
senderAddressId og receiverAddressId kan sent i pipelinen overskrive sender og receiver.
freightPayerId eller freightPayer.customerNumber kan fylle freightPayer og carrier contract-kontekst.

Senere resolvere vinner over tidligere.

Oversikt

Felt	Godtar	Resolver	Overwrite-oppførsel
`organizationId`	underorganisasjonens `ulid` eller `quick_id`	tenant-kontekst, noen ganger `sender`	fyller ikke `sender` hvis `senderId` eller `sender` allerede finnes
`senderId`	i praksis en sender-adresses `quick_id`	`sender`	hvis den finnes, erstatter den inline `sender`
`receiverId`	i praksis en receiver-adresses `quick_id`	`receiver`	hvis den finnes, erstatter den inline `receiver`
`consignmentTemplateId`	template `id` eller `quick_id`	template-payload	request vinner i normal mode, template vinner i override mode
`senderAddressId`	address book `id` eller `quick_id`	`sender`	kjører sent og overstyrer derfor også `senderId` og organization sender fill
`receiverAddressId`	address book `id` eller `quick_id`	`receiver`	kjører sent og overstyrer derfor også `receiverId`
`freightPayerId`	address book `id` eller `quick_id`	`freightPayer` og contract-kontekst	virker bare hvis adressen har contract for gitt `serviceId`
`organizationMemberId`	eksisterende `organization_members.id`	ingenting	valideres bare nå

Viktige kombinasjoner

bare organizationId: tenant byttes og sender fylles fra organisasjonsprofilen
organizationId + senderId: tenant byttes, deretter bestemmer senderId verdien av sender
senderId + sender: en vellykket lookup via senderId erstatter hele sender
ugyldig senderId + sender: senderId blir null og den eksplisitte sender blir stående
senderId + senderAddressId: endelig sender kommer fra senderAddressId

senderId og receiverId

senderId og receiverId kjører før consignment templates. Hvis lookupen lykkes, skrives hele party-payloaden om.

den nåværende fill-pipen resolver disse feltene via quick_id
uløste verdier normaliseres til null
en vellykket lookup vinner over tidligere inline-data

Merk

Valideringsregelen godtar numerisk adresse-id eller quick_id for senderId og receiverId, men den nåværende fill-pipen resolver dem via quick_id. I praksis bør disse feltene bruke quick_id.

senderAddressId og receiverAddressId

Disse feltene er separate fra senderId og receiverId.

lookup skjer i tenantens address book
lookup godtar numerisk adresse-id eller quick_id
en vellykket lookup erstatter hele sender eller receiver
receiverAddressId kan også fylle preNoticeEmail, preNoticeSMS og deliveryInstructions
senderAddressId kan også fylle pickupInstructions

Fordi de kjører senere i pipelinen, vinner de over tidligere party-resolve.

consignmentTemplateId

consignmentTemplateId godtar template id eller quick_id. Når en template blir resolved, normaliseres requesten til template-ens riktige id.

normal mode: request-verdier vinner og templaten fyller hull
override mode: template-verdier vinner
items og parcels merges per indeks med samme logikk
templaten kan fylle manglende serviceId

freightPayerId

freightPayerId fyller ikke sender eller receiver. Det resolver third-party betalingskontrakt-kontekst.

krever serviceId
slår opp i tenantens address book via id eller quick_id
fyller bare freightPayer hvis adressen har contract for tjenesten
bygger i praksis freightPayer fra receiver-data pluss resolved customer number

Anbefaling

bruk organisasjonens ulid eller quick_id i organizationId
bruk quick_id i senderId og receiverId
bruk senderAddressId og receiverAddressId når address book-posten eksplisitt skal vinne sent i pipelinen
bruk consignmentTemplateId for defaults eller kontrollert override
unngå å sende flere resolvere for samme part med mindre du bevisst vil bruke prioriteringsrekkefølgen over