What Item requirements can’t do
This is kind of a recurring question: people have illusions about the Item requirements sales order type in Dynamics 365 for Finance and SCM.
First of all, in connection with a Fixed-fee project in D365 you may only open an Item requirement sales order. In one of the D365 versions they shortly enabled the classic Sales order but then quickly closed the ‘exploit’ (“Sales Orders may not be created for project type Fixed-price“), because a “classic” delivery note (en-us: Picking list) does not produce project transactions; the sales order would forever remain in the status Delivered and would never impact the project revenue. A project Sales order is only available on T&M projects where it can be billed directly.
Project management and accounting/Item tasks/Item requirements
Pros and contras
A project sales order of the Item requirement type cannot be updated with an ordinary Delivery note but the special “Project – Delivery note” only. Then it produces a cost transaction to drive the project revenue recognition. Once delivered, the line immediately becomes “Invoiced” as if the sales price was zero. The support of Warehouse management had been added some time ago, and the shipment knows exactly which type of the delivery note to trigger upon confirmation of the load. This is what can be considered ‘good’ about the sales order type.
The list of the Item requirement sales order disadvantages is much longer:
- One cannot confirm an Item requirement sales order, I seriously can’t comprehend the reason. Order confirmations are not supported, you cannot liaise the delivery to your customer in a structured way.
- The user interface differs radically from the normal sales order, which is not well received by users and business owners.
- One cannot activate the Direct delivery mode at the IR sales order line level. Instead, you use the classic marking and open a purchase order through the Create purchase order button. Then you have to manually update the purchase order, choosing the customer’s address from the global address book and propagating it to the lines.
- Subsequently, a PO delivery note cannot update the sales order unless you affirm the “Consume items for a project…” prompt on posting. This however requires a 1:1 relation between a PO and SO which is not always given if the MRP planning is used: one purchase order may cover both project and non-project demands, and won’t become a Project purchase order. In such a case, the IR sales order delivery note must be posted manually.
- Similarly, Intercompany order chains are not supported.
- In the Warehouse management module, item requirements should not be consolidated in a load with “classic” sales orders as they may not be on the same delivery note. This is a subtle, nasty trap: in standard D365, a delivery note is posted per load = truck, not per shipment = order. There is an attribute, a flavour of the load whether it’s a ‘project’ load or a ‘normal’ load. In a mix of different sales order types this flavour cannot be right of course (see \Classes\WHSSalesPackingSlipPost): either one shipment or another is going to be posted wrongly or throw an error. Post the 2 delivery notes separately from the sales order screen, neither the load nor the shipment Delivery note button is going to work.
- Item requirements do not support multiple funding sources, i.e. multiple billing customers or changes of the customer account in the project contract. And no, the latest feature Allow sales orders for projects with multiple funding sources does not apply to the fixed-price project, try it: “Item requirement may not be created for a project associated to a contract with multiple funding sources“.
The validation is dumb stupid, the 100% allocation in the funding rules to one or another funding source doesn’t bring any relief. You make this mistake only once; you may still gain access to your IR sales order through the normal sales list page or the Item tasks/Sales orders button, but processing the delivery of this sales order poses a serious challenge (unless you use Warehouse management). And no, you can’t remove the 2nd funding source anymore: Catch-22. You better delete the sales order and start all over.
- For the migration of historical orders, there is a special entity “Project item requirements“, and it is weak. It works at the line level and creates one SO header per project, i.e. you have no control over the Sales ID. Most of the sales order header attributes – delivery reason, sales taker, sales responsible etc. – are not available.
Last but not least, non-stockable services are not updated properly by the “Project – Delivery note” and such a line remains in the Delivered status forever, the sales order as a whole will never be “Invoiced”.Update 28.07.2021: the issue 9 will go away if you activate the feature Enable creation of item requirement for non-stocked items: “Enabling this and turning on the ‘Create item requirement’ parameter will create an item requirement when creating a PO with non-stocked items.”
Update 29.08.2022: The mode Allow sales orders for projects with multiple sources has been extended to fixed fee projects. In some July 2022 update (10.0.27 ?) they finalized the feature “Allow item requirements with multiple funding sources for Project Operations stocked/production-based scenarios“. Activate it, and the caption for the above parameter becomes SALES ORDERS AND ITEM REQUIREMENTS. Warning: activating the feature does not update existing sales order lines! A new field Invoice account at the item requirement lines remains empty, and it prevents you from updating the lines.
What can we do?
- Live with it.
- Complain about it, but Microsoft has been aware for a long time.
- Re-enable “classic”project sales orders on Fixed fee projects and programmatically enforce the “Item requirement-style” delivery note on those sales orders. This is not an easy development, but feasible in D365.
Project Management and Accounting blog series
Advance payment invoices in Fixed fee projects in D365, D-A-CH style
What Item requirements can’t do
Revenue recognition with project budget shadow forecasts
Intercompany project invoicing in practice: Process
Intercompany project invoicing in practice: Setup
Hi Eugen, we found this article and share both the experience and the sentiment.
Microsoft, since the early AX days seem to treat Projects and Sales orders as though no business would ever have a scenario to use both and we’ve found that the Projects area has become less and less flexible – to the point we’re going to have to likely develop much of the above, including intercompany chains etc.
On #9, we’ve also found that you can’t use the Sales Categories on fixed price projects – again, our Project Manager teams who enter both Projects for a our large engineered orders and Sales orders, for our flow business – tend to try and just enter everything in the same way, for reporting – so we use Documentation as Sales Categories for example but when you try to deliver them, they go to Delivered & not Invoiced.
Any ideas on this or is this also in the “Complain about it, but Microsoft has been aware for a long time.” bucket?
Hello, MSFT must be working on some issues. For example, a solution to #7 must be close: their upcoming feature has the name ProjItemRequirementMultipleFundingSources and it is present in the latest D365 codebase, but I guess the FeatureLifecycleStage = Incomplete means they are reluctant to release it yet due to some code quality issues:
As for #9, I see not a slightest chance to get it fixed. The legacy code relies heavily on InventTrans to calculate the cost price or to make an update of the sales order line, but a Sales category cannot produce an inventory transaction by definition.
The feature ProjItemRequirementMultipleFundingSources has apparently been released into production. See above.
In a similar way, also project and non-project purchase order lines do not work smoothly together (for example – releasing purchase agreements into project and non-project purchase orders)
Earlier this year I participated when a mid-sized corporation that does a lot of project (and not-project) procurement evaluated both D365 and Oracle Cloud.
Even for their relatively straight forward business requirements the project related functionality in D365 fell so short compared to Oracle that it became a major reason for them to pick up Oracle in the end.
Yes, same here. Nobody understands why a PO for a project production order may not be be a project PO. I mean, technically is it easy to explain, but from the business perspective this does not make much sense.