Want to force a value into a Key field on an Ice UD entry form. Fro example I always want PM as the value for key1 if they are entering using the preventivice_maint customization.
May I ask why you need a key value to be dictated by a UI customization that is in use. Any reason you couldn’t just consume a separate UD table for the separate data? Sounds like you are trying to pack too much data into one UD table.
You’ll likely have to go down a rabbit whole of overriding the new button in the toolbar if you can’t come up with another way
In addition to Chance’s very thoughtful and worthwhile comment, Epicor data binding is not like Access or VB.Net, etc. Instead of forcing data into form fields, one always should change the DataView and let the “epi-magic” take care of the rest.
Have already used the 40 ud tables. And the extended tables do not work correctly.
It is a very common practice to have values in a key field to differentiate data.
Use an in-trans data directive to set PM and use either call context data or client to tell the in-trans it’s a record created from your preventative_maint customization
1 Like
Sounds like what I need. Can you point me in the direction on how to do this?
Thanks
How on earth did you use all of them yowza!?
I’ve already given the direction, if you’re unsure how to execute I would point you to the customization guides. Do a run through on those. What I described is as basic as server side customizations can get.
Data-Directive in-trans directive for new records set field = PM
See if the customization ID is in call context client, I know assembly is. If not on the customization side set call context bpm data, maybe character01, to your customization ID and sent that along for the ride to the BPM directive to know what customization it’s being called from.
I have something very similar to this. I use a table for HR documents and use a couple of entry forms to enter them. I use a post processing method directive on GetANewUD17.
Mine’s fairly in depth but to give you the highlights that will help you.
I use conditional statements to determine which form entry it is coming from.
You can then use custom code to set the key field that you want. I highly advise making sure you that your key fields are unique. I use a UD field on the JCSyst table for this that is an integer that I increment and use for the first key.
var ttUD17Row = ( from row in ttUD17
where row.RowMod == "A"
select row ).FirstOrDefault();
if(ttUD17Row != null)
{
var jcSystRow = ( from JCrow in Db.JCSyst
where JCrow.Company == callContextClient.CurrentCompany
select JCrow ).FirstOrDefault();
if(jcSystRow != null)
{
ttUD17Row.Key1 = jcSystRow.HRDocNum_c.ToString();
ttUD17Row.Key2 = "2";
jcSystRow.HRDocNum_c++;
}
}
In my case, Key1 is the integer that I am incrementing to make sure my key is unique.
Key2 is set to “2” on if this is called from the “Attend” customization. Then when I query this database, those with Key2 set to “2” apply for Attendance documents. (“3” is Time Off Requests, etc.)
Hope that helps.
For example I use UD table for custom configurators. We have a dozen or so. Each configurator will have 10 or more drop down boxes to configure the product. These are all table data which items can be added to when needed. Thus 1 configurator uses just 1 ud table instead of 10 or more. If everything was a separate table I would be using 100’s…
Thanks
I don’t use configurator, so forgive my ignorance, but isn’t that was the configurator lookup table is supposed to be for?
Oooooh, the PCLookup is nasty and slow. Each record in there is a “cell” in a “PC Table”. So when you want a “row”, you find the cell that you want the row of and then make another call to get all of the columns that match that roll for that table for that configurator. 