SAPtips
Page 46
S AP tip s Journal April/ May 2008 V olume VI Issue 2
Define Depreciation Area Currency
Specify the currency for the new Depreciation Area with transac-tion OAYH, or via IMG‡Financial Accounting‡Asset Accounting ‡ Valuation ‡ Currencies‡Define Depreciation Area for Foreign Cur-rencies (Figure 15).
Activate the New Depreciation Area
The last step is to activate the new Depreciation Area 40 for each asset class that you plan to use in your new company code. You do this in transaction OAYZ, or via IMG‡ Financial Accounting ‡ Asset Accounting ‡Valuation ‡ Determine Depreciation Areas in the Asset Class.
You simply need to switch off the Deact indicator in the relevant asset classes, and if necessary, adjust the Depreciation Key and Default Useful Life according to your requirements (Figure 16).
Tip: If you already have some Asset master records for your tests in your company code, you can automatically open the new Depreciation Area using transac-tion AFBN, which is accessible via SAP Easy Access Menu‡ Account-ing ‡Financial AccountAccount-ing ‡Fixed Assets‡ Environment‡ AFBN
“New Depreciation Area” (see Figure 17).
4 On Financials
Figure 15: Define Depreciation Area Currency (OAYH)
Figure 16: Activate the New Depreciation Area (OAYZ)
Figure 17: Automatically “Open” a New Depreciation Area (Transaction AFBN)
SAPtips
Page 47
S AP tip s Journal April/ May 2008 V olume VI Issue 2
Figure 18 shows how I run transac-tion AFBN in my example.
This completes the Fixed Assets settings necessary to accommodate our parallel currency solution!
You should now take a moment to create a Fixed Asset in your system and then use the “Asset Explorer”
(transaction AW01 or AW01N) to verify that the new Deprecia-tion Area is working correctly (see Figure 19).
If you have no requirement to activate the Material Ledger in your new company, you have now completed all the required custom-izing and are ready to test the new functionality.
If you are going to use the Actual Costing/Material Ledger module in your company code, then you must also complete the configura-tion steps presented in the next installment of this series, “Parallel Currency: Actual Costing - Material Ledger settings”.
Conclusion
In this installment of my series on using parallel cur-rencies, I explained the benefits and nuances of parallel currency reporting in SAP. I presented an overview of the solution and then took you through the details of the biggest part of the required system settings.
In the next installment, I will look at the necessary steps to activate the parallel currency in the Material Ledger module and then use these parallel currencies to facili-tate local legally required reporting using, for example, exchange rates that are provided by the National Bank of your local subsidiary.
Dimitris Langas is an independent SAP consultant specializing in the Financials modules. He has partici-pated in numerous SAP implementations across many European countries and has worked with customers of almost any size, industry sector, and nationality in the EU. Working with business software since 1992 and with SAP products since 1998, he has undertaken many technical, functional, and management roles in a large number of IT projects. His current interests include financial process automation, accommodating financial reporting standards and local legal requirements on SAP ERP, and using SAP software and tools to turn transactional data and figures into valuable manage-ment information and insight. You may contact the author at [email protected]. Be sure to mention the author’s name and/or the article title.
≈
4 On Financials
Figure 18: Automatically “Open” a New Depreciation Area (Transaction AFBN)
Figure 19: Displaying a Fixed Asset with the New Depreciation Area (transaction AW01N)
SAPtips
Page 48
S AP tip s Journal April/ May 2008 V olume VI Issue 2 Editor’s Note: Disappointed by your system’s BI
per-formance? Take heart—things can improve. Anurag Barua demonstrates how to get that most out of your BI queries by focusing on a few areas the can make a significant impact on taking things from 0 to 60 in no time flat!
Introduction: Buyer’s Remorse?
Here’s an unlikely scenario but one that serves as a good analogy. Imagine that you are in the market for a car that meets all your criteria – a plethora of features, impeccable German engineering, peerless performance, classy interiors, premium brand, and your hubris. Let us say that after considerable research you settle on a Mercedes S550 and you estimate the final cost to be around $90,000. You convince your spouse and/or other stakeholders in your family, through a long and painstaking process, that this will be a worthwhile investment.
Finally, the rubber hits the road and your dream car is ready to roar. The first few months are a dream. Gradu-ally though, you start to see some disturbing signs.
Quite often your toy is coughing and sputtering instead of roaring. The engine is not exploding off the blocks, some of the sophisticated gadgetry is malfunctioning, and gasoline consumption is off the charts. You feel that the car is failing several of your initial criteria. And the fun and joy of driving it is receding just as the total cost of ownership (TCO) is starting to go up. Something has to change…
If you think of SAP® as the Mercedes of ERP software, this analogy is on target. And if you have upgraded to or installed SAP NetWeaver™ 7.0 (and BI 7.0 in particular), you expect very good (if not spectacular) performance, even without the BI Accelerator. If you believe that the performance of your BI queries is not what it should be, there are several measures that you can take to analyze, improve, and mitigate performance bottlenecks. In this article, I walk you through the most important ones.
Performance Improvement Measures If it’s time for some fine tuning on your BI engine, you can focus your effort on just a few areas for the greatest impact. These include:
• Secondary Indexes
This article fully describes steps to tweak, tighten, and otherwise improve BI engine performance for each of these areas.
Aggregates
Aggregates are mini-cubes built on top of InfoCubes.
An aggregate is a highly summarized version of the data in the underlying InfoCube. During query execution, if applicable, an aggregate is hit before the InfoCube, and this serves to improve performance. It is important to note that unlike multiproviders, aggregates actually store the aggregated data in the database. A multipro-vider enables users to run reports off more than one InfoProvider, by combining the information that resides in them in a “union” operation. When a query is run on a multiprovider, the processor spawns parallel sub-que-ries to the various InfoProviders, and this in turn expe-dites query execution. Users of aggregates (especially first-timers), tend to think of it as a silver bullet for the
“query is taking forever to run” problem.