PTP Spend Analysis
-
Upload
babloo123456 -
Category
Documents
-
view
22 -
download
6
description
Transcript of 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)
2LIS_02_SCLPurchasing Data(Schedule Line
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
ZSP_PUR_EKKNPurchase Order
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
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZOSPLDTL
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
Acct Mapping
Spend Analysis
ZMPURSPND
Enhancement
YTLEATitle SL
(Line Item)
SpecialLedgerDetail
InfoCubeDoc Types: ZS , KR Doc Types: JZ, ZG, JG, JH
SPL Design Change
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZOSPLDTL
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
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 .
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
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 .
ZSP_PUR_EKKNPurchase Order
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
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
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)
ZSP_PUR_EKKNPurchase Order
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
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
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)
ZSP_PUR_EKKNPurchase Order
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??
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
True delta Delta Delta
Full Load
Delta
ZPUREKKN ZPUR_O01
New ODS
ZCPURSAPP
New ODS for Sending Change Document to Cube
•Proposed Design for (Delta + EKKN Changes )option-III(ED)
ZSP_PUR_EKKNPurchase Order
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
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKO
EKPO
EKKO
EKET
Delta Delta
ZPUR_O01
ZCPURSAPP
New ODS for Sending Change Document to Cube
•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
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Delta Delta
ZPUR_O01
ZCPURSAPP
•Option II(IRD): Master Data.
ZSP_PUR_EKKNPurchase Order
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
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Existing Design Including Spend and Committed and Location Accounting
ZSP_PUR_EKKNPurchase Order
AccountAssignments
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZOSPLDTL
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
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
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Initial Design Including Spend and Committed and Location Accounting
ZSP_PUR_EKKNPurchase Order
AccountAssignments
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZOSPLDTL
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
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
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Existing Design Full Flow (Change option Suggested based on Change in SPL Stream)
ZSP_PUR_EKKNPurchase Order
AccountAssignments
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZOSPLDTL
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
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
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Existing Design Suggestion Change Option I
ZSP_PUR_EKKNPurchase Order
AccountAssignments
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
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
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
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Existing Design Suggestion Change Option II
ZSP_PUR_EKKNPurchase Order
AccountAssignments
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZOSPLDTL
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
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
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 .
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Existing Design Suggestion Change Option III
ZSP_PUR_EKKNPurchase Order
AccountAssignments
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
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
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 .
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Existing Design Suggestion Change Option IV
ZSP_PUR_EKKNPurchase Order
AccountAssignments
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
Ledger
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
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 )
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Existing Design Suggestion Change Option V
ZSP_PUR_EKKNPurchase Order
AccountAssignments
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZOSPEND
ZSPL_DTLSpecial Purpose
Ledger Detail
Generic DataSource on Ytlea or
Bseg
YFR1CAT_GL_COMCD,YFR1CAT_PORG_CCD,Commodity Code to GL
Acct Mapping
SpendAnalysis
ZMPURSPND
Enhancement
Doc Types: ZS , KR Doc Types: JZ, ZG, JG, JH
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 .
ZSP_PUR_EKKNPurchase Order
AccountAssignments
EKKN
ZPUR_SAPPO SpendAnalysis Data from SAP
infoset(Inner join betweenZPUR_O01 andZPUREKKN)
SAP PODetails
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
2LIS_02_ITMPurchasing Data(Document Item
Level)
2LIS_02_SCLPurchasing Data(Schedule Line
Level)
EKKN EKKO
EKPO
EKKO
EKET
Full Load Delta Delta
Full Load
ZPUREKKN ZPUR_O01
ZCPURSAPP
Existing Design Suggestion Change Option For Change in Custom Table VI
ZSP_PUR_EKKNPurchase Order
AccountAssignments
Spend andCommitted /Non-PO
LocalAccounting /Non-SAP PO
ZSPL_DTLSpecial Purpose
Ledger Detail
3FI_SL_YT_SIDetailed Line
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 .