Finance | Project Operations, Human Resources, ...

Dual Write for Custom Entity Purchase Order Header - Not triggering when a PO is Received

(5) Share

Report

Posted on by Mario C

Hello community,

I’m working with dual write on a custom entity using the "Purchase Order Headers V2" entity to sync the status of purchase orders between D365 and Dataverse. The overall mapping and initial synchronization are working well; however, I’ve hit an issue with one specific field: PurchaseOrderStatus. This field, which is an enum that can be Backorder, Invoiced, Received, or Canceled, is not triggering dual write correctly.

Here’s the scenario: Changes made in Dataverse are reflecting correctly in D365, for most statuses (Backorder, Invoiced, Canceled), updates from D365 also sync properly to Dataverse, but the problem is with the "Received" status, when I change the status to Received in D365, the update doesn't trigger dual write to reflect the change in Dataverse.

I’ve checked that the mapping is correct and verified that the initial sync and other statuses are working as expected.

Any help or insights would be greatly appreciated!

Thanks!
Mario

Categories:

Dynamics 365 Finance

I have the same question (0)

All responses (2)

Answers (0)

Sort by

Suggested answer

Holly Huffman 6,554 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!
Good morning, afternoon, or evening depending on your location!

Based on your description, it appears that the "Received" status is not triggering synchronization from D365 to Dataverse, even though other statuses are working correctly.
Possible Causes & Steps to Resolve

Check Dual Write Mapping & Triggers

Verify that the PurchaseOrderStatus field is correctly mapped in the Dual Write setup.

Ensure that the mapping includes real-time synchronization for status updates.

Review Business Events & Change Tracking

Some status updates rely on business events rather than direct field updates.

Check if the "Received" status requires a specific trigger (e.g., a product receipt journal) to initiate synchronization.

Validate Entity Refresh & Dependencies

Confirm that the Purchase Order Headers V2 entity is refreshing correctly when the status changes.

Some updates may require dependencies on related entities (e.g., Purchase Order Lines).

Plugin or Workflow Interference

If a custom plugin or workflow is involved, ensure it does not override or block the status update.

Review logs for any errors related to the Received status update.

Test with Manual Data Entry

Try manually updating the Received status in D365 and check if it syncs.

If manual updates work but automated ones do not, the issue may be related to batch processing or event triggers.

Hope this helps some!

Was this reply helpful? Yes No
vince.perta 9 on at

Like (0)

Report
Copy link

Link copied!
I believe I'm facing this same issue. Did you ever find what the root cause is, or determine a workaround?

I'm suspecting it is somehow tied to the way that the PurchTable.PurchStatus field is often updated using the .doUpdate() method instead of .update() - See PurchTableType.updateBackStatus() method.

It appears to happen with invoicing too. I suspect that the updates to that field alone may not be enough to trigger DW, but that often other changes (such as the approval status) happen around the same time, which do trigger DW, and it's those updates that push the PO header, along with the new status, from F&O to Dataverse.

Update: For anyone else who is looking for a (albeit hacky) workaround to this... I created an extension of the PurchTableType class that works around this problem by first performing .update() with SkipVersioning off, so that it doesn't throw a "Changes to the document are only allowed in state Draft" error on PO's that are utilizing workflow. I suspect that error is the reason the base code is using .doUpdate(). It then switches SkipVersioning back on before performing the CoC .updateBackStatus(). The code is controlled by a NoYes parameter flag I created on a custom table, so it can be turned off if it doesn't work as expected, or if Microsoft eventually fixes the bug. This has been working well for me for the past few weeks, so I figured I'd share, but I make no guarantee that it can't result in issues, especially if you have other customizations.
[ExtensionOf(classStr(PurchTableType))] final class PurchTableType_CUSTOM_Extension { void updateBackStatus() { ttsbegin; if (CUSTOMParameters::find().POStatusVersionFix) { unchecked(Uncheck::XDS) { purchTable.PurchStatus = PurchLine::lowestPurchStatus(purchTable.PurchId); purchTable.SkipVersioning = NoYes::Yes; // Override versioning to allow this update to trigger DW. purchTable.update(); purchTable.SkipVersioning = NoYes::No; // Re-enabled versioning } } next updateBackStatus(); ttscommit; } }

Was this reply helpful? Yes No