PaulOvigele's blog listings. Feed Zend_Feed_Writer 1.10.8 (http://framework.zend.com) http://www.insiderlearningnetwork.com/paulovigele Displaying Prior Year Balances after a New GL Migration By now, everyone knows about the New GL, which is now called the “SAP General Ledger”. By the way, who else finds the term “SAP General Ledger” confusing, since this term could also refer to the “General Ledger” module? I understand why SAP called it New GL as the name needed to symbolize the radical changes that were made from the original GL. However, when they realized that the “New” prefix will no longer seem appropriate as the years went by, why didn’t they take a page from Apple’s book and call it “General Ledger 2.0” or something? This will not only distinguish it from classic GL but will open up the possibility for future General Ledger updates. Anyway, I am digressing from the purpose of this blog so let me get back to the point…

When you go through a migration process, the key dates are the Migration Date (the end of a fiscal year) and the activation date (the date that you activate New GL). The migration populates the New GL tables (e.g. FAGLFLEXT) with data from the classic GL tables (e.g. GLT0) which relate to the prior years (that is, the years up to the migration date) and the current year (the periods between the beginning of the current year and the activation date).

What is not common knowledge (except to people who have been through a New GL migration) is that, after the migration process you are no longer able to view the balances of non-open item managed general ledger accounts from the years prior to the migration date. The prior year balances of these non-open item managed accounts form part of the current balance sheet value through the balance carryforward program; however you will not be able to see the individual balances of these accounts in the prior years. For example if you went to the G/L balance display transaction FS10N (which is changed to FAGLB03 after the migration) to view the balance of one of these accounts in a prior year, you will get a message saying “no data exists in fiscal year XXXX”. Also if you use one of the “list of G/L account balances” reports (such as S_ALR_87012277 or S_ALR_87012301) you will find that the historical information is incomplete because it only shows the balances of accounts that are managed on an open-item basis.

The ways to deal with these issues are as follows:

(1)    Displaying prior year balances using transaction FS10N: In order to display the prior year balances for non-open item managed accounts (which includes all Profit and Loss accounts) you need to go to your user settings by going to the top-menu “System -> User Profile -> Own Data” or transaction SU3. Then click on the “Parameters” tab and enter “CLASSIC_BAL_FS10N” in the “Parameter ID” column, and enter “X” in the “Parameter Value” column.

(2)    Displaying prior year balances using transactions S_ALR_87012277 or S_ALR_87012301: In the user profile settings (transaction SU3) click on the “Parameters” tab and enter “CLASSIC_BAL_FIREP” in the “Parameter ID” column, and enter “X” in the “Parameter Value” column.

If you want to view the prior year balances of these accounts when running the financial statement comparative reports, you will need to use the “rollup” method. For more information on this, go to SAPNote 893206.

I will be presenting the following sessions at the Financials 2013 conference. Hope to see you there:

Optimizing FI: Proven tips and techniques to better manage core financial accounting processes; Practical tips to maximize your existing CO solution and achieve more efficient managerial accounting; Streamline parallel valuation and actual costing with expert guidelines to exploit key material ledger functionality and; A step-by-step guide to reconciling CO-PA to the SAP General Ledger; What controllers and finance managers need to know to get better information from their SAP systems.

0 Comments - Leave a Comment
]]>
Fri, 15 Mar 2013 17:47:15 -0500 http://www.insiderlearningnetwork.com/paulovigele/blog/2013/03/15/displaying_prior_year_balances_after_a_new_gl_migration http://www.insiderlearningnetwork.com/paulovigele/blog/2013/03/15/displaying_prior_year_balances_after_a_new_gl_migration By now, everyone knows about the New GL, which is now called the “SAP General Ledger”. By the way, who else finds the term “SAP General Ledger” confusing, since this term could also refer to the “General Ledger” module? I understand why SAP called it New GL as the name needed to symbolize the radical changes that were made from the original GL. However, when they realized that the “New” prefix will no longer seem appropriate as the years went by, why didn’t they take a page from Apple’s book and call it “General Ledger 2.0” or something? This will not only distinguish it from classic GL but will open up the possibility for future General Ledger updates. Anyway, I am digressing from the purpose of this blog so let me get back to the point…

When you go through a migration process, the key dates are the Migration Date (the end of a fiscal year) and the activation date (the date that you activate New GL). The migration populates the New GL tables (e.g. FAGLFLEXT) with data from the classic GL tables (e.g. GLT0) which relate to the prior years (that is, the years up to the migration date) and the current year (the periods between the beginning of the current year and the activation date).

What is not common knowledge (except to people who have been through a New GL migration) is that, after the migration process you are no longer able to view the balances of non-open item managed general ledger accounts from the years prior to the migration date. The prior year balances of these non-open item managed accounts form part of the current balance sheet value through the balance carryforward program; however you will not be able to see the individual balances of these accounts in the prior years. For example if you went to the G/L balance display transaction FS10N (which is changed to FAGLB03 after the migration) to view the balance of one of these accounts in a prior year, you will get a message saying “no data exists in fiscal year XXXX”. Also if you use one of the “list of G/L account balances” reports (such as S_ALR_87012277 or S_ALR_87012301) you will find that the historical information is incomplete because it only shows the balances of accounts that are managed on an open-item basis.

The ways to deal with these issues are as follows:

(1)    Displaying prior year balances using transaction FS10N: In order to display the prior year balances for non-open item managed accounts (which includes all Profit and Loss accounts) you need to go to your user settings by going to the top-menu “System -> User Profile -> Own Data” or transaction SU3. Then click on the “Parameters” tab and enter “CLASSIC_BAL_FS10N” in the “Parameter ID” column, and enter “X” in the “Parameter Value” column.

(2)    Displaying prior year balances using transactions S_ALR_87012277 or S_ALR_87012301: In the user profile settings (transaction SU3) click on the “Parameters” tab and enter “CLASSIC_BAL_FIREP” in the “Parameter ID” column, and enter “X” in the “Parameter Value” column.

If you want to view the prior year balances of these accounts when running the financial statement comparative reports, you will need to use the “rollup” method. For more information on this, go to SAPNote 893206.

I will be presenting the following sessions at the Financials 2013 conference. Hope to see you there:

Optimizing FI: Proven tips and techniques to better manage core financial accounting processes; Practical tips to maximize your existing CO solution and achieve more efficient managerial accounting; Streamline parallel valuation and actual costing with expert guidelines to exploit key material ledger functionality and; A step-by-step guide to reconciling CO-PA to the SAP General Ledger; What controllers and finance managers need to know to get better information from their SAP systems.

0 Comments - Leave a Comment
]]>
0
Ensuring That the Appropriate G/L accounts are Entered in Purchase Orders Paul Ovigele, Ovigele Consulting

When purchase orders are entered in the standard SAP system, the general ledger account that is posted to is derived in the below ways:

(1)    If it is a purchase of inventory (stock), then the general ledger account assigned to the valuation class that is linked to the material is defaulted;

(2)    If it is the purchase of a fixed asset, then the general ledger account that is assigned to the account determination that is linked to the asset class that the asset belongs to is defaulted;

(3)    If you are not purchasing fixed assets or inventory, then the system will use the ‘Account Modification’ that is assigned to the ‘Account Assignment Category’ which is specified in the purchase order. This Account Modification is linked to a general ledger account in the account determination table (transaction OBYC). In this transaction, if you double-click on transaction key GBB and look at the relevant Account Modification (called “General Modification” in this table), it is the general ledger account that does not have a valuation class assigned to it that will be defaulted in the purchase order.

(4)    If you are not purchasing fixed assets or inventory but you do not want just one general ledger account to be defaulted for all purchase orders that use that account assignment category, then you can assign material groups (which are specified in the purchase order) to valuation classes, and in turn assign the valuation classes to general ledger accounts. You can find out more about this option in Part 7 (Tip 69) of my book “100 Things You Should Know About Financial Accounting”

If you have scenarios that do not fit into the options described above (and you do not use “feed in” systems into SAP ERP, such as EBP, CRM or an external system to create your purchase orders) then it is most likely that the folks in the purchasing department are entering the general ledger accounts manually in the purchase orders. No matter how well-defined your general ledger account descriptions are, they are still probably confusing to people in non-accounting departments, and hence it is very easy for them to enter the wrong accounts when making non-stock purchases.

My general recommendation to the above issue is to use options 3 or 4 above; however, if you simply want to restrict certain accounts (such as payroll) from being entered into POs then you can set the field status group of the G/L accounts to be incompatible with the account assignment categories used in the purchase orders.

For example if you are using account assignment category K (Cost Center), you can go to transaction OME9, double click on this account assignment category and make the field “Functional Area” an optional entry. You can then go to transaction FS00 for the G/L account (that you do not want to be posted on a purchase order), go to the “Create/bank/interest” tab and note the relevant ‘Field Status Group’; then go to transaction OBC4 and for the relevant Field Status Variant, double-click on the field status group that the G/L account is assigned to and double-click on “Additional Account Assignment” and set the Functional Area field to “Hidden”.

Once this is done, though a purchase order can be entered with account assignment category “K” and the above G/L account, the system will issue an error message when you save the purchase order because of the conflicting field statuses of the account assignment category and G/L account.

For more information on how to optimize your SAP Financials landscape, I've put together my top tips in the book 100 Things You Should Know About Financial Accounting with SAP  which is published by SAP Press.

0 Comments - Leave a Comment
]]>
Sun, 08 Jan 2012 22:39:07 -0600 http://www.insiderlearningnetwork.com/paulovigele/blog/2012/01/08/ensuring_that_the_appropriate_gl_accounts_are_entered_in_purchase_orders http://www.insiderlearningnetwork.com/paulovigele/blog/2012/01/08/ensuring_that_the_appropriate_gl_accounts_are_entered_in_purchase_orders Paul Ovigele, Ovigele Consulting

When purchase orders are entered in the standard SAP system, the general ledger account that is posted to is derived in the below ways:

(1)    If it is a purchase of inventory (stock), then the general ledger account assigned to the valuation class that is linked to the material is defaulted;

(2)    If it is the purchase of a fixed asset, then the general ledger account that is assigned to the account determination that is linked to the asset class that the asset belongs to is defaulted;

(3)    If you are not purchasing fixed assets or inventory, then the system will use the ‘Account Modification’ that is assigned to the ‘Account Assignment Category’ which is specified in the purchase order. This Account Modification is linked to a general ledger account in the account determination table (transaction OBYC). In this transaction, if you double-click on transaction key GBB and look at the relevant Account Modification (called “General Modification” in this table), it is the general ledger account that does not have a valuation class assigned to it that will be defaulted in the purchase order.

(4)    If you are not purchasing fixed assets or inventory but you do not want just one general ledger account to be defaulted for all purchase orders that use that account assignment category, then you can assign material groups (which are specified in the purchase order) to valuation classes, and in turn assign the valuation classes to general ledger accounts. You can find out more about this option in Part 7 (Tip 69) of my book “100 Things You Should Know About Financial Accounting”

If you have scenarios that do not fit into the options described above (and you do not use “feed in” systems into SAP ERP, such as EBP, CRM or an external system to create your purchase orders) then it is most likely that the folks in the purchasing department are entering the general ledger accounts manually in the purchase orders. No matter how well-defined your general ledger account descriptions are, they are still probably confusing to people in non-accounting departments, and hence it is very easy for them to enter the wrong accounts when making non-stock purchases.

My general recommendation to the above issue is to use options 3 or 4 above; however, if you simply want to restrict certain accounts (such as payroll) from being entered into POs then you can set the field status group of the G/L accounts to be incompatible with the account assignment categories used in the purchase orders.

For example if you are using account assignment category K (Cost Center), you can go to transaction OME9, double click on this account assignment category and make the field “Functional Area” an optional entry. You can then go to transaction FS00 for the G/L account (that you do not want to be posted on a purchase order), go to the “Create/bank/interest” tab and note the relevant ‘Field Status Group’; then go to transaction OBC4 and for the relevant Field Status Variant, double-click on the field status group that the G/L account is assigned to and double-click on “Additional Account Assignment” and set the Functional Area field to “Hidden”.

Once this is done, though a purchase order can be entered with account assignment category “K” and the above G/L account, the system will issue an error message when you save the purchase order because of the conflicting field statuses of the account assignment category and G/L account.

For more information on how to optimize your SAP Financials landscape, I've put together my top tips in the book 100 Things You Should Know About Financial Accounting with SAP  which is published by SAP Press.

0 Comments - Leave a Comment
]]>
0
Assigning Personnel Numbers to Vendor Accounts Paul Ovigele, Ovigele Consulting

If you use the Travel Management module, then you probably know that in order for employee expenses to be posted to financial accounting, the personnel numbers of the employees should be assigned to vendor accounts. When you do so, the vendor account  will be credited with the expense amount while the relevant expenses are debited to the general ledger accounts that correspond with the expense types that are entered in the Trip document.

The personnel number field is located in the ‘Accounting Information’ screen of the vendor master’s ‘Company Code Data’ section. If you have several employees in your company, updating this field for each vendor would be a cumbersome task which could require a custom upload program being created for this purpose. If you are not keen on taking this route, there are a few standard options that you can use which will accomplish the same purpose:

(1)    Create an LSMW project: This can be created with a recording of transaction FK02 and specify fields LIFNR (Vendor account number), BUKRS (Company Code) and PERNR (Personnel Number) in the Source Structure. The only issue with using an LSMW is that it may not be a function that is available to end users. Also it could create major problems if used incorrectly or by an inexperienced person

(2)    Use the mass maintenance function: This transaction can be accessed through transaction XK99. You would need to select table LFB1, enter the relevant vendor number range and company code(s) and execute the screen. You can then click on the ‘Select Fields’ button, pull in the personnel number and copy and paste the personnel numbers into the appropriate column for their respective vendors. One disadvantage of this approach is that you have to paste the values one page at a time, so depending on the number of employees in your organization it could be a tedious task.

(3)    Use transaction FK02CORE: This transaction can be used specifically to assign personnel numbers to vendors. If users in your company are not allowed to perform general mass maintenance for all vendors and you only want to allow the mass update of personnel numbers, this is a good transaction to use. Simply click on ‘New Entries’ and enter the vendor number, company code and personnel number. However, just as with transaction XK99, you can only copy and paste the personnel numbers one page at a time.

(4)    Create the Vendor Master directly from the HR record: To do this, you need to go to transaction PRAA. Enter the employees’ HR number in the ‘Personnel Number’ field (you can click on the ‘Multiple selection button to copy and paste multiple personnel numbers or ranges). Select the radio button ‘Initial setup’ in the ‘Maintenance mode’ section. You can then enter a reference vendor that the new vendor can be copied from. Make sure that this vendor uses internal and not external number assignment. You can then execute the transaction (initially in ‘Test run’) mode so that a batch input session is created, which you can process in transaction SM35. This is my recommended option as it is relatively easy to process for multiple personnel numbers without requiring much technical knowledge.

For more information on how to optimize your SAP Financials landscape, I've put together my top tips in the book 100 Things You Should Know About Financial Accounting with SAP  which is published by SAP Press.

0 Comments - Leave a Comment
]]>
Wed, 04 Jan 2012 21:33:23 -0600 http://www.insiderlearningnetwork.com/paulovigele/blog/2012/01/04/assigning_personnel_numbers_to_vendor_accounts_ http://www.insiderlearningnetwork.com/paulovigele/blog/2012/01/04/assigning_personnel_numbers_to_vendor_accounts_ Paul Ovigele, Ovigele Consulting

If you use the Travel Management module, then you probably know that in order for employee expenses to be posted to financial accounting, the personnel numbers of the employees should be assigned to vendor accounts. When you do so, the vendor account  will be credited with the expense amount while the relevant expenses are debited to the general ledger accounts that correspond with the expense types that are entered in the Trip document.

The personnel number field is located in the ‘Accounting Information’ screen of the vendor master’s ‘Company Code Data’ section. If you have several employees in your company, updating this field for each vendor would be a cumbersome task which could require a custom upload program being created for this purpose. If you are not keen on taking this route, there are a few standard options that you can use which will accomplish the same purpose:

(1)    Create an LSMW project: This can be created with a recording of transaction FK02 and specify fields LIFNR (Vendor account number), BUKRS (Company Code) and PERNR (Personnel Number) in the Source Structure. The only issue with using an LSMW is that it may not be a function that is available to end users. Also it could create major problems if used incorrectly or by an inexperienced person

(2)    Use the mass maintenance function: This transaction can be accessed through transaction XK99. You would need to select table LFB1, enter the relevant vendor number range and company code(s) and execute the screen. You can then click on the ‘Select Fields’ button, pull in the personnel number and copy and paste the personnel numbers into the appropriate column for their respective vendors. One disadvantage of this approach is that you have to paste the values one page at a time, so depending on the number of employees in your organization it could be a tedious task.

(3)    Use transaction FK02CORE: This transaction can be used specifically to assign personnel numbers to vendors. If users in your company are not allowed to perform general mass maintenance for all vendors and you only want to allow the mass update of personnel numbers, this is a good transaction to use. Simply click on ‘New Entries’ and enter the vendor number, company code and personnel number. However, just as with transaction XK99, you can only copy and paste the personnel numbers one page at a time.

(4)    Create the Vendor Master directly from the HR record: To do this, you need to go to transaction PRAA. Enter the employees’ HR number in the ‘Personnel Number’ field (you can click on the ‘Multiple selection button to copy and paste multiple personnel numbers or ranges). Select the radio button ‘Initial setup’ in the ‘Maintenance mode’ section. You can then enter a reference vendor that the new vendor can be copied from. Make sure that this vendor uses internal and not external number assignment. You can then execute the transaction (initially in ‘Test run’) mode so that a batch input session is created, which you can process in transaction SM35. This is my recommended option as it is relatively easy to process for multiple personnel numbers without requiring much technical knowledge.

For more information on how to optimize your SAP Financials landscape, I've put together my top tips in the book 100 Things You Should Know About Financial Accounting with SAP  which is published by SAP Press.

0 Comments - Leave a Comment
]]>
0
Currency Translation for Cost Center Reports Paul Ovigele, Ovigele Consulting

The cost center reports in SAP are normally displayed in Controlling Area currency. This means that if you have several company codes that have different currencies but belong to the same controlling area, the standard cost center reports will only be displayed in the currency of that controlling area. This is okay if you only want to display the cost center reports on a consolidated level; however if you want to be able to report the cost center values in the currency of the company code that the cost center belongs to, you would need to make the necessary setting in order to do so.

Firstly, you would need to set the reporting currency appropriately in your controlling user settings. To do this, go to transaction RPC0 and scroll to the tab called “Reporting Currency”. Here you can choose which currency you want the reports to be displayed in. If you have not made any settings in this transaction before, it is most likely that the “Controlling Area Currency” button will be the default setting. You should therefore click on the “Object Currency” setting if you want the reports to be displayed in the currency of the company code that the cost center belongs to. Note that the term “Object” relates not only to cost centers but to any other cost object that is used in Overhead Cost Controlling, such as internal orders, WBS elements, business processes, and so on.

When you save the settings in transaction RPC0, you will see that the next time you go to a cost center report such as with transaction S_ALR_87013611, the values with be displayed in the respective cost center currencies. One problem that you may find here is that you will no longer be able to view data from cost centers have different currencies (that is cost centers that belong to company codes in different countries) in one screen. The system will instead show an “X” character in areas where it cannot add two amounts that belong to different currencies. You will therefore need to have the flexibility to display the report in object currency as well as in controlling area currency without having to switch the settings in transaction RPC0 back and forth from Controlling Area to Object currency.

To switch the currency directly in the report you will first need to activate the “Expert Mode” indicator. To do this when you have executed the relevant cost center report, go to the top-menu “Settings -> Options” and check the “Expert Mode” checkbox. When you press the ‘Enter’ key you will see a few extra buttons appear in the top part of the report. One of these buttons is the “Currency Translation” button (which has the “Dollar” and “Yen” symbols on it). You can then click on the radio button “Translate to Target Currency”, and specify the currency and exchange rate type that you want to use to translate the report, and also choose which columns of the report should be translated.

For more information on how to optimize your SAP Financials landscape, I've put together my top tips in the book 100 Things You Should Know About Financial Accounting with SAP  which is published by SAP Press.

0 Comments - Leave a Comment
]]>
Mon, 02 Jan 2012 22:03:51 -0600 http://www.insiderlearningnetwork.com/paulovigele/blog/2012/01/02/currency_translation_for_cost_center_reports http://www.insiderlearningnetwork.com/paulovigele/blog/2012/01/02/currency_translation_for_cost_center_reports Paul Ovigele, Ovigele Consulting

The cost center reports in SAP are normally displayed in Controlling Area currency. This means that if you have several company codes that have different currencies but belong to the same controlling area, the standard cost center reports will only be displayed in the currency of that controlling area. This is okay if you only want to display the cost center reports on a consolidated level; however if you want to be able to report the cost center values in the currency of the company code that the cost center belongs to, you would need to make the necessary setting in order to do so.

Firstly, you would need to set the reporting currency appropriately in your controlling user settings. To do this, go to transaction RPC0 and scroll to the tab called “Reporting Currency”. Here you can choose which currency you want the reports to be displayed in. If you have not made any settings in this transaction before, it is most likely that the “Controlling Area Currency” button will be the default setting. You should therefore click on the “Object Currency” setting if you want the reports to be displayed in the currency of the company code that the cost center belongs to. Note that the term “Object” relates not only to cost centers but to any other cost object that is used in Overhead Cost Controlling, such as internal orders, WBS elements, business processes, and so on.

When you save the settings in transaction RPC0, you will see that the next time you go to a cost center report such as with transaction S_ALR_87013611, the values with be displayed in the respective cost center currencies. One problem that you may find here is that you will no longer be able to view data from cost centers have different currencies (that is cost centers that belong to company codes in different countries) in one screen. The system will instead show an “X” character in areas where it cannot add two amounts that belong to different currencies. You will therefore need to have the flexibility to display the report in object currency as well as in controlling area currency without having to switch the settings in transaction RPC0 back and forth from Controlling Area to Object currency.

To switch the currency directly in the report you will first need to activate the “Expert Mode” indicator. To do this when you have executed the relevant cost center report, go to the top-menu “Settings -> Options” and check the “Expert Mode” checkbox. When you press the ‘Enter’ key you will see a few extra buttons appear in the top part of the report. One of these buttons is the “Currency Translation” button (which has the “Dollar” and “Yen” symbols on it). You can then click on the radio button “Translate to Target Currency”, and specify the currency and exchange rate type that you want to use to translate the report, and also choose which columns of the report should be translated.

For more information on how to optimize your SAP Financials landscape, I've put together my top tips in the book 100 Things You Should Know About Financial Accounting with SAP  which is published by SAP Press.

0 Comments - Leave a Comment
]]>
0
Using Translation Keys in Drilldown Reports (Part 2) Paul Ovigele, Ovigele Consulting

This is a continuation of my previous blog, in which I describe how you can use translation keys for foreign currency conversion in drilldown reports. This functionality is useful in cases where you want to convert financial data into a specified currency at some point after the transaction has been posted. For example, you may have a month end rate, which is provided by a parent company or affiliate, and you want your reports to be translated at that rate at the end of the closed month. You can enter the rate for your specified exchange rate type using transaction OB08, and then use the Currency Translation button in the drilldown report to pick this rate up.

When you use the Currency Translation functionality, you have to decide what section of the report you want to translate. If you want the currency translation to apply to the whole report, simply follow the instructions described above. However, if you have different columns in the report and you want a different currency translation for each column, you will need to click somewhere in that column and hit the Currency Translation button. You will notice that in the ensuing pop-up box, a new section called “Area of Validity” appears in the top-part of the screen and it describes the specific line of the column that you clicked on. This may seem like the currency translation will only relate to that line, however it really relates to the whole column that the line exists in. You can then select the relevant currency and translation type that you want the column to be translated to.

If you do not want to keep selecting the Currency Translation button and change the settings key every time you want to convert the report’s currency, you may want to save the definition of the report so that it always defaults to the specified currency at the appropriate rate.

In order to save the definition of a drilldown report, you can go to the top-menu of the report and select the option “Report -> Save Definition”. You will then get a message at the bottom of the screen saying that the report has been saved. Alternatively, you can click on the “Save” icon, which also does the same thing. Note however, that you can only have one setting saved per report. This means that if (say) you set the currency of the report to convert to Euros at a month end rate, you will always have this setting when you execute the report. If you change the currency setting to Canadian Dollars, this will overwrite the previous setting. If you want to delete your setting or bring it back to the default currency you would need to do the following: When you execute the report, click on the Currency Translation button and then click on the “Database Currency” button, which is at the bottom of the pop-up box; then click on the ‘Save’ button so that the changes are stored.

For more information on how to optimize your SAP Financials landscape, I've put together my top tips in the book 100 Things You Should Know About Financial Accounting with SAP  which is published by SAP Press.

0 Comments - Leave a Comment
]]>
Thu, 29 Dec 2011 09:10:04 -0600 http://www.insiderlearningnetwork.com/paulovigele/blog/2011/12/29/using_translation_keys_in_drilldown_reports_(part_2) http://www.insiderlearningnetwork.com/paulovigele/blog/2011/12/29/using_translation_keys_in_drilldown_reports_(part_2) Paul Ovigele, Ovigele Consulting

This is a continuation of my previous blog, in which I describe how you can use translation keys for foreign currency conversion in drilldown reports. This functionality is useful in cases where you want to convert financial data into a specified currency at some point after the transaction has been posted. For example, you may have a month end rate, which is provided by a parent company or affiliate, and you want your reports to be translated at that rate at the end of the closed month. You can enter the rate for your specified exchange rate type using transaction OB08, and then use the Currency Translation button in the drilldown report to pick this rate up.

When you use the Currency Translation functionality, you have to decide what section of the report you want to translate. If you want the currency translation to apply to the whole report, simply follow the instructions described above. However, if you have different columns in the report and you want a different currency translation for each column, you will need to click somewhere in that column and hit the Currency Translation button. You will notice that in the ensuing pop-up box, a new section called “Area of Validity” appears in the top-part of the screen and it describes the specific line of the column that you clicked on. This may seem like the currency translation will only relate to that line, however it really relates to the whole column that the line exists in. You can then select the relevant currency and translation type that you want the column to be translated to.

If you do not want to keep selecting the Currency Translation button and change the settings key every time you want to convert the report’s currency, you may want to save the definition of the report so that it always defaults to the specified currency at the appropriate rate.

In order to save the definition of a drilldown report, you can go to the top-menu of the report and select the option “Report -> Save Definition”. You will then get a message at the bottom of the screen saying that the report has been saved. Alternatively, you can click on the “Save” icon, which also does the same thing. Note however, that you can only have one setting saved per report. This means that if (say) you set the currency of the report to convert to Euros at a month end rate, you will always have this setting when you execute the report. If you change the currency setting to Canadian Dollars, this will overwrite the previous setting. If you want to delete your setting or bring it back to the default currency you would need to do the following: When you execute the report, click on the Currency Translation button and then click on the “Database Currency” button, which is at the bottom of the pop-up box; then click on the ‘Save’ button so that the changes are stored.

For more information on how to optimize your SAP Financials landscape, I've put together my top tips in the book 100 Things You Should Know About Financial Accounting with SAP  which is published by SAP Press.

0 Comments - Leave a Comment
]]>
0