W_AR_XACT_F vs W_AR_AGING_INVOICE_A - (Receipt Number column in particular)

OBIEE_Drool

Hello,

Well, as you all know OOTB Aging Snapshot Aggregate Fact Tables are done at a month level (month bucket level OOTB to be precise) on top of base fact table. Here in discussion, I would like to bring up 2 such widely know tables for Fin - AR. They are W_AR_XACT_F (Financials - AR Transactions subject area) vs W_AR_AGING_INVOICE_A (Financials - AR Invoice Aging subject area) tables.

Question: Why is that we don't have all columns brought into W_AR_AGING_INVOICE_A from W_AR_XACT_F in PLP phase? Is it to avoid lower granularity level so that the aggregation stays at the level we want (which is month bucket level OOTB)?

The only reason I am asking this is to understand what happens if I want to pull Receipt Number column (REC_NUM) into W_AR_AGING_INVOICE_A table while populating from W_AR_XACT_F table in PLP Phase?

Any thoughts are appreciated. Pardon me if its a basic question of understanding.

Thanks.

Thomas Dodds

The base fact and the snapshot server two different business purposes ... they might both contain AR subject data, and on might be populated using the other, but they are distinct.  If you change the grain of any table, then be prepared to have to rework the RPD and possibly the front end (avoid granularity changes in OOTB tables) -- at that point you are better off pursuing a new table WC_AR_AGING_INVOICE_A where the WC_ indicates you've got a custom warehouse table going.

Specific to Receipt Number - if it's not a WID (warehouse generated key) and it won't add rows (ie: 2 or more REC_NUM per WID granularity) you should be ok to add it.  I would note that you probably should add it as X_REC_NUM that way in the future you are clear it wasn't there OOTB (it's a custom column).