Passing CustNum on load to ShipTo quick Search parameter

Below what I tried to do but nobody reposed so I’ve changed the approach. I want to use a quick search. The BAQ has a defined parameter and quick search has a prompt criteria of CustNum. Both ignoring nulls. When Basic search open the WhereClause has a customer number. I want to feed this information to my quick search criteria. The best way would be to use a bpm as ship to is used in few different places.

Have anyone did this with the quick search?

Thank you
Aleksander

Hi all,

I have an UD Boolean field in ShipTo table - Inactive_c. Whenever I do not show some address in ship to search I mark it as Inactive (checkbox on Customer -> ShipTo tab). I have a predirective on GetList method with a simple code:
string myFilter = "(Inactive_c = 0) AND ";
whereClause = myFilter + whereClause;

This worked great on sales order screen. When I was asked to do hide inactive address on opportunity/quote screen I thought the ship to button triggers the same method. I could not be more wrong.

I used tracing to find that the GetListFilterCustomer is used and according to help this method calls GetList one. The result are not filtered and contains addresses marked as inactive. When I tried to create the same code on GetListFilterCustomer I was given an error when searching for addresses that there is a multipart indentifier ShipTo_UD.Inactive_c and and cannot be bound.

Could you please help me understand why if the getlist is called inside GetListFilterCustomer my predirective is omitted? Why the GetListFilterCustomer is used then it’s actually do the same what GetList does? Why I am getting this silly error message?

Thank you
Aleksander

I realize this is a 3 year old post here and Aleksander has likely moved on, but I wanted to note that I had this same question and came up with an approach that is probably a hack but I wanted to share it regardless. In my case I was building a custom lot search dialog invoked via quick search. “Out of the box” I didn’t see any way to make this quick search automatically scope down to just lots for the part I was dealing with. My hack looked like this:

  1. On the screens where I was invoking the lot search dialog I set a tag on the user record that is something like “LotPn=Part1234”:

  1. Then I added a pre-processing on QuickSearch.RunQuickSearchPaged that auto-populates the PartNum field that was defined as an available criteria in the quick search:

So from here I have just set the quick search to the default and the users have a custom lot search that can work exactly how they want it including all of the search filters or columns imaginable from a BAQ. The only caveat is that you MUST include the column you want to automatically filter on as a quick search criteria - I just labeled it as “Part Number (Automatic)” and instructed the users to just leave it blank.

Without a doubt there is some additional overhead from the reads and writes to tags here and perhaps some day I will look back on this approach and think it was a bad / stupid idea. But for now it got the job done.

I read this without looking at who posted it and now I got to the bottom and went back to see who came up with this idea and it is you Adam! That is an out-of-the-box way of going at this.

I was looking at different ways people were trying to handle this on the forum. This is wild.

I was wondering if there is no way to use a context BPM field instead?

My question is, how do you know what quick search they are calling when this method directive runs?

Or can you add a row to the ttQuickSearchCriteria table regardless of what is being called? I see you are setting the QuickSearchID in the row so maybe if the search they are calling isn’t that one this doesn’t cause any errors?

EDIT: I guess it does have to do with the QuickSearchID field being set. This would get called every time the quick search method is called that we write the BPM on. Still I wish there was a different way to store the PO number or in your case the lot number.

Hey Utah - nice to hear from you! I gotta say, I was hesitant to even post this because it seemed like such a hack. But in the end, I wasn’t really able to see a better way - the BPM call context wasn’t an option unfortunately so I was racking my brain thinking if there was some sort of “session context” I could use. Obviously environmental variables were not an option this time (I use them from time to time when dealing with client side code) because quick search is executed at the sever. So I ended up with this hack of a “user context”.

To your question, I think I did fail to mention I added a criteria on my BPM so that it only ran for a specific quick search ID.

Now with my code here it is true that anything could be setting my LotPn variable and that would affect the quick search results but that was desired in my case.

The only other option I have seen used on a few implementations is to just ditch the standard search screen and develop a custom dialog. That just ends up being so much extra code.

I think if I were to spell out what would be ideal in the form of a feature request to Epicor it would actually be something similar to the hack here - that in addition to BPM call context that we’d also have access to a BPM session context. As developers we could store values in this context just like we do for call context, but it would bridge that gap when something is not part of the same call. And ideally, being a session context, it would clear out automatically when the session is disposed.

Thanks for the further detail! I was about to go down that road of creating a custom quick search, but I saw this post and thought maybe this would work!

So this is server side, but does the search button on the lot entry screen have some event that you can pass an launch form option variable to?

I recall lfo options being something people used when trying to pass data to forms. Would the search form also have something like that?

-Utah

I don’t think so (but I’d be happy to be proven wrong). Obviously in some manner the standard lot search dialog knows to filter down for just the given part - I am just not sure if there is any way to snag that and feed it into a quick search.

I would also love to see someone that may have been able to snag that action and feed it into the quick search.

Thanks for your thoughts and time Adam!

I know that this is now a really old post, but I think this is what I want. I am trying to pass a PO Number to my quick search using this code/BPM logic. My problem is I am getting compiler errors for namespace sysTag. I added in the 2 SysTag assemblies I found but I still get the errors. What is the proper assembly reference? Also I don’t see where userSysRowID is being set.

Hey Jeanne,

Yep, looks like I was missing notes on both of those details. See attached for the customization where I implemented this logic and let me know if it doesn’t clear things up for you.

App.IssueMaterialEntry.IssueMaterialForm_Customization_IssueMaterialEntry_20210119_CustomExport.xml (19.8 KB)

Thanks so much for the help Adam! I got this working but I do have a question. My Quick Search has PO Number for the prompt when the search opens but it isn’t filled in for the user. When I click the search button it does return the correct search results (for the PO passed in). Any idea how I would either put in the PO number into the criteria field so the user knows its there or is there a way to force the Search button to be clicked so they see the results automatically, since the PO is already there?

That was something I never got to buttoning up when I had implemented this - I basically just told the users not to worry about filling it in. If it were a regular form I’d say just use a customization to hide it or something but you kinda get what you get with quick searches.