A feature that can silently stop your D365FO Sales orders integration

Microsoft Dynamics 365 for Finance and Operations (D365FO) is a powerful cloud product that regularly introduces new features to enhance user experience. The product team strives to maintain backward compatibility, but regression issues can still arise.

In this topic, I describe the recently announced Pricing Management module. This module is currently in Preview, and enabling it might have unexpected consequences for Sales order integrations.

Where is the catch: imagine you have some X++ code that creates Sales orders, without using the Pricing management functionality(it may be Integration or some custom function that creates and post Sales order based on another document)

A typical code for such a task looks like this:

• salesTable.insert() ..?//Init and create sales header
• salesLine.insert().. //init and create lines
• salesFormLetter.update()..?//create a document based on the sales order

The problem is that the Pricing management adds a new code extension that always runs on salesTable.insert() and sets the Sales order “Do not process” flag (SalesTable.MCROrderStopped)

The posting code in salesFormLetter ignores such orders with the “Do not process” flag, and the posting call will succeed without any error or warning. Then you, as a developer, will have a hard time figuring out why the Sales order stayed in the Open status after the successful posting.

As of now(Update 10.0.35), there is no solution for this issue, as the Pricing module is in Preview, and Microsoft promised to fix it in 10.0.37. A temporary workaround probably will be an X++ code to remove the flag SalesTable.MCROrderStopped after the SalesTable.insert() call. This is a frustrating situation, as creating and posting a sales order is a basic operation for X++ developers.

Hopefully, this article will give you a heads-up about the issue and save you some debugging time.