I’ve been tasked with adding a field to the part transaction table which only gets touched when the Issue Material screen is used.
I’ve seen people on here frown upon the use of ud fields on transaction tables and was wondering why that is and what could go wrong with transaction table ud fields?
Because they’re the largest and most frequently used tables in the system and adding a UD column to each row is therefore the most expensive UDF you can make. You even have to be careful with BPM’s, because they’re going to get called all the time. You actually have to understand what’s going on under the hood, which is unlike 99% of the system where you can throw trash-tier code at the problem and it will still work well enough that users won’t notice.
Also, I’ve yet to see a scenario that would justify it. Like…why do you even need this? You know who used Issue Material, because the transaction will be STK-MTL.
Welcome @fnasoetion!
I will heartily second everything @jtownsend says. Adding additional complexity to the already-most-complex processes in Epicor is begging for trouble.
Let’s look at this another way. What are you trying to do, what data are you hoping to capture, and how will that data be used afterwards?
This is a perfect opportunity to use a tag.
Glad to be here @Ernie!
I am trying to add a text field on the issue material screen.
The user will type in a code which would be a reference number for that batch of material, which usually comes from the supplier.
The data should then display in the material transaction grid in job tracker.
I’ve been able to achieve this by binding a text box to a CallContextBpmData.Character01 and then using a data directive to update the ud field on the part transaction.
I’ve seen Part lot or using a ud table as alternatives, but haven’t found a resource that explains how to set those up or what implications it may have to use them.
Like a Lot Number? 
So yes, this would be part of the Lot functionality. On the Part Entry screen, there is a checkbox for “Track Lots”. Once enabled, every movement of that part will require that the appropriate Lot Number be entered. When a PO Receipt is entered for a Lot Tracked material, the Lot must be created, and optionally any of several characteristics of that lot (Batch Number, Heat Number, Expiration Date, Manufacture Date, to name only some) also must be entered as well. They are forever stored with that Lot Number, so they can be looked up later.
It is a very common functionality. What version are you on so I can guide you to more extensive information?
My version is 10.2.700.
After looking into lot tracking, it seems like it would be too big of a change to implement within our organization.
Would creating entries in an unused ud table with the part tran number as the key be a solution?
I’m not sure why lot tracking would be that much of a change. It’s not global. It’s per part.
The system will do all the dirty work for you.
You receive it with a lot number, you issue it with a lot number.
I agree with @klincecum… and if you create custom fields and processes that duplicate an existing process, it will be even harder down the road to move away from what you’ve created back to the out-of-the-box process (which, I would bet the ranch is what you’ll eventually need to do). Yes, turning on Lot Tracking affects a lot of people and processes, but it needs to because you’re documenting more data that travels throughout the organization.
Please reconsider.