Functional Understanding

Procure to Pay (Part 1)

The purpose of this blog series is to provide the basic understanding of procure to pay flow in Dynamics for a Developer.

In this Blog Series, i will try to cover the technical and functional aspects of Full payment Cycle Step  by Step with inventory and financial impacts, also the Basic Account setup and things which will help a developer to better understand the cause of errors.

Standard Procure to Pay Cycle :

Procure to pay Cycle

For this Example i am using two new items and Vendor (Chase Value Center)

  • Shirts
  • Trousers

Purchase Order:

I am skipping Purchase requisition Step and starting from Purchase order as Purchase requisition is just for approval and analysis that either we need the items or not .

I  have created PO for Vendor “Chase Value Center” with Both Items with 500 Qty each. (Assuming to have the knowledge, how to create PO)



In Header view of PO, If financial dimension is missing check the vendor Master financial dimension, At the time of creating PO Financial dimensions will be defaulting from Vendor.

On Hand Inventory:

Inventory transactions can be viewed from the purchase order line area. Click Inventory > Transactions. The Transactions form opens..

OnHand Navigation.png

In our case, we have created a purchase order. So, the item on purchase order lines must have inventory transactions of the Ordered status.


The main inventory transaction fields are item ID, item dimensions, quantity, and item status. Item status is divided to Receipt and Issue statuses.

Receipt statuses are used when items are received into a warehouse. Issue statuses are used when items are issued from a warehouse.

Financial Impact :

Till now there will be no financial impact in the system.



There is also an option to generate a pro-forma confirmation for an order before the actual confirmation has been processed. This option just creates a report that you can share with the vendor. It doesn’t create any journal information.

On Confirmation A journal is created to store an exact copy of what was confirmed in the system. Sometimes, orders require changes, and additional journals are created after the updated order is confirmed. These journals let you view the history of the various versions of the order that were confirmed.

On Confirmation Step Accounting distributions are also created, and order checks and budget checks occur if this functionality has been enabled. If either check fails, you receive an error message that states that changes must be made to the PO before it can be confirmed again.

On Hand Inventory:

Confirmation will not impact the Inventory.

Financial Impact :

Till now there will be no financial impact in the system.

Report name : PurchPurchaseOrder

Classes :

  • PurchPurchaseOrderContract
  • PurchPurchaseOrderDP
  • PurchPurchaseOrderController


Summary :

Till now we have created and Confirmed the PO. In Part 2 we will Create registration , packing Slip and Invoice and will see the Financial and inventory impact step by step in detail.




2 thoughts on “Procure to Pay (Part 1)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s