Monday, May 16, 2022

Change default download directory from SAP GUI

Today here’s a quick tip on how to change default download directory from SAP GUI. The default directory on WINDOWS OS host where files that are being downloaded via SAP GUI are stored is pointing to:

x:\Users\<username>\Documents\SAP\SAP GUI

 

However, there is a possibility to change it. Once of the options here is via WINDOWS Registry. Below is the Registry path:


[HKEY_LOCAL_MACHINE\Software\SAP\SAP Shared] on 32bit operating systems

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\SAP\SAP Shared] on 64bit operating systems

Key: SapWorkDir

Type: Expandable String Value

Value: The path you want to change

 

Fort someone who has no an access to the WINDOWS Registry this is not an option. Other possibility is to do it via user profile settings in SAP GUI. Simply call t-code SU3 and switch to tab called Parameters.

Here enter the param name GR8.



Give value to desired target directory for the parameter.


Once you use the file download functionality in any SAP GUI’s t-code the default folder will be pointing to the folder name given in the SU3’s param. Similarly, one can leverage other parameter CR9 that is used while uploading the files from user’s workstation to the SAP system.

Seems this is very old functionality as it is available in SAP NetWeaver based systems since component SAP_BASIS version 620 - that was released circa 2007.



More information:

622128 - Customizing the file Upload/Download paths.

Thursday, May 12, 2022

SAP for Me and SAP Support Portal vs ONE Support Launchpad

In my post, I do mention supports sites of SAP a lot. They are quite useful to search for an information about SAP products, issues, how-tos, also to request license keys, support or to download SAP software.  As there are many names for those sites I recon it can be useful to mention the latest ones.

In past we normally referred to these sites as SAP Support Portals either as OSS (Online Support System) or later as SMP (Service Market Place). Nowadays we can distinguish between two main support landing pages:

 

SAP Support Portal is one stop for all support and service related needs of SAP customers. It can be used to access the software, download the software, request license keys, get technical support, get an information about the software solution and find the documentation. Link: support.sap.com

 

ONE Support Launchpad is the new version of the Service Market Place (SMP) for all SAP customers. Link: launchpad.support.sap.com the site will soon transaction to SAP for Me that will be single entry point to all support site of SAP. Right now, the SAP for Me serves as a place to improve SAP customer experience throughout all touch-points with SAP. A list of all product’s portfolio, finance and legal stuff with customer relation to SAP is available there, other areas are service and support and systems and provisioning among other things are available via the SAP for Me site.


More information:

OSS

SMP

SAP Support Portal

SAP ONE Support Launchpad

Tuesday, April 19, 2022

Run DTP as a job?

This is probably a quite silly idea to run the DTP scheduled as background job. However, I just started to wonder whether it is possible at all. I am aware that ever since there was a concept of a process chain introduced in BW this is not really necessary. Having the process chain it is a pretty much possible to run the DTP within that chain anytime we want with any frequency we want. Nevertheless, I still wondered - it is possible to run the DTP as a job without the chain? Let us have a look.

There is an ABAP program called RSPROCESS that can runs any BW Process. Be it Execute Data Transfer Process (DTP_LOAD), Delete Complete Data Target Contents (DROPCUBE), Activate Requests in advanced DataStore Objects (ADSOACT), Execute ABAP Program (ABAP), Execute Operating System Command (COMMAND), Activate Master Data (MDACTIVAT), any BPC process and so on. See overview of different BW tasks/objects within the SAP BW here.

Thus, a very first idea is to leverage this program and schedule it as the background job. On the program’s selection screen, here are input parameters that need to be provided:

Process Type                                                 DTP_LOAD

Process Variant                                              <DTP_tech_name>


Now the program needs to be scheduled as the background job. To do that there is an item called Execute in background in menu Program:


As a next, just accept a Background Print Parameters pop-up:


Finally enter Start date/time or event which should serve as the background job’s trigger. Once done the job will be scheduled by accepting the pop-up by save button.


There is an information message “Background job was scheduled for program RSPROCESS” confirming the job’s schedule.


Now it is possible to observe the job’s execution in t-code SM37. Depending on DTP and BW system setup there can be several jobs found:


RSPROCESS - job that ran the program RSPROCESS itself. This one started next job(s) that represents the DTP load execution.

BIDTPR_20220419211828000002_1 – generated timestamps represents the data load request ID that can be seen in DTP’s monitor (e.g. t-code RSDTP). There can be multiple of those jobs depending on size data set that is being processed, DTP’s pack size etc. 




Debugging End Routine in HANA runtime of BW Transformation

In BW’s Transformation that are set to be executed in HANA mode there is still possible to have an ABAP End Routine. Here’s a short guide on how to debug ABAP code in such End Routines.


Technically a place that where the ABAP code of the End Routine is embedded into overall code of the HAAP process is a generated ABAP class. As an example if HAAP name (variable I_HAAPNM) is TR_ZQPTTP4YE36NYCQEVA6P_A then the ABAP class name is /BIC/ZQPTTP4YE36NYCQEVA6P_A (variable R_CLASS_NAME). In that ABAP class there is a method called GLOBAL_END where it code is located.

There are two environments where such an End Routine can be debugged.

 

1. in SAP HANA Studio – First open the transformation and display the End Routine code. Do a right click on some executable ABAP statement and set the breakpoint via choosing "Toggle Breakpoint" context menu item. 


While being in BW Modeling perspective open respective DTP and via button on DTP’s toolbar called "Start execution of data transfer process" select "Simulate in Dialog" item. This action open an RSDTP t-code embedded in SAP HANA Studio. Here hit a Simulate button and continue as you would do the debugging in SAP GUI as described below.



2. in SAP GUI – The debugging is still possible in SAP GUI if one prefer to do so. While being in RSDTP t-code set a "Processing Mode" to "Serially in the Dialog Process (for Debugging)" position, check out "Expert Mode" checkbox and hit Simulate button.


Next, a following pop-up called "Debug Request" is shown. Here enable "Before Transformation" checkbox. After that run it.



After a while, an ABAP debugger screen of SAP GUI is presented. Follow to Break./Watchpoints tab of the ABAP Debugger. Create a new breakpoint here pointing to ABAP objects:



Class name       CL_RSDHAR_TGT

Method Name      IF_RSDHAR_TGT~EXTRACT

Once the new breakpoint is created, it is visible like below:



Run the debugger until the new breakpoint is reached. There may be few more stops caused by hardcoded BREAK-POINT ABAP statements until it is reached to. If the ABAP debugger finally stops at IF_RSDHAR_TGT~EXTRACT (CL_RSDHAR_TGT) breakpoint just scroll a little bit down to a place where a call of method o_execute_abap_endrout is located and place a another breakpoint there.



Once that new breakpoint at the call of method o_execute_abap_endrout is reached, you came into the point where the ABAP code of custom End Routine is executed.

Thursday, March 31, 2022

BW on HANA - tables consistency check program

In SAP BW systems based on HANA DB there is a program to check a consistency of table properties with respect to BW application. The consistency check is often performed in cases of system migration (e.g. OS, hardware), system copies, restores. The program name is RSDU_TABLE_CONSISTENCY.


The program reads all tables residing in HANA DB and identifies those, which are BW relevant considering the program’s consistency check scenarios. So-called consistency check scenarios are present on the program’s selection screen. Inconsistency is found in case expected table property is not matching the reality. The program supports also repair mode along the detecting an issues.

Program RSDU_TABLE_CONSISTENCY is obsolete in BW/4 based systems as a part of simplification effort. The code of the program is not present. It can run but a message “Report not supported anymore. Please see SAP Note 2668225 (msg no: RSHDB 111)” is shown instead of the program execution. As the main object that carry the BW data persistency is in BW/4 an aDSO object the checks of the aDSO objects are now available in t-code RSOADSODTO.  

 

More information:

2569097 - How to use of report RSDU_TABLE_CONSISTENCY [VIDEO]

2668225 - Report RSDU_TABLE_CONSISTENCY is deprecated with SAP BW/4HANA

1937062 - Usage of RSDU_TABLE_CONSISTENCY - PDF doc


Wednesday, March 30, 2022

BW/4 t-code RSOADSODTO - Data Tiering Maintenance

Data Tiering is a strategy for a placing of a data into different areas (tiers). Decision on where the data is stored is highly driven by a frequency of data access, requirement the data updates, performance requirements and criticality of the data for business.

In case the data is very frequently used as well as updated, also the data is critical for the business we put it to so called hot tier.

If the data is less often accessed, has lower performance requirement we put it to so called warm tier.

Finally in a case the data is infrequently accessed, not require the updates, can be accessed in a longer time and is not critical put it to so called cold tier.

A concept of hot/warm/cold storage tier is called temperature schema.

In general putting the data into those areas, we say as Data Tiering Maintenance or Data Tiering Optimization (DTO). The DTO is a feature of BW/4 systems. There is still a possibility to use data archiving Data Archiving Process (DAP) as traditional approach used in NetWeaver based BW systems.

In terms of BW/4 based systems we can leverage an InfoProvider of type aDSO as object for the Data Tiering. From underlying HANA DB technology we used HANA indexserver nodes for hot tier. HANA extension nodes based on scale-out technology with relaxed core/memory and memory/disk ratio are used for the warm tier. In addition, some kind of external storage like SAP IQ DB that is accessible via Smart Data Access (SDA) for query access (DQL) and data manipulation (DML) can be used for the cold tier.

In BW/4 the aDSO as object needs to have some kind of a time characteristics or any other IO included in aDSO’s key) is part of key field’s definition. Once this is fulfilled on a Settings tab of the aDSO definition there is a Partitions part enabled. Here either Static (by given hardcoded values) or Dynamic Partitioning (by loaded data of particular characteristics) can be defined. Each partition can be maintained in different temperature / tier via button Maintain Temperatures. Depending on a version of BW/4 the click on this button either opens t-code RSOADSODTO (ABAP prog RSO_RES_ADSO_TEMP_MAIN) - Temperature Maintenance or launch’s BW/4 cockpit and its FIORI app (under DataStore Object -> Manage Data Tiering) for the DTO. In one of the two environment, we can choose the tier for particular partitions. Once the tiers are chosen it is possible to execute a change of the tier for specific partition/object depending how the DTO was defined on level of aDSO’s settings. The tier change can be also done in t-code RSOADSODTOEXE (ABAP prog RSO_RES_ADSO_TEMP_MAIN_EXEC) – Data Tier Adjustment. Another t-code RSOADSODTOS (ABAP prog RSO_RES_ADSO_TEMP_MAIN_START) is used for the FIORI app calls. The execution of the data tier change stores a logs about it. Those can be reviewed in t-code SLG1 under Object = RSOADSODTO, Subobject = RSOADSODTO_EXEC and Ext. Identifier = ADSO_TEMP_MAINTENANCE*.


More information:

Online docu

BW transport error: Error 2.048 has occurred in the BWA/SAP HANA server

While importing a new BW object like IO or aDSO across the landscape a following transport error may pop up in BWonHANA or BW/4 based systems:

 

RSD_TREX100:        column store error: <?xml version='1.0' encoding=' 2048

DBMAN099:   column store error: <?xml version='1.0' encoding='utf-8'?><createCubeResult version='1.0'><status><message>Error during ...

DBMAN099:   executing SQL statement</message><errorCode>2116</errorCode></st

DBMAN901:   Error 2.048 has occurred in the BWA/SAP HANA server

RS_EXCEPTION000: Could not create logical index

 

I recently came across this error in case of transporting an InfoProv – aDSO object in BW/4 based system. Every InfoProv object that runs in HANA DB must have column view created to access its data. The column view is needed for reporting on the object. The column view is sometimes called as logical index. It is view on DB containing all joins and can be used for an Infoprovider while querying it. The view is being created in the origin system when it was created upon its creation. In any other system where the object is moved to the view is created upon its transport.

Solution is to create the column view in that target system of the transport manually as it failed during the transport way. There is an ABAP program RSDDB_LOGINDEX_CREATE that can be used to generate the column view for aDSO, InfoCube, Open ODS View, CompositeProvider, InfoObject and MultiProviders. However there are more objects for which the views have to be generated there another tool – ABAP program RSDDB_INDEX_CREATE_MASS. Once the view is fixed the transport’s reimport will be finished successfully.


More information:

2286336 - Column view cannot be created on HANA

BWonHANA: InfoProvider column views

2607883 - Checking Column View and Calculation Scenario Errors in BW Queries



BW generation tool

The BW generation tool is to generate classes used in different data warehouse technical operation like: Activating data in DSO, extracting data from InfoProv, etc. Basically, every data operation in BW is performed via some generated piece of code.

Objects that are generated by BW generation tool usually falls under 'GP*' namespace. Those generated programs are sometimes called as writers. E.g. aDSO Writer, or InfoCube write program, etc.

The 'GP*' objects are generated by the BW generation tool according the templates. The generation is done by the program (generation) classes. The template is special ABAP include (e.g. RSDSO_ACTIVATE_TMPL) that contains a string like '*@' at the beginning of the line. Upon the generation, the template is filled with the actual data as per BW objects which it is being generated for.

Technically, there is a t-code RSSGPCLA (Maintain program class) where we can maintain what's template for particular data operation represented by the program class.

Assignment of program classes (field PROGCLASS, data element RSSG_PCLAS, domain RSSG_PCLAS) to template (field TEMPLATE, data element RSSG_TEMPL, domain PROGNAME) is stored in table RSSGTPCLA 'BW Generation Tool: Program Class'.

Here is few examples of different program classes:

RSAPTD1                        Generation of the Program for Transaction Data Transfer

RSDMD_ACTIVATE           Activation of requests for enhanced master data update

RSDRO_ACTIVATE            Activate an ODS Object

RSDRO_EXTRACT             Extraction of ODS Objects

RSDRO_UPDATE 

RSDSO_ACTIVATE            Activation of DataStore Objects (advanced)

RSDSO_OLRPROC             Select Requests for Deletion in Process Type ADSOOLR

RSDSO_ROLLBACK           Deletion of requests from DataStore objects (advanced)

RSDSO_UPDATE              Update Procedures

RSDTPERR                      Error Handling DTP

RSDWTMPLWIDTP            InfoCube Update Program for DTP

RSODSO_ACTIVATE          Activation of DataStore Object Data

RSODSO_RDA                 Template for Realtime Data Acquisition

RSODSO_ROLLBACK         Deletion of request from DataStore objects

 

Furthermore there are tables as per different BW object (e.g. in case of IO it is table RSDCHABASLOC, in case of aDSO it is table RSOADSOLOC, etc.) that store an assignment of generated writer programs to the particular BW object.

A few situations are there that may require maintaining the table RSSGTPCLA via t-code RSSGPCLA. It is mostly in case when the writer program need to be regenerated e.g. due to upgrade of BW system. This activity is sometimes called as 'Reset generation flag'. It can be performed by hitting a button 'Set Status' located in a toolbar of the t-code RSSGPCLA. The status is set to "Generation required". This means once the operation will run for next time the generated/writer program will be regenerated prior. Technically the setting of the status is done by a call of FM RSS_PROGRAM_GENSTATUS_RESET.

When one does this it must be ensured that while the generation flag is reset for particular BW activity the operation is not in progress. Otherwise, the current operation is cancelled and some inconsistencies may occur.




Tuesday, March 22, 2022

Cube-like aDSO object

In my other post, I introduced different flavors of an aDSO objects. In this post, I want to go deeper with one of them – cube-like aDSO object.

Aim of the cube-like aDSO object is to replicate behavior of infocube object that we know from classic (NetWeaver based) releases of SAP BW. It is used to model data warehouse layer – data mart according LSA++ architecture. The object does not have change log (CL) table. There are only two tables underneath:

1 Inbound data (AQ or AX for a cold storage) - stores newly loaded data identified by data load requests, similar to F-table in classic cube.

2 Active data (AT) – stores compressed data by activation requests, similar to E-table in classic cube.

Data is moved from inbound table to active one upon its activation (also known as aggregation). Once all data is activated, there is no data in the inbound table.

The cube-like aDSO object setup is following. "Active data" and "All Characteristics are Key" check boxes are checked.

Reporting on the cube-like ADSOs is performed as a union of inbound and active tables. This behavior is referred as stable navigation. There is no need to activate the data as both tables are used for the querying the data.

There are few remarks with regard to a deletion of the cube-like aDSO object. Request based deletion works if the data is only available in the inbound/new (AQ, e.g. /BIC/A*1 Inbound Table) table. Once the data is activated it is not possible to delete the request in the aDSO. There is only possibility to complete content deletion or a selective deletion. If a possibility to delete the requests is needed the data must not be activated.

 

More information:

Onlinedocu - infocube

Onlinedocu – datawarehouse layer – delta calculation

Flavors of aDSO object

3102582 - Request Based Deletion does not work as expected

3116509 - Deletion of overlapping request for ADSO is not working in case if the request is activated in target of ADSO type cube


Flavors of aDSO object

aDSO objects came in BW with many flavors. Mostly the different flavors corresponds to different layers of Enterprise Data Warehouse Architecture (like LSA++ for SAP BW/4HANA or LSA++ for classic BW) categories:


1 Data acquisition layer - including corporate memory

2.1 Corporate memory - compression capabilities

2.2 Corporate memory - reporting capabilities

3.1 Data warehouse layer - delta calculation

3.2 Data warehouse layer - data mart


Or to different InfoProvider objects as we know them from classic BW:

4 Standard DataStore object

5 Write-optimized DataStore object

6 InfoCube


Or from planning point of view:

          7 Planning in InfoCube-like manner

          8 Planning on direct update

 

BW modeling tools offers a template to make a decision of what type of the aDSO objects would a developer pick via called Templates for Modeling the Data Warehousing Layers. The template appears in SAP HANA Studio (BW Modeling perspective). Developer can pick from the template and the new aDSO object’s settings are setup by the system.


Here is a brief description on how the particular predefined property settings for the aDSO object look like for different aDSO object type:

 

1 Data acquisition layer - including corporate memory: No properties are selected, object corresponds to PSA layer as known in the classic BW.

 

2 Corporate memory

2.1 compression capabilities: "Active data" check box is enabled. Data is loaded into the inbound table. Data can be compressed (activated). However, the request cannot be deleted anymore after the activation. No request based deletion of the request possible after the activation. While querying such the aDSO the active table is accessed.

2.2 reporting capabilities: "Active data" and "Keep Inbound data extract from Inbound Table" check boxes is enabled. Data is stored redundantly in the inbound and in active table as well. This enables activation of the data and deleting the activated data requests. Data can be reloaded from inbound table as well (detailed information is not lost). While querying such the aDSO the active table is accessed.

 

3 Data warehouse layer

3. 1 Delta calculation: "Active data" and "Write Change Log" check boxes is enabled. Data is loaded to inbound table. Another checkbox called "Unique Data Records" can be enabled too in case only unique data is loaded to the aDSO. While querying such the aDSO the active table is accessed thus data need to be activated prior the querying. Change log table is used to enable deletion of activated requests thus the aDSO can be reloaded again. Behavior of this type of the aDSO is similar to standard DSO (classic) like object. Mechanics here is called unstable navigation as while querying only active table is used.

 

3.2 Data mart: "Activate Data" and "All Characteristics are Key, Reporting on Union of Inbound and Active Table" check boxes is enabled. Behavior of this type of the aDSO is similar to standard InfoCube object (cube-like object). Its inbound table is similar to F (not compressed data) table of the cube and active table is similar to E (compressed data) table of the standard cube. This type of the aDSO object supports so called stable navigation as while querying both the tables are used (via union): inbound and active too.

 

4 Standard DataStore object: so called classic DSO-like aDSO object - See point 3.1.

 

5 Write-optimized DataStore object: No properties are selected.

 

6 InfoCube:  so called cube-like aDSO object - See point 3.2.

 

7 Planning in InfoCube-like manner: "Active Data", "All Characteristics are Key, Reporting on Union of Inbound and Active Table" and "Planning Mode" check boxes is enabled.

 

8 Planning on direct update: "Direct Update" and "Planning Mode" check boxes is enabled.

 

Notice that the templates for the Modeling the Data Warehousing Layers are only available for classic BW systems and not in BW4/HANA.

 

More information:

Templates for Modeling the Data Warehousing Layers

Sunday, March 20, 2022

BW4 - Parameters of RSADMIN table

Many BW’s functional parts can be influenced by parameters. BW has few tables that store those parameters. Most prominent among them is RSADMIN one. With the introduction of BW/4HANA a suite of new parameters were introduced in the RSADMIN table.

 

Some of the RSADMIN parameters valid for BW/4HANA are having a BW4 prefix. However, that can’t be an guiding rule to distinguish between parameters valid for BW4 and prior BW’s versions. Thus there is a wide range mix of the parameters introduced in older BW versions that are still valid for BW/4HANA based systems.

Below I just mention few most important params that I came across.

 

ADSO_NE__XYZ (2950922) if values is set to X a zero elimination during aDSO request activation is activated. XYZ stands for particular aDSO technical name. This is same as param ADSO_NULL_ELIM__XYZ (2931468) that is valid for BW 7.5 systems.

 

ADSO_MDC_MODE_FOR_BEXFL_NEVER (3024244) parameter to decide what master data check mode is to be used by default for an InfoObjects in aDSO if the source object is a classic DSO.

 

Overview of BW/4HANA’s RSADMIN table parameter can be found in SAP Note: 2769125 - Composite Note: RSADMIN Parameter for SAP BW/4HANA

 

Related posts:

Parameters of RSADMINC table

Parameters of RSADMINA table

How to work with RSADMINA, RSADMINC and RSADMINS tables

How to work with RSADMIN table

Finally there is a list of RSADMIN table parameters (classic BW)

Friday, March 18, 2022

Closed loops scenarios in BW

Closed loop systems use feedback where a portion of the output is fed back to the input to reduce errors and improve stability. In BW world we can say that transformation of data that runs on top of same InfoProvider object (cube, aDSO) are the closed loops. In nutshell data transformation it writes data back to its source.

Such a scenarios are used quite often in BW. One of example can be a calculation of additional key figures on top of those that were calculated during a load from different objects underneath the target object.

Topic of closed loops appears when there is a migration to BW4/HANA. Normally during the migration BW objects that are not supported in BW/4 anymore need to be converted to the new objects. BW/4 requires these closed loops data loads and associated DTPs to be remodeled. In the BW/4 some write optimized aDSO needs to be part of the flow.

In order to help with the remodeling there are few tools (ABAP programs) provided by SAP:

RSB4H_REBUILD_CLOSED_LOOP_DTPS    Rebuild closed loop DTPs

RSBK_FIND_CLOSED_LOOP_DTPS            Identification of closed loops


More information:

3013897 - Closed Loop DTPs in the context of BW4/HANA Conversion

3019023 - Transfer Tool DTP & RSSM (41) - Report to rebuild closed loop DTPs

 

Generating master data for Time Characteristics

There is a handful of so-called virtual or fixed system infoobjects that do not really have a data stored persistently in database. Instead, those data is generated on the fly in a memory. There can be several issues with such a characteristics. Mostly some time/calendar/date entries can be missing in case of IOs like 0FISCPER, 0CALMONTH, 0FISCPER, 0DATE etc. That normally means that master data for the particular characteristics is missing. In addition, entries cannot be seen in reporting or in F4 values. While running the reports.

Normally the master data need to be maintained but as those characteristics are virtual, it can’t be maintained via master data app in BW/4 cockpit (in BW/4) or in the master data maintenance web (in case BW 7.4 and higher) or via t-code RSD1 (alternatively via FM RSDMD_MDMT) in older releases of classic BW.

Just a side note; running above mentioned FM for 0CALYEAR would end up with a message: says: RSDMD 172 No master data maintenance possible for characteristic 0CALYEAR.

Therefore, there is a t-code RSRHIERARCHYVIRT (ABAP prog SAPLRSR_HIERARCHY_VIRT) for that. It is also available in BW’s customizing via following paths in SPRO t-code:

Classic BW or SAP Netweaver based BW systems: SAP Netweaver -> SAP Business Information Warehouse -> Report-Relevant settings -> General report settings for Business Explorer -> Set F4 help and Hierarchies for Time chars / OLAP settings

SAP BW4/HANA based BW systems: -BW4/HANA Customizing -> SAP BW4/HANA -> Analysis -> Set F4 Help and Hierarchies for Time Characteristics/OLAP Settings

 

The t-code RSRHIERARCHYVIRT allows create some general OLAP settings for time characteristics and generate the data/hierarchies itself. Complete rebuild of the data can be achieved by button “Execute Recreate” placed on General Settings tab”. The button technically calls a method REBUILD_TIME_MD_TABLES of an ABAP class CL_RS_TIME_SERVICE.


Further checks that can be performed in case you face issues with TIME related characteristics are following:

ABAP Report RSD_TIME_TCT_MREADCLASS_CHECK – it checks what is the master data class that is used to read characteristic's master data.

 

t-code RSRV -> Tests in Transaction RSRV ->All Elementary Tests -> Transaction Data -> Consistency of time dimension for InfoCube.

  

More information:

Virtual Time Hierarchy

2582961 - How to fill master data table of 0CALMONTH (time characteristics)

2194279 - Check report for technical characteristics and time characteristics

2237679 - Time Characteristics and Current Member Variables