Extractor for Financial Statements

[Former Member]

Dear experts,

I'm trying to find out which extractor, ODS and cube do I have to use in order to show in a standard BW query the data for Financial Statements as they are shown in R3 with report RFBILA00.

I've been reading a lot, and I have tryed with several:

- 0FI_GL_4 updating cubes 0FIGL_C01 and 0FIGL_VC1. We used 0FI_GL_4 because tables GLT0 were empty in R3. This didn't give a very bad result, except for the account 129000 which represents the profit and loss for the year before. It doesn't appear the real ammount since it is just a flow of amounts without no document behing. For this we tryed with the standard query "0FIGL_VC1_Q0001".

Afterwards we were told that these tables (GLT0) were empty because they were using the New General Ledger, thus I updated the following flow:

- Extractor 0FI_GL_10 updating ODS 0FIGL_O10 which updated cubes 0FIGL_C10 and 0FIGL_V10. This doesn't work at all, very strange results are returned. We tryed with the standard query "0FIGL_V10_Q0001".

I have seen now that there is as well extractor 0FI_GL_14 but since I have tryed with so many and they haven't worked I am not sure to implement this one.

Does anybody know which standard extractor, ODS, cube and queries should I use in order to see Financial statements as in R3 report RFBILA00???

Thanks in advance to everyone, I really don't know how to continue or which is the issue....

Best regards,

Cecilia

[Former Member]

Hi Cecilia

Try Dennis' suggestions if you're on ECC 6 ( we're currently on ECC 5 ) there's obviously a few changes to FI with the available EHP3 plug in.

I guess you could try creating a view via (SE11) as a datasource, using the identified source fileds fields you have.

Good luck

Helen

[andrea_previati]

Hi

You should use this standard business content query 0FIGL_V10_Q0001 based on virtual infocube 0FIGL_V10

install them from business content

Hope it helps

[Former Member]

Hello Andrea,

Thanks for your reply, but we have already used this query and it is not giving is the correct result....We believe that this is because we are updating cube 0FIGL_C10 and thus 0FIGL_V10 with extractor 0FI_GL_4 instead of 0FI_GL_1. We are doing this because we are using the New General Ledger and thus we do not have updated in R3 tables GLT0, which are the ones that supply data to datasource 0FI_GL_1.

Nevertheless, tanks for your reply.

Best regards,

Cecilia

[dennis_scoville4]

If you're using the new general ledger reporting in ECC6 EHP3 (or greater), then try the delivered queries 0FIGL_M20_Q0001 (Transaction Figures: Account Balance) 0FIGL_M20_Q0002 (GL Account List). This is built off of the 0FIGL_M20 MultiProvider. Here's the flow into it:

0FI_GL_20 DataSource -> 0FIGL_R20 VirtualProvider and 0FIGL_C20 InfoCube -> 0FIGL_M20 MultiProvider

Or, you can still use the VirtualProvider and InfoCube that you've started using, but instead of sourcing with 0FI_GL_4, these should be sourced by 0FI_GL_10.

In general, you should be using the following general ledger extractors for pulling data from your ECC environment:

0FI_GL_10 - General Ledger Balances for Leading Ledger (delta-enabled)

0FI_GL_14 - General Ledger Line Items for Leading Ledger (delta-enabled)

0FI_GL_20 - Transaction Figures (delta-enabled)

0FI_GL_21 - Cumulated Balances

0FI_GL_40 - General Ledger Actuals Line Items

0FI_GL_50 - General Ledger Planned Line Items

3FI_GL_XX_TT - General Ledger Balances for Non-Leading Ledger (delta-enabled)

3FI_GL_XX_SI - General Ledger Line Items for Non-Leading Ledger (delta-enabled)

The reason for using these new extractors over the old extractors is that they pull data from the FAGLFLEX* tables in ECC, which didn't exist prior to the introduction of the new general ledger reporting in ECC6 EHP3. This could be the cause of you missing data.

[Former Member]

Hello Dennis,

Thanks for your answer, but we are using SAP ERP Central Component 5.0 and realease 640 for BW. Thus we are not able to use the Datasource you are talking about.

With this system status do you know how should we update this information? I've been trying several ways and never result with the exact correct numbers, which is very strange since in R3 they have all standard and BW should work then correctly with the standard.

Best regards, and points assigned for your helpfull answer.

Cecilia

[dennis_scoville4]

My apologies. I made an assumption that you were on ECC6 EHP3 or greater when you said, "...We are doing this because we are using the New General Ledger..." in an ealier post.

After re-reading some of your posts, I noticed that you stated that you're not posting data to GLT0 and therefore cannot use the 0FI_GL_1 or 0FI_GL_6 extractors. I'm wondering, does your end customers use PCA for financial reporting instead of general ledger. It's a fairly common practice. If that's the case, then you're going to want to use the 0EC_PCA_1 extractor and go that route. You have to be careful with that extractor, however, because it doesn't extract periodic balance transfer (ACTIV=PRC4) accounts and you have to extract those separately in a generic extractor. Typically Balance Sheet accounts, except for possibly inventory, are periodic balance transfer accounts. This means that instead of having activity posted to the account, the balance is deleted and a new balance re-inserted. 0EC_PCA_1 doesn't extract these types of accounts because it has no way of knowing when a balance has been deleted.

Now, if you end customer truly uses the general ledger for financial reporting, you're most likely going to have to create a custom report. Since there is no common flow to an InfoCube for 0FI_GL_4, you can load the data to 0FIGL_O02 and then build a custom InfoCube off of that to get the necessary aggregation for your report.

You should also look at your PSA to see if that account is even coming through. If you have account number and fiscal year/period setup as selectable, you can also do a test extraction in the source system on RSA3 to see if it's extracting that account in that period. It may actually be showing in Period 0, which ECC accounts for and shows as Period 1. If that's the case, you need to put in transformational logic to ensure that any values coming in for Period 0 are changed to Period 1 so that they show up in reports and aggregate to that period.

[Former Member]

Dear Dennis

I have one more doubt, since we were using the New General Ledger which supplies data to table FAGLFLEXT we tryed as well updating data with datasource 0FI_GL_10 "General Ledger: Leading Ledger Balances " into ODS 0FIGL_O10 (General Ledger (New): Transaction Figures) which updated afterwardscubes 0FIGL_C10 (General Ledger (New): Transaction Figures) and 0FIGL_V10 (General Ledger (New): Financial Statement). This virtual cube has a standard query named "Bal.Sheet and Profit and Loss (New):Actual/Actual Comparison". We supposed this query should show us the Balnce Sheet but data that appears in it has nothing to do with data in S_ALR_87012284.

Why does this flow is not working?

Nevertheless, thanks a lot for your help.

Best regards

Cecilia

[dennis_scoville4]

I don't have a satisfactory answer for your question as to why the standard content queries don't align with "canned" ABAP reports in R3/ECC.

The only only explanation that ever made some, but not complete, sense to me was somewhat formed in a question: "Why would we need to re-create a report in SAP BW if it's already available in R3/ECC?" Basically, the thought is that it doesn't make sense to have a redundant report. I would debate that there may be end users that shouldn't have to logon to the source system to get reports and also since those reports are real-time they could be using up system resources that are better suited for transactional activities (e.g. order to cash processing).

Take a look at the PSA data, as suggested before, to make sure that data isn't really being posted in Period 0. Typcally, balance carry forward type transactions are posted into that period and SAP BW standard content doesn't account for it in the Transformations. In those cases, we have to build some ABAP routines in the Transformations to force it to go to Period 1. In my case, I not only have to do that but also have to ensure that Periods 13-16 Fiscal Year-End adjustment postings are reflected in Period 12.

[Former Member]

Thanks again Dennis,

I feel the same about you regarding your question on why should we have a report which shows the same as in R3, but in SAP docuemntation it is said that with virtual cube you should be able to reproduce that report......

Let me try with your suggestion of the PSA and I will inform you how has it worked out!

Thanks a lot for your support!!!

Best regards.

Cecilia

[Former Member]

Hello Dennis,

I've been searching everywhere in BW this ammount but it doesn't appear. Nevertheless I believe it is normal since the ammount that I want to show is an ammount which doesn't appear in table BSEG because it doesn't has a document associated.

This ammount is a carry forwards from the year before into period 001.2009, but without document. Is not until period 006.2009 that a document is posted to the account 129000 with the ammount I would need to see in period 001.2009.

Let me explain again the issue in order to see if you or somebody else can help me.

We have in the balance sheet of R3 an ammount of 100 (for example) in the calculated node which represents the total result of the company for year 2008. This calculated node is part of the Balance Sheet and P&L hierarchy (0GLACCEXT infoobject). This is, in period 016.2008 we had an accu

At the beginning of the new year (2009) the ammount of 100 (amount of the calculated node) is carried forward to period 001.2009 without having a document behind since it hasn't been assigned yet. It is not until 006.2009 that the company assigns this ammount of 100 to a certain document and appears then in table BSEG.

What they see in R3 and what they need to see in BW is this carry forward of 100 from the calculated node of the hierarchy at the end of 2008 to the account node 129000 in period 001.2009 (although no document has been assigned to yet).

Is there any way to show this, this is a standard function in R3 and thus I believe in BW should be a way to show it the same way.

This is a reason why I believe extractor 0FI_GL_4 is not going to work, because this extractor extracts line items with a document behing (BSEG).

Any idea????

Thanks in advance for any advice, idea or help!!!!!!

Best regards,

Cecilia

[Former Member]

Cecilia

I wasn't familiar with report RFBILA00 but, when I ran the program RFBILA00 via (SE38) the resulting screen was a Financial Statement standard transaction. When I input restrictions on this transaction for COA, GL Account, Company Code and Financial Statement Version the results (for us) were nonsense. However, instead of accessing the transaction through (SE38) why not access directly using S_ALR_87012284; using the same restrictions here returns a result set that can be reconciled back to a number of other transactions including (FBL3N) and (FBL5N)? Or am I misunderstanding your question?

You may then use standard out of the box extractor 0FI_GL_4 , ODS 0FI_GL_O02 and cube 0FI_GL_C02 to ectract and load your data into BW.

I hope this helps

Regards

Helen

[Former Member]

Dear Helen,

Yes, program RFBILA00 is the same as the Information System S_ALR_87012284. My issue is that in this program in R3 I am able to see the Financial Statements with the correct hierarchy and the correct amounts. I would like to see the same in BW.

I already updated 0FI_GL_4 into cube 0FIGL_C10 and thus 0FIGL_V10. But the issue is that there is an account 129000 (profit & loss for the year before) which the amount that appears in R3 in the S_ALR_87012284 for 2009 does not appear in BW since there is no journal for this in R3 until year end processign happens - and even then the posting is made to period 001 of the new year 2009.

BW is not dragging the amount from 2008 to 2009, and I don't know if this is due because we are using 0FI_GL_4 extractor and it is a line item extractor (the amount dragged to this account doesn't have a document associated with it).

Thanks again!!

Cecilia