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:

1. One cannot confirm an Item requirement sales order. Order confirmations are not supported, you cannot confirm the delivery to your customer in a structured way.
2. The user interface differs radically from the normal sales order, which is not well received by users and business owners.
3. 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.
4. 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.
5. Similarly, ad-hoc Intercompany order chains are not supported.
6. In the Warehouse management module, item requirements cannot be consolidated in a load with “classic” sales orders.
7. 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 allocation in the funding rules doesn’t matter. You make this mistake only once, but you may still gain access to your IR sales order through the normal sales list page or the Item tasks/sales orders button. Processing the delivery of this sales order poses a serious challenge, though (unless you use Warehouse management).
8. 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.
9. 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”.

What can we do?

Not much:

• 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.

The post What Item requirements can’t do appeared first on ER-Consult.