FIGL BI Extraction

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 3
At a glance
Powered by AI
The main differences between old GL and new GL are that new GL allows a single account to capture details across multiple business scenarios and it enables document splitting to see transaction details at the lowest level.

The main differences are that new GL allows maintaining fewer number of accounts while capturing same level of details by allowing single account to be used across multiple scenarios, and it allows breaking down transactions using document splitting.

Document splitting in new GL allows breaking down a transaction into multiple segments to see the expenditure details at a granular level, for example splitting an office supplies purchase transaction into amounts spent on paper, cartridges, copier etc.

Difference between old GL and New GL: The main differences are a. Business scenarios b. Document splitting a.

Business Scenarios: If you are using classic GL there is a possibility your chart of account can have large number of accounts. Since you want to capture every level of details the chart of accounts grows in size. With New GL what you are trying to do is maintain fewer numbers of accounts and still get to same level of details. They way you implement this is by allowing a single GL account to be used in single or multiple scenarios (there are 6 scenarios). Asset module analogy will make it much easier. You maintain different books (depreciation area). Say you have 3 book areas 10, 20 & 40. When capitalization/acquisition/retirement/sale happens; each business processes impact these books differently based on the dep. area setting. b. Document Splitting: Lets say you buy office supplies for your company (say 5000 p.m). Now your company wants to see how much was spent on papers, cartridges, copier, markers and etc. With document splitting you are able to break down the 5000 p.m. to 2000 (paper) 1000 (cartridges) 1000(copier) 1000 (markers). Basically its the ability to see the details at minutest level. OR 1. Document Splitting option was not available in old GL it is in, New G.L to get a segment reporting according to the IFRS requirements. 2. Parallel Accounting, (Like, Leading ledger & non leading Ledger) 3.We can maintain different FSV with different fiscal variant according to the requirement of your company Via, non leading ledger.

With old G/L in R/3, the tables GLT0 (totals), BSEG, BKPF (Line Item) get filled. In BI side u have to use data model 0FI_GL_1 --> 0FI_GL_1 --> 0FIGL_C01 (for Totals).. 0FI_GL_1 is based on table GLT0 0FI_GL_4 --> 0FI_GL_4 --> 0FIGL_O02 (for Line item)... 0FI_GL_4 is based on table BSEG With New G/L in R/3, the tables FAGLFLEXT (totals), FAGLFLEXA, BSEG, BKPF (Line Item) get filled. In BI side u have to use data model 0FI_GL_10 --> 0FI_GL_10 --> 0FIGL_C10 (for Totals)... 0FI_GL_10 is based on table FAGLFLEXT 0FI_GL_14 --> 0FIGL_O14 (for Line item)... 0FI_GL_14 is based on tables FAGLFLEXA, BSEG, BKPF Functionally, this affects other financial modules like AP, AR, PCA (Profit Center Accounting) For ex: with new G/L implemented in BI side, this fulfils most of profit center accounting requirements, and u does not have to implement PCA module separately.

Delta Procedure
To transfer transaction figures from Financial Accounting, you can make important global settings in SAP R/3 in the table BWOM_SETTINGS The recording of changed transaction figures should be started at an appropriate time interval before the first data request in update mode initialization of delta procedure. To do this, you add the following entry to table TPS31 using transaction SM30 (view maintenance):

Process 5012

Country

Appl.

Function Module BWFI2P_WRITE_AEDA2_POINTER

With delta extraction, only new data or data that has changed since the last extraction is loaded into SAP BW. Data that has already been loaded and has not changed is not extracted and does not need to be deleted before a new load. This improves performance compared with periodic extraction of the entire dataset. The respective extractors read the Financial Accounting transaction figures directly from the SAP R/3 tables. A time stamp on the transaction figures determines the delta dataset. Time stamp intervals that have already been read are then stored in a time stamp table. The delta dataset is transferred directly, without records being transferred to the delta queue in the SAP R/3 system (extractor delta procedure). The transaction figures are extracted from the SAP R/3 system in their most recent status (after-image delta procedure). This delta procedure is not suitable for filling Info Cubes directly in the BW system. The transaction figures must therefore first be loaded in an ODS object that determines the changes to individual characteristics and key figures within a delta data record. Other data destinations (InfoCubes, ODS objects) can be provided with data from this ODS object. If the ODS object permits BEx Reporting, queries can be defined directly there. When a delta dataset has been selected successfully, the SAP R/3 system logs two time stamps that define a selection interval for a DataSource in table BWOM2_TIMEST: The time stamps are determined from the system date and time and converted into the format seconds since 1/1/1990 (with consideration of time zone and daylight saving time). To ensure correct and unique reconversion to date and time, the time zone and daylight saving time must be stored in table BWOM2_TIMEST. Constraints: No more than one delta dataset can be transferred for the Info Sources 0FI_*_6 und 0FI_*_7 each day. The extracted data therefore has the status of the previous day. The Info Source does not provide data for further data requests on the same day. This is the standard delivery, which you can change. For more information, see note 485958 Changed transaction figures are recorded in table BWFI_AEDA2 with the document key and the date/time of the last change. The extractors can use this log table and the time stamp procedures described above to determine a delta dataset of changed transaction figures in Financial Accounting.

http://help.sap.com/saphelp_nw04/helpdata/en/41/4b73415fb9157de10000000a155106/fr ameset.htm http://help.sap.com/saphelp_nw04/helpdata/en/af/16533bbb15b762e10000000a114084/c ontent.htm

0FI_GL_40
This DataSource provides the line items in General Ledger Accounting from tables BKPF, BSEG, FAGLFLEXA, .BSIS, BSAS, BSID, BSAD; BSIK, BSAK, FAGLBSIS, FAGLBSAS and VBSEGS. Line items can be requested in the general ledger view and in the entry view. Which view is applied depends on the ledger selected: Enter the desired ledger for the general ledger view, and enter a restriction to the initial value for the entry view (RLDNR = '')

Extractor Logic
In the entry view, the values of characteristics DOCNR, DOCLN, RFISCVAR, RYEAR and POPER are not defined because no posting has been made to a ledger in General Ledger Accounting. To simplify the analysis in this case, the values are taken from the corresponding fields in the entry view (DOCNR from BELNR, DOCLN from BUZEI, RFISCVAR from FISCVAR, RYEAR from GJAHR, and POPER fromMONAT). Accordingly, restrictions on the general ledger-specific characteristics are interpreted as restrictions on the corresponding entry characteristics when the data is read in the entry view. The DataSource can read open items. To restrict the selection to customer accounts, vendor accounts, or G/L accounts, you can use the characteristic Account Type (KOART). For the key date selection, you can use the characteristics Clearing Status (AUGST), Clearing Date (AUGDT), and Posting Date (BUDAT). The DataSource can also read line item that have not yet been posted (such as noted items). To restrict the selection to items with a specific status, you can use the characteristic Document Status(BSTAT_S).

0FI_GL_50
This DataSource provides the plan line items in General Ledger Accounting from table FAGLFLEXP.

You might also like