How to Convert Base Unit into target Units in BW Reports

My client has a requirement to convert the base units of measurements into target units of measurements in BW reports. How to write the conversion routine and otherwise please refer conversion routine used so that the characteristic value(key) of an info object can be displayed or used in a different format to how they are stored in the database.

Have a look at the how to document "HOW TO_ALTERNATE_UOM2"

or

You can use the function module 'UNIT_CONVERSION_SIMPLE'

CALL FUNCTION 'UNIT_CONVERSION_SIMPLE'
EXPORTING
input = ACTUAL QUANTITY
* NO_TYPE_CHECK = 'X'
* ROUND_SIGN = ' '
unit_in = ACTUAL UOM
unit_out = 'KG' ( UOM YOU WANT TO CONVERY )
IMPORTING
* ADD_CONST =
* DECIMALS =
* DENOMINATOR =
* NUMERATOR =
output = w_output-h_qtyin_kg
* EXCEPTIONS
* CONVERSION_NOT_FOUND = 1
* DIVISION_BY_ZERO = 2
* INPUT_INVALID = 3
* OUTPUT_INVALID = 4
* OVERFLOW = 5
* TYPE_INVALID = 6
* UNITS_MISSING = 7
* UNIT_IN_NOT_FOUND = 8
* UNIT_OUT_NOT_FOUND = 9
* OTHERS = 10
.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

How to Debugg Update and transfer Rules?

1.Go to the Monitor.
2. Select 'Details' tab.
3. Click the 'Processing'
4. Right click any Data Package.
5. select 'simulate update'
6. Tick the check boxes ' Activate debugging in transfer rules' and 'Activate debugging in update rules'.
7. Click 'Perform simulation'.

SAP Tables

ADCP	Person/Address assignment (central address administration)
ADIRACCESS	Table to store keys for TADIR objects
ADR2	Telephone numbers (central address admin.)
ADRP	Persons (central address administration)
APQD	DATA DEFINITION Queue
APQI	Queue info definition
D010SINF	ABAP- Information about ABAP program source code
E071	Change and Transport System- Object Entries of Requests/Tasks
E07T	Change and Transport System- Short Texts for Requests/Tasks
ENLFDIR	Additional Attributes for Function Modules
INDX	System table INDX

NAST	Message Status
STXH	STXD SAPscript text file header
T005	Countries
T005S	Taxes- Region (Province) Key
T005U	Taxes- Region Key- Texts
T006	Units of Measurement
T015M	Names of the months
T247	Month name and short text
T777A	Building Addresses
TADIR	Directory of Repository Objects
TBTCO	Job status overview table
TBTCP	Batch job step overview
TFDIR	Function Module
TFTIT	Function Module Short Text
TSP03L	Spool- Long device names
TSTC	SAP Transaction Codes
TSTCT	Transaction Code Texts
TUTYP	User Types in Current Price List in SAP System
TUZUS	Special versions
TVARV	Table of variables in selection criteria
TVDIR	View Directory
US930	Data Relevant to Measurement for User Master Record
USR01	User master record (runtime data)
USR02	Logon data
USR04	User master authorizations
USR06	Additional Data per User
USR14	Surchargeable Language Versions per User
USR21	Assign user name address key
ARCH_OBJ	Objects for archiving and reorganization
BTCUED	Description of user event IDs for background processing
BTXSUPB	BSI- Upgrade-Information
CCCFLOW	Client Copy Control Flow
DBSTATC	DB Optimizer Control (Statistics Creation)
DEVACCESS	Table for development users
DEVL	OBSOLETE- Do not use (See TCETRAL)
E070	Change and Transport System- Header of Requests/Tasks
E070L	CTS- Index for Assigning Numbers to Requests/Tasks
INSTVERS	Documentation for installation Status and History
PAT03	Patch Directory
SDBAC	DBA Action Table
T100	Messages
TAPLT	Program Application Long Texts
TASYS	OBSOLETE- Do not use, see TCEDELI
TDEVC	Development Classes
TEMSE	Temp Sequential table.
TLOCK	Change and Transport System- Lock Table
TNAPR	Processing programs for output. Can be very handy to find the print program for a SAPScript.
TNAST	Printed output control table
TPFET	Table of profile parameters
TPFHT	Profile header, administration data for profiles in DB
TPROT	Table contains all DD tables to be logged
TRBAT	Communication Table for Transport Control
TRDIRT	Title texts for programs in TRDIR
TRESN	Table of Naming Conventions in ABAP Workbench
TRJOB	Job ID for Coordinating Batch-ABAP/UNIX for Transports
TSP03C	Spool- Device Description Extension
TST03	TemSe data
TSYST	OBSOLETE- Do not use (see TCESYST)
TWSYS	OBSOLETE- Do not use (See TCETRAL)
USOBT	Relation transaction - authorization object
USR03	User address data
USR05	User Master Parameter ID
USR12	User master authorization values
USR40	Table for illegal passwords
USR41	User master- Additional data
UST04	User masters
VARIT	Variant texts
VARID	Variant directory
D010TAB	Table for Use Report---Tables
DD02L	SAP tables
DD02T	R/3 DD- SAP table texts
DD03L	Table Fields
DD03T	DD- Texts for fields (language dependent)
EDIDC	IDOC Control Records
EDIDOT	Short description of IDoc types
EDID2	IDOC segments (version 3.1)
EDID4	IDOC segments (version 4.6)
EDSEA	EDI- Table of all segments of current release
VRSX2	Central Table for Version Management (Report Source)
TSE05	Can add parameters to the INSERT COMMAND (IC). Then, when you insert command, your info appears in the editor. Useful for comment blocks, common section of code, etc.
CDPOS	Change document items
CDHDR	Change document header
T529A	governs the foreground sequence of infotypes the system will use to prompt the user during online and batch processing. You will have to code your BDC to follow that sequence of creating infotypes.
T588Z	governs the dynamic event processing that will only take place during online user inputs. For BDC's you will have to create separate BDC's to handle any infotypes that are inserted dynamically by this table.
T588M	Infotype Screen Control

User exits

User exits

1. Introduction
2. How to find user exits
3. Using Project management of SAP Enhancements


1. Introduction

User exits (Function module exits) are exits developed by SAP. The exit is implementerd as a call to
a functionmodule. The code for the function module is writeen by the developer. You are not writing
the code directly in the function module, but in the include that is implemented in the function module.


The naming standard of function modules for functionmodule exits is:  EXIT_<3
digit suffix>

The call to a functionmodule exit is implemented as: CALL CUSTOMER.-FUNCTION <3 digit suffix>

Example:

The program for transaction VA01 Create salesorder is SAPMV45A

If you search for CALL CUSTOMER-FUNCTION i program SAPMV45A you will find ( Among other user
exits):

CALL CUSTOMER-FUNCTION '003'
exporting
xvbak   = vbak
xvbuk   = vbuk
xkomk   = tkomk
importing
lvf_subrc = lvf_subrc
tables
xvbfa = xvbfa
xvbap = xvbap
xvbup = xvbup.

The exit calls function module EXIT_SAPMV45A_003


2. How to find user exits

Display the program where you are searching for and exit and search for CALL CUSTOMER-EXIT

If you know the Exit name, go to transaction CMOD. Choose menu Utillities->SAP Enhancements.
Enter the exit name and press enter.

You will now come to a screen that shows the function module exits for the exit.

3. Using Project management of SAP Enhancements

We want to create a project to enahance trasnaction VA01

Go to transaction CMOD
Create a project called ZVA01
Choose the Enhancement assign radio button and press the Change button
In the first column enter V45A0002 Predefine sold-to party in sales document . Note that an
enhancement can only be used i 1 project. If the enhancement is allready in use, and error message
will be displayed
Press Save
Press Components. You can now see that enhancement uses user exit EXIT_SAPMV45A_002.
Double click on the exit.
Now the function module is displayed. Double click on include ZXVVAU04 in the function module
Insert the following code into the include: E_KUNNR = '2155'.

Activate the include program. Go back to CMOD and activate the project.
Goto transaction VA01 and craete a salesorder. Note that Sold-to-party now automatically is "2155"

Another way to find user exits

This tip has been copied from SearchSap.com
Tip submitted by: Tim Jones


Here is a small addition to a tip from Matthew Billingham on how to locate user exits. Instructions are
relevant to 4.6B but I'm pretty sure I've used it in earlier versions. It's been a while though.

If you goto the SAP Application hierachy (SE81)you can go down into individual modules.

Select the area you are interested. (It should turn yellow).

Choose Information System button.

Select Environment--->Exit Techniques-->Customer Exits--->Enhancements.

You should now belooking at a selection screen with the DEV classes filled in from the Application
hierachy.

If you hit Execute you will get the exits for the selected part of the hierachy!

Have a play around with SE81 / Info system it can be very usefull in finding all sorts of interesting
things!

Frequently Asked Questions - SAP BW DeltaQueue (RSA7)

What does the number in the 'Total' column in Transaction RSA7 mean?
The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repetition of a delta request) and the LUWs for the next delta request. A LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System.

What is a LUW in the delta queue?
A LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet of an application extractor.

Why does the number in the 'Total' column in the overview screen of Transaction RSA7 differ from the number of data records that is displayed when you call the detail view?
The number on the overview screen corresponds to the total of LUWs (see also first question) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both, the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. Thus, only the records that are ready for the next delta request are displayed on the detail screen. In the detail screen of Transaction RSA7, a possibly existing customer exit is not taken into account.

Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded to the BW System. Then, the LUWs of the previous delta may be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change when the first delta was loaded to the BW System.

Why are selections not taken into account when the delta queue is filled?
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for reasons of performance.

Why is there a DataSource with '0' records in RSA7 if delta exists and has also been loaded successfully?
It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor (delta for master data using ALE change pointers). Such a DataSource should not be displayed in RSA7. This error is corrected with BW 20B Support Package 11.

Do the entries in table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area and so on).
Caution: As of PlugIn 2000.2 patch 3 the entries in table ROIDOCPRMS are as effective for the delta queue as for a full update. Please note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the DeltaQueue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.

Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?
With PlugIn 2001.1 the display was changed: the user has the option of defining the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the 'actual' delta data and the data intended for repetition and so on.

What is the purpose of function 'Delete data and meta data in a queue' in RSA7? What exactly is deleted?
You should act with extreme caution when you use the deletion function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. You do not only delete all data of this DataSource for the affected BW System, but also lose the entire information concerning the delta initialization. Then you can only request new deltas after another delta initialization.
When you delete the data, the LUWs kept in the qRFC queue for the corresponding target system are confirmed. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.
The deletion function is for example intended for a case where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.

Why does it take so long to delete from the delta queue (for example half a day)?
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion is considerably improved.

Why is the delta queue not updated when you start the V3 update in the logistics cockpit area?
It is most likely that a delta initialization had not yet run or that the the delta initialization was not successful. A successful delta initialization (the corresponding request must have QM status 'green' in the BW System) is a prerequisite for the application data being written in the delta queue.

What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix 'BW, the client and the short name of the DataSource. For DataSources whose name is 19 characters long or shorter, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in table ROOSSHORTN.
In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.

Why are the data in the delta queue although the V3 update was not started?
Data was posted in background. Then, the records are updated directly in the delta queue (RSA7). This happens in particular during automatic goods receipt posting (MRRS). There is no duplicate transfer of records to the BW system. See Note 417189.

Why does button 'Repeatable' on the RSA7 data details screen not only show data loaded into BW during the last delta but also data that were newly added, i.e. 'pure' delta records?
Was programmed in a way that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system.

I loaded several delta inits with various selections. For which one is the delta loaded?
For delta, all selections made via delta inits are summed up. This means, a delta for the 'total' of all delta initializations is loaded.

How many selections for delta inits are possible in the system?
With simple selections (intervals without complicated join conditions or single values), you can make up to about 100 delta inits. It should not be more.
With complicated selection conditions, it should be only up to 10-20 delta inits.
Reason: With many selection conditions that are joined in a complicated way, too many 'where' lines are generated in the generated ABAP source code which may exceed the memory limit.

I intend to copy the source system, i.e. make a client copy. What will happen with may delta? Should I initialize again after that?
Before you copy a source client or source system, make sure that your deltas have been fetched from the DeltaQueue into BW and that no delta is pending. After the client copy, an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943. After the client copy, Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. After the system copy, the table will contain the entries with the old logical system name which are no longer useful for further delta loading from the new logical system. The delta must be initialized in any case since delta depends on both the BW system and the source system. Even if no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an InfoPackage, you should expect that the delta has to be initialized after the copy.

Is it allowed in Transaction SMQ1 to use the functions for manual control of processes?
Use SMQ1 as an instrument for diagnosis and control only. Make changes to BW queues only after informing the BW Support or only if this is explicitly requested in a note for component 'BC-BW' or 'BW-WHM-SAPI'.

Despite of the delta request being started after completion of the collective run (V3 update), it does not contain all documents. Only another delta request loads the missing documents into BW. What is the cause for this "splitting"?
The collective run submits the open V2 documents for processing to the task handler which processes them in one or several parallel update processes in an asynchronous way. For this reason, plan a sufficiently large "safety time window" between the end of the collective run in the source system and the start of the delta request in BW. An alternative solution where this problem does not occur is described in Note 505700.

Despite my deleting the delta init, LUWs are still written into the DeltaQueue?!
In general, delta initializations and deletions of delta inits should always be carried out at a time when no posting takes place. Otherwise, buffer problems may occur: If a user started the internal mode at a time when the delta initialization was still active, he/she posts data into the queue even though the initialization had been deleted in the meantime. This is the case in your system.

In SMQ1 (qRFC Monitor) I have status 'NOSEND'. In the table TRFCQOUT, some entries have the status 'READY', others 'RECORDED'. ARFCSSTATE is 'READ'. What do these statuses mean? Which values in the field 'Status' mean what and which values are correct and which are alarming? Are the statuses BW-specific or generally valid in qRFC?
Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this does not mean that the record has successfully reached the BW yet. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the DeltaQueue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a DeltaExtraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which is confirming and deleting records which have been loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status is an indicator for an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903).
The value 'U' in field 'NOSEND' of table TRFCQOUT is discomforting.

The extract structure was changed when the DeltaQueue was empty. Afterwards new delta records were written to the DeltaQueue. When loading the delta into the PSA, it shows that some fields were moved. The same result occurs when the contents of the DeltaQueue are listed via the detail display. Why are the data displayed differently? What can be done?
Make sure that the change of the extract structure is also reflected in the database and that all servers are synchronized. We recommend to reset the buffers using Transaction $SYNC. If the extract structure change is not communicated synchronously to the server where delta records are being created, the records are written with the old structure until the new structure has been generated. This may have disastrous consequences for the delta.
When the problem occurs, the delta needs to be re-initialized.

How and where can I control whether a repeat delta is requested?
Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type 'Repeat'. If you need to repeat the last load for certain reasons, set the request in the monitor to red manually. For the contents of the repeat see Question 14. Delta requests set to red despite of data being already updated lead to duplicate records in a subsequent repeat, if they have not been deleted from the data targets concerned before.

Are there particular recommendations regarding the data volume the DeltaQueue may grow to without facing the danger of a read failure due to memory problems?
There is no strict limit (except for the restricted number range of the 24-digit QCOUNT counter in the LUW management table - which is of no practical importance, however - or the restrictions regarding the volume and number of records in a database table).
When estimating "smooth" limits, both the number of LUWs is important and the average data volume per LUW. As a rule, we recommend to bundle data (usually documents) already when writing to the DeltaQueue to keep number of LUWs small (partly this can be set in the applications, e.g. in the Logistics Cockpit). The data volume of a single LUW should not be considerably larger than 10% of the memory available to the work process for data extraction (in a 32-bit architecture with a memory volumen of about 1GByte per work process, 100 MByte per LUW should not be exceeded). That limit is of rather small practical importance as well since a comparable limit already applies when writing to the DeltaQueue. If the limit is observed, correct reading is guaranteed in most cases.
If the number of LUWs cannot be reduced by bundling application transactions, you should at least make sure that the data are fetched from all connected BWs as quickly as possible. But for other, BW-specific, reasons, the frequency should not be higher than one DeltaRequest per hour.
To avoid memory problems, a program-internal limit ensures that never more than 1 million LUWs are read and fetched from the database per DeltaRequest. If this limit is reached within a request, the DeltaQueue must be emptied by several successive DeltaRequests. We recommend, however, to try not to reach that limit but trigger the fetching of data from the connected BWs already when the number of LUWs reaches a 5-digit value.

FAQ - ALPHA Conversion

Frequently Asked Questions - ALPHA Conversion

What is the "ALPHA conversion" about?
A characteristic in BW can use a conversion routine like the conversion routine called ALPHA. A conversion routine converts data that a user enters (in so called external format) to an internal format before it is stored on the data base.
The most important conversion routine - due to its common use - is the ALPHA routine that converts purely numeric user input like '4711' into '004711' (assuming that the characteristic value is 6 characters long). If a value is not purely numeric like '4711A' it is left unchanged.
We have found out that in customers systems there are quite often characteristics using a conversion routine like ALPHA that have values on the data base which are not in internal format, e.g. one might find '4711' instead of '004711' on the data base.
It could even happen that there is also a value '04711', or ' 4711' (leading space).
This possibly results in data inconsistencies, also for query selection; i.e. if you select '4711', this is converted into '004711', so '04711' won't be selected.

Why is the "ALPHA conversion" necessary?
In such a case, a number of problems can arise in reporting like wrong values of key figures, no data found for certain filter values...
The "conversion of internal characteristic values", in short term: "ALPHA conversion", is a transaction (transaction code RSMDCNVEXIT) that checks the format of all values of characteristics that use one of the conversion routines ALPHA, GJAHR and NUMCV.
If values are found that do not have the correct internal format it can replace them by correct value and update all dependant BW objects (like InfoCubes, Hierarchies, master data of other characteristics...).
This transaction potentially has to touch a very significant part of all the data in BW. While running the check or conversion phase of RSMDCNVEXIT no data loads of any kind are possible; the conversion part of it cannot be interrupted. Therefore you should never start the conversion part without having thoroughly read the documentation.
We recommend to run the conversion as soon as possible.

Where do I find detailed information?
The "ALPHA conversion" transaction RSMDCNVEXIT has online documentation which you reach via its "Help" button.
OSS note 447341 is about the ALPHA conversion in general and has attached to it a number of other OSS notes describing solutions to known problems.

What are the prerequisites for the "ALPHA conversion"?
Before running ALPHA conversion, apply SP 26 (2.0B) resp. SP 18 (2.1C) resp. SP 11 (BW 3.0A).
If you have large ODS Objects (> 50 mio records in all) we recommend to apply Support Package 27 (2.0B) resp. 19 (2.1C) or the coding correction of OSS note 548122.
If you are unsure if the conversion has already been executed in your system (in a BW 3.0A system it probably has already been done during the upgrade to BW 3.0A) start transaction RSMDCNVEXIT and look at the system status: if it says "All characteristic only have correct internal values" you do not need to run it.
We recommend a database backup before you run the transaction.
If you have strong reasons not to apply the named support packages, please note that you can run the ALPHA conversion starting from SP 22 (BW2.0B) resp. SP 14(BW2.1C). If your support package level is strictly smaller than 25 (BW 2.0B) resp. 17 (BW 2.1C) you have to apply the coding correction of OSS note 528381. If you have SID tables with more than several millions of records you have to be on SP 25 (BW 2.0B) resp. 17 (BW 2.1C) and also apply a correction described in OSS note 543482.

What effects does the "ALPHA conversion" have on my BW system?
No data loads are possible while the transaction is checking or converting.
Once the conversion part has been started the conversion has to be completed. The system is in an inconsistent state in the mean time!

How long does the conversion take?
Usually, the alpha conversion requires between 3 and 20 hours for production systems. For very big systems (>1TB) , it could also take up several days.
From our experience, the most decisive factor for the duration is the size of the ODS objects. As a rough rule of thumb, approximately 2.5 mio. Records per hour can be converted within ODS objects (status BW 2.0B SP 27 resp. BW 2.1C SP 19). To improve the conversion for ODS objects, keep the change log small (i.e. delete old entries) because all change log records will be converted, too. Furthermore, the size of the master data tables (which include characters with one of the ALPHA, NUMCV or GJAHR conversions) has impact on the runtime of the upgrade.
As of BW 2.0B SP 29 resp. BW 2.1C SP 21, ODS objects can be converted in parallel. Please see note 559524 for details how to set up this parallelism.
As of BW 2.0B SP 29 resp. BW 2.1C SP 21, transaction RSMDCNVEXIT is enhanced by a workload estimate. This preliminary check lists all characteristics, database tables and the size of the tables that will be converted during the alpha conversion. Furthermore, possible meta data inconsistencies are found and the possibility of aborts during the conversion is reduced.
During the conversion process, you can check the state of the conversion in the log.
This estimate can be executed without locking the system. We recommend to run it before starting the conversion.
Please see the enhanced online help in transaction RSMDCNVEXIT for more details.

What is the interrelation between a BW upgrade and the "ALPHA conversion"?
During the prepare phase of an upgrade to BW 3.0B it is checked that the "conversion of internal characteristic values", also called "ALPHA conversion", has been successfully completed. This "ALPHA conversion" is time-consuming. Therefore we strongly recommend to separate this conversion from the actual upgrade process.

Frequently Asked Questions - Planning in SAP BW

Frequently Asked Questions - Planning in SAP BW

What is SAP's strategy for Planning and Budgeting?

SAP offers an integrated business platform through the mySAP Business Suite, which covers all planning requirements from overall business and financial planning to supply chain planning on the strategic, tactical and operational levels.
Planning and budgeting capabilities reside in different areas. Planning is available in operational context in transactional systems such as R/3 as well as in a more strategic, analytical context within the Business Planning and Simulation component, as of release SAP BW 3.5 part of SAP Business Intelligence (BW-BPS). Supply chain planning takes place in mySAP Supply Chain Management using SAP APO. The results of both business planning and supply chain planning are consolidated in SAP BW, for performance analysis and evaluation purposes.

Why have we decided to move planning to SAP Business Intelligence?

SEM-BPS offers state of the art planning capabilities that address the current needs of customers in regards to data integration on a common platform, usage of Excel and Web as user interfaces, process management and flexible reporting and analysis through SAP BW.
While we understand that the responsibility of business planning often resides in the finance function, we also recognize that the planning concepts implemented in the SEM-BPS planning framework are generic ones that can be reused in many other contexts (CRM, Human Resources, Retail, Consumer Products…). At the same time we realize that planning is becoming a much more integrative process that spans all functions of the enterprise including sales, marketing, production, etc. Our customers have communicated this fact in various product requirement sessions and development influence councils. In fact some customers currently are using SEM-BPS not only for financials but also for sales and marketing planning, headcount planning, purchase planning, travel planning amongst other non-financials types of planning.
Consequently, we want to support the market need and provide an open and flexible planning framework for both financial budgeting and other areas of planning. Therefore, SAP will deliver planning functionality in SAP Business Intelligence in order to provide the desired flexibility that our customers demand.
This step may be compared to the decision to move reporting and analysis to a generic area.
Therefore SAP will leverage the concepts of the SEM-BPS planning framework for the development of BW integrated planning. In addition starting with SAP BW 3.5 SEM-BPS is delivered as BW-BPS and remains in maintenance status.
A comparative view of the evolution of SAP's planning strategy is provided below:

What is a planning application?

Business scenario containing business content
§ Planning and Analysis Services/Planning Functions (e.g. Time lag, financial depreciation)
§ Planning Templates
Examples of planning applications: Sales planning, Financial statement planning, Profitability planning

What are the benefits for the customers?

§ Tightly integrated planning and analysis from one integrated data platform
§ Greater flexibility in creating custom planning applications to meet company-specific or market-specific requirements. Use of SAP BW tools like BEx Analyzer (Alerting, Drilldown Chart Tools, Calculated Key Figures, Hierarchical Data Entry)
§ Reduction of complexity by unique release procedure and reduced number of tools and planning objects
§ Ease of use: Planning and analysis use the same user interfaces
Some of the other features of the planning environment for customers will include improved forecasting algorithms, enhanced process control and status monitoring, simplified, hierarchical data entry, ….
(Please refer to the integrated planning for detailed information about SAP BW integrated planning)

How does this affect SAP Strategic Enterprise Management (SEM)?

Recognizing the fact that a closed-loop planning, measurement, and analysis environment is critical to the finance function, SEM will continue to be positioned and sold as a complete business performance management suite. SEM will deliver financial specific planning applications built on base of SAP BW integrated planning. Planning and budgeting will continue to be a key component of SEM along with the existing financial consolidation, performance measurement, and strategy management functions.

What are our customers and prospects deployment options?

SAP BW integrated planning will be available with SAP Netweaver BI 7.0 (Ramp-Up mid 2005). Current customers evaluating SAP planning solutions should evaluate and purchase BW-BPS (part of SAP BW 3.5) with the full comfort of knowing that their investment in BPS will be protected in the future should they wish to continue on this planning solution. Additionally, should they wish to migrate to SAP BW integrated planning, a migration strategy will be provided as well.

What are the recommendations for current SEM/BPS customers?

For current SEM-BPS customers and BW-BPS customers, their investment will continue to be supported by SAP. In this way users can expect to continue to realize the benefits of the planning capabilities with BPS and also realize the platform upgrades as future releases of SAP BW continue to evolve.
Please have a look at the presentation Decision Support for recommendations of implementing planning functionality for existing SAP SEM customers and customers planning the implementation in 2004 or 2005.

How will SAP BW integrated planning be integrated with the SEM components (Balanced Scorecard, Consolidations)?

Regarding the integration to Balanced Scorecard and Consolidation current capabilities will remain and be enhanced. The integration will still done via SAP BW InfoCubes. As a result, it will be possible to consolidate plan data in BCS. It will be possible to display plan data within the Balanced Scorecard and to drag or change it in Performance Measurement. The integration of master data will also be guaranteed using the common SAP BW data basis.

What will be delivered with SAP Netweaver BI 7.0 in regards to planning capabilities?

Step 1: SAP Netweaver BI 7.0 with BI Content Add-on 7.0.1 (mid 2005 - Ramp Up)
Features:
§ Integrated planning
§ SAP BW-BPS (former SEM-BPS)*
Existing SEM-BPS customers can use either planning capabilities. New customers can only use Integrated Planning.
Step 2: SAP Netweaver BI 7.0 with BI Content Add-on 7.0.2 (end 2005)
Features:
§ Integrated planning*
§ Planning applications**
§ Application specific planning services
§ Application specific planning services
§ Application specific planning content (pre-customized planning scenarios)
* SAP BW-BPS - former SEM-BPS will be continued to be supported in the future
** Planning Applications may be also delivered as Add-On.

If a customer has installed the SEM Add-on in the past, and wants to upgrade to SAP Netweaver BI 7.0 and subsequent SAP BW releases that contain planning functionality, will he still need to upgrade the SEM Add-on?
Yes. There are current technical limitations in the Add-on registration process that flag a system as being "Add-on" relevant, and will ask for the add-on upgrade when upgrading the core system.

Does this mean that customers have to wait for a period of time after the core SAP BW release, when the SEM Add-on and new BI Content Add-on will be available?

Yes. In order to develop the SEM and BI Add-ons based on the new SAP BW technology platform, there is typically a delay of a few months from the release date of the core SAP BW technology release, for the Add-on releases to be made available.

How are the BI Content Add-ons and the SEM Add-ons correlated?

SEM and SAP BI Content Add-Ons are built upon a core technology release of SAP BW. As such, after delivery of the BI content Add-On the corresponding SEM is available.

What exactly will be supported as a part of the migration from SEM-BPS to SAP Netweaver BI 7.0 /Content Add-on 7.0.1 integrated planning?

Customers will have the following choices:
§ Migrate to SAP BW Integrated Planning
§ No migration, just upgrade SAP BW/SEM and keep running SAP BW-BPS (former SEM-BPS) *
* Note: This selection is a "maintenance only" option, meaning that no new features will be delivered in subsequent releases for this selection. Only in the area of integrated planning are future enhancements planned.
The following objects will be migrated (manual and automatic):
§ Planning Areas*
§ Planning levels + planning packages*
§ Planning Layouts*
§ Planning Functions*
§ Variables*
§ Planning Folders*
§ User Exits*
* New technology is used to render these objects in SAP BW Integrated Planning, but the concept is the same as in SEM -BPS.
The following objects will need no migration:
§ Master Data
§ Transactional Data

Technique to list all User Exits in SAP

There are a number of techniques SAP have used over the years to implement user-exits.

The most recent exits will be found in CMOD. Using CMOD (or SMOD), you can list all the enhancements available, that use this technique. As is usual in the SAP world, the later the version of SAP you are using, the more exits are available.

Other exits do not use the enhancement technique. For example, in Sales Order Processing (SAPMV45A), SAP have provided empty forms, such as USEREXIT_SAVE_DOCUMENT_PREPARE that can be used to provide customer functionality. With one client, this was used to set the blocking indicator on a sales order, if a manual change had been made to pricing.

Another technique is the use of validation and substitution rules in the financial modules.

The best way to find the user exits available is through the IMG. The relevant nodes will take you to where the customization can be performed. Usually, the associated IMG note details the use of each exit, though there are gaps.

BW Useful Programs

RSIMPCURR -- To Transfer Exchange Rates
RSIMPCUST -- To Transfer Global Settings from source system
RS_TRANSTRU_ACTIVATE_ALL -- To Activate Transfer Rules -- Useful whenever we need to activate transfer rules in Quality or Production system after transports.
RSAU_UPDR_REACTIVATE_ALL -- To Activate Update Rules
SAP_CONVERT_TO_TRANSACTIONAL -- To change Basic Cube to Transactional Cube
RSAR_PSA_CLEANUP_DIRECTORY -- To Clean PSA and Change log
SAP_INFOCUBE_DESIGN -- To know statistics(Size) of Cubes -- Useful to know the size of Fact Tables and Dimension Tables
RSSM_SET_REPAIR_FULL_FLAG -- To change request status from Full load to repair full-- Useful to start delta loads, If full loads are already present in data target from same data source
RSDDS_AGGREGATES_MAINTAIN -- For Hierarchy/Attribute Change run RSDDS_CHANGERUN_MONITOR-- To Check Change run Status
RSDG_ODSO_ACTIVATE -- To Activate ODS in background. very much useful when BEx reporting switched on.
RSDG_IOBJ_ACTIVATE -- To Activate Infoobjects(Mass Activation)
RSDG_MPRO_ACTIVATE -- To Activate MultiProviders
RSDG_CUBE_ACTIVATE -- Activation of InfoCubes
RS_COMSTRU_ACTIVATE_ALL -- Activate all inactive communication structures
RSCONN07 - SAP Connect Administration(System Status)
RSAOS_METADATA_UPLOAD_BATCH -- To replicate single datasource from Source(R/3)

BW Useful Function Modules

BW Useful Function Modules
RSW_RATE_GET_BASIC -- To get exchange rate for combination of source and target currency for defined exchange rate type
WEEK_GET_FIRST_DAY -- First day of week
DATA_TO_PERIOD_CONVERT -- To derive period from DateRSAPO_SWITCH_BATCH_TO_TRANS, RSAPO_SWITCH_TRANS_TO_BATCH -- To change Transactional cube to basic cube & basic cube to tran cube
BAPI_USER_ACTGROUPS_ASSIGN -- To assign Roles to User
BAPI_USER_GET_DETAILS - To get User Details
SUPRN_INS_OR_DEL_PROFILE -- To insert or delete a Profile
RSBCTDPE_GET_ROLE_FOR_USER -- To see Roles per User
BP_EVENT_RAISE -- To raise an EVENT
RSDTM_ICD_DATA_DOWNLOAD -- To Download data from Infocube
RSPC_API_CHAIN_START -- To Start process Chain
RSPC_PROCESS_FINISH -- To finish any process in Process Chain-- how to use : RSPC_PROCESS_FINISH (To restart PChain)
RSU5_SAPI_BADI -- To enhance Master data(Note : 709816)
RSDMD_DEL_MASTER_DATA -- To delete Master Data
RSMDM_MD_ACTIVATE -- To activate Master Data
BAPI_IOBJ_CREATE -- To Create Infoobjects
BAPI_IOBJ_REORG -- To reorganise Infoobjects
BAPI_IPAK_START -- To start Infopackage
BAPI_IPAK_CHANGE -- To Change Infopackage
BAPI_IPAK_GET_DETAIL -- To get details of Infopackage
RSSM_GET_REQUEST_STATUS -- To get request Status
BAPI_ISREQUEST_GETSTATUS -- To get request status
FILE_GET_NAME -- To get file Name.
RSW_RATE_GET_BASIC -- To Currency Translation
RSAOS_METADATA_UPLOAD -- To Replicate datasources selectively
RSDRD_DELETE_FACTS -- To delete data selectively
RSDU_CHECK_PKEY_FACTTAB_DB6 -- Checks the partitioning key for the fact table of an InfoCube.
RSDU_CHECK_PKEY_ODSTAB_DB6 -- Checks the partitioning key for an ODS table.RSDU_CHECK_PKEY_PSATAB_DB6 -- Checks the partitioning key for a PSA table
RSDRI_INFOPROV_READ -- To read data from Infocubes

BW tables

Custome Infoobjects Tabels:
/BIC/M -- View of Master data Tables
/BIC/P -- Master data Table, Time Independent attributes
/BIC/Q -- Master data Table, Time Dependent attributes
/BIC/X -- SID Table, Time Independent
/BIC/Y -- SID Tabel, Time Dependent
/BIC/T -- Text Table
/BIC/H -- Heirarchy Table
/BIC/K -- Heirarchy SID Table
Standard Infoobjects Tabels(Buss. Content):
Replace "C" with "0" in above tables.
Ex: /BI0/M -- View of Master data Tables
Standard InfoCUBE Tables :
/BI0/F -- Fact Table(Before Compression)
/BI0/E -- Fact Table(After Compression)
/BI0/P -- Dimension Table - Data Package
/BI0/T -- Dimension Table - Time
/BI0/U -- Dimension Table - Unit
/BI0/1, 2, 3, .......A,B,C,D : -- Dimension Tables
BW Tables:
BTCEVTJOB -- To check List of jobs waiting for events
ROOSOURCE -- Control parameters for Datasource
ROOSFIELD -- Control parameters for Datasource
ROOSPRMSC -- Control parameters for Datasource
ROOSPRMSF -- Control parameters for Datasource-- More info @
ROOSOURCE weblog
RSOLTPSOURCE -- Replicate Table for OLTP source in
BWRSDMDELTA -- Datamart Delta Management
RSSDLINITSEL, RSSDLINITDEL-- Last valid Initialization to an OLTP Source
RSUPDINFO -- Infocube to Infosource correlation
RSUPDDAT -- Update rules key figures
RSUPDENQ -- Removal of locks in the update rules
RSUPDFORM -- BW: Update Rules - Formulas - Checking Table
RSUPDINFO -- Update info (status and program)
RSUPDKEY -- Update rule: Key per key figure
RSUPDROUT -- Update rules - ABAP routine - check table
RSUPDSIMULD -- Table for saving simulation data update
RSUPDSIMULH -- Table for saving simulation data header information
RSDCUBEIOBJ -- Infoobjects per InfocubeRSIS -- Infosouce Info
RSUPDINFO -- Update Rules InfoRSTS -- Transfer Rules Info
RSKSFIELD -- Communication Structure fields
RSALLOWEDCHAR -- Special Characters Table(T Code : RSKC, To maintain)
RSDLPSEL -- Selection Table for fields scheduler(Infpak's)
RSDLPIO -- Log data packet no
RSMONICTAB -- Monitor, Data Targets(Infocube/ODS) Table, request related info
RSTSODS -- Operational data store for Transfer structure
RSZELTDIR -- Query Elements
RSZGLOBV -- BEx Variables
RXSELTXREF, RSCOMPDIR -- Reports/query relavent tables
RSCUSTV -- Query settings
RSDIOBJ -- Infoobjects
RSLDPSEL -- Selection table for fields scheduler(Info pak list)
RSMONIPTAB -- InfoPackage for the monitor
RSRWORKBOOK -- Workbooks & related query genunid's
RSRREPDIR -- Contains Genuin id, Rep Name, author, etc...
RSRINDEXT -- Workbook ID & NameRSREQDONE -- Monitor: Saving of the QM entries
RSSELDONE -- Monitor : Selection for exected requests
RSLDTDONE -- Texts on the requeasted infopacks & groups
RSUICDONE -- BIW: Selection table for user-selection update Infocubes's
RSSDBATCH -- Table for Batch run scheduler
RSLDPDEL -- Selection table for deleting with full update scheduler
RSADMINSV -- RS Administration
RSSDLINIT -- Last Valid Initializations to an OLTP Source
BTCEVTJOB --To check event status(scheduled or not)
VARI -- ABAP Variant related TableVARIDESC -- Selection Variants: Description
SMQ1 -- QRFC Monitor(Out Bound)
SM13 -- Update Records status

FAQs - RSA7

Question 1:
What does the number in the 'Total' column in Transaction RSA7 mean?
Answer:
The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repeating a delta request) and the LUWs for the next delta request. An LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System.

Question 2:
What is an LUW in the delta queue?
Answer:
An LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet from an application extractor.

Question 3:
Why does the number in the 'Total' column, in the overview screen of Transaction RSA7, differ from the number of data records that are displayed when you call up the detail view?
Answer:
The number on the overview screen corresponds to the total number of LUWs (see also question 1) that were written to the qRFC queue and that have not yet been confirmed. The detail screen displays the records contained in the LUWs. Both the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. This means that only the records that are ready for the next delta request are displayed on the detail screen. The detail screen of Transaction RSA7 does not take into account a possibly existing customer exit.

Question 4:
Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Answer:
Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded into the BW System. The LUWs of the previous delta may then be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change if the first delta is loaded into the BW System.

Question 5:
Why are selections not taken into account when the delta queue is filled?
Answer:
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for performance reasons.

Define Source System

Source System is the system from where data is extracted and stored in data warehouse.

Following are the steps to Define a Source System in SAP BW

1) Execute transaction RSA1
2) Select Source System as shown below and right click to create




3) Select Source System Type as shown below. In this example, we are creating a source system for a flat file. Using this, we can load a .csv file to an infocube

Similarly, a SAP R/3 or SAP BW system can be defined as source system. Server id, system id, background user, clients are some of the information required to define SAP source system.



4) Enter a name and description for source system



5) Source system is created as shown