Skip to Content
0

Functional Area Hierarchy

Feb 12 at 01:36 AM

142

avatar image

Hello Friends,

We have a reporting requirement from business to show the PL statement with functional area dimension only. The hierarchy structure is defined by business. Currently we have a PL of GL accounts, which does not completely meet the needs.

After building the hierarchy we realised that the signage of the numbers in the functional area PL is reversed for Expense FA(eg support costs) if an Income GL account hierarchy node is selected for account dimension in the context, and if we select a Expense GL account node, the Income FA's have their signs revered.

Users want to have a dynamic PL based on FA which has a capability of drill down based on the FA hierarchy. Any ideas on how to fix the signage and allow drill-ability.

Attached sample report

Thanks for your time

Ed.capture.png

capture.png (23.1 kB)
10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

5 Answers

Vadim Kalinin Feb 12 at 06:26 AM
0

The sign on the report is depending on ACCTYPE property of ACCOUNT dimension - look on MEASURE formula. Theoretically you can create custom measure based on some function area property, but I don't think it's a correct approach.

P.S. Please don't use "Insert File" instead of "Insert Image"! I will not answer questions with "Insert File".

Share
10 |10000 characters needed characters left characters exceeded
Edward Masarri Feb 12 at 02:48 PM
0

Thanks Vadim for your reply. I have attached the screen shot as an image.

I came across this link, which states to use custom measures to define the signage of functional area node by defining a custom account type property on the functional ara

http://www.infogility.org/insight-blog/need-more-than-one-account-type-dimension-in-a-sap-bpc-model-it-is-possible/

Do you think this method will have severe reporting impact.

I need to tell the business there is a workaround but we will have a list of problems and sap does not recommend it.

Thanks for your time

Ed


capture.png (23.1 kB)
Show 1 Share
10 |10000 characters needed characters left characters exceeded

I still do not clearly understand the issue!

What members do you have in FUNCTIONAL AREA dimension?

How do they correspond to accounts?

0
Edward Masarri Feb 13 at 03:42 PM
0

I have attached the high level functional area hierarchy and top level GL account hierarchy as an image.

If we define custom measures on functional area dimension, and use those measures instead of the BPC standard measures would it give us correct results if we pull in account dimension too in the reports?


capture1.png (18.9 kB)
Show 4 Share
10 |10000 characters needed characters left characters exceeded

Sorry, looks like you are doing strange things!

You functional area is just another account dimension... Absolutely strange from accounting point of view!

To my mind there is some misunderstanding between business and BPC support.

0

Thanks Vadim for your reply.

The top level structure for Account and Function look similar.But for expenses as we dig in deep we might have the same set of accounts posted to different kinds of support or direct costs.

An account hierarchy would not be sufficient to show these costs separately. The cost centre's would define to which function that data is getting posted to.

Thanks for your time

Ed.

.

0

To my mind this approach is incorrect and will only create a confusion.

Hierarchy of functional areas has to correspond to some business structure and not to the chart of accounts.

0

P.S. Also you may have extra hierarchy in Account dimension.

0
Lucas Costa Feb 18 at 09:02 PM
0

It seems like your trying to create a new "GL" structure with your FA structure. Is the FA being derived in FI e.g.: via FI substitution?

Because usually FA is a further break down of the account movement but never the movement itself. E.g.: you can have something like production, IT, S&D, HR... These are driven out of business rules such as, as you said, based on the Cost Object...Profit Centre... The account plus the FA can then tell later on if the item is an SG&A, Selling Expense, or a production cost... E.g.: Account Wages + FA PROD = "prod. cost"... or Account Wages + FA SALES = Cost of Sales - Salary Direct Cost...

If your current Account Structure doesn't support the reporting requirements, what I recommend is to create a secondary Account structure in which you would fill with data based on the rules you'd apply for the structure you posted above. If this is required only for actuals, you can play around the conversion files. Or, of course, use Script Logic to do the job.

Share
10 |10000 characters needed characters left characters exceeded
Edward Masarri Feb 18 at 11:45 PM
0

Thanks Lucas for your reply.

The functional area in ecc-gl transaction data is derived by cost center's functional area,It is not derived by GL Account's functional area.

The business requirement is to show a reports for cos, support costs, direct costs etc using functional area hierarchy only, without merging the account dimension.

When you suggest an alternate account hierarchy, would that be a high level hierarchy of new nodes in account dimension which corresponds to functional area nodes?

Example - Move the data sitting in functional area for one of the support costs to an alternative account hierarchy element "support costs"?

We have this requirements for actual, budget and forecast.

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Yes, that's exactly what I am suggesting. Not a good idea to have an additional "account dimension".

For actuals, you can pretty much perform the mapping in the conversion file, e.g.: Account + FA, or Account + CC = Auxiliary account in BPC...

For budget, account transformation, dimension properties, script logic to generate the secondary structure.

0

That's exactly what I have proposed few days ago.

Please provide some detailed sample of ECC data and required reporting!

0