Eugen Glasow Solution Architect

The existing SalesQuotationTable V2 entity only supports quotations of the Sales type. There is currently no way you can export, or import a project quotation. Funny enough, there is a Project quotation WBS entity. Since you cannot import a header, the usage of that one must be very limited :))

There must be an option to turn off material consumption on the mobile scanner, and let the system only backflush materials at the Job card terminal. The Mobile menu items "Report as finished and put away" and "Report as finished" must be extended for non-compulsory material consumption. This is a one-liner in X++ in the WhsWorkCreateProdPut. setProdParmReportFinishedMainProductFieldsForProdItem() method: ... prodParmReportFinishedMainProduct.bomAutoConsump = ProdParametersDim::find(prodParmReportFinishedMainProduct.InventDimId).BOMAutoConsumpRepFin; ... Justification: the error-prone recording of the material consumption is an internal planning and controlling requirement, while labeling and shipping generates revenue. One does not want to see label printing failing just because one screw is missing in the ledger. See also https://experience.dynamics.com/ideas/idea/?ideaid=dd8b4ec9-781c-e811-80c1-00155d7c7f0c https://experience.dynamics.com/ideas/idea/?ideaid=aa2399b7-e407-e811-80c0-00155d7cd0b4

Advanced scenarios may require a distinction between an “Operation finish” and “Production finish” as opposed to a single flushing principle “Finish”. This is hard to achieve through an extension to D365FO, as the respective enumeration is not extendable. For example, in a sophisticated environment where packing is performed by a robot, the last operation “Packing” is not managed by the Manufacturing execution module. The WHS “Report as finished” function is triggered as full boxes or pallets pass a simple photoelectric sensor or a bar code reader. While the preceding operations may be captured at the Job terminals, it might be tempting to backflush the packaging materials at the ‘non-operation’ Report as finished. This is not possible, because a material with no operation number is accredited to the first operation on the route. A split of the Finish flushing principle into 2 could have addressed this scenario: - Operation finish - Production finish where the mobile device only considered the latter. see http://erconsult.eu/blog/missing-flushing-principle/ for more details.

The D365FO configuration is not granular enough to divide the Manufacturing execution RaF and the Warehouse management RaF (reporting as finished), and should better be enhanced by a parameter per Resource. Imagine operations running in dedicated production orders, with tangible semi-finished goods (SFG) exchanged between the machines. This is a common scenario in process manufacturing where the SFG batches can hardly be quantized and bear no labels. The output and input resource locations in the middle of the chain are not license plate controlled and do not have to be equipped with mobile scanners, as there is nothing to scan. Here we need a choice between semi-finished goods reported as finished at Job devices, and finished goods reported from Mobile scanner devices. This configuration – whether to trigger Reporting as finished in Manufacturing execution or not – is available at the Site level only, not a single Resource level. Yet an Advanced warehouse process cannot span multiple warehouses, let alone sites. This would end up either in full blown transfer orders between machines, or in an inability to track actual time at the Job card device. see also http://erconsult.eu/blog/missing-flushing-principle/

Purchase orders (PO) derived from an “item requirement” sales order (e.g. through the MRP) are excluded from the project committed cost. It is only if the Item requirement is set to yes in the Cost commitment parameters, then the system starts recording committed cost from this pair SO-PO. An "Item requirement", however, is committed into the project budget as soon as the SO line has been created. From the standpoint of my customer, this is too early: 1) An item requirement sales order is created to initiate the R&D work on the equipment. The cost is not fully known yet, as the product BOM has not been fully developed and we may not have decided yet between procurement or own manufacturing. 2) A planned PO is prepared by the MRP, but not approved: there is no commitment yet, as a planned order is an artifact on the planning mechanism in D365FO and may be amended or cancelled in many ways. 3) A planned PO is converted into a real PO. We are getting close, but the ultimate price and delivery date has not been promised yet by the supplier. 4) The PO is confirmed. There is a signed agreement with the supplier, the cost is now committed. The logic should be reversed: if there is an item requirement sales order with a PO coverage, take the PO for the cost commitment and the SO delivery for the ultimate budget consumption. We can make this behavior dependent on the project management parameter Create item requirement. It if is set to No, apply the above modified logic. If it is set to yes, use the standard business logic.