Feed for Paul Ovigele

Paul Ovigele, Ovigele Consulting

During my live Q&A session on last week “What’s changed in Profit Center Accounting with SAP General Ledger?”, I was asked a great question by two of the attendees which related to the reporting of secondary cost elements in Profit Center Accounting (PCA) under the SAP General Ledger. As the functionalities of the SAP General Ledger such as Segment Reporting and Document Splitting are focused more on getting more transparency in your balance sheet, it is easy to think that the profit and loss accounting aspect (which includes secondary cost elements) has somewhat been neglected. Since profit center accounting has been moved into the general ledger module, this has not only changed the navigation path to profit center transactions (which is now in the Financial Accounting area), but it also means that most of the transactions that existed in the Controlling area for PCA are no longer useable.

If you have activated the New General Ledger but you find that you can still display and execute all the transactions that exist in the Profit Center menu of the Controlling module, then it is probably because you have not deactivated the Profit Center component from your Controlling Area (transaction OKKP). It is recommended by SAP to deactivate this component after a time period so that you do not have increased data volumes due to the parallel updates in New GL (which should already have the profit center scenario activated) and Classic PCA.

However, if you use one of the SAP General Ledger reports such as with transaction S_PL0_86000028 for profit center reporting, you will lose some of the visibility of the postings to secondary cost elements. As one of the Q&A attendees pointed out, the FICO reconciliation account (which is the self-balancing account that is posted to when a cross-profit center posting is made) is usually a single account and does not tell the whole story with certain CO transactions such as assessments, overhead allocation, activity allocation, and so on. These transactions are captured in more detail with secondary cost elements, but secondary cost elements are not visible in most New G/L reports. The classic PCA reports which are found in the menu path “Accounting -> Controlling -> Profit Center Accounting -> Information System -> Reports for Profit Center Accounting -> Interactive Reporting” provided you with this visibility.

The equivalent reports in the SAP General Ledger which will show the secondary cost elements by profit center can be found in the following menu path (note that I am using release ERP 6.0 enhancement pack 4 in my example): Accounting -> Financial Accounting -> General Ledger -> Information System -> General Ledger Reports (New) – Reports for Profit Center Accounting (the transaction codes for these reports are in the range S_E38_98000088 to S_E38_98000091. You will find that these are very flexible drilldown reports that can be sorted by various characteristics such as account number, cost element, segment, profit center, functional area and so on.

If you cannot find this menu path in your system, it means you have not activated the New GL business function. To do this go to transaction SFW5, open up the “Enterprise Business Functions” folder and activate the business function FIN_GL_CL_1.

For more infrormation 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.

Paul Ovigele, Ovigele Consulting

The travel management module allows you to record your travel expenses in the SAP system as “Trips”, and with the proper approval, allow them to be settled to the financial accounting module. There are a number of ways of recording trips: by using transaction PR05 to enter the expenses; by using transaction TRIP to enter travel requests and expenses; or by using the “Employee Self Service” (ESS) portal, to enter travel requests and expenses. The approach that is taken varies with different organizations – the first two are available within the SAP ERP system, and the third requires the ESS environment to be set up in your SAP landscape. Whichever, approach that is used the method of posting to financial accounting is generally consistent. I will detail the steps that are to be taken to post a travel expense trip to the financial accounting module.

Trip Settlement – Once the trip has been approved, it can be settled. This is done using transaction PREC. You would need to enter a payroll area (which groups employees for payroll purposes, but is also needed in the Travel management module) and the period of settlement. Then you can choose whether to settle a particular employee’s trips, a particular trip, or all trips for all employees in the period.
Posting Run Creation – Once the trip has been settled, you can perform a posting run which collects all the trips that can be transferred to accounting and designates a posting run number to them by using transaction PRFI. You can choose whether to post a particular employee’s trips, a particular trip, or all trips for all employees in the period. With this transaction you can also choose to whether or not replace incorrect CO objects with the cost center that exists in the Travel Privileges infotype 0017 of the employee. To do this, you can select the “Replace incorrect CO objects” checkbox.
Posting Run Management – For all the trips selected from the “Posting Run Creation” step, you can post them to financial accounting by using transaction PRRW. You simply enter the username of the person that created the posting run and enter the date of creation. When you click on the ‘Execute’ button you will see a list of posting runs that can be transferred to the FI module. You can then highlight the relevant posting run and click on the ‘Post’ button. You will then get a message asking if you want to transfer the documents immediately or create a background job. If you click on the “Post immediately” button and there are no FI/CO errors with the document, then the accounting module will be immediately updated.

If you do not want to perform all these steps manually, you can create each one as a background job in sequential order. To create transactions PREC and PRFI as jobs, you can simply go to the transaction and go to the menu “Program -> Execute in Background” to schedule the job as normal. To create transaction PRRW as a background job you need to execute program RPRPOSTD. You can then select the “Post” button and the “All possible posting run” button, and then go to the menu “Program -> Execute in Background” to schedule the job as normal.

Paul Ovigele, Ovigele Consulting

In my upcoming session “Accelerate local and global financial closes and period-end reports with improved integration between profit center accounting and the general ledger” which I will be covering in the Reporting & Analytics conference, I will be discussing the integration of profit center accounting with the SAP General Ledger and how the new functionalities aid your period-end processes and reporting.

For those of you that use or are thinking of using the document splitting functionality in the SAP General Ledger, it is important that you understand how passive splitting works. It is easy to overlook this aspect of document splitting, because unlike the other two types (active splitting and zero-balancing) you do not really have to make any specific configuration settings in order for it to work. However, by understanding how the functionality works this will help you to set up your master data and business processes accordingly.

In order to understand passive document splitting, you need to understand the principle of document splitting. This is the process which assigns a characteristic (such as a profit center) to the line item of a financial document by inheriting the account assignment of the offsetting line of that document, with a view to producing full profit center balance sheets. The simplest example is where a customer posting inherits the profit center from the revenue line of an invoice document (the profit center of the revenue line would normally come from the material master or sales order). When this happens the system has performed active splitting. When the invoice is paid, the system will also need to inherit the profit center from somewhere. However, with a payment transaction, the system cannot directly access the profit center from the offsetting line (as the postings usually involve a bank account and a customer account which would not contain the original profit center). Therefore, the system has in-built program logic that can determine which profit center was posted to when the customer line item was posted (during invoice processing) and this profit center is adopted in the customer line of the payment transaction. This is the function of passive splitting.

It is easy to see that, with the system performing the function of passive splitting you do not need to repost items in the “dummy profit center” in cases where the system could not determine the appropriate profit center at the time of the posting. An example that I have experienced in classic general ledger, is where you reset a payment which was cleared in a previous month, but is now open in the current month. When this happens the system assigns the dummy profit center to the payment posting, and you would need to trace this document back to the original invoice which was previously cleared to determine which profit center to assign it to. Then you would need to perform a profit center reposting, either through an assessment/distribution or via a profit center transfer posting (transaction 9KE0). Needless to say, this adds more tasks to your period-end processes and potentially increases your time to close. Passive splitting, therefore helps reduce the number of manual activities performed at period-end and consequently improves the accuracy of your financial reporting.

Paul Ovigele, Ovigele Consulting

When using the automatic payment program to make payments to vendors, the normal procedure is for the system to select all the vendor items that you have set in your parameters, and as long as the items are due they will be proposed for payment at the full amount. If however, you do not want to pay the full amount of certain invoices you will not be able to accomplish this in the payment program. Even though you can edit the proposal, the invoice amounts are not among the fields that are editable. This leaves you with the less adequate option of using the manual payment transaction (F-53) to make partial payments.

There is however, a way you can make partial payments in the automatic payment program, by using the special G/L transaction for payment requests. There are a few steps to be taken to set up this functionality, and they are detailed below:

Configure automatic posting keys for payment requests (transaction OBXP): This is normally set up in the standard system, however make sure that both the debit and credit posting keys are relevant for vendor postings (account type K). If not select the appropriate posting key or create an appropriate one in transaction OB41. Also note the special G/L indicator that is used for payment requests, which is specified in the “Special G/L Ind.” field of transaction OBXP.
Set up the Alternative Account for the Special G/L Indicator (transaction OBXT): Double-click on the relevant special G/L indicator for payment requests and enter the reconciliation account(s) for vendors and the corresponding special G/L account. This is the same type of configuration that is made for down payment accounts (transaction OBYR) so you can use the same (or a similar) special G/L account that is set up there.
Add Special G/L indicator to Company Code’s Payment Program settings (transaction FBZP): Click on the button “All company codes” and add the payment request special G/L indicator to the field “Sp. G/L transactions to be paid” field in the “Vendors” section.

Once the above settings have been made, vendor you can enter the vendor invoices as usual. If for example, you enter an invoice for $1,000, but only want to pay $400 in the next payment run, you will need to create a payment request for this invoice as follows:

Go to transaction F-59 and enter the document number of the invoice, the company code and fiscal year and hit the ‘Enter’ key. Then confirm the header data by hitting the ‘Enter’ key again. In the subsequent screen you will see the total amount of the invoice ($1,000 in our example). Simply overwrite this amount with the amount that you want to pay ($400) and post the document. If you go to the vendor line items (transaction FBL1N) you will need to select the ‘Noted Items” check box as well as “Normal Items” and you will see that there are two lines for that invoice in the vendor’s account. One is for the actual invoice, and the other is for the payment request (which is a one-sided entry). You should block the actual invoice for payment by double-clicking on the line, clicking on the ‘Change’ button and entering the relevant payment block.

When you create the payment run, the system will propose only the payment request amount (for $400). When you have made payment, the system will clear the payment request noted item with the payment amount which will now appear in the vendor’s account as a special G/L item. When you are ready to pay the balance of the invoice, the payment program will net off the invoice amount ($1,000) with the special G/L amount ($400).

Paul Ovigele, Ovigele Consulting

In my previous blog, titled “Secondary Cost Element Reporting in SAP General Ledger PCA” I discussed how you could run reports in the SAP General Ledger which include secondary cost elements. These reports which range from transactions S_E38_98000088 to S_E38_98000095 are flexible drilldown reports which allow you to view all the accounting elements that are posted to in the profit center and segment characteristics. The crux of the above article was based on the reporting the secondary cost elements of actual data, for example, overhead cost allocation to production orders, actual assessments, actual activity allocation and so on. However you would also need to ensure that the data for secondary cost element planning flows into these reports as well. Examples of this data are plan assessments, manual planning of secondary costs, internal activity allocation planning, and so on.

There would therefore be a need to bring secondary cost elements into the planning part of the SAP General Ledger. As you will notice from the reports mentioned above, a number of them are based on the comparison of plan and actual data for the specified characteristic. There are a couple of steps that are needed to bring secondary cost element planning into the SAP General Ledger:

First of all you would need to create a plan version for the ledger(s) that you want to report on. To do this, go to the configuration menu path (SPRO): Financial Accounting (New) -> General Ledger Accounting (New) -> Planning -> Plan Versions -> Define Plan versions, or totransaction GLPV. You can then click on ‘New Entries’ and enter the ledger that you are using (for example ‘0L’) in the ledger column; enter a version (for example ‘1’ in the version column); check the box “Man. plan” if you want to perform manual planning in the ledger; check the box “Integ. Plan” so that plan data from the controlling overhead management (CO-OM) and controlling profitability analysis (CO-PA) modules can be transferred to the SAP General Ledger; and enter a description for the version that you created. Note that you can create several plan versions for your ledger, depending on how many different simulations of your budget and forecasts are needed, just as you would do in the controlling modules CO versions.

You then need to activate plan data integration for secondary cost elements. To do this, go to the configuration menu path (SPRO): Financial Accounting (New) -> General Ledger Accounting (New) -> Planning -> Activate Plan Integration for Secondary Cost Elements or to transaction “FAGL_PLAN_ACT_SEC”. You will initially see a red button indicating that plan data activation for secondary cost elements is not active. Check the boxes “Activate” and “Transport Change” and hit the ‘Execute’ button. You will eventually get a message saying that “Plan data integration was activated for secondary cost elements” and the red indicator will now be green.

When you go to one of the SAP General Ledger reports such as transaction S_E38_98000088, and enter the relevant information such as currency type, ledger, controlling area, periods, etc, you would also need to enter the plan version that you created in the ‘Plan version’ field in order to execute the report.

Paul Ovigele, Ovigele Consulting

The cost center accounting module has several great reports that can be used to analyze the plan, target and actual costs, broken down by cost elements in a particular period or range of periods. These reports are normally satisfactory to most users due to their flexibility (you can report on one or many cost centers and groups) and detail (you can drill down into each cost element line to find the individual transactions that make up that line) and they can be found in the below menu path:

Accounting -> Controlling -> Cost Center Accounting -> Information System -> Reports for Cost Center Accounting

One disadvantage of these reports though is to do with the options that you have on the selection screen. When you click on the ‘Multiple Selection’ button (the box with a yellow arrow), you will see that you only have the option to select single cost center values or ranges. This means that unlike other reports’ selection screens (see transactions FBL1N, FAGLL03, or S_ALR_87011963 for example) you do not have the option to exclude cost center values from your report selection. One obvious way to do this is to use cost center groups (or ranges) and exclude the relevant cost center(s) from the group. This however, is not a very flexible approach. Cost center groups do not allow you to exclude cost centers either, and you would instead need to create ranges in the group which circumvent the cost center(s) you are trying to exclude. Needless to say, this is a cumbersome process and not really flexible for quick and expedient reporting.

A great but underutilized option is to use selection variants. These can be created in transaction KM1V. Enter a variant name and click on the “Create” button. You will then see a number of fields within which you can enter different criteria. Click on the ‘Multiple Selection’ button to the right of the “Cost center” field. You will see the four normal tabs that you can use to include or exclude cost center values or ranges. You can then enter the cost center(s) that you want to exclude in the “Exclude Single Values” tab, click on the ‘Execute’ button and click on the ‘Attributes’ button to name and save the variant.

Note that selection variants can be used for a whole bunch of other purposes by restricting or specifying values in all the other fields that exist in the “Maintain Variant” screen.

When next you go to a cost center report, such as one of the most commonly used ones – transaction S_ALR_87013611; simply enter a period and the selection variant that you created in the “Cost center group” field. For example, if you created a selection variant called “BURDEN”, then enter the value “.BURDEN” as the cost center group. When you execute the report you will see that the cost center(s) that you excluded will not be shown.

You can easily change the selection variant by going back to transaction KM1V, entering the variant name and clicking on the “Change” button. You can then amend the variant accordingly, save it, and re-execute your cost center report containing the selection variant.

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.

Paul Ovigele, Ovigele Reporting

A question that came up both during my Q&A session last month and my presentation in the Reporting & Analytics conference concerned the use of characteristics such as WBS elements for document splitting. The standard scenarios that exist in the SAP General Ledger contain the profit center, segment and business area fields which can be defined as document splitting characteristics so that full balance sheet reporting can be made by those dimensions. However, there is no scenario that contains the WBS element field (PSPNR) and hence you cannot readily define this field for document splitting. Some organizations use the project systems module heavily in their SAP landscape, and it may be more important to see full balance sheets by WBS element rather than the other fields that are available.

To accomplish this, you would need to add the WBS element field as a customer enhancement field in the SAP General Ledger totals table FAGLFLEXT. You can do this by going to transaction FAGL_GINS enter totals table FAGLFLEXT and hit the ‘Change’ button. Then in the ‘Field Name’ column, enter the value “ZZPS_PSP_PNR” (the prefix “ZZ” is the naming convention required for defining customer fields) and save and activate the setting. You can then go to the following configuration menu path (transaction SPRO) to add the WBS element field to your relevant ledgers:

Financial Accounting (New) -> Financial Accounting Global Settings (New) -> Ledgers -> Ledger -> Define Scenarios and Customer Fields to Ledgers

You can then highlight the relevant ledger, double-click on the ‘Customer Fields’ folder and click on the “New Entries” button to add the field to your ledger. You would then need to define the WBS element field as a document splitting characteristic. To do so go to the configuration menu path:

Financial Accounting (New) -> General Ledger Accounting (New) -> Business Transactions -> Document Splitting -> Define Document Splitting Characteristics for General Ledger Accounting

You can then click on ‘New Entries’ select the WBS Element field and then check the ‘Zero balance’ box (if you want every document to be balanced per WBS element) and the ‘Mandatory’ checkbox (if you want to the system to issue an error message if a WBS element does not exist in a document). You need to be aware that by checking the zero balance checkbox, the system will post as many extra lines as is necessary to make sure that all WBS elements in a document are balanced to zero.

If you have several WBS elements in a document, this will create several extra lines every time this document is processed. You therefore need to decide if it is worth performing zero-balancing at that level or if you can use a more summarized characteristic such as profit center or segment (which all WBS elements can be assigned to) to produce full balanced sheets. In order that every transaction contains a WBS element, you would need to enable the field status of this field in the general ledger accounts’ field status variants (by using transaction OBC4).

Once the WBS element field is available in the FAGLFLEXT table, you can pull it into the relevant SAP General Ledger reports such as Report Painter, Drilldown reports and Business Information reports.

Paul Ovigele, Ovigele Consulting

One of the topics that I will be covering at the Reporting and Analytics Conference is on the use of drilldown reports to enhance your financial statement reporting. Drilldown reports are interactive reports that you can use to analyze your data according to various characteristics, and display the results in value “buckets” known as key figures. They are usually associated with Controlling Profitability Analysis (CO-PA) reports, as this module contains several reporting dimensions such as customer, product, plant, region, etc which can be grouped into profitability segments.

In the SAP General Ledger, combination of several ledgers into a single table means that the fields associated with the ledgers are now available for reporting. Hence, when you define scenarios such as “profit center update”, “cost center update”, “segment reporting” and “cost of sales accounting” in your ledger, you also inherit the fields (profit center, cost center, functional area, etc) that come along with them. This means that unlike previously where you could only produce financial statements by general ledger account, you can now do so by any of these characteristics. You can also “slice and dice” your financial statement by several characteristics, for example, by all the profit centers in a particular segment, or all the accounts posted in a profit center in a segment, and so on. This provides more transparency in your balance sheet and gives you a single-source of information for all dimensions which eliminates any reconciliation nightmares (remember when you had to reconcile profit center and business area reports back to the financial statements?).

As you know, there are now various reporting options out the ERP system – Business Information, Business Objects, etc where all the financial information can be passed to for more flexible analysis (there are several other great sessions in the R&A conference that cover these areas). However, I will discuss a simple way in the ERP system that you can create a drilldown report. Depending on your requirements, you may prefer to build the report from scratch, but I find that the easiest way to do it is to copy a standard report that already exists. You can do this by going to the following configuration menu path (SPRO): Financial Accounting (New) -> General Ledger Accounting (New) -> Information System -> Drilldown Reports (G/L Account) -> Form -> Specify Form

Here you can double-click on the “Create Form” option, enter a form name, and in the ‘Copy from’ section, enter the name of the standard form that you want to copy. Hit the ‘Create’ button, and then you can add or modify the key figures that you need. When you save the form, you then need to create a report from it. To do so, go to the configuration menu path (SPRO): Financial Accounting (New) -> General Ledger Accounting (New) -> Information System -> Drilldown Reports (G/L Account) -> Report -> Define Report

Double-click on the “Create report” option, enter the report name, and once again you can copy an existing report by specifying it in the ‘Copy from’ section and hit the ‘Create’ button. On the right part of the subsequent screen you can select the characteristics that should be available in the report by highlighting them and using the arrow “Add char.” to pull them into the left part of the screen.

Once you have saved and generated the report, you can either assign it to a custom transaction code (using transaction SE93) or you can access all the drilldown reports (for the SAP General Ledger) by using transaction FGI3.

Paul Ovigele, Ovigele Consulting

There are basically two main ways of tracking projects in SAP – by using WBS Elements in the Project System (PS) module, and using internal orders in the Controlling (CO) module. The Project System module is much more robust and has extensive project tracking, recording and reporting capabilities, however using internal orders is a sufficient way of monitoring your projects without some of the complexities involved in the Project Systems module.

If you simply want to track short-term project costs (CAPEX overhead, marketing, R&D, etc) for planning and reporting purposes, you can use statistical internal orders. As opposed to real orders, you do not need to settle statistical orders (hence saving time on any extra month-end steps) to another cost object. However, it means that if you are making expense purchases, you would need to specify a cost object (such as a cost center) as well as a statistical order. By specifying an internal order alone, you will get an error message by the system, asking you to enter a real cost object.

If you are making a Capital Expenditure (CAPEX) purchase, you would need to specify a statistical cost element (balance sheet account) in order to use a statistical order. Fixed Asset balance sheet accounts can be created as statistical cost elements by going to the following configuration menu path (SPRO):
Financial Accounting (New) -> Asset Accounting -> Transactions -> Budget Monitoring with Statistical Orders/WBS Elements -> Create Statistical Cost Elements

You can then double-click on the activity “Create Cost Elements for Project/Order Account Assignment”; then enter your Controlling Area, a ‘Valid from’ and ‘Valid to’ date, and hit the ‘Execute’ button. The system will then produce a log of the accounts that have been created as statistical cost elements and assign to them a cost element category of ‘90’.

In order to create a statistical internal order, you check the ‘Statistical’ indicator in the order master data. You can find this in the ‘Control data’ tab of the internal order master data transaction (KO01 to create or KO02 to change). Once the statistical indicator is flagged, you will not be able to create a settlement rule for the order, as these orders cannot be settled.

Some users have asked me to set up certain order types so that the ‘statistical’ indicator is automatically defaulted anytime they create an internal order using that order type. This is a reasonable request as you may not always remember to set this indicator when creating the order. The way to do this is to go to the following configuration menu path (SPRO):
Controlling -> Internal Orders -> Order Master Data -> Define Order Types

You can then double-click on the relevant order type to go to its settings. Then click on the ‘Field Selection’ button (which looks like a pencil) and scroll down to the second page of the ‘Change Field Selection’ screen until you get to the line that reads “Identifier for statistical order”. You can then click on the “Req. entry” radio button and check the “HiLi” checkbox (which stands for Field is highlighted). Then save your settings.

When next you create an internal order with that order type, you will find that the 'statistical' flag is automatically selected in the ‘Control’ tab for that order.

Paul Ovigele, Ovigele Consulting

In my previous blog, I described one of the steps needed to perform real-time integration between the Enterprise Controlling Consolidation (EC-CS) module and the general ledger. This step involved creating a consolidation unit directly from a company in a consolidation group hierarchy.

The next step would be to copy the general ledger accounts in the chart of accounts into FS Items in the EC-CS module. FS Items should be equivalent to general ledger accounts on a one-to-one basis. To create FS Items on an individual basis, you can go to transaction CX14 and enter the necessary data. However, if you want to create the FS Items automatically from the existing G/L accounts, you would need to go to transaction CXN1 and in the ‘Copy from’ section, enter the chart of accounts whose G/L accounts you want to copy; then in the ‘to’ section, enter the consolidation chart of accounts and a description and then click on the ‘Execute’ button. The FS Items are then created with the same number as your general ledger accounts. I would recommend setting this program (FICICA00) as a job which runs (at least) every night so that any new general ledger accounts that are created are copied over as FS Items.

You would also need to assign the transaction chart of accounts to the consolidation chart of accounts. To do that, you should go to the following configuration menu path (transaction SPRO):

Enterprise Controlling -> Consolidation -> Integration: Preparation for Consolidation -> Preparation in the Consolidation System -> Collection of Data -> Assign Transaction Charts of Accounts to Cons Chart of Accounts

You can then hit the ‘New Entries’ button and enter the general ledger chart of accounts in the ‘Chart/accts’ column, and the consolidation chart of accounts in the ‘Cons chart’ column.

If you want your FS Item hierarchy (which is the structure of FS Items in the EC-CS module) to be equivalent to your general ledger’s financial statement version, then you would need to go to transaction CX16. You then need to go to the top-menu path: Cons chart of accounts hierarchy -> Transfer autom. -> Financial Statement Version. Then enter your item hierarchy name and description in the ‘Information about item hierarchy’ section, and enter the financial statement version that you want to copy from in the ‘Information about fin. stmt version’ section. You can then hit the ‘Execute’ button in order for the structure to be copied over accordingly.

A final important step needed to perform real-time integration between the general ledger and EC-CS module is to run the transaction to ‘Integrate Group Data’. To do this, go to transaction OCCI and enter the consolidation group name and fiscal year variant. You can then check the box ‘SAP Cons’ and click on the ‘Detail EC-CS’ button. In the ‘Integrated consolidation types / data transfer methods’ section, check the box ‘Company consolidation’ and select the option ‘Realtime update’. You can then go back to the original screen and save your changes.

Paul Ovigele, Ovigele Consulting

If you plan to consolidate your financial reports within the SAP ERP system, the only option that you have is to use the Enterprise Controlling Consolidation System (EC-CS) module. The other two options for consolidation Strategic Enterprise Management Business Consolidation System (SEM-BCS) and Business Objects Planning and Consolidation (SAP BPC) exist in separate environments, where the data from the ERP system needs to be extracted into.

While the EC-CS module does not contain some of the robust analytical features of its counterparts, it does have the advantage of being updated in real-time, particularly if you are using the “Realtime update from FI” data transfer method. As the name indicates, this means that one a document is posted in financial accounting; it is immediately updated in the EC-CS. I will set out a few of the key steps (over two blogs) to be taken to ensure that this real-time update occurs seamlessly between both modules.

Firstly you would need to copy a consolidation unit from a company. Now, a consolidation unit is a key organizational unit in the EC-CS system which represents the smallest element of a group structure for which a full consolidation can take place. It is usually the reflection of the company code in the financial accounting module. There are two main ways to create a consolidation unit:

The first way is by creating it directly, which involves going to the following configuration menu path (transaction SPRO): Enterprise Controlling -> Consolidation -> Master Data -> Organization Units -> Consolidation Units -> Maintain Consolidation Units Individually. You can then double-click on “Create Consolidation Unit”, enter a name for the consolidation unit and fill out the relevant fields such as country, language, address, data collection method, and so on.

The second way to create consolidation units is by copying it from a company (a "Company" is an organizational unit that represents a business organization according to the laws of a country. It is not to be confused with a “Company Code”). Before you do this you need to have created the company using transaction OX15, and assigned the company to the relevant company code (usually on a one-to-one basis) using transaction OX16. You would then need to go to the following configuration menu path: Enterprise Controlling -> Consolidation -> Master Data -> Organization Units -> Consolidation Groups -> Maintain Hierarchies.

Note that a consolidation group hierarchy is simply a structure that groups consolidation units (or companies) into logical reporting structures. You can then double-click on “Maintain Consolidation Group Hierarchy” and in the subsequent screen you can click on the consolidation hierarchy group where you want to insert your consolidation unit. Each consolidation unit needs to belong to a consolidation group. You can create the consolidation group by simply clicking on the “Create” button and entering a name and description of the group. You then select the group and click on the button “Companies” and in the pop-up box enter the company which is linked to the company code that you want the consolidation group to represent. You can then hit the ‘Execute’ button and save your entries, and you will see that the company (and its details) will now be inserted into your consolidation group hierarchy.

Paul Ovigele, Ovigele Consulting

A few of the areas that you can expect to see reconciliation differences between the Financial Accounting (FI) module and the Controlling Profitability Analysis (CO-PA) module are as follows:

- Rebate Accounts: This is a very tricky one because it is not easily noticed. Rebates are usually posted in CO-PA as negative values (as they derive from negative conditions). However, in the P&L account that is posted to for rebates (which is linked to the condition type account key in transaction VKOA), it is a positive value. Therefore there could potentially be a mismatch between the postings in CO-PA and FI due to the different signs.

- Cost of Sales Account: In costing-based CO-PA, the cost of sales value field is updated when the billing document is posted (at the same time that revenue is posted), while the cost of sales account in the FI module is posted when the ‘Post Goods Issue’ (PGI) transaction is made. This means that if a PGI is done in one month and the billing document is made in a subsequent period, there will be a time-lag between the update of cost of sales in the general ledger and in CO-PA.

- Cost Element Categories: If the cost element that is linked to a condition type’s account key does not have the cost element category of 11 or 12, then the relevant CO-PA value field will not get updated. In most cases, when a value field is not mapped to a sales condition, the billing document will not get passed to accounting, hence the condition will need to be mapped in order to correct the issue. However, if the condition is mapped to a value field, but the cost element linked to that condition’s account key uses a different cost element category (other than 11 or 12) then you will not get a billing document error message. This is because a CO-PA document will be created (but the relevant value field will not be posted to). This therefore means that it will be more difficult to detect these issues since the system will not alert you to the fact that the CO-PA value field has not been updated.

Production Variance Account: This is the account that is posted to when a manufacturing order which is delivered or technically complete, is settled (transaction CO88). This variance account is configured under transaction OBYC, in transaction key PRD and account modification PRF (if you are not using an account modification, then it is simply the account configured under transaction key PRD, but for a manufactured product, such as one with a semi-finished or finished product’s valuation class). This account should not be set up as a cost element, as the variance is normally posted to CO-PA by mapping variance categories to the PA transfer structure (transaction KEI1). If you set up the variance account as a cost element then there will be a double-posting in CO-PA.

You can use transaction KEAT to perform a reconciliation between FI and CO-PA. This report shows (for each billing document) the differences between FI, SD and CO-PA for sales conditions such as revenue, cost of sales, rebates, commissions, etc. It helps detect any errors in configuration that cause discrepancies between the modules. Another good way of performing a reconciliation (if data volumes allow) is to drilldown into a value field line of a CO-PA report and compare it to the items in the corresponding general ledger account.

Paul Ovigele, Ovigele Consulting

One of the biggest issues that accountants have with the Controlling Profitability Analysis (CO-PA) module, is that is not easy to reconcile it with the Financial Accounting (FI) module. Some users have said that they were told that CO-PA was not meant to reconcile with FI, and should be accepted it as an analysis tool for evaluating the contribution margin for the various market segments of the organization. However, in order for accountants to validate the figures reported by CO-PA, they need to ensure that they are reconciled with accounts in the general ledger.

There is the option of using account-based profitability analysis. The idea is that you can create CO-PA reports using cost elements as opposed to value fields. However, I do not find this option to be particularly advantageous because it simply shows the information according to profit and loss accounts, which is the same thing that an income statement will do. Therefore, any of the reconciliation issues that occur between CO-PA and the general ledger will also occur between costing-based CO-PA (which is the version of CO-PA that this blog is based on) and account-based CO-PA.

In order to address the reconciliation issues, we need to identify the different ways that actual data flows into CO-PA. They are as follows:

- Conditions from Sales Document: Sales order conditions (such as revenue, discounts, commissions, etc) are mapped to CO-PA value fields. These conditions are also mapped to account keys which are linked to G/L accounts. You can therefore look at the accounts that are linked to these account keys and tie them back to the value fields that the conditions are assigned to.

- PA transfer structures: General Ledger accounts can be assigned directly to value fields by using PA transfer structures. These G/L accounts are normally either posted directly to, during a financial posting or posted to automatically during an inventory-related posting. Also, variance categories from Cost Object Controlling are mapped to value fields to reflect the production variances that arise when a manufacturing order is settled. The total of the variance categories should be equal to the general ledger account that is posted to for the production variances (this is the account that is configured in transaction OBYC, under transaction key PRD and general modification PRF).

- Assessments: These are created to map the postings to a cost center (for all or specific cost elements in that cost center) to value fields in CO-PA. Assessments to CO-PA are normally used for costs that do not pass through the Sales and Distribution module, such as Research and Development costs, General and Administration Costs and indirect selling expenses.

- Manual Posting: By using transaction KE21N you can directly post to a CO-PA value field. This only updates CO-PA and not the general ledger. It is normally used when there are adjustments that need to be made to CO-PA only, either for legacy balances or in cases where there are errors which can no longer be corrected in the source data.

As you can see from the above methods, most value field assignments are either directly or indirectly linked to a general ledger account (cost element). Therefore, in most cases you should be able to identify groups of cost elements that should be reconciled with their corresponding value fields.

In my next blog I will highlight a few areas where you can expect differences to occur between CO-PA and FI. This will allow you to easily pinpoint the value fields which will need to be investigated when reconciliation issue occur.

Paul Ovigele, Ovigele Consulting

During my session “Accelerate local and global financial closes and period-end reports with improved integration between profit center accounting and the general ledger” in the Reporting & Analytics conference, a question came up about the purpose of business transaction variants in document splitting. To explain how business transaction variants work, you will first need to understand how business transactions are used.

Business transactions in the SAP General Ledger are specific events that lead to the update of values in financial accounting. You can think of them as classifications of accounting postings such as vendor invoices, vendor payments, bank clearing, etc. They also help you to define the logic for document splitting. For example, if the business transaction is a vendor invoice, the system has a predefined logic for how the vendor line on the invoice should inherit its account assignment from the offsetting line(s) on the invoice. A typical example is where the vendor line inherits the profit center from the material (the inventory account that is assigned to the valuation class of the material) that is purchased during an invoice posting. The document type for vendor invoice postings (normally KR or RE) are linked to business transactions and business transaction variants in the following configuration menu path (SPRO):

Financial Accounting (New) -> General Ledger Accounting (New) -> Business Transactions -> Document Splitting -> Classify Document Types for Document Splitting

Here you will see that (for example) document type KR (Vendor Invoice) is assigned to business transaction 0300 (Vendor Invoice) and business transaction variant 0001 (Standard). Business transactions are predefined by SAP and are not modifiable; therefore if you wanted to use a different document splitting logic for document type KR you cannot create a new business transaction to meet this requirement. Instead you should create a new business transaction variant and change the settings accordingly. To do this you need to go to configuration menu path (SPRO):

Financial Accounting (New) -> General Ledger Accounting (New) -> Business Transactions -> Document Splitting -> Extended Document Splitting -> Define Business Transaction Variants

Here you can click on the relevant business transaction (for example, 0300) and double-click on the folder “Accounting transaction variant”. Then you can click on the ‘New Entries’ button and enter a new variant and description. You can then highlight the new variant and double-click on the folder “Assigned item categories” and you will see all the item categories that are assigned to that business transaction. You can delete the item categories as required by clicking on the ‘Delete’ button, or add new ones by clicking on the ‘New Entries’ button and save your settings. This new business transaction variant will then need to be added to the relevant document type by going to the menu path for classifying document types for document splitting (mentioned above).

If you want the document type to use a different item category as a basis for document splitting, then you can create a new splitting rule and assign your new business transaction variant to it. To do this you need to go to configuration menu path (SPRO):

Financial Accounting (New) -> General Ledger Accounting (New) -> Business Transactions -> Document Splitting -> Extended Document Splitting -> Define Document Splitting rule

The easiest way to define the new splitting rule would be to copy an existing one (for example, highlight splitting method/business transaction/variant: 0000000012/0300/0001 and click on the ‘Copy’ icon) and enter the new splitting method and assign your business transaction variant accordingly. You can then select the item categories to be edited and the base item categories that will meet your specific business requirement.

Paul Ovigele, Ovigele Consulting

SAP Queries can be accessed directly by going to transaction SQ01 and executing the relevant query. Some companies, however, do not like to give users access to this transaction as it could lead to users running a query which has a long runtime and could potentially cripple the system. An alternative therefore is to assign the query to a transaction code which you can then assign to the relevant users.

To assign a query to a transaction code to need to go to transaction SE93, enter the transaction code and click on the ‘Create’ button. Then enter a short text for the transaction code and click on the button “Transaction with Parameters (parameters transaction)”. When you hit the ‘Enter’ key, this will take you to the “Create Parameter Transaction” screen. In the ‘Default values for’ section, enter the value “START_REPORT” in the ‘Transaction’ field and check the box ‘Skip initial screen’. In the ‘GUI Support’ screen, check the boxes ‘SAPGUI for HTML’, SAPGUI for JAVA’ and ‘SAPGUI for windows’.

In the ‘Default values’ section at the bottom of the screen, enter the following values in the ‘Name of Screen Field’ and ‘Value’ columns:

D_SREPOVARI-REPORTTYPE: Enter the value “AQ” which is the code for SAP Query;

D_SREPOVARI-REPORT: Enter the user group that the query was created in. The infoset that the query is created from is assign to (at least one) user group and every query is created according to a user group.

D_SREPOVARI-EXTDREPORT: Enter the name of the query that you want the transaction code to be derived from.

D_SREPOVARI-VARIANT: If you have created a selection screen variant for your query then you can enter it here. This way the variant is automatically defaulted anytime you go to that transaction.

D_SREPOVARI-NOSELSCRN: If you want to skip the selection screen, enter an “X” in the value column. Otherwise you can leave it blank.

There are two types of queries – standard queries and global queries. If you are using standard queries, then you need to manually trigger a transport request. In this case you would assign the user group to the screen field D_SREPOVARI-REPORT as explained above. If you are using global queries (which are available in all clients in the instance), the system automatically triggers a transport request. In this case you would need to add a suffix of “G” to your user group when assigning it to the screen field D_SREPOVARI-REPORT. Note that when you do this, the “G” character needs to be in the thirteenth position of the field. For example, if you have a user group named ZFIUSER, you would need to leave five spaces before assigning the G character. The field value would therefore be “ZFIUSER G”.

One advantage of using global queries is that you can take advantage of queries that have been set up by SAP (such as vendor, customer and general ledger evaluations) and simply assign them (as described in the above steps) to transaction codes so that they are available to the relevant users.

Paul Ovigele, Ovigele Consulting

A question that I get asked a lot is “How can we get to default certain fields in the vendor or customer master?” The answer I normally give is for the users to create the vendor or customer master with reference to a similar vendor or customer and hence any default values or checkboxes will automatically be carried over. This answer is normally sufficient however, not all companies are in favor of copying existing master data to create new ones. One reason for this is that although you get the benefit of inheriting default values, you could run the risk of adopting certain features from the referenced master data that do not apply to the new master data. There should therefore be the option of creating vendor and customer master data from scratch but choosing which fields should be defaulted and what values or indicators should exist in them.

In this example, I will demonstrate how to default the “check double invoice” checkbox in the vendor master, since I am frequently asked how this setting can be made automatically.

A simple way to do this is by using the Transaction and Screen Variant functionality. You can access this functionality by going to Transaction SHD0, and enter the relevant transaction code (here, I will enter transaction FK01 for creating a vendor master record) and a transaction variant (which can simply be a “Z” and then the transaction code, e.g. ZFK01).

You then click on the Create button which will take you to the initial screen for creating the vendor. You do not have to go through all the fields to create a new vendor, only enter what is necessary in order for you to get to the screen that you want. Hit ‘Enter’ and the “Confirm Screen Entries” pop-up box will appear.

Now, if the screen that appears does not contain the field that you want to default, then take the flag off the “Copy Settings” checkbox and hit the ‘Enter’ button. You will then get to the “Create Vendor: Address” screen. Enter very minimal data to get through this screen.

When you hit the ‘Enter’ button, the “Confirm Screen Entries” pop-up screen will appear again. As mentioned above, keep taking the flag off the “Copy Settings” checkbox and hitting the ‘Enter’ button. Depending on your field status settings, some screens may require that you fill in a field before you can move forward. If that is the case, simply put a valid value in the required fields and hit the ‘Enter’ button. Keep doing this until you get to the screen that contains the field you want to default (which, in our example is the "Payment Transactions Accounting" screen). When you get to this screen, check the “Chk double Inv.” box.

You then hit the ‘Enter’ button to get the “Confirm Screen Entries” pop-up screen. This time do not take the flag off the “Copy Settings” checkbox. Instead, scroll down the screen until you get to the “Chk double Inv.” line. You then check the “W. Content” checkboxbox for that line.

Then hit the "Exit and Save" button, and hit the "Save" button . You will be asked to assign a development package to your transport – this can be provided by your Basis team.

When you hit the Back button to go back to the “Transaction and Screen Variants” screen, go to the “Standard Variants” tab and enter the transaction variant in the 'Name' field.

You can then activate the Transaction variant by clicking on the Activate button .

The next time you create a vendor using transaction FK01, the “Chk. Double inv.” box will be automatically flagged .

For more infrormation on using transaction and screen variants, and other ideas 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:

www.sap-press.com/products/100-Things-Yo...

Paul Ovigele, Ovigele Consulting

A very neat way of maintaining G/L account master data is by using the “Hierarchy Display” functionality. This enables you to see all the existing accounts and easily decide which new number to insert or which similar account can be copied. This view has the feel of one of SAP’s “Enjoy” transactions, because you can perform multiple functions using a single screen.

You can get to the hierarchy display view by going to the normal G/L account master data screen (transaction FS00) and by selecting the option ‘Settings -> Hierarchy Display’. You will then get a dialog box asking whether you want to display the accounts in a navigation tree or not. When you choose the option to display in a navigation tree, the system will give the message “The new settings will take effect once the transaction is restarted”. You can then either exit the current transaction or restart it, or simply type transaction “/nFS00” in the command field.

The left part of the screen contains the account groups. These are created in transaction OBD4 and they control the number range intervals of the accounts per chart of account, and also the field statuses (suppressed, optional, required or displayed) of the fields that are available in the account master record. These accounts groups are shown in folders and you can expand them to view the general ledger accounts that exist in those groups. This hierarchical view is similar to other master data maintenance views in SAP such as the cost center hierarchy (which can be accessed from transaction OKENN) and the consolidation financial statement hierarchy (which can be accessed from transaction CX16). The key difference here is that, unlike those hierarchies, you cannot drag and drop a general ledger account from one account group to the other like you can with a cost center to another cost center group, or an FS item to another hierarchy area. This is because the account group is a very fundamental setting which cannot be changed when a general ledger account is created. If you want to create a new account in a particular range you can easily see what the next available number is. You can then select the account that you want to copy from, click on the ‘copy’ icon and then enter the account number that you want to create.

Changing the description and other settings can be done on the right part of the screen as you would in the normal account maintenance scenario. By using the ‘Find’ icon, you can search for a number or description of an account in a company code. This could be useful if you are creating an account which may already exist as a different number. By putting all or part of the description in the search field, you will find out if there is a similar account in the same or a different account range. The ‘Block’ and ‘Mark for Deletion’ icons are available as with the normal maintenance view, but it is easier to scan through several accounts with the hierarchical view and check or maintain the block and deletion settings. Lastly, you can easily change the view from one company code to another by clicking on the ‘Change Company Code’ icon.

For more infrormation on the hierarchical G/L Account maintenance, and other ideas 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:

www.sap-press.com/products/100-Things-Yo...

Also, please find the below information about my live Q&A forum:

Technical tips and tricks to get more out of your SAP Financials transactions:
A Q&A with SAP PRESS author Paul Ovigele

Seeking quicker, easier ways to perform SAP Financials transactions, post accounts, display your reports, and monitor your G/L accounts? Ask Paul Ovigele your questions in a live moderated forum on Thursday, July 28, from 12:30-1:30 pm EDT in the Insider Learning Network’s Financials Forum.

Paul Ovigele, Ovigele Consulting

Ever wondered how you can easily find out where G/L accounts are assigned in the system? The assignment of accounts is made in several tables depending on which module the table represents, so there has never been an easy way to find out where an account has been assigned without going into several configuration transactions. In the past, this was a laborious process which involved downloading certain tables (if you had the access!) into Microsoft excel and performing various manipulations of the data (vlookup, pivot tables, etc) to get the information that you need.

That is up until release ECC 5.0, where SAP has delivered the ‘Account Detective’ report. This report lists all the accounts in a company code or chart of accounts along with their master data settings, and gives you the option of finding out where they have been assigned.

To access the ‘Account Detective’ go to transaction S_ALR_87101048. If you want to analyze the accounts in just one company code, then enter the company code and check the box “Only Accounts in the Company Code”.

Then enter the relevant controlling area and chart of accounts. You can only enter one chart of accounts because most account determination tables are populated on a chart of accounts basis. You can then either enter one or several accounts that you want to analyze. The modules that are available for account determination analysis are explained as below:

Module	Explanation	Examples
FI Account Assignment	Assignment of accounts to Financial tables	Bank Main and clearing Accounts Down Payment reconciliation accounts Tax Accounts
MM/HR Account Assignment	Assignment of accounts to materials management, inventory management and human resources tables	Inventory Accounts Consumption Accounts Travel Expense Accounts
Cost Element Categories	Categories that are linked to the primary cost elements of the accounts. Also, indicator for automatic assignment of cost element to a cost object	Primary Costs (01), Revenue (11), Sales deduction (12) Default Account assignment entries
AA Account Assignment	Assignment of accounts to Fixed Asset tables	Acquisition and Production (APC) Accounts Depreciation Accounts Gain/Loss from asset sale accounts
SD/EK Account Assignment	Assignment of Accounts to Sales and Distribution tables	Revenue accounts Rebate Accounts Freight Accounts

If you do not select any of the options in the ‘Account Determination Analysis’ checkbox, you will get a list of the accounts that you selected and their respective settings in the general ledger master record. This list is useful if all you want to do is analyze (say) the number of accounts that are open item managed, available for line item display, or automatically posted to. If you select any of the ‘Account Determination Analysis’ checkboxes, you will get the list of master data settings as the header line, and in the tables where the accounts have been assigned in the item lines.

If you click once on the table name (and have the appropriate authorization) you will be taken to the ‘Data Browser’ transaction (SE16) where, if you want, you can display the items that exist in the table. If you double-click on the account line you will be taken to another screen that shows all the attributes of the general ledger master, such as the account group, tax category, field status group, etc.

For more infrormation on the Account Detective, and other ideas 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:

www.sap-press.com/products/100-Things-Yo...

Also, please find the below information about my live Q&A forum:

Technical tips and tricks to get more out of your SAP Financials transactions:
A Q&A with SAP PRESS author Paul Ovigele

A link directly to the Forum is here: www.insiderlearningnetwork.com/go/thread...

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.

Paul Ovigele, Ovigele Consulting

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.

Secondary Cost Element Reporting in SAP General Ledger PCA

Posting Travel Expenses Automatically to Financial Accounting

Passive document splitting in the SAP General Ledger

Making Partial Payments using the Automatic Payment Program

Integrating Secondary Cost Element Planning in SAP General Ledger

Excluding Specific Cost Centers from Cost Center Reports

Using WBS Element as a Document Splitting Characteristic

Using Drilldown Reports with the SAP General Ledger

Setting up Statistical Orders for Project Monitoring

Setting up Real-time Integration of EC-CS and the General Ledger (Part 2)

Setting up Real-time Integration of EC-CS and the General Ledger (Part 1)

Reconciling CO-PA with Financial Accounting (Part 2)

Reconciling CO-PA with Financial Accounting (Part 1)

Defining Business Transaction Variants in the SAP General Ledger

Assigning SAP Queries to Transaction Codes

Setting Up Default Field Values for the Vendor and Customer Master

Effortless master data maintenance of your SAP G/L Accounts

Analyzing the Automatic Account Assignment of your SAP General Ledger Accounts

Using Translation Keys in Drilldown Reports (Part 2)

Using Translation Keys in Drilldown Reports