Adaptability
I can look for people who are flexible when things change. I can cope with changing demands, uncertainty and stress. I can remain calm and composed. I can demonstrate that I have successful completed several projects or assignments with competing deadlines.
--------------------------------------------------------------------------------
Teamwork & Collaboration
how I can do my work with others to achieve shared Business goals. I can make it respect
and value others' differences. I can easily build and maintain relationships with others. Do you offer support and help others and share your expertise with them to enhance the effectiveness of the team.
--------------------------------------------------------------------------------
Communication
This competency focuses on how I m communicate with others. I can present oral and written information clearly, precisely and succinctly. I can match the way i communicate with the requirements of the situation and my audience. I can pay attention to listen carefully to others, asking questions when necessary to ensure understanding.
--------------------------------------------------------------------------------
Drive to achieve
I need to be committed to success and accomplishing challenging goals. I can take the initiative to learn new skills that will be useful for my future career. I can learn about things beyond the
scope of your current job or assignment. I can prepare to put in as much additional time or effort as is necessary to ensure high quality results.
--------------------------------------------------------------------------------
Creative problem solving
this is all about using ingenuity, supported by logical methods and appropriate analysis, to propose solutions to problems. I can conduct thorough fact-finding and analysis, anticipating any potential problems and then plan accordingly. I can think 'outside the box' when proposing solutions to problems. I can put forward new ideas for activities at Client Business Reporting and consolidation or work and offer innovative ideas to overcome challenges.
--------------------------------------------------------------------------------
Client focus
I m deadly look client focussed organisation so I need people working with me who share this focus and can anticipate their needs and respond appropriately. I can't think about 'clients' just in the sense of 'customers' - clients' can also be colleagues, study groups, maybe even lecturers. I can build rapport quickly and easily and think about a situation from their point of view. Based upon Business requirement I can recommend solutions that meet their needs. I can initiate to act with their satisfaction as top priority.
--------------------------------------------------------------------------------
Passion for the business
this is all about being able to demonstrate a passion for our client Business Concern and the industry in which I operate. I know what does, and what recent achievements I have had. I can demonstrate knowledge of recent trends within the IT & Consulting industry. I can understand the message behind our current 'Smarter Planet” advertising campaign.
--------------------------------------------------------------------------------
Taking ownership
this is all about identifying and taking responsibility proactively for tasks and decisions in a timely manner. I can demonstrate when you’ve accepted responsibility for mistakes and worked to correct them. I can focus on resolving difficult situations rather than finding someone to blame. I can anticipate potential problems with a project and then plan accordingly, implementing decisions with speed, reliability and urgency.
Monday, November 23, 2009
My Abilities...
My Abilities...
Tuesday, July 28, 2009
How to improve FI_GL_4 data extract
When a Delta InfoPackage for the DataSource 0FI_GL_4 is executed in SAP NetWeaverBI (BI), the extraction process in the ECC source system mainly consists of two activities:- First the FI extractor calls a FI specific function module which reads the new andchanged FI documents since the last delta request from the application tablesand writes them into the Delta Queue.- Secondly, the Service API reads the delta from the Delta Queue and sends the FIdocuments to BI.
The time consuming step is the first part. This step might take a long time to collect allthe delta information, if the FI application tables in the ECC system contain many entriesor when parallel running processes insert changed FI documents frequently.
A solution might be to execute the Delta InfoPackage to BI more frequently to processsmaller sets of delta records. However, this might not be feasible for several reasons:First, it is not recommended to load data with a high frequency using the normalextraction process into BI. Second, the new Real-Time Data Acquisition (RDA)functionality delivered with SAP NetWeaver 7.0 can only be used within the newDataflow. This would make a complete migration of the Dataflow necessary. Third, as ofnow the DataSource 0FI_GL_4 is not officially released for RDA.To be able to process the time consuming first step without executing the deltaInfoPackage the ABAP report attached to this document will execute the first step of theextraction process encapsulated. The ABAP report reads all the new and changeddocuments from the FI tables and writes them into the BI delta queue. This report can bescheduled to run frequently, e.g. every 30 minutes.The Delta InfoPackage can be scheduled independently of this report. Most of the deltainformation will be read from the delta queue then. This will greatly reduce the number ofrecords the time consuming step (First part of the extraction) has to process from the FIapplication as shown in the picture below.
The Step By Step Solution4.
1 Implementation DetailsTo achieve an encapsulated first part of the original process, the attached ABAP report iscreating a faked delta initialization for the logical system 'DUMMY_BW'. (This system can be named anything as long as it does not exist.) This will create two delta queues for the0FI_GL_4 extractor in the SAP ERP ECC system: One for the ‘DUMMY_BW’ and theother for the 'real' BI system.The second part of the report is executing a delta request for the ‘DUMMY_BW’ logicalsystem. This request will read any new or changed records since the previous deltarequest and writes them into the delta queues of all connected BI systems.The reason for the logical BI system ‘DUMMY_BW’ is that the function module used inthe report writes the data into the Delta Queue and marks the delta as already sent tothe ‘DUMMY_BW’ BI system.This is the reason why the data in the delta queue of the ‘DUMMY_BW’ system is notneeded for further processing. The data gets deleted in the last part of the report.The different delta levels for different BI systems are handled by the delta queue and areindependent from the logical system.Thus, the delta is available in the queue of the 'real' BI system, ready to be sent duringthe next Delta InfoPackage execution.This methodology can be applied to any BI extractors that use the delta queuefunctionality.As this report is using standard functionality of the Plug-In component, the handling ofdata request for BI has not changed. If the second part fails, it can be repeated. Thecreation & deletion of delta-initializations is unchanged also.The ABAP and the normal FI extractor activity reads delta sequential. The data is sentto BI parallel.If the report is scheduled to be executed every 30 minutes, it might happen that itcoincides with the BI Delta InfoPackage execution. In that case some records will bewritten to the delta queues twice from both processes.This is not an issue, as further processing in the BI system using a DataStore Object withdelta handling capabilities will automatically filter out the duplicated records during thedata activation. Therefore the parallel execution of this encapsulated report with the BIdelta InfoPackage does not cause any data inconsistencies in BI. (Please refer also toSAP Note 844222.)
4.2 Step by Step Guide1. Create a new Logical System usingthe transaction BD54.This Logical System name is used inthe report as a constant:c_dlogsys TYPE logsys VALUE 'DUMMY_BW'In this example, the name of theLogical System is ‘DUMMY_BW’.The constant in the report needs tobe changed accordingly to thedefined Logical System name in thisStep.
. Implement an executable ABAPreportYBW_FI_GL_4_DELTA_COLLECTin transaction SE38.The code for this ABAP report canbe found it the appendix.
3. Maintain the selection texts of thereport.In the ABAP editorIn the menu, choose Goto TextElements Selection Texts
. Maintain the text symbols of thereport.In the ABAP editorIn the menu, choose Goto TextElements Text Symbols
5. Create a variant for the report. The"Target BW System" has to be anexisting BI system for which a deltainitialization exists.In transaction SE38, click Variants6. Schedule the report via transactionSM36 to be executed every 30minutes, using the variant created instep 5.
Code
This report collects new and changed documents for the 0FI_GL_4 from*& the FI application tables and writes them to the delta queues of all*& connected BW system.*&*& The BW extractor itself therefore needs only to process a small*& amount of records from the application tables to the delta queue,*& before the content of the delta queue is sent to the BW system.
*&---------------------------------------------------------------------*REPORT ybw_fi_gl_4_delta_collect.TYPE-POOLS: sbiw.* Constants* The 'DUMMY_BW' constant is the same as defined in Step 1 of the How to guideCONSTANTS: c_dlogsys TYPE logsys VALUE 'DUMMY_BW',c_oltpsource TYPE roosourcer VALUE '0FI_GL_4'.* Filed symbols.
FIELD-SYMBOLS:
DATA: l_slogsys TYPE logsys,
l_tfstruc TYPE rotfstruc,
l_lines_read TYPE sy-tabix,
l_subrc TYPE sy-subrc
,l_s_rsbasidoc TYPE rsbasidoc,
l_s_roosgen TYPE roosgen,
l_s_parameters TYPE roidocprms,
l_t_fields TYPE TABLE OF rsfieldsel,
l_t_roosprmsc TYPE TABLE OF roosprmsc,
l_t_roosprmsf TYPE TABLE OF roosprmsf.
* Selection parameters
SELECTION-SCREEN: BEGIN OF BLOCK b1 WITH FRAME TITLE text-001.
SELECTION-SCREEN SKIP
1.PARAMETER prlogsys LIKE tbdls-logsys OBLIGATORY.SELECTION-SCREEN:
END OF BLOCK b1.AT SELECTION-SCREEN.
* Check logical systemSELECT COUNT * FROM tbdls BYPASSING BUFFERWHERE logsys = prlogsys.IF sy-subrc <> 0.MESSAGE e454(b1) WITH prlogsys.* The logical system & has not yet been definedENDIF.
* Get own logical systemCALL FUNCTION 'RSAN_LOGSYS_DETERMINE'EXPORTINGi_client = sy-mandtIMPORTINGe_logsys = l_slogsys.* Check if transfer rules exist for this extractor in BWSELECT SINGLE * FROM roosgen INTO l_s_roosgenWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.
MESSAGE e025(rj) WITH prlogsys.* No transfer rules for target system &ENDIF.* Copy record for dummy BW systeml_s_roosgen-rlogsys = c_dlogsys.MODIFY roosgen FROM l_s_roosgen.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-002.* Update of table ROOSGEN failedENDIF.
* Assignment of source system to BW systemSELECT SINGLE * FROM rsbasidoc INTO l_s_rsbasidocWHERE slogsys = l_slogsysAND rlogsys = prlogsys.IF sy-subrc <> 0 OR( l_s_rsbasidoc-objstat = sbiw_c_objstat-inactive ).MESSAGE e053(rj) WITH text-003.* Remote destination not validENDIF.
* Copy record for dummy BW systeml_s_rsbasidoc-rlogsys = c_dlogsys.MODIFY rsbasidoc FROM l_s_rsbasidoc.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-004.* Update of table RSBASIDOC failedENDIF.
* Delta initializationsSELECT * FROM roosprmsc INTO TABLE l_t_roosprmscWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.MESSAGE e020(rsqu).* Some of the initialization requirements have not been completedENDIF.
LOOP AT l_t_roosprmsc ASSIGNING .IF -initstate = ' '.MESSAGE e020(rsqu).* Some of the initialization requirements have not been completedENDIF.-rlogsys = c_dlogsys.-gottid = ''.-gotvers = '0'.-gettid = ''.-getvers = '0'.ENDLOOP.
* Delete old records for dummy BW systemDELETE FROM roosprmscWHERE oltpsource = c_oltpsourceAND rlogsys = c_dlogsysAND slogsys = l_slogsys.
* Copy records for dummy BW systemMODIFY roosprmsc FROM TABLE l_t_roosprmsc.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-005.* Update of table ROOSPRMSC failedENDIF.* Filter values for delta initializationsSELECT * FROM roosprmsf INTO TABLE l_t_roosprmsfWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.MESSAGE e020(rsqu).
* Some of the initialization requirements have not been completedENDIF.LOOP AT l_t_roosprmsf ASSIGNING .-rlogsys = c_dlogsys.ENDLOOP.* Delete old records for dummy BW systemDELETE FROM roosprmsfWHERE oltpsource = c_oltpsourceAND rlogsys = c_dlogsysAND slogsys = l_slogsys.* Copy records for dummy BW systemMODIFY roosprmsf FROM TABLE l_t_roosprmsf.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-006.* Update of table ROOSPRMSF failedENDIF.
**************************************
COMMIT WORK for changed meta data
**************************************
COMMIT WORK.* Delete RFC queue of dummy BW system* (Just in case entries of other delta requests exist)CALL FUNCTION 'RSC1_TRFC_QUEUE_DELETE_DATA'
EXPORTING
i_osource = c_oltpsource
i_rlogsys =
c_dlogsysi_all = 'X'
EXCEPTIONS
tid_not_executed = 1
tid_not_executed = 1
client_not_found = 3
error_reading_queue = 4
OTHERS = 5.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.
********************************************
COMMIT WORK for deletion of delta queue
********************************************
COMMIT WORK.
* Get MAXLINES for data package
CALL FUNCTION 'RSAP_IDOC_DETERMINE_PARAMETERS'
EXPORTINGi_oltpsource = c_oltpsourcei_slogsys = l_slogsysi_rlogsys = prlogsysi_updmode = 'D 'IMPORTINGe_s_parameters = l_s_parameterse_subrc = l_subrc.
.IF l_subrc <> 0.MESSAGE e053(rj) WITH text-007.* Error in function module RSAP_IDOC_DETERMINE_PARAMETERSENDIF.* Transfer structure depends on transfer methodCASE l_s_roosgen-tfmethode.WHEN 'I'.
l_tfstruc = l_s_roosgen-tfstridoc.WHEN 'T'.l_tfstruc = l_s_roosgen-tfstruc.ENDCASE.* Determine transfer structure field listPERFORM fill_field_list(saplrsap) TABLES l_t_fieldsUSING l_tfstruc.* Start the delta extraction for the dummy BW systemCALL FUNCTION 'RSFH_GET_DATA_SIMPLE'
EXPORTINGi_requnr = 'DUMMY'i_osource = c_oltpsourcei_showlist = ' 'i_maxsize = l_s_parameters-maxlinesi_maxfetch = '9999'i_updmode = 'D 'i_rlogsys = c_dlogsysi_read_only = ' 'IMPORTING
e_lines_read = l_lines_readTABLESi_t_field = l_t_fieldsEXCEPTIONSgeneration_error = 1interface_table_error = 2metadata_error = 3error_passed_to_mess_handler = 4no_authority = 5OTHERS = 6.IF sy-subrc <> 0.MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.
*********************************
COMMIT WORK for delta request
**********************************
COMMIT WORK.
** Delete RFC queue of dummy BW systemCALL FUNCTION 'RSC1_TRFC_QUEUE_DELETE_DATA'EXPORTINGi_osource = c_oltpsourcei_rlogsys = c_dlogsysi_all = 'X'EXCEPTIONStid_not_executed = 1invalid_parameter = 2client_not_found = 3error_reading_queue = 4OTHERS = 5.IF sy-subrc <> 0.MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.* Data collection for 0FI_GL_4 delta queue successfulMESSAGE s053(rj) WITH text-008.
The time consuming step is the first part. This step might take a long time to collect allthe delta information, if the FI application tables in the ECC system contain many entriesor when parallel running processes insert changed FI documents frequently.
A solution might be to execute the Delta InfoPackage to BI more frequently to processsmaller sets of delta records. However, this might not be feasible for several reasons:First, it is not recommended to load data with a high frequency using the normalextraction process into BI. Second, the new Real-Time Data Acquisition (RDA)functionality delivered with SAP NetWeaver 7.0 can only be used within the newDataflow. This would make a complete migration of the Dataflow necessary. Third, as ofnow the DataSource 0FI_GL_4 is not officially released for RDA.To be able to process the time consuming first step without executing the deltaInfoPackage the ABAP report attached to this document will execute the first step of theextraction process encapsulated. The ABAP report reads all the new and changeddocuments from the FI tables and writes them into the BI delta queue. This report can bescheduled to run frequently, e.g. every 30 minutes.The Delta InfoPackage can be scheduled independently of this report. Most of the deltainformation will be read from the delta queue then. This will greatly reduce the number ofrecords the time consuming step (First part of the extraction) has to process from the FIapplication as shown in the picture below.
The Step By Step Solution4.
1 Implementation DetailsTo achieve an encapsulated first part of the original process, the attached ABAP report iscreating a faked delta initialization for the logical system 'DUMMY_BW'. (This system can be named anything as long as it does not exist.) This will create two delta queues for the0FI_GL_4 extractor in the SAP ERP ECC system: One for the ‘DUMMY_BW’ and theother for the 'real' BI system.The second part of the report is executing a delta request for the ‘DUMMY_BW’ logicalsystem. This request will read any new or changed records since the previous deltarequest and writes them into the delta queues of all connected BI systems.The reason for the logical BI system ‘DUMMY_BW’ is that the function module used inthe report writes the data into the Delta Queue and marks the delta as already sent tothe ‘DUMMY_BW’ BI system.This is the reason why the data in the delta queue of the ‘DUMMY_BW’ system is notneeded for further processing. The data gets deleted in the last part of the report.The different delta levels for different BI systems are handled by the delta queue and areindependent from the logical system.Thus, the delta is available in the queue of the 'real' BI system, ready to be sent duringthe next Delta InfoPackage execution.This methodology can be applied to any BI extractors that use the delta queuefunctionality.As this report is using standard functionality of the Plug-In component, the handling ofdata request for BI has not changed. If the second part fails, it can be repeated. Thecreation & deletion of delta-initializations is unchanged also.The ABAP and the normal FI extractor activity reads delta sequential. The data is sentto BI parallel.If the report is scheduled to be executed every 30 minutes, it might happen that itcoincides with the BI Delta InfoPackage execution. In that case some records will bewritten to the delta queues twice from both processes.This is not an issue, as further processing in the BI system using a DataStore Object withdelta handling capabilities will automatically filter out the duplicated records during thedata activation. Therefore the parallel execution of this encapsulated report with the BIdelta InfoPackage does not cause any data inconsistencies in BI. (Please refer also toSAP Note 844222.)
4.2 Step by Step Guide1. Create a new Logical System usingthe transaction BD54.This Logical System name is used inthe report as a constant:c_dlogsys TYPE logsys VALUE 'DUMMY_BW'In this example, the name of theLogical System is ‘DUMMY_BW’.The constant in the report needs tobe changed accordingly to thedefined Logical System name in thisStep.
. Implement an executable ABAPreportYBW_FI_GL_4_DELTA_COLLECTin transaction SE38.The code for this ABAP report canbe found it the appendix.
3. Maintain the selection texts of thereport.In the ABAP editorIn the menu, choose Goto TextElements Selection Texts
. Maintain the text symbols of thereport.In the ABAP editorIn the menu, choose Goto TextElements Text Symbols
5. Create a variant for the report. The"Target BW System" has to be anexisting BI system for which a deltainitialization exists.In transaction SE38, click Variants6. Schedule the report via transactionSM36 to be executed every 30minutes, using the variant created instep 5.
Code
This report collects new and changed documents for the 0FI_GL_4 from*& the FI application tables and writes them to the delta queues of all*& connected BW system.*&*& The BW extractor itself therefore needs only to process a small*& amount of records from the application tables to the delta queue,*& before the content of the delta queue is sent to the BW system.
*&---------------------------------------------------------------------*REPORT ybw_fi_gl_4_delta_collect.TYPE-POOLS: sbiw.* Constants* The 'DUMMY_BW' constant is the same as defined in Step 1 of the How to guideCONSTANTS: c_dlogsys TYPE logsys VALUE 'DUMMY_BW',c_oltpsource TYPE roosourcer VALUE '0FI_GL_4'.* Filed symbols.
FIELD-SYMBOLS:
DATA: l_slogsys TYPE logsys,
l_tfstruc TYPE rotfstruc,
l_lines_read TYPE sy-tabix,
l_subrc TYPE sy-subrc
,l_s_rsbasidoc TYPE rsbasidoc,
l_s_roosgen TYPE roosgen,
l_s_parameters TYPE roidocprms,
l_t_fields TYPE TABLE OF rsfieldsel,
l_t_roosprmsc TYPE TABLE OF roosprmsc,
l_t_roosprmsf TYPE TABLE OF roosprmsf.
* Selection parameters
SELECTION-SCREEN: BEGIN OF BLOCK b1 WITH FRAME TITLE text-001.
SELECTION-SCREEN SKIP
1.PARAMETER prlogsys LIKE tbdls-logsys OBLIGATORY.SELECTION-SCREEN:
END OF BLOCK b1.AT SELECTION-SCREEN.
* Check logical systemSELECT COUNT * FROM tbdls BYPASSING BUFFERWHERE logsys = prlogsys.IF sy-subrc <> 0.MESSAGE e454(b1) WITH prlogsys.* The logical system & has not yet been definedENDIF.
* Get own logical systemCALL FUNCTION 'RSAN_LOGSYS_DETERMINE'EXPORTINGi_client = sy-mandtIMPORTINGe_logsys = l_slogsys.* Check if transfer rules exist for this extractor in BWSELECT SINGLE * FROM roosgen INTO l_s_roosgenWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.
MESSAGE e025(rj) WITH prlogsys.* No transfer rules for target system &ENDIF.* Copy record for dummy BW systeml_s_roosgen-rlogsys = c_dlogsys.MODIFY roosgen FROM l_s_roosgen.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-002.* Update of table ROOSGEN failedENDIF.
* Assignment of source system to BW systemSELECT SINGLE * FROM rsbasidoc INTO l_s_rsbasidocWHERE slogsys = l_slogsysAND rlogsys = prlogsys.IF sy-subrc <> 0 OR( l_s_rsbasidoc-objstat = sbiw_c_objstat-inactive ).MESSAGE e053(rj) WITH text-003.* Remote destination not validENDIF.
* Copy record for dummy BW systeml_s_rsbasidoc-rlogsys = c_dlogsys.MODIFY rsbasidoc FROM l_s_rsbasidoc.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-004.* Update of table RSBASIDOC failedENDIF.
* Delta initializationsSELECT * FROM roosprmsc INTO TABLE l_t_roosprmscWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.MESSAGE e020(rsqu).* Some of the initialization requirements have not been completedENDIF.
LOOP AT l_t_roosprmsc ASSIGNING .IF -initstate = ' '.MESSAGE e020(rsqu).* Some of the initialization requirements have not been completedENDIF.-rlogsys = c_dlogsys.-gottid = ''.-gotvers = '0'.-gettid = ''.-getvers = '0'.ENDLOOP.
* Delete old records for dummy BW systemDELETE FROM roosprmscWHERE oltpsource = c_oltpsourceAND rlogsys = c_dlogsysAND slogsys = l_slogsys.
* Copy records for dummy BW systemMODIFY roosprmsc FROM TABLE l_t_roosprmsc.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-005.* Update of table ROOSPRMSC failedENDIF.* Filter values for delta initializationsSELECT * FROM roosprmsf INTO TABLE l_t_roosprmsfWHERE oltpsource = c_oltpsourceAND rlogsys = prlogsysAND slogsys = l_slogsys.IF sy-subrc <> 0.MESSAGE e020(rsqu).
* Some of the initialization requirements have not been completedENDIF.LOOP AT l_t_roosprmsf ASSIGNING .-rlogsys = c_dlogsys.ENDLOOP.* Delete old records for dummy BW systemDELETE FROM roosprmsfWHERE oltpsource = c_oltpsourceAND rlogsys = c_dlogsysAND slogsys = l_slogsys.* Copy records for dummy BW systemMODIFY roosprmsf FROM TABLE l_t_roosprmsf.IF sy-subrc <> 0.MESSAGE e053(rj) WITH text-006.* Update of table ROOSPRMSF failedENDIF.
**************************************
COMMIT WORK for changed meta data
**************************************
COMMIT WORK.* Delete RFC queue of dummy BW system* (Just in case entries of other delta requests exist)CALL FUNCTION 'RSC1_TRFC_QUEUE_DELETE_DATA'
EXPORTING
i_osource = c_oltpsource
i_rlogsys =
c_dlogsysi_all = 'X'
EXCEPTIONS
tid_not_executed = 1
tid_not_executed = 1
client_not_found = 3
error_reading_queue = 4
OTHERS = 5.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.
********************************************
COMMIT WORK for deletion of delta queue
********************************************
COMMIT WORK.
* Get MAXLINES for data package
CALL FUNCTION 'RSAP_IDOC_DETERMINE_PARAMETERS'
EXPORTINGi_oltpsource = c_oltpsourcei_slogsys = l_slogsysi_rlogsys = prlogsysi_updmode = 'D 'IMPORTINGe_s_parameters = l_s_parameterse_subrc = l_subrc.
.IF l_subrc <> 0.MESSAGE e053(rj) WITH text-007.* Error in function module RSAP_IDOC_DETERMINE_PARAMETERSENDIF.* Transfer structure depends on transfer methodCASE l_s_roosgen-tfmethode.WHEN 'I'.
l_tfstruc = l_s_roosgen-tfstridoc.WHEN 'T'.l_tfstruc = l_s_roosgen-tfstruc.ENDCASE.* Determine transfer structure field listPERFORM fill_field_list(saplrsap) TABLES l_t_fieldsUSING l_tfstruc.* Start the delta extraction for the dummy BW systemCALL FUNCTION 'RSFH_GET_DATA_SIMPLE'
EXPORTINGi_requnr = 'DUMMY'i_osource = c_oltpsourcei_showlist = ' 'i_maxsize = l_s_parameters-maxlinesi_maxfetch = '9999'i_updmode = 'D 'i_rlogsys = c_dlogsysi_read_only = ' 'IMPORTING
e_lines_read = l_lines_readTABLESi_t_field = l_t_fieldsEXCEPTIONSgeneration_error = 1interface_table_error = 2metadata_error = 3error_passed_to_mess_handler = 4no_authority = 5OTHERS = 6.IF sy-subrc <> 0.MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.
*********************************
COMMIT WORK for delta request
**********************************
COMMIT WORK.
** Delete RFC queue of dummy BW systemCALL FUNCTION 'RSC1_TRFC_QUEUE_DELETE_DATA'EXPORTINGi_osource = c_oltpsourcei_rlogsys = c_dlogsysi_all = 'X'EXCEPTIONStid_not_executed = 1invalid_parameter = 2client_not_found = 3error_reading_queue = 4OTHERS = 5.IF sy-subrc <> 0.MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgnoWITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.ENDIF.* Data collection for 0FI_GL_4 delta queue successfulMESSAGE s053(rj) WITH text-008.
Publish exceptions
Publish exceptions
1.create query with exceptions
2.use central alert framwork:
.T-code ALRTCATDEF
.create alert category
.create containor element
.create text for alert message
.Then you can enter a text and a URL for a subsequent activity (optionally). E.g. you can add a link to a BI Query which should be checked by the recipient in order to react to the alert.
.In the last step of the alert category configuration you have to assign the alert to the end users. You can enter fixed recipients or roles. If you enter a role, all users that are assigned to that role will get the alert. You can also enter roles, if you press the button "Subscription Authorization". In that case the assigned users will have the option to subscribe for the alert later.
.In the next step you have to call the BEx Broadcaster and create an Information broadcasting setting based on the query, on which the exception has been defined on. As distribution type you have to choose "Distribute according to exceptions". In the details you can either choose the distribution type "Send Email" or "Create Alert", if you want to distribute the alert via the Universal Worklist. As selection criterion you can either choose to distribute all exceptions or you can choose a specific alert level. In our example we only want to distribute alerts, which have the level "Bad 3".
.Then you have to assign the corresponding alert category you have created before to your Information broadcasting setting.
.In the next step you have to do the mapping between the BI parameters of the Query and the alert container elements. These parameters will then be passed over to the alert.
.In the last step you have to save the Information Broadcasting setting. You can execute the setting directly or you can schedule the execution e.g. periodically each week.
.As a result you will see 2 new alerts in the Universal Worklist for all users which have been assigned to the alert corresponding alert category. You can access the Universal Worklist in the Enterprise Portal: Business Intelligence Business Explorer Universal Worklist.
1.create query with exceptions
2.use central alert framwork:
.T-code ALRTCATDEF
.create alert category
.create containor element
.create text for alert message
.Then you can enter a text and a URL for a subsequent activity (optionally). E.g. you can add a link to a BI Query which should be checked by the recipient in order to react to the alert.
.In the last step of the alert category configuration you have to assign the alert to the end users. You can enter fixed recipients or roles. If you enter a role, all users that are assigned to that role will get the alert. You can also enter roles, if you press the button "Subscription Authorization". In that case the assigned users will have the option to subscribe for the alert later.
.In the next step you have to call the BEx Broadcaster and create an Information broadcasting setting based on the query, on which the exception has been defined on. As distribution type you have to choose "Distribute according to exceptions". In the details you can either choose the distribution type "Send Email" or "Create Alert", if you want to distribute the alert via the Universal Worklist. As selection criterion you can either choose to distribute all exceptions or you can choose a specific alert level. In our example we only want to distribute alerts, which have the level "Bad 3".
.Then you have to assign the corresponding alert category you have created before to your Information broadcasting setting.
.In the next step you have to do the mapping between the BI parameters of the Query and the alert container elements. These parameters will then be passed over to the alert.
.In the last step you have to save the Information Broadcasting setting. You can execute the setting directly or you can schedule the execution e.g. periodically each week.
.As a result you will see 2 new alerts in the Universal Worklist for all users which have been assigned to the alert corresponding alert category. You can access the Universal Worklist in the Enterprise Portal: Business Intelligence Business Explorer Universal Worklist.
about DTP
DTP
.default It is recommended to configure the DTP with upload mode “Delta”. The deletion of the PSA data is necessary before each data load, if a “Full” DTP is used. A Full DTP extracts all Requests from the PSA regardless if the data has been already loaded or not. This means the Delta upload via a DTP from the DataSource (PSA) in the InfoCube is necessary, even if the data is loaded via a Full upload from the Source to the DataSource (PSA) by using an InfoPackage. ( which means load from PSA via DTP will load all data from PSA no matter the data were loaded before or not,so eother PSA should delted after load ,or DTP use delta even laod form Data source to PSA use delta already)
.Only get Delta Once:
.Get Data by Request: get the oldest request
.Get runtime information of a Data Transfer Process (DTP) in a Transformation : I will give detail in another blog .
.Debug a Data Transfer Process (DTP) Request:The debugging expert mode can be started from the execute tab of the DTP. The “Expert Mode” flag appears when the Processing Mode “Serially in the Dialog Process (for Debugging)” is selected.Choose “Simulate” to start the Debugger in expert mode.The debugging for loaded data can be executed from the DTP Monitor directly.Choose “Debugging”.
.default It is recommended to configure the DTP with upload mode “Delta”. The deletion of the PSA data is necessary before each data load, if a “Full” DTP is used. A Full DTP extracts all Requests from the PSA regardless if the data has been already loaded or not. This means the Delta upload via a DTP from the DataSource (PSA) in the InfoCube is necessary, even if the data is loaded via a Full upload from the Source to the DataSource (PSA) by using an InfoPackage. ( which means load from PSA via DTP will load all data from PSA no matter the data were loaded before or not,so eother PSA should delted after load ,or DTP use delta even laod form Data source to PSA use delta already)
.Only get Delta Once:
.Get Data by Request: get the oldest request
.Get runtime information of a Data Transfer Process (DTP) in a Transformation : I will give detail in another blog .
.Debug a Data Transfer Process (DTP) Request:The debugging expert mode can be started from the execute tab of the DTP. The “Expert Mode” flag appears when the Processing Mode “Serially in the Dialog Process (for Debugging)” is selected.Choose “Simulate” to start the Debugger in expert mode.The debugging for loaded data can be executed from the DTP Monitor directly.Choose “Debugging”.
Thursday, April 30, 2009
SAP Business Warehouse Topics
SAP Business Warehouse Topics
1. Fundamentals: What is NetWeaver? What is BI? What is SAP BW or Business Information Warehouse? What is SAP R3? Decision support in an Enterprise. Decision support v/s Operational Reporting. OLTP v/s OLAP. Fundamentals about working of SAP R3. Fundamentals aboutworking of SAP BW.
2. Functions of BW: Reporting (Decision Support and Operational), Open Hub (Supply Data to External Applications), Planning (Business Planning and Simulation – BPS). SEM–BPS is now BW-BPS. BW as EDW (Enterprise Data Warehouse).
3. Data Modeling: Data modeling concepts. Concepts behind various Data Models used in OLTP and OLAP. Why different Data Models? MDM v/s ERM. Extended Star Schema used in SAP BW.
4. SAP BW Terminology: Communication Structure in SAP R3, Extract Structure, User Exit, Transfer Structure, Datasource, Source System, PSA, Transfer rules, Communication Structure in BW, Update Rules, Infocube, ODS (Operational Data Store), Infoobject, Master Data(Attributes, Texts and Hierarchies), Characteristics and Key Figures, Infoprovider, Datatarget, Infoprovider v/s Datatarget, Infoarea, Application Components, Administrator Work Bench, Multiprovider, Infoset, Bex Query, Infoset Query, Classic Infoset.
5. Data Flow: How the data flows from Source System in to BW? Data Flow Diagram for SAP R3 OLTP System to SAP BW. Types of Updates – Direct v/s Flexible. How the elements described above are used in Data Flow?
6. Infoobject: How to create Infoobject? Types of Infoobjects. Characteristics and Key Figures, Master Data, Special types (Unit/Currency, Date), Data Structures in Infoobject. How to Load Data in to Infoobject? How is the Infoobject used in Reporting? Global Transfer Routine – How to use Global Transfer Routine? Why it is used. Management of overlapping Master Data fromMultiple Sources. Creating Direct Update Infosources Automatically. Infoobject as Infoprovider.
7. Types of Updates: Additive, Overwrite. Where to maintain update type for Datasource? Which objects use these update types (ODS/Infocube?Master Data)?
8. Infocube: How to create an Infocube? Types of Infocubes (Transactional, Basic, Remote/Virtual), Data Structures in an Infocube. Update types for Infocube. How is the data updated in the Infocube? Virtual Key Figures.
9. ODS Object: How to Create ODS Object? Structure of ODS Object. Updste types in ODS Object. Update Mechanism. Data structures in an ODS Object.
10. Infosource: Creating Infosource, Update and Transfer Rules, Update Routine, Transfer Routine, Start Routine, Start up Routine.
11. AWB – Administrator Work Bench: Functions of AWB – Modeling, Monitoring, Reporting Agent, Transport Connection, Documents, Business Content, Translation, Metadata Repository.
12. Transports: How transports work in BW. How to create Transports? Efficient ways to create Transports in Different Scenarios.
13. Business Content: Standard Business Content in R3 and BW. Transferring Datasources and Application Component Hierarchy in R3. Replication of Datasources. Activation of Business Content. How to Activate Business Content – various Scenarios.
14. Data Extraction Using Flat Files: How to generate Transfer Structure from Communication Structure? Loading Data using Flat File.
15. Data Extraction from SAP R3 – Data Collection: Transaction Processing in SAP R3. Update types in SAP R3. How “Delta” is managed? V3 Control. Direct and Queued Delta. Update Mechanism in SAP R3. Manipulation of Data in SAP R3. Transaction User Exits, LIS User Exits.BW User Exits.
16. Data Extraction from SAP R3 –Application Specific: Infrastructure needed for loading data – Datasource, LO-Cockpit Datasources, CO_PA, FI-SL, FI_Line Item Extraction, LIS Extraction.
17. LO-Cockpit Extraction: Demonstrate each step in data extraction by performing transactions in SAP R3.
18. Data Extraction from SAP R3 – Generic: How to Create Generic Datasource? Delta Management. Generic Delta.
19. Data Extraction from SAP R3 – Maintain Datasource: What is - Direct Access, Delta, Inversion, Selection, Field only…, Hide. How to Maintain Datasource?
20. Data Extraction from SAP R3 – Modifying Data: Manipulation of Transaction Data / Master Data / Texts / Hierarchies. How to program in User Exit? Concept of Project. Function Modules used for Data Manipulation.
21. Modify Datasource: Demo the process of modifying Master Data Source by adding additional field and filling it with Data in BW.
22. Data Extraction from XML Source: XML Integration, Creating Flat File Datasource and generating Myself Datasource. Create and Maintain “Delta Queue” in BW System.
23. DB Connect: Concepts.
24. Data Mart Interface: Extraction within BW System. ODS to ODS, ODS to Infocube and Infocube to Infocube Extraction.
25. Open Hub Services: Infospoke, Create and Schedule Infospoke. BW as Open Hub or Data Hub.
26. Performance Management: How to improve performance of Data Load and Query?
Partitioning. Indexes in Infocubes and ODS’s. Aggregates on Infocubes. Compression.
27. Production Support: Monitoring Jobs, Process Chains, Event Chains, Infopackage Groups, Creating and Triggering Events, Common Problems, How to Fix them.
28. BW Presentation – Queries: Bex Analyzer, Query Designer, Queries in standard Excel Front end, Functions, Formulas, Calculated and Restricted Key Figures, Tabular Display. Query Views. Exception Reporting.
29. Web Interface: Launching Queries in Web Front end. Building simple Web site for launching Queries.
30. Web Application Designer: Web Templates. Creating Web Template with Company Logo. Adding more than one Query in a Web Page.
31. Reporting Agent: Demo - Scheduling a Query with exceptions to run at certain time and send e-mail with the result as attachment.
32. Report to Report Interface: Also known as RRI or Query Jump. Jump from Aggregate to Detailed Query with selections from the Aggregate Query.
1. Fundamentals: What is NetWeaver? What is BI? What is SAP BW or Business Information Warehouse? What is SAP R3? Decision support in an Enterprise. Decision support v/s Operational Reporting. OLTP v/s OLAP. Fundamentals about working of SAP R3. Fundamentals aboutworking of SAP BW.
2. Functions of BW: Reporting (Decision Support and Operational), Open Hub (Supply Data to External Applications), Planning (Business Planning and Simulation – BPS). SEM–BPS is now BW-BPS. BW as EDW (Enterprise Data Warehouse).
3. Data Modeling: Data modeling concepts. Concepts behind various Data Models used in OLTP and OLAP. Why different Data Models? MDM v/s ERM. Extended Star Schema used in SAP BW.
4. SAP BW Terminology: Communication Structure in SAP R3, Extract Structure, User Exit, Transfer Structure, Datasource, Source System, PSA, Transfer rules, Communication Structure in BW, Update Rules, Infocube, ODS (Operational Data Store), Infoobject, Master Data(Attributes, Texts and Hierarchies), Characteristics and Key Figures, Infoprovider, Datatarget, Infoprovider v/s Datatarget, Infoarea, Application Components, Administrator Work Bench, Multiprovider, Infoset, Bex Query, Infoset Query, Classic Infoset.
5. Data Flow: How the data flows from Source System in to BW? Data Flow Diagram for SAP R3 OLTP System to SAP BW. Types of Updates – Direct v/s Flexible. How the elements described above are used in Data Flow?
6. Infoobject: How to create Infoobject? Types of Infoobjects. Characteristics and Key Figures, Master Data, Special types (Unit/Currency, Date), Data Structures in Infoobject. How to Load Data in to Infoobject? How is the Infoobject used in Reporting? Global Transfer Routine – How to use Global Transfer Routine? Why it is used. Management of overlapping Master Data fromMultiple Sources. Creating Direct Update Infosources Automatically. Infoobject as Infoprovider.
7. Types of Updates: Additive, Overwrite. Where to maintain update type for Datasource? Which objects use these update types (ODS/Infocube?Master Data)?
8. Infocube: How to create an Infocube? Types of Infocubes (Transactional, Basic, Remote/Virtual), Data Structures in an Infocube. Update types for Infocube. How is the data updated in the Infocube? Virtual Key Figures.
9. ODS Object: How to Create ODS Object? Structure of ODS Object. Updste types in ODS Object. Update Mechanism. Data structures in an ODS Object.
10. Infosource: Creating Infosource, Update and Transfer Rules, Update Routine, Transfer Routine, Start Routine, Start up Routine.
11. AWB – Administrator Work Bench: Functions of AWB – Modeling, Monitoring, Reporting Agent, Transport Connection, Documents, Business Content, Translation, Metadata Repository.
12. Transports: How transports work in BW. How to create Transports? Efficient ways to create Transports in Different Scenarios.
13. Business Content: Standard Business Content in R3 and BW. Transferring Datasources and Application Component Hierarchy in R3. Replication of Datasources. Activation of Business Content. How to Activate Business Content – various Scenarios.
14. Data Extraction Using Flat Files: How to generate Transfer Structure from Communication Structure? Loading Data using Flat File.
15. Data Extraction from SAP R3 – Data Collection: Transaction Processing in SAP R3. Update types in SAP R3. How “Delta” is managed? V3 Control. Direct and Queued Delta. Update Mechanism in SAP R3. Manipulation of Data in SAP R3. Transaction User Exits, LIS User Exits.BW User Exits.
16. Data Extraction from SAP R3 –Application Specific: Infrastructure needed for loading data – Datasource, LO-Cockpit Datasources, CO_PA, FI-SL, FI_Line Item Extraction, LIS Extraction.
17. LO-Cockpit Extraction: Demonstrate each step in data extraction by performing transactions in SAP R3.
18. Data Extraction from SAP R3 – Generic: How to Create Generic Datasource? Delta Management. Generic Delta.
19. Data Extraction from SAP R3 – Maintain Datasource: What is - Direct Access, Delta, Inversion, Selection, Field only…, Hide. How to Maintain Datasource?
20. Data Extraction from SAP R3 – Modifying Data: Manipulation of Transaction Data / Master Data / Texts / Hierarchies. How to program in User Exit? Concept of Project. Function Modules used for Data Manipulation.
21. Modify Datasource: Demo the process of modifying Master Data Source by adding additional field and filling it with Data in BW.
22. Data Extraction from XML Source: XML Integration, Creating Flat File Datasource and generating Myself Datasource. Create and Maintain “Delta Queue” in BW System.
23. DB Connect: Concepts.
24. Data Mart Interface: Extraction within BW System. ODS to ODS, ODS to Infocube and Infocube to Infocube Extraction.
25. Open Hub Services: Infospoke, Create and Schedule Infospoke. BW as Open Hub or Data Hub.
26. Performance Management: How to improve performance of Data Load and Query?
Partitioning. Indexes in Infocubes and ODS’s. Aggregates on Infocubes. Compression.
27. Production Support: Monitoring Jobs, Process Chains, Event Chains, Infopackage Groups, Creating and Triggering Events, Common Problems, How to Fix them.
28. BW Presentation – Queries: Bex Analyzer, Query Designer, Queries in standard Excel Front end, Functions, Formulas, Calculated and Restricted Key Figures, Tabular Display. Query Views. Exception Reporting.
29. Web Interface: Launching Queries in Web Front end. Building simple Web site for launching Queries.
30. Web Application Designer: Web Templates. Creating Web Template with Company Logo. Adding more than one Query in a Web Page.
31. Reporting Agent: Demo - Scheduling a Query with exceptions to run at certain time and send e-mail with the result as attachment.
32. Report to Report Interface: Also known as RRI or Query Jump. Jump from Aggregate to Detailed Query with selections from the Aggregate Query.
Comparing/Limitation of SAP R/3 Reporting Systems
Comparing/Limitation of SAP R/3 Reporting Systems
Comparingof SAP R/3 Reporting Systems
Common feature among R/3 reporting systems is that they all collect data in special data tables. This is a preferred method for operational reporting due to real-time data acquisition from linked SAP modules. Several reporting systems derive data based on update rules.
External data can also be imported in the reporting information structures for consolidated information view.
These information systems use a variety of tools for presentation and analysis such as ABAP, ABAP Query, Report Writer/Painter, and LIS.
All information systems require in-depth R/3 configuration knowledge.
This is the most important reason that reporting requirements must be a part of overall OLTP business workflow-business rules.
Using linked SAP modules requires absolute integration with process configuration teams. The process requirements must be stable, because the workflow determines what data is captured based on a variety of states and conditions defined to meet business operations and analysis requirements.
SAP R/3 is primarily designed for a high transaction rate. Information processing in an OLTP and a data warehouse are very different. A few differentiating characteristics between an OLTP and a data warehouse are listed in Table 2-1. Data warehouses require a very different configuration due to large data volume and unpredictable data navigation schemes. It is impossible to configure an OLTP system as a full-featured data warehouse without having an impact on OLTP operations. Therefore, the nature of reporting on OLTP systems must be limited to support real-time operations and not historical reporting. The next section addresses reporting issues associated with R/3 information systems.
Limitation of SAP R/3 Reporting Systems
Comparingof SAP R/3 Reporting Systems
Common feature among R/3 reporting systems is that they all collect data in special data tables. This is a preferred method for operational reporting due to real-time data acquisition from linked SAP modules. Several reporting systems derive data based on update rules.
External data can also be imported in the reporting information structures for consolidated information view.
These information systems use a variety of tools for presentation and analysis such as ABAP, ABAP Query, Report Writer/Painter, and LIS.
All information systems require in-depth R/3 configuration knowledge.
This is the most important reason that reporting requirements must be a part of overall OLTP business workflow-business rules.
Using linked SAP modules requires absolute integration with process configuration teams. The process requirements must be stable, because the workflow determines what data is captured based on a variety of states and conditions defined to meet business operations and analysis requirements.
SAP R/3 is primarily designed for a high transaction rate. Information processing in an OLTP and a data warehouse are very different. A few differentiating characteristics between an OLTP and a data warehouse are listed in Table 2-1. Data warehouses require a very different configuration due to large data volume and unpredictable data navigation schemes. It is impossible to configure an OLTP system as a full-featured data warehouse without having an impact on OLTP operations. Therefore, the nature of reporting on OLTP systems must be limited to support real-time operations and not historical reporting. The next section addresses reporting issues associated with R/3 information systems.
Limitation of SAP R/3 Reporting Systems
One of the hardest tasks in developing a reporting environment in R/3 is selecting one data access and analysis tool that satisfies end-user needs. The following are the major shortfalls of native SAP R/3 reporting:
• Information on existing reports is either missing or unclear. Searching a report among thousands of available reports in R/3 is a big problem. The Report Navigator, developed by SAP's Simplification Group, is a good attempt to solve this problem.
• Available reports are designed to meet operational and transactional information needs. Most reports are predefined, list oriented, and provide very limited OLAP functionality.
• Several reporting modules and associated reporting tools make it hard to select a specific tool. Reporting tools are inconsistent, and designing reports is a complex process. Maintenance of thousands of reports for software upgrades is a huge challenge. Knowledge of how often a report is used is not available, such as which reports are frequently used or ever used. As a consequence, all reports need to be maintained regardless of their usage. Recently, SAP has provided utilities to track report-usage statistics that will help identify which reports are to be upgraded or dropped in a release upgrade or support.
• Fragmented reporting menu access requires extensive end-user training to navigate through
several multi-level menus to display a few reports.
• Performance impact on R/3 OLTP operations due to reporting is another major issue. The R/3 systems are configured to provide high OLTP transaction rates. Building a robust reporting and OLAP environment under an OLTP environment requires different configuration parameters that will degrade OLTP operations. See Table 2-1, which lists the common differences between OLTP and Reporting/OLAP environments.
To overcome OLTP and reporting co-existence problems, several customers have attempted to build a separate R/3 environment dedicated to reporting. I discuss a few such models in the next section. But first, I'd like to look at how SAP planned to re-architect R/3 application components in the early '90s.
Application architects at SAP planned to break down the traditional SAP R/3 very tightly integrated application modules into several loosely coupled applications; these applications would still be connected to each other by use of Application Link Enabling (ALE) technology (ALE is SAP's EDI-like middleware. I discuss ALE in much more detail in the next few sections.). This new distributed application concept became what is known as SAP Business Framework Architecture, as shown in Figure 2-4. Due to the mySAP.com initiative, the SAP Business Framework today looks quite different from when it was proposed in the early 1990s, as shown in Figure 2-4.
However, the core concept behind the SAP Business Framework remains the same-loosely coupled business components. The only difference is that today the integration technologies are becoming Internet-centric, replacing pure ALE and new business components to support business to business (B2B), business to customer (B2C), Customer Relationship Management (CRM), and business intelligence, and have taken higher priority than breaking SAP R/3 modules into individual stand-alone applications.
SAP BW Glossary
SAP BW Glossary
Aggregate
An aggregate is a subset of an InfoCube. The objective when using aggregates is to reduce I/O volume. The BW OLAP processor selects an appropriate aggregate during a query run or a navigation step. If no appropriate aggregate exists, the BW OLAP processor retrieves data from the original InfoCube instead.
Aggregate rollup
Aggregate rollup is a procedure to update aggregates with new data loads.
Application component
Application components are used to organize InfoSources. They are similar to the InfoAreas used with InfoCubes. The maximum number of characters allowed for the technical name is 32.
Authorization
An authorization defines what a user can do, and to which SAP objects. For example, a user with an authorization can display and execute, but not change, a query. Authorizations are defined using authorization objects.
Authorization object
An authorization object is used to define user authorizations. It has fields with values to specify authorized activities, such as display and execution, on authorized business objects, such as queries. The maximum number of characters allowed for the technical name is 10.
Authorization profile
An authorization profile is made up of multiple authorizations. The maximum number of characters allowed for the technical name is 10.
Bitmap index
A bitmap index uses maps of bits to locate records in a table. Bitmap indices are very effective for Boolean operations of the WHERE clause of a SELECT statement. When the cardinality of a column is low, a bitmap index size will be small, thereby reducing I/O volume.
Business Content
Business Content is a complete set of BW objects developed by SAP to support the OLAP tasks. It contains roles, workbooks, queries, InfoCubes, key figures, characteristics, update rules, InfoSources, and extractors for SAP R/3, and other mySAP solutions.
BW
BW is a data warehousing solution from SAP.
BW Monitor
BW Monitor displays data loading status and provides assistance in troubleshooting if errors occur.
BW Scheduler
BW Scheduler specifies when to load data. It is based on the same techniques used for scheduling R/3 background jobs.
BW Statistics
BW Statistics is a tool for recording and reporting system activity and performance information.
Change run
Change run is a procedure used to activate characteristic data changes.
Characteristic
Characteristics are descriptions of key figures, such as Customer ID, Material Number, Sales Representative ID, Unit of Measure, and Transaction Date. The maximum number of characters allowed for the technical name is 9.
Client
A client is a subset of data in an SAP system. Data shared by all clients is called client-independent data, as compared with client-dependent data. When logging on to an SAP system, a user must specify which client to use. Once in the system, the user has access to both client-dependent data and client-independent data.
Communication structure
The communication structure is the structure underlying the InfoSource.
Compound attribute
A compound attribute differentiates a characteristic to make the characteristic uniquely identifiable. For example, if the same characteristic data from different source systems mean different things, then we can add the compound attribute 0SOURSYSTEM (source system ID) to the characteristic; 0SOURSYSTEM is provided with the Business Content.
Data packet size
For the same amount of data, the data packet size determines how work processes will be used in data loading. The smaller the data packet size, the more work processes needed.
Data Warehouse
Data Warehouse is a dedicated reporting and analysis environment based on the star schema database design technique and requiring special attention to the data ETTL process.
DataSource
A DataSource is not only a structure in which source system fields are logically grouped together, but also an object that contains ETTL-related information. Four types of DataSources exist:
DataSources for transaction data
DataSources for characteristic attributes
DataSources for characteristic texts
DataSources for characteristic hierarchies
If the source system is R/3, replicating DataSources from a source system will create identical DataSource structures in the BW system. The maximum number of characters allowed for a DataSource's technical name is 32.
Delta update
The Delta update option in the InfoPackage definition requests BW to load only the data that have been accumulated since the last update. Before a delta update occurs, the delta process must be initialized.
Development class
A development class is a group of objects that are logically related.
Display attribute
A display attribute provides supplemental information to a characteristic.
Drill-down
Drill-down is a user navigation step intended to get further detailed information.
ETTL
ETTL, one of the most challenging tasks in building a data warehouse, is the process of extracting, transforming, transferring, and loading data correctly and quickly.
Free characteristic
A free characteristic is a characteristic in a query used for drill-downs. It is not displayed in the initial result of a query run.
Full update
The Full update option in the InfoPackage definition requests BW to load all data that meet the selection criteria specified via the Select data tab.
Generic data extraction
Generic data extraction is a function in Business Content that allows us to create DataSources based on database views or InfoSet queries. InfoSet is similar to a view but allows outer joins between tables.
Granularity
Granularity describes the level of detail in a data warehouse. It is determined by business requirements and technology capabilities.
IDoc
IDoc (Intermediate Document) is used in SAP to transfer data between two systems. It is a specific instance of a data structure called the IDoc Type, whose processing logic is defined in the IDoc Interface.
Index
An index is a technique used to locate needed records in a database table quickly. BW uses two types of indices: B-tree indices for regular database tables and bitmap indices for fact tables and aggregate tables.
InfoArea
InfoAreas are used to organize InfoCubes and InfoObjects. Each InfoCube is assigned to an InfoArea. Through an InfoObject Catalog, each InfoObject is assigned to an InfoArea as well. The maximum number of characters allowed for the technical name is 30.
InfoCube
An InfoCube is a fact table and its associated dimension tables in the star schema. The maximum number of characters allowed for the technical name is 30.
InfoCube compression
InfoCube compression is a procedure used to aggregate multiple data loads at the request level.
InfoObject
In BW, key figures and characteristics are collectively called InfoObjects.
InfoObject Catalog
InfoObject Catalogs organize InfoObjects. Two types of InfoObject Catalogs exist: one for characteristics, and one for key figures. The maximum number of characters allowed for the technical name is 30.
InfoPackage
An InfoPackage specifies when and how to load data from a given source system. BW generates a 30-digit code starting with ZPAK as an InfoPackage's technical name.
InfoSource
An InfoSource is a structure in which InfoObjects are logically grouped together. InfoCubes and characteristics interact with InfoSources to get source system data. The maximum number of characters allowed for the technical name is 32.
Key figure
Key figures are numeric values or quantities, such as Per Unit Sales Price, Quantity Sold, and Sales Revenue. The maximum number of characters allowed for the technical name is 9.
Line item dimension
A line item dimension in a fact table connects directly with the SID table of its sole characteristic.
Logical system
A logical system is the name of a client in an SAP system.
Multi-cube
A multi-cube is a union of basic cubes. The multi-cube itself does not contain any data; rather, data reside in the basic cubes. To a user, the multi-cube is similar to a basic cube. When creating a query, the user can select characteristics and key figures from different basic cubes.
Navigational attribute
A navigational attribute indicates a characteristic-to-characteristic relationship between two characteristics. It provides supplemental information about a characteristic and enables navigation from characteristic to characteristic during a query.
Number range
A number range is a range of numbers that resides in application server memory for quick number assignments.
ODS
ODS is a BW architectural component located between PSA and InfoCubes that allows BEx reporting. It is not based on the star schema and is used primarily for detail reporting, rather than for dimensional analysis. ODS objects do not aggregate data as InfoCubes do. Instead, data are loaded into an ODS object by inserting new records, updating existing records, or deleting old records, as specified by the 0RECORDMODE value.
Parallel query
A parallel query uses multiple database processes, when available, to execute a query.
Partition
A partition is a piece of physical storage for database tables and indices. If the needed data reside in one or a few partitions, then only those partitions will be selected and examined by a SQL statement, thereby significantly reducing I/O volume.
Profile Generator
Profile Generator is a tool used to create authorization profiles.
PSA
PSA is a data staging area in BW. It allows us to check data in an intermediate location, before the data are sent to its destinations in BW.
Query
A BW query is a selection of characteristics and key figures for the analysis of the data in an InfoCube. A query refers to only one InfoCube, and its result is presented in a BEx Excel sheet. The maximum number of characters allowed for the technical name is 30.
Read mode
Read mode for a query determines the size and frequency of data retrievals from database: all data at once, as needed per navigation step, or as needed per hierarchy node.
Reconstruct
Reconstruct is a procedure used to restore load requests from PSA.
Request
A request is a data load request from BW Scheduler. Each time that BW Scheduler loads data into an InfoCube, a unique request ID is created in the data packet dimension table of the InfoCube.
RFC
RFC (Remote Function Call) is a call to a function module in a system different from the caller's—usually another SAP system on the local network.
Role
In Profile Generator, an authorization profile corresponds to a role. A user assigned to that role also has the corresponding authorization profile. A user can be assigned to multiple roles. The maximum number of characters allowed for the technical name is 30.
SID
SID (Surrogate-ID) translates a potentially long key for an InfoObject into a short four-byte integer, which saves I/O and memory during OLAP.
Source system
A source system is a protocol that BW uses to find and extract data. When the source system is a non-SAP system, such as a flat file or a third-party tool, the maximum number of characters allowed for the technical name is 10. When the source system is an SAP system, either R/3 or BW, the technical name matches the logical system name. The maximum number of characters allowed for the technical name is 32.
Star schema
A star schema is a technique used in the data warehouse database design to help data retrieval for online analytical processing.
Statistics
For a SQL statement, many execution plans are possible. The database optimizer generates the most efficient execution plan based on either the heuristic ranking of available execution plans or the cost calculation of available execution plans. Statistics is the information that the cost-based optimizer uses to calculate the cost of available execution plans and select the most appropriate one for execution. BW uses the cost-base optimizer for Oracle databases.
System Administration Assistant
System Administration Assistant is a collection of tools used to monitor and analyze general system operation conditions.
System landscape
The system landscape specifies the role of each system and the paths used in transporting objects among the various systems.
Time-dependent entire hierarchy
A time-dependent entire hierarchy is a time-dependent hierarchy whose nodes and leaves are not time-dependent.
Time-dependent hierarchy structure
A time-dependent hierarchy structure consists of nodes or leaves that are time-dependent, but the hierarchy itself is not time-dependent.
Transfer rule
Transfer rules specify how DataSource fields are mapped to InfoSource InfoObjects.
Transfer structure
A transfer structure maps DataSource fields to InfoSource InfoObjects.
Update rule
An update rule specifies how data will be updated into their targets. The data target can be an InfoCube or an ODS object. If the update rule is applied to data from an InfoSource, the update rule's technical name will match the InfoSource's technical name. If the update rule is applied to data from an ODS object, the update rule's technical name will match the ODS object's technical name prefixed with number 8.
Variable
A variable is a query parameter. It gets its value from user input or takes a default value set by the variable creator.
Workbook
A BW workbook is an Excel file with a BEx query result saved in BDS. BW assigns a 25-digit ID to each workbook. Users need merely name a workbook's title.
Aggregate
An aggregate is a subset of an InfoCube. The objective when using aggregates is to reduce I/O volume. The BW OLAP processor selects an appropriate aggregate during a query run or a navigation step. If no appropriate aggregate exists, the BW OLAP processor retrieves data from the original InfoCube instead.
Aggregate rollup
Aggregate rollup is a procedure to update aggregates with new data loads.
Application component
Application components are used to organize InfoSources. They are similar to the InfoAreas used with InfoCubes. The maximum number of characters allowed for the technical name is 32.
Authorization
An authorization defines what a user can do, and to which SAP objects. For example, a user with an authorization can display and execute, but not change, a query. Authorizations are defined using authorization objects.
Authorization object
An authorization object is used to define user authorizations. It has fields with values to specify authorized activities, such as display and execution, on authorized business objects, such as queries. The maximum number of characters allowed for the technical name is 10.
Authorization profile
An authorization profile is made up of multiple authorizations. The maximum number of characters allowed for the technical name is 10.
Bitmap index
A bitmap index uses maps of bits to locate records in a table. Bitmap indices are very effective for Boolean operations of the WHERE clause of a SELECT statement. When the cardinality of a column is low, a bitmap index size will be small, thereby reducing I/O volume.
Business Content
Business Content is a complete set of BW objects developed by SAP to support the OLAP tasks. It contains roles, workbooks, queries, InfoCubes, key figures, characteristics, update rules, InfoSources, and extractors for SAP R/3, and other mySAP solutions.
BW
BW is a data warehousing solution from SAP.
BW Monitor
BW Monitor displays data loading status and provides assistance in troubleshooting if errors occur.
BW Scheduler
BW Scheduler specifies when to load data. It is based on the same techniques used for scheduling R/3 background jobs.
BW Statistics
BW Statistics is a tool for recording and reporting system activity and performance information.
Change run
Change run is a procedure used to activate characteristic data changes.
Characteristic
Characteristics are descriptions of key figures, such as Customer ID, Material Number, Sales Representative ID, Unit of Measure, and Transaction Date. The maximum number of characters allowed for the technical name is 9.
Client
A client is a subset of data in an SAP system. Data shared by all clients is called client-independent data, as compared with client-dependent data. When logging on to an SAP system, a user must specify which client to use. Once in the system, the user has access to both client-dependent data and client-independent data.
Communication structure
The communication structure is the structure underlying the InfoSource.
Compound attribute
A compound attribute differentiates a characteristic to make the characteristic uniquely identifiable. For example, if the same characteristic data from different source systems mean different things, then we can add the compound attribute 0SOURSYSTEM (source system ID) to the characteristic; 0SOURSYSTEM is provided with the Business Content.
Data packet size
For the same amount of data, the data packet size determines how work processes will be used in data loading. The smaller the data packet size, the more work processes needed.
Data Warehouse
Data Warehouse is a dedicated reporting and analysis environment based on the star schema database design technique and requiring special attention to the data ETTL process.
DataSource
A DataSource is not only a structure in which source system fields are logically grouped together, but also an object that contains ETTL-related information. Four types of DataSources exist:
DataSources for transaction data
DataSources for characteristic attributes
DataSources for characteristic texts
DataSources for characteristic hierarchies
If the source system is R/3, replicating DataSources from a source system will create identical DataSource structures in the BW system. The maximum number of characters allowed for a DataSource's technical name is 32.
Delta update
The Delta update option in the InfoPackage definition requests BW to load only the data that have been accumulated since the last update. Before a delta update occurs, the delta process must be initialized.
Development class
A development class is a group of objects that are logically related.
Display attribute
A display attribute provides supplemental information to a characteristic.
Drill-down
Drill-down is a user navigation step intended to get further detailed information.
ETTL
ETTL, one of the most challenging tasks in building a data warehouse, is the process of extracting, transforming, transferring, and loading data correctly and quickly.
Free characteristic
A free characteristic is a characteristic in a query used for drill-downs. It is not displayed in the initial result of a query run.
Full update
The Full update option in the InfoPackage definition requests BW to load all data that meet the selection criteria specified via the Select data tab.
Generic data extraction
Generic data extraction is a function in Business Content that allows us to create DataSources based on database views or InfoSet queries. InfoSet is similar to a view but allows outer joins between tables.
Granularity
Granularity describes the level of detail in a data warehouse. It is determined by business requirements and technology capabilities.
IDoc
IDoc (Intermediate Document) is used in SAP to transfer data between two systems. It is a specific instance of a data structure called the IDoc Type, whose processing logic is defined in the IDoc Interface.
Index
An index is a technique used to locate needed records in a database table quickly. BW uses two types of indices: B-tree indices for regular database tables and bitmap indices for fact tables and aggregate tables.
InfoArea
InfoAreas are used to organize InfoCubes and InfoObjects. Each InfoCube is assigned to an InfoArea. Through an InfoObject Catalog, each InfoObject is assigned to an InfoArea as well. The maximum number of characters allowed for the technical name is 30.
InfoCube
An InfoCube is a fact table and its associated dimension tables in the star schema. The maximum number of characters allowed for the technical name is 30.
InfoCube compression
InfoCube compression is a procedure used to aggregate multiple data loads at the request level.
InfoObject
In BW, key figures and characteristics are collectively called InfoObjects.
InfoObject Catalog
InfoObject Catalogs organize InfoObjects. Two types of InfoObject Catalogs exist: one for characteristics, and one for key figures. The maximum number of characters allowed for the technical name is 30.
InfoPackage
An InfoPackage specifies when and how to load data from a given source system. BW generates a 30-digit code starting with ZPAK as an InfoPackage's technical name.
InfoSource
An InfoSource is a structure in which InfoObjects are logically grouped together. InfoCubes and characteristics interact with InfoSources to get source system data. The maximum number of characters allowed for the technical name is 32.
Key figure
Key figures are numeric values or quantities, such as Per Unit Sales Price, Quantity Sold, and Sales Revenue. The maximum number of characters allowed for the technical name is 9.
Line item dimension
A line item dimension in a fact table connects directly with the SID table of its sole characteristic.
Logical system
A logical system is the name of a client in an SAP system.
Multi-cube
A multi-cube is a union of basic cubes. The multi-cube itself does not contain any data; rather, data reside in the basic cubes. To a user, the multi-cube is similar to a basic cube. When creating a query, the user can select characteristics and key figures from different basic cubes.
Navigational attribute
A navigational attribute indicates a characteristic-to-characteristic relationship between two characteristics. It provides supplemental information about a characteristic and enables navigation from characteristic to characteristic during a query.
Number range
A number range is a range of numbers that resides in application server memory for quick number assignments.
ODS
ODS is a BW architectural component located between PSA and InfoCubes that allows BEx reporting. It is not based on the star schema and is used primarily for detail reporting, rather than for dimensional analysis. ODS objects do not aggregate data as InfoCubes do. Instead, data are loaded into an ODS object by inserting new records, updating existing records, or deleting old records, as specified by the 0RECORDMODE value.
Parallel query
A parallel query uses multiple database processes, when available, to execute a query.
Partition
A partition is a piece of physical storage for database tables and indices. If the needed data reside in one or a few partitions, then only those partitions will be selected and examined by a SQL statement, thereby significantly reducing I/O volume.
Profile Generator
Profile Generator is a tool used to create authorization profiles.
PSA
PSA is a data staging area in BW. It allows us to check data in an intermediate location, before the data are sent to its destinations in BW.
Query
A BW query is a selection of characteristics and key figures for the analysis of the data in an InfoCube. A query refers to only one InfoCube, and its result is presented in a BEx Excel sheet. The maximum number of characters allowed for the technical name is 30.
Read mode
Read mode for a query determines the size and frequency of data retrievals from database: all data at once, as needed per navigation step, or as needed per hierarchy node.
Reconstruct
Reconstruct is a procedure used to restore load requests from PSA.
Request
A request is a data load request from BW Scheduler. Each time that BW Scheduler loads data into an InfoCube, a unique request ID is created in the data packet dimension table of the InfoCube.
RFC
RFC (Remote Function Call) is a call to a function module in a system different from the caller's—usually another SAP system on the local network.
Role
In Profile Generator, an authorization profile corresponds to a role. A user assigned to that role also has the corresponding authorization profile. A user can be assigned to multiple roles. The maximum number of characters allowed for the technical name is 30.
SID
SID (Surrogate-ID) translates a potentially long key for an InfoObject into a short four-byte integer, which saves I/O and memory during OLAP.
Source system
A source system is a protocol that BW uses to find and extract data. When the source system is a non-SAP system, such as a flat file or a third-party tool, the maximum number of characters allowed for the technical name is 10. When the source system is an SAP system, either R/3 or BW, the technical name matches the logical system name. The maximum number of characters allowed for the technical name is 32.
Star schema
A star schema is a technique used in the data warehouse database design to help data retrieval for online analytical processing.
Statistics
For a SQL statement, many execution plans are possible. The database optimizer generates the most efficient execution plan based on either the heuristic ranking of available execution plans or the cost calculation of available execution plans. Statistics is the information that the cost-based optimizer uses to calculate the cost of available execution plans and select the most appropriate one for execution. BW uses the cost-base optimizer for Oracle databases.
System Administration Assistant
System Administration Assistant is a collection of tools used to monitor and analyze general system operation conditions.
System landscape
The system landscape specifies the role of each system and the paths used in transporting objects among the various systems.
Time-dependent entire hierarchy
A time-dependent entire hierarchy is a time-dependent hierarchy whose nodes and leaves are not time-dependent.
Time-dependent hierarchy structure
A time-dependent hierarchy structure consists of nodes or leaves that are time-dependent, but the hierarchy itself is not time-dependent.
Transfer rule
Transfer rules specify how DataSource fields are mapped to InfoSource InfoObjects.
Transfer structure
A transfer structure maps DataSource fields to InfoSource InfoObjects.
Update rule
An update rule specifies how data will be updated into their targets. The data target can be an InfoCube or an ODS object. If the update rule is applied to data from an InfoSource, the update rule's technical name will match the InfoSource's technical name. If the update rule is applied to data from an ODS object, the update rule's technical name will match the ODS object's technical name prefixed with number 8.
Variable
A variable is a query parameter. It gets its value from user input or takes a default value set by the variable creator.
Workbook
A BW workbook is an Excel file with a BEx query result saved in BDS. BW assigns a 25-digit ID to each workbook. Users need merely name a workbook's title.
Evolution of SAP BW
Evolution of SAP BW
A Quick Look at SAP R/3 Architecture and Technologies
Founded in 1972 in Mannheim, Germany, as Systemanalyse und Programmen-twicklung to produce and market standard software for integrated business solutions, today that company is known as SAP (Systems, Applications and Products in Data Processing), headquartered in Walldorf, Germany. SAP built packaged applications for mainframe computers, called SAP R/2. As the client/server technologies emerged in the early 1980s, SAP launched a major initiative to engineer powerful three-tiered integrated business applications under one framework. The SAP R/3 product is the outcome of that initiative.
Note Often, people ask what R/2 and R/3 mean. The letter R stands for real-time, and 2 and 3 represent two-tiered and three-tiered architectures, respectively. SAP R/2 is for mainframes only, whereas SAP R/3 is three-tiered implementation using client/server technology for a wide range of platforms-hardware and software. When implementing a Web front-end to an SAP R/3 implementation, the three-tiered architecture becomes multi-tiered depending on how the Web
server is configured against the database server or how the Web server Itself distributes the
transaction and presentation logic.
All SAP R/3 business applications use an active dictionary to store all business rules defined to run business. These business and workflow rules keep information flowing among application modules in a controlled and secured fashion. The "ABAP Workbench" is used to develop business programs using the Advanced Business Application Programming (ABAP) language. The Basis technology is responsible for managing R/3 infrastructure such as software installation, operations, and administration.
SAP R/3's multi-tiered architecture enables its customers to deploy R/3 with or without an application server. Common three-tiered architecture consists of the following three layers:
• Data Management
• Application Logic
• Presentation
The Data Management layer manages data storage, the Application layer performs business logic, and the Presentation layer presents information to the end user.
Most often, the Data Management and Application Logic layers are implemented on one machine, whereas workstations are used for presentation functions. This two-tiered application model is suited best for small business applications where transaction volumes are low and business logic is simple.
When the number of users or the volume of transactions increases, separate the application logic from database management functions by configuring one or more application servers against a database server. This three-tiered application model for SAP R/3 keeps operations functioning without performance degradation. Often, additional application servers are configured to process batch jobs or other long and intense resource-consuming tasks. This separation of the application server enables system operations staff to fine-tune individual application servers suited for specific data processing tasks.
A Quick Look at SAP R/3 Architecture and Technologies
Founded in 1972 in Mannheim, Germany, as Systemanalyse und Programmen-twicklung to produce and market standard software for integrated business solutions, today that company is known as SAP (Systems, Applications and Products in Data Processing), headquartered in Walldorf, Germany. SAP built packaged applications for mainframe computers, called SAP R/2. As the client/server technologies emerged in the early 1980s, SAP launched a major initiative to engineer powerful three-tiered integrated business applications under one framework. The SAP R/3 product is the outcome of that initiative.
Note Often, people ask what R/2 and R/3 mean. The letter R stands for real-time, and 2 and 3 represent two-tiered and three-tiered architectures, respectively. SAP R/2 is for mainframes only, whereas SAP R/3 is three-tiered implementation using client/server technology for a wide range of platforms-hardware and software. When implementing a Web front-end to an SAP R/3 implementation, the three-tiered architecture becomes multi-tiered depending on how the Web
server is configured against the database server or how the Web server Itself distributes the
transaction and presentation logic.
All SAP R/3 business applications use an active dictionary to store all business rules defined to run business. These business and workflow rules keep information flowing among application modules in a controlled and secured fashion. The "ABAP Workbench" is used to develop business programs using the Advanced Business Application Programming (ABAP) language. The Basis technology is responsible for managing R/3 infrastructure such as software installation, operations, and administration.
SAP R/3's multi-tiered architecture enables its customers to deploy R/3 with or without an application server. Common three-tiered architecture consists of the following three layers:
• Data Management
• Application Logic
• Presentation
The Data Management layer manages data storage, the Application layer performs business logic, and the Presentation layer presents information to the end user.
Most often, the Data Management and Application Logic layers are implemented on one machine, whereas workstations are used for presentation functions. This two-tiered application model is suited best for small business applications where transaction volumes are low and business logic is simple.
When the number of users or the volume of transactions increases, separate the application logic from database management functions by configuring one or more application servers against a database server. This three-tiered application model for SAP R/3 keeps operations functioning without performance degradation. Often, additional application servers are configured to process batch jobs or other long and intense resource-consuming tasks. This separation of the application server enables system operations staff to fine-tune individual application servers suited for specific data processing tasks.
Evolution of SAP BW
Evolution of SAP BW
A Quick Look at SAP R/3 Architecture and Technologies
Founded in 1972 in Mannheim, Germany, as Systemanalyse und Programmen-twicklung to produce and market standard software for integrated business solutions, today that company is known as SAP (Systems, Applications and Products in Data Processing), headquartered in Walldorf, Germany. SAP built packaged applications for mainframe computers, called SAP R/2. As the client/server technologies emerged in the early 1980s, SAP launched a major initiative to engineer powerful three-tiered integrated business applications under one framework. The SAP R/3 product is the outcome of that initiative.
Note Often, people ask what R/2 and R/3 mean. The letter R stands for real-time, and 2 and 3 represent two-tiered and three-tiered architectures, respectively. SAP R/2 is for mainframes only, whereas SAP R/3 is three-tiered implementation using client/server technology for a wide range of platforms-hardware and software. When implementing a Web front-end to an SAP R/3 implementation, the three-tiered architecture becomes multi-tiered depending on how the Web server is configured against the database server or how the Web server Itself distributes the transaction and presentation logic.
All SAP R/3 business applications use an active dictionary to store all business rules defined to run business. These business and workflow rules keep information flowing among application modules in a controlled and secured fashion. The "ABAP Workbench" is used to develop business programs using the Advanced Business Application Programming (ABAP) language. The Basis technology is responsible for managing R/3 infrastructure such as software installation, operations, and administration.
SAP R/3's multi-tiered architecture enables its customers to deploy R/3 with or without an application server. Common three-tiered architecture consists of the following three layers:
• Data Management
• Application Logic
• Presentation
The Data Management layer manages data storage, the Application layer performs business logic, and the Presentation layer presents information to the end user.
Most often, the Data Management and Application Logic layers are implemented on one machine, whereas workstations are used for presentation functions. This two-tiered application model is suited best for small business applications where transaction volumes are low and business logic is simple.
When the number of users or the volume of transactions increases, separate the application logic from database management functions by configuring one or more application servers against a database server. This three-tiered application model for SAP R/3 keeps operations functioning without performance degradation. Often, additional application servers are configured to process batch jobs or other long and intense resource-consuming tasks. This separation of the application server enables system operations staff to fine-tune individual application servers suited for specific data processing tasks.
Founded in 1972 in Mannheim, Germany, as Systemanalyse und Programmen-twicklung to produce and market standard software for integrated business solutions, today that company is known as SAP (Systems, Applications and Products in Data Processing), headquartered in Walldorf, Germany. SAP built packaged applications for mainframe computers, called SAP R/2. As the client/server technologies emerged in the early 1980s, SAP launched a major initiative to engineer powerful three-tiered integrated business applications under one framework. The SAP R/3 product is the outcome of that initiative.
Note Often, people ask what R/2 and R/3 mean. The letter R stands for real-time, and 2 and 3 represent two-tiered and three-tiered architectures, respectively. SAP R/2 is for mainframes only, whereas SAP R/3 is three-tiered implementation using client/server technology for a wide range of platforms-hardware and software. When implementing a Web front-end to an SAP R/3 implementation, the three-tiered architecture becomes multi-tiered depending on how the Web server is configured against the database server or how the Web server Itself distributes the transaction and presentation logic.
All SAP R/3 business applications use an active dictionary to store all business rules defined to run business. These business and workflow rules keep information flowing among application modules in a controlled and secured fashion. The "ABAP Workbench" is used to develop business programs using the Advanced Business Application Programming (ABAP) language. The Basis technology is responsible for managing R/3 infrastructure such as software installation, operations, and administration.
SAP R/3's multi-tiered architecture enables its customers to deploy R/3 with or without an application server. Common three-tiered architecture consists of the following three layers:
• Data Management
• Application Logic
• Presentation
The Data Management layer manages data storage, the Application layer performs business logic, and the Presentation layer presents information to the end user.
Most often, the Data Management and Application Logic layers are implemented on one machine, whereas workstations are used for presentation functions. This two-tiered application model is suited best for small business applications where transaction volumes are low and business logic is simple.
When the number of users or the volume of transactions increases, separate the application logic from database management functions by configuring one or more application servers against a database server. This three-tiered application model for SAP R/3 keeps operations functioning without performance degradation. Often, additional application servers are configured to process batch jobs or other long and intense resource-consuming tasks. This separation of the application server enables system operations staff to fine-tune individual application servers suited for specific data processing tasks.
Wednesday, April 29, 2009
I am giving System landscape means real time prospects
I am giving System landscape means real time prospects(In My abity View)
Hi, Good Moring Viewers…
Functional Specs are requirements of the business user.Technical Specs translate these requirements in a technical fashion.
Let's say Functional Spec says,1. the user should be able to enter the Key date, Fiscal Year, Fiscal Version.
2. The Company variable should be defaulted to USA but then if the user wants to change it, they can check the drop down list and choose other countries.
3. The calculations or formulas for the report will be displayed in precision of one decimal point.
4. The report should return values for 12 months of data depending on the fiscal year that the user enters Or it should display in quarterly values.
Functional specs are also called as Software requirements.
Now from this Techinal Spec follows, to resolve each of the line items listed above.
1. To give the option of key date, Fiscal year and Fiscal Version – certain Info Obejcts should be availble in the system. If available, then should we create any variables for them - so that they are used as user entry variable. To create any varaibles, what is the approch, where do you do it, what is the technical of the objects you'll use, what'll be the technical name of the objects you'll crete as a result of this report
.2. Same explanation goes for the rest. How do you set up the varaible,
3. What changes in properties willu do to get the precision.
4. How will you get the 12 months of data.
What will be the technical and display name of the report, who'll be authorized to run this report, etc are clearly specified in the technical specs Check the link below for ASAP implementation and roadmaps there you can find what you need.
AcceleratedSAP (ASAP) RoadmapsThe ASAP Roadmaps provide you with proven, practical, comprehensive, repeatable, and rich implementation methodologies that enable speedy, focused implementation of SAP Solutions. ASAP Roadmaps cover the most important aspects and phases of a SAP solutions implementation, enhancements, or upgrade following the AcceleratedSAP (ASAP) principles.The roadmaps are available for browsing and offline use on this site and also delivered as standard component of SAP Solution Manager – the implementation and operations platform.ASAP Roadmaps Deliver transparent, proven approach helping the project team to reduceimplementation time, costs and risks throug efficient implementation process.
ASAP Roadmaps Deliver transparent, proven approach helping the project team to reduceimplementation time, costs and risks throug efficient implementation process.
Achieve better results by leveraging the experiences of other successful projectsKnowledge management - use the Implementation Roadmap for SAP Solutions togather knowledge on how to organize and run your implementation projectsAvailability.
ASAP Implementation RoadmapThe ASAP Implementation Roadmap for SAP Solutions provides proven implementation methodology for implementation of mySAP Business Suite (mySAP ERP, mySAP CRM, mySAP SCM, mySAP PLM, mySAP SRM), SAP xApps, SAP NetWeaver and SAP Solutions for Mobile Business. The methodology covers, among other things, the necessary project management, the configuration of business processes, testing and training aspects as well as technical implementation activities.
ASAP Implementation Roadmap for SAP Enterprise Portal The ASAP Implementation Roadmap for Enterprise Portal provides guidance for the implementation teams embarking on implementation project of SAP Enterprise Portal Solution. The roadmap is a subset of the ASAPImplementation Roadmap and covers steps specific for EP implementation. If your project includes other SAP Solutions we recommend to use the full ASAP Implementation Roadmap.
ASAP Implementation Roadmap for SAP Enterprise Portal The ASAP Implementation Roadmap for Enterprise Portal provides guidance for the implementation teams embarking on implementation project of SAP Enterprise Portal Solution. The roadmap is a subset of the ASAP.
Implementation Roadmap and covers steps specific for EP implementation. If your project includes other SAP Solutions we recommend to use the full ASAP Implementation Roadmap.
ASAP Implementation Roadmap for SAP Exchange Infrastructure The ASAP Implementation Roadmap for Exchange Infrastructure provides guidance for the implementation teams embarking on implementation project of SAP Exchange Infrastructure Solution. The roadmap is a subset of the ASAP Implementation Roadmap and covers steps specific for XI implementation. If your project includes other SAP Solutions we recommend to use the full ASAP Implementation Roadmap.
Solution Management RoadmapThe Solution Management Roadmap provides a methodology for the implementation of the technical infrastructure and its operation. The Solution Management Roadmap complements the Implementation Roadmap.
Global Template Roadmap
The Global Template Roadmap describes how to organize and how to run a project in which a corporate template is developed. The Global Template Roadmap is geared to more complex implementation or harmonization projects, typically involving more than one kind of mySAP solution, and a variety of sites, possibly in different countries. The corporate template is rolled out to other sites in a follow-up project.
Upgrade Roadmap
As a central guidance for the entire project team, the Upgrade Roadmap provides SAP latest upgrade methodology to plan and execute an SAP upgrade. It bundles SAP's latest knowledge and best-practices for basic project management, functional and technical aspects to upgrade an entire SAP system landscape.
Target audienceRoadmaps are relevant for the following roles.
Project manager, project sponsor, key stakeholders
Project team members
Consultants
PartnersBenefits
Provide proven, practical and cost-effective project implementation approach. Flexible, scalable and tailorable to meet Project and Customer needs.
Leverage SAPs vast experience in the implementation, upgrade and operations of its Solutions as well as industry recognized best practices for effective Business Solutions.
Extends across all aspects of the solution life-cycle; from strategic reviews and analysis, to design, implementation, training and post project support.
Is scalable and can be tailored to meet customer and project specific requirements and constraints.Supports different project types (single-site, multi-site, template, prototype, upgrade, evaluation, etc.)
Has been developed over many years to deliver cost-effective and successful implementation and is being continually enriched with content based on the experiences gained in implementing SAP Solutions.
Hi, Good Moring Viewers…
Functional Specs are requirements of the business user.Technical Specs translate these requirements in a technical fashion.
Let's say Functional Spec says,1. the user should be able to enter the Key date, Fiscal Year, Fiscal Version.
2. The Company variable should be defaulted to USA but then if the user wants to change it, they can check the drop down list and choose other countries.
3. The calculations or formulas for the report will be displayed in precision of one decimal point.
4. The report should return values for 12 months of data depending on the fiscal year that the user enters Or it should display in quarterly values.
Functional specs are also called as Software requirements.
Now from this Techinal Spec follows, to resolve each of the line items listed above.
1. To give the option of key date, Fiscal year and Fiscal Version – certain Info Obejcts should be availble in the system. If available, then should we create any variables for them - so that they are used as user entry variable. To create any varaibles, what is the approch, where do you do it, what is the technical of the objects you'll use, what'll be the technical name of the objects you'll crete as a result of this report
.2. Same explanation goes for the rest. How do you set up the varaible,
3. What changes in properties willu do to get the precision.
4. How will you get the 12 months of data.
What will be the technical and display name of the report, who'll be authorized to run this report, etc are clearly specified in the technical specs Check the link below for ASAP implementation and roadmaps there you can find what you need.
AcceleratedSAP (ASAP) RoadmapsThe ASAP Roadmaps provide you with proven, practical, comprehensive, repeatable, and rich implementation methodologies that enable speedy, focused implementation of SAP Solutions. ASAP Roadmaps cover the most important aspects and phases of a SAP solutions implementation, enhancements, or upgrade following the AcceleratedSAP (ASAP) principles.The roadmaps are available for browsing and offline use on this site and also delivered as standard component of SAP Solution Manager – the implementation and operations platform.ASAP Roadmaps Deliver transparent, proven approach helping the project team to reduceimplementation time, costs and risks throug efficient implementation process.
ASAP Roadmaps Deliver transparent, proven approach helping the project team to reduceimplementation time, costs and risks throug efficient implementation process.
Achieve better results by leveraging the experiences of other successful projectsKnowledge management - use the Implementation Roadmap for SAP Solutions togather knowledge on how to organize and run your implementation projectsAvailability.
ASAP Implementation RoadmapThe ASAP Implementation Roadmap for SAP Solutions provides proven implementation methodology for implementation of mySAP Business Suite (mySAP ERP, mySAP CRM, mySAP SCM, mySAP PLM, mySAP SRM), SAP xApps, SAP NetWeaver and SAP Solutions for Mobile Business. The methodology covers, among other things, the necessary project management, the configuration of business processes, testing and training aspects as well as technical implementation activities.
ASAP Implementation Roadmap for SAP Enterprise Portal The ASAP Implementation Roadmap for Enterprise Portal provides guidance for the implementation teams embarking on implementation project of SAP Enterprise Portal Solution. The roadmap is a subset of the ASAPImplementation Roadmap and covers steps specific for EP implementation. If your project includes other SAP Solutions we recommend to use the full ASAP Implementation Roadmap.
ASAP Implementation Roadmap for SAP Enterprise Portal The ASAP Implementation Roadmap for Enterprise Portal provides guidance for the implementation teams embarking on implementation project of SAP Enterprise Portal Solution. The roadmap is a subset of the ASAP.
Implementation Roadmap and covers steps specific for EP implementation. If your project includes other SAP Solutions we recommend to use the full ASAP Implementation Roadmap.
ASAP Implementation Roadmap for SAP Exchange Infrastructure The ASAP Implementation Roadmap for Exchange Infrastructure provides guidance for the implementation teams embarking on implementation project of SAP Exchange Infrastructure Solution. The roadmap is a subset of the ASAP Implementation Roadmap and covers steps specific for XI implementation. If your project includes other SAP Solutions we recommend to use the full ASAP Implementation Roadmap.
Solution Management RoadmapThe Solution Management Roadmap provides a methodology for the implementation of the technical infrastructure and its operation. The Solution Management Roadmap complements the Implementation Roadmap.
Global Template Roadmap
The Global Template Roadmap describes how to organize and how to run a project in which a corporate template is developed. The Global Template Roadmap is geared to more complex implementation or harmonization projects, typically involving more than one kind of mySAP solution, and a variety of sites, possibly in different countries. The corporate template is rolled out to other sites in a follow-up project.
Upgrade Roadmap
As a central guidance for the entire project team, the Upgrade Roadmap provides SAP latest upgrade methodology to plan and execute an SAP upgrade. It bundles SAP's latest knowledge and best-practices for basic project management, functional and technical aspects to upgrade an entire SAP system landscape.
Target audienceRoadmaps are relevant for the following roles.
Project manager, project sponsor, key stakeholders
Project team members
Consultants
PartnersBenefits
Provide proven, practical and cost-effective project implementation approach. Flexible, scalable and tailorable to meet Project and Customer needs.
Leverage SAPs vast experience in the implementation, upgrade and operations of its Solutions as well as industry recognized best practices for effective Business Solutions.
Extends across all aspects of the solution life-cycle; from strategic reviews and analysis, to design, implementation, training and post project support.
Is scalable and can be tailored to meet customer and project specific requirements and constraints.Supports different project types (single-site, multi-site, template, prototype, upgrade, evaluation, etc.)
Has been developed over many years to deliver cost-effective and successful implementation and is being continually enriched with content based on the experiences gained in implementing SAP Solutions.
SAP System Landscape Directory
SAP System Landscape Directory
Purpose
A modern computing environment consists of a number of hardware and software components that depend on each other with regard to installation, software updates, and demands on interfaces. The SAP System Landscape Directory (SLD) simplifies the administration of your system landscape.
The SLD is a server application that communicates with a client application by using the Hypertext Transfer Protocol (HTTP). The SLD server contains component information, a landscape description, and a name reservation, which are based on the standard Common Information Model (CIM). The CIM standard is a general schema for describing the elements in a system landscape. This standard is independent of any implementation.
Features
The component description provides information about all available SAP software modules. This includes version numbers, current patch level, and dependencies between landscape components. SAP makes this information available to its customers. You can download the current component description from SAP Service Marketplace, which then updates your local component description (see SAP Note 669669). It is also possible to add instances for third-party components to the component description.
The system landscape description represents the exact model of an actual system landscape. Together with the current component description, the system description provides information for various processes (the system administration and implementation, for example).
The example below shows a possible scenario that illustrates how the component and system landscape description functions.
Example
On the left-hand side of the following graphic is the master description for all existing SAP software modules. SAP maintains this information. The local component description on the right-hand side (client side) can be updated in accordance with the master description.
An installed mySAP.com component is registered in the System Landscape Directory. The component description contains information about the installed components. If, for example, a new Support Package is available for this component, SAP publishes this information using the master description. In this way, the customers receive all the latest information relevant for their system landscape promptly.
Architecture and System Landscape (BW-BPS)
Definition
There are three basic possibilities for configuring BW and BW-BPS systems.
1. Centralized: BW system and BW-BPS share data, structure and database.
2. Remote: BW-BPS (local) has a remote connection to the BW system (remote).
3. Separate: Separation of BW system functions and BW-BPS functions.
These configuration options do not restrict the functionality or the features of BW-BPS, they simply address different business requirements.
Use
There are three areas which need particular consideration when defining and implementing BW-BPS applications:
· System availability
· Performance
· Patches and upgrades
It is also important to remember that the BW system is also used by non-BW-BPS users. As a result, the following key issues arise:
· Cost-efficiency, legal and security requirements
· Periodic usage of planning tools
· Data redundancies
· Data integration - combining and using plan data and non-BW-BPS data conjointly
· Routine work and work related to patches and upgrades
· Administration work and costs
· System costs
Choosing the right system configuration is very important. It is possible to switch from one configuration to another but this involves a large outlay in terms of time, costs, and administrative efforts.
The most important characteristics of the different system configuration options named above will now be listed.
Centralized
· The BW system and BW-BPS are on the same server/system; they use the same system landscape (DEV, QA, PROD).
· The data and structures are stored on the same server in the same database.
· BW patches and upgrades are implemented simultaneously for the BW system and for BW-BPS.
Remote
· The BW system and BW-BPS are on different servers/systems. BW-BPS (local) has a remote connection to the BW system (remote).
· BW-BPS is configured in the local BW-BPS system.
· Data and structures are stored on the same database.
· BW-BPS only uses the structures of the remote BW system.
· BW-BPS reads and writes data straight from the remote BW system.
· BW patches and upgrades are implemented on the respective servers for the BW system and for BW-BPS and can therefore be implemented independently of each other.
Separate
· The BW system and BW-BPS run on different systems that are independent of each other.
· Configuration, structures and data from the BW system and BW-BPS are stored on different (that is their own) servers and databases.
· Users of BW-BPS and the “general” BW systems use different (that is their own) system landscapes (DEV, QA, PROD).
· Data from BW-BPS and the BW system can be loaded to and from each system using BW data marts.
· BW patches and upgrades are implemented on the respective servers for the BW system and for BW-BPS and can therefore be implemented independently of each other.
Advantages and Disadvantages of System Configuration Options
The following table offers an overview of the advantages and disadvantages of these three options:
following table offers an overview of the advantages and disadvantages of these three options:
Centralized
Remote
Separate
Data integration
No data redundancy
Ease of system maintenance
Access to planning and reporting
Low costs for system landscape
Separation of BW and BW-BPS
Ease of security setup/maintenance
Reduced release-dependency
Ability to fine-tune
ASAP Methodologies
ASAP Methodologies
ASAP stands for Accelerated SAP. Its purpose is to help design SAP implementation in the most efficient manner possible. Its goal is to effectively optimize time, people, quality and other resources, using a proven methodology to implementation.ASAP focuses on tools and training, wrapped up in a five-phase process oriented road map for guiding implementation.The road map is composed of five well-known consecutive phases:
• Phase 1 Project Preparation
• Phase 2 Business Blueprint
• Phase 3 Realization
• Phase 4 Final Preparation
• Phase 5 Go-Live and supportIn today's post we will discuss the first phase.
Phase 1 : Project PreparationPhase
1 initiates with a retrieval of information and resources. It is an important time to assemble the necessary components for the implementation. Some important milestones that need to be accomplished for phase 1 include
• Obtaining senior-level management/stakeholder support
• identifying clear project objectives
• architect an efficient decision-making process
• creating an environment suitable for change and re-engineering
• building a qualified and capable project team.
Senior level management support:
One of the most important milestones with phase 1 of ASAP is the full agreement and cooperation of the important company decision-makers - key stake holders and others. Their backing and support is crucial for a successful implementation.
Clear project objectives:
be concise in defining what your objectives and expectations are for this venture. Vague or unclear notions of what you hope to obtain with SAP will handicap the implementation process. Also make sure that your expectations are reasonable considering your company's resources. It is essential to have clearly defined ideas, goals and project plans devised before moving forward.
An efficient decision making process:
One obstacle that often stalls implementation is a poorly constructed decision-making process. Before embarking on this venture, individuals need to be clearly identified. Decide now who is responsible for different decisions along the way. From day one, the implementation decision makers and project leaders from each area must be aware of the onus placed on them to return good decisions quickly.
Environment suitable for change and re engineering: Your team must be willing to accept that, along with new SAP software, things are going to change, the business will change, and information technology enabling the business will change as well. By implementing SAP, you will essentially redesign your current practices to model more efficient or predefined best business practices as espoused by SAP. Resistance to this change will impede the progress of your implementation.
ASAP- Second Phase- Business Blueprint
SAP has defined a business blueprint phase to help extract pertinent information about your company that is necessary for implementation. These blueprints are in the form of questionnaires that are designed to probe for information that uncovers how your company does business. As such, they also serve to document the implementation. Each business blueprint document essentially outlines your future business processes and business requirements. The kinds of questions asked are germane to the particular business function, as seen in the following sample questions:
1) What information do you capture on a purchase order?
2) What information is required to complete a purchase order?
Accelerated SAP question and answer database:
The question and answer database (QADB) is a simple although aging tool designed to facilitate the creation and maintenance of your business blueprint. This database stores the questions and the answers and serves as the heart of your blue print. Customers are provided with a customer input template for each application that collects the data. The question and answer format is standard across applications to facilitate easier use by the project team.
Issues database:
Another tool used in the blueprinting phase is the issues database. This database stores any open concerns and pending issues that relate to the implementation. Centrally storing this information assists in gathering and then managing issues to resolution, so that important matters do not fall through the cracks. You can then track the issues in database, assign them to team members, and update the database accordingly.
ASAP Phase- 3 - Realization:
With the completion of the business in phase 2, "functional" experts are now ready to begin configuring SAP. The Realization phase is broken in to two parts.
1) Your SAP consulting team helps you configure your baseline system, called the baseline configuration.
2) Your implementation project team fine-tunes that system to meet all your business and process requirements as part of the fine tuning configuration.
The initial configuration completed during the base line configuration is based on the information that you provided in your blueprint document. The remaining approximately 20% of your configuration that was not tackled during the baseline configuration is completed during the fine tuning configuration. Fine tuning usually deals with the exceptions that are not covered in baseline configuration. This final bit of tweaking represents the work necessary to fit your special needs.
Configuration Testing:
With the help of your SAP consulting team, you segregate your business processes into cycles of related business flows. The cycles serve as independent units that enable you to test specific parts of the business process. You can also work through configuring the SAP implementation guide (IMG). A tool used to assist you in configuring your SAP system in a step by step manner.
Knowledge Transfer:
As the configuration phase comes to a close, it becomes necessary for the Project team to be self-sufficient in their knowledge of the configuration of your SAP system. Knowledge transfer to the configuration team tasked with system maintenance (that is, maintenance of the business processes after Go-live) needs to be completed at this time.In addition, the end users tasked with actually using the system for day-to-day business purposes must be trained.
ASAP Methodology - Phase 4 - Final Preparation:
As phase 3 merges into phase 4, you should find yourselves not only in the midst of SAP training, but also in the midst of rigorous functional and stress testing. Phase 4 also concentrates on the fine tuning of your configuration before Go-live and more importantly, the migration of data from your old system or systems to SAP.
Workload testing (including peak volume, daily load, and other forms of stress testing), and integration or functional testing are conducted to ensure the accuracy of your data and the stability of your SAP system. Because you should have begun testing back in phase 2, you do not have too far to go until Go-live. Now is an important time to perform preventative maintenance checks to ensure optimal performance at your SAP system.At the conclusion of phase 4, take time to plan and document a Go-live strategy. Preparation for Go-live means preparing for your end-users questions as they start actively working on the new SAP system.
ASAP - Phase 5 - Go-live and Support:
The Go-live milestone is itself is easy to achieve; a smooth and uneventful Go-live is another matter altogether. Preparation is the key, including attention to what-if scenarios related not only to the individual business processes deployed but also to the functioning of technology underpinning these business processes and preparation for ongoing support, including maintenance contracts and documented processes and procedures are essential.
ASAP stands for Accelerated SAP. Its purpose is to help design SAP implementation in the most efficient manner possible. Its goal is to effectively optimize time, people, quality and other resources, using a proven methodology to implementation.ASAP focuses on tools and training, wrapped up in a five-phase process oriented road map for guiding implementation.The road map is composed of five well-known consecutive phases:
• Phase 1 Project Preparation
• Phase 2 Business Blueprint
• Phase 3 Realization
• Phase 4 Final Preparation
• Phase 5 Go-Live and supportIn today's post we will discuss the first phase.
Phase 1 : Project PreparationPhase
1 initiates with a retrieval of information and resources. It is an important time to assemble the necessary components for the implementation. Some important milestones that need to be accomplished for phase 1 include
• Obtaining senior-level management/stakeholder support
• identifying clear project objectives
• architect an efficient decision-making process
• creating an environment suitable for change and re-engineering
• building a qualified and capable project team.
Senior level management support:
One of the most important milestones with phase 1 of ASAP is the full agreement and cooperation of the important company decision-makers - key stake holders and others. Their backing and support is crucial for a successful implementation.
Clear project objectives:
be concise in defining what your objectives and expectations are for this venture. Vague or unclear notions of what you hope to obtain with SAP will handicap the implementation process. Also make sure that your expectations are reasonable considering your company's resources. It is essential to have clearly defined ideas, goals and project plans devised before moving forward.
An efficient decision making process:
One obstacle that often stalls implementation is a poorly constructed decision-making process. Before embarking on this venture, individuals need to be clearly identified. Decide now who is responsible for different decisions along the way. From day one, the implementation decision makers and project leaders from each area must be aware of the onus placed on them to return good decisions quickly.
Environment suitable for change and re engineering: Your team must be willing to accept that, along with new SAP software, things are going to change, the business will change, and information technology enabling the business will change as well. By implementing SAP, you will essentially redesign your current practices to model more efficient or predefined best business practices as espoused by SAP. Resistance to this change will impede the progress of your implementation.
ASAP- Second Phase- Business Blueprint
SAP has defined a business blueprint phase to help extract pertinent information about your company that is necessary for implementation. These blueprints are in the form of questionnaires that are designed to probe for information that uncovers how your company does business. As such, they also serve to document the implementation. Each business blueprint document essentially outlines your future business processes and business requirements. The kinds of questions asked are germane to the particular business function, as seen in the following sample questions:
1) What information do you capture on a purchase order?
2) What information is required to complete a purchase order?
Accelerated SAP question and answer database:
The question and answer database (QADB) is a simple although aging tool designed to facilitate the creation and maintenance of your business blueprint. This database stores the questions and the answers and serves as the heart of your blue print. Customers are provided with a customer input template for each application that collects the data. The question and answer format is standard across applications to facilitate easier use by the project team.
Issues database:
Another tool used in the blueprinting phase is the issues database. This database stores any open concerns and pending issues that relate to the implementation. Centrally storing this information assists in gathering and then managing issues to resolution, so that important matters do not fall through the cracks. You can then track the issues in database, assign them to team members, and update the database accordingly.
ASAP Phase- 3 - Realization:
With the completion of the business in phase 2, "functional" experts are now ready to begin configuring SAP. The Realization phase is broken in to two parts.
1) Your SAP consulting team helps you configure your baseline system, called the baseline configuration.
2) Your implementation project team fine-tunes that system to meet all your business and process requirements as part of the fine tuning configuration.
The initial configuration completed during the base line configuration is based on the information that you provided in your blueprint document. The remaining approximately 20% of your configuration that was not tackled during the baseline configuration is completed during the fine tuning configuration. Fine tuning usually deals with the exceptions that are not covered in baseline configuration. This final bit of tweaking represents the work necessary to fit your special needs.
Configuration Testing:
With the help of your SAP consulting team, you segregate your business processes into cycles of related business flows. The cycles serve as independent units that enable you to test specific parts of the business process. You can also work through configuring the SAP implementation guide (IMG). A tool used to assist you in configuring your SAP system in a step by step manner.
Knowledge Transfer:
As the configuration phase comes to a close, it becomes necessary for the Project team to be self-sufficient in their knowledge of the configuration of your SAP system. Knowledge transfer to the configuration team tasked with system maintenance (that is, maintenance of the business processes after Go-live) needs to be completed at this time.In addition, the end users tasked with actually using the system for day-to-day business purposes must be trained.
ASAP Methodology - Phase 4 - Final Preparation:
As phase 3 merges into phase 4, you should find yourselves not only in the midst of SAP training, but also in the midst of rigorous functional and stress testing. Phase 4 also concentrates on the fine tuning of your configuration before Go-live and more importantly, the migration of data from your old system or systems to SAP.
Workload testing (including peak volume, daily load, and other forms of stress testing), and integration or functional testing are conducted to ensure the accuracy of your data and the stability of your SAP system. Because you should have begun testing back in phase 2, you do not have too far to go until Go-live. Now is an important time to perform preventative maintenance checks to ensure optimal performance at your SAP system.At the conclusion of phase 4, take time to plan and document a Go-live strategy. Preparation for Go-live means preparing for your end-users questions as they start actively working on the new SAP system.
ASAP - Phase 5 - Go-live and Support:
The Go-live milestone is itself is easy to achieve; a smooth and uneventful Go-live is another matter altogether. Preparation is the key, including attention to what-if scenarios related not only to the individual business processes deployed but also to the functioning of technology underpinning these business processes and preparation for ongoing support, including maintenance contracts and documented processes and procedures are essential.
ASAP Methodologies SAP
ASAP Methodologies
ASAP stands for Accelerated SAP. Its purpose is to help design SAP implementation in the most efficient manner possible. Its goal is to effectively optimize time, people, quality and other resources, using a proven methodology to implementation.ASAP focuses on tools and training, wrapped up in a five-phase process oriented road map for guiding implementation.The road map is composed of five well-known consecutive phases:•
Phase 1 Project Preparation
Phase 2 Business Blueprint
Phase 3 Realization
Phase 4 Final Preparation
Phase 5 Go-Live and support
In today's post we will discuss the first phase.
Phase 1 : Project PreparationPhase 1 initiates with a retrieval of information and resources. It is an important time to assemble the necessary components for the implementation. Some important milestones that need to be accomplished for phase 1 include
• Obtaining senior-level management/stakeholder support
• identifying clear project objectives
• architect an efficient decision-making process
• creating an environment suitable for change and re-engineering
• building a qualified and capable project team.
Senior level management support:One of the most important milestones with phase 1 of ASAP is the full agreement and cooperation of the important company decision-makers - key stake holders and others. Their backing and support is crucial for a successful implementation.Clear project objectives:be concise in defining what your objectives and expectations are for this venture. Vague or unclear notions of what you hope to obtain with SAP will handicap the implementation process. Also make sure that your expectations are reasonable considering your company's resources. It is essential to have clearly defined ideas, goals and project plans devised before moving forward.An efficient decision making process:One obstacle that often stalls implementation is a poorly constructed decision-making process. Before embarking on this venture, individuals need to be clearly identified. Decide now who is responsible for different decisions along the way. From day one, the implementation decision makers and project leaders from each area must be aware of the onus placed on them to return good decisions quickly.
Environment suitable for change and re engineering: Your team must be willing to accept that, along with new SAP software, things are going to change, the business will change, and information technology enabling the business will change as well. By implementing SAP, you will essentially redesign your current practices to model more efficient or predefined best business practices as espoused by SAP. Resistance to this change will impede the progress of your implementation.
ASAP- Second Phase- Business Blueprint
SAP has defined a business blueprint phase to help extract pertinent information about your company that is necessary for implementation. These blueprints are in the form of questionnaires that are designed to probe for information that uncovers how your company does business. As such, they also serve to document the implementation. Each business blueprint document essentially outlines your future business processes and business requirements. The kinds of questions asked are germane to the particular business function, as seen in the following sample questions:
1) What information do you capture on a purchase order?
2) What information is required to complete a purchase order?
Accelerated SAP question and answer database:
The question and answer database (QADB) is a simple although aging tool designed to facilitate the creation and maintenance of your business blueprint. This database stores the questions and the answers and serves as the heart of your blue print. Customers are provided with a customer input template for each application that collects the data. The question and answer format is standard across applications to facilitate easier use by the project team.
Issues database:Another tool used in the blueprinting phase is the issues database. This database stores any open concerns and pending issues that relate to the implementation. Centrally storing this information assists in gathering and then managing issues to resolution, so that important matters do not fall through the cracks. You can then track the issues in database, assign them to team members, and update the database accordingly.
ASAP Phase- 3 - Realization:
With the completion of the business in phase 2, "functional" experts are now ready to begin configuring SAP. The Realization phase is broken in to two parts.
1) Your SAP consulting team helps you configure your baseline system, called the baseline configuration.
2) Your implementation project team fine-tunes that system to meet all your business and process requirements as part of the fine tuning configuration.
Saturday, April 11, 2009
What are the Business content Cubes, ODS and some other objects in SD,MM, FI-Co modules we use regularly in implementation.
I can give the process fllow of different modules!
SD Flow
You create a sales document to enter information about different sales transactions. R/3 provides a number of predefined sales document types. However , these can be customized to suit your company's needs when R/3 is installed.
Some examples of sales documents include:
• sales queries
• sales orders
• outline agreements
• complaints
You use sales queries to enter information about potential sales into R/3.Types of sales query documents include:
• inquiries
• quotations
• free-of-charge deliveries
An inquiry is used to record any general queries a customer may have about goods or services they
are thinking of buying from your company. An inquiry is one of the first possible documents you can
create in the customer order management cycle. An example of the type of information contained in an inquiry is whether your company stocks a certain product line. Along with entering general customer queries, you can use inquiries to record the goods or services that a customer is interested in. And you can enter descriptions of goods or services that your company should research in order to answer customer queries. You can carry out automatic pricing for any goods or services you enter in an inquiry. This will enter the price of goods or services into the inquiry for you. You can also check whether any goods you entered in the inquiry are available in your company's warehouse. The order probability function enables you to determine the likelihood that a customer will buy from you. To increase the probability of a sale, you can offer the customer alternative goods and services.
Quotations are sales query documents that you create when a customer requests specific information
about a product. For example, you can use a quotation if a customer makes a query regarding how much goods or services cost or you can use a query if a customer asks when goods will be available for shipping.
You can create quotations from scratch or you can create them by copying inquiries. If a customer is
interested in the products or services after they have made an inquiry, you can provide a quotation based on the original inquiry. R/3 allows you to copy the information directly from an inquiry to a quotation.
Let's say an inquiry was created when a customer inquired whether your company, could manufacture
twenty motorcycles. Assume a quotation was created by copying this inquiry when the customer called
back to inquire how much twenty motorcycles would cost. You can use quotations to enter information and descriptions for goods and services that are to be researched. You can also use them to carry out automatic pricing and to check goods availability. You can use quotations to calculate the probability that a customer will buy the goods or services entered on a quotation. This function is called order probability. You can also use quotations to enter details about alternative goods or services. These are goods or services that a customer did not inquire about but that you think they will consider purchasing. Once you have created a quotation for a query in R/3, you send the quotation to the customer who made the query. The quotation represents a binding offer made to the customer that includes quantity and cost details.
You create a free of charge delivery when you send free samples of any goods that your company
produces to customers. These contain information about the goods that are delivered but they don't
include the corresponding pricing information for them.
Let's look at the sales orders that exist in R/3.You create a sales order when a customer has ordered
goods or services from your company. They are a part of the customer order management cycle.
You can carry out automatic pricing in sales orders to enter the price of goods or services.
R/3 will also run a credit check on the customer to see if they will be exceeding their credit limit.
You can also check whether ordered goods will be available in your company's warehouse for delivery.
Examples of types of sales order include
• standard orders
• consignment orders
• cash orders
• rush orders
You create standard orders for goods and services that will be delivered or rendered according to
the standard R/3 sales cycle. This means that goods are ordered, picked from the warehouse, and
then shipped before customers are billed for them. Likewise, services are rendered before customers
are billed for them.
Your company may store its goods in its customers' warehouses. You create a consignment order when a customer is ready to retrieve stock from the warehouse.
SAP can propose the most suitable stock to retrieve, including third-party stock.
A consigment order is like a standard sales order for goods but it doesn't have any delivery
information.
You create cash orders and rush orders for the sale of goods only.
You create a cash order when a customer picks up and pays for a delivery as soon
as it is ordered. And you create a rush order when the customer picks up the goods on the
same day as the order is placed. In this case, the invoice is created later.
You can arrange to deliver goods or render services in installments. To do this, you create an
outline agreement. Examples of some types of outline agreement include :
• quantity and value contracts
• master contracts
• scheduling agreements
• service contracts
You create a quantity contract if a customer has agreed to order a certain quantity of goods from your company during a specified period.
And you create a value contract if a customer has agreed to order goods of a certain cumulative value from your company during a specified period.
Quantity and value contracts do not include delivery dates, so releases are made using a sales order.
You can unite multiple contracts in a single master contract.
Let's say you create a quantity contract because a customer has agreed to order 500 engines in the first six months of the current year. If the customer orders 100 of these engines in January, you create a sales order called a release order.You refer to a quantity contract in a release order. So you refer to the quantity contract created for the 500 engines in each release order created for these engines. R/3 will then update the quantity contract automatically so it contains the correct number of remaining engines to be ordered.
Scheduling agreements specify the installments in which goods will be delivered to a customer. They include the quantity of a product that will be delivered in each installment. And they include the delivery date of each installment. You process a delivery for each installment contained in the scheduling agreement in the same way that you process a delivery for a regular sales order.No sales documents, such as release orders, are created before the products included on a scheduling agreement are processed for delivery.
You create a service contract if a customer requests a service over a particular period of time. For example, you could create a service contract if a customer ordered five one-hour maintenance checks from your company's motorcycle repair department.
You create complaint sales documents if there has been a fault with any goods that have been delivered, or with any services rendered, by your company.
For example, you create complaint sales documents if customers have been billed
incorrectly for an item or service, or if goods are faulty.
Different types of complaint sales document include
• returns
• credit memo requests
• debit memo requests
You create a returns document if a customer returns goods they have purchased from you because they are not satisfied with them. You can create returns from scratch or you can create them by copying the sales order that was originally created for the returned delivery.
A returns document records that you expect stock to be returned to your warehouse.
You can create one or more credit memo requests if a customer has been overcharged for a quantity of goods or services. You can also create a credit memo request if goods were damaged during transit and you want to credit the customer for the goods damaged.
When you create a credit memo request, your Accounting department reviews it to confirm that it can be justified. If the credit memo request is approved, the Accounting department creates a credit memo based on the request. You can create credit memo requests by copying other sales documents such as the sales order where the overcharge occurred.
You create debit memo requests when customers have been undercharged for products or services. Your company’s Accounting department can then create an invoice to bill the undercharged customer.
This document is adopted from Smart Force Campus Course Material
____________ _________ _________ _____
MM Flow
PR >Release the PR>RFQ>Quotation>Quotation Comparison>PO>Release the PO>GR>Invoice Verification
MM Process flow:
Process Flow
The typical procurement cycle for a service or material consists of the following phases:
1. Determination of Requirements
Materials requirements are identified either in the user departments or via materials planning and control. (This can cover both MRP proper and the demand-based approach to inventory control. The regular checking of stock levels of materials defined by master records, use of the order-point method, and forecasting on the basis of past usage are important aspects of the latter.) You can enter purchase requisitions yourself, or they can be generated automatically by the materials planning and control system.
2. Source Determination
The Purchasing component helps you identify potential sources of supply based on past orders and existing longer-term purchase agreements. This speeds the process of creating requests for quotation (RFQs), which can be sent to vendors electronically via SAP EDI, if desired.
3. Vendor Selection and Comparison of Quotations
The system is capable of simulating pricing scenarios, allowing you to compare a number of different quotations. Rejection letters can be sent automatically.
4. Purchase Order Processing
The Purchasing system adopts information from the requisition and the quotation to help you create a purchase order. As with purchase requisitions, you can generate Pos yourself or have the system generate them automatically. Vendor scheduling agreements and contracts (in the SAP System, types of longer-term purchase agreement) are also supported.
5. Purchase Order Follow-Up
The system checks the reminder periods you have specified and - if necessary - automatically prints reminders or expediters at the predefined intervals. It also provides you with an up-to-date status of all purchase requisitions, quotations, and purchase orders.
6. Goods Receiving and Inventory Management
Goods Receiving personnel can confirm the receipt of goods simply by entering the Po number. By specifying permissible tolerances, buyers can limit over- and under deliveries of ordered goods.
7. Invoice Verification
The system supports the checking and matching of invoices. The accounts payable clerk is notified of quantity and price variances because the system has access to PO and goods receipt data. This speeds the process of auditing and clearing invoices for payment.
Pur info record is nothing but a master data like thing which will be maintained for different materials to determine the prices etc.It Specifies the number that uniquely identifies a record.
For Example: an info record is based on Plant Vendor and Material Based on these three the Material Prices will be calculated for different combinations different values are taken into consideration.
During pricing it brings these values automatically based on this info record.
Use ME11 Tcode to create this record.
Common Tables used by SAP MM
Below are few important Common Tables used in Materials Management Modules:
EINA Purchasing Info Record- General Data
EINE Purchasing Info Record- Purchasing Organization Data
MAKT Material Descriptions
MARA General Material Data
MARC Plant Data for Material
MARD Storage Location Data for Material
MAST Material to BOM Link
MBEW Material Valuation
MKPF Header- Material Document
MSEG Document Segment- Material
MVER Material Consumption
MVKE Sales Data for materials
RKPF Document Header- Reservation
T023 Mat. groups
T024 Purchasing Groups
T156 Movement Type
T157H Help Texts for Movement Types
MOFF Lists what views have not been created
A501 Plant/Material
EBAN Purchase Requisition
EBKN Purchase Requisition Account Assignment
EKAB Release Documentation
EKBE History per Purchasing Document
EKET Scheduling Agreement Schedule Lines
EKKN Account Assignment in Purchasing Document
EKKO Purchasing Document Header
EKPO Purchasing Document Item
IKPF Header- Physical Inventory Document
ISEG Physical Inventory Document Items
LFA1 Vendor Master (General section)
LFB1 Vendor Master (Company Code)
NRIV Number range intervals
RESB Reservation/ dependent requirements
T161T Texts for Purchasing Document Types
Tcodes:
RFQ to Vendor - ME41
Raising Quotation - ME47
Comparison of Price - ME49
Creation of PO - ME21N
Goods Receipt - MIGO
Invoice (Bill PAssing) - MIRO
Goods Issue - MB1A
Physical Inventory - MI01( Create doc)
MI04 (Enter Count)
MI07 (Post)
____________ _________ _
FICO
The FI module has 8 sub modules:
FI-GL: General Ledger Accounting
FI-LC: Consolidation
FI-AP : Accounts Payable
FI-AR : Accounts Receivable
FI-BL : Bank Accounting
FI-AA :Asset Accounting
FI-SL : Special Purpose Ledger
FI-FM : Funds Management
CO Controlling
represents the company's flow of cost and revenue. It is a management instrument for organizational decisions. It too is automatically updated as events occur.
The CO module has following sub modules:
CO-OM : Overhead Costing (Cost Centers, Activity Based Costing, Internal Order Costing)
CO-PA : Profitability Analysis
CO-PC : Product Cost Controlling
SD Flow
You create a sales document to enter information about different sales transactions. R/3 provides a number of predefined sales document types. However , these can be customized to suit your company's needs when R/3 is installed.
Some examples of sales documents include:
• sales queries
• sales orders
• outline agreements
• complaints
You use sales queries to enter information about potential sales into R/3.Types of sales query documents include:
• inquiries
• quotations
• free-of-charge deliveries
An inquiry is used to record any general queries a customer may have about goods or services they
are thinking of buying from your company. An inquiry is one of the first possible documents you can
create in the customer order management cycle. An example of the type of information contained in an inquiry is whether your company stocks a certain product line. Along with entering general customer queries, you can use inquiries to record the goods or services that a customer is interested in. And you can enter descriptions of goods or services that your company should research in order to answer customer queries. You can carry out automatic pricing for any goods or services you enter in an inquiry. This will enter the price of goods or services into the inquiry for you. You can also check whether any goods you entered in the inquiry are available in your company's warehouse. The order probability function enables you to determine the likelihood that a customer will buy from you. To increase the probability of a sale, you can offer the customer alternative goods and services.
Quotations are sales query documents that you create when a customer requests specific information
about a product. For example, you can use a quotation if a customer makes a query regarding how much goods or services cost or you can use a query if a customer asks when goods will be available for shipping.
You can create quotations from scratch or you can create them by copying inquiries. If a customer is
interested in the products or services after they have made an inquiry, you can provide a quotation based on the original inquiry. R/3 allows you to copy the information directly from an inquiry to a quotation.
Let's say an inquiry was created when a customer inquired whether your company, could manufacture
twenty motorcycles. Assume a quotation was created by copying this inquiry when the customer called
back to inquire how much twenty motorcycles would cost. You can use quotations to enter information and descriptions for goods and services that are to be researched. You can also use them to carry out automatic pricing and to check goods availability. You can use quotations to calculate the probability that a customer will buy the goods or services entered on a quotation. This function is called order probability. You can also use quotations to enter details about alternative goods or services. These are goods or services that a customer did not inquire about but that you think they will consider purchasing. Once you have created a quotation for a query in R/3, you send the quotation to the customer who made the query. The quotation represents a binding offer made to the customer that includes quantity and cost details.
You create a free of charge delivery when you send free samples of any goods that your company
produces to customers. These contain information about the goods that are delivered but they don't
include the corresponding pricing information for them.
Let's look at the sales orders that exist in R/3.You create a sales order when a customer has ordered
goods or services from your company. They are a part of the customer order management cycle.
You can carry out automatic pricing in sales orders to enter the price of goods or services.
R/3 will also run a credit check on the customer to see if they will be exceeding their credit limit.
You can also check whether ordered goods will be available in your company's warehouse for delivery.
Examples of types of sales order include
• standard orders
• consignment orders
• cash orders
• rush orders
You create standard orders for goods and services that will be delivered or rendered according to
the standard R/3 sales cycle. This means that goods are ordered, picked from the warehouse, and
then shipped before customers are billed for them. Likewise, services are rendered before customers
are billed for them.
Your company may store its goods in its customers' warehouses. You create a consignment order when a customer is ready to retrieve stock from the warehouse.
SAP can propose the most suitable stock to retrieve, including third-party stock.
A consigment order is like a standard sales order for goods but it doesn't have any delivery
information.
You create cash orders and rush orders for the sale of goods only.
You create a cash order when a customer picks up and pays for a delivery as soon
as it is ordered. And you create a rush order when the customer picks up the goods on the
same day as the order is placed. In this case, the invoice is created later.
You can arrange to deliver goods or render services in installments. To do this, you create an
outline agreement. Examples of some types of outline agreement include :
• quantity and value contracts
• master contracts
• scheduling agreements
• service contracts
You create a quantity contract if a customer has agreed to order a certain quantity of goods from your company during a specified period.
And you create a value contract if a customer has agreed to order goods of a certain cumulative value from your company during a specified period.
Quantity and value contracts do not include delivery dates, so releases are made using a sales order.
You can unite multiple contracts in a single master contract.
Let's say you create a quantity contract because a customer has agreed to order 500 engines in the first six months of the current year. If the customer orders 100 of these engines in January, you create a sales order called a release order.You refer to a quantity contract in a release order. So you refer to the quantity contract created for the 500 engines in each release order created for these engines. R/3 will then update the quantity contract automatically so it contains the correct number of remaining engines to be ordered.
Scheduling agreements specify the installments in which goods will be delivered to a customer. They include the quantity of a product that will be delivered in each installment. And they include the delivery date of each installment. You process a delivery for each installment contained in the scheduling agreement in the same way that you process a delivery for a regular sales order.No sales documents, such as release orders, are created before the products included on a scheduling agreement are processed for delivery.
You create a service contract if a customer requests a service over a particular period of time. For example, you could create a service contract if a customer ordered five one-hour maintenance checks from your company's motorcycle repair department.
You create complaint sales documents if there has been a fault with any goods that have been delivered, or with any services rendered, by your company.
For example, you create complaint sales documents if customers have been billed
incorrectly for an item or service, or if goods are faulty.
Different types of complaint sales document include
• returns
• credit memo requests
• debit memo requests
You create a returns document if a customer returns goods they have purchased from you because they are not satisfied with them. You can create returns from scratch or you can create them by copying the sales order that was originally created for the returned delivery.
A returns document records that you expect stock to be returned to your warehouse.
You can create one or more credit memo requests if a customer has been overcharged for a quantity of goods or services. You can also create a credit memo request if goods were damaged during transit and you want to credit the customer for the goods damaged.
When you create a credit memo request, your Accounting department reviews it to confirm that it can be justified. If the credit memo request is approved, the Accounting department creates a credit memo based on the request. You can create credit memo requests by copying other sales documents such as the sales order where the overcharge occurred.
You create debit memo requests when customers have been undercharged for products or services. Your company’s Accounting department can then create an invoice to bill the undercharged customer.
This document is adopted from Smart Force Campus Course Material
____________ _________ _________ _____
MM Flow
PR >Release the PR>RFQ>Quotation>Quotation Comparison>PO>Release the PO>GR>Invoice Verification
MM Process flow:
Process Flow
The typical procurement cycle for a service or material consists of the following phases:
1. Determination of Requirements
Materials requirements are identified either in the user departments or via materials planning and control. (This can cover both MRP proper and the demand-based approach to inventory control. The regular checking of stock levels of materials defined by master records, use of the order-point method, and forecasting on the basis of past usage are important aspects of the latter.) You can enter purchase requisitions yourself, or they can be generated automatically by the materials planning and control system.
2. Source Determination
The Purchasing component helps you identify potential sources of supply based on past orders and existing longer-term purchase agreements. This speeds the process of creating requests for quotation (RFQs), which can be sent to vendors electronically via SAP EDI, if desired.
3. Vendor Selection and Comparison of Quotations
The system is capable of simulating pricing scenarios, allowing you to compare a number of different quotations. Rejection letters can be sent automatically.
4. Purchase Order Processing
The Purchasing system adopts information from the requisition and the quotation to help you create a purchase order. As with purchase requisitions, you can generate Pos yourself or have the system generate them automatically. Vendor scheduling agreements and contracts (in the SAP System, types of longer-term purchase agreement) are also supported.
5. Purchase Order Follow-Up
The system checks the reminder periods you have specified and - if necessary - automatically prints reminders or expediters at the predefined intervals. It also provides you with an up-to-date status of all purchase requisitions, quotations, and purchase orders.
6. Goods Receiving and Inventory Management
Goods Receiving personnel can confirm the receipt of goods simply by entering the Po number. By specifying permissible tolerances, buyers can limit over- and under deliveries of ordered goods.
7. Invoice Verification
The system supports the checking and matching of invoices. The accounts payable clerk is notified of quantity and price variances because the system has access to PO and goods receipt data. This speeds the process of auditing and clearing invoices for payment.
Pur info record is nothing but a master data like thing which will be maintained for different materials to determine the prices etc.It Specifies the number that uniquely identifies a record.
For Example: an info record is based on Plant Vendor and Material Based on these three the Material Prices will be calculated for different combinations different values are taken into consideration.
During pricing it brings these values automatically based on this info record.
Use ME11 Tcode to create this record.
Common Tables used by SAP MM
Below are few important Common Tables used in Materials Management Modules:
EINA Purchasing Info Record- General Data
EINE Purchasing Info Record- Purchasing Organization Data
MAKT Material Descriptions
MARA General Material Data
MARC Plant Data for Material
MARD Storage Location Data for Material
MAST Material to BOM Link
MBEW Material Valuation
MKPF Header- Material Document
MSEG Document Segment- Material
MVER Material Consumption
MVKE Sales Data for materials
RKPF Document Header- Reservation
T023 Mat. groups
T024 Purchasing Groups
T156 Movement Type
T157H Help Texts for Movement Types
MOFF Lists what views have not been created
A501 Plant/Material
EBAN Purchase Requisition
EBKN Purchase Requisition Account Assignment
EKAB Release Documentation
EKBE History per Purchasing Document
EKET Scheduling Agreement Schedule Lines
EKKN Account Assignment in Purchasing Document
EKKO Purchasing Document Header
EKPO Purchasing Document Item
IKPF Header- Physical Inventory Document
ISEG Physical Inventory Document Items
LFA1 Vendor Master (General section)
LFB1 Vendor Master (Company Code)
NRIV Number range intervals
RESB Reservation/ dependent requirements
T161T Texts for Purchasing Document Types
Tcodes:
RFQ to Vendor - ME41
Raising Quotation - ME47
Comparison of Price - ME49
Creation of PO - ME21N
Goods Receipt - MIGO
Invoice (Bill PAssing) - MIRO
Goods Issue - MB1A
Physical Inventory - MI01( Create doc)
MI04 (Enter Count)
MI07 (Post)
____________ _________ _
FICO
The FI module has 8 sub modules:
FI-GL: General Ledger Accounting
FI-LC: Consolidation
FI-AP : Accounts Payable
FI-AR : Accounts Receivable
FI-BL : Bank Accounting
FI-AA :Asset Accounting
FI-SL : Special Purpose Ledger
FI-FM : Funds Management
CO Controlling
represents the company's flow of cost and revenue. It is a management instrument for organizational decisions. It too is automatically updated as events occur.
The CO module has following sub modules:
CO-OM : Overhead Costing (Cost Centers, Activity Based Costing, Internal Order Costing)
CO-PA : Profitability Analysis
CO-PC : Product Cost Controlling
Subscribe to:
Posts (Atom)