Supply chain | Supply Chain Management, Commerce

Error "Number sequence is not set" while importing custom composite Return Order entity in D365 SCM

(0) Share

Report

Posted on by Gurveen Kaur Bagga

Hi all,

We are working on integrating an OMS with Dynamics 365 SCM and are trying to create Return Orders using a custom composite data entity.

Setup:

We have created:

Custom header entity: OmsReturnOrderHeaderV1Entity
Custom line entity: OmsReturnOrderLineV1Entity
Custom composite entity: OmsReturnOrderCompositeV1Entity

These are based on:

ReturnOrderHeaderV2Entity
ReturnOrderLineV2Entity

We duplicated the standard entities and adjusted staging tables, relations, and composite structure. We have added RowId and ParentRowId in new entities, since the standard entities do not seem to be built for composite usage due to these missing fields.

Current Status:

Export using the composite entity works fine ✅

Issue:

During import execution, we get the following error in Execution log:

“Number sequence is not set”

The issue exists for XML when ReturnOrderNumber is passed and also without ReturnOrderNumber (set auto-generate in Mapping).

Question:

Has anyone faced a similar issue when duplicating standard entities and creating new composite entity to use in DMF?

Specifically:

Is there any additional logic required to trigger number sequence assignment in custom data entities?
Are there known limitations or best practices when duplicating entities like ReturnOrderHeaderV2Entity for composite usage?
Could this be due to missing standard framework calls during DMF processing?

Any guidance would be greatly appreciated.

Thanks in advance!

OmsReturnOrderCom...

Categories:

Dynamics 365 Supply Chain Management

I have the same question (0)

All responses (6)

Answers (0)

Sort by

André Arnaud de Cal... 304,293 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hi Gurveen,

I haven't integrated return orders myself. Have you checked if the number sequence for RMA numbers are configured correctly? Can you manually create a return order in the application without the same error?

Was this reply helpful? Yes No
Suggested answer

Mallesh Deshapaga 1,819 on at

Like (1)

Report
Copy link

Link copied!

Did you link the original order lot ID to the return order? Most issues occur due to incorrect linking of the original order ID with the return order during import.

Go to the SalesLine table and filter the SalesType as “Return order.” From there, you can find the Sales ID (the Return Order Number). The ItemID field gives the item to filter, and the InventTransIdReturn field holds the Lot ID. In the Return order lines V2 entity, InventTransIdReturn maps to RETURNINGINVENTORYLOTID.

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

Like (0)

Report
Copy link

Link copied!
Hi all,

Thanks for the responses so far — adding some more observations from our testing which might help clarify the issue.

We verified return order creation from the UI in two ways:

1. Using “Find sales order” option

Return order gets created successfully

RMA number and Return order number are generated correctly as per number sequence (e.g., 00106, 001231)

Return lot ID and other linkage fields are also populated automatically

2. Creating return order manually (without “Find sales order”)

Header creation still works

Number sequences are generated correctly

However, line-level validations (like return lot ID / cost linkage) become stricter and require proper input

What we are observing in our custom composite entity import:

Header staging validates successfully (no errors)

But no record is created in target (0 created, 0 updated)

When mapping is set to auto-generate:

RMA number gets generated as 1

which does not follow the configured number sequence

When mapping is not auto-generated:

we get “Number sequence is not set”

This behavior is different from UI/API creation where number sequences are correctly triggered.

Our current understanding / hypothesis:

The issue seems less about configuration and more about how the custom entities are behaving at runtime

Since we duplicated:

ReturnOrderHeaderV2Entity

ReturnOrderLineV2Entity

and created a composite entity on top

It appears that some standard framework logic (especially number sequence handling) is not getting triggered correctly in the custom entity context

Additional observation:

Return Orders seem more complex compared to Sales Orders because they involve two identifiers:

ReturnOrderNumber (SalesId)

RMANumber

In Sales Order composite scenarios, using auto-generated mapping worked fine, but for Returns this seems to break validation or bypass standard number sequence generation.

Current thinking:

We suspect that:

duplicating standard entities and using them in a composite may not fully replicate standard behavior (especially number sequence + return-specific logic)

this might be a limitation or design gap in using composite entities for Returns

We are now evaluating alternative approaches such as:

using standard entities via OData (separately for header and lines), or

implementing a custom service to create return orders using standard business logic

Would appreciate if anyone has:

successfully implemented Return Order creation via DMF composite entities

or faced similar issues with duplicated entities and number sequence behavior

Thanks in advance!

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

Like (0)

Report
Copy link

Link copied!

Hi Gurveen,

Thanks for the very detailed additional information. This is helpful in understanding. Can you confirm if using the entity ReturnOrderHeaderV2Entity separately, the number sequences are used correctly?

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

Like (0)

Report
Copy link

Link copied!
Hi André,

Thanks for the suggestion — we tried this and wanted to share the observations.

We created a separate Data Import Project using only the standard entity ReturnOrderHeaderV2Entity (without using our custom composite or duplicated entities). We did not set any auto-generation in mapping for ReturnOrderNumber or RMANumber.

In this case:

The import was successful

Return order was created, just the header part.

Both ReturnOrderNumber (SalesId) and RMANumber were generated correctly as per the configured number sequences

We then extended the test by using the same file data including lines (using our custom composite setup), and observed:

Header staging validates successfully

However, line validation fails with:
“Field ‘Return order’ must be filled in”

In staging, the line record shows Return order = blank, indicating that the generated header value is not being passed to the line during processing

I have attached the XML files used for reference.

At this point, it appears that:

The standard entity works correctly when used independently

But when used via duplicated entities in a composite setup, the runtime behavior differs (especially around number sequence handling and header-line linkage)

We are still investigating whether this is expected behavior for custom composite entities in this scenario, or if additional setup is required to ensure proper propagation of generated header values to lines.

Any further guidance would be very helpful.

Thanks!

ReturnOrderHeader...
OmsReturnOrderCom...

Was this reply helpful? Yes No
Martin Dráb 239,240 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

I think you should set the mapping of Return order field on the list as auto-default. Give it a try. For more details, you may want to check a similar discussion in Best practice for creating Sales Orders from an external system in D365 FO.

Just for your information, the logic defining number sequences for fields of ReturnOrderHeaderV2Entity can be found in its initValue() method.

Was this reply helpful? Yes No

Join the conversation

Community site session details