Supply chain | Supply Chain Management, Commerce

Best standard approach to export Sales Orders Packing Slip data

(1) Share

Report

Posted on by Gurveen Kaur Bagga

Hi everyone,

We are implementing an integration between an external OMS and D365 SCM, where sales orders are imported in D365 from OMS and fulfillment is completed in D365. We need to export fulfillment confirmation back to the OMS.

From our analysis and testing, packing slip seems to be the correct business entity to sync since:

multiple packing slips can be created for partial shipments
packing slip posting represents the actual fulfillment confirmation
tracking information can be associated with the packing slip

We have identified these entities:

CustPackingSlipJourBiEntities for packing slip header
CustPackingSlipTransBiEntities for packing slip lines
PackingSlipTrackingInformation for tracking details

In Data Management target entities, we could only find line-oriented entities such as:

Customer packing slip lines - stocked
Customer packing slip lines - non stocked
Customer packing slip lines - invoiced
but we could not find a clear standard packing slip export entity there.

Our questions are:

Is using CustPackingSlipJourBiEntities + CustPackingSlipTransBiEntities + packing slip tracking information the recommended standard approach for exporting packing slip data to an external OMS?
Is there any standard composite or export-friendly entity that includes packing slip header, lines, and tracking together?

Any guidance or best practices would be very helpful.

Thanks!

Categories:

Dynamics 365 Supply Chain Management

I have the same question (0)

All responses (6)

Answers (0)

Sort by

Suggested answer

Mallesh Deshapaga 1,811 on at

Like (2)

Report
Copy link

Link copied!

Yes, In D365F&O there is currently no active entity available for packing slip, as it is marked with an obsolete status.

I have tried checking the following entities, but the data is not being exported. Since mostly posted data is not required, that might be the reason.

In D365F&O, you can view the full list of packing slips, and from there you can export them to a spreadsheet. This can be used as a workaround if it fits your requirements.

Export to excel

Was this reply helpful? Yes No
Gurveen Kaur Bagga 65 on at

Like (0)

Report
Copy link

Link copied!

Hi everyone, checking back in on this.

While 'Export to Excel' is a helpful manual workaround, we specifically need an automated, scalable approach for a real-time integration with our external OMS.

Since the standard entities for packing slips appear to be line-oriented, has anyone successfully:

- Built a Custom Data Entity (Header + Lines + Tracking) specifically for this?

- Utilized Business Events triggered by the packing slip posting to push data out via a Logic App or Power Automate?

We want to ensure we are following a stable, 'best practice' path for fulfillment sync rather than building a high-maintenance custom solution. Any advice from those who have handled D365-to-OMS shipment exports would be greatly appreciated!

Thanks in advance.

Was this reply helpful? Yes No
Suggested answer

André Arnaud de Cal... 305,178 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!
Hi Gurveen,

You can use the data entities as you mentioned in your question. There are two more for integration purposes used by Dual Write:

CustPackingSlipJourCDREntities

CustPackingSlipTransCDREntities

The data entities can most likely be used as a data event that can be enabled via the Business Events Catalog or via enabling a Virtual table.

Then you get a small payload that can be picked up by a Logic App or Power Automate flow to retrieve all related information from these entities and move it to your OMS.

Was this reply helpful? Yes No
Gurveen Kaur Bagga 65 on at

Like (0)

Report
Copy link

Link copied!

Hi @André Arnaud de Calavon

Thank you for your guidance. I have been attempting to implement the suggested approach using Business/Data Events and Logic Apps.

We are working on a Cloud-hosted (Tier 1 / Developer) environment deployed via LCS. In the "Power Platform Integration" section, it does not provide a Setup button, which is expected for this environment type.

Consequently, the Activate button in the Data event catalog tab is disabled for all entities, including CustPackingSlipJourCDREntities.

We only see the Warehouse-specific event (WHSShipmentPackingSlipJournalModifiedBusinessEvent) in the Business Event Catalog, which does not trigger for manual packing slip postings.

Is it mandatory to move to a Tier 2 (Sandbox) environment to properly develop an integration that relies on Data Events?

We want to ensure that whatever we build in Dev will be a "process-agnostic" solution that triggers regardless of whether the packing slip is posted via WMS or manually.

Thanks again for your help.

Was this reply helpful? Yes No
André Arnaud de Cal... 305,178 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hi Gurveen,

Yes, the data events do rely on the Power Platform integration being enabled. For that you need to have a Tier 2+ or a new unified environment deployed via PPAC.

A workaround for data events would be creating an alert rule with the option enabled to send it externally. This can be triggered via a business event. This can be used in all environment types. You can also only use this approach in a DEV instance and use the data events when you start testing on a UAT connected with the Power Platform.

Was this reply helpful? Yes No
Gurveen Kaur Bagga 65 on at

Like (1)

Report
Copy link

Link copied!
An update from my side after further testing on this requirement.

We were able to successfully implement the Business Event/Data Event based approach and consume the events externally.

Tested approaches:

D365 Business Event → Logic App

D365 Business Event → Azure Service Bus Queue → Azure Function

Both approaches worked successfully for the POC.

One additional requirement we have is that we only want to sync shipment lines fulfilled through D365/WMS flows, and not the lines already fulfilled directly by OMS.

Because of this filtering requirement, we are also exploring another approach using a custom flattened export entity which combines:

packing slip header

lines

tracking information

into a single export-friendly entity.

This may simplify the integration compared to consuming multiple entities separately and joining header/lines/tracking externally after export. It may also help apply filtering directly at the export/entity level.

OData is also possible, but would require multiple API calls to retrieve the complete shipment information.

Still evaluating which approach would be the cleanest and most maintainable long-term solution, sharing the findings here in case it helps others exploring similar OMS fulfillment integrations.

Any other feedback is welcome.

Thanks again everyone for the suggestions and guidance shared on this thread. It really helped us move forward with the POC and evaluate different approaches.

Was this reply helpful? Yes No