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.
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.
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.
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.
Drilldown reports have become more widespread with the latest versions of SAP ERP. What used to be available only for management reports in the Controlling Profitability Analysis (CO-PA) and Project Systems (PS) modules is now being used for financial statement reporting (with the SAP General ledger), Accounts Payable and Receivable Reports and many others. For that reason I want to show you a way that you can easily convert amounts that are displayed in drilldown reports into different currencies.
A typical example of where this may be used is when you have a month-end translation rate that you apply to your financial transactions at the end of the month. Although SAP translates currencies on a real-time basis, the rates are usually on a historical basis and will not reflect any short-term fluctuations that may have occurred.
You probably already know that SAP can translate the values from one currency to another as long as you have maintained the currency pair in the exchange rate table (TCURR). This table stores currencies by Exchange Rate Type. The default exchange rate type that is used in all company codes is “M – Average Rate” (unless you decide to change it to a different exchange rate type per document type in transaction OBA7). This means that any foreign currency is translated into the company code currency using this exchange rate. If you also want to translate your figures into a different exchange rate using an exchange rate type other than M, you would need to create a translation key by doing the following:
Go to transaction SM30 and enter table V_T242Q and hit the “Maintain” button. You will be prompted to enter an Application class (this controls which module the settings are to be maintained for). Choose the appropriate application class according to the drop-down list. Note that for the SAP General Ledger, you should choose Application class “FBRG - FI: Flexible general ledger”. You can then click on “New Entries” and enter a description for the Currency Translation Type, and enter the exchange rate type that you want to use (in the exchange rate table). You can then choose whether you want a fixed or variable ‘To Currency’ and ‘Currency Translation Date’ and whether you want an ‘Inverse Exchange Rate’. When you press the ‘Enter’ key you will be asked for the relevant ‘To Currency’ and ‘’Currency Translation Date’. You only need to specify these if you want them to be fixed, if not simply hit the ‘Enter’ key again. You can then save your settings and return to the initial screen.
In order to utilize the translation key that you set up, you need to ensure that the exchange rate type that you specified has been maintained for the relevant currencies in the exchange rate table (TCURR).
To change the currency displayed on a drilldown report to the one that you have set up, you need to execute the relevant drilldown report and click on the “Currency Translation” button (which has the “Dollar” and “Yen” sign on top of the number “100”) and enter the ‘To currency’ and drop-down in the “Translation Key” field. You will then see all the translation keys that exist, and you can choose the one that you have set up for the specific currency translation that you want.
