Friday, August 22, 2025

Step-by-Step Guide to Move Your Custom Changes from Tier 2 to PROD in D365 Finance & Operations

Hey everyone,

👉 Not every Technical consultant gets the chance to schedule a PROD deployment, but it’s something they can learn. The process is easy and only takes a few steps to move the custom changes to PROD.

✅ Prerequisites

  1. You need LCS access for your project.

  2. The deployable package must already be deployed successfully to Tier 2 (preferably Pre-PROD or UAT).

  3. You need a PROD deployment approval from the relevant team, including a downtime slot.


🚀 Steps to Schedule a PROD Deployment

Let’s assume the customization was built in the Dev environment, the code was merged into the release branch, and the deployable package was uploaded to the Asset Library and already deployed on Tier 2.

1) Go to Tier 2 environment history in LCS by clicking environment changes.


2) Select the custom package you want to move to PROD. Click Sign off and mark it as a Release            Candidate.










3) Now open the PROD environment in LCS. Click Full Details → Maintain → Update Environment.


4) Select the Tier 2 environment from available sandboxes.  Let it load (may take a few minutes), then click on the package that was signed off and marked as the Release Candidate from step2.

Choose the deployment time slot and click Schedule.

 

⚠️ Don’t do these steps inside the VM, because the timing will follow the VM’s clock instead of the actual schedule.

5) If prompted, click confirm.













Now the PROD deployment has been scheduled successfully.

Deployment usually takes 1–2.5 hours depending on the customization.

Note: Check the PROD LCS page to see the schedule status. If needed, you can cancel the schedule before it starts. Once it begins, you cannot revert.












After deployment, if you made any entity changes (field addition/modification), don’t forget to refresh the entity list in PROD.

👉 This is all it takes to schedule a PROD deployment in D365 F&O.

Wednesday, August 13, 2025

Custom Sales Line Discount Calculation (Similar to Poland Localization) in D365 F&O X++



I recently had a requirement to calculate the Sales Line discount price in the same way as it is done for Poland localization.

If you’re not familiar with it, you can read Microsoft’s official documentation here: 

'Line discount calculation from the unit price for Poland - Finance | Dynamics 365 | Microsoft Learn'.

Technical Approach:

As per standard, the PriceDisc class, specifically the price2Amount() method, is responsible for calculating price amounts for Sales Orders, Purchase Orders, and Sales Quotations.

For Poland, the price2Amount() method is used to handle discount calculation.

Our goal is to reuse the same Poland logic for our custom requirement.

Steps to Implement:

  1. Create an Extension for the PriceDisc class.

  2. Write a Chain of Command (CoC) for the price2Amount() method.

  3. In the post-method CoC, duplicate the Poland logic and override the amount value.


Context Framework Usage

I used the disposable context framework to ensure:

  • The customization triggers only for Sales.

  • Added custom flag “Custom Sales Price Calculation” in AR parameter form/Prices tab to acts as an extra safeguard. You can turn it on only for the specific company where you want this customization to run, and keep it off for others. It’s also useful for quickly disabling the customization if something isn’t working as expected.


  • Create the context class with necessary variables and methods.

Plese refer this blog if you are not familiar with Context framework '(3) D365F&O. The magic of the Grabage Collection (GC) or story about Disposable Context | LinkedIn'

To initialize the context only for Sales:

  • Extend the SalesPurchLinePriceDiscCalculation class.

  • Override the calcPrice2LineAmount() method.

  • Initialize the context there and set the class variable as true, so the customization runs only for Sales Orders.

This is important because PriceDisc is used for both Sales and Purchase scenarios, and we don’t want

the customization to affect Purchases.

 

Testing Scenarios

Make sure you test both unit and functional cases to confirm the customization works and doesn’t impact other processes:

  1. Intercompany scenario

  2. Sales Return

  3. Sales Margin functionality

  4. Ensure Sales Quotations and Purchase Orders are not affected

Note: I have not tested this with Retail Sales Orders. Please validate this scenario if relevant to your environment.

Disclaimer: Please note that these suggestions are based on my personal experience and may not be the only solution. As always, thoroughly test any changes in your test environment before moving them to Production.

Wednesday, August 21, 2024

Post-PROD DB Restoration Steps

Hi Everyone, 

While many resources explain the process of performing a point-in-time restore from Production to Sandbox in Dynamics 365 FO, post-restore steps are often overlooked. This guide outlines essential actions to take after a successful database restoration. 

Steps:

  • Verify Data Integrity: Open a frequently used form to ensure that the latest PROD data has been copied to your UAT environment.
  • Enable User Accounts: After a restore, user accounts might be disabled. Navigate to the System Admin module, go to the Users form, and enable the necessary user ID’s.

        
  • Email batch job:  Enable the email distributions batch job if required.
  • Custom alerts: If the custom alters are configured in the production environment, disable it.
  • Email parameters: Remove the email parameter setting that currently points to the PROD environment and change it to point to the UAT.







  • This step is necessary if your system has integrated with third-party applications and may not be applicable to all users.

    1. Microsoft Entra ID: Change the Microsoft Entra ID application ID that points to the production environment to the UAT application ID.
    2. Azure Key Vault parameters: Remove the secrets, delete the key vault setups, and reconfigure them with the UAT values.
    3. BYOD: Ensure that your BYOD data source is configured to point to the UAT instead of the PROD. Replace the PROD application ID with UAT in recurring integration data projects(DMF). Set the recurring integrations batch job to "Waiting" status from "Withhold".
    4. Endpoints: Configure the business event endpoints if it's required.

  • Export backup: Once all the above steps are completed, export a database backup from the UAT environment. This backup can be used to restore the latest database to development machines.

How to Assign the Same Security Role to Multiple Users in Dynamics 365 Finance and Operations(D365 F&O)

Hello everyone,

We often encounter situations where we need to assign the same role to multiple users simultaneously. This frequently occurs when restoring the PROD DB to the UAT environment. By following these steps, you can easily assign the same role to multiple users.

1) Before assign the role, ensure all users are imported into the system. Navigate to System Admin > Users and click Import Users. This allows you to import multiple users simultaneously.

2) Go to System Admin > Security > Assign Users to Roles. Select the desired role and click the manually assign/exclude users button.


3) Select the specific users (multiple) you want to assign the role to. Click Assign to Role button to complete the process.

Thursday, July 25, 2024

After Upgrading to Dynamics 365 Finance 10.0.40 or higher, the custom Model Build Fails

Hi All,

I recently upgraded the application to version 40. During the subsequent custom model build, we encountered the following issue

Error message: 

A reference to Dynamics.Ax.ProcessAutomation, version = 0.0.0.0, Culture=neutral,PublicKye=null  is required to compile this module

Resolution:

Update your custom model parameters to reference 'ProcessAutomation' and check-in the custom model Descriptor file.



Tuesday, July 23, 2024

Set purchase order workflow status as Draft when it's created from planned orders


 

Hi All,


I encountered the scenario requiring the creation of a purchase order in draft status after firming the planned order

As per standard, when a purchase order is created from a planned order, the purchase order workflow is automatically submitted and approved.

Customization is required to modify this behaviour, so that the PO is created in draft status, allowing users to review and submit it manually.


Code change:

Create a extension for a class ‘ReqTransPoMarkFirm’ and create a COC for the method ‘shouldSkipWorkflowSubmissionAndApproval()’.

Returning True from this method based on your specified conditions will set the PO status to draft instead of approved.









Technical Note: This method will be available from V39 (10.0.39 onwards).

Furthermore, I've investigated why purchase orders are created in Approved status as part of the standard process.

I found interesting blog written by Ali Danish on linked-in, where it's clearly mentioned the reason of creating the Approved PO and impact of customizing this behaviour. 

Please take a look at the post for a more detailed understanding, 

(5) D365 SCM | The Magic of Planning Optimization | Purchase Trade Agreements | Part 2 | LinkedIn

As mentioned in the above blog, there is a possibility of creating duplicate planned orders when a user runs MRP with purchase orders in draft status.

However, we can avoid the creation of duplicate entry by following the below steps.

  • The PO workflow should be approved with-in one day.
  • The planner has to make sure, no open purchase orders are exists in a system for a particular item before firm.
  • The MRP process should be executed Weekly or two weeks once.

Note: Please double-check with your respective functional before implementing this customization.


Additional information about PO creation from purchase requisition

Customization is not required when a purchase order is created from purchase requisition, it will be handled based on the below standard check box.













Disclaimer: Please note that these suggestions are based on my personal experience and may not be the only solution. As always, thoroughly test any changes in your test environment before moving them to Production.


Friday, April 14, 2023

D365 F&O - Add custom signing limit document type into the singing limit policies.

 

As part of standard, below are the document types available in singing limit polices. To add the custom document type please follow the below steps.

 

Usage of singing limits:

It will be used in hierarchy level workflows to approve the document based on signing limit amount.

Scenario: We are going to add custom document type ‘sales return’. We can use this custom document type in singing limit polices and workflow editor.

1)      Extend the base enum ‘HrpLimitDocumentType’ and ‘SourceDocumentRelationType’ and add your custom document type, here its is ‘sales return’.

2)      Create the post COC for init() method for the below forms

·       SysPolicyListPage

·       WorkflowTableListPageRnr

Ex: Extension of the form ‘SysPolicyListPage’

[ExtensionOf(formstr(SysPolicyListPage))]

final class KMGSysPolicyListPageForm_Extension

{

    /// <summary>

    /// Insert the sales return document type record if not exists

    /// </summary>

    public void init()

    {

next init();

HRPLimitDocument::insertIfNotExists(HrpLimitDocumentType::KMGSalesReturn, SourceDocumentRelationType:: KMGSalesReturn);

    }.

Write the COC like above for WorkflowTableListPageRnr form as well.

Step-by-Step Guide to Move Your Custom Changes from Tier 2 to PROD in D365 Finance & Operations

Hey everyone, 👉  Not every Technical consultant gets the chance to schedule a PROD deployment, but it’s something they can learn. The proc...