Microsoft Dynamics AX 2012 R3 splits the procure to pay (P2P) process between the procurement and sourcing module and the purchase ledger module. With this split, AX has introduced functionality specifically to meet the operational requirements of the procurement function whilst seamlessly integrating into purchase ledger and general ledger. The procurement and sourcing module can be utilised to manage both stock and non-stock procurement. Here we take a closer look at some features to aid non-stock procurement.
Previous versions of AX required the setup of a ‘service’ item to select on purchase orders. By default, it was configured to be a non-stocked product so no physical stock records were kept when used. It could often be lost however within the existing item listing, and if not properly managed, opened up the potential to duplicate its setup in the item listing. Think about your own product listing. How many ‘Paper, PAPER, Printing Paper’, products do you have? If the service item was not managed like this, it was used as a single ‘catch all’ item for all purchases, which removed the ability to report on the type of purchases the business is making when it came to non-stock procurement. Whilst that option is still available, AX 2012 introduced a concept called category hierarchies, and more specifically for our purpose, procurement categories.
A procurement category hierarchy provides the ability to create structures of parent and child nodes for use within the procurement process and can be independent of the item listing. It guides the user to selecting the correct category when purchasing. Imagine expanding a section called ‘Office supplies’ to see nodes of ‘Pens, Paper, Envelopes’. Reducing input error, but also adding the ability to report on spend per category. Without the use of categories, with a single ‘service item’ approach, you would need to analyse the invoices posted against the supplier to get a useful spend analysis. With procurement categories, that process becomes a lot simpler. The same hierarchy can also be used when purchasing stock items to narrow down the item selection when adding items to the purchase order.
The procurement hierarchy use does not stop there. It is also used when setting up purchasing policies. Examples include determining the rules of which suppliers can be used when purchasing against a particular category. You can tie this to an approved or preferred supplier list setup against the category itself. It is also possible to control which sections of the hierarchy users in the business will see. Why allow someone raising requisitions from the warehouse to see categories relevant to the IT department? In addition, spending and approval limits can be configured for use with the requisition and approval process.
How does some of the described functionality help the purchase ledger department? When using the single service item approach, every time an invoice is received the first thing the department would need to do is code the invoice and send for approval. With procurement categories, you can determine the cost account per category node. What does this mean? It means once a user selects the category they are purchasing, they are also coding the invoice for the general ledger. Invoice matching rules can also be set independently from stock purchases, with controls at category level for whether or not you want to two or three-way match, or even which categories should make financial entries at purchase receipt.
The category hierarchy can also be used to process non-stock invoices that did not originate from a purchase order. Again, reducing input error by selecting a category of spend to default financial information already setup by the finance department.
With the above configured and the use of module specific on system workflows, the non-stock procurement cycle from requisition to purchase order, receipt, invoice and payment is an integrated process. A purchase requisition request for some ‘paper’ defaults the supplier and the cost account. Once submitted and approved through the AX workflow engine, the purchase order can be automatically created. The invoice can then be received against an already approved expense, processed and paid.