API

See leht kirjeldab, kuidas shipment request identifikaatoriväljad normaliseeritakse enne valideerimist ja broneerimist. Käitumine põhineb api repo praegusel pipeline'il.

Töötlemise järjekord

Shipment request normaliseeritakse selles järjekorras:

organizationId võib vahetada tenant-konteksti alamorganisatsioonile.
senderId ja receiverId proovivad täita sender ja receiver.
organizationId võib täita sender valitud organisatsiooni profiilist, kui sender ja senderId puuduvad.
consignmentTemplateId või auto-apply-template merge'itakse requesti.
teenusepõhine pickup-aadress võib täita pickupAddress.
senderAddressId ja receiverAddressId võivad pipeline'i lõpus kirjutada üle sender ja receiver.
freightPayerId või freightPayer.customerNumber võib täita freightPayer ja carrier contract-konteksti.

Hiljem jooksnud resolver võidab varasema.

Kokkuvõte

Väli	Lubab	Resolve'ib	Overwrite-käitumine
`organizationId`	alamorganisatsiooni `ulid` või `quick_id`	tenant-kontekst, vahel `sender`	ei täida `sender`-it, kui `senderId` või `sender` on juba olemas
`senderId`	praktikas sender-aadressi `quick_id`	`sender`	kui leitakse, asendab inline `sender` payloadi
`receiverId`	praktikas receiver-aadressi `quick_id`	`receiver`	kui leitakse, asendab inline `receiver` payloadi
`consignmentTemplateId`	template `id` või `quick_id`	template payload	tavalises režiimis võidab request, override-režiimis template
`senderAddressId`	address book `id` või `quick_id`	`sender`	jookseb hilja, seega võidab ka `senderId` ja organization sender fill
`receiverAddressId`	address book `id` või `quick_id`	`receiver`	jookseb hilja, seega võidab ka `receiverId`
`freightPayerId`	address book `id` või `quick_id`	`freightPayer` ja contract-kontekst	töötab ainult siis, kui aadressil on contract selle `serviceId` jaoks
`organizationMemberId`	olemasolev `organization_members.id`	mitte midagi	hetkel ainult valideeritakse

Olulised kombinatsioonid

ainult organizationId: tenant vahetub ja sender täidetakse organisatsiooni profiilist
organizationId + senderId: tenant vahetub, seejärel otsustab senderId sender-i
senderId + sender: edukas senderId lookup asendab kogu sender
vigane senderId + sender: senderId muutub null-iks ja eksplitsiitne sender jääb alles
senderId + senderAddressId: lõplik sender tuleb senderAddressId-st

senderId ja receiverId

senderId ja receiverId jooksevad enne consignment template'e. Kui lookup õnnestub, kirjutatakse kogu party-payload üle.

praegune fill-pipe resolve'ib need väljad quick_id alusel
leidmata väärtused normaliseeritakse null-iks
edukas lookup võidab varasema inline andmestiku

Märkus

Valideerimisreegel lubab senderId ja receiverId jaoks nii numbrilist aadressi id kui ka quick_id, kuid praegune fill-pipe resolve'ib need quick_id kaudu. Praktikas tuleks neis väljades kasutada quick_id.

senderAddressId ja receiverAddressId

Need väljad on eraldi senderId ja receiverId väljadest.

lookup tehakse tenant'i address book'ist
lookup lubab aadressi numbrilist id või quick_id
edukas lookup asendab kogu sender või receiver
receiverAddressId võib täita ka preNoticeEmail, preNoticeSMS ja deliveryInstructions
senderAddressId võib täita ka pickupInstructions

Kuna need jooksevad hiljem, võidavad need varasema party-resolve'i.

consignmentTemplateId

consignmentTemplateId lubab template id või quick_id. Kui template resolve'itakse, normaliseeritakse request template'i päris id peale.

tavaline režiim: requesti väärtused võidavad ja template täidab lüngad
override-režiim: template väärtused võidavad
items ja parcels merge'itakse indeksi kaupa sama loogikaga
template võib täita puuduva serviceId

freightPayerId

freightPayerId ei täida sender'it ega receiver'it. See resolve'ib third-party arvelduslepingu konteksti.

vajab serviceId
teeb lookup'i tenant'i address book'ist id või quick_id alusel
täidab freightPayer ainult siis, kui aadressil on teenusele contract
ehitab freightPayeri põhiliselt receiver'i andmete ja leitud customer number'i peale

Soovitus

kasuta organisatsiooni ulid-it või quick_id-d väljal organizationId
kasuta quick_id-d väljadel senderId ja receiverId
kasuta senderAddressId ja receiverAddressId, kui address book kirje peab pipeline'i lõpus kindlasti võitma
kasuta consignmentTemplateId-d defaultide või kontrollitud override'i jaoks
ära saada sama party jaoks mitut resolverit, kui sa ei taha teadlikult kasutada siin kirjeldatud prioriteedijärjestust