01Summary A leading North American manufacturer of heavy-duty commercial vehicles moved three years of procurement history from a legacy ERP into Dynamics 365 Finance and Operations, and roughly 4,000 of those Purchase Orders were already cancelled in the source system. The Data Management Framework imported them as records without complaint, but DMF cannot run a PO cancellation, so those orders landed in D365 F&O as confirmed supply and the first test Master Planning run returned net requirements of zero for hundreds of items the assembly line actually needed. CloudFronts extended the DMF staging entity with a cancel flag and added a post-import X++ batch job that reads the flag and calls the same cancellation API behind the Cancel button on the Purchase Order form. All 4,000 cancelled POs now hold the correct state in D365 F&O, MRP plans against real supply, and a reconciliation log gives procurement a line by line count to check against legacy. Table of Contents 01Summary→ 02About the Customer→ 03Business Challenges→ 04Solution Overview→ 05Technical Approach→ 06Business Impact / Key Takeaways→ 07Conclusion / Final Thoughts→ 08Call to Action / Connect With Us→ 02About the Customer Our customer is one of North America’s leading manufacturers of heavy-duty commercial vehicles, operating an extensive network of manufacturing and logistics facilities. As part of its supply chain operations, the organization manages high-volume production, component manufacturing, and distribution processes that require seamless integration across enterprise systems. 03Business Challenges The customer builds heavy-duty commercial vehicles across a network of manufacturing and logistics facilities, running high-volume component production that feeds a fixed assembly schedule. Master Planning was a go-live dependency, not a phase two item. If MRP could not be trusted on the first run, the build schedule could not be trusted either. Uncancelled POs are phantom supply D365 F&O nets demand, meaning sales orders, production orders and forecasts, against supply, meaning on-hand inventory, Purchase Orders and planned orders. Every confirmed PO counts as expected incoming material. Import 4,000 cancelled legacy POs as confirmed orders and the planning engine sees 4,000 supply lines that no vendor will ever ship. The arithmetic is unforgiving. Net requirement is demand minus supply, so inflating supply with dead orders drives net requirement to zero or below. MRP then raises nothing. The warehouse stays empty and the line stops. ⚠One PO can suppress an entire item A single uncancelled PO for a high-value component, an engine assembly, a transmission housing or a steel frame, suppresses MRP planning for that item across every production order that needs it. At 4,000 phantom POs, the whole planning output stops being usable. Where the existing pipeline stopped Legacy system exports PO line recordsEvery Purchase Order, active or cancelled, leaves the legacy ERP as a flat file record. DMF imports the records into D365 F&OPO lines land in PurchTable and PurchLine through the standard Purchase Order Lines data entity. Backend automation approves and confirms POs starting with NThe automation picks up everything matching that number series prefix and pushes it through approval and confirmation. That pipeline handled active orders well. The cancelled ones broke it in four separate ways. No flag in the file. The legacy export mixed active and cancelled POs, and the DMF entity carried no field to mark which ones needed cancelling in D365 F&O. The automation confirmed the wrong orders. It ran on every PO matching the number series, so orders cancelled in legacy were approved and confirmed into live supply commitments. Manual cancellation cost weeks. The UI cancels one PO at a time. The team sized 4,000 POs at three to four weeks of clicking, and MRP could not run reliably until that cleanup finished. No reconciliation record. Even a manual pass would leave no structured log proving each cancellation completed, and no way to match the cancelled count between legacy and D365 F&O. Why the cancelled POs could not simply be dropped from scope MRP accuracy was the reason this work became non-negotiable, but three other requirements pointed the same way. Audit and compliance. Procurement auditors trace why a purchase was raised, who approved it and why it was reversed. Three years of history with the cancellations missing is a history with holes in it. Vendor performance analysis. Cancellation patterns are where lead time failures and specification mismatches show up. Migrate only active and completed POs and procurement loses the evidence it negotiates with. Financial reconciliation. Cancelled POs that carried prepayments, accruals or commitments have to exist in D365 F&O so finance can close out historical transactions without opening the legacy system again. 04Solution Overview Before the fix makes sense, one thing about D365 F&O has to be clear. Cancelling a Purchase Order is not a data update. It is a business operation, and the status field is the last thing it touches, not the first. What the Cancel button actually does Validation checks. The system tests eligibility. Has a product receipt posted against any line? Has an invoice been matched? Are registrations pending? Any of these blocks the cancellation or narrows it to specific lines. Workflow recall. If Change Management is enabled, the approval workflow is recalled so the PO leaves its approved state through the proper channel instead of a status override. Accounting distribution reversal. Encumbrances, pre-encumbrances and budget reservations created at confirmation are reversed or voided. Inventory marking cleanup. Marking references between PO lines and sales or production order lines are removed. MRP exclusion. The PO drops out of Master Planning calculations and stops counting as incoming supply. For this migration, that was the step that mattered. Status update. Only once all of the above completes does the PO status become Cancelled. The Purchase Order Lines DMF entity writes field values into PurchTable and PurchLine. It does not invoke any of those six steps. Push a status value of Cancelled through DMF and you get one of three outcomes, a validation failure, a silently ignored value, or a written status with none of the underlying logic behind it. That third outcome is the dangerous … Continue reading How a Leading North American Commercial Vehicle Manufacturer Bridged the Legacy PO Cancellation Gap in Dynamics 365 Finance & Operations Using DMF and X++ →

Introduction: In this blog, we will see how to create factbox of workflow history of purchase order in Microsoft Dynamics 365 Finance and Operations Details:  Well, Factbox is a very pretty cool feature available from the earlier version AX 2012. It is very easy to achieve in Dynamics 365 as well.  Here we will see how easy it is and steps for that.    As shown in the above image, we will be going to create factbox for the “Tracking details list” Steps:  Create the solution in Visual Studio and project for that. We’ll be required four objects mainly that is one display MenuItem, Table, Form (on which to display factbox), another Form (factbox). Reference attached below: 1. Table For displaying workflow history, we need to create the extension of table WorkflowTrackingStatusTable and create the normal relation and its relevant properties as 2. Factbox Now we are required to create the factbox of workflow history. For that we will use the effortless technique, where we will duplicate the standard form “WorkflowStatus” and will name as CFSPurchTableWorkflowHistoryFactBox (give name as per your naming convention standards) After duplicating and renaming the form, we need to change the pattern as “custom” After applying the custom pattern, delete the NavigationList which is not required in factbox, and do visible false ActionPane and PanelTab After that create the new Grid and assign the data source to it in the property and put all the required fields to show in factbox 3. Display MenuItem We will attach the created factbox form to the display menu item and relevant label “Workflow history” 4. Base form Base form we call it as where we will attach the factbox. Here it is purchase form. Go to Parm section and create a new part and give it a relevant name and its properties Properties:  Data source: Attached data source with which workflow history is connected Data Source Relation: WorkflowTable.RelationName Name: Part name That’s it. Build the project and go the frontend and check the output how it looks like. Conclusion: It results as (we can scroll left and right to see all the tracking details list) Hurray, How pretty it looks like! In the above example, we have seen how we can develop factbox in Microsoft Dynamics 365 Finance and Operations.   Thanks for reading and stay connected with us for more updates!!! Jagdish Solanki | Senior Technical Consultant | CloudFronts Business Empowering Solutions Team “Solving Complex Business Challenges with Microsoft Dynamics 365 & Power Platform”

When we create purchase order using RFQ its default approval status will be approved. To change that status to draft write following code where we will change its status to draft. create new class and add following code class CFSPOStatusRfq {     [PostHandlerFor(classStr(PurchAutoCreate_RFQ), methodStr(PurchAutoCreate_RFQ, endUpdate))]     public static void PurchAutoCreate_PurchReq_Post_endUpdate(XppPrePostArgs args)     {         //PurchTable  purchTable = args.getThis(‘purchTable’);         PurchAutoCreate_RFQ purchReq = args.getThis() as PurchAutoCreate_RFQ;         PurchTable  purchTable, purchTablenew;         purchTable = purchReq.parmPurchTable();         ttsbegin;         select forupdate purchTablenew where purchTableNew.PurchId == purchTable.PurchId;         if(purchTablenew && purchTablenew.DocumentState == VersioningDocumentState::Approved)         {             purchTablenew.DocumentState = VersioningDocumentState::Draft;             purchTablenew.update();         }         ttscommit;     } }

In the case of D365 Finance and Operations when you approve purchase requisition by default system creates Purchase order with approval status as “Approved” as follows     To change this default behavior of system such that once purchase requisition is approved the approval status of the purchase order as a draft you can use the following class class CFSPOStatus {     /// <summary>     ///     /// </summary>     /// <param name=”args”></param>     [PostHandlerFor(classStr(PurchAutoCreate_PurchReq), methodStr(PurchAutoCreate_PurchReq, endUpdate))]     public static void PurchAutoCreate_PurchReq_Post_endUpdate(XppPrePostArgs args)     {         //PurchTable  purchTable = args.getThis(‘purchTable’);         PurchAutoCreate_PurchReq purchReq = args.getThis() as PurchAutoCreate_PurchReq;         PurchTable  purchTable, purchTablenew;         purchTable = purchReq.parmPurchTable();         ttsbegin;         select forupdate purchTablenew where purchTableNew.PurchId == purchTable.PurchId;         if(purchTablenew && purchTablenew.DocumentState == VersioningDocumentState::Approved)         {             purchTablenew.DocumentState = VersioningDocumentState::Draft;             purchTablenew.update();         }         ttscommit;     } }and your final result looks like And after changing status you can apply your own purchase order workflow on it. For purchase order workflow you can refer to my blog

In this blog we will learn how to create workflows in D365 finance and operation. For this blog we are taking example of Purchase order workflow. Which will allow us to create purchase order which is allocated to different persons for approval and review process. Navigate to Procurement and Sourcing >>Setup>>Procurement and Sourcing workflows, and click on new and select purchase order workflow as follows:- This will open workflow editor in you first need to provide log in details same as that of environment. Here we need to arrange various components and need to set their properties to resolve those following errors. Components for this of workflow: – Start: – To indicate start of workflow design. End:- To indicate end of workflow design. Review Purchase order:-This assign review(Complete/Return PO). Approve Purchase order:- This assign users who needs to approve purchase order.   To design workflow follow the steps :- Now In designer create design as shown in screenshot Set the Review element and right click and open properties and set as basic settings as follows:- In assignment make sure you have assigned type(in our case user) and user name You can also escalate roles after certain time as follows(we are not considering this setup for this blog) Now get back to approve purchase order and open its properties for and set automatic action as follows which will approve Purchase order below 10000 USD. Set the notification for person who will receive notification when particular operation is performed(for eg :- Approved/rejected etc) Now click on step 1 to enter in step 1 section and open its properties. First we are assigning user who will approve the purchase order as screenshot suggest as well as you can set time limit for approval and completion policy as well. You can also add the condition to step 1 which will decide whether to run this step or notNow close step and get back to main design of designer Now click on save and close and mention version notes and activate this workflow Now you can see new workflow in procurement and sourcing workflows Now create new purchase order and after that click on workflow button and click on submit you can also check history of it Now another user will complete the purchase order approval and mention comment. Now user with authority of approval will approve  from common>>Work Items assigned to me  

Introduction: In D365 Operations, when we create a workflow for Purchase Order we face a formatter error related to Time zone. This error is caused due to conflict as same time zone specified twice for a legal entity. First for the legal entity and second time for the address. In this blog, I will tell you how to resolve it. Solution: Go to Organization Administration -> Legal Entities In Address Tab, select More options -> Advanced In General Tab, Edit the Time zone to a different time zone.