The dispatch encounter should be created in Avni under corresponding demand with - voiding status, last modified date time, and external id. For the remaining fields use the mapping metadata approach.
Reuse the two scheduled jobs for demand to run dispatch sync also
Dispatch response now has "TypeOfMaterial" :"Contributed, Kit, Purchase" specified to ease Avni Dispatch entity creation, use it to complete Dispatch sync from SF to Avni
Store DispatchStatusId as External ID instead of DispatchStatusName
DispatchLineItems id field “DispatchLineItemId” and following non-mandatory fields
“DispatchLineItemId”: “adli1234”,
"PurchaseItemCategory": null,
"OtherKitDetails": null,
"KitName": null,
"MaterialName": null,
"ItemName": null,
"ItemCategory": null,
"ContributedItem": null,
Remove incompatible fields :
"Contributed (voided~207321)": 12,
"Purchase/High Value": 12,
"Non-Kit (voided~207320)": 12
Implement support for handling “DeletedObjects": { "DeletedDispatchStatusLineItems": [], "DeletedDispatchStatuses": []}
Save error record for missing mapping for a field, its coded answers, or missing demand in Avni.
The sync should resume from the previous point if an uncaught exception occurs.
Make it ready for QA
Deploy to Staging
Acceptance criteria
All the dispatches should be visible in the data entry app, under their demand, in Avni for any user who has the privilege. Note that only the fields mapped will be visible. All the field and their coded answers mapping will be handled via a separate implementation story.
Acceptance criteria
All the dispatches should be visible in the data entry app, under their demand, in Avni for any user who has the privilege. Note that only the fields mapped will be visible. All the field and their coded answers mapping will be handled via a separate implementation story.