ptp spend analysis

PTP Spend Analysis

Design Approach and Research Findings

Agenda

• Background • Purchase Order Stream design approach

analysis and Conclusion• Special ledger stream Design approach

and Conclusion• Special ledger User Exit Performance

Tunings option and Conclusion based on Special ledger Stream decision

Design /Architecture Team Initial Design :(Mar-June 2004)• Data Architect : Tam Doan (IBM)- BW Team Lead• Data Modeling/BW technical Support : Rajeev Kumar (IBM)• Data Modeling: Sujata Ghosh(Sony)

July-Till November 2004:• Data Architect : Tam Doan (IBM)– BW Team Lead• Data Modeling: Sujata Ghosh(Sony)/Arjun Kamarsu

January 2005–Till Date:• Design and Architecture Discussion : Rajeev Kumar IBM)• BW technical Data modeling : Rajeev Kumar IBM)• BW technical Data modeling : Arjun Kamarsu(Sony)

Existing Design

Data TargetLevel 2

Data TargetLevel 1

Data TargetLevel 3

R/3 Data

SEM Data

LEGEND

Delta-EnabledExtractor

Custom Extractor

R/3 DataSources

Project STAR Financials BW Spend Analysis - Data Flow Diagram

Business Explorer Reports BEX Reports

2LIS_02_ITMPurchasing Data(Document Item

Level)

2LIS_02_SCLPurchasing Data(Schedule Line

Level)

Purc

hase

Ord

er D

ata

SpendAnalysis

CustomEnhancements

Spend Analysis

Spend andCommitted /Non-PO

3FI_SL_YT_SIDetailed Line

Ledger

Potential ODS objectsin design

YTLEATitle SL

(Line Item)

EKKOEKPO

EKKOEKET

Spec

ial L

edge

r Det

ailOD

S Ob

ject

SAP PODetails

InfoCube

ReportingLayer

LocalAccounting /Non-SAP PO

MultiCube

Master Data

InfoSources 2LIS_02_ITMPurchasing Data(Document Item

Level)


Level)

ZSPL_DTLSpecial Purpose

Ledger Detail

Data TargetLevel 4

Data TargetLevel 5

YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL

Acct Mapping

ZSP_PUR_EKKNPurchase Order

AccountAssignments

Purc

hasin

g Ac

coun

tAs

signm

ents

EKKN


AccountAssignments

ZPUREKKN ZPUR_O01

ZCPURSAPP

ZPUR_SAPPO SpendAnalysis Data from SAP

infoset(Inner join betweenZPUR_O01 andZPUREKKN)

ZMPURSPND

ZCPURSCNP ZCPURLANS

ZOSPLDTL

Purchase Order Stream

Special Ledger Stream

Existing Design Scalability For Special ledger Stream

• In production System I tried to fetch PTP Specific Data data from Special ledger stream (SPL ODS) and it took 10-15 minutes from 140 million records existed in SPL ODS .

Root Cause

Hurdle faced to make the design operational

• Special ledger stream being a business critical stream after Go live and Spend analysis was not high priority for user .

• Special Ledger Stream ODS Data (Duplicate data and unavailability) unavailable for making the PTP Stream operational .

• Minutes of final Decision sessions not available based on that design went into production .---Which resulted Design session after Go Live .

Precautionary Action and measure taken

• Researched the design and Documented all aspects and Assumption on which design is working .

• Researched and Documented all action items and points suggested in last 2 Design review session.

• Effort to document all minutes of decision making session to avoid Duplicate effort in future .

Reason for PTP design Session-I

• During the Architecture/Design change for Special ledger Stream ODS was removed from Architecture may be due to some performance reason .

• PTP Stream was not productional as it was leveraging some data from SPL ODS which is not having data in production.

New Design of Special Ledger

Existing PTP Stream is Leveraging some Data from SPL ODS



ZOSPLDTL


Ledger Detail


Ledger


Acct Mapping

Spend Analysis

ZMPURSPND

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCubeDoc Types: ZS , KR Doc Types: JZ, ZG, JG, JH

SPL Design Change



ZOSPLDTL


Ledger Detail


Ledger


Acct Mapping

Spend Analysis

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCubeDoc Types: ZS , KR Doc Types: JZ, ZG, JG, JH

Design Session -I• Design Review Session 1:• BW - PTP (Spend Analysis)Design Review Meeting held on February 9, 2005

at 10.00 am in Hayden 2252:• Attendees:• Ravi Patel• Arjun Kamarsu• Rajeev Kumar• Madhu Kolli• Sandeep GuptaAgenda1. Review BW design for PTP Spend Analysis reporting stream2. Explanation of all enhancements on the R/3 associated with SPL Detail

and Purchasing3. Explanation of the data flow and model of the Purchasing stream and SPL

Detail stream at each level of the flow4. Explanation of how the information is consolidated in BW5. Explanation of why the information is consolidated as per design in BW

Background Agenda and Key Decision

• Background: The PTP spend analysis reporting stream was developed but could not be made product ional since go live. Some reasons for this stream not being product ional were:

• 1. One of the data sources for this stream was SPL Detail ODS and this ODS had duplicate / bad data due to data load errors

• 2. Other reports like Projects & Overheads, Special ledger reports were more critical and the team was focused on resolving issues around them

• 3. The Spend report was not required by the users immediately after go live• While discussing ways to make this stream product ional, the team had several design

conversations and it was decided to have a design review session to go over the design & rationale behind the design.

• Key Decisions• The BW design for PTP Spend Analysis reporting stream looks fine. 2 options were discussed to

make the reporting stream productional.• Option 1 was to see if the data currently obtained from the SPL Detail ODS can be

obtained from the SPL Detail Cube• Option 2, in case option 1 is not possible; to have a plan for reloading SPL Detail ODS with

accurate data • Naming Convention of the BW objects to be reviewed and changed if the convention is not

followed• User exit codes need to be commented where the comments are missing• The version 8 changes made in the system need to be documented in the functional specs.

Research finding and Discussion for additional points after -I Review Session

Arjun kamarsau:• 1. The data flow diagram needs to be revised. • The tables YFR1CAT_GL_COMCD and YFR1CAT_PORG_CCD are used as reference in the user exit to derive the Material Group and the Purchasing

Organization as these fields are not available in the YTLEA table. Hence the same are derived as these are required for the PO and these fields are filled in the Infosource. However, this could have been avoided as we are getting the PO's in a separate Infosource. Need to be researched as to how this can be achieved.

• 2. BSEG is a monster in R/3 and it grows at a rapid pace. When we query on this table, it can create performance issues for retrieving information and SAP has standard function modules to take care of this. I would prefer using this function module for getting information. An other advantage to this is flexibility. At a later stage, if there is a need to get additional fields, this would be easy.

• 3. Currently, the ODS has only one report AM20 (Special Ledger detail ODS data) and I am not sure of this is being used by any user. If this is taken care of, I do not see any necessity for having this ODS and deleting this ODS could be of great help in terms of loading data and other performance related issues.

• 4. There is some data which is being repeated for example in the SPL Detail. I do not see any reason for having the purchasing info stored in this cube as we can always have a multiprovider which reads the PO number from the SPL detail and can get the required information from the PO cube.

• 5. When we are not reporting out of the Spend and Committed Non-PO and Local Accounting/Non SAP PO cubes separately (we have one query using a multiprovider), to simplify issues, can we not combine the cubes and get the required information. This design would be more simpler and easy to maintain.

• 6. The standard naming conventions for the Infocubes are not followed and this needs to be changed.

• 7. A validation procedure with R/3 needs to be determined.Ravi Patel :1. a. Enhancements made to the SPL Detail datasource may not be necessary and should be researched to remove. This includes the

enhancement for YFR1CAT_GL_COMCD and YFR1CAT_PORG_CCD.2. b. Research the use of the standard delivered FM to read the BSEG table for the enhancement to the SPL Detail Datasource.3. c. Research the removal the existing SPL ODS - this creates a redundancy of data in the data warehouse.4. d. Research the removal of the extension of Purchasing information vendor and purchasing org in the SPL - FI Line Item stream.

Design Discussion -II2nd Design Review Session for PTP (Spend Analysis):9th March 2005 2:00 to 3:00 Pm, Hayden

Place 2225• BW - PTP (Spend Analysis)Design Discussion:• Invitees:• Arjun Kamarsu• Alex• Jamie Johnson• Ravi Patel• Sandeep Gupta• Madhukar Kolli• Soumen Ghosh• Tugutla Reddy• Harihara SrinivasanAgenda: • Explanation of the data flow and model of the Purchasing stream and

SPL Detail stream for at each level of the flow for new team .• Review of all key point discussion and research from 1st Design

review Session and to arrive at a conclusion to make Stream productional.

Action Item Points for Research after Discussion -II

• Testing and Research on possibility of change in account assignment details and impact on existing design .

• Confirming with user for the requirement of history preservation .

• Research on Extra code removal for PO details for RE and RN Document type and Confirm with the user cause after removing this from SPL data source User will not have the functionality of jump query except PO and POITM .

• Research on Decoupling the stream from SPL data source and impact for the same .

• Aggregation of data from SPL detail cube and using this data for Spend analysis multicube reporting .

Account Assignment EKKN Data Change

• Tested the Delta for data coming from EKKN for PO 4600000561(Change in account assignment details) .Since right now an additive delta for EKKN is coming based on AEDAT(Date on which the record was created) ,it will not accommodate any changes in delta apart from new PO created in EKKN table .

• Changes to any filed in EKKN Can capture only on full upload through EKKN .

• Here are the option and suggestion for the same .

• Full Load :

– If we want to capture the changes for EKKN table we need to disable the delta option for EKKN Data source and do a full load which will capture all changes in EKKN for account assignment .This decision will depend on Volume of PO in production .

• Production PO Assumption:– Currently we have 8000 PO Created in 4 months .– As per functional Team PO creation is 2000/Month .– Data After 5 Year at Existing Rate : 120,000PO– Data After 10 Year at Existing Rate : 240,000PO

• Delta Load with AEDAT(PO Creation Date):

– With Existing Pseudo Delta with AEDAT it will not Consider the changes occurred in EKKN for Existing PO this delta will capture EKKN details only for new PO created .


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET

Delta Delta

Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

•Existing Design Which Will Capture EKKN Changes Only for New PO Created in EKKN .


AccountAssignments

Pseudo before image Delta on AEDAT

Functional Decision for EKKN Changes

• EKKN Changes Facts in Production :In RPR I have seen that there are around 180

changes applied to EKKN table as of for all PO created which is around 2-5% of all PO .So in that case we need to take a decision that whether we want to capture the changes in EKKN for the same along with newly created PO .

No--- No Design ChangeIF Yes – Proposed Design ahead

Full Load

Delta Load


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET

Full Load Delta Delta

Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

•Proposed Design Which Will Capture EKKN Changes in Existing design (Option-I(ED)


AccountAssignments

Disable the Delta Option

Problem of Delta Load is still Existing if we go with this Solution.

Action Item for Decision-EKKN:

Full ---Yes

No ---Proposed delta Option for Existing Design

Data Assumption:Currently we have 8000 PO Created in 4 months .As per functional Team PO creation is 2000/Month .Data After 5 Year at Existing Rate : 120,000POData After 10 Year at Existing Rate : 240,000PO


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

Delta

ZPUREKKN ZPUR_O01

New ODS

ZCPURSAPP

New ODS for Sending Change Document to Cube

•Proposed Design for (Delta + EKKN Changes )option-II(ED)


AccountAssignments

Advantage: Problem of Ekkn Changes and Delta is Resolved .Existing Issue (Full Load twice) : Since we are having Info set which is having and outer join between ZOPUREKKN and ZPUR_O01 .

•So Due to Info set every time on Info set level it will join the full records and we have to do full load even if we are getting Delta from 1st level.

Why we are using Infoset??


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET

True delta Delta Delta

Full Load

Delta

ZPUREKKN ZPUR_O01

New ODS

ZCPURSAPP


•Proposed Design for (Delta + EKKN Changes )option-III(ED)


AccountAssignments

Advantage: Delta Can be achieved at data Extractor Level .Existing Issue (Full Load once) : Since we are having Info set which is having and outer join between ZOPUREKKN and ZPUR_O01 .

•So Due to Info set every time on Info set level it will join the full records and we have to do full load even if we are getting Delta from true delta Extractor.

Why we are using Infoset??

Make "true delta " extractor which can be achieved by writing a BW specific function module on top of the EKKN table which would make it delta enabled .

Report Records to Add from different ODS (Info set Substitute)

PO PO ITM PO Value Inv Amt PO Qty

A 10 100 100 100

B 10 100 100 100

PO PO ITM Assignment % Account Seq.

No.

A 10 100

B 10 40 1

40 2

20 3

PO PO ITM PO Value Inv Amt PO Qty % Assignment Account Seq.

no.

A 10 100 100 100 100 1

B 10 40 40 40 40 1

10 40 40 40 40 2

10 20 20 20 20 3

ZPPUR_O01 ZPUR_EKKN

Final Layout Required

Alex Query Regarding Infoset Design Session-II

Option –I(IS), ODS

PO PO ITM PO Value Inv Amt PO Qty % Assignment Account Seq.

no.

A 10 100 100 100 X X

B 10 100 100 100 X X

40 1

40 2

20 3

Not Possible as We have different Key in both ODS .

Option-II(IS)SAP BW Infoset Query

• It’s not possible cause in report we are having lot of navigational attribute which we will be using in report .

• Biggest Disadvantage of the info set query is that you will not have navigational attribute available to you for reporting purpose .

Option-III (IS)SAP ABAP Infoset • Its Left outer join for PO and PO ITM between 2 ODS .Which will

give the records for PO with account assignment details and without account assignment Details.

Analysis for clubbing the Data Parameter Option –I(IS), ODS Option-II(IS) ,

SAP BW Infoset Query

Option-III (IS) SAP ABAP Infoset

Final Result

Data merging

Not Possible Possible without Calculation

Possible without Calculation

Option-III (IS)SAP ABAP Infoset

Navigational Attribute

N/A Not Possible Can feed the Data in Cube to have navigational Attribute .

Option-III(IS) SAP ABAP Infoset

Data Source Creation

N/A Not Possible We Can Create Data source on ABAP info set for feeding another Data Target

Option-III (IS)SAP ABAP Infoset

Conclusion NO NO Yes Option-III (IS)SAP ABAP Infoset

Existing Data Clubbing design Approach is best optimal solution for this kind of situation.

Can we Replace Info set with Some New Design Change in existing Situation which Capture EKKN

Changes :Point for Assumption :

•Flexibility•Performance •Transformation / Calculation

SAP PODetails


Level)


Level)


Level)


Level)

EKKO

EKPO

EKKO

EKET

Delta Delta

ZPUR_O01

ZCPURSAPP


•Enhancement Option I(IRD): for Enhancing EKKN Data in LIS Extractor

Enhancement Of ,Account Assignment Details, Asset Number, Profit Center, GL Account , Cost Center, WBS Element, MPM Number into Append Structure MCEKPOBW for EKPO and Writing the user exit code to fill it .

Problem :Tested the Delta Extractor but it seems change in account assignment is not captured in Existing delta management .So In that Case even if we enhance Delta for EKKN details will be missing and we will not get correct Data.

EKKN

SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET

Delta Delta

ZPUR_O01

ZCPURSAPP

•Option II(IRD): Master Data.


AccountAssignmentsMaster Data

PO Master Data

Spend Analysis

DeltaMaking PO as Master Data and Following as Navigational Attribute :

Account Assignment Details, Asset Number, Profit Center, GL Account , Cost Center, WBS Element, MPM Number

Advantage :Simple Design Easy to Maintain

Disadvantage: All Calculation for Multiple Account Assignment will be carried out at Query Level. Performance of query will be affected .

Suggested by Hari/Ravi

Design Discussion -II

Not a Flexible Design for future performance .

Comparison of Exiting design with New Options .

• Comparison With Design Option I(IRD).1. In option I we will always miss the changes occurred in account assignment Details since change in

account assignment is not captured in Existing delta management .2. In Existing Design we can get the EKKN Changes by Full load and Can also make it Delta Enabled .

• Comparison With Design Option II(IRD).1. Poor query Performance: All Calculation for Multiple Account Assignment will be carried out at

Query Level. Performance of query will be affected which will keep on increasing as number of PO increase in Production and we will face the problem everytime we run the query but in existing Design it will be during loading the data that is one time a day or week.

2. We don’t have any contingency flexible option with master data design option if due to business decisions PO number increase /After 5 year down the line no of PO in production increase. In that case we have to go for new design .

3. With the existing Design if by the time or due the business decision PO in production is increased we can go for ODS Delta option or True Delta achieved by writing a BW specific function module on top of the EKKN table which would make it delta enabled .

Suggestion : Existing Solution with slight modification based on Functional Decision.

Analysis for Design Approach Parameter Enhancing LIS Option –

I(IRD)(Existing Design ) PO Master Data-

II(IRD)Final Result

Flexibility N/A Flexibility (Can be Delta Enable)

Non Flexibility :We cannot change Design even if PO volume increase in future

Existing Design

Performance N/A •One Time During Load.•Performance can be controlled as Delta load .

•Performance Every time user Run the query •Cannot be controlled without architecture change.

Existing Design

Transformation / Calculation

N/A At Cube Level Query Level Existing Design

Final SolutionSolution Based on decision Tree

Functional Decision for EKKN Changes to Capture No Yes No Design Change Proposed Solution for Delta and Full Loads

Remove the Pseudo delta in Existing Design (Option -1)

Optimal Solution

Delta True Delta

Full Loa

Make extractor True Delta

• Proposed Design for (Delta + EKKN Changes )option-II


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Existing Design Including Spend and Committed and Location Accounting


AccountAssignments



ZOSPLDTL


Ledger Detail


Ledger


Acct Mapping

Spend Analysis

SpendAnalysis

ZMPURSPND

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCube

Jump Query

For RE and RN Doc Type

Doc Types: ZS , KR Doc Types: JZ, ZG, JG, JH

Doc Types: RE, RN

Sap Invoice No.

FI Doc Type

Posting Date


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Initial Design Including Spend and Committed and Location Accounting


AccountAssignments



ZOSPLDTL


Ledger Detail


Ledger


Acct Mapping

Spend Analysis

SpendAnalysis

ZMPURSPND

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCube

Jump Query



Doc Types: RE, RN

Sap Invoice No.

FI Doc Type

Posting Date


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Existing Design Full Flow (Change option Suggested based on Change in SPL Stream)


AccountAssignments



ZOSPLDTL


Ledger Detail


Ledger


Acct Mapping

Spend Analysis

SpendAnalysis

ZMPURSPND

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCube

Jump Query



Doc Types: RE, RN

Sap Invoice No.

FI Doc Type

Posting Date


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Existing Design Suggestion Change Option I


AccountAssignments




Ledger Detail


Ledger


Acct Mapping

Spend Analysis

SpendAnalysis

ZMPURSPND

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCube

Jump Query



Doc Types: RE, RN

Sap Invoice No.

FI Doc Type

Posting Date

Taking the Data Directly From SPL info source .

Reason and point to neglect the option is since we will be having one init going to different target .So both will be dependent and if for Some technical Reason like database lock error other stream will be affected


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Existing Design Suggestion Change Option II


AccountAssignments



ZOSPLDTL


Ledger Detail


Ledger


Acct Mapping

Spend Analysis

SpendAnalysis

ZMPURSPND

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCube

Jump Query



Doc Types: RE, RN

Sap Invoice No.

FI Doc Type

Posting Date

Make the ODS PTP Specific Since SPL is not using it

Reason and point to neglect the option is since we will be having one init going to different target .So both will be dependent and if for Some technical Reason like database lock error other stream will be affected

Suggestion: If we make it PTP Specific since same kind of data will be flowing in cube and ODS we can go with init into cube as well as ODS from Technical point of view .Data base issue can occur anywhere based on system state .


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Existing Design Suggestion Change Option III


AccountAssignments




Ledger Detail


Ledger


Acct Mapping

Spend Analysis

SpendAnalysis

ZMPURSPND

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCube

Jump Query



Doc Types: RE, RN

Sap Invoice No.

FI Doc Type

Posting Date

Suggestion:PTP Stream will be dependent on Special Ledger Details Cube .Since Special ledger Details cube is mission Critical than PTP Spend Analysis Assumption is that Data will be always available in the stream .We Can go with the Design if we are comfortable from Functional point of view as dependency .


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Existing Design Suggestion Change Option IV


AccountAssignments


Ledger Detail


Ledger


Acct Mapping

SpendAnalysis

ZMPURSPND

Enhancement

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCube

Doc Types: RE, RN

Spend Analysis

Create an aggregate on SPL Cube which is having All Data Enhanced For PTP Stream

Problem Faced :Validation for Spend analysis Not Possible filtering by Document type as accounting document field is not coming from PO Stream .

Validation may be possible by Source System which is a custom field created based on Cube and Data

• Validation: • documents where the GL account

equals one of accounts stored in table YFR1CAT_GL_COMCD

• Documents type equals : ZG , ZS, JG ,H, KR, JZ

Decoupling is never possible in future and Spend analysis will be Directly affected from SPL Stream cube (No work Around for reporting if SPL cube is down )


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Existing Design Suggestion Change Option V


AccountAssignments



ZOSPEND


Ledger Detail

Generic DataSource on Ytlea or

Bseg


Acct Mapping

SpendAnalysis

ZMPURSPND

Enhancement


Doc Types: RE, RN

Generic Data Source on Ytlea or Bseg

Doc Types: RE, RN

Merge Doc Types: RE, RN information with one of Existing Cube to remove Jump query .

Spend Analysis

•No dependency on SPL Stream

New Aspects for SPL

• Possibility of changing records in following tables. – YFR1CAT_GL_COMCD– YFR1CAT_PORG_CCD

• Note : Since User has Confirmed that it can be changed

• Please find the Design option Suggestion for the same .


AccountAssignments

EKKN



SAP PODetails


Level)


Level)


Level)


Level)

EKKN EKKO

EKPO

EKKO

EKET


Full Load

ZPUREKKN ZPUR_O01

ZCPURSAPP

Existing Design Suggestion Change Option For Change in Custom Table VI


AccountAssignments




Ledger Detail


Ledger

Spend Analysis

SpendAnalysis

ZMPURSPND

YTLEATitle SL

(Line Item)

SpecialLedgerDetail

InfoCube

Doc Types: ZS , KR

Doc Types: JZ, ZG, JG, JH Doc Types: RE, RN

ZSP_G/L master

YFR1CAT_GL_COMCD YFR1CAT_PORG_CCD

ZSP_G/l ZSP_COCode

YFR1CAT_GL_COMCD

YFR1CAT_PORG_CCD

ZSP_CoCodeMast

Dependency Cannot be removed from SPL Stream we have to take Data either from SPL Detail Cube of ,make SPL ODS PTP Specific for the same .

Extra Code Removal for PO details for RE and RN from SPL user Exit

• We can create use Jump query as a sub query which will Pass the value data set for finance data (Accounting document number ,FI Document type, Posing Date) by Replacement path in that case we don’t have to Jump on another query .In that way we can remove the code from SPL user Exit for Additional PO details which is currently providing the functionality to jump from main query to jump query for PO details like material group .

Solution Based on Priority • Design for Change in custom table : Existing Design

Suggestion Change Option For Change in Custom Table VI( Advantage: Extra User enhancement removal from existing SPL Stream)

• With User Exit + dependency on SPL Stream : Existing Design Suggestion for Change Option I,II and III.

• With User Exit in SPL Stream + Strong Dependency + Validation on query Level for Custom Defined filed which is populated manually + Aggregate :Existing Design Suggestion for Change Option IV

• Decoupling and Removing User Exit from SPL Stream :Existing Design Suggestion for Change Option V

Performance Option for SPL Extractor

• BSEG is a monster in R/3 and it grows at a rapid pace. When we query on this table, it can create performance issues for retrieving information and SAP has standard function modules to take care of this. I would prefer using this function module for getting information. An other advantage to this is flexibility. At a later stage, if there is a need to get additional fields, this would be easy.

Internal Table Solution and suggestion:• I have analyzed the code and into existing code also we are using all keys for fetching the data from Bseg

except one statement .So for existing code also from performance point of view we are using all primary key .

• Please find my research findings for more improvement for the same.• 1st Solution (Internal table):• I can declare an internal table for the following fields. • ITAB_BSEG,• KOSTL TYPE KOSTL , "Cost Center• ANLN1 TYPE ANLN1 , "Asset Number• LIFNR TYPE LIFNR , "Vendor• XREF2 TYPE XREF2 , "Vendor for PCARD• EBELN TYPE EBELN , "Purchasing document number• EBELP TYPE EBELP , "Item number of purchasing document• KOART TYPE KOART , "Account Type• RBUKRS• BELNR• RYEAR• BUZEI .• · Get the Bseg data for all document type and for all entries in C_T_Data. (Before LOOP into

C_T_DATA INTO W_C_T_DATA statement) in internal table .• Advantage: Use the internal table data for all derivation in code instead of calling Bseg every time.• Disadvantage: Since C_T_DATA will be having lot of data so it will not be good suggestion for this kind of

solution.

Work Area• 2nd Solution (Work area) :• · We will add some more fields in Existing work area as follows :• RBUKRS• BELNR• RYEAR• BUZEI .• Expected Data flow for the solution:• LOOP AT C_T_DATA INTO W_C_T_DATA .• For the following document type conditions. • IF • W_C_T_DATA-RZZBLART = 'ZG' "Local Accounting System• OR W_C_T_DATA-RZZBLART = 'ZS' "Spent and Committed• OR W_C_T_DATA-RZZBLART = 'JG' "JDE• OR W_C_T_DATA-RZZBLART = 'JH' "JDE• OR W_C_T_DATA-RZZBLART = 'KR' "SAP_NON_PO• OR W_C_T_DATA-RZZBLART = 'JZ' "PCARD• OR W_C_T_DATA-RZZBLART = 'RE' "Sap System• OR W_C_T_DATA-RZZBLART = 'RN'."Sap System• SELECT all corresponding data from bseg into Work area for bseg for the following • Conditions. • WHERE BUKRS = W_C_T_DATA-RBUKRS• AND BELNR = W_C_T_DATA-BELNR• AND GJAHR = W_C_T_DATA-RYEAR• AND BUZEI = W_C_T_DATA-BUZEI .Advantage: Need to fetch Bseg Data only once and in whole code I can use the same work area .Only required

field for existing requirement will be in work area so in that case we don’t pull unnecessary fields in program which is more effective performance point of view .

Disadvantage: We need to add filed in future if new field come in .

Function Module (Read_Bseg)• Functional Module Solution :• LOOP AT C_T_DATA INTO W_C_T_DATA .• For the following document type conditions . • IF • W_C_T_DATA-RZZBLART = 'ZG' "Local Accounting System• OR W_C_T_DATA-RZZBLART = 'ZS' "Spent and Committed• OR W_C_T_DATA-RZZBLART = 'JG' "JDE• OR W_C_T_DATA-RZZBLART = 'JH' "JDE• OR W_C_T_DATA-RZZBLART = 'KR' "SAP_NON_PO• OR W_C_T_DATA-RZZBLART = 'JZ' "PCARD• OR W_C_T_DATA-RZZBLART = 'RE' "Sap System• OR W_C_T_DATA-RZZBLART = 'RN'."Sap System• Call function module READ_BSEG for the following condition .• • WHERE BUKRS = W_C_T_DATA-RBUKRS• AND BELNR = W_C_T_DATA-BELNR• AND GJAHR = W_C_T_DATA-RYEAR• AND BUZEI = W_C_T_DATA-BUZEI .• Now I will have the XBseg Structure and I don’t need to fetch Bseg data for any other

condition .I can use this g XBseg line item for rest for data and derivation .

Comparative Analysis for Solution based on Performance and Flexibility

• Internal Table Solution is not suggested as we are expecting huge data in Extractor in that Case Internal table size will be big and SAP suggest that for huge data processing internal table solution is not good if we have some other optimal solution for the same .

• Work area solution is better than Function module for performance point of View but work area Solution will be more effective in terms of performance as we will have only required fields for the program. But in Function module Solution we will have all data of bseg into XBseg .

• Performance wise Work area solution will be better but If we use the standard SAP function module, if we need additional fields referenced at a later stage, we need not modify the code again and it’s a flexible Solution for future addition + performance point of view an effective Solution .