I need to save a UD Code into a table on Quote Entry. I thought the obvious place to put my UD column was in QuoteOpr. The field represents a classification of OSS, which will be used for pulling in costs from a UD table, by way of a yet-to-be-made BPM. I was surprised to find out that QuoteOpr was not in the list for binding to my custom control. Should I just use JobOpr?
Any [other] advice on this challenge? Thanks!
Justin,
When I went into the Classic version, customization mode, and clicked on other fields on the Operations/Detail tab, they all showed the binding to JobOper - so you should be using that. I never noticed that before. As a reminder, while the rule of thumb is the EpiBinding “table name” matches, the actual SQL table, that’s not always true. I’m not sure why Epicor used the JobOper as the binding name in Quote Entry - probably a leftover from old Vantage 3 days would be my guess.
This seems odd. I wonder what the JobNum will be… like, how will I identify this record in a BPM? Diving in to see. Thanks!
Really confused. I bound the control to JobOper.OSSType_c. I can open a quote and save a value, but can’t find it in a BAQ. Field Help never done me wrong like this…
It also has the same value for every Op in the Quote.
QuoteOpr isn’t available for direct binding in the Quote Entry screen, even though it exists in the database. This is because Epicor doesn’t expose it as a bindable datasource in the UI layer by default. JobOpr shouldn’t be used as a substitute, since it’s tied to the Job Entry module and not related to quotes.
The best approach is to add a UD field to QuoteOpr using Extended UD Table Maintenance, then use a BPM or Function to write to it. In the UI, you can place a custom control and trigger the update through scripting or event logic, even without binding. That way, the data gets stored correctly and remains available for downstream logic like cost retrieval.
Shouldn’t I be able to make QuoteOpr bindable by adding it to the customization with Data Tools? Currently struggling to understand how the FKVs work (it’s disrespecting my inputs and replacing them with whatever it feels like, it seems). I thought I was getting somewhere, but then my QuoteOpr table appeared in the bindings with QuoteHed fields.
I ran your scenario through our AI tool, (still in beta testing). And this is what it returned…sometimes it’s right on the money and sometimes not. That’s why it’s still in beta, it hallucinates on the SQL fields occasionally but it’s close. 
Let me know if it helps:
You can make QuoteOpr bindable in a customization using Data Tools and Application Studio (or Classic Customization), but there’s a key detail that often trips people up: you have to manage the foreign key view (FKV) linkages properly, or the binding context gets confused.
If you’re seeing QuoteOpr show up with QuoteHed fields, that typically means the FKV was added, but the relation path wasn’t established correctly, so it’s defaulting to a parent-level binding.
Here’s how to get it working cleanly:
The key takeaway is: yes, it’s totally possible, but you must steer Epicor’s FKV assumptions and rewire the relationships if the default is pointing at the wrong table like QuoteHed.
QuoteOpr is in its own dedicated menu item now in Kinetic, quote engineering (or something like that, on my phone). Your UD column will be available there to bind to a control. Classic was a lot cleaner how it was all shown within the quote screen
Still stuck on this classic Ux customization.
An AI helper is suggesting that I modify extended properties so that QuoteDtl.QuoteNum and QuoteLine are “like” the corresponding QuoteOpr fields. I’m really unclear on how this should look as well, if it’s even the right path.
