Share
Report
6,355Through an experiment and an extensive study of the source code I figured out that purchase orders derived from an item requirement (through the MRP, there is no other way to obtain a PO for an Item requirement SO) are excluded from the project committed cost.
It is only if you activate Item requirement = yes in the Cost commitment parameters than the system starts recording committed cost from this pair SO-PO.
However, PO cost is considered committed as you confirm the PO, which makes perfectly sense: you have an agreement with the supplier. An "Item requirement", in contrary, is committed into the project budget as soon as the SO line has been created.
From the standpoint of the customer, this is too early:
1) I am opening an item requirement and just initiating my R&D work on the machinery. The cost is not defined, I may not have decided yet between procurement or own manufacturing. Or maybe I won't need this component at all.
2) A planned PO is prepared by the MRP, but not approved: no commitment, this is "just" an artifact on the planning mechanism in D365FO and may be wrong in a multitude of ways.
3) A planned PO is converted into a real PO. We are getting close.
4) The PO is confirmed. There is a signed agreement with the supplier, the cost is now committed for sure.
My client and me consider the moment (4) to be the best event for a commitment.
For any fixed fee project, the D365FO system enforces the event (1), because there is no other type of an SO for a fixed fee project but the bloody Item requirement.
Please tell me, where am I mistaken?
If there is no mistake in my assessment, what would you suggest? Customize the PurchTable.isProjectSalesItemReqPO() method and let it think this was NOT a item requirement-derived PO?
All responses (
Answers (
