We’ve had many heated debates as to whether or not to provide a default when we make a field mandatory. And sometimes whether or not the “mandatory-ness” of the field should be enforced.
I’m kind of against using defaults. It’s always obvious that a ProdGrp of <blank> is wrong for that part. But if you setup a default (say: WIRE), you can bet that there will be many instances where the PrdGrp was left as WIRE when it should have been changed to something else. Now finding those is not always straightforward (unless you have a “smart” or “categorized” P/N scheme).
Changing the PrdGrp or PartClass of a part isn’t to difficult - aside from issues related to GLC’s tied to those Grp’s or Classes.
I don’t like to set defaults. I typically suggest that it should be required and leave it blank. That said, I also know that some companies say "but what if the user doesn’t know which partclass/prodGroup the part goes in… my answer… “Well, maybe your part classes and product groups are too complex”?
One answer is to create a special class/group called “TBD” that is defaulted. Then a dashboard that finds all parts with TBD so that it can be updated by a person how knows. You can also make additional BPMs that keep the part inactive until all "TBD"s are set.
But going back to part class complexity… if you have classes such as “long bolt” and “Short bolt” and the definition is unclear, you will always fight the problem. How about “Bolt” or “Fastener” as a class instead. It is amazing how many variations we find in the field.
On the Parts Class side of things, I find that there are two groups that wan to use them differently. Materials group wants them to be meaningful for them - like doing Inventory checks, settinig up Buyers, etc… While the other group is accounting and they want it to be all about the GL (via GLC on the class).
What I do is determine which Department requires the most granularity and setup the Classes that way, which, in my experience is usually Purchasing\Inventory Management. Then Accounting can assign the same GL Control to multiple Part Classes.
As for defaults, I typically advise against using them unless they are redundant settings, meaning that certain part classes should ALWAYS be non-Stock, then that makes sense. Sometimes if I am using a BPM to set a field value, I will pop up a message stating what else was set, just so the user is aware, but that depends on what it is. In some cases people struggle to determine the correct option or sometimes multiple things contribute to which value to be used and those hierarchies that some companies have can get complex. In that case, I will use a BPM Form to ask the more business friendly questions and let the BPM then determine the field value based on the combination of answers.