I’m sure like others, we have Reason Codes for RMA, Scrap, etc areas that have for one-reason-or-another been needing to be “disabled” and no longer show up in the pull down. In this case, I was lucky we only had two valid reasons to display and I was able to get some help to this filter working:
EpiFilter: ReasonCode = ‘?{ReasonCodeCol,’’}’
EpiFilterParams: ReasonCodeCol=
SearchFilter: (ReasonCode = ‘Credit’ OR ReasonCode = ‘Warranty’) AND ReasonType = ‘A’
My question --for future use-- is there a wildcard in the filters available? ie: ReasonCode <> ‘ABC%’ that would exclude any codes that started with “ABC”?
One way to accomplish is to put the filter on GetList/GetRows BPM to filter out the unwanted values. Annoying, but possible
Interesting idea @Aaron_Moreng. As I was thinking about it more, if I run into a case where there is a long list to codes display, probably do a UD checkbox field for “Disabled” and filter via that.
It sure is annoying that they don’t have an “Active” flag or something to that effect in the reason code section.
Isn’t it just?! Also missing “Active” flag on Customer Ship To’s, ShipVia’s, and probably more.
Aaron, I’m going to give you the solution as it’s elegant and doesn’t need a UD field. 
Though my lazy ass would probably go the UD field method just for future upkeep. 
Low tech way is to change the description to start with Z-do not use ( original description)… The ones you don’t want all show up at the bottom and the good
ones show up normally.
We have done exactly this and it works for us. It’s very annoying there’s no built-in way to retire Reason Codes - we were stuck with once-off ones used only during implementation.
That’s actually the filter I was trying to use.
It’s a common issue I’ve seen at every company where we’ve used Epicor. The UD checkbox to filter I’ve seen before, was trying to be clever and find another way. But alas, @Aaron_Moreng had the clever idea.
I’ve added a custom field like “Inactive_c” to many tables like ProdGroup, PartClass, etc… Then anywhere a user can select an entry from that table, I add a filter for Inactive_C = false.
I know I am coming in late on this and a solution has been found. But if you uncheck all the boxes that the Reason Code would apply too would that not make appear in a drop down list. I know you have to have items checked to be seen so I would think the opposite.
Side note…I do wish Epicor would make more options with Inacttive or Disabled check boxes. Just helps to keep the system cleaner when changes occur.
Coming in even later. For Reason codes use Reason.GetList. works a treat and you don’t have to apply the customisation against the menu. Bring on the Active flag.
@Kimberley Unchecking on the reason code doesn’t work for inventory adjustments (10.2.400). 
Still late to the game but an interesting use case. Our users are used to simply entering in the reason code, as opposed to using the drop down. So, if they enter “13700” + TAB, “zDoNotUse Inventory Adjust” still populates into the Reason Code field, and will post. Even though they can’t see the reason code in the drop down list. So, I’m trying to develop a BPM that will prohibit this from posting. If/when I get a solution, I’ll post it here.
This might help:
Funny this would come up. I just noticed that in RMA entry the reason code combo shows the filter as ReasonTyp = ‘A’ however it returns, what it seems to be all the reason codes… very weird… So it looks like that BPM I wrote whilst works ok for Qty adjustments breaks RMAs…
Here’s and updated one that is a bit busy and could have been better done in code.ReasonCodeFilterInactive.bpm (93.7 KB)
I’ve only tested RMA and Qty adjustment so the usual caveats apply. Put ZZ in the description of the reason code you don’t want to use.
If you wanted to make things a bit prettier you could add a ud field to the reason table that was a bool for inactive/active and run the BPM against that.
For our use @hmwillett had the answer, the filter needed “NOT LIKE” instead of what I was trying; <>.
Hi Calvin. Always nice to hear from you in a thread! The issue/concern I have with using a BPM on Erp.ProdGrup.GetList, or any method that simply filters the list of ReasonCodes/ProductGroups etc., is that a user can still type in a reason code that’s not on the list and post/save. That’s the issue I’m having right now. They don’t even use the list, just type in a code they have been using for 10+ years that is now defunct. So, what I really think I need is something that does a secondary validation prior to Post/Save. What are your thoughts?
-S
Have the BPM verify that the code is valid before the save and reject if it’s not a valid code. May need to add a UD checkbox to mark older existing codes that are now “defunct” as well.
