Does anyone have a good understanding of how the built-in RDD’s work? There seems to be a few aspects abou them that aren’t obvious to the average user. Things like:
It is not just a collection of tables, joins, and criteria. There is code being executed, to perform complex functions that straightforward query couldn’t do.
The Data Sources listed in the RDD maintenance, aren’t always a reference to a table in the main DB. Some have names that don’t have a corresponding table in the main DB. And some have names that have matching table name, but the fields may not be identical.
Data sources that include Calculated values maybe from complex calculations, and not just the type you can do in simple to moderate SQL.
And there’s probably more…
Lets take the OrderAck RDD for example.
There’s no table named OHOrderMsc in the Erp or Ice DB (that I know of). So I’m guessing that is a temp dataset created by code when the RDD is run.
Which leads to the questions:
Are these Datas Sources populated by code, and then the “table relationships” defined in the RDD applied to them? Or is it something else?
Does and RDD always generate a temp version of those data sources (the name with the GUID suffix)? And can those table have more data than you desire, and you just rely on the query expression in the RDL to do the final filtering.
It seems like the RDD generates these data sources (adding the GUID to their name) in the Report DB, but these are just subsets of data that need to be further refined by the RDL’s query expression. That correct?
Because OrderAck happens to be an RDD I have dealt with quite a bit, I have a little insight into it. The tables generally are the real tables, except for the calculated fields which do indeed have some hidden code to populate them. OHOrderMsc is likely OrderMsc with OrderLine = 0. The relationships are what determine what is pulled in recordwise. We have duplicated that one and added other tables and modified the relationships quite a bit for our UK company because they decided to make that report Customer facing and not just Salesperson facing like our other companies. The RDL only needs to filter when you modify the relationships, in general, the RDD seems to get just the data you need and the RDL doesn’t have to do much other than grab the fields.
You CAN modify the RDD so those temp tables contain more data, and we have done this in many cases, since RDD won’t let you use the same table more than one. Customer contacts are a big one for us, we generally have to pull in all the contacts for a given customer, then filter them in the RDL for soldto, billto and shipto since Epicor doesn’t handle it the way we need it to.
So yes, there’s a ‘black box’ behind those RDDs which does a lot of work, but you do still have some ability to manipulate the data.
(as a general rule, I dislike RDD immensely just for the reason that I can’t alias tables and use them again)
It has been a minute, but have you ever decompiled the .dll for the salesorderack?
I think decompiling it has helped me solve for calculated fields in the RDD, but I don’t know about calculated tables in the RDD, never looked through the decompiled assembly from that angle.
Have you already checked with Epicor support?
I don’t know if Epicor still maintains the knowledgebase articles for E10
but… upon request, they used to provide answerbooks for some of these RDDs with “weird” tables.
e.g. RDD WIPReport - table “TWip”.
Where support sent me answerbook 6135MPS (for V8, along time ago)
“JM Work in Process Report Notes” which was helpful at that time.
Helpful at that time…
