Anda di halaman 1dari 5

DTA Architecture:

The data from QDF Curr\Hist is loaded into zero_level_fact table after arranging data in aggregation and
in hierarchies. Next step the data would be populated in cubes from the fact table and reports will be
generated by hitting the Cubes.

Here in DTA Reports are classified in to two types

1. Static Reports
2. Dynamic Reports

Static Reports:

1. Based on the filtered condition, the data would be fetched from the cube database and it would
be displayed in reports. We can be saved locally the reports and can access the report at any
time without hitting to the Server.
2. The layout of the report is fixed.
3. The saved reports can be attached in email shared with all intended users.
4. These are generally intended for the users working offline.

Dynamic Reports:

1. The report is generated every time by hitting the server with the filtering conditions.
2. Pivot functionality is available in this reports.
3. Directly report is refreshed/generated by user
4. Both hierarchies and columns/measures are available to be pulled into report.

Based on the Sales data the reports are categorized as follows.


ID REPORT NAME TYPE

R9 Report Indirect Shipments All details Sellout static


R10 Report Indirect Shipments by Geography Sellout dynamic
R11 Report Indirect Shipments by Stores Sellout dynamic
R12 Report Indirect Shipments by PSKU Sellout static
R23 Report Daily Indirect Shipments - All Sellout – Static
details

R23_-_Report_Daily_Indirect_Shipments__-_All_details:

This report contains the static data and the displaying the data of the reports would be changed
based upon the filtered conditions.

Refer the following Examples.


Examples:

Daily Indirect shipment by Branch:

The report would be displayed at distributor level with the selected period for measure of
Statistical Unit.

Daily Indirect shipment by Sku:


The report would be displayed at product level with the selected period for measure of PU.

LA Data Flow.

It contains basically for layers

1. Source data
2. Global Data
3. Local Data
4. SASS reporting

The data from the file would be loaded in to two different target system

a. Regional Target Lookup Table (Global)

b. Local Target Lookup Table

Please refer the following the Diagram for the flow.

1. The Product, Customer, Trade channel and Distribution dimensions are created in Global
schema by pulling the reference data from the RDS server.
2. Next the related data will be stored in the Local Database based on the smart selection of
dimensions based on the SMDFCT.
3. The cubes would be populated from the Local database with the limited data.

Level Zero Fact Load:


Following are the Level Zero facts that would be populated for LA region. The data would be sourced
from the Base Facts. The derivations would primarily be aggregations and deriving of required flags.

Entity Name Description

ISIS_LA_PR_SALES_SFCT Derived Fact for Sales Data at FPC level


ISIS_LA_DIST_DAY_DFCT Derived Fact for Sales Data at EAN level at day level
ISIS_LA_DIST_MTH_DFCT Derived Fact for Sales Data at EAN level at month level
ISIS_LA_DIST_P1M_DFCT Derived Fact for Sales Data at EAN level at month level for P1M
ISIS_LA_DIST_P2M_DFCT Derived Fact for Sales Data at EAN level at month level for P2M
ISIS_LA_DIST_P3M_DFCT Derived Fact for Sales Data at EAN level at month level for P3M
ISIS_LA_DIST_P6M_DFCT Derived Fact for Sales Data at EAN level at month level for P6M
ISIS_LA_SX_DFCT Derived Lookup for Store Master data
Derived Lookup for Store mater data and P3M sales data based on
ISIS_LA_SXGT_P3M_DFCT
global target
Derived Lookup for Store mater data and P3M sales data based on
ISIS_LA_SXRT_P3M_DFCT
regional target
Derived fact for sales at EAN level at month level based on regional
ISIS_LA_DIST_RT_DFCT
target
Derived fact for sales at EAN level at month level based on global
ISIS_LA_DIST_GT_DFCT
target
ISIS_RT_LKP Derived lookup for regional target
ISIS_GT_LKP Derived lookup for global target

By taking the data from QDF tables Synonyms will be created to derive the different products, supv code
based on the sales Rep code after doing aggregation of data at Prod_EAN level, which will be loaded into
Day level table ISIS_LA_DIST_DAY_DFCT.

Aggregation of Sales data :


Input – Sales Transaction Data – QDF_CLSS_IDENG (CURR/HIST)
Output – Aggregated Sales Transaction Data – ISIS_LA_PR_SALES_SFCT
Processing – For Coverage reporting derived fact table, input sales transaction data will be aggregated at
store level. The data in sales consists of net sales value of the transactions at day level. Geo id is derived
using lookup on use ISIS_SH30_CUST_677_LKP mapping the customer_id to distributor branch id.
Unknown codes are assigned to dimensions which are not a part of RDS hierarchy.Some additional filters
that are applied to QDF sales are
attr_val_10 = 1, fact_type_code = 'ID',attr_val_6 = 'N',( NVL (net_val_tc, 0) <> 0
OR NVL (vol_stat_unit, 0) <> 0
OR NVL (vol_base_unit, 0) <> 0.
Population of composed products is also done.

Aggregation of Sales data At Day level


Input – Sales Transaction Data – ISIS_LA_PR_SALES_SFCT
Output – Aggregated Sales Transaction Data – ISIS_LA_DIST_DAY_DFCT
Processing – For Distribution reporting derived integrated fact table, input sales transaction data will be
aggregated at PROD_EAN level. It will hold sales data at day level. PROD_EAN is derived for all the
countries for which PROD_DUN is derived for GCAS mapping by joining in prod_id.

Aggregation of Sales data At Month level


Input – Aggregated Sales Transaction Data at day level – ISIS_LA_DIST_DAY_DFCT, ISIS_LA_SX_DFCT
Output – Aggregated Sales Transaction Data at month level – ISIS_LA_DIST_MTH_DFCT
Processing – For Distribution reporting derived integrated fact table, input sales transaction data will be
aggregated at month level. It will hold sales data at month level. Month level will be reported only for
those months which are present in store master for that month

Anda mungkin juga menyukai