Supply chain | Supply Chain Management, Commerce

Best practice to create fully processed Sales Return (RMA) via OData/Data Entities in D365 SCM

(0) Share

Report

Posted on by Gurveen Kaur Bagga

We are integrating an OMS with Dynamics 365 SCM and need to create completed sales returns (RMA) in D365.

In OMS, the return is already completed and refunded. We need to send the below to D365:

Return header
Return items
Payment (PAYMENT_REFUNDED)

We explored OOTB entities and found:

ReturnOrderHeaderV2
ReturnOrderLineV2

These work for creating return orders and lines, but we did not find any OOTB composite entity to handle the full return lifecycle (receive, packing slip, invoice, refund).

Questions:

What is the recommended approach to create a fully processed return (received + invoiced) via integration?
Is it expected to orchestrate this using multiple entities and service operations?

Any guidance or best practices would be helpful.

Categories:

Dynamics 365 Supply Chain Management

I have the same question (0)

All responses (7)

Answers (0)

Sort by

Suggested answer

Navneeth Nagrajan 2,618 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hi Gurveen,

Agree, the OOTB entities ReturnOrderHeaderV2 and ReturnOrderLineV2 can only achieve your requirement partially as it can only handle return orders. Also, there are no composite entities in standard D365 FO to achieve the entire process of receipt and invoiced via integration.

A few questions:

1. Are there multiple LEs involved in this integration process?

2. Are you looking to process headers and lines together through one import?

3. Are you considering mapping Payment (Payment_Refunded) as a field in the data entity?

4. Are you considering posting these sales orders post import in D365 FO?

Suggestions:

You can extend the entity(If there are no existing processes running on this data entity) or create a new custom entity(if you are considering Multiple legal entities) with filters SalesType = Return (Available in Standard). You can add a filter on the data entity (extension or the custom one(if you are considering Multiple legal entities)) on the ReturnStatus field and consider Received, Invoiced as values (as an extension to the standard data entity). Would consider the line level entity in this case for the integration process. Header record can be created automatically through the line (if there are no custom fields to be considered at the header level).

Custom Fields at Header Level:

In case if you have any fields at the header level to be considered, you will have can leave the standard filter where SalesType = Return.

Composite Data Entities:

If you are considering usage of composite entities then you need to duplicate the SalesOrderV4Entity and add the above data entities (Both Header and Lines) under one composite entity and achieve the process as a whole.

After import (if you are considering posting the return sales orders in D365 FO):

If you are considering posting the sales order returns in D365 then you can use the SalesFormLetter_Invoice class in your batch and consider adding the following parameters highlighted in the screen clip below

We have setup this for a client using Order Type as Returned Order and set the Status for Received + Invoiced. Sharing the batch parameters that we setup for processing Return sales orders with status Delivered and Invoiced.

Hope this helps.

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

Like (0)

Report
Copy link

Link copied!
Hi @Navneeth Nagrajan,

Thanks for the detailed response, this is very helpful.

To clarify our scenario:

We are currently working with a single legal entity.

Our aim is to use the standard approach as much as possible.

For creation, we are fine using standard entities separately (for example, creating the return order header first and then the return lines through OData / standard entities).

Our main objective is to create completed returns in D365 such that:

inventory is updated for returned items, and

required financial postings are created correctly.

From our manual testing, our understanding is:

Once the RMA / returned order is created, the line starts in Expected status.

To increase inventory, we also need to complete the receiving step.

Only after that can we post the packing slip, and then the invoice / credit note.

Packing slip posting and invoice posting seem manageable through OOTB batch jobs with appropriate parameters as you also mentioned.

Few other questions we have are:

For a return that should increase inventory, should we also automate the receiving / registration step as part of the integration before the packing slip and invoice batch jobs can process it?

When a returned order is invoiced, it creates a credit note with a negative balance. As I understand it, that does not complete the cycle by itself and it still needs to be settled.

For closing that cycle, we are thinking of syncing the refund payment details from OMS into D365 by creating a customer payment journal with the refund amount in Debit amount, and then settling that against the credit note transaction.

Would that be the correct standard approach to fully close the return lifecycle in D365, both from:

inventory perspective, and

financial / customer balance perspective?

Appreciate your guidance.

Was this reply helpful? Yes No
Suggested answer

Navneeth Nagrajan 2,618 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hi Gurveen,

Suggestions:

Regarding the main objective to complete returns in D365, you will need to process the return order explicitly through a batch to update the inventory for returned items, post import of the returned orders from OMS. The required financial postings will be created automatically through the standard process (assuming you are not considering any custom fields from OMS in D365 for tracking purposes).

1. The registration/receiving process can be automated through a batch job in D365 FO (considering the batch parameters required). It will update the inventory of the returned item as expected. On skipping this step, packing slip and invoice cannot be processed because the physical inventory is not available. The batch job that i mentioend in my previous post with the screen clip should run after this process is complete and when the physical inventory of the product is available.

2. You are right. Invoicing a return order creates a credit note with a negative balance but does not complete the cycle because the settlement needs to be processed against the payment being made.

3. You can have a customer payment journal created as a part of the integration process with a debit amount and an offset bank or cash account and then you can settle the payment against the credit note. This needs to go after the registration/receiving process is completed in D365 FO. Based on this, the settlement process can run through the customer payment journal.

Hope this helps. Happy to answer questions, if any.

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

Like (1)

Report
Copy link

Link copied!
Hi @Navneeth Nagrajan,

Thanks, this is very helpful. This confirms our understanding of the end-to-end return cycle, including credit note creation, refund payment journal, and settlement.

We did some additional validation on the registration/receiving step.

We are able to create the arrival journal using standard OData entities:

ItemArrivalJournalHeadersV2

ItemArrivalJournalLinesV2

So the journal creation part is working through standard entities.

We also explored options for automating the posting:

We were able to successfully configure batch posting for Customer Payment Journals using the standard Post journals batch job (LedgerJournalMultiPost).

However, we could not find a similar OOTB batch job for posting Item Arrival Journals.

At this point, our understanding is that arrival journal posting might need to be handled differently (possibly via a posting class or custom service).

Could you please confirm:

What is the recommended standard approach to auto-post Item Arrival Journals created via integration?

Once this is clear, our full flow could be:

RMA → Arrival journal (entity) → Arrival journal posting → Packing slip → Invoice (credit note) → Payment journal → Settlement

Appreciate your guidance.

Was this reply helpful? Yes No
Suggested answer

Navneeth Nagrajan 2,618 Super User 2026 Season 1 on at

Like (1)

Report
Copy link

Link copied!

Hi Gurveen,

A few questions:

1. How many transactions are you expecting at the registration/receiving step? By how many transactions are these expected to grow in the future?

2. Have you considered using Azure Logic Apps and map the data entity in D365 FO/Custom Batch service job for creation of ItemArrival journals?

Suggestions:

For the registration/receiving step, wouldn't recommend using OData, if the transaction count is more than 1500 lines on a single run, then would recommend using custom service to import the Journal Lines. Journal Headers can be created through the custom service, if the line records are handled through the lines.

For customer payment journals, yes LedgerJournalMultiPost should work.

To answer your question on standard approach to auto-Post Item Arrival Journals, you can use the Validate and Post class called WMSJournalCheckPostReception that extends WMSJournalCheckPost. WMSJournalCheckPostReception is the batchable class that is triggered on validating and Posting the Item Arrival journals in D365 FO.

You can set the above mentioned batch job recurrence with the required parameters to post the item arrival journals.

So your full flow should be:

RMA → Arrival journal (through Azure Logic Apps data entity or by invoking the custom service class) → Arrival journal posting → Packing slip → Invoice (credit note) → Payment journal → Settlement

Hope this helps. Happy to answer questions, if any.

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

Like (0)

Report
Copy link

Link copied!
Hi Navneeth,

Thanks again, for your suggestions and guidance.

Regarding transaction volume, we are not currently expecting very high volumes (certainly not in the range of 1500+ lines per run). For now, we are exploring the use of standard OData entities for arrival journal creation, and will evaluate alternative approaches such as custom services if volume increases in future.

We also validated the posting behavior in our environment:

We confirmed that Item Arrival Journal posting through the standard Post action creates a batch task using WmsJournalCheckPostReception.

We also observed that this standard batch submission works per journal (i.e., it posts only the selected journal and does not automatically pick multiple unposted arrival journals like LedgerJournalMultiPost does for customer payment journals).

Based on this, our current understanding is:

Arrival journals can be created through standard entities.

Posting would need to be triggered for each journal (for example, via a service or equivalent mechanism), rather than relying on a query-based batch job to pick multiple journals.

Does this align with the recommended approach for integration scenarios, or is there any standard pattern to handle bulk auto-posting of arrival journals that we should consider?

Appreciate your guidance.

Was this reply helpful? Yes No
Suggested answer

Navneeth Nagrajan 2,618 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Hi Gurveen,

Suggestions:
For the entities if you are using the OData approach then you need to manage two Data entities headers and lines explicitly with Change tracking enabled. Would recommend exploring the custom service option in parallel because the transaction volume will definitely grow in the future beyond 1500+ lines per journal.

LedgerJournalMultiPost is applicable for customer payment journals and it has the ability to pick multiple journals because this is a multi-threaded batch and not a sequential batch like WMSJournalCheckPostReception. For picking up multiple journals, you need to extend the class WMSJournalCheckPostReception as a multi-threaded batch like LedgerJournalMultiPost and this should resolve the issue.

Hope this helps. Happy to answer questions, if any.

Was this reply helpful? Yes No