Evert Bos Technical Fellow

THe parameter "MAX enforced' on the Agreement line is by default 'NO" I do not know any customers who want to let the remaining quantity on the Agreement line go negative but there could be customers like that. It is much more logical to me to make this parameter say "YES" as a default. Or better still: let the user choose in a new parameter in Procurement. What is your default for MAX enforced? Yes/No. With that it should also be allowed to change it from No to Yes later when you still have plenty of remaining quantity. Right now this is not allowed I wonder why we don't allow that. Of course when we have gone over MAX already, the field should be locked.

The system allows to make items with default order type PUR to be phantoms. The slider on the item does let you say "YES" to phantom and the line type on the BOM line lets you make it Phantom for a purchased part . No warning. but serious MRP consequences. MRP will not recognize existing Purchase orders for a so called purchased phantom and will create a new planned PO but that planned PO will say "Directly derived" because it is for a phantom and you won't be able to firm it. Purchased phantoms should be made impossible as the concept makes no sense. the user should be protected against making this mistake

When a BOM is in the approved or active state, the menu choices "approve" and "activate" should change to reflect that you would no UNapprove or DEactivate if you push them. Their name should change. IT makes a strange impression on the user that an approved BOM stil have a lit up button "approved" showing.

The current situation is that MFG execution parameters control the functionality of the Adv Warehousing transactions for Report as Finished. This is very confusing to the user. Suggestion is to reorganize and rename the menu choices and the field names to indicate this fact. If a customer uses mfg exeuction and advanced warehousing, the option to do an RAF on the workfloor linked to the "completion" of an operation by a registration worker is no longer feasible as a license plate will have to be provided. One would say "NO" to this parameter, but one does not realize that the other parameters in this section are now working for the handheld RAF transaction, the two critial ones being "end job" yes/no and "accept error" yes/no. This iis not made clear anywhere. Suggestion is to add warnings/ messages to this RAF section and also put the RAF parameter in the Warehousing module

This parameter "accept error" , used during Report as Finished transaction, is a questionable design. THe design should be changed. 1 it should be clear what type of error is suppresses. Some errors are indeed non-consequential and should be suppressed. (even better. the error should not even be there.) It remains a strange concept to me to suppress errors. . Example of a non significant error: I have reported my actual times and all my operations are completed but for some reason job scheduling was run, there are still jobs for these operations and they are "waiting". With accept error I can continue with my RAF without wasting time reporting each of these completely redundant jobs complete. 2 The accept error is able to suppress warning message that items in the prod bom "have not been fully released"> it ignores remaining quantity. This is something you would NOT want to suppress . These are two common examples. I suggest strongly to remove the accept error slider completely and change the way certain errors are generated . example 1: if should not be possible when Production routing operations are complete that we still have "waiting" jobs from job scheduling. This is an illogical situation. There should be no need to generate an error for this situation. the situation itself should be made impossible. Example 2: we have the "end mark picking list" already to make the system accept an open remaining quantity. IT is a dangerous parameter already that should in principle not be used. Items are in the BOM for a reason. If we want to ignore that, we should remove them from the BOM> I vote to not have functionality that lets you accept "forgotten" material consumption. (only for discrete manufacturing. I am not talking for Process)

In many screens in the system where items have to be entered (Item inventory adjustment, Item allocation key, many more) the user faces a time consuming clicking process because the item dimension display by default displays Size Color Style and Configuration. Every time the user gets to that screen , four clicks to uncheck these . One can assume that the vast majority of items used on transactions do not use these dimensions. It makes no sense to have this default "checked", it should be the opposite, unchecked. if the "save set up:" button would work, this idea would be less important but facing the fact that it seems an irreprairable flaw of D365 that "save setup" no longer works, we have to insist in changing these defaults.

The constraint based configurator can only produce config id's for a product master. Many customers want the configurator to produce new part numbers just like Product Builder could do. This is a much more user friendly way of working with configured products.