‘ Find the GRID item by name and unhide it plus a range that is offset to the row below it
For Each oBexItem In oBexItems
If (oBexItem.Name = “GRID_1”) Then
‘Set range1 = oBexItem.Range
‘set the correct worksheet
Application.Worksheets(oBexItem.Worksheet.Name).Activate
Dim lFirstDataCell As Variant
lFirstDataCell = oBexItem.DataProvider.Result.Grid.firstdatacell
MsgBox oBexItem.Range.Row
MsgBox oBexItem.Range.Column
MsgBox lFirstDataCell.X
MsgBox lFirstDataCell.Y

I found a blog post describing a program that allows you to change the BEx query “External Access” flag en masse. Very useful if you start integrating SAP BO and SAP BW and want to expose your existing queries.

The blog author is named Campbell Skene and here is the link to his blog:

You can maintain the application component hierarchy in RSA6. There are options to create/delete/rename and move hierarchy nodes under the Hierarchy menu.

To transport a modified version of the RSA6 application component hierarchy you will have to manually add it to a transport by adding R3TR DSAA APCO (to transport the inactive version of the hierachy use R3TR DSAD APCO).

If the application hierarchy is in the $TMP package you first have to set it to a transportable package as follows:

If your application component hierarchy is assigned to local object then first you need to change the package.

Go to TCode: SE03
For Object Type Selection use: DSAA
Object: APCO
Now change object directory from $TMP to the one being used in your project.

See SAP note 382471 – BW-OLTP-APCO: How do I transport it?
Also check OSS note 542454

Technique for switching ECC source systems in SAP BW Environment without affecting the
data modeling objects in the BW environment. By data modeling objects, we mean transformations, update rules and transfer rules getting inactive or getting deleted. Once the source system is switched, data reload needs to happen to have the initializations and deltas to come from the new source system. Also we have to ensure that the data from old source system( both transactional and master ) needs to be deleted in the BW system before reloading from the data from new source system to ensure consistency in the data from new system.

Data from the standard REFX exctractor 0REFX_1 can be loaded into a DSO with keys related to the RE Object (Object ID, Company Code, Building, Rental Space…) the condition Type and a validity date (ex:0DATEFROM). The condition amounts are provided with cumulative Key Figures (see 0COND_CHG) in relation to time.

This works fine for normal condition type that can have a start date, an end date and in some cases 1 or more dates where the value of the condition changes.

You see that here there are 2 records on the 1.1.2014. If the transformation rule is set to overwrite, one record will be lost.

What can be done in BW: Make sure that 2 distinct 0REFX_1 records with similar keys do not have the same valid from date. to do this. Locate possible cases by identifiying the one time condition record and then shift the valid from date by 1 day in the past (and make sure no more overlaps exists any more).

However it is not easy to identify one time conditions in the standard extractor 0REFX_1

To do this you need field UNIQUECOND. This field is available in the extract structure REIS_CONDITION_TRAN and the FM that is executed by the extractor will fill this field. However the field is set to not visible in ROOSFIELD, thus it is not visible in the extraction. A field in an extract structure is set to invisible when field ROOSFIELD-SELECTION equals ‘A’. This can be changed directly in the table by creating and running a small ABAP program. This change is not transportable, you will need to do this in acceptance and production too, and then transport the extractor after having removed the ‘Hide’ flag in RSA6 for the now visible UNIQUECOND field.