Dynamics Community Forum Thread Details

Procurement Category PO's

We use procurment categories and financial dimensions to control budeting and the raising of PO's for service based expensiture encumberance accounting eg media spend

Users raise a large PO with the vendor Qty 1 , Unit price being the value of the service, say £300,000. The accounting date on the PO header and thus to the line determines the encumberance to fall in the correct period. The PO is than confirmed and receipted, with the receipt creating the vouchers based on the accounting date . As the media companies invoice over time with several invoices , we have the situation that the the match of the 1st invoice for say £2,000 shuts down the PO, meaning a new PO needs to be raised for the balance £298,000 and so forth for each invoice posting . This is not great for users to understand teh billing and , also accruals. D365 F& O doesn't cater for a "line type" desgination to allow for a serviced based booking , and allow many invoices to be matched against a procuement cost amount . It is still required to enter Qty 1. There is the ability to use recurring service items ( eg Machine Repair) , but this doesn' suit a service based organstions where the many types of services are being purchased ( Advertising, Web site , consultancy etc) , not discreet labour type service. Dynamics Navision does have a line type to cater for this type of service based organisations in this situation .

Ludwig metioned in post swapping the Qty and Unite orice around , so in this case Qty = £300,000, and Unite price = 1. We tested after introducing 2 DP precision on the "Unit" to cater for decimal points in teh Qty and the process seems to work allowing the PO to remain opened for further invoice matching but are mindful that they may be problems elsewhere in the system of this change , Any other ideas/ solutions would be welcome

Categories:

Microsoft Dynamics AX

Hi Ravji,

In various implementations, I suggested the same approach to swap the quantity and the unit price. There were no side effects apart from people find it hard to remember when to swap the values and when not.

In the last two occassions, I suggested a customization to use a setting in the application (e.g. on the item or category) to let the application know that it should be swapped. Then I used edit methods for the quantity and unit price fields that had logic to determine in which field what value would be stored. The for the user it showed quantity 1 and price 300,000, but in the database it was saved as quantity 300,000 and unit price 1.00 depending on the setting.

This has one side effect that users could not filter on these columns anymore.

Quick Links