This is more of a theoretical/discussion topic. I’ve been going through a lot of my new Epicor environment’s custom c# BPM code and I’m noticing a lot of hard coded “checks” if you will. An example of this is a BPM that checks the description of user codes. The previous developer hard coded the descriptions into a list variable instead of creating an array of descriptions that read from that table (for the most up to date list). If new codes are added or removed than that BPM will need to manually be modified to accommodate the change.
What do the majority of you all (awesome fun Epicor userland) use in bpms? Hard coded values or dynamic lists that read in from tables?
Depends, if that list in only used in that place, there is no need to mess with UD codes/UD tables. If it reused, or needs to be updated by users, then UD codes is the way to go
The UserCodes functionality exists for this sole purpose. It’s free, included in the framework and I can’t think of any good reason why you would want hard coded lists for validation.
However like Chris said if it’s only used here… That’s probably ok, however like I said it’s free and it doesn’t force you to go modify code when you inevitably need to add more values.
And my favorite reason… You can show the users how to add them / change them and then it gets off your plate
Hard Coding…Ewwwwww. Nothing like making it hard for the next person…as Jose said, it is one less thing for users to hassle you about. The same goes for dashboards. I am a big advocate to make sure that you make a dashboard as flexible as possible for users, (also the BAQ behind it) so you aren’t left with a million requests for specific requests which more often than not a derivative of a single dashboard. There are limitations into the amount of flexibility, but stopping and asking the question “who else is this going to be useful for” doesn’t hurt.
Going back to the checks. The only check you should have is the inactive flag…and one user codetypeid per BPM usage, of combobox usage (er Problem Application Design), if that makes sense. Don’t forget if for some particular reason you need more fields in you user codes there is nothing stopping you from adding more.
If you want to restrict users from only changing some User codes and not others then you would put a BPM on the security group based on the codetypeid.