Correct Method to Return Data From a UD Adapter

BA-Quest · August 15, 2019, 8:11pm

Hello to all.

I am working on a custom UD table/form solution and since this is my first stab at UD tables/forms, I am making quite a few incorrect assumptions concerning how things actually work.

Slight background for this solution
The UD table is meant to be an extension of non-conformance whereby FAA-specific data needs to be captured and related back to the originating NonConf entry record. I already added a few requirements within a direct customization to the NonConf UI (and additional UD fields on the NonConf table) - but - the FAA-related data was better suited for its own separate UD table. In order to relate these two tables successfully, I wanted to make sure that the new UD table maintained its own PKID field (primary key identifier) in “Key1” and a foreign key reference back to the NonConf table by inserting the corresponding [NonConf.TransID] in “Key2”. Pretty simple.

With some terrific assistance I had received earlier this week here on EpiUsers.Help, I was able to demonstrate that, upon requesting a new record in the UD UI, I could generate a new PKID for “Key1” – and – with the implementation of a “Simple Search” wizard, I could also allow the user to select the originating NonConf record and pull in, not only the [NonConf.TransID] in “Key2”, but also a few additional fields which provide extra visual cues on the UI for the user to check and validate.

All of that seems to operate pretty well.

So what’s the problem?
Data entry for the initial UD is only half of what needs to be offered in this solution. These records will also be searched for (by “Key1” value [which is being referred to as an “NMR ID”]) and edited by various others in the chain of custody over the course of several steps in our Quality inspection-to-disposition process. Essentially, I’m trying to simulate/mimic the standard Epicor behavior as depicted in the DMR example below (but this functionality exists for almost anything one intends to look up and retrieve as an editable record):

For example, I can look up a customer record and edit that record at any time. The solution I’m working on also needs to offer that functionality.

However, when I use the same “Simple Search” wizard to create a lookup on the UD adapter, it never pulls back any data to the UD form. Yet, I’ve successfully implemented this capability on the same form in order to look up NonConf information and pull it back to the same UD adapter/form. So, I’m a bit confused by that.

Here’s the basic setup on the pertinent controls for the UD form:

Notice that there are two search buttons on the “Details” section of the UD form.

“What other details might be affecting the behavior you expect?”
We’ll, the NonConf search works, I believe, because the workflow requires a new record to be requested from the UD UI. So, I’m getting a new record first (and an available data view) then, searching the NonConf adapter to pull back data to the UD adapter. However, with the “NMR ID” search on the UD table (again, “Key1”), I’m not supposed to be requesting a new record here. I merely want to search for an existing NMR record and pull it back for editing. So, no UD data view exists at that point.

My limitation is not knowing the correct/best practice way to do this, or how Epicor has established this functionality for out-of-the-box form modules. I simply don’t know it and can’t bridge the gap.

Might anyone know [1] if this is possible and [2] what method I should be using here?

Many thanks.

markdamen · August 15, 2019, 9:05pm

So on UD11, there would have been a search button by default to start with, alongside Key1.

That search should do what you need - but you can improve upon it. By default, it will show you all of the Key1 - Key5 fields.

Check that the search does bring back the record you select to the screen as you expect, and then look to create a BAQ Search on that search so that you can select which columns you wish to display, perform filtering etc.

BA-Quest · August 15, 2019, 9:26pm

Mark:

That makes sense. I had hid that default search button and created a custom button (thinking that was appropriate ). So, let me switch that back and do some work with it and see if that’ll do the trick. Thanks for the help - I’ll make sure to let you know the results.

Banderson · August 15, 2019, 9:28pm

So I did basically what you are trying to do. On the Key1 box , right click, and go to quick search entry. Then you can make a new search based on a BAQ, and if you check the Suppress Base checkbox, that search will replace the stock one.

Here’s my UD10 search

BA-Quest · August 15, 2019, 9:51pm

@markdamen :

That was [sarc]horribly[/sarc] quick.

Got rid of the custom button, found the hidden default button, didn’t have to have any code behind that button at all. Everything just automagically works.

You are awesome, sir… and here, I thought I had to get all fancy

Thanks for the help and for the extra tip on adding in the BAQ Search functionality, as well. That’s definitely going to help pare down the search columns from all that will appear by default in a standard UD table.

@Banderson -

The additional information you provided also helps because I had never set up a quick search before. Good to know that option is also on the table, as well.

Thank you for illustrating that for me - that’s awesome.

Hogardy · August 16, 2019, 12:02pm

Hello Bill,

I was just wandering the following:
You have the DMR form where you indicated using UD table 11 for extra info. Your issue as I understood it, was to implement the search from the UD11 form of your DMR data. I assume then you have created a seperate menu for your users to access this UD11 form.

But have you thought about adding the UD11 table as a child in your DMR form? Via the wizard it does pretty much all the coding needed and it just needs a bit of tweaking. The result is as soon as a user searches for a DMR number, the code gets all related UD11 records at the same time. I personnaly would just create your UD11 view under a new tab in the DMR form. (adding custom buttons to add a new ud11 record etc…) The advantage would be all the info available under one menu, less clicks for the user etc…

If I misunderstood it all …well I apologize…It is just how I would have done it.

Have a good day!

Pierre

BA-Quest · August 19, 2019, 5:53pm

Pierre:

Keep in mind that this issue is currently resolved, but… what I was trying to do was to conduct a simple search, from the customized UD11 form, for records entered into the UD11 table. Since I had been unfamiliar with the default Epicor-supplied key fields and button controls on that form - and also because had read several posts where people had suggested to hide these default fields when customizing a UD form - I had assumed that I needed to hide these fields and create my own controls. That assumption was not accurate.

Since establishing this post and receiving great feedback from you and others, I now understand that the default “Search” button and reserved key textbox fields do serve specific purposes for user-defined table/form solutions.

For my specific case, the default search button was all I needed to launch a search form directly on the UD11 table and return a selected record to the customized UD11 form.