No…just type the field correctly
Just setting the expression to:
ttOrderHedRow.BidMargin_c
yields
EDIT: that expression is what I get by double clicking the field in the Available Variables pane.
Hmm, so you added the field in Extended UD Table Maintenance, regenerated the data model, and then recycled IIS correct?
Yes. but by “Recycled” I did it in the EAC. Not via ISSRESET on a command line.
From the help:
Emphasis on “May be able to” …
I would have interpreted that as the compiler not knowing the type of the field, but you probably know better than I do. In which case I’m out of ideas, sorry! I’ve yet to have all three versions fail.
It is certainly very odd that the editor allows you to select those fields and then still complains. The fact that they’re showing up surely means that the data model regeneration has done its job? We’ve never had to do an IISRESET for that, though now we have more than one app server we do have to do it in both.
In extended table maintenance, does it show that the OrderHed table is in sync?
Yup
Hmm, this is weird. Can you try regenerating the data model again and do the IIS recycle? I’ve seen weird things before with the data model regen…
I can add standard fields. But even other UD fileds (ones added years ago) give me the same error.
What if you assign those fields to BPM variables first, then try to do the math with the variables instead of the fields directly?
One last throw of the dice before I have to leave my desk:
ttOrderHedRow.UDField<System.Int32>(“BidMargin_c”)
Aren’t you going to get screwed up using integers? This should be decimals shouldn’t it?
Maybe - the integer bit was an assumption based on the earlier parts of the thread. <System.Decimal> if that’s what the field is.
2 Likes
@Banderson
Same thing. Get the “OrderHed TempRow does not conatins …” error
@dhewi - I’m in the process of re-regenerating the data model. I’ll try that after it’s done.
To All
To be clear…
- This is an In-Tran Data Directive.
- The Data Model has been regenerated
- The App Pool IIS was cycled via EAC
After second regen and IIS Cycle, the problem still exists …
So instead of a DD … How about a Method Directive?
But am I correct that a MD wouldn’t show the change on the UI, unit after the record is saved?
I think there is something else wrong, but not sure how to address it. In my environment, I am able to reference a custom field within a BPM with zero issues. But, to answer the other question, if you do a pre-processing MD, it should reflect on the UI after the method completes, assuming your data view is refreshed by that method.
@ckrusen
assuming your ttOrderHed.BidMarginPct_c is decimal type then i suggest to
remove the word ‘Row’ from the BidRevenue_c field name manually and see
also i suggest to do a simple math validation to avoid division over ‘zero’, this is a mathematical undefined value (Error), something like
if(ttOrderHed.BidRevenue_c = 0 then BidMarginPct_c = 0* or 100* else ttOrderHed.BidMargin_c/ttOrderHed.BidRevenue_c)
//*depends on your definition of this revenue percentage function
The divide by zero was taken care of in a prior condition block.
I found a solution. EDIT - even though someone had already posted it 
Contrary to the info in a guide that support sent me “Epicor ERP C# Programming Guide (conversion from ABL ) 10.1”
Point 3 should have worked. But gives me my original error.
Point 4, which says is for Method Directives, does work. I ended up using
ttOrderHedRow.UDField<System.Decimal>("BidMargin_c")
Note I did have to include ‘Row’ in the tt table name.
Updated to give credit to @dhewi for posting the solution - even though I was too stupid to realize it.
3 Likes
This is interesting, thanks for confirming the solution! (I don’t need credit for it, your explanation would be more useful for anyone finding this topic later).
I suspect the difference is not so much between types of directive, but whether you’re operating on a ttTable or a ttTableRow, and that isn’t necessarily very obvious within any given directive - does that make sense to you as a possibility? Where I’ve had to use this syntax particularly has been in updateable BAQs where rows are typically dealt with one by one and it’s the Epicor pattern, and noticing the ttOrderHedRow in your code made me think of that.
Anything which helps me get more of a clue to the way Epicor works, which is often not the way it looks like it works, is very welcome.
3 Likes