Very good Webinar on sapinsider about HANA. Its a webinar 60 mins which can be request through the site www.sapinsider.com

Title :

Learn How You Will Benefit from a Fully
In-Memory-Enabled SAP NetWeaver BW Powered by SAP HANA

Following is youtube link which explains the BW architecture in very efficient way. The video needs to be appreciated in the way it captured the wholestic view and interaction between various sections in BW throughout version 3.5 , 7.0 .  Awaiting video on 7.3

http://www.youtube.com/watch?v=fovmnSIplpc ( BW 3.5 architecture)

http://www.youtube.com/watch?v=dCcyKmdwVYk (BW 7.0 archetecture)

Scheduling Process Chain multiple times a day using Events

On high level, following are the Steps
1)Create an event Eg : 'Z_REDCOP_DAILY_LOAD_CHAIN_EVENT'
2)Create a Program to call the FM : BW_EVENT_RAISE by passing event id like below ( we used Z_BW_EVENT_RAISE here )
3)Create a Job at frequency of 2 hours.( in SM36 ).In the step information of the job specify the above program created
4)Specify the eventid in the process chain start variant also.

Explanation : Step 1
a) Goto Sm62.
b) Open last tab
c) Click on Creat button and give technical name/desc of the event.


Explanation : Step 2
REPORT ZBW_EVENT_TRIGGER_PROGRAM.
DATA : EVENTID LIKE TBTCO-EVENTID.
DATA : DATE TYPE SY-DATUM.

DATE = SY-DATUM.
IF DATE+06(02) LE 16.
EVENTID = 'Z_REDCOP_DAILY_LOAD_CHAIN_EVENT'.

CALL FUNCTION 'Z_BW_EVENT_RAISE'
EXPORTING
EVENTID = EVENTID
EXCEPTIONS
BAD_EVENTID = 1
EVENTID_DOES_NOT_EXIST = 2
EVENTID_MISSING = 3
RAISE_FAILED = 4
BP_EVENT_RAISE_OTHERS = 5
OTHERS = 6
.
IF SY-SUBRC <> 0.
ENDIF.

ENDIF.

Explanation : Step 3
a) Open Sm36.
b) Give Job name and target system. Save

c) If it asks for ABAP program then give our program name ( if notClick on STEP button and it will ask ). Give variants if necessary.

d) Click save. It shows :

e) Now go back to main screen and click on start condition and give 2 hours periodic setting there.
f) Save.
g) Check in Sm37 if job is scheduled….


Explanation : Step 4

Specify the eventid in your Start variant of the process Chain.

Calculation on data which is split into different packages

During the data load data is split by data packets and the start routine in update rule is applied packet by packet. It is hence not possible to do calculation in start routine which requires a group of the records as they
could be split in to different packets.

Solution1 :
In reference to the blog
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/3f91f628-0b01-0010-9da8-9e7ca2cbb104

we have mark the infopackage to load the data only upto to PSA.Then we extract data of PSA , apply our logic for calculation and write back to PSA. After we can update data from PSA to data targets.
That is,
The ABAP for reading the PSA data and writing back to PSA is in four sections
a- Get the request number ( call FM : RSSM_API_REQUEST_GET )
b- Get data ( call FM : RSAR_ODS_API_GET )
c- Change Data ( Custom code to do the calculations that you want )
d- Write data back to PSA ( Call FM : RSAR_ODS_API_PUT )

Solution2:
If your loading data from and ODS to any data target. Then we follow this approach.
You can write a custom program to update the active table of the source ODS.
As active table is a flat table, you can easily do your calculations using a custom program and update the active table. Following is the program i tried for my requirment :

REPORT ZBW_SORTING_HR.

DATA: IT_RESULTS LIKE /BIC/AZPT_O0200 OCCURS 0 WITH HEADER LINE.
DATA: WA_TEMP LIKE /BIC/AZPT_O0200.
DATA: IT_SORTED1 LIKE /BIC/AZPT_O0200 OCCURS 0 WITH HEADER LINE.
DATA: KEY3(255) TYPE C,KEY1(255) TYPE C, KEY2(255) TYPE C.
DATA: END_DATE LIKE /BIC/AZPT_O0200-calday.
DATA: START_DATE LIKE /BIC/AZPT_O0200-calday.
clear : it_results.

SELECT * FROM /BIC/AZPT_O0200 INTO TABLE IT_RESULTS.

SORT it_results by
EMPLOYEE
CALDAY
REPTT
UNIT.

clear : wa_temp,it_sorted1.
clear : key1,key2,start_date,end_date.

LOOP AT IT_RESULTS INTO WA_TEMP.

CONCATENATE WA_TEMP-EMPLOYEE WA_TEMP-REPTT INTO KEY1.

IF KEY2 = KEY1.
END_DATE = WA_TEMP-CALDAY.
WA_TEMP-/BIC/ZDAY_TO = END_DATE.
WA_TEMP-/BIC/ZDAY_FROM = START_DATE.
ELSE.
START_DATE = WA_TEMP-CALDAY.
END_DATE = WA_TEMP-CALDAY.
WA_TEMP-/BIC/ZDAY_TO = END_DATE.
WA_TEMP-/BIC/ZDAY_FROM = START_DATE.

ENDIF.

KEY2 = KEY1.

APPEND WA_TEMP TO IT_SORTED1.
endloop.

UPDATE /BIC/AZPT_O0200 FROM TABLE IT_SORTED1.

Templates for Start Routine

Following is the sample code for start routine in Transformation :

DATA: WA_TEMP TYPE DATA_PACKAGE_STRUCTURE, KEY1(255) TYPE C, KEY2(255)
TYPE C.
DATA: KEY3(255) TYPE C.
DATA: END_DATE LIKE DATA_PACKAGE-CALDAY.
DATA: START_DATE LIKE DATA_PACKAGE-CALDAY.

SORT DATA_PACKAGE BY
EMPLOYEE
CALDAY
REPTT
UNIT.

LOOP at DATA_PACKAGE INTO WA_TEMP.

CONCATENATE WA_TEMP-EMPLOYEE WA_TEMP-REPTT INTO KEY1.

IF KEY2 = KEY1.
END_DATE = WA_TEMP-CALDAY.
WA_TEMP-/BIC/ZDAY_TO = END_DATE.
WA_TEMP-/BIC/ZDAY_FROM = START_DATE.
ELSE.
START_DATE = WA_TEMP-CALDAY.
END_DATE = WA_TEMP-CALDAY.
WA_TEMP-/BIC/ZDAY_TO = END_DATE.
WA_TEMP-/BIC/ZDAY_FROM = START_DATE.

ENDIF.


KEY2 = KEY1.

MODIFY DATA_PACKAGE FROM WA_TEMP.

ENDLOOP.

Dynamic table name in select statement in ABAP

Here is a sample code piece used :

DATA name_snp_chn(20) TYPE c VALUE '/bic/azmmiv_sc00'.
DATA name_snp_usa(20) TYPE c VALUE '/bic/azmmiv_sU00'.
DATA name_snp_eur(20) TYPE c VALUE '/bic/azmmiv_sE00'.
DATA name_snp(20) TYPE c VALUE '/bic/azmmiv_os00'.

DATA name_mov_chn(20) TYPE c VALUE '/bic/azmmiv_2c00'.
DATA name_mov_usa(20) TYPE c VALUE '/bic/azmmiv_2U00'.
DATA name_mov_eur(20) TYPE c VALUE '/bic/azmmiv_2E00'.
DATA name_mov(20) TYPE c VALUE '/bic/azmmiv_o200'.

DATA : BEGIN OF ITAB OCCURS 0,
FACALID LIKE /BI0/MPLANT-FACTCAL_ID,
END OF ITAB.

if I_ZREGION = 'CHN'.
name_snp = name_snp_chn.
name_mov = name_mov_chn.
elseif I_ZREGION = 'USA'.
name_snp = name_snp_usa.
name_mov = name_mov_usa.
elseif I_ZREGION = 'EUR'.
name_snp = name_snp_eur.
name_mov = name_mov_eur.
endif.



IF i_test = 'X'.
BREAK-POINT.
* xl_plant = 'AA'.
* xl_stor_loc = '7000'.
* xl_material = '000000000000010712'.

xl_plant = 'RYAN'.
xl_stor_loc = '7000'.
xl_material = '000000000007519620'.

* xl_plant = 'CL00'.


SELECT * FROM (name_snp)
INTO CORRESPONDING FIELDS OF TABLE io_snapshot
WHERE plant EQ xl_plant
AND stor_loc EQ xl_stor_loc
AND material EQ xl_material.
ENDIF.

Where to check for code used in extractor of DS

Goto to RSA2 in source system.
Give the datasource.
Check the extractor details. Click on the extractor. It will open the code.

Idocs between R3 and BW while extraction

1)When BW executes an infopackage for data extraction the BW system sends a Request IDoc ( RSRQST ) to the ALE inbox of the source system.Information bundled in Request IDoc (RSRQST) is :
Request Id ( REQUEST )
Request Date ( REQDATE )
Request Time (REQTIME)
Info-source (ISOURCE)
Update mode (UPDMODE )
2)The source system acknowledges the receipt of this IDoc by sending an Info IDoc (RSINFO) back to BW system.The status is 0 if it is ok or 5 for a failure.
3)Once the source system receives the request IDoc successfully, it processes it according to the information in the request. This request starts the extraction process in the source system (typically a batch job with a naming convention that begins with BI_REQ).
The request IDoc status now becomes 53 (application document posted). This status means the system cannot process the IDoc further
4)The source system confirms the start of the extraction job by the source system to BW by sending another info IDoc (RSINFO) with status = 1
5)Transactional Remote Function Calls (tRFCs) extract and transfer the data to BW in data packages. Another info IDoc (RSINFO) with status = 2 sends information to BW about the data package number and number of records transferred
6)At the conclusion of the data extraction process (i.e., when all the data records are extracted and transferred to BW), an info IDoc (RSINFO) with status = 9 is sent to BW, which confirms the extraction process.

Appearence of Values for charecterstic input help screen

Which settings can I make for the input help and where can I maintain these settings?
In general, the following settings are relevant and can be made for the input help for characteristics:

Display: Determines the display of the characteristic values with the following options "Key", "Text", "Key and text" and "Text and key".
Text type: If there are different text types (short, medium and long text), this determines which text type is to be used to display the text.
Attributes: You can determine for the input help which attributes of the characteristic are displayed initially. When you have a large number of attributes for the characteristic, it makes sense to display only a selected number of attributes. You can also determine the display sequence of the attributes.
F4 read mode: Determines in which mode the input help obtains its characteristic values. This includes the modes "Values from the master data table (M)", "Values from the InfoProvider (D)" and "Values from the Query Navigation (Q)".
Note that you can set a read mode, on the one hand, for the input help for query execution (for example, in the BEx Analyzer or in the BEX Web) and, on the other hand, for the input help for the query definition (in the BEx Query Designer).


You can make these settings in InfoObject maintenance using transaction RSD1 in the context of the characteristic itself, in the InfoProvider-specific characteristic settings using transaction RSDCUBE in the context of the characteristic within an InfoProvider or in the BEx Query Designer in the context of the characteristic within a query. Note that not all the settings can be maintained in all the contexts. The following table shows where certain settings can be made:

Setting RSD1 RSDCUBE BExQueryDesigner
Display X X X
Text type X X X
Attributes X - -
Read mode
- Query execution X X X
- Query definition X - -


Note that the respective input helps in the BEx Web as well as in the BEx Tools enable you to make these settings again after executing the input help.

When do I use the settings from InfoObject maintenance (transaction RSD1) for the characteristic for the input help?
The settings that are made in InfoObject maintenance are active in the context of the characteristic and may be overwritten at higher levels if required. At present, the InfoProvider-specific settings and the BEx Query Designer belong to the higher levels. If the characteristic settings are not explicitly overwritten in the higher levels, the characteristic settings from InfoObject maintenance are active.

When do I use the settings from the InfoProvider-specific characteristic settings (transaction RSDCUBE) for the input help?
You can make InfoProvider-specific characteristic settings in transaction RSDCUBE -> context menu for a characteristic -> InfoProvider-specific properties.
These settings for the characteristic are active in the context of the characteristic within an InfoProvider and may be overwritten in higher levels if required. At present, only the BEx Query Designer belongs to the higher levels. If the characteristic settings are not explicitly overwritten in the higher levels and settings are made in the InfoProvider-specific settings, these are then active. Note that the settings are thus overwritten in InfoObject maintenance.

When do I use the settings in the BEx Query Designer for characteristics for the input help?
In the BEx Query Designer, you can make the input help-relevant settings when you go to the tab pages "Display" and "Advanced" in the "Properties" area for the characteristic if this is selected.
These settings for the characteristic are active in the context of the characteristic within a query and cannot be overwritten in higher levels at present. If the settings are not made explicitly, the settings that are made in the lower levels take effect.

How can I display attributes for the characteristic in the input help?
Attributes for the characteristic can be displayed in the respective filter dialogs in the BEx Java Web or in the BEx Tools using the settings dialogs for the characteristic. Refer to the related application documentation for more details.
In addition, you can determine the initial visibility and the display sequence of the attributes in InfoObject maintenance on the tab page "Attributes" -> "Detail" -> column "Sequence F4". Attributes marked with "0" are not displayed initially in the input help.

Why do the settings for the input help from the BEx Query Designer and from the InfoProvider-specific characteristic settings not take effect on the variable screen?
On the variable screen, you use input helps for selecting characteristic values for variables that are based on characteristics. Since variables from different queries and from potentially different InfoProviders can be merged on the variable screen, you cannot clearly determine which settings should be used from the different queries or InfoProviders. For this reason, you can use only the settings on the variable screen that were made in InfoObject maintenance.

Why do the read mode settings for the characteristic and the provider-specific read mode settings not take effect during the execution of a query in the BEx Analyzer?
The query read mode settings always take effect in the BEx Analyzer during the execution of a query. If no setting was made in the BEx Query Designer, then default read mode Q (query) is used.

How can I change settings for the input help on the variable screen in the BEx Java Web?
In the BEx Java Web, at present, you can make settings for the input help only using InfoObject maintenance. You can no longer change these settings subsequently on the variable screen.

ABAP program to find prev request in cube and delete

There will be cases when we cannot use the SAP built-in settings to delete previous request..The logic to determine previous request may be so customised, a requirement.
In such cases you can write a ABAP program which calculates previous request basing our own defined logic.
Following are the tables used :
RSICCONT ---(list of all requests in any particular cube)
RSSELDONE ----- ( has got Reqnumb, source , target , selection infoobject , selections ..etc)
Following is one example code. Logic is to select request based on selection conditions used in the infopackage:
REPORT ZGET_LAST_REQ_SHORT_RUN.
PARAMETERS : TAR_CUBE(9) TYPE C,
SOUR_ODS(9) TYPE C.
DATA : IT_REQ LIKE TABLE OF RSICCONT.
data : it_REQ_WA type RSICCONT.
DATA : IT_CALMONTH_LOW TYPE /BI0/OICALMONTH.
DATA : IT_CALMONTH_HIGH TYPE /BI0/OICALMONTH.
data : diff type N.
DATA : IT_REQ_CUBE LIKE TABLE OF RSSELDONE.
data : it_REQ_CUBE_WA type RSSELDONE.
data : sour_tar(22) type C.
TABLES : ZBW_PARAM.
CLEAR It_REQ.
CLEAR it_REQ_WA.
CLEAR it_REQ_CUBE.
CLEAR DIFF.
concatenate SOUR_ODS '_TO_' TAR_CUBE INTO SOUR_TAR.
SELECT * FROM RSICCONT INTO TABLE IT_REQ WHERE ICUBE = TAR_CUBE.
LOOP AT IT_REQ INTO IT_REQ_WA.
SELECT * FROM RSSELDONE INTO TABLE IT_REQ_CUBE WHERE RNR = IT_REQ_WA-RNR AND SOURCE = SOUR_ODS AND FIELDNAME = 'CALMONTH'.
ENDLOOP.
LOOP AT IT_req_cube into it_req_cube_wa.
IT_CALMONTH_LOW = IT_REQ_CUBE_wa-LOW.
IT_CALMONTH_HIGH = IT_REQ_CUBE_wa-HIGH.
diff = IT_CALMONTH_HIGH - IT_CALMONTH_LOW.
if diff <= 3.
ZBW_PARAM-ZKEY1 = 'INV_SHORT_REQ'.
ZBW_PARAM-ZKEY2 = SOUR_TAR.
ZBW_PARAM-ZDATA = IT_REQ_CUBE_WA-RNR.
MODIFY ZBW_PARAM.
ENDIF.
endloop.

Once after reqnumb is found out, you can pass
cubename, reqnumb as inputs to FM : RSSM_DELETE_REQUEST and get the job done.

Decision making process type in Process chains

To Logically decide on the next step in the process chain flow( IF-THEN-ELSE), we can use option of "Decision between multiple Alternatives" Process type.
Step 1 : Choose "Decision between multiple Alternatives " Process type.Drag it to process chain window.

Step 2: We get a popu-up.Create a new decision making variant.


Step 3: Define the formula for IF. We have got formula editor for help.


We can define as many formula's as we have we options for next step.

Step 4: Each of the above IF condition is marked against a event ( options ) and they can be used in the process chain to define the next step ( to the respective option )

DTP filer Routine

Following is the example of routine written in DTP filter.
While writing the logic of l_t_range-SIGN,l_t_range-OPTION,l_t_range-LOW etc. we should write l_t_range-Fieldname also here...

data: l_idx like sy-tabix.
read table l_t_range with key
fieldname = 'PLANT'.
l_idx = sy-tabix.

DATA : IT_PLANT LIKE TABLE OF /BI0/PPLANT.
data : it_plant_wa type /BI0/PPLANT.
DATA : IT_COUNTRY LIKE TABLE OF /BI0/PCOUNTRY.

CLEAR IT_COUNTRY.
CLEAR IT_PLANT.

SELECT * FROM /BI0/PCOUNTRY INTO TABLE IT_COUNTRY WHERE /BIC/ZMARKET2
= 'USA'.

IF IT_COUNTRY[] IS NOT INITIAL.
SELECT * FROM /BI0/PPLANT
INTO TABLE IT_PLANT
FOR ALL ENTRIES IN
IT_COUNTRY
WHERE COUNTRY = IT_COUNTRY-COUNTRY.
ENDIF.

LOOP AT IT_PLANT INTO IT_PLANT_WA.
l_t_range-low = IT_PLANT_WA-PLANT.
l_t_range-Fieldname = 'PLANT'.
l_t_range-SIGN = 'I'.
l_t_range-OPTION = 'EQ'.
append l_t_range.
ENDLOOP.

if l_idx <> 0.
modify l_t_range index l_idx.
else.
append l_t_range.
endif.
p_subrc = 0.

Function module to make yellow request to RED

Use SE37, to execute the function module RSBM_GUI_CHANGE_USTATE.From the next screen, for I_REQUID enter that request ID and execute.From the next screen, select 'Status Erroneous' radiobutton and continue.This Function Module, change the status of request from Green / Yellow to RED.

ABAP routine in infopackage for Multiple Selections

Requirement : 0plant should be restricted in the infopackage level using routine picking only selective plants ( say under some country or region )
Following is the code, i tried and working fine.
Solution
data: l_idx like sy-tabix.
DATA : IT_PLANT LIKE TABLE OF /BI0/PPLANT.
data : it_plant_wa type /BI0/PPLANT.

read table l_t_range with key
fieldname = 'PLANT'.
l_idx = sy-tabix.

SELECT * FROM /BI0/PPLANT INTO TABLE IT_PLANT WHERE COUNTRY = 'BE'.

LOOP AT IT_PLANT INTO IT_PLANT_WA.
l_t_range-low = IT_PLANT_WA-PLANT.
l_t_range-SIGN = 'I'.
l_t_range-OPTION = 'EQ'.
append l_t_range.
ENDLOOP.

modify l_t_range index l_idx.
p_subrc = 0.

Difference between LIS and LO Extraction

Both (LIS & LO) extractors are used to extract logica data from source system. Now a days most of the clients using LO extractor insted of LIS extractor.

LIS is old technique through which we can load the data. Here we use typical delta and full up-loading techniques to get data from an logistics application, it uses V1 and V2 update, it means that it was a synchronous or asynchronous update from the application documents to LIS structures at the time when the application document was posted.

LO Cockpit is new technique i think from bw 3.0 (not sure) which uses V3 which is an update that you can schedule, so it does not update at the time when you process the application documents, but it will be posted at a later stage.

You have separate datasources for header level, item level and schedule line level available in LO, you can choose at which level you want to extract your data and switch off others, which results in reduced data.we do not have this flexibility with LIS structures


All most all LIS extractor is outdated becuse of it's disadvantages.

Differences :

1. LIS works on transparent table concept and LO’s works on Cluster table concept.
2. Each data source i.e 2lis_11_s264 is splitted in to multiple data sources like 2 lis_11_vahdr, 2lis_11_vaitm,2lis_11_vascl, with this we can give more detailed level of information to the end users.
3. LIS works under Push mechanism where as Lo works on PULL Mechanism.
4. when we r doing delta then two transparent tables will come into picture i.e SBIW1 and SBIW2 in LIS. Where as in Los structures called LBWQ (Extractor queue), SM13 (Updatequeue)and RSA3 (delta queue).
5.LO cock pit is BW CONTENT EXTRACTOR
where as LIS is CUSTOMER GENERATED EXTRACTOR..
6.LO cockpit is uses Readymade datasorce...
but LIS we need to cretae everything...

and not to forget,
LO cockpit supports V3 update(BACK GROUND SCHEDULING Jobs)
LIS does't supports V3 update mode... it supports only V1 (SYNCHRONUS)& V2ASYNCHRONUS UPDATE)

What will happend if a request in Green is deleted?

Deleting green request is no harm. if you are loading via psa, you can go to tab 'reconstruction' and select the request and 'insert/reconstruct' to have them back.But,
For example you will need to repeat this delta load from the source system. If you delete the green request then you will not get these delta records from the source system.

Explanation :
when the request is green, the source system gets the message that the data sent was loaded successfully, so the next time the load (delta) is triggered, new records are sent.
If for some reason you need to repeat the same delta load from the source, then making the request red sends the message that the load was not successful, so do not discard these delta records.Delta queue in r/3 will keep until the next upload successfully performed in bw. The same records are then extracted into BW in the next requested delta load.

When is reconstruction allowed? Questions

1. When a request is deleted in a ODS/Cube, will it be available under reconstruction.
Ans :Yes it will be available under reconstruction tab, only if the processing is through PSA
Note: This function is particularly useful if you are loading deltas, that is, data that you cannot request again from the source system

2. Should the request be turned red before it is deleted from the target so as to enable reconstruction
Ans :To enable reconstruction you may not need to make the request red, but to enable repeat of last delta you have to make the request red before you delete it.

3. If the request is deleted with its status green, does the request get deleted from reconstruction tab too
Ans :No, it wont get deleted from reconstruction tab

4. Does the behaviour of reconstruction and deletion differ when the target is differnet. ODS and Cube
Ans :Yes

Handling Amount Values with currencies in BW

SAP stores amount values of different currencies with a fixed interpretation of having two decimal places.There are some currencies that do not work well with such two decimal place setting. Usually this is because for some currencies, a fraction of currency unit is meaningless. That is true for the Japanese Yen, the
Turkish Lira, and Korean Won and many other such currencies.

TCURX table
The table determines the number of decimal places in the output according to the currency key. If the contents of currency exist in table TCURX as currency key CURRKEY, the system sets the number of decimal places according to the entry CURRDEC in TCURX. Otherwise, it uses the default setting of two decimal places. That means that TCURX only has to list the exceptions with a number of decimal places
other than 2.

Lets observe the following steps where TCURX is refered.
• Step 1: Updating the amount values into BW data target
• Step 2: Displaying the amount values in the BW reports.

Step 1: Updating the amount values into BW data target
When we load the data into BW having amount fields in it, it checks the TCURX table for the currency entry.If the currency entry is present in TCURX table, it divides the amount value by 10** (2- (CURRDEC entry in TCURX table)).
Step 2: Displaying the amount values in the BW reports.
The exactly converse happens while displaying such values in the report output. The amount value will be multiplied by 10** (2- (CURRDEC entry in TCURX table)) while displaying in the report output.

Example
Note: The KRW (Korean WON) currency key is present in the TCURX table with the decimal place value as 0.
Step 1:
Whenever the amount 123 KRW is loaded in BW, it checks the TCURX table for the KRW currency.After finding the entry in TCURX table, it stores the amount value in target as 123 / {10** (2 – (0))} that is 1.23 KRW. (The amount is divided by 100)
For this to happen, we have to make a specific setting in the InfoPackage thru which we schedule the loads.The checkbox for “Currency Conversion for External Systs” should be ticked as shown below.
Step 2:
While displaying the same amount value in the report output, the exactly opposite will happen. That is the amount value 1.23 KRW will be multiplied by 100 and shown as 123 KRW (Amount is multiplied by 100) in the report output which is the initial value which came from the source system.

General Observations
In most of the cases, we miss step 1 as it need manual intervention (like ticking the checkbox for “Currency Conversion for External Systs”) whereas the step 2 is carried out by default and we get the wrong results in the report output. Even if amount is not divided while loading, the multiplication is carried out by default at the time of reporting. That is the reason why it is necessary to check whether the step 1 is being carried out successfully or not.
As the settings in the External Data tab of InfoPackage applies to the data which is coming from the external source only, the checkbox for “Currency Conversion for External Systs” works for the currencies which are coming from the source system directly. Hence if you write logic to pick up the currency (lookup etc.) in either
transfer rules or update rules, step 1 will not be carried out. Step 2 will be carried out by default thereby giving wrong results in the report output.

Note : This knowledge was got after i read :
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/600aa67b-c348-2b10-f690-aaa81d12ec6a

PSA reverse posting

When the data is loaded to BW Infocube and then it is compresed then u can't delete the data pertaining to this request in the cube . For this what u can do is if the request is loaded via PSA then u can click on the Request Reverse Posting option on the MOnitor screen of the particular Request . This will reverse the sign of the keyfigures loaded into the InfoCube for that particular request only ,so that it will make overall keyfigyure value in the cube for this particular request to 0


Reverse posting to be done by system @ Monitoring --> Scheduler --> Reverse posting --> Immediate & Save.
This will nullify the before request values by sending reverse values.
This can be done only if the loaded data is still present in PSA.

Unable to Cancel Job in SM37 (R3)

Question from sdn :
We got a situation :Unable to Kill the Background job (BI_REQ*).It shows "ACTIVE" and been running for more than 19,000 secs (2 days..) .When this job started ,the PROCESS ID was : 244277..But after a day,this PROCESS ID : 244277 has been allocated to some other R3 Program(Monitored in SM50).But the Background Job is still "ACTIVE".Tried killing the Job in SM37--->Cancel Active Job or Delete the Job) but ,when tried to "Cancel" the Job,we get a message : The job is NOT ACTIVE !!!. Then when tried to "DELETE" the job ,we get a message " Job is still ACTIVE"......!!!!
----->Since there is no Work Process in SM50,what is the alternative solution to Kill this Job..........???
(In BW ,there is no Update of data records,with the monitor showing

Answere :
Go to SM37 >> select the job >> Click on the JOB tab in the top >> Click on Check status............
Then it status will show cancel...........
Actually sometimes it happens job gets cancelled but staus shows active....then we need to do this..........actually job is already cancelled......