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.
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.
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.
The posting rules for Bank Statement processing have been around for over a decade, but I find that there are still a lot of people (consultants and end-users alike) that do not fully understand how they function. This is probably because businesses normally accept the standard settings made by SAP or use them as a reference for new posting rules. The problem with that is that when there is an error during the bank statement processing, or if the appropriate account is not posted to correctly it will be difficult to troubleshoot the issue without understanding the different posting rules, posting areas and posting types and what they are used for. Now, I do not intend to go through all the steps needed to configure bank statement processing, but only the part that relates to defining posting rules.
To get to the configuration for defining posting rules, you need to go to the following configuration menu path (transaction SPRO) for Electronic bank statements:
Financial Accounting (New) -> Bank Accounting -> Business Transactions -> Payment Transactions -> Electronic Bank Statement -> Make Global Settings for Electronic Bank Statement
Or for manual bank statements:
Financial Accounting (New) -> Bank Accounting -> Business Transactions -> Payment Transactions -> Manual Bank Statement -> Define Posting Keys and Posting Rules for Manual Bank Statement
You can then double-click on the “Define Posting Rules” folder and this will bring you to the relevant screen of which I will explain the main columns:
Posting Rule: This represents the type of bank transaction – Checks out, checks in, wires out, bank fees, etc;
Posting Area: This determines whether you want the posting to only be made to the general ledger (that is to the main bank account and another G/L account) or to the vendor/customer account as well;
Posting Key (D): Debit posting key – which should only be entered if its corresponding account is not to be cleared.
Acct (Debit): This is the account symbol for the account to be debited. The account symbol can represent one account (such as the bank fees account) or a group of accounts (such as the clearing accounts representing “Checks out” from different banks);
Posting Key (C): Credit posting key – which should only be entered if its corresponding account is not to be cleared.
Acct (Credit): This is the account symbol for the account to be credited. The account symbol can represent one account (such as the bank fees account) or a group of accounts (such as the clearing accounts representing “Checks out” from different banks);
Doc. Type: This controls the type of document that will be posted for that posting rule. For example a posting from the main bank account to the clearing account could have doc. Type “SA”; a posting from a clearing account to a customer or vendor account could have a doc. Type “DZ” or “KZ” respectively.
Posting Type: This controls whether you simply want to post to the G/L or subledger account, or if you want to clear the debit or credit amount in the account with the posting from the bank.
On Account Posting Key: This is the posting key that is used when the G/L or subledger account cannot be cleared and hence the amount from the bank needs to be posted on the account.
In most companies the Goods Receipt/Invoice Receipt (GR/IR) clearing account is the most difficult to manage due to the number of lines that are posted to it. For this reason, SAP has a maintenance transaction for this account (transaction MR11). The purpose of this transaction is to whittle down the number lines in the account by writing off quantity differences that exist between a goods receipt and an invoice receipt, and reversing goods (or invoice) receipt postings that do not have corresponding invoice (or goods) receipts that they can be matched with.
When you are using transaction MR11 it is important to pay attention to the tolerance amount (this is the field that is called “Qty Var. Less Than/Equal To”) because it influences which lines are displayed when you execute the transaction, and hence which lines can be written off. For whatever percentage you enter in this field, the system will display any purchase order line that has a quantity variance that is less than or equal to that amount. This therefore means that if you enter too high an amount (like 100%), you could end up writing off a purchase order line which did not have a quantity difference but only shows up because its invoice has not yet been entered into the system. Therefore, if the invoice is subsequently posted, there will be no goods receipt to match it against. If on the other hand, you enter too low an amount (like 2%) you may not pick up several purchase order lines that have genuine quantity differences with the invoices that are posted to them, but for percentages that are higher than the one that you sent as a tolerance. The effect in this latter case is that you will have a constant mismatch of goods and invoice receipt lines in the GR/IR account and this will make the account even more difficult to manage.
To set appropriate tolerance level, I would suggest that you go with the following approaches:
(1) Set a percentage that matches the quantity variance tolerance that you have set up for the purchase order (which is made in transaction OMR6 under ‘Tolerance Key’ “DQ”). This way you will only be displaying purchase order lines whose invoices were not blocked for payment (and hence require further investigation) and can therefore be written off due to known or expected discrepancies.
(2) Set a percentage of 100% so that any goods receipts that have not been invoiced can be ‘reversed’. Note that if you use this approach, you have to be careful that you are not writing off a purchase order line that has been goods received but is still awaiting an invoice. You would therefore need to have a timeline for which goods receipts that have still not been invoiced can be written off. This timeline can vary between organizations but I would normally suggest that it is at least as long as the maximum payment term that you receive from any of your vendors. If for example you have a payment term of 120 days from a vendor, then I would recommend setting this timeline as three months. Therefore, if a goods receipt has been posted, but the invoice receipt to match it has not been entered after three months, then it is okay to write that goods receipt off. The way to set this timeline in transaction MR11 is by setting ‘To’ field of the purchase order date to three months before the period that you are running the transaction for.
There are also cases where you would want to uniquely treat a specific purchase order that does not fall in line with the above approaches. In that case you can simply leave the “Qty Var. Less Than/Equal To” blank so that all the variance lines for that PO appear and you can select which ones you want to write off.
Additive costs are extra costs that are added to a material’s cost estimate which are not calculated through the system. They are used in addition to the costs that are calculated automatically by the system using BOMs, routings, special procurement keys and other methods. A typical example of when you would use additive costs is when you have a warehouse that products are shipped to from your plant. The transportation costs for shipping the products should be added to the cost of the product at the warehouse. For example, if the cost of the product at the plant is $1 per lb and the transportation cost to get the product to the warehouse is $.10 per lb, the standard cost at the warehouse should be $1.10 per lb.
The transaction to enter additive costs is CK74N. You enter the material, plant and costing variant in the relevant fields and then hit the ‘Enter’ key. You then enter the “Costing From”, “Costing Due” and “Valuation” dates and hit the ‘Enter’ key again. The screen “Create Unit Cost Estimate – List Screen” then appears. Here you enter the values as follows:
Field
Explanation
Item Category
Enter the value “V – Variable Item”
Quantity
Quantity to be multiplied by the unitcost
Unit of Measure
Unit of Measure that the cost is based on
Description
Description of the type of additive cost
Price
The unit cost of the to be added
Cost Element
The secondary cost element that will be used to update the cost estimate
When you save the entries the cost will be added to the cost estimate of the product when it is calculated.
The problem with additive costs is that you can only enter them for a single material at a time. This could be quite cumbersome if you have several materials which need to have additive costs entered (which is normally the case). There is currently no standard program to update additive costs on a mass basis, so you have the options of either creating a custom program or creating an LSMW object. I prefer the latter as it does not require the assistance of a programmer.
You should create the LSMW using the Batch Input recording method. The transaction the recording should be based on should be CK74. The new additive costs transaction CK74N does not seem to work as well. Most of the generic steps needed to create this LSMW can be learned by reading the documentation on the SAP Help site. I will however, detail the fields that need to be specified in the “Maintain Source Fields” step. They are as follows:
Field
Description
KLVAR
Costing Variant
MATNR
Material Number
WERKS
Plant
TVERS
Costing Version
KADAT
Costing Date From
BIDAT
Costing Date To
BWDAT
Valuation Date
LST_SETNR
Unit Costing Item Number
TYPPS_01
Item Category
MENGE_01
Quantity
LTEXT_01
Description
LPREIS_01
Price
LPEINH_01
Price Unit
KSTAR_01
Cost Element
One thing to note is that if you entered a “Costing Date To” value of 12/31/9999 (which is typical when cost estimates are created), the next time you execute the LSMW the system will give you a message saying that a cost estimate already exists and will ask if you want to overwrite this. For that reason the LSMW’s batch input session will not be able to run in the background unless you confirm the message for each material (which could be a painstaking exercise). To avoid this, you may need to create a different LSMW for changing additive costs which is based on transaction CK75.
Delivery costs such as freight, customs, duty, and so on, can be planned on a purchase order so that an accrual is created when that order is goods received. This accrual is posted to an account that is separate from the Goods receipt Invoice receipt (GR/IR) account so that the relevant costs can be tracked separately from the cost of the product. When an invoice is received to match these planned delivery costs, it is a common scenario that the vendor that sends the invoice is different from the one that the product is bought from. For this reason, it is important to know the options for posting these invoices to a different vendor to the one that is proposed from the purchase order.
When you are matching a delivery cost invoice with the purchase order (using transaction MIRO), you need to make sure that you have the correct “Items Indicator” in the transaction (this is the drop-down field on the extreme right of the transaction screen, right above the “Layout” field). There are 3 possible settings:
Goods/Service Items: Choosing this indicator will display the lines that refer to the product(s) purchased. This is used where the invoice you are posting is from the product vendor and does not include any delivery costs;
Planned Delivery Costs: Choosing this indicator will display the planned delivery cost lines. This is used where the invoice you are posting is from the planned delivery costs vendor;
Goods/Service Items + Planned Delivery Costs: Choosing this indicator will display both the lines for the product purchased and the planned delivery cost. This is used where the invoice you are posting is from the product vendor and includes planned delivery costs;
Note that whichever setting you choose will be the default setting for the next time you use the transaction. You therefore need to be aware of the setting before you make a new posting, because you may for example, think that a purchase order does not contain any planned delivery costs (even though it does) because the relevant lines do not appear due to the setting “Goods/Service Items” being set.
You need to choose the “Planned Delivery Costs” indicator when you are posting delivery costs from a different vendor. However, this will not automatically propose the delivery costs vendor in the invoice posting. The system will propose the product vendor (or more accurately, the Invoicing Party in the Purchase Order). Since the purchase order can only have one invoicing party, you cannot set both the product and the delivery cost vendors as invoicing parties. You therefore have two options:
(1) Change the Invoicing Party in transaction MIRO: to do this, you need to go to the “Details” tab of the transaction, and in the “Inv. Party” field, enter the account number of the delivery costs vendor. When you hit the enter key, you will notice that the proposed vendor is now the delivery costs vendor. You can then carry out the posting as normal. This option is carried out by the finance team, and they therefore need to be careful not to post the invoice to the product vendor when they receive a delivery cost invoice from a different vendor.
(2) Set the delivery costs vendor in the condition of the purchase order: When the delivery cost condition is entered in the purchase order, you can select the condition line and click on the “Condition Detail” button (which looks like a magnifying glass) and enter the delivery cost vendor in the “Vendor” line of the ensuing screen. This way, when the finance team selects the “Planned Delivery Costs” indicator, the delivery cost vendor will be proposed as the invoicing party.
Note that you can also enter the delivery costs vendor at the goods receipt stage. To do this you need to enable the setting in the condition type of the delivery cost. Go to transaction M/06 and in the 'Control Data 2' section change the "Vendor in GR" field to "1" (Entry possible if vendor not maintained) or "2" (Entry always possible).
