Tag Archives: refx

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.

The program below lists all the indexations that have occurred for a REFX lease contracts. ( For contracts that have not had or will never have any indexations, some info is available in table VIAJSEPCINDX (fields INDEXSERIES and INDEXBASEYEAR) )

For a given contract ID it derives the INTRENO (internal object ID).

The INTRENO is used to get all relevant records in VIAJRECORD. The records that correspond to past indexations have a status 3 in field ADJMDRECORDSTAT (‘Adjustment Complete’).
Other useful info => ADJMFROMOLD and ADJMFROMCALC (previous index date and index adjustement date)

Each record in VIAJRECORD is linked to a record in VIAJRECINDX via PROCESSGUID + INTRENO.

In VIAJRECINDX you can retrieve INDEXSERIES/INDEXBASEYEAR + ADJMINDEXBASE (index value at adjustement date) and FIRSTINDEXBASE (reference index at initial date of index calculations).

In SAP REFX, only the first contract end date is stored in the contract master data. All the next possible break dates are linked to renewal rules. In transaction RE80 or RECN you can simulate future renewals to see all possible future break dates.

Below is a small program that fills an internal table with the same information as the one provided by the simulation button. The program uses a FM that performs the actions that are behind the contract renewal simulate button.

SAP Note 1543274 explains how to extract the Next Possible Contract End Date for each contract.

This information is not stored in the REFX contract tables but is derived from several element such asthe contract end date, the renewal rules and the notice periods.

In theory this calculated date should be the same as the one that is visible in transaction RECN in field. (xxx)

I have implement the SAP Note but I noticed that the extractor derives an incorrect date.

After debugging the extractor I found that at one point in theextractor code all possible end dates since the beginning of the contract are stored in an internal table and then the 1st date in used for the extraction.

This is incorrect as there are dates that are in the past.

To correct the issue I modified thePERFORM cn_next_end_get in the include file LREIS_MASTERDATA_EXTRACTIONF02that is called by the extractor to delete from the derived list all dates in the past.

Look for the statement “SORT lt_rnsim BY rnextdate.” and insert a single statement after that.

SORT lt_rnsim BY rnextdate.

*{ INSERT DEVK900261 1“Next Possible End Date (simulaiton) does not work as expected“The result of the simulation contains all end dates since begin of contract“Thus by selecting the 1st row in the sorted table a date in the past can“be selected.“This modification corrects this behaviour by deleting from the table all entries“where rnextdate is in the past delete lt_rnsim where rnextdate < sy-datum.*} INSERT READ TABLE lt_rnsim INTO ls_rnsim INDEX 1.