5

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)

STATUS DETAILS
Needs Votes
Ideas Administrator

Thank you for your feedback.

Currently this is not in our roadmap; however, we are tracking it and if we get more feedback and votes, we may consider it in the future.

Sincerely,

Johan Hoffmann 

PM,

Microsoft.