Data Extraction from Finance Special Ledger using SAP BW

FI-SL is a system that combines data (planned and actual) from different levels of OLTP applications (for example, FIGL, EC-PCA, CO-CCA).In R/3, FI-SL enhances the functions and usability of these applications, without restricting their operative functions in any way.FI-SL has planning functions and reporting tools. FI-SL reporting is, however, restricted:

Cross-application reporting is not as diverse as SAP BW reporting.The OLTP System is optimized for transaction processing, and a high reporting load would impact the overall performance of the system.The solution is FI-SL reporting in SAP BW.

The special ledger system (FI-SL) is a receiver system, which records data form various other SAP applications. It is not a sender system for other SAP applications.In FI-SL, you are able to use flexible data structures (with additional fields) that correspond to individual business requirements. This allows you to combine and summarize information for any number of code combinations, at any
level of detail.Selective data retrieval: The assignment of transactions to particular combinations of company code/ledger or company/ledger, determines which ledgers are updated using the data.

Adjustment postings are possible in the FI-SL system (for example, when valuing currencies). You can post data in various versions.In FI-SL, you are able to use alternative charts of accounts (operative, group-specific, and country-specific charts of accounts). Using various fiscal year variants, enables you to create weekly or monthly reports, for example.Validations or substitutions allow you to check or modify specifically the validity of the data, at the point when it is entered into the FI-SL system.

In addition to data from FI, CO, MM, and SD, external data, and data that is entered directly into the system, can also be posted into FI-SL.The update takes place either online or as subsequent processing. With subsequent processing, a predefined number of data records are transferred to the FI-SL database tables, at a certain point in time, independently of the time the original document was created.

You can activate various functions for the update in the FI-SL Special Ledger:

Ÿthe validation can check the data that is going to be updated, according to a set of freely definable rules Ÿ the substitution can replace the data with changed data, according to particular rules, before the update takes place.

Ÿ the ledger selection allows an update from only partic ular ledgers Ÿ transferring fields determines which characteristics / dimensions are used in the FI-SL system. You use these dimensions when you are defining your special ledger. n Available operations on FI-SL data:

ŸThe function Currency translation translates amounts that have been posted to the ledger in the FISL system.At the fiscal year change, use the Balance carry forward function to transfer actual and plan values from the previous fiscal year into the new fiscal year. Allocation (assessment/distribution) means the transfer of an amount that has already been posted, from a sender object to one or more receiver objects. Ÿ To get faster reporting processing times, create a roll up ledger containing totaled and summarized data from one or more ledgers.


Data Structures in FI-SL  Table Group ZZ

When you create an FI-SL table group, up to 5 tables with fixed naming conventions are created (after the organizational unit is determined for unit or company): Totals table (...T), actual line items tables (...A), plan line item tables (...P), object table_1 (object/partner) (...O), and the optional object table_2 (movement attribute) (...C). 

To evaluate these tables via reporting, ledgers are defined that refer to this kind of table group (with the total table in the middle).The totals table contains fixed key fields, such as, client, ledger, record type, version, fiscal year, object number, sender (credited account assignment element), object number receiver (credited account assignment element), company code, account number, business area, cost center, function area for the credited account assignment element and company code, account number, business area, function area for the debited account assignment element and additional characteristics. 

The object number sender indicates a credited account assignment element (for example, cost center, profit center, or project) with additional properties (additional characteristics) that are contained in the object table_1.In the same way, the object number receiver indicates a debited account assignment element (for example, cost center, order, profit center, or project) with additional properties (additional characteristics) that are contained in the object table_1.


Totals Table ZZT in FI-SL

A particular feature of data modeling in the totals table, is the period block: There is a key field RPMAX (period) that specifies the current meaning of the period for key figures TSL16, HSL16,and KSL16. The meaning or the periods for key figures *SL01 to *SL15 is then output. This means, when RPMAX has the value "016", the values for key figures TSL16, HSL16 and KSL16 refer to period "016" of the fiscal year variant set in Customizing.

If the RPMAX has the value "064", the values for key figures TSL16, HSL16 and KSL16 refer to the period "064", the values for key figures TSL15, HSL15 and KSL15 to period "063", ... of the fiscal year variant set in Customizing.You can display the fiscal year variants with a period number > 16 and the key figure values are divided among various data records with different RPMAX values. Currency handling is explained here: The key figures TSL01 to TSL16 always have the transaction currency, which is specified in the field RTCUR (currency key). The key figures HSL01 to HSL16 have the so-called second currency: this is specified in Customizing and can be, for example, the house currency. The key figures KSL01 to KSL16 have the so-called third currency: this is specified in Customizing and can be, for example, the company code currency.


Ledger in FI-SL

A ledger is a closed reporting area, which always refers to exactly one totals table. You can think of a ledger as a logical part of a totals table.Several ledgers can be defined for a totals table. A ledger is created in Customizing in a totals table. The ledger contains Metadata, such as the set of rules by which it is updated.A maximum of 4 different sender structures (MOVE or programable Exit) can update a ledger. Manual correction postings are also possible. n But the transaction data itself remains in the tables of the table group.

Difficulties Connecting FI-SL to BW

  1. The FI-SL transaction data is stored in a group of tables.
  2. A ledger can refer to part of a table group.
  3. The object numbers in the totals table are not 'expressive'.
  4. The period block means that a key figure TSL01 can refer to two different totals records in two different periods.
  5. The currency information is only partially stored in the table group.
  6. Quantity key figures     

When you generate an FI-SL Data Source, a ledger, which is based on a totals table, proposes a combination of characteristics and key figures.

Related Posts
 
No comments :
Labels: ABAP , abap programming , SAP ABAP , SAP BW

SAP Business Process Delta Process

In  SAP Business Process Delta Process, By way of securing data integrity, a delta initialization or delta request replicates all the new line items that were previously posted from line items at the time t (t = 30 minutes). This retention period of 30 minutes is often described as a "security delta" and is represented in the schema by the yellow bars. Since a delta update is scheduled every night after the daily posting processes, the retention period does not disrupt the day's business.


The security delta also comes into use when you build summarization levels. If the delta initialization can be covered by the summarization level, the replica "inherits" the security delta from the summarization level.Please note that D1 and D4 cover more data than before in the diagram above. However, the delta initialization is usually faster if the data can be retrieved from a summarization level.Please also note that the availability of a summarization level is checked at the time of extraction.You must make sure,Ÿ that a relevant summarization level is active and available if the Data Source is using the required aggregation (> 1:3 compared to the single line items). that the data on the "best" summarization level is up-to-date, so as to avoid unnecessarily large D1 and D4.





"Delta method" in Account-based CO-PA

The accounting-based Data Sources only support the "Full" update mode.The indicator is set for delta compatibility, but an attempt to load a delta or an initialization will trigger the error message RD150.Ÿ A delta process for medium-sized volumes of data can be simulated if you delete requests for the last period from the InfoCube and carry out another full update for the period.A summarization level is required as the source for a full update. You cannot access line items directly.

Delta support is scheduled for R/3 ³ 4.0B with PI 2000.2 (2.1C).You must select a fixed value for KOKRS and PERIO:

for KOKRS, because accounting-based summarization levels are always restricted to a controlling area (compulsory)
Ÿ
for PERIO, because only the most up-to-date completed periods are transferred.


BW: Selection Restriction

As of Release 2.0B, it is possible to make selections for the delta initialization, full and delta updates. Full updates can be carried out with various selections; in a cycle in which the delta initializations and delta updates switch over, the selections must, however, be the same for all requests.  This is the exactly the same process that drill down reporting in CO-PA would take on.Please note that there may be performance problems because of the index structure in the CE1xxxx-,CE2xxxx- and CE4xxxx tables.

The extra index MANDT+PAOBJNR for CE1xxxx and CE2xxxx supports all types of requests as long as no selections are applied.Ÿ Selecting in Info Packages requires additional indexing sometimes.Ÿ There may be situations where delta initializations and delta requests cannot be dealt with effectively with one index structure for the CO-PA tables. In any case, you are recommended to carry out testing with productive data.



 
Related Posts
 
No comments :
Labels: ABAP , abap programming , SAP BW

Extraction from CO and PA using SAP BW Part Three

For extracting data  from SAP  data Source in business warehouse we have option like Single Line item Characteristics.The units are selected automatically if you select their quantity field.

Characteristics from the single line items :Ÿ In this area, all characteristics are displayed that were not selected for the operating concern in TA KEQ3, such as fields, which are only saved in single line items. The system only shows these fields of the single line items that make use of the unique data in the database tables. Some fields are either redundant (for example, CLIENT), or only specific for COPA internal use (for example, PAOBJNR, AWSYS) or do not contain any relevant data. Please note that some of the fields shown are not relevant for customer installation (for example, STO_BELNR, RBELN).
Ÿ
Remember that all updates affect your data from the line items if you choose a field from this area. Delta updates always affect your data from the line items. It is of no consequence here, whether you select a single line item or not. If you select the document number DOCNO, a non-aggregated replica usually appears in the Data Warehouse. This is generally seen as an incorrect way to use the Data Warehouse and mostly causes performance problems.


Data Source: Selection Fields

The displayed field name is the name of the extract structure and can deviate from the CO-PA field names in some cases. If the check box in the column Selection is active, that is, shown in white, you can select it. However, some fields cannot be selected: Especially fields that are to be worked on (currency, PALEDGER, PLIKZ, PERIV, KTOPL,..), units, currency, value fields and calculated key figures. Ÿ You should only select fields that divide your data if (a) there is a large volume of data for the first data transfer, or (b) there are business reasons and you need to select these in the future. 

The selection in BW can only be a fixed value or an interval.Never specify very large PERIO intervals (PERIO=001.1999..999.2999). The system will crash because the memory is overloaded. Use FYEAR intervals instead (FYEAR=1999..2999).You can ignore the column Hide field since you have already selected the fields you want to replicate.

After making your selections, choose Generate. This ends the activities in the R/3 System.Choose the detail view in the IMG to display the Data Sources. n The next steps are made in the BW System. First load a newly defined Data Source into BW and create an Info Cube based on the DataSource.


Data Source Definition: Accounting CO-PA

Defining an accounting Data Source is not much different to defining accrued Data Sources.Ÿ KOKRS, BUKRS, KSTAR are compulsory.There are no characteristics available from the line items since accrued DataSources do not contain characteristics.There is only one amount (in three currencies) and a quantity (together with the quantity unit). Ÿ There are no value fields or calculated key figures available. Ÿ KOKRS and PERIO must be selected as selection fields. Ÿ The special procedure for certain fields has already been described.There are certain restrictions for the data upload, which are described in detail in the section on further update topics.


BW: Replicating Data Sources

In this step, the definition of the Data Source that you just created is loaded into a SAP BW System. You are recommended to start the replication from the most detailed node to obtain an optimum response time. The replication of the entire SAP R/3 System takes a few minutes, but is started when you.create a Data Source for the first time.


BW: Attaching Info Sources

When a Data Source is assigned to an Info Source, the system proposes the field assignment, and the
transfer and communication structures. In addition, Info Objects and Data Sources are created on request.
Ÿ
For CO-PA fields (WW..., VV...) with names that consist of 5 characters, Info Objects are created with the naming convention OG_Cxxxxx (characteristics), 0G_Axxxxx (amounts) 0G_Qxxxxx (quantities) and 0G_Uxxxxx (quantity units). xxxxx stands for the name of the relevant CO-PA field. These InfoObjects are automatically assigned to the fields in the DataSource. Example:

VV007 / VV007_ME « 0G_QVV007 / 0G_UVV007.
ŸFields from the template operating concern (S_CP, S_GO, S_AL) and 0MB1 (Banking) and the retrieved key figures, use relevant InfoObjects in Business Content, which are automatically assigned to them. Please note that you must activate Business Content before assigning the Data Sources. Example: KMKDGR « 0CUST_GROUP.

Fields that are clearly presented in other Data Source/Info Source mappings, inherit this same mapping. Example: BUKRS « 0COMP_CODE. Ÿ To define or create missing Info Objects, you can use the standard procedure used in SAP BW. Hierarchies are not supported as yet, but a complete hierarchy extraction with PI-2000.2 (2.1C extractors) is being programmed.Choose Propose transfer rules to define unique rules and structures if the system has not yet defined them.


BW: Setting up the Delta Upload

CO-PA Data Sources support the delta method for a BW target system (see below for more details on transferring data in more than one BW System).to apply the delta method you need two Info Packages:

You can use the first Info Package to implement the initialization request. It is carried out at the beginning and then again after every assignment change in the source system. The other Info Package (from the same selection) is for the delta transfer and is usually scheduled on a daily basis. You can create it as long as the first initialization request is successfully complete.

ŸPlease note that is not possible to repeat a delta request to CO-PA.You can introduce the Info Package as an ABAP report with start variants, and a request as a scheduled execution of this report with the variant.

You no longer need RKEBW200 before a new initialization. As of PI-A99, the CO-PA replica status  After every new initialization request is automatically reset.After the system retrieves the data from the line item or the stigmatization levels, it aggregates the data, calculates the key figures and deletes the records with zero values. This is why the number of records that have been read and the number of records that are transferred into BW (both are displayed in TA KEB2) are considerably different.


Related Posts
No comments :
Labels: ABAP , abap programming , SAP ABAP , SAP BW
Subscribe to: Posts ( Atom )