There’s a few threads on here for limiting the lists presented to users. Mostly for the need to “inactivate” a record to prevent future uses of it. Like:
While this works well for most applications, a few people have mentioned issues where it has limits or shortfalls. So I wanted to open a discussion on the uses for this type of custom functionality (don’t want to call it a “customization”).
Not sure if all (or any) of theses are still valid, but its a starting point.
Some expectations / special considerations:
Just when creating new records. It is not for records that already have a value for the selection.
The inactivated list item is “hidden” across the whole company. And should not be available for selection from anywhere but in the Maintenance for that object.
One person reported that users could still type in the missing selection(one inactivated by the method above) - not sure if they type the code or the description - and the “inactive” one would be used. Has anyone else seen this?
Another issue that comes to mind (and might be related to the above), is when not only is the list populated, but one of the selections gets selected. Like a form where you’re presented with a dropdown of inventory bins that have a QOH for that part. Something is pre-selecting an item from that list. Maybe it is something like the default bin. Would this case bypass the limited list?
I’ve been testing this with PartClass. I have the BPM ready to go but I haven’t enabled it yet. From my tests so far, it seems to be working. I’m changing the whereClause with a pre GetList BPM similar to what @timshuwy did there. I’ll add a few important things below, they are probably related to the issues you mentioned.
When you’re using the form (Part Entry for example), GetList is not called until you click on the PartClass dropdown. So GetList doesn’t populate the selection in the dropdown, that is done before GetList is called (my guess here is GetByID).
When you change the whereClause, make sure you’re not overwriting it. You’ll need a null/empty check first. If whereClause is empty you just set it (whereClause=“Description not like ‘do not use’”), if it’s not you add it to what’s already there (whereClause=whereClause + " AND Description not like ‘do not use’").
Regarding the selection in the dropdown, here’s an example. Let’s say you have part 123 with ClassID=‘ABC’ and class description ‘ABC - do not use’. Class ABC is already assigned to part 123 in Part Entry. You now create the BPM that excludes ‘do not use’ class descriptions and you enable it in your system. Here is what happens in my version:
I go to Part Entry and select the part 123
The form will still display the class ‘ABC - do not use’ and it will still be visible in the dropdown. But just this one and not the other classes with ‘do not use’ in their descriptions. And that is because it’s assigned to the part and I don’t think GetList has anything to do with that
I now go in and change the class to something valid like ‘class X’. After I save, the old ‘ABC - do not use’ will still be visible in the drop-down BUT…
If you close the Part Entry form and open it again, or if you right-click on the class drop-down and select Refresh, it will not be there
So this works even better than I expected - if you have a BPM that excludes some classes and if you have parts with those classes already assigned, you’ll still be able to see and change them.
With that being said, I would love to hear from somebody who has this in their live system.
I’ve used a BPM on the GetList method for many places. But only for “inactivating” a record. I’ve also used a UD field to set whether a record is inactive or not. A little more complicated than going off the Description alone, but I feel its a little cleaner.
@Dragos - With your BPM enabled, and you go to Part Class Maint, and use the button to search for a Part Class, do your “do not use” classes show in the search results? If it doesn’t I’m sure you could just type ID in - if you happen to know it. A tweak to your BPM would be to also check if the user is a Sec Manager, and not apply your rules if so.
Others have mentioned that in some forms they can manually type the inactivated ID (or description?), and while its not in the dropdown list, it is valid so the record using the field does save without any problems. I’ve not seen this myself.
I have gotten around the ability to type in a value instead of searching or pressing a combo. There are two methods… one is getlist and one is getbyid… you can create a BPM in both… the getlist is where you can remove entries in a post processing BPM. but in the getbyid, you can also apply a post processing bpm and look at the data that is returned… if it needs hidden, you can throw an error and clear the value.
There isn’t a search button for Part Class but if I use Open With - Part Class Search then I can select the classes with ‘do not use’. And it makes sense as the search doesn’t use GetList. It also works if I type in the class ID.
I guess both of the above can be fixed with an pre-update BPM that checks the class description and throws an error if it contains ‘do not use’.
I like the idea with the security admin, I’ll have a look at that.
I knew this wasn’t going to be that easy. Found the first issue with ProdGroup. With the BPM above enabled, as soon as I right-click on ProdGroup in Part Entry, I get a server error. And that is because Epicor does a GetList just before that. It sets the whereClause to the selected group in the form with something like “ProdCode=‘somecode’ BY Description”. So you need another condition in the BPM to bypass that first.
