on 12-07-2007 10:52 AM
Hi,
I have the following business scenerio at my client -->
1. Multiple company codes
2. Spread across globe.
3.Multiple currency.
Consolidation Requirement :
1.Company code wise
2.Geographical wise
3.Business Wise.
I have planned the approach as -->
1.Single Consolidation Area.
2.Multiple Dimensions.(i.e for Co Codes wise,Geography wise etc)
Is my approach correct? Or is there a better way of approaching.
Your valuable comments are requested.
The trick in this case will be to capture the partner characteristic for all three and execute eliminations for them. As Eugene indicated, the consolidation logic for reporting only interprets two characteristics as cons units. Thus, the best way, if possible is to have hierarchy of either company or business area (or profit center) arranged geographically.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Amit,
Let's analyze your requirements from the architeсture sideю
<i>
1. Multiple company codes
</i>
-- As always. No helpful info.
<i>
2. Spread across globe.
</i>
-- As always. No helpful info.
<i>
3.Multiple currency.
</i>
-- Happens. There is a rather std solution in SEM-BCS without impact on architecture.
<i>
Consolidation Requirement :
1.Company code wise
</i>
-- As always, even mandatory. No helpful info.
<i>
2.Geographical wise
</i>
It's more interesting. If your geography may be represented by sets of company codes, then we use a hierarchy of company codes for reporting, without any impact on data model.
<i>
3.Business Wise.
</i>
It's even more interesting. What kind of business wisdom? I see two possibilities. Like business area in SAP, cross-company wide aggregation. Or like profit centers wide.
The main open issue is reporting requirements. The most restrictive is balance sheet reporting. Do you need it for both, geography and business wide reporting?
If no, then your approach is correct.
If yes, then you may get it for 2 characteristics only. One of them, a company code, is determined already. You'll just have to choose the 2nd char, either geography, or business. To get B/S for the 3rd dimension is not a std functionality. But, I believe, there is a way out.
We are just working in this direction.
Hope your situation is not so severe.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Amit,
No, I didn't say that there is no posiibility to have reporting for more than 2 independent characteristics.
I just have this situation on my current project. We have a matrix structure, company plus profit centers. The 3rd char, like affiliates structure (that couldn't be represented by combination of companies and/or profit centers), I need to account for using non standard functionality. Most likely, it'l be an ABAP program that will balance my balance sheet by the 3rd char (dimension). And I'm still not sure that it'll be succesful.
And you'd better just understand clearly that such restrictions are apllied to balance sheet reporting. For reports like P&L and others, you don't need to balance items. Hence, it's enough to maintain such characteristics like attributes in the data model.
Certainly, what I said here was true for one data basis, and presumably, one cons area.
If you don't mind to load and consolidate data twice, you may go for another architecture.
I don't think that two cons areas will be enough. SInce they are subsets of settings in data basis. Two data basises with matrix structure in both!
I'll be happy if I'm mistaken.
If you want to derive balancesheet by business area also then explore the option of Matrix consolidation.
What kind of reports you need by geography? If it is additional drill down reports, then explore the option of using geopgraphy as attribute/navigational attribute in for the OCompany. This waya all data will be available by geograpphy including the jounal entries.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
9 | |
4 | |
3 | |
3 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.