QSandS Publications Samples

• Quality Services & SAP Expertise • Enabling Business & Technology solutions • Enhanced Efficiency & Improved Effectiveness • Lower Costs & Higher Profitability

Our SAP Publications

4264 Nerissa Circle, Fremont, CA 94555T: (408) 242-7588 E: [email protected]

Quality Systems & Software (QSandS.com)

QS&S Publications

Dear colleague, Quality Systems & Software (QS&S) is widely acknowledged in the industry as leading SAP Experts, with over 50 publications, 40 presentations and more (2nd only to SAP) • Publications

o Over 50 articles & white papers. o Guidebook “How to achieve IAS-14 Segment Reporting in New G/L”

• Technical Advisory Board Principals serve as strategic, technical advisors and resident editors • Conferences Invited to speak at more than 40 reputed SAP events and conferences

I am enclosing some of our white papers for your reference. These represent some of the common business challenges you wrestle everyday. We can help you overcome many of the business challenges on your toughest SAP projects. Respectfully,

Mitresh Kundalia Director – SAP Practice, Quality Systems & Software, [email protected]


QS&S Publications

Table of Contents Abstracts of Publications 3 Achieve Balanced Reporting by Automating Document Splitting in the New G/L

17

Plan and Monitor Your Sales Campaigns in the CO-PA Ledger 24 10 Best Practices for Designing Summarization Levels 31 Extract Pricing Conditions from the R/3 Module into BW 36 Copy Control Gives You Flexibility to Manage Your SD Document Flow 39 What’s an “Assignment Number,” and How a Misunderstanding Can Give your End Users an Unfriendly Surprise

46

Fast Data Conversion, Migration, and Updates for Functional Analysts with LSMW

50

Find the Hidden Condition Technique in CO-PA and Fine-Tune Your Profitability Analysis

55

What You Should Know About the SD Higher-Level Item Category’s Influence on Financial Reports

61

Ensure That SD Billing Document Invoices Are Posted in FI 66 Avoid These 11 Common Unit-of-Measure Errors 72 What Every FI/CO User Should Know About This Error Message 82 Are Your Stock Balances Correct? 87 Currency Types: The Key to Reporting Parallel Valuations 92 Account for Time Zone Differences So That They Do Not Affect Your Global Close

99

Avoid a Disconnect Between Your MM and FI Period Closes 103 What Happens to Materials in Prior Periods? 107


QS&S Publications

Our Presentations and White Papers We are invited to speak at various SAP events. We are regular speakers at the premier industry events such as America’s SAP User Group (ASUG), Global SAP Environments conferences, SAP Financials conferences, Supply Chain conferences, Managing SAP Projects, Customer Relationship Management (CRM), SAP Netweaver BI, Administration & Infrastructure, Reporting and Analytics, HR conferences and more. Also, we have published more than 50 consulting white papers which cover many of business challenges you wrestle everyday. Here is the partial list of our presentations and the abstracts of some of our white papers. If you want to discuss business cases involving these presentations or white papers or specific to your industry, please write to Mitresh Kundalia, Director – SAP Practice. He can be reached by E-mail at [email protected]. New G/L Guidebook "Achieve IAS-14 Segment Reporting by Automating Document Splitting in the New G/L" New GL offers many new features including Document splitting to meet ‘IAS-14 Segment Reporting’ Requirements. With document splitting, the system splits accounting line items according to specific characteristics. This enables you to create financial statements for entities such as Segments. In this comprehensive guidebook on the document splitting, the author describes in detail on how to activate the document splitting automatically to create Segment reporting real-time. The book describes the background details on IFRS-8 requirements, the document splitting concept in the New G/L and step-by-step instructions to configure the New G/L to achieve balanced reporting. Presentations

• How to achieve balanced reporting with automated document splitting in the New G/L

• Dos and don’ts for configuring the New G/L

• Hidden Secrets to fine-tune CO-PA Ledger

3


QS&S Publications

• CO-PA 101 – Demystify SAP profitability analysis

• Derive greater value from CO-PA by taking advantage of frequently overlooked functionality

• Say Goodbye to Sluggish CO-PA Reporting

• CO-PA Implementation Best Practices

• Best Practices for designing CO-PA Summarization Levels

• 5 techniques to speed performance of profitability analyses and other CO-PA reports

• Perform flexible customer profitability analysis leveraging CRM, BW, and CO-PA

• Unearth Hidden Secrets of Pricing Procedure to address complex Order-To-Cash processes

• Leverage the power of VOFM routines to enhance the versatility of your Order-To-Cash processes

• Enrich your SD pricing procedures with statistical conditions

• Tap into Sales Information System (SIS) for more effective sales reports and deeper knowledge of your customers

• The 10 not-widely-known tools and techniques that every SAP project manager should know about

• The top 5 “must have” SAP data management tools

• Indispensable Tips and Tricks for harnessing the capabilities of CATT and eCATT

• Cutting Edge Pointers for converting SAP data with the Legacy system Migration Workbench (LSMW)

• Navigate Your SAP Financial Ledger Options and Choose the Best Ledger for the Task at Hand

• Conquer the Complexities of Global Operations

• Tips and Tricks for Mastering Currency Types

4


QS&S Publications

• Keys to a Hassle-Free Material Ledger Conversion

• What Every Finance Team Now Needs to Know About FI and MM Integration

• Do’s and Don’ts for Smoothly Integrating SD and FI

• 30 Training and Empowerment Tips for Users Who Rely on SAP Financial Applications

• The 4 FI-AR Tips and Tricks You Need to Know

• FI-GL Configuration Tips and Tricks

• Tips and Tricks for Dealing with Units of Measure (UoMs)

• Preventing, Correcting, and Assigning Blame for Inconsistencies and Errors in Stock-Related Postings

• Conquer the Complexity of a Global Rollout

• Integrate FI and MM the Right Way

• Advanced Tips and Tricks for SD and FI Integration and Reconciliation

• How to Prepare for the Legal, Business, and Cultural Complexities of a Global SAP Rollout

• Technical Features and Functions to Facilitate Your Global SAP Rollout

• Tips and Tricks for Getting the Most Out of SAPNet

White Papers New G/L "Achieve Balanced Reporting by Automating Document Splitting in the New G/L" New GL offers many new features including Document splitting to meet ‘IAS-14 Segment Reporting’ Requirements. With document splitting, the system splits accounting line items according to specific characteristics. This enables you to create financial statements for entities such as Segments. In this article, the author describes in detail on how to activate the document splitting automatically. The splitting method is the main key to activate document splitting in the new G/L,

5


QS&S Publications

including splitting rules, business transactions, business transaction variants, and more. "Unearth the Hidden Secrets of Zero-Balancing in the New G/L" International financials regulations may require you to zero-balance the financial transactions by certain characteristics – such as, profit center, segment and more. In this article, the author describes how to set-up the zero-balancing characteristics. Also, learn the un-documented feature of how system creates varying number of zero-balancing line items. "Use Document Simulation in the New G/L to see how the system posts G/L Documents" In this article the author describes how to leverage much improved functionality of Document Simulation in the New G/L. The classic G/L offers a feature called document simulation that helps you determine how the system automatically generates accounting entries, troubleshoot and fix missing configuration settings, and identify and rectify any mistakes made before posting the accounting transaction. This feature has improved in the new G/L and adds particular benefit to document splitting. Using document splitting, you can balance the document for predefined characteristics at run-time rather than waiting until period-close. “Do’s and don’ts for configuring the new G/L” In this article, the author explains the New G/L implementation considerations to reduce risk, including master and organizational data management, transactional data integrity, and financial reporting compliance. How to prepare for New G/L implementation challenges. Find out how to ensure data and process integrity by avoiding too many parallel ledger setup. Weigh the impact of data volume by activating document splitting functionality and find out why you to be careful when updating profit centers with segments. Learn about the best practices and configuration tips of utilizing simulation, inheritance, setting zero balance constants and more. “New G/L replaces many traditional ledgers – Not the CO-PA Ledger” Introduced in SAP ERP Central Component (ECC) 5.0, the new General Ledger (new G/L) is a single ledger to meet many reporting requirements. It provides many functions of the traditional ledgers, meaning that you no longer need the traditional ledgers. However, be careful – you will still need the CO-PA Ledger for meeting the margin analysis reporting by business segments.

6


QS&S Publications

“Learn about Segments Assignments and Segment derivation in the New G/L” International Accounting Standards (IAS) 14 relates to segment-level financials reporting. The key objective is to report financial information by lines of business and/or by geographical areas. In other words, you require preparing balanced financials statements at an entity below company code-level. That is the requirement to meet with segment reporting. In this article, the author explains how segments help define balanced segment reporting for a company. In addition, the author also explains how the segments are defined in the New G/L, how these are assigned and derived. GRC "Build Bullet-proof testing strategies to comply with challenging compliance" Organizations need to design and develop effective testing strategies to comply with Sarbanes-Oxley and industry-specific requirements. These testing strategies and methodologies need to cover both normal day-to-day maintenance of business scenarios and major initiatives such as upgrades, fresh implementations, and more. See how to build and follow a five-phase plan to perform testing on your system and ensure compliance. "How Can Enhancement Packages Help Compliance?" In this article, the author describes the new ways that SAP distributes updates to your system, and how you can use them to cut down on testing and resource use Consulting Notes "How to avoid inconsistency when you post to COGS account during a billing process" Creating an Invoice is the most fundamental and basic ‘Revenue Recognition’ process. Usually, the invoice posts to Revenue (or Discount accounts) during the billing. Did you know that in some industries, you might want to post to Cost of Goods Sold (COGS) account, instead of Revenue account? Typically, this is required when the business purpose of the process is ‘Costs Reduction’ and not ‘Revenue Recognition’. You may think that simply swapping the Revenue account to COGS account may solve your issue. However, be ready for a rude shock. In this article, the author explains behind-the-scenes mechanics on how the financial inconsistency is created and offers you a solution on how to avoid this inconsistency.

7


QS&S Publications

“VOFM Routines Help Make Logistics Processes More Versatile” In the world of logistics, it is so common to see many different and sometimes contradicting business processes requirements. For example, selling a particular product at a regular list price, but, under a specific situation, give it free-of-charge. What makes SAP system so powerful is that you can make it is flexible to adapt to such diverse business requirements. VOFM is one such tool-set which is extensively used, especially in logistics processes. VOFM functions are small but nifty tools, available in your arsenal to add flexibility to the business processes. "Omnipotent Condition Technique" Condition Technique is one of the most powerful tools available in SAP. It is extensively utilized within various SAP functions. What makes it so powerful is its flexibility to meet your specific business requirements from basic additions to more complex calculations. Especially within Sales and Distribution (SD) module, condition technique has been utilized extensively, within various processes - pricing calculations, output control, account determination, material determination, free goods determination and more. In this article, the author explains the mechanics of how Condition Technique works and with an example from Pricing function, demonstrates various features available so that it can be used for various scenarios. “Cost Conditions in R/3 - Are You Sending Your Financials Team an Unpleasant Surprise?” Almost everyone in SAP community is aware of condition type VPRS, that basically it determines the cost of the material – either standard or moving average, depending upon the valuation of the product. However, very few are aware that something called as ‘future price’ of the product also has noteworthy influence on how the VPRS cost is determined. Not only that, if not understood correctly it can have negative impact and can cause the differences in your Financials. "Signs in CO-PA" Revenues are stored as negatives in Financials. However, the same revenue postings are assigned as positive in SD module. Since, data can be posted from both modules to CO-PA, it handles signs a bit differently. If not handled properly, it can cause wrong results in CO-PA. In this paper, the author explains the logic for handling signs and how to avoid incorrect results. “What Is so Special about Statistical Conditions in SD?” Needless to mention that pricing procedure is one of the most powerful

8


QS&S Publications

configurations in Sales and Distribution (SD) module, which is used to calculate the price of the item being sold. In spite of general awareness among the business community about the strength of the pricing procedure, many are not aware of the hidden strengths of the components of the pricing procedure. In this article, the author highlights the hidden features of the Statistical conditions and alternative ways of calculating the condition values. "Find The Hidden Condition Technique in CO-PA and Fine-tune CO-PA Ledger" Have you ever wished that CO-PA module had a Condition Technique? Guess what? It does, but in CO-PA it is termed as 'valuation with Costing sheet'. In this paper, the author unearths the hidden Condition Technique in CO-PA and clarifies some of the terminologies, which have caused it to be underutilized. "Help Profit Analysts Find Causes and Effect Relationship with 3 CO-PA data Fine-tuning Options" In this paper, the author explains some of the 'secret' data-tuning techniques, which help you get maximum out of CO-PA module. One of the most important SD Configurations - 'Pricing Procedure', plays a very important role for CO-PA. Author explains how one can fine-tune CO-PA ledger with the help of 'Statistical Conditions', 'Alternative Calculation Type' and 'Sub Totals'. "What is an Assignment Number and How a Misunderstanding can give an unfriendly surprise" Often SAP uses the same term quite differently in different modules. One such term is 'allocation'. In CO module, allocation is a term used to transferring costs from one cost center to another. In FI, allocation number is an additional reference field for FI account line item. Realizing the potential confusion, SAP now calls it 'assignment number' in FI. However, whether it is 'assignment number' or 'allocation number', its usage has remained confusing. In this article, author clarifies some of the potential confusion created by it usage in Customer or Vendor accounts and the corresponding G/L reconciliation account. "10 Consulting Notes all CO-PA consultants should keep handy" If a business user has a problem, they call consultants. But, what if the CO-PA consultants need some help? In this article, the author has listed 10 most common business issues in CO-PA module and the OSS consulting notes to resolve these challenges.

9


QS&S Publications

“Material Master History Tables: What Happens to Materials in Prior Periods?” SAP R/3 4.5A stores previous period data for materials in new history tables. Learn how this change improves the MM period closing process and allows you the unprecedented opportunity to view historic material master data. Starting with SAP R/3 Release 4.5A, SAP added functionality to save monthly history of the key material master tables. These material master history tables can be a useful source of information and can form the basis of custom reports to meet specific user requirements. Many SAP standard reports, such as RM07MMFI and FB5L, use these new history tables. “Avoid a Disconnect Between Your MM and FI Period Closes” Your cutoff for transactions at close may be affected if you don't understand the relationship between the Materials Management (MM) period close and the FI period close. In this article, the author explains the configuration details so that you can configure your R/3 system to ensure a clean cutoff for MM transactions at period close. “Are Your Stock Balances Correct?” In this article, the author answers to six questions along with a little-known report can help you to keep your R/3 Materials Management (MM) and FI stock balances in sync. “Currency Types: The Key to Reporting Parallel Valuations” Do you know what the different currency types are, where they are configured, and when to use them? Confusion abounds in this area, especially when dealing with parallel valuation. In the article, the author provides a roadmap to gain control of all of your conversions and valuations. “Secure Your Revenue Stream: Ensure That SD Billing Document Invoices Are Posted in FI” It is possible to have an SD billing document without a corresponding FI invoice. This type of error can result in significant under-reporting of revenue. In this article, the author provides the detailed steps to ensure all SD invoices are reflected accurately in FI-AR. Two R/3 modules, SD and FI, cover the order-to-cash process. Invoicing represents the interface between SD and FI, and there is a high risk if the two teams are not working in cooperation. If the teams are not aware of their actions’ impact on the others, do not understand the end-to-end

10


QS&S Publications

process, and do not have clearly defined areas of responsibility, or if they simply do not talk to each other, the results may be disastrous. “Use Reconciliation Account Determination with a Special G/L Indicator for More Flexible Invoicing” The author demonstrates how to optimize reconciliation account determination. He introduces the fundamentals of reconciliation account determination, special G/L indicator configuration, and manual adjustments. With examples, he shows how to use reconciliation account determination with a special G/L indicator in the FI-A/R module. “Nine Tips for Dealing with Zero Decimal Place Currencies” The U.S. dollar, like many of the world's currencies including the euro, uses two decimal places, which - not surprisingly - is the default setting for R/3. When you roll out your SAP functionality across geographies, however, you may run in trouble coping with currencies with other decimal-place demands. The author provides tips to help you avoid mistakes when viewing or working with various currencies. “Which A/R Underpayment Option Should You Use: Partial Payment or Residual Item?” When a customer makes a payment for an invoice that is a great deal less than the full invoice value, the A/R user has several choices of how to process the underpayment. Both users and consultants are often confused about the difference between two of those options - partial payment and residual item - because they can appear to have similar results. The author explains how they differ by taking the same invoice through both processes. “Avoid These 11 Common Unit-of-Measure Errors” To keep your SCM operations running smoothly, learn how to avoid and correct these 11 common unit-of-measure errors that can bring them to a standstill. The crucial role of units of measure (UoMs) in SAP is to give context to quantities. A key activity of an SAP system is maintaining clear communication with external business partners (e.g., sending a purchase order to a vendor for raw materials or sending an invoice to a customer). You can accomplish this communication in a number of ways, such as paper invoice, EDI purchase order, or XML delivery confirmation. Quantity is one of the most important aspects of that communication: You need to be sure that an order for five cases of a material is not interpreted as five pieces or five pallets.

11


QS&S Publications

Reporting “Should I Report in CO-PA or BW?” You have a choice of three approaches when reporting on CO-PA data: You can report using CO-PA, Business Information Warehouse (BW), or both. In this article, the author compares these reporting options. "How to Use the SIS Data Warehouse for Management Reporting" It is so common to see clients developing customized reports to get Sales Bookings information. This approach of developing customized solution is not only inefficient you lose the flexibility of exception reporting. Have you thought about Sales Information System (SIS)? It's a part of standard system with its own drill-down reporting tool. With an example, the author demonstrates how to activate custom-defined SIS structure for management Reporting. "Tips and Tricks to improve CO-PA Reporting performance" Published on 'SAPInsiderOnline.com', Editor's Desk of February 2003. CO-PA reporting performance is one of the most crucial aspects of Profitability Analysis. In this article, author has described some of the most important tips and tricks to improve reporting performance. "Split and Speed up your CO-PA reports" Reporting performance is one of the most crucial aspects in CO-PA module. There are few options available in SAP to optimize reporting performance. In this paper, author demonstrates one such trick - to "split" CO-PA reports. Seemingly simple, this trick of breaking one big report into many smaller reports can have dramatic performance improvement. "10 Best Practices for Designing Summarization Levels" Summarization Levels are one of the most powerful techniques for improving CO-PA performance. However, if not defined properly, these Summarization Levels can be the source of performance degradation. In this article, author has unearthed secrets behind how SAP system determines which Summarization Level to use. Also, author has suggested 10 best practices for optimum summarization levels.

12


QS&S Publications

“Extract Pricing Conditions From the R/3 Sales and Distribution Module into BW” The current BW version does not offer extract structures for SD conditions, therefore there is no straight-forward way to transfer SD pricing conditions to BW for further analysis and reporting. In this article, the author reveals a work-around solution and explains how to extract SD conditions to BW. "What You Should Know About SD Higher-level Item Category's Influence on Financial Reports" You might think that the item category of a sales document is purely a Sales and Distribution (SD) function. It's true that it primarily controls how the sales item is processed within SD. However, some of the settings have a significant influence on the FI module. In this article, author demonstrates some of the features of SD Item Category and Sales BOM, which can have significant impact on Financials. “Speed Up Your Report Performance by Knowing Where Your FI Data Is Hiding” Often at go-live, reports are written that appear to work very well, and then a year or two later, they run very slowly. The reason might be a misunderstanding about the kinds of tables that FI debit and credit data is hiding in. This article explains why it's important to your report's performance for you to know if a table is transparent, clustered, or pooled. Productivity Solutions "Plan and Monitor Your Sales Campaigns in the CO-PA Ledger" Offering discounts is one of the most common business practices to increase the business volume. SD module has rich functionality to handle special prices and discounts. Planning and executing a successful promotion campaign is critical to your business. You want to find out how successful your discount campaign was - whether it was really successful or not. SD module provides something called as 'promotion' and 'sales deals' to group together such conditions. However, did you know that you could transfer these details of 'promotion' and 'sales deals' to CO-PA Ledger too? Did you know that CO-PA Ledger can be used to monitor the performance of these marketing initiatives throughout the cycle of such initiatives - right from budget planning, order Bookings to Invoicing?

13


QS&S Publications

"Fast Data Conversions for Functional Analysts with LSMW" LSMW stands for Legacy System Migration Workbench. As the name suggests, LSMW is used during data conversion and is one of the most powerful tools provided by SAP. One of the common myths among SAP community is that data conversion is handled by technical team members - ABAPers. However, the most important highlights of LSMW is that it is so easy to use that everybody, including functional analysts, can use it! Although, many in SAP community use CATT tool for data upload to SAP, features of LSMW far out-weigh. Easy wizard like step-by-step tasks walk you through the whole process. In this article, author details the features of LSMW and with a business example demonstrates how easy it is to use. "CO-PA Archiving - Why and How?" Importance of data archiving cannot be emphasized enough. However, it is an irony that even in companies where archiving is started, many times CO-PA is excluded from the scope. On the other hand, CO-PA should be the first module to get archived. In this article, author explains why CO-PA database grows much faster than you initially thought and how to archive CO-PA data. “For Enhanced System Performance, One SE16 Call is Better than Two” SE16 is one of the most frequently used transaction codes, but it comes with a lot of overhead in terms of system memory. In this article, the author reveals one of the tricks to reduce the number of SE16 calls. “Use CATT to Test Your End-to-End Business Processes” Computer Aided Test Tool (CATT) is SAP’s testing tool for testing various SAP transactions. Though using CATT is fairly simple, many companies do not fully exploit the features. In this article, the author demonstrates how CATT can be used to test end-to-end process like Purchase-to-Pay or Order-to-Cash. "Use TVARV Variables More Effectively To Fasten Month-End Close" Though use of variants is very common, many in business community just scratch the surface. There is much more to variants than just saving the screen field values. Using variables for variants makes the usage more effective and efficient. Instead of creating a new variant or changing the existing variant each time a field value changes, you can create a variable in table TVARV and assign a variable to field value. These are popularly called as TVARV variables and you

14


QS&S Publications

can directly manage the variable values using table maintenance. In this article, the author has unearthed hidden secrets of TVARV variables and explained how to leverage these for more efficient use. Also, the author has documented the best practices on managing these TVARV variables to get maximum out of it. “Can’t Get There?: Find the Right Transaction to Display CO Documents” Sometimes a transaction is not available in the SAP Easy Access Menu, or when you do use the transaction, a cryptic error message results. This type of problem can occur when you try to display CO documents. In this article, the author provides a quick tip to find the right transaction to display the CO documents. “Enhance User Productivity with a Custom Search Help” Take advantage of this underused option to add a custom search help without assistance from a programmer or the need for a developer key. Standard SAP provides multiple search helps for customer look-ups but none that allow you to search by, for example, the VAT registration number field. You can easily create such a search help. Custom search helps can increase end-user productivity by simplifying common searches. Often access to transaction codes SE16 and SE17 is restricted because of Sarbanes-Oxley. Adding a search help is a good way to provide ad hoc look-up. “Tips for Tracking Clearing Transactions” The author compares the two types of clearing functionality in SAP, clearing with or without posting. In addition, he lists steps that allow you to trace clearing transactions going backward as well as forward. “Discover Hidden Parameter IDs to Simplify Your FI Settings” Many users set default values for their FI transactions using transaction FB00 - Accounting Editing Options. However, not all settings for FI/CO transactions are available here. In this article, I'll show you other ways to find and set default values for parameters. I'll also introduce you to some "hidden" parameters. “Who Changed My Config?” The author explains how to use the table logging functionality to answer the question, "Who changed my config?" Table logging is a functionality that enables recording of all insertions, deletions, and changes in configuration tables. He says it has proven invaluable in preventing configuration errors from impacting the production systems at his projects.

15


QS&S Publications

“Update Was Terminated'— What Every FI/CO User Should Know About This Error Message” Have you ever seen the message, Update was terminated, and wondered what it meant? Here's a more worrisome question: Do Your FI users know what to do when they see this message? Project Management “How to Manage User-exits for multiple projects” It is common for companies to have many user exits, for managing multiple initiatives in the organization. Managing user-exits is a challenge, as these user-exits are dependant on various factors and many times may hinder the go-live plans. In this article, the author exhibits a technique on how to manage user-exits. “Account for Time Zone Differences So That They Do Not Affect Your Global Close” When a global company has a period-end close, a great deal of coordination needs to occur among the independent locations to make sure that tight deadlines are met. The author provides eight tips to prevent misunderstandings that can occur because of timing differences when you have offices in more than one time zone.

16

SAP financial concepts, technology, and best practices

>>continued on page 4

June 2007Volume 5 | Number 6

10 RE-FX Builds on RE-Classic with Improved MDM and Document Processing

14Transport Customizing Settings Between SAP Environments Using Transport Requests

18View Your Profit and Loss Data and Analyze Your Investments Using Visual Composer

The new General Ledger (new G/L) in the SAP ERP system offers a feature called docu-ment splitting. With document splitting, the system splits accounting line items according to specific characteristics. This enables you to create financial statements for entities such as segments and meet the legal requirements such as International Accounting Standards (IAS) regulations for segment reporting. You can find out more information about these requirements by visiting www.iasb.org.

I’ll discuss the concepts of document splitting with a simple example of a financial transaction of a vendor invoice. Say you have a vendor invoice that has two expense items totaling $10,000 with $1,000 input tax, so the total is $11,000 (Table 1).

If you are responsible for profit center PC-1 and want to analyze all of the financial transactions for PC-1, you cannot do so completely because the Vendor account (A/C) and Input Tax are not assigned to any profit centers. You cannot assign PC-1 or PC-2 because these items are for combined balances, not for individual profit center items.

Looking more closely at the financial document, it is clear that the total expenses of $10,000 were in the ratio of 80%-20% between PC-1 and PC-2. Therefore, according to the same

See the rules, steps, transactions, and method for document splitting. Then follow seven steps to configure it in your system.

Achieve Balanced Reporting by Automating Document Splitting in the New G/L

by Mitresh Kundalia, Director – SAP Practice, Quality Systems & Software

The splitting method is the main key to activate document splitting in the new G/L, including splitting rules, business transactions, business transaction vari-ants, and more. It is a component of active splitting. The process is a new capability in the new G/L and was not possible in the classic G/L.

Key Concept>>

Account Description Amount Profit Center

Vendor A/C -11,000

Purchases 1 8,000 PC-1


Input Tax 1,000

Sample vendor invoice accounting entriesTable 1

17

www.WISpubs.com

4 © 2007 Financials Expert Reproduction prohibited. All rights reserved.

calculations, the Input Tax and Vendor A/C should also be in the same ratio of 80%-20% between PC-1 and PC-2 (Figure 1).

Using these calculations, the vendor invoice transaction from the earlier scenario looks similar to what is shown in Table 2. If you were to actually post the vendor invoice as shown here, with multiple Input Tax and Vendor A/C items, you could get the balanced Financials report-ing for profit centers PC-1 and PC-2.

While this solves your reporting issue, you still need to be able to post this invoice with split accounting items, as shown in Table 2. Expecting your users to punch in the numbers in calculators, calculate the ratios, and manually split these items is obviously out of the question, so you need to consider how to do this automatically. With the document splitting capability in the new G/L, the user can enter the vendor invoice transaction as shown in Table 1 and the system automatically splits the vendor transaction as shown in Table 2. Before I explain the steps to configure document splitting, I’ll describe the three basic steps and the document splitting method.

Document Splitting in the New G/L — Basic StepsDocument splitting is basically divided into three steps: passive splitting, active splitting, and zero-balancing. The system first tries passive splitting, in which it copies rules from a previous transac-tion. Then it tries active splitting, which includes the rules and method I will cover. Then, if zero-balancing is active, it tries to do zero-balancing. I’ll explain each of these in a little more detail.

Passive splitting. You use passive split-ting especially with clearing transactions (e.g., payment transaction F-53). The system creates a reference to the exist-ing account assignments and uses these account assignments as the basis for the

line items to be split. You cannot change the settings for passive splitting because they are pre-set in the system. For the payment transaction, the system takes the rules from the earlier transaction of the vendor invoice and applies those rules from the vendor invoice.

Active splitting: rule-based document splitting. In active splitting, the system splits the documents on the basis of pre-defined splitting rules. The SAP ERP system is delivered with many such pre-defined rules. If standard splitting rules are not sufficient or you want to enhance the functionality, you can create your own splitting rules. This is outside the scope of this article.

Splitting using zero-balancing. Zero-balancing the document ensures not only that the document is balanced but also that the document is balanced for the charac-teristics. You can define the characteristics that you want to use for zero-balancing, such as a segment or a profit center. I’ll cover zero-balancing in more detail when it comes up in my process.

The active splitting method mentions splitting rules, which are fundamental to document splitting and require a brief

explanation. Splitting rules define which accounting items the system splits and which calculations it uses to split (i.e., based on which accounting items). In my vendor invoice example, you need to split the vendor and input tax items and you use the calculations of 80%-20% based on the expense items. So, the splitting rules for the vendor invoice transaction that you should use are:

Vendor and tax items are accounting items that you need to split

Expense items to use as the base items

As another example, if you had a cus-tomer invoice transaction you would use the splitting rules:

Customer accounting items that you need to split

Revenue items to use as the base items

Document splitting rules are a major part of the document splitting method, which I’ll explain next.

Splitting MethodThe splitting method is the main key to activate splitting in the new G/L. In

•

•

•

•

>>continued from cover

Ratios of input taxes and vendor A/CsFigure 1


Vendor A/C -8,800 PC-1


Input Tax 800 PC-1

Vendor A/C -2,200 PC-2


Input Tax 200 PC-2Sample vendor invoice accounting entries with assigned profit centersTable 2

18

June 2007 • www.FinancialsExpertOnline.com

For group rates on electronic access, call 1-781-751-8799 �

simple terms, it’s the list of all splitting rules for all of the business transactions. Technically, it is a collection of the split-ting rules, business transactions, business transaction variants, and more as shown in Figure 2. In Figure 2, the values and

description in parentheses show the sample values for the vendor invoice example. Also, the new G/L has the pre-defined splitting method 0000000012, with pre-delivered splitting rules for various business transactions.

Continuing with the vendor invoice example, let’s review the Financials transactions in the new G/L. Say you are posting a vendor invoice (transaction FB60) to two expense accounts as shown in Figure 3. Figure 3 shows a vendor invoice (docu-ment type KR) for 11,000 EUR with tax of 1,000 EUR to be posted against two expense items. In Figure 4, you can see how this enters the new G/L. The system assigns expense items to profit centers and segments based on the cost centers to which the expenses are charged, whereas the columns Profit Ctr and Segment are empty initially.

Figure 4 shows the document in the Entry view. The system applies the active docu-ment splitting rules and then splits the document as shown in Figure 5 (on the next page), which is the G/L view. End users (or in some cases the automated postings your system carries through) do not need to change their ways because they only fill out the Entry view as shown in Figure 4. In the simulation (Figure 5), you can see the result of the split, where the vendor A/C and tax are split in pro-portion to the ratio of the two expense postings.

In splitting the document, the system used the splitting method information of busi-ness transaction of vendor invoice 0300 and document type KR to split the vendor and tax items (category 03000 and 05100) according to the 80%-20% calculations of expense items (category 20000) as shown in Figure 2.

It is important to recall that document splitting in the new G/L gets the same results as shown in Table 2. Instead of manually adjusting the financial transac-tions, traditionally done at the month-end, you can achieve the same results in real time using the rule-based splitting in the new G/L. Now that I’ve described the basic elements of document splitting, I’ll show you some customization to config-ure it in your system.

Schematic representation of the document splitting methodFigure 2

Vendor invoice (transaction FB60)Figure 3

Entry viewFigure 4

19

www.WISpubs.com

� © 2007 Financials Expert Reproduction prohibited. All rights reserved.

Document Splitting CustomizationYou can find the configuration for document splitting by following menu path IMG> Financial Accounting New>General Ledger Accounting (New)>Business Transactions>Document Splitting. From this menu path, you can follow these steps to customize document splitting in your system.

Step 1. Classify the G/L accounts for document splitting. One of the first steps for configuring document splitting is to assign the item categories to the G/L accounts for your chart of accounts. Item categories are groupings of G/L accounts. Instead of defining the splitting rules for all expense accounts individually, item category 20000 groups all expense accounts together. You could have one rule for all of the expenses. The system comes with pre-defined item categories.

Click on Classify G/L accounts for Document Splitting and assign the item categories for the G/L accounts. Instead of assigning the item catego-ries by individual accounts, you should use the range of accounts as shown in Figure 6. For example, look at row 8 in Figure 6. Instead of setting the rules for each individual account between 400000 and 419999, you create a range of those accounts resulting in the grouping cate-gory 20000. Then you don’t have to create table entries for 20,000 rows. Recall that splitting rules have item categories for the items to be split and base category items. The SAP system is already pre-delivered with the standard item categories as shown in Table 3.

Step 2. Classify document types for document splitting. So that the system considers every relevant financial transac-tion for document splitting, you categorize the document types to specific business transaction variants. Business transaction variants are a specific version of business

G/L viewFigure �

Assign categories to the G/L accounts Figure �

Account Category Description

01000 Balance sheet account

01001 Zero balance posting (free balancing units)

01100 Company code clearing

01300 Cash discount clearing

02000 Customer

02100 Customer: special G/L transaction

03000 Vendor

03100 Vendor: special G/L transaction

04000 Cash account

05100 Taxes on sales/purchases

05200 Withholding tax

06000 Material

07000 Asset

20000 Expense

30000 Revenue

40100 Cash discount (expense/revenue/loss)

40200 Exchange rate difference

80000 Customer-specific item categoryStandard item categories for G/L accountsTable 3

20


For group rates on electronic access, call 1-781-751-8799 �

transactions, provided by SAP. A business transaction is a general breakdown of the actual business process. Examples of business transactions are vendor invoice, customer invoice, and cash payment. There are various business transaction variants (e.g., vendor invoice or pay-ments) that are already pre-defined in the new G/L. Various document types are linked to the business transactions and business transaction variants.

Click on Classify Document Types for Document Splitting to review the con-figuration and make appropriate changes for the custom document types (Figure 7). In my example, I used document type KR for the vendor invoice.

Step 3. Define zero-balance clearing account. To create balanced Financials for a specific characteristic, you need to use document splitting with the zero-balance option (Table 4). To balance the document on the left for the profit center, you need to post it with a G/L account for zero-balancing the profit center as shown on the right. You need to post two additional accounting line items. Then for these items, you use account number 9999, as illustrated in Table 4.

After document splitting, the system validates whether the document is zero-balanced for the selected characteristic. If it is not balanced, the system creates a balancing entry using a zero-balance clearing account.

Say you have posted a re-post transaction as shown in Figures 8 and 9 (on the next page), which reflect the entry view as seen in the data entry and the G/L view as seen with document splitting, respectively. Using document splitting with zero- balancing for the characteristic Segment, the system posts the splitting document. For the document to be balanced for the segment, it needs to post an additional clearing account, as shown in Table 4.

In this step, you define a G/L account that you should use for creating the zero-

Classify FI document typesFigure �



A/C 1001 123.45 PC-1 A/C 1001 123.45 PC-1

A/C 2002 -123.45 PC-2 A/C 9999 Zero-balancing account

-123.45 PC-1

A/C 9999 Zero-balancing account

123.45 PC-2

A/C 2002 -123.45 PC-2Zero-balancing account balances the document in the profit centerTable 4

Entry view for zero-balancingFigure 8

21

www.WISpubs.com

8 © 2007 Financials Expert Reproduction prohibited. All rights reserved.

balancing splitting for the characteristics. You need a zero-balance clearing account (Figure 10). You may need to create this G/L account if it does not already exist.

Step 4. Define document splitting char-acteristics for G/L accounting. In this configuration step, you define the charac-teristics for which the document splitting rules apply. Common examples include Business Area, Profit Center, Segment (Figure 11). For these characteristics, additionally, you specify whether you want to have zero-balancing and whether this characteristic is mandatory. You may want to have the characteristic mandatory to make sure that particular characteristic field value is entered and not left blank.

Step 5. Define document splitting characteristics for CO and post- capitalization of cash discounts to assets (optional). You can define the document splitting characteristics for CO and define post-capitalization of cash discounts to assets. For example, you can define the document splitting characteristics for the Controlling (CO) module that use docu-ments transferred from the G/L. Also, you can define whether the cash discount that could be on the payment of the asset invoice should be capitalized along with the asset itself.

Step 6. Define constants for non-assigned processes. Here you define default account assignments (for example, default segment) as shown in Figure 12. As the name suggests, when the system cannot determine the characteristic it uses default account assignments.

Step 7. Activate document splitting. Finally, activate document splitting in the new G/L (Figure 13). Check the check box next to Document Splitting and enter in the method. As I mentioned before, standard SAP includes pre-defined splitting method 0000000012, with pre-delivered splitting rules for various business transactions. Note that you activate document splitting at the client

G/L view for zero-balancingFigure 9

Zero-balancing G/L account required for clearingFigure 10

Document splitting characteristics for G/LFigure 11

Constant values for non-assigned processesFigure 12

22


For group rates on electronic access, call 1-781-751-8799 9

level and you can always deactivate docu-ment splitting for specific company codes.

The Inheritance indicator in Figure 13 derives the characteristics in the document from the other line items. For example, when you create a customer invoice from a revenue item, the system inherits the characteristics in the customer and tax lines automatically. Without inheritance, you would need to define the rules, for example, to achieve zero-balancing. After you activate the document split-ting, you can test your document splitting transactions.

Vendor Payment (Follow-Up Process)As a follow-up process, you can post the payment to the vendor and clear the vendor items. The system first splits the payment document according to the passive document splitting rules for clearing. The payment document uses document splitting rules that you use in the original expense postings. Accord-ingly, the system creates the payable lines (e.g., AP-domestic account 160000) through passive document splitting rules.

The system splits the vendor payment document as shown in Figures 14 and 15. Again note that the system applied split-ting rules appropriately for Petty cash (account 100000) and Input tax (account 154000). n

Activate document splittingFigure 13

During testing/development, you should test document splitting one company code at a time to reduce the potential adverse impact to other company codes during the testing phase when you would like to make sure your configuration is working properly. I’ll cover this in more detail in a future article.

Note>>

Entry view for vendor paymentFigure 14

G/L view for vendor paymentFigure 1�

Mitresh Kundalia heads the SAP practice division at Quality Systems & Soft-ware (www.QSandS.com). QS&S helps companies achieve world-class performance by realizing their latent business and technological potential with emphasis on SAP systems. With an MBA degree in finance, Mitresh manages implementations of financial and logistics applications with a special focus on management reporting, Profitability Analysis, the new G/L, and Business Intel-

ligence. You may reach him via email at [email protected].

23

Planning, tracking, and evaluating a discount program orany promotional activity can be accomplished using the SDmodule in concert with the CO-PA ledger in much the sameway that the two work together to book orders and billings.While the SD module together with the CO-PA ledger areoften used to analyze incoming orders and invoicing, manyare not aware that you can combine them to manage andmonitor a promotional campaign.

SAP’s SD module provides the functionality to record andanalyze the prices and discounts associated with promotions. The SD module generatesseparate condition types to identify discounts and promotional prices. These conditiontypes can be mapped to separate value fields in the CO-PA ledger. By closely integratingthe SD data with the CO-PA ledger, you can plan and follow a campaign and evaluateits performance.

The key to this functionality relies on two types of pricing agreements — promotionsand sales deals. You may be aware of these pricing agreements if you are familiarwith the SD module, but you may not know that they can also be transferred to theCO-PA ledger. Using a technique similar to transferring sales bookings and invoicinginformation, the planned values for promotions and sales deals can be established inSD master data and passed to the CO-PA ledger. You can configure the system to transferpromotion and sales deals values as characteristics to the CO-PA ledger. This data can bemonitored along with booking and invoicing data to get a complete picture of a marketingcampaign from sales planning through invoicing, complete with reporting capabilities.

This article examines how SD uses the special pricing agreements to accommodatediscount programs and promotions. I will show you how these agreements can betransferred into the CO-PA ledger, and point out some of the obstacles and confusionpoints that may arise in the process, including the problems associated with transferringlesser-known G record types from SD to CO-PA. I will also discuss how the datacan be analyzed in the CO-PA ledger at various stages of the campaign, and showyou how to configure your system to support this functionality.

The newsletter for mastering SAP financial

concepts, technology,and best practices

February 2004Volume 3, Issue 2

www.FICOExpertOnline.com

© 2004 FI/CO EXPERT • Reproduction prohibited. All rights reserved. 1

Inside This Issue

8Make the SEM ManagementCockpit More Useful withDrill-Down Configuration

12Nine Tips for Dealing withZero Decimal PlaceCurrencies

18How to Delete WronglyEntered Bank Statements

21Understand the DifferenceBetween Active and PassiveWorkflow Substitution

Plan and Monitor Your SalesCampaigns in the CO-PA Ledgerby Mitresh Kundalia, SAP Practice Manager, Quality Systems & Software Inc.

This article appeared in the February 2004 issue of FI/CO Expert, a newsletter from the publishers of SAP Professional Journal and SAP Insider, and is reprinted with theirpermission. To subscribe, or for additional information, visit www.ficoexpertonline.com.

24

2 © 2004 FI/CO EXPERT • Reproduction prohibited. All rights reserved.

February 2004 • www.FICOExpertOnline.com

Promotions and Sales DealsPromotions and sales deals are pricingagreements1 that form a hierarchical relationship. Promotions can consist ofvarious sales deals, and sales deals canact as finer categorizations for promotions.For example, promotions can representdiscounts related to a set of productlines such as those found in high-levelmarketing plans, while sales deals canrepresent individual customer discountsas well as specific products or productlines with special prices.

I have created an example (ChristmasPromotion 1000 in Figure 1) to illustratethe hierarchical relationship betweenpromotion and sales deal agreements. In this example, Sales Deal 1001 is forcustomers and Sales Deal 1002 is forproduct lines. Note that Sales Deal 1001

1 Note that pricing agreements are not the sameas pricing conditions.

represents both customer discounts(condition type K007) along with customer/product discounts (conditiontype K005), while Sales Deal 1002 isfor product lines (K004). Each conditiontype maintains condition records – e.g.,Discounts (K007) for Wal-Mart is 5.00percent, whereas Discounts (K007) forKmart is 3.00 percent. You use the stan-

dard condition maintenance screens(transaction code VK11) for updatingthese discount conditions.

Whenever a sales order is entered, SDautomatically applies the appropriatediscounts (if available) in the pricingprocedure. In addition, the system captures the relevant promotion number

From Our On-Call FI/CO ExpertI am delighted to have been asked to participate in the rollout of a newsletterpredicated on the idea that everyone can be a FI/CO expert if certain con-cepts and mechanics about the modules are clearly explained. The articlesI’ll write or acquire from colleagues for you will answer one, two, or all three of the questions that I’ve been asking myself every day of my eight years of customizing SAP FI and CO modules for companies large and small:

(1) What’s available in FI/CO?

(2) How does it work?

(3) Why should anyone care?

My goal, and that of the other contributing experts, is to bolster every reader’s on-the-job productivity,whether your role is manager, consultant, end user, or executive. My method is to clarify andexpose confusing or poorly documented functionalities, terms, and relationships, so that you — thereader — can be in a position to make your own decisions about what to use and how to use it.

Kurt Goldsmith, Enowa Consulting

About Enowa Consulting: Founded in 2003 by four former "Top Tier" practitioners, the U.S. division of Enowa Consulting represents businessmanagers who believe that the I.T. projects with the most predictable results are those with the fewest consultants. For questions or a competitive bid on Quality Assurance roles for projects $10 million and up, contact director Winni Hesel ([email protected]).For questions or a competitive bid on a minimalist approach to staffing a rollout, a merger, or a redesign project, contact director Ali Sarraf([email protected]).

FI/CO Expert11300 Rockville Pike, Suite 1100Rockville, MD 20852-3030, USA(301) 287-2719 phone (866) 313-0972 toll-free(301) 816-8945 faxhttp://www.FICOExpertOnline.com

EEDDIITTOORR-IINN-CCHHIIEEFF Bonnie Penzias

GGRROOUUPP EEDDIITTOORR Michael [email protected]

MMAANNAAGGIINNGG EEDDIITTOORR Andrea [email protected]

EEDDIITTOORR Charlie [email protected]

SUBSCRIPTIONSFI/CO EXPERT (ISSN #: 1537-9922) is published 10 times a year. A one-year subscription is $595.Volume discount subscriptions are available by calling (781) 751-8799.

DISCLAIMERAlthough we use reasonable care to produce FI/COEXPERT, we cannot assume any liability for its contents. In no event will FI/CO EXPERT be liable for costs or damages, direct or indirect, includingspecial, remote or consequential damages, even ifFI/CO EXPERT has been advised of the possibility ofsuch damages, from any cause, whether in contract,tort or strict liability, in excess of the subscription feepaid by the subscriber.

CHANGE OOF AADDRESSIf you plan to relocate, please give us 4 to 6 weeksnotice to ensure that you do not miss any issues.Postmaster: Send address changes to FI/CO EXPERT,11300 Rockville Pike, Suite 1100, Rockville, MD20852-3030, USA.

TRADEMARKSSAP and mySAP are registered trademarks of SAP AGin Germany and in several other countries. All otherregistered trademarks are the property of theirrespective holders.

Figure 1 Typical promotion and sales deals

25


and sales deal number. It stores the infor-mation in the Sales Document: ItemData (VBAP) table, which allows youto write basic reports listing the discountsand special prices offered for specificpromotions and sales deals. KNUMA_PIis the technical field name for promotionsand KNUMA_AG is for sales deals.

After you create the two pricing agree-ments in the SD module, you can passthem to the CO-PA ledger as character-istics. Once they are transferred, youcan generate drill-down reports to analyzethe performance of an entire promotionalcampaign or to determine how well adiscounted price on an individualproduct is driving sales.

Tapping the AnalysisFunctionalityIn addition to entering special prices and discounts, users can enter theplanned values expected to result from

For site licenses and volume subscriptions, call 1-781-751-8799 3

transferred. When the Incoming salesorders bookings function is activated inCO-PA via the transaction code KEKF,condition values for sales orders enteredin the source system are transferred tothe CO-PA ledger as record type A(Record types in CO-PA identify thesource transactions as shown in Figure 3).Similarly, planned values are transferredto CO-PA as commitments identified bythe record type G (Customer agree-ments). Use transaction code KES4 toactivate the transfer of discounts fromSD to CO-PA. The condition types specific to the promotional campaignare set in the Activate BudgetAssignment screen.

Tip! Although the data in record typeG represents so-called plannedvalues, these records are not storedin Plan Data table (CE2) in CO-PA.Instead, planned values are stored inActual Line Items table (CE1) in CO-PA as commitments, which leads tosome confusion.

Configuring your system to transfer promotion and sales deal data to theCO-PA ledger as characteristics makesreporting available throughout the life-

the discounted terms in the SD module,and analyze this data relative to theactual results in CO-PA. This combinedfunctionality allows you to plan,monitor, and analyze the performance of your promotional programs frombeginning to end.

Consider the following example: Amarketing plan is created that calls for a5 percent discount for specific customers,which is expected to generate €1 millionin sales for a total of €50,000 in customerdiscounts. These target figures are enteredinto the SD module using transactionVK11 as Planned values (Figure 2).By transferring these values into CO-PA, the program can be scrutinizedto see how close the campaign came tohitting the €1M/€50K target.

As I indicated earlier, transferring plannedvalues from SD to CO-PA is accomplishedin much the same manner that salesbookings and invoices transactions are

Figure 2 Budget planning for condition records Figure 3 CO-PA record types to identify

source transactions

26



cycle of the campaign, as shown inFigure 4. You can configure yoursystem to transfer SD data to CO-PA atthe time of sales planning (KES4), salesbooking (KEKF), and invoicing.

In CO-PA, you can design reports toanalyze the campaign and track how it isperforming at various levels. For example,you can design a report to show how theoverall campaign is performing in termsof sales, with the ability to allow users todrill down to see how individual customersare performing. Figure 5 shows the totalrevenue for a campaign along with therevenue broken out by customer. In thisexample, Wal-Mart and JC Penney areperforming better than expected, whileMacy’s and Sears are behind budget, sug-gesting a strategy change may be in order.

Passing Pricing Agreementsfrom SD to CO-PAConfiguring your system to allow theSD module to pass pricing agreementsto the CO-PA ledger is not overly com-plicated, although the practice is notwell known.

You need to add two user-defined char-acteristics for promotion and sales deals toyour operating concern so the values forthe pricing agreements in SD transactiontable VBAP (VBAP-KNUMA_PI andVBAP-KNUMA_AG) can be passed into

the CO-PA ledger. Although the fields inSD are from a standard SAP table (VBAP),you cannot add them as standard fieldsin the operating concern. Because theKNUMA_PI and KNUMA_AG fieldsare eight characters long, you get anerror message (“Field name must havebetween 04 and 05 characters”) if youtry. I named my user-defined fieldsWWPRO and WWSDL, but you canuse any name as long as it starts withWW and is four or five characters long.

Tip! Test this configuration in yoursandbox first. Once a characteristicis added to the CO-PA operatingconcern, it is very difficult to remove.

Use transaction code KEA5 or menupath COPA IMG>Structures>Operating Concern>MaintainCharacteristics>Create/Change toaccess the screen shown in Figure 6,which is from the IDES 4.5B system.Click the User-definition radio buttonand enter your user-defined characteristicname, in this case WWSDL, along withthe description Sales deal. Next,select the button With reference toexisting values and select the Dataelement KNUMA_AG. Save and activate the characteristic. Following the same steps, create your second characteristic (WWPRO) using Promotionin the description field and KNUMA_PIas the Data element.

PromotionSalesDeal Customer

Budget forSeason

Orders receivedduring season

Shipped andInvoiced Status

1000 1001 Wal-Mart 5,000,000 6,000,000 5,500,000 Beating expectations

1000 1001 Target 2,000,000 2,000,000 1,500,000

1000 1001 Kmart 2,000,000 2,000,000 1,500,000

1000 1001 Macy’s 1,000,000 500,000 500,000 Revise strategies?

1000 1001 Sears 1,000,000 750,000 750,000 Revise strategies?

1000 1001 JC Penney 500,000 750,000 500,000 Beating expectations

Total 11,500,000 12,000,000 10,250,000

Figure 4 With data from SD, CO-PA can provide details throughout the process, fromsales planning through invoicing

Figure 5 Sample drill-down report with planned discounts, booking, and revenue details

27


Once the two characteristics are created,you need to add them to the operatingconcern structure using transaction codeKEA0 or menu path COPA IMG>Structures>Operating Concern>Maintain Operating Concern. Enterthe name of your operating concern, inthis case IDEA, choose the DataStructures radio button, and click on thechange icon. Because the characteristicsand key figures of the operating concernare the same in all clients, you see aninformational message indicating thatthese changes will be reflected in allclients.

Transfer the two newly created charac-teristics from the field catalog to thedata structure of the operating concern,as shown in Figure 7. Save and activatethe changes, and generate the operatingconcern when prompted. At this stage,you have successfully added these twocharacteristics and the CO-PA structureshave been modified to receive promotionand sales deal values.

Maintain TKEZU Entries The new user-defined characteristicsrequire that you maintain your rules in order to transfer the values to CO-PA. Table TKEZU maintains themapping of transfer values from thesource tables in SD to CO-PA. The topic is covered broadly in SAP note33968; however, I have put a finer point on it in the following few paragraphs.To maintain table TKEZU (Table 1, onthe next page), use the view maintenancetransaction code SM31 or transactioncode SM30 (View V_TKEZU).

In this example, I used XXXX as adummy name for the operating concernand WWPRO and WWSDL representthe user-defined promotion and salesdeal characteristics. SD00, SDIN, andSDOR are the business transactionsrelated to the sales processes and must

be maintained. SD00 is the businessprocess identifying a billing document,and SDIN and SDOR are the businessprocesses to create a billing documentand a sales document, respectively. Youneed to create entries for these threebusiness processes if you are runningR/3 version 4.6B or older. Note, however,that for implementations of 4.6C and

newer, you only need to create an entryfor business transaction KEDR.

PAPL is the business process to identifyprofit planning, and it is used for main-taining condition records for planning.You must have PAPL entries in tableTKEZU. Condition maintenance recordsare not stored in the Sales Document:

Figure 6 Create user-defined characteristic for a sales deal

Figure 7 Transfer characteristics from the field catalog and add to the data structure




Item Data (VBAP) table like SD00,SDIN, and SDOR. Instead, these valuesare picked from the KOMP structure.

Transferring G Records and Setting DiscountsNext, the system must be configured to allow the transfer of record type Gcustomer agreements for discounts andoffers from SD to CO-PA. Use transactioncode KES4 or menu path CO-PAIMG>Flows of Actual Values>Set UpTransfer of Customer RebateAgreements and check the appropriateBudget as... for specific conditiontypes, as shown in Figure 8.

Tip! Best practices suggest that youavoid transferring all conditions forbudget assignment to CO-PA. Instead,transfer only those conditions relevantto your promotion planning.Otherwise, unnecessary data will betransferred, which will increase yourCO-PA database and lead to associ-ated problems.

Tip! As noted earlier, you can main-tain planned values for conditions intransaction code VK11, but theActivate Budget assignment check-boxes located in the Budget as...column in Figure 8 must be set. Ifthe checkbox is not set, the plannedvalues field is not visible when youare maintaining the condition records shown in Figure 2on page 3.

Assign Valid Condition Types After determining all of the discountrates for a sales deal or promotion, you can manage them more easily bycollecting the condition types in a

condition type group. A condition typegroup limits the number of discount-related condition types that show upwhen creating a new sales deal master.

Use IMG menu path Sales andDistribution>Basic Functions>Pricing>Pricing Agreements>Set upSales Deals>Assign Conditiontypes/Tables to Condition TypeGroups to assign condition type to condition type group 0020, which is

available specifically for sales deals(Figure 9). When defining conditiontypes, make sure to include thosecustom condition types that you mayhave created for your client for specialcustomer discounts such as the ZDIScondition type in Figure 9.

Business Example Once your configuration is complete,you can test it with the following basic

Operatingconcern(ERKRS)

FieldName

(MERKMAV)

BusinessTransaction(VRGNG)

TableName

(TABLENAME)

FieldName

(FIELDNAME)

XXXX WWPRO PAPL KOMP KNUMA_PI

XXXX WWPRO SD00 VBAP KNUMA_PI

XXXX WWPRO SDIN VBAP KNUMA_PI

XXXX WWPRO SDOR VBAP KNUMA_PI

XXXX WWSDL PAPL KOMP KNUMA_AG

XXXX WWSDL SD00 VBAP KNUMA_AG

XXXX WWSDL SDIN VBAP KNUMA_AG

XXXX WWSDL SDOR VBAP KNUMA_AG

Table 1 Maintain TKEZU entries

Figure 8 Activate transfer of customer rebate agreements for budget assignment

29



business example, which includes creating promotions and sales dealsagreements, planning discount values,creating a sales order, and billing.

The first step calls for creating a promotion in the standard system viatransaction code VB31 (menu pathLogistics>Sales and Distribution>Master data>Agreements>Promotion>Create), and entering the appropriatedescription and validity period for thepromotion along with its organizationaldata. Via transaction code VB21, younext create a sales deal, enter itsdescription and validity period, and link it to the appropriate promotion.

At the Sales Deal screen (Figure 10),click on Conditions to maintain conditions for discounts or specialprices, choose the condition typeassigned to sales deals, and enter thediscount percentage offered to the customer. Using the Planned basisfield in the Planned values block, enter the total amount of sales expectedfrom the discount. Save the conditions,which are transferred to CO-PA asrecord type G along with the plannedvalue amounts. In addition to theplanned values, the promotion and sales deal numbers are transferred toCO-PA. You can use transaction codeKE24 (display actual line items) to view the record type G data.

Now you can create a sales order and test the system to determine if itcorrectly applies the discounts. When a sales order is created via transactioncode VA01, the system checks whethernewly offered special prices and dis-counts are in effect. If so, it gets theappropriate promotion and sales dealnumbers and applies these discountsautomatically to the order. These salesorder details, along with promotion andsales deal numbers, are transferred toCO-PA ledger as record type A. Once

the order is billed, the details are passedto CO-PA ledger as record type F.

In this business example, I am usingtransaction code KE24 just to reviewCO-PA line items. You can create a drill-down CO-PA report to dodetailed analysis. For example, youcould create a CO-PA report to monitorthe commitments in record type G, thenslice-and-dice on promotion and salesdeals. You also could create a CO-PAreport to compare commitments andsales bookings and analyze whether youare able to attract business based onplanned discounts.

Mitresh Kundalia heads the SAP practicedivision at Quality Systems & Software(www.QSandS.com). QS&S helps companiesachieve world-class performance by realizingtheir latent business and technologicalpotential with an emphasis on SAP systems.QS&S uses best practices and industry-proven implementation tools to integratecomplex business processes with SAPsystems. With an MBA degree in finance,Mitresh implements Financial and Logisticsapplications specializing in ManagementReporting, Profitability Analysis, InformationSystems, and Business InformationWarehousing. He can be reached by email at [email protected].

Figure 9 Assign valid condition types for sales deals

Figure 10 Sales deal details and assignment to promotion

30


January 2004 • www.FICOExpertOnline.com

10 Best Practices for DesigningSummarization Levels

by Mitresh Kundalia, SAP Practice Manager, Quality Systems & Software Inc.

Summarization level is one of the mostpopular techniques for improving reportperformance in CO-PA. It was introducedwith the 3.0C release and improved inrecent releases. Summarization levels,which are presummarized data for specific characteristics, can improveperformance dramatically if they areproperly defined. However, improperlydefined, summarization levels canburden a system to the extent that per-formance is considerably degraded.

One of the most frequently asked questionsabout summarization levels is how theR/3 system determines which level touse. You may think the system is goingto use summarization level “X,” but ituses summarization level “Y” instead.

This article clarifies how the systemdetermines the most suitable summa-rization level. It then will show you howto use that information to define theoptimum summarization level and thusimprove your report performance. This information, which comes frommy personal experience, is not well documented elsewhere. If you need arefresher on summarization levels, seethe sidebar “What Are SummarizationLevels?” on page 13.

System Logic Determinesthe Summarization LevelWhen you execute a CO-PA report,the system displays an informationalmessage at the bottom of the screen.The message indicates whether the

system found a suitable summarizationlevel. You have probably observed messages such as Read data from summarization level 310. So how doesthe system know which summarizationlevel to use? R/3 follows these fivesteps to find the most suitable summa-rization level.

Step 1. The system finds all the character-istics that are required for aggregation inthe report: characteristics from generaldata selection, characteristics used inreport row/column definitions, and drill-down characteristics. These form the basisfor further selection and requirements.

Step 2. The system finds all summariza-tion levels that have at least all thecharacteristics listed in step 1, althoughthe summarization levels can havemore characteristics. The system marksthese summarization levels as suitable. Ifa characteristic of the summarizationlevel is defined as a fixed value (not as“*”), then that characteristic has to beexplicitly defined in the report the sameway. Otherwise, the summarization levelis deemed not suitable to meet therequirements. For example, if a summa-rization level is created for customergroup 01 and general data selection is forcustomer group 02, this summarizationlevel is marked as not suitable.

Step 3. For each suitable summarizationlevel identified, the system finds howmany characteristics it has to summarizeto get aggregated data, the total numberof summary table records, and the last

timestamp. The idea is to find which ofthese suitable summarization levels isoptimal, as shown in Table 1 on page 12.

Step 4. Possible summarization levelsare sorted by the number of charactersneeded to summarize (ascending), thenumber of records in the summary table (ascending), and the timestamp(descending), as shown in Table 2 onpage 12.

Step 5. Once the summarization levelsare sorted, the system chooses the firstsummarization level, which is optimalfor the required characteristics. Insimple terms, the system tries to find thesummarization level with the leastnumber of “extra” characteristics (i.e.,not required for display) and the fewestsummary records. Let’s say your reportrequires customer group drill-down andyou have two summarization levels, onewith the customer group and anotherwith a combination of the customergroup and the product group. Althoughboth can give data summarized by customer group, the first is the fastest.

If not defined properly, summarizationlevels may degrade system performance.With insight on how the system determinesthe optimal summarization level, youcan design efficient summarizationlevels. The following are 10 best practicesfor designing summarization levels.

1. Include dependent characteristicsin summarization levels. When youinclude a characteristic in a summarizationlevel, you should include all the character-

This article appeared in the February 2004 issue of FI/CO Expert, a newsletter from the publishers of SAPProfessional Journal and SAP Insider, and is reprinted with their permission. To subscribe, or for additional information, visit www.ficoexpertonline.com.

31



istics that are dependent on it. Addingdependent characteristics does not increasethe size of the level, but may extend itsuseability. If you use the system proposalExtras>Proposal for>Reports, includedependent characteristics in the definitionof summarization level.

For example, if you have included thecharacteristic “customer” in the summa-rization level, you should also include allcharacteristics that are derived from thecustomer master record (e.g., customergroup). If the summarization level contains characteristics from the Salesand Distribution (SD) table KNVV ofthe customer master, the level shouldalso contain the fields that make up thesales area (fields VKORG, VTWEG,and SPART). These fields are part of thekey for the customer master.

If the key table has 1,000 unique customer records, even after you add the customer group in the definition ofthe summarization level, the key tablestill has 1,000 records. Summary tablerecords also do not increase. On theother hand, the summarization level ismore useable — for example, if youhave a report with the customer grouponly as a drill-down characteristic, itcould use the summarization level.

2. Do not include constant character-istic values in summarization levels. Ifa characteristic is a constant — i.e., ithas only one possible value — youshould either exclude this characteristicor include it with an asterisk (*) to indicate “all possible values.”

If the summarization level is defined forcompany code 0001, for example, thenthis company code must be defined inthe report definition. Otherwise, thesystem thinks that this summarizationlevel is not suitable. The rule is that ifany constants (hard-coding) are in thedefinition, then these constant valuesmust be defined in the report.

An exception to this practice is for thecharacteristic “controlling area.” In thiscase, you should not exclude it from thedefinition of summarization level if it isused in cost center assessment. For costcenter assessment cycles, the controllingarea is implicitly defined.

3. Avoid fixed characteristic values in summarization levels. In normal circumstances, do not include fixed values for characteristics in summarizationlevels. There is no advantage in definingfour separate summarization levels forfour separate company codes such as 0001,0002, 0003, and 0004 (with the samedefinitions except for company code).

However, an exception occurs when oneof the company codes (0001) is verylarge in comparison to the others, andyou do not need a summarization level toanalyze all company codes together. Inthis case, it may make sense to create onesummarization level each for companycodes 0001, 0002, 0003, and 0004.

Avoiding fixed characteristic values hasa technical advantage, too, especially onOracle databases. It is often difficult tobuild summarization levels, and the sys-tem causes terminations with error mes-sage ORA-1555 – snapshot too old. Toavoid terminations, the system breaksdown a SELECT statement on the CE4

SummarizationLevel

Suitable? CharactersRequired

Number ofRecords in

Summary Table

Timestamp

1

2 ✓ 8 60,000 Mar 1, 2003 8:04 p.m.

3

4 ✓ 11 95,000 Mar 1, 2003 8:04 p.m.

5

6

7 ✓ 9 75,000 Mar 1, 2003 8:04 p.m.

8

9

10

11 ✓ 7 50,000 Mar 1, 2003 8:04 p.m.

12 ✓ 13 85,000 Mar 1, 2003 8:04 p.m.

13

Table 1 Suitable summarization levels and details

SummarizationLevel

Suitable? CharactersRequired

Number ofRecords in

Summary Table

Timestamp

11 ✓ 7 50,000 Mar 1, 2003 8:04 p.m.

12 ✓ 8 60,000 Mar 1, 2003 8:04 p.m.

7 ✓ 9 75,000 Mar 1, 2003 8:04 p.m.

4 ✓ 11 95,000 Mar 1, 2003 8:04 p.m.

12 ✓ 13 85,000 Mar 1, 2003 8:04 p.m.

Table 2 Sorting of suitable summarizations — the system chooses the first summarization level, 11

32



What Are Summarization Levels?

The primary purpose of a CO-PA report is to display information in aggregated (summarized) form. If the reporthas to read the CO-PA data from transaction tables and presummarize it in memory before displaying the data, ittakes much longer. The CO-PA module is notorious forhaving a huge volume of transactions. The report performancecan be improved if the presummarized data already exists,so that the system does not have to read transaction data. Inshort, summarization levels are presummarized data forselected characteristics. (For more information on summa-rization levels, see the article by Tony Rogan, “ImproveYour CO-PA Response Speeds by Summarizing Your Users’Data,” published in the April 2002 issue of FI/CO Expert.)

Technical StructureTransaction data in CO-PA is stored primarily in CE1xxxx,CE3xxxx, and CE4xxxx tables (where xxxx is the name ofthe operating concern).

• CE4 Segment table (profitability segments)

• CE3 Segment level (period totals for the profitability segments)

• CE1 Line items — actuals

Table 1 shows the CE1, CE3, and CE4 tables.

If no suitable presummarized data is available, the systemreads data from the CE3 and CE4 tables. It is easier to

Table 1 Transactions stored in CE4, CE3, and CE1 tables. The blank columns do not represent anything. They are includedfor comparison purposes only.

Segment No. Customer Product AdditionalCharacters

0477 C081 PROD1

0478 C081 PROD2

0479 C081 PROD3

Segment No. Period Revenue AdditionalValue Fields

0477 01/2003 100.00

0477 02/2003 2,000.00

0478 01/2003 200.00

0479 02/2003 4,000.00

Segment No. Period Document Item Customer Product AdditionalCharacters

Revenue AdditionalValue Fields

0477 01/2003 120007 0001 C081 PROD1 100.00

0478 01/2003 120007 0002 C081 PROD2 200.00

0477 02/2003 120008 0001 C081 PROD1 400.00

0479 02/2003 120008 0002 C081 PROD3 800.00

0477 02/2003 120009 0001 C081 PROD1 1,600.00

0479 02/2003 120009 0002 C081 PROD3 3,200.00

CE4 — Segment table

CE3 — Segment level

CE1 — Line items (actual)

Note! Although CO-PA reports are the primary candidates for using summarization levels, R/3 uses summarization levels inother functions also: cost center assessments to CO-PA, planning functionalities, and LIS-to-CO-PA interfaces.

33

What Are Summarization Levels? (cont.)



understand the CE4 table as a key table, and the CE3 tableas a summary table.

Summarization Levels — Data StructureSummarization levels are further summarizations of CE3and CE4 tables. Similar to the CE4 (segment table) and CE3 (segment level) tables, a summarization level consists oftwo tables: a key table and a summary table. The key table corresponds to the segment table and contains the character-istics that are defined for the summarization level. Thesummary table contains totals of value and quantity fields.The summary table also contains the characteristics period(PERIO), fiscal year, and record type (VRGAR).

Table 2 shows how summarization levels further summarizethe CE3/CE4 data. Therefore, when the CO-PA reportaccesses summarization levels, it needs to access fewerrecords to display the aggregated information.

Summarization levels for costing-based CO-PA are stored in tables K81nnnn, where nnnn is a four-digit runningnumber. Key tables have an odd nnnn and totals tables havethe next even number.

Table 2 shows the data in CE3 and CE4 tables. Even if thereport is required to show data for the customer only, it stillneeds to read data for products too. The key table andsummary table show the summarization level created for thecharacteristic “customer.” Now, with the help of the sum-marization level, the same CO-PA report has to read manyfewer records to display customer information.

How to Build Summarization LevelsUnlike CE3 and CE4 tables, which are automatically populated by the source transactions, summarization levelsneed to be defined and updated manually. You can definesummarization levels based on your requirements by trans-action code KEDV, as shown in Figure 1. It is alwayseasier to let the system propose the summarization level (if the option is available) and then fine-tune it. Once it isdefined, you need to update the new summarization levelwith program RKETRERU (option Build new levels).Periodically, you also need to update summarization levelswith program RKETRERU (option Update).

PSegment Customer Product

PS1 C1 P1

PS2 C1 P2

PS3 C1 P3

PS4 C1 P4

PS5 C2 P1

PS6 C2 P2

PS7 C2 P3

PS8 C2 P4

PSegment Period Revenue

PS1 1/2003 1000.00

PS1 2/2003 600.00

PS1 3/2003 350.00

PS2 1/2003 250.00

PS2 2/2003 350.00

PS2 3/2003 480.00

PS3 1/2003 2000.00

PS3 2/2003 500.00

PS3 3/2003 300.00

PS4 1/2003 1250.00

PS4 2/2003 350.00

PS4 3/2003 250.00

PS5 1/2003 1230.00

PS5 2/2003 300.00

PS5 3/2003 500.00

PS6 1/2003 600.00

PS6 2/2003 700.00

PS6 3/2003 750.00

PS7 1/2003 1200.00

PS7 2/2003 350.00

PS7 3/2003 300.00

PS8 1/2003 200.00

PS8 2/2003 250.00

PS8 3/2003 300.00

PSegment Customer

PS11 C1

PS12 C2

PSegment Period Revenue

PS11 1/2003 4500.00

PS11 2/2003 1800.00

PS11 3/2003 1380.00

PS12 1/2003 3230.00

PS12 2/2003 1600.00

PS12 3/2003 1850.00

CE4Segment Table

CE3Segment Level

K810001Key Table

K810002 Summary Table

Table 2 Summarization level for customer

Figure 1 Defining and updating summarization levels

34



table into multiple smaller SELECTstatements. As a result, applicationsdon’t keep the cursor open for long, andterminations are avoided. However, thestatements are broken only if no condi-tions are specified for the CE4 table —i.e., fixed values are not used in the def-inition of summarization levels.

4. Maintain a moderate number of summarization levels (eight to 20 will suffice). Extensive use of summarizationlevels improves report performance dramatically. However, in their enthusiasm,customers may create too many. Eightto 20 summarization levels are alwayssufficient. For a simpler setup (e.g., onecompany code, one controlling area, oneplant, one sales organization), four tosix summarization levels should suffice. For more complex scenarios (e.g., aconglomerate with multiple legal entitiesand a resulting complex organization), itis not uncommon to have more than 20.This is not a hard and fast rule. Thebasic idea is not to overdo it becausesummarization levels occupy data space,and they have overheads, too.

5. Avoid redundant summarizationlevels. If one summarization level con-tains another, make sure the two are nottoo close to each other. Let’s say you have summarization level 0002, whichcontains all the characteristics of summarization level 0001. Typically, itdoes not make sense that summarizationlevel 0002 would have only one or twocharacteristics more than SL 0001, andwith very few extra records. In this case,summarization level 0001 is not veryuseful. Also, you should avoid a summarization level with nearly as many records as the segment level.

6. Build all summarization levels tohave the same timestamp. It is advisablefor all the summarization levels to havethe same timestamp so that all have“current” status for consistency. If you

So that the report does not have to readmany of these missing records, it is advisable to run the update job at least30 minutes later than a typical mass updatejob (e.g., invoices creation). For example,let’s say your company has a periodicjob of creating invoices at 10 p.m. dailyand updating the summarization levelsat 10:15 p.m. The summarization levelkeeps a safety delta of 30 minutes andincludes only those records createdbefore 9:45 p.m. The invoice recordscreated at 10 p.m. are excluded, andevery time you run a CO-PA report, thereport has to read these missing lines.This affects report performance. In thiscase, it is advisable to run the summa-rization update job after 10:30 p.m. daily.

10: Periodically fine-tune your sum-marization levels. Periodically reviewthe definitions of summarization levelsand adapt the definitions to suit therecent changes in your organization. If you are changing the definition ofsummarization levels, make sure thatthe earlier reports are still able to usethe new summarization level. When you change a summarization levelexpecting improvement, make surenothing has fallen through the cracks.You can quickly execute earlier CO-PAreports to make sure R/3 displays themessage that it is using a summarizationlevel in the status screen. Also, it is agood idea to periodically check how thesummarization tables are growing.

Mitresh Kundalia heads the SAP practice division at Quality Systems & Software (QS&S).QS&S helps companies achieve world-class performance with enablement of business andtechnological solutions with emphasis on SAPsystems. With an MBA degree in finance,Mitresh implements financial applications withspecialization in Profitability Analysis, GeneralLedger, subledgers, Special Purpose Ledger,information systems, and Business InformationWarehouse. You may reach him by email [email protected].

Figure 1 Checking when data waslast read

have many summarization levels, it isadvisable to build all the smaller sum-marization levels together in the firstrun and then build the larger ones. Onceall the summarization levels have beenbuilt, update them again in one final runso that they all have the same timestamp.When you update all the levels together,you achieve the same time frame for alllevels so that any two reports alwayshave consistent data, even when theyread it from different levels.

7. Delete older summarization levels.This sounds obvious, but you should deleteolder summarization levels that are notbeing used. In a dynamically changingenvironment, some of the summarizationlevels that were required in the previousyear may now not be used at all. Withthe use of transaction code KEDV;check the Date last read status of thesummarization level, as shown in Figure 1.

8. Update summarization levels daily.It is usually sufficient to rebuild a summarization level once and to updateit periodically. Do not update summa-rization levels more often than necessary.Usually once each night is sufficient.

9. Keep 30 minutes distance frommass data postings when updatingsummarization levels. To maintainconsistency, the system does not includedata records created in the last 30 minutes (this is termed a “safety delta”)when updating summarization levels. In that sense, the summarization leveldoesn’t include the exact totals. However,when the report is executed, the systemadds these so-called “missing” recordsto show the correct result.

35


July/August 2004 • www.BWExpertOnline.com

Extract Pricing Conditions from the R/3 Module into BWby Mitresh Kundalia, SAP Practice Manager, Quality Systems & Software

Dear Reader,

Unfortunately, the current BW systemlacks the extract structures you’relooking for to transfer sales documentpricing conditions from R/3. TheLogistics Extraction Cockpit (LOCockpit) does not have an extractorfor the sales orders or billing docu-ment condition values contained inR/3 table KONV.

Ask the BW Expert

Dear BW Expert,

I cannot find an InfoSource for pricingconditions for sales documents in thestandard business content. Can youpoint me to an InfoSource that extractspricing conditions for sales documentsfrom the KONV table in R/3?

Satish Hiranandani, Hewlett-Packard

It’s common for BW practitioners toattempt to make up for the missingextraction technology by writing customer enhancement RSAP0001(EXIT_SAPLRSAP_001) for trans-ferring pricing conditions. This is amistake that can cause performanceissues because the system reads conditions data in a loop. In addition,EXIT_SAPLRSAP_001 is called atthe time of extraction and the condi-tions can change by the time the datais transferred, causing reporting inaccuracies and other problems.

However, there is an effective work-around based on subtotal fields in R/3 fortransferring Sales and Distribution (SD)module pricing conditions into BW.Subtotal variables are used to calculateand temporarily store important conditionvalues during pricing calculations infields that are accessible for extraction.

What Are Subtotals?Before I explain my solution, I’d like to tell you a little more about subtotalsand what they do in R/3 so you canbetter understand the workaround. TheR/3 system ships with more than 20subtotal variables, and they are animportant component of its pricing procedure. Used to determine anitem’s selling price, pricing proce-dures consist of various conditiontypes such as categories of prices, discounts, surcharges, and taxes thatare totaled together. Figure 1 showsan abbreviated example of a typicalpricing procedure (RVAA01) withcolumns for both condition types(CType) and subtotals (SubTo).

The subtotal code, which is representedas 1 in Figure 1, determines into whichvariable the subtotal is placed. Figure 2shows that the value of step 100 isassigned to subtotal variable 1, whichmeans the Gross Value amount is storedin KOMP-KZWI1. Variable codes 1through 6 indicate that the values arecarried over to the KOMP structure.These values are permanently stored intables VBAP (Sales Document: ItemData) and VBRP (Billing Document:Item Data). In Figure 2, note that subtotals codes 7, 8, 9, and A through Care reserved for special purposes andshould not be used for customizing.

Subtotal variables fulfill a couple objectives in R/3. They are used tototal more than one row of pricing Figure 1 Typical pricing procedure

This article appeared in the July 2004 issue of BW Expert, a newsletterfrom the publishers of SAP Professional Journal and SAP Insider, and isreprinted with their permission. To subscribe, or for additional information,visit www.bwexpertonline.com.

36

2 © 2004 BW EXPERT • Reproduction prohibited. All rights reserved.


Figure 2 Subtotal (SubTo) variables and their corresponding fields

Figure 3 Subtotal variable E totals condition type ZK11 and ZK12 in XWORKE

procedures when the rows are notsequential (Figure 3). To calculate thesum of ZK11 and ZK12, for example,you would assign subtotal variable E toeach of the rows with these conditiontypes. The total is then stored in fieldXWORKE. Subtotals also performother roles such as providing access tospecific condition-type values whenrow numbers are not available.

Subtotals WorkaroundSubtotal fields can be used to transfercondition values into BW via salesorders and billing documents screens in SD. These are the KZWI fields numbered KZWI1 through KZWI6 intables VBAP and VBRP. You can display these tables VBAP or VBRPvia transaction code SE11 and reviewthe technical fields (Figure 4).

The standard InfoCube 0SD_C03 (SalesOverview) contains all the transactiondata from sales orders, deliveries, andbilling documents. It is updated via thefollowing InfoSources:

• 2LIS_11_VAITM (sales document)

• 2LIS_12_VCITM (delivery item)

• 2LIS_13_VDITM (billing documentitem)

InfoCube 0SD_C03 containsInfoObjects 0SUBTOT_1S,0SUBTOT_2S, 0SUBTOT_3S,0SUBTOT_4S, 0SUBTOT_5S, and0SUBTOT_6S that correspond to sixsubtotal fields (VBAP-KZWI throughVBAP-KZWI6) in SD.

Let’s say your company uses the pricingprocedure shown in Figure 5 on thenext page, and you need to extract andtransfer the following values:

• *Gross value for Item

• *Net Value of Item Figure 4 Technical table structure showing the six subtotal (KZWI) fields

37



• *Net Value of Item 2

• *Freight

• *Total Discounts

Use transaction code V/08 to tweak thepricing procedure by adding subtotalvariables to the Sub. To column asshown in Figure 6.

The pricing procedure is altered such thatthe Gross value for Item entry isassigned to variable 1, which is storedpermanently in table VBAP (or VBRP)as KZWI1. The extract contain fieldsVBAP-KZWI1 through VBAP-KZWI6so the value is extracted to InfoObject0SUBTOT_1S. Similarly, the othervalues are stored as shown in Table 1.

Note! In this example, I haveassigned subtotals to only a fewrows of the pricing procedure. Thestandard system supports only sixsuch subtotal fields. Refer to SAPnote 155012 if you want to transfer more subtotal fields.

Limits to the WorkaroundThis workaround has a couple limita-tions. The condition values are correctlyupdated and stored in the table once therevised pricing procedure is in place.However, the workaround will notchange values for historical transactions.Table entries for historical transactionsare already stored, and the conditionvalues will not be recalculated.

If you are using the Sales InformationSystem (SIS), you also need to see ifthat information structure uses subtotalvalues. For example, information struc-ture S001 uses subtotal variable 1 andupdates the gross value of incomingorders. If you are making changes to anexisting assignment, make sure that itdoes not affect your SIS.

Rumor has it that SAP realizes theimportance of extracting pricing con-ditions. Watch the release notes to seeif and when the functionality becomesavailable. Until then, you’ll find thatmy workaround solution does thetrick!

Mitresh Kundalia heads the SAP practice division at Quality Systems & Software.QS&S helps companies achieve world-classperformance by realizing their latent businessand technological potential with an emphasis

Table 1 Condition values stored in tables VBAP and VBRP can be extracted to BW

Figure 5 The column Value display the sample condition values and is not part ofan actual pricing procedure

Figure 6 Pricing procedure with subtotal variables added to specific rows

Value Field name Value InfoObject

Gross value for Item KZWI1 115.00 0SUBTOT_1S

Net Value of Item KZWI2 102.00 0SUBTOT_2S

Net Value of Item 2 KZWI3 109.00 0SUBTOT_3S

Freight KZWI4 7.00 0SUBTOT_4S

Total Discounts KZWI5 -13.00 0SUBTOT_5S

on SAP systems. QS&S uses best practicesand industry-proven implementation tools tointegrate complex business processes withSAP systems. With an MBA degree in finance,Mitresh implements financial and logisticsapplications specializing in managementreporting, profitability analysis, informationsystems, and Business Information Warehouseapplications. He can be reached by email [email protected].

38

Document flows are sequences of docu-ments that make up a business transactionin ERP systems like R/3. They link docu-ments together and allow relevant data tobe copied from one document in the flowto another. When a delivery document iscreated, for example, the system copies therelevant information from a sales order.Document flows are crucial to the Salesand Distribution (SD) module.

With copy control, documents such as sales orders can be generated based on informa-tion in existing sales, delivery, and billing documents, which are the components ofsome of the most common document flows in SD. The copy control function also pro-vides the mechanics for performing other tasks such as checking what prerequisitesmust be met before any copying can take place.

Copy control settings are a flexible piece of the configuration that determine howinformation is moved from source to target documents in a document flow. Copycontrol’s role in this process is to manage all the copying required for subsequent doc-uments.

In this article, I will provide you with an overview of the copy control functionalityand the various flexible features it offers. My focus is primarily on the copy controlsettings for billing documents, but the concepts are similar for copying informationinto sales and delivery documents. I will also detail the role that source and target doc-ument types and pricing types play in the process as well as explain how ABAProutines control certain copying prerequisites.

SAP supply chain concepts, technology, and best practices

www.SCMExpertOnline.com

Jan./Feb. 2005 | Volume 3 | Issue 1

Your system has to manage a multitude of sales, delivery, and billing documents. R/3 offers apowerful piece of configuration that controls how the source documents are copied into target doc-uments in a document flow.

Copy Control Gives YouFlexibility to Manage Your SD Document Flow

by Mitresh Kundalia, Director – SAP Practice, Quality Systems & Software Inc.


Publisher of SAP Insider

From WIS, publisher of

9Cost Conditions in R/3Are You Sending YourFinancials Team anUnpleasant Surprise?

14 Customize SNP InteractivePlanning to Better DisplayCritical Conditions

19 Identify and Track Slow-Moving Items in BW

>>inside

In R/3, ccooppyy ccoonnttrrooll allows you tomove critical data from a sourcedocument to a target documentand plays a key role in creatingdocuments that make up a docu-ment flow.

Key Concept>>

39


For electronic licenses and group access, call 1-781-751-8799 3

Configure Copy ControlAs noted earlier, copy control manages thecreation of sales, delivery, and billing docu-ments in SD. Sales documents oftenreference other sales documents includingquotations, contracts, and sales orders,which can be created from invoice docu-ments. Billing documents can be createdwith references to delivery documents, salesdocuments, or other billing documents.Delivery documents are created using salesorders as their source.

Examples of the various copy controloptions for target and source documents aresummarized in Table 1. Customizing copycontrol functionality is done within SD orby entering the transaction codes listed inthe table.

Note the naming convention. Transactioncodes for copy controls begin with VT,the third letter represents the target docu-ment, and the fourth letter represents thesource document. Sale documents aredesignated with an A, an F is used forbilling documents, and an L is fordelivery documents.

Build a Basic BillOne basic application of the copy control function is to create a billing document. Billing documents are usuallygenerated after a sales order ships or anorder for a service item is completed.Using copy control, the billing documentdata is sourced from a sales order alongwith other documents, eliminating theneed to re-enter information. The systemautomatically copies pricing informationfrom the sales order to the billing docu-ment as well as the date, which is basedon the delivery document, and other relevant information from precedingdocuments in the document flow.

There are three scenarios for creating billingdocuments with copy control. Billing docu-ments can be created with references todelivery documents. If no delivery isinvolved such as for services-rendered con-

tracts, a billing document can be sourcedfrom a sales document. Billing documentscan also reference another billing document.The system can then generate an invoicecancellation document using the originalbilling document if it is cancelled. I willwalk you through each of these.

Unique copy control settings must be con-figured for each of the three billingscenarios and there are separate customiz-ing options for each. This is true for alldocuments created with the copy controlfunctionality. Copying prerequisites must beset if you wish to establish requirementsprior to transferring data. You also definehow data transfer takes place between thesource and target documents as well as howthe quantity and values are updated. Thesettings are maintained at the header- anditem-line level and, if required, at the sched-ule-line level for sales documents. The copycontrol for billing documents is configuredwithin SD Customizing>Billing>Billing

document>Maintain copying control forbilling documents.

Delivery Documents to BillingDocument TargetsEnter transaction VTFL to manage thecopy control functions for billing documenttargets with delivery document sources.Document types determine the copy con-trols. For this example, I have used a coupleof the most common document types. AnInvoice billing document is the F2 targetreferencing an LF Delivery documentsource (Figure 1).

January/February 2005 • www.SCMExpertOnline.com

Table 1

Figure 1

Target document Source document Transaction code

Sales document Sales document VTAA

Sales document Billing document VTAF

Delivery document Sales document VTLA

Billing document Delivery document VTFL

Billing document Sales document VTFA

Billing document Billing document VTFF

The principles used to createbilling documents are the samefor creating sales and deliverydocuments with copy control.

Note>>

40

4 © 2005 SCM Expert Reproduction prohibited. All rights reserved.

Double-clicking on the row moves you tothe header-level copy control configura-tion screen (Figure 2). The header-levelsettings determine the copying require-ments, export data, allocation number, andreference numbers.

The copying requirements are smallABAP routines that dictate what (if any)prerequisites exist for each documenttype. At the header level, for instance,these routines can be used to validate document headers before copying. In my example, information from the LFDelivery document type is copied tobilling document type F2, and the copyrequirements determine what data will beexported.

The 003 Header/Div-related settingrequires the system to check whether thereare any blocks on delivery headers and, ifso, prevents the information from beingcopied to the billing documents.

The Determ. export data field specifieshow the system determines export data.For example, when dealing with customersfrom countries where the economic orpolitical conditions are not stable, it oftenmakes sense to redetermine the export datain the billing document rather than simplyreferring or copying the export data fromthe delivery document.

The Allocation number is a user-definedfield on the billing document and account-ing document that can be used to provide

additional information. You can choose,for example, to enter the delivery numberon the billing document you are creating.Then, you don’t have to revert back to thedelivery document when viewing thebilling document. Allocation numberoptions are selected from a drop-downmenu (Figure 3) accessed by clicking onthe Allocation number field.

The reference number refers to a field inthe accounting document header. You candefine the Reference number field whencreating a billing document by choosingfrom a list of options offered in the field’sdrop-down menu (Figure 4). It allows youto provide additional information such asa vendor invoice number or a customer’scheck number.

In addition to the allocation and referencenumbers, you can copy item numbersfrom the delivery document source. Set aflag in the copy item numbers check boxand item numbers are copied to the billingdocument.

Item-Level SettingsIn addition to header-level settings, youmust also configure settings at the itemlevel and item-category level. Click onthe Item folder in the Dialog Structurefield (Figure 5). Setting the item-category level determines the copyingrequirements for an item as well as thedata transfer logic for invoice tables.

www.WISpubs.com

>> NoteCopying requirements are VOFM rou-tines and managed by transactionVOFM. The standard R/3 systemcomes with many copy requirementroutines and you can create yourown. See my article “VOFM RoutinesHelp Make Logistics Processes MoreVersatile,” published in November2004 for more details about VOFMroutines. Figure 2

41


These settings establish what quantity tobill and how pricing should be carried out.In this example, TAN populates the Itemcategory field.

Like in the header-level controls, theCopying requirements field at the itemlevel defines VOFM routines. The ABAPcode might be used to check for billing

blocks at the header level, and similarVOFM routines would check the item-level billing blocks at the item level. Inboth cases, the copy requirement routinesdetermine the prerequisites that must bemet before copying takes place.

The Data VBRK/VBRP field managesthe data transfer from a delivery to a

billing document. In the R/3 system,billing information is stored in tablesVBRK (billing header) and VBRP(billing item data). Data transfer ismanaged with VOFM routines andaccordingly, a routine number is definedin this field. In my example, I’ve showndata transfer routine 001, which is a stan-dard data transfer routine that determineshow the system splits the invoices.

For billing documents sourced from deliv-ery documents, the billing quantity can bedefined as the delivered quantity less thealready invoiced quantity when multipledeliveries and invoices exist. This is amathematical formula performed automat-ically by the system when the Billingquantity field is set to B.

No new pricing calculations should bedone at the time of billing. Prices shouldbe carried over from the sales order,where conditions such as discounts havebeen defined. Pricing types define howcondition types are determined and if theyneed to be recalculated or copied as is.Setting the Pricing type with a G valuecopies the pricing elements unchanged,but redetermines the taxes.

The Price source setting controls fromwhere and in what sequence the condi-tions from the reference documents arecopied to the billing document. Thevarious price source options are chosenfrom a drop-down menu (Figure 6) thatyou access by clicking on the Price


Figure 3

Figure 4

Figure 5

Figure 6

42


source field. Option E is used in thisexample, which determines the conditionsfrom a delivery.

Source Sales Documents toBilling Document TargetsThe document types in Figure 7 deter-mine the copy control for billingdocuments with reference to sales docu-ments. I’ll show you an example using anF2 target (Invoice) with an OR(Standard Order) source. These arecommon billing and sales document types.

Settings at the header level for sourcing asales document to a billing document(Figure 8) are similar to sourcing deliverydocuments, except for the copyingrequirements, which are order related inthis case rather than delivery related.

The item-level copy control settings areconfigured as shown in Figure 9. In thefirst example, I used the item categoryTAN, which includes a delivery compo-nent. In this example, I used item categoryTAD for services, because with a serviceyou invoice after an order and do not needto accommodate any delivery information.

For billing documents created from salesorders, the billing quantity is determinedbased on the order quantity. Set theBilling quantity field to A using thedrop-down menu. This calculates theorder quantity less the invoiced quantity.The definition for billing quantity A ispredefined in SD and does not need to bemaintained. The other fields in this screenincluding Copying requirements, DataVBRK/VBRP, and Pricing type aremaintained as they were in the earlierexample.

Billing Document from aBilling Document SourceIf you need to cancel a billing documentin SD, R/3 does not delete it from thesystem. Instead, it creates another billingdocument with equal but opposite

www.WISpubs.com

Figure 7

Header-level copy control settings for sourcing a sales order document to aninvoice target

Figure 8

Figure 9

43


should be made. The Pricing type isalways set to D, which dictates that thecopy pricing elements are copiedunchanged.

Billing Document SummaryYou can see that the copy control func-tion is a critical piece for customizing inSD. Table 2 on the next page offers asummary of the settings I used for tar-geting data to billing documents.Understanding the influence each ofthese settings has on how and what dataflows from source documents to targetdocuments will provide you with a clearpicture of what is possible using copycontrol. Remember that these settings aresome of the more common options


amounts and assigns a different billingtype, an invoice cancellation. For thesecases, the copy control allows you tocreate a billing document based onanother billing document.

The Invoice Cancellation target header-level settings shown in Figure 10 use anoriginal billing document as a source. Theheader-level settings are similar to theitem-category level settings shown inFigure 11. Most of the settings performthe same functions discussed in the priorexamples. You should be aware of acouple of exceptions, however.

When creating an invoice cancellationfrom a billing document, the pricing ele-ments should be copied exactly as theywere in the source document. No changes

Header-level settings for a billing document target with a billing documentsource

Figure 10

Item-category level settings for sourcing a billing documents to a targetbilling document

Figure 11

>> Tip!If you define your own custom docu-ment types, e.g., sales documenttypes or item categories, it is advis-able to copy from existing elements so that the system auto-matically copies all the relevantcustomization settings. Alwaysdouble-check the copy control set-tings for your customized items.

44


employed in SD and they can be cus-tomized significantly.

Similar to creating billing documents, as Inoted earlier, copy control settings alsowork for sales documents and deliverydocuments. For predefined sales anddelivery document types, configurationsettings are already maintained in thestandard system. If you want to change ormodify the settings, instead of modifyingthe standard settings, you may createanother Z set of document types for yourcustom needs.

For information on this author, see hisbiography on page 13.

www.WISpubs.com

Table 2

Delivery document to billing document

Sales orderto billing document

Billing documentto billing document

Select document-typeconfigurations

LF source to F2target

OR source to F2target

F2 source to S1target

Header level

Copying requirements

003 — Header(Delivery related)

001 — Header (Orderrelated)

005 — Header(Cancellation)

Allocation number C — Delivery number N/A N/A

Reference number E — Current billingdocument number

E — Current billingdocument number N/A

Copy item numbers Yes Yes Yes

Item level

Item category TAN — Standard item TAD — Service item TAN — Standard item

Copying requirements

004 — Delivery-related item

002 — Item/order-related item

006 — Cancellationitem

Data VBRK/VBRP 001 — Invoice split 001 — Invoice split N/A

Billing quantityB — Delivered quan-tity, less invoicedquantity

A — Ordered quantity,less invoiced quantity N/A

Pricing typeG — Copy pricing ele-ments unchanged,but redetermine taxes

G — Copy pricing ele-ments unchanged,but redetermine taxes

D — Copy pricing ele-ments unchanged

Price source E — Delivery/order

This article appeared in the July 2004 issue of SCM Expert, a newsletter from the publishers of SAP Professional Journal and SAP Insider, and is reprinted with their permission. To subscribe, or for additional information, visit www.scmexpertonline.com.

45


June 2003 • www.FICOExpertOnline.com

What’s an “Assignment Number,” and How a Misunderstanding Can Giveyour End Users an Unfriendly Surpriseby Mitresh Kundalia, SAP Practice Manager, Quality Systems & Software

In the FI module, “assignment number,” previously known as“allocation number,” refers to an additional reference field onthe Accounting Line Item screen. It is primarily used to sortaccounting transactions by default. Figure 1 shows account-ing transactions default-sorted by their posting dates.

So what is the big deal about using an extra field to sort lineitems? The answer is that a default sort allows you to sortaccounts by different criteria, such as expense accounts bycost center and assets accounts by asset number.

The role of the default sort is sometimes confusing, and there-fore it is underused in the FI module. The first source ofconfusion stems from terminology, which I can easily clear up.(See the sidebar, “Terminology Adds to the Confusion.”)

The second source of potential confusion here, which is notwell-documented in SAP self-help materials, is somethingthat most of us have wondered about, and is what I want tofocus the remainder of this article on. This is the question ofwhat to do when we have not one, but two, places in thesystem offered to us to set up the default. The classicexample is a customer or vendor master, each of which mustlink to a G/L reconciliation account. The customer or vendoraccount number has a sort key setting in its master. And, thelinked G/L account number has a second (and separate) sortkey setting in its (G/L) master!

Note! The screenprints shown in this article are from IDES Release 4.6, and therefore in most cases they showthe reference column as Assignment. In earlier releases,you see it as Allocation. From this point on, I will use theterm “assignment number” to avoid confusion when youare looking at the screenprints.

Although this gives you the ability to sort customer line itemswith one kind of default and the corresponding line items ofthe G/L account with a second kind of default, it can lead toan unpleasant surprise for the end users analyzing this data.

Figure 1 Display account line items (transaction code FBL3 or FBL3N) automatically sorts the line items by the assignment field

Figure 2 System uses assignment field as default sort criteria

Let’s look more closely at that. But first, I’d like to touch ontwo basics to make sure there is no confusion about anassignment number vs. a sort key.

46



What Is an AssignmentNumber?The assignment number is a freelydefinable field of up to 18 characterspopulated on the account line item (technically BSEG-ZUONR), as shownin Figure 2.

You can enter the assignment numbermanually, or you can design youraccounts in such a way that the assign-ment field is automatically filled. Thisis done by configuring so-called sortkeys and linking these sort keys to theaccount numbers. If you configure thesystem to fill them in automatically, itcan take details from the documentheader table (BKPF) or from the line

Figure 3 Standard sort key 001 defined as posting date (BUDAT). Note that the process is referred to by the former term of “allocation” on this screen.

Terminology Adds to the Confusion

Often SAP uses the same term quitedifferently in different modules. Onesuch term is “allocation,” which has adifferent meaning depending on whatyou are referring to.

In the Controlling (CO) module,“allocation” is a term used for trans-ferring (i.e., allocating) costs fromone cost center to another. SAP pro-vides two types of allocation methodsin CO—distribution and assessment.

Allocation in FI has nothing to dowith allocating costs in CO. The allo-cation number in FI is an additionalreference field on the line item of anaccounting document.

Realizing the potential confusion ofword “allocation number” in the FImodule, SAP, starting with Release4.6, calls it “assignment number.”However, the change is not well doc-umented, and many in the SAPfinancial community still refer to it as“allocation number.”

Figure 4 Sort key assigned to the account number at the company-code level

item table (BSEG) and put in an assignment number field.

Sort Keys for G/L AccountsYou configure sort keys by transactioncode OB16 (IMG menu path FinancialAccounting>General LedgerAccounting>G/L Accounts>LineItems>Line Item Display>DetermineStandard Sorting for Line Items, asshown in Figure 3. The assignment

number can be poppulated from thecontents of up to four fields. Note thatthis transaction is client-independent,meaning these sort keys are valid for allclients. Technically, these sort keys arestored in table TZUN.

Once configured, sort keys can be linkedto account master records (transactioncode FS02) as shown in Figure 4. Theadvantage of linking to the accountnumber is that whenever you post to

47



the account number, R/3 automaticallyfills the assignment number field in theaccounting document line item. Refer to Table 1for tips for defining sort keys.

In this case, whenever you post toaccount 800000, the assignmentnumber on the accounting line item isfilled with the value of the posting date.Accordingly, the display account lineitems transaction automatically sortsline items by the posting dates asshown in Figure 1.

Sort Keys for Customer orVendor AccountsSimilar to G/L accounts, you can set thesort keys for customer and vendormaster accounts, too. You can use thesame sort keys (transaction code OB16)for customer or vendor accounts, andthe same concept for displaying cus-tomer (or vendor) line items.

Here’s where the possibility for confu-sion develops. When you display lineitems of the reconciliation account, R/3displays the line items sorted by theG/L account’s sort key. However, whenyou double-click on the G/L line item,you see a different assignment number.

Let me show you with an example.Let’s say G/L account 196900 is a reconciliation account of type D (forcustomers) and it has a sort key, 026 -Payment baseline Date. The correspon-ding customer, 3474, has a sort key,035 - Rental agreement. When youdisplay G/L account lines for account196900, you see line items sorted bythe payment baseline date as shown inFigure 5.

Note that the assignment number of thefirst line is 19990201, which is thepayment baseline date value. Nowdouble-click on the first line and you

The standard R/3 system has a sort key 014 – Purchase Order (technically a combina-tion of the purchase order number and the item number). The R/3 system uses sort key 014 to automatically clear goods receipts/invoice receipts (GR/IR) accounts. Themain purpose of 014 is to clear GR/IR accounts. If you don’t set it that way, the GR/IRaccount does not clear automatically.

It is a good idea to set a sort key for expense accounts as 008 – Cost Center, so thatyou can obtain expense totals by cost center.

For bank accounts and check collection accounts, you typically would like to getaccount balances sorted by value date. The standard system has sort key 027 - Valuedate for this purpose. You could also use sort key 003 – Document Date, so that transactions are sorted by document date.

For employee accounts, you should keep sort key 015 – Personnel Number, so that you can use the employee number to sort account transactions.

To sort assets transactions by asset number and sub-number, set the sort key as 018 – Asset Number.

If you are using one-time customers or vendors in your business, you can use sort key022 – Name and City, for sorting account items by customer (or vendor) name and city.

If you want to display purchase price variance (PPV) account transactions sorted bypart or material number, you could define your own sort key for material numbers.Create a sort key (transaction code OB16) with technical field MATNR and assign it toPPV accounts via transaction code FS02.

Table 1 Tips for sort key use

Figure 5 Line items of reconciliation account sorted by assignment number of the G/L account (BSIS-ZUONR)

48



see a different assignment number(BSEG-ZUONR). What is populated isa rental agreement number, rather thanthe payment baseline date. Click onMore data and you see that the assign-ment number field for the G/L accountis saved under a separate field, Sp.G/L assigt (BSEG-HZUON), as shownin Figure 6.

In effect, there are two separate fieldsto store assignment numbers, one forthe reconciliation account and one forthe customer (or vendor) account. Thisis because the customer’s sort key populated the assignment number onthe accounting segment’s line item(BSEG-ZUONR). Refer to flow-chartin Figure 7 to clarify how the assign-ment number is populated.

Therefore, when you displayed the lineitems of Reconciliation Account 196900as shown in Figure 5, the system dis-plays line items from the BSIS (G/Lline items) and BSAS (G/L cleareditems) table. It accordingly showedassignment number BSIS-ZUONR,which was populated from G/Laccount’s sort key. When you double-clicked on the accounting document,the system showed assignment numberBSEG-ZUONR, which was populatedfrom customer account’s sort key.

Mitresh Kundalia is a FI/CO consultantwith more than six years of SAP consultingexperience. With an MBA degree infinance, Mitresh concentrates on theFinancial and Controlling modules withemphasis on Profitability Analysis, CostCenter Accounting, General Ledger, sub-ledgers, and Special Ledger. He also has experience with InformationConsolidations, SIS, and BusinessWarehouse. He can be reached by e-mail at [email protected].

Figure 6 Assignment numbers of the customer master record (BSEG-ZUONR) and corresponding reconciliation account (BSET-HZUON)

BSEG-HZUON

BSEG-ZUONR

Figure 7 Rules for populating assignment numbers for G/L reconciliation accountsand customer (vendor) accounts

49


July/August 2003 • www.FICOExpertOnline.com

Fast Data Conversion, Migration,and Updates for Functional Analystswith LSMWby Mitresh Kundalia, Quality Systems & Software

Data conversion is no longer a one-timeactivity. Gone are the days when it wasrequired only during an initial SAPimplementation project. Here are someday-to-day business scenarios when youmay be called upon to convert data:

• Mass updating cost centers to betterreflect a new organizational structure

• Uploading initial account balancesfor a newly merged company

• Uploading open invoices for cus-tomers or vendors

• Updating customer or vendor recordsfor specific fields

Let’s take the last example, the commonbusiness requirement of updating a fewfields of the customer master records.You could use Mass Maintenance to domass updates, or as an alternative, youcould use CATT (Computer Aided TestTool). Both would work for somesimple scenarios, but they may not be asuseful for other situations. For example,Mass Maintenance cannot be used fortransaction-based recordings, and CATTis more suitable for testing transactions.

For any slightly complex data-massagingrequirement, you probably end upcalling on your technical team todevelop a customized ABAP program.The problem is that ABAP developmentis a time-consuming process. Forcomplex programming, that is fine.However, when you want to perform asimple and fairly straightforward updateor conversion, ABAP development is

overkill, especially if this is a one-timerequirement. I know of many sites withnumerous ABAP programs that they arenot using anymore.

As a functional analyst, you may havewished that you could quickly updatecustomer master records from an Excelsheet, or that you could quickly converta customer’s open invoices. If so, Isuggest you consider LSMW (LegacySystem Migration Workbench). Youcan download it free-of-charge fromthe SAP service marketplace(http://service.sap.com/LSMW).

Many people in the SAP communityare not aware of LSMW. The reason isthat it is not part of a standard system,although it is supported by SAP. I’lldescribe its features, and then, with ashort demo, I’ll show you how to use it.

Here are some of LSMW’s features:

• LSMW does not require any ABAPknowledge. For most of the typicalconversion and migration tasks, youcan use standard R/3 programs withbuilt-in conversion routines.

• LSMW handles various requirementsfrom simple mapping rules to com-plex data massaging rules. Since it isbased on standard R/3 posting princi-ples, data consistency is guaranteed.All typical checks are done before thedata is posted.

• Although you can use LSMW fordata migration from a legacy system,it also can be used for many data

massaging tasks within R/3 duringthe production support phase.

• LSMW uses existing standard R/3conversion interface programs.Standard programs are already avail-able for many objects such as com-monly used master data (G/L accountmaster, customer master) or transac-tion data (financial documents,invoices). You can use either thebatch input or the direct input methodfor data conversion. Another typicalrequirement is updating the recordsbased on transaction recording. UsingLSMW, you can record your owntransaction, making it much easier foryou to update only the relevant fields.

• If you are using the standard R/3interface program, you are accus-tomed to creating a text file with mul-tiple structures.1 With LSMW, thismulti-layout file is created automati-cally from a structured data sheet.

• LSMW’s wizard-like feature is simi-lar to step-by-step instructions.

Figure 1 shows how LSMW works.The legacy data is already available in a specific file format on a PC orapplication server. The Read programof LSMW reads the legacy system data.

1 For example, for customer masters programRFBIDE00, you used to create a text file withsession details (structure BGR00 with recordtype 0), header data (structure BKN00 withrecord type 1), and general information (structure BKNA1 with record type 2).

50



The Convert program converts thislegacy data into an R/3-specific format.During conversion, you have the optionof using various conversion rules tomap data from one format to another.These conversion rules are reusable forother conversion tasks. Once the data isconverted into an internal R/3 format,LSMW can use standard R/3 programs(batch input, direct input, or BAPIs) toupload the data to R/3.

In brief, you do the following four tasksto migrate data from a source system toa target system:

Task 1: Define the targets; Define busi-ness objects (e.g., material master, FIdocuments); Define the import method(batch input, direct input, or IDocs).

Task 2: Define the source structures;Define how the source file is structured;Define the file layouts and attributes;Define the relation between the sourcestructure and the target structure.

Task 3: Define the conversion rules;How the source fields are mapped totarget fields; Re-usable conversion rulesacross multiple conversion tasks.

Task 4: Import data; Import data toR/3 system.

Now, I’ll illustrate these tasks with abrief example. For a step-by-stepdemo of this example, go towww.FICOExpertonline.com/downloads.

Demo: Using LSMW to UpdateCustomer Master RecordsLet’s say that as a part of restructuringin your company, some of your cus-tomers are reorganized under a separategrouping. You need to change the salesoffice, sales group, and customer groupfields of these specific customer masterrecords.

Without LSMW, you would have tomanually change these fields from customer master records with transac-tion code XD02. You would have tochange all the customer master recordsseparately—enter transaction codeXD02, enter the key information,click on sales view, and update theappropriate fields. This method is cumbersome and prone to errors.LSMW allows you to record transac-tions so that you can update specificfields for specific screens.

Note! The screenprints in this articleare from IDES Release 4.6. Theymay differ slightly in other versions.

Calling LSMWYou call LSMW by executing transac-tion code LSMW. All conversions are grouped together under a Project/Subproject/Object structure. Groupingtogether conversions within Projectand Subproject makes it easier for you to maintain and retrieve your ownconversion objects. For example, fordemonstration purposes, I’m creatinga Project called LSMW_DEMO and aSubproject called CUSTOMERS forall different customer updates—suchas transaction recording (CUST_REC).(See Figure 2.)

The main screen of LSMW provideswizard-like step-by-step tasks, as

Figure 1 Process for converting legacy data with LSMW

Figure 2 Migration Object with Project and Subproject

51



shown in Figure 3. To complete yourdata conversion, you need to executethese steps in sequence. Note that thesesteps may look different depending onyour Personal menu settings.

Task 1: Maintain Object AttributesThe first task is to define the targetsand attributes—what object you aregoing to update and how. LSMW offersvarious import techniques: batch ordirect input for standard pre-definedobjects, transaction recording forupdates of specific fields of screens,BAPIs, and IDocs. (See Figure 4.)

In this demo example, you’ll be updatingcustomer master records with the helpof recording transaction XD02. Chooseradio button Batch Input Recordingand click on the recording overviewicon to record the R/3 transaction.

Enter the recording name asXD02_REC, the description asCustomer Master UpdatesRecording, and the transaction codeas XD02. Once you click on theoverview icon, you see a small screenwhere you enter this information.

The system calls the transaction codeXD02 and prompts you to complete theChange Customer transaction. Enter thekey customer information (CustomerAccount Number 1000, Sales organiza-tion 1000, Distribution channel 01, andDivision 00), make changes to thesethree fields (Sales office 1010, Salesgroup 110, and Customer group 01),and save the transaction. Once thetransaction is complete, R/3 records theflow of screens and fields and saves theinformation, as shown in Figure 5.

Note that the fields are populated withdefault values that were set when yourecorded the transaction.

The transaction-recording processstores field names in a technical format.

Figure 3 LSMW Wizard — initial screen

Figure 4 Define targets and maintain object attributes

Figure 5 Transaction recording overview

Default Values

Field Names

52



If you press the F1 key on individualscreen fields and then press the F9 key,the system displays technical names.You can then replace the technicalnames with descriptive names. Double-click on the field RF02D-KUNNR,enter the name as KUNNR and thedescription as Customer AccountNumber, and remove default value.Double-click on all other fields withdefault values and make appropriatechanges. Once you have made changes,the recording overview screen lookslike what you see in Figure 6.

The objective of the first task was todefine the target and its attributes. Inthis case, the transaction recordingXD02_REC is the conversion task, and fields in XD02_REC become thetarget structure.

Save your changes. When you go back tothe initial screen, you see that the initialscreen steps have changed. Since youwant to import data via the BDC method,the Direct Input and IDoc-related stepsare hidden, as they are not relevant.

Task 2: Define Source StructuresYou need to designate what fields arepassed from the source system so thatappropriate field values are passed tothe target structures. Accordingly, youdefine the source structures and whatfields are within the source structure.Source data may be in a single structureor in multiple structures with a “header-detail” relationship. Each sourcestructure consists of source fields.

The first step is to create a source struc-ture, which I’ll call XD02S. Give ameaningful description, in this caseSource structure for XD02S. Maintainsource fields for the source structure byentering Type, Length, and FieldDescription, as shown in Figure 7.

Figure 6 Transaction recording overview — with screen field attributes

Tip! If you have a date field and the

batch input session is unable to

interpret date value, you can make

the date field a characteristic field

(Type C), and then enter date values

in the input file according to individ-

ual user defaults.

Once the source structures are createdand the source fields are maintained,relationships between the target struc-tures and the source structures are cre-ated. In this demo example, since thereis only one source and one target struc-ture, the relationship is automaticallydefaulted by the system.

Task 3: Define Conversion RulesThe next task is to define how a fieldfrom a source structure is mapped to afield in the target structure.

LSMW offers various predefined con-version rules, which you can re-useacross different LSMW objects. One ofthe most common requirements is toderive target values based on sourcevalues. For example, say that in an R/3 system, a field can have only A, B,

or C as a value, whereas the sourcesystem has 1, 2, or 3 values only. Youcreate a translation rule so that targetvalues are derived from the source fieldvalues, as shown in Figure 8.

Next, you maintain field mapping foreach of the target fields. If your sourcefile provides the field, simply map thesource field to the target field by click-ing the source field icon. The systemuses the conversion rule Transfer(MOVE) to move the source value tothe target field.

Map all the target fields to source fields(Figure 9). Note that for the RF02D-D0310 field, the default should be setto X. Use the Constant rule icon tochoose the constant value of X forfield RF02D-D0310.

Figure 7 Source fields of source structure

53



You can also maintain re-usable trans-lations and user-defined routines,which can be used across conversiontasks. For example, you could create are-usable conversion routine to trans-late the material number, which canbe used in many such LSMW conver-sion tasks. Once mapping is defined,specify the location and names of thefiles that contain the source data.Maintain attributes of the file—whether the input file is delimited orwhether the input file has columnheadings. (See Figure 10.) Then,assign file names to source structures.

Figure 9 Field mapping and conversion rules

Bach input session. Confirm that thecustomer master records are updatedby viewing the customer masterrecords (XD03).

SummaryAs an alternative to this example, youcould use the standard SAP object 0050 – Customer Master, which would use a predefined R/3 interfaceprogram (RFBIDE00 – Batch InputInterface for Customers) to update data. Some standard objects offerdirect input updates, which are muchfaster than batch input updates. Referto www.ficoexpertonline.com/down-loads to review step-by-stepinstructions for that example.

Mitresh Kundalia is a FI/CO consultant

with over six years of SAP Consulting

experience. With an MBA degree in

finance, Mitresh concentrates on the

Financial and Controlling modules with

emphasis on Profitability Analysis, Cost

Center Accounting, General Ledger, sub-

ledgers, and Special Ledger. He also has

experience with Information

Consolidations, SIS, and Business

Warehouse. He can be reached by email

at [email protected].

Figure 10 Maintain file attributes

Task 4: Import DataAt this stage, the major activities aredone and you are ready to update thecustomer master records, which in myexample are in an Excel file. Prepare atab-delimited Excel file on your C:\drive, with these columns: CustomerAccount Number, Sales organization,Distribution channel, Division, Salesoffice, Sales group, and Customergroup.

Go back to the initial LSMW screenshown in Figure 3 and follow thesteps from Read data through Run

Figure 8 Various conversion rules available in LSMW and sample rules

54


February 2003 • www.ficoexpertonline.com

Find the Hidden Condition Technique in CO-PA and Fine-TuneYour Profitability Analysisby Mitresh Kundalia, SAP Practice Manager, Quality Systems & Software

Have you ever wished that the CO-PAmodule had a condition technique?Guess what? It does, but in CO-PA, it is called “valuation with costingsheet.”

The condition technique has the flexi-bility to meet specific requirementsfrom basic addition to more complexcalculations. FI and CO-PA analystscan use the condition technique to sup-plement information in the CO-PAledger with estimated, calculated, andadditional values. This leads to moreaccurate profitability analysis, andthus, to a more accurate decision-making process. It is not as easy toachieve the same goal with any other

accounting tool, as other tools are basedon actual transactions.

This accounting tool will help you perform profitability analysis on trans-actions before they occur. Say, forexample, that you want to perform aninterim margin analysis for an incomingsales booking. It can help calculate estimated values, such as:

• Commission payable to sales force

• Freight costs for shipments

• Cash discounts payable to customersfor early payments

• Outgoing packaging based on numberof parts sold

• Custom duty payable for cross-border shipments

• Reserves or administration over-heads in insurance companies

A commonly misunderstood notionabout condition technique is that it isused primarily in the Sales andDistribution (SD) module. The mis-leading term for condition technique in CO-PA, “valuation with costingsheet,” adds to the confusion. As aresult, it has remained underused inmany R/3 installations. (Refer to Table1 for commonly used terms within theSD and CO-PA modules.)

I will clarify those issues and demon-strate how to implement the conditiontechnique in the CO-PA module. Witha screenprint and table, I’ll also clarifyhow the condition type is assigned tothe value field, a point of confusion ifyou don’t understand the underlyingrelationship.

Estimating a SalesCommissionHere’s a quick example of how to usethe condition technique to determinethe commission payable to salesemployees based on revenues gener-ated by an incoming sales order.Normally this would be calculatedwhen the order is invoiced. Look at

SD module CO-PA module

Commonly known as condition Condition technique is called valuation

technique. with costing sheet.

Transaction code V/06 creates Transaction code KE47 creates condition

condition types. Technically, stored types. Although technically stored in the

in table T685. same table, T685, these are identified by a

separate field application (KAPPL) as KE.

Transaction code KE4I assigns SD Transaction code KE45 assigns CO-PA

conditions to CO-PA value fields. condition to CO-PA value fields.

Condition types assignment is one-way. Condition type assignment can be

SD conditions are assigned to CO-PA bi-directional: you can assign

value fields. -CO-PA value fields to base conditions and

-Calculation conditions to CO-PA value fields

Table 1 Comparison of commonly used terms within SD and CO-PA module

55



Table 2. You calculate sales commis-sions based on a percentage of theProfit Margin (row 920) and store themin CO-PA value fields as supplementalinformation.

Condition Technique in CO-PAThis article assumes a basic understand-ing of how the condition techniqueworks and how the R/3 system findscondition records to calculate conditionvalues. (See Figure 1.) What follows isa review of how to develop the condi-tion technique in CO-PA.

1. Configure a valuation strategy basedon the costing sheet and assigned to thepoint of valuation with a record type.

2. In CO-PA, amounts are stored invalue fields. However, the costing sheetworks on condition types. Therefore,you need to have condition types withinCO-PA, which in turn have valuesassigned from these value fields.Determine the sales commission basedon the profit margin, which is derivedfrom value fields VV010, VV020, andVV030. In simple terms:

sales commission = percentage of profit margin,

where profit margin = (VV010 - VV020 - VV030)

Figure 1 Basics of condition technique. Typically, access sequences are assigned to condition types. The access sequence is a search strategy that defines how to search for specific records, and it consists of accesses and condition tables.

To do this, create three condition typesrepresenting these three value fields;these are called “base condition types.”Since the values of these conditions areassigned directly from value fields, youdo not need access sequences. Createan additional condition type to deter-mine the sales commission amount; thisis called a “calculation condition type.”Since the value of the commissiondepends upon various factors, you need

an access sequence, which in turn hasaccesses and condition records.

3. Once the value of the sales commis-sion is calculated in the costing sheet,store it in a separate value field byassigning a condition type to a separatevalue field. Note that the assignment isbidirectional—value fields are assignedto condition types, and condition typesare assigned to value fields. That is

Step Ctype Description Fr To Stat Sub To AltCType Acc Key COPA Value Field DescValue Field

10 PR00 Base price ERL VV010 Revenues

20 PR01 Price adjustments ERL VV010 Revenues

100 * Gross value 1

110 K005 Customer/material ERS VV020 Discountsdiscount

120 K007 Special price disc ERS VV020 Discounts

200 * Total discount 101 199

800 * Net value 2

910 VPRS Internal costs X B VV030 Cost of Goods

920 * Profit margin 11

Table 2 Relevant columns of a typical pricing procedure and assignment to value fields in CO-PA ledger, with asterisks added to make the distinction clearer

56



unlike SD, where conditions aremapped to CO-PA value fields. Youcannot assign CO-PA value fields to SD condition types.

I have explained this solution in a “top-down” manner. However, while config-uring, you follow “bottom-up” steps,which are explained in detail in the fol-lowing six steps. For example, youneed to include condition types in acosting sheet, so first you must createcondition types. You may need to createaccess sequence before condition types,as you might need to assign it in condi-tion types.

Configuration StepsThe configuration steps in CO-PA relat-ed to the valuation with costing sheet areshown in Figure 2. The screen prints inthis article are from Release 4.5B.

The configuration steps in CO-PA relat-ed to condition types differ from thosein SD pricing. For example, the CreateCondition Types step is available inSD pricing also. In SD, the transactioncode is V/06, and in CO-PA it is KE47.1

This is another possible cause of confusion.

Step 1. Define Condition Table (KE4A)Create a condition table and specify anumber between 501 and 999 (giveonly the number). Skip this step if youhave already created the required con-dition tables. Choose the required fieldsby double-clicking fields from theField catalog. The selected fields arelisted under the Selected Fields col-umn. Now generate the table. This

prompts R/3 to create a transparenttable that is activated. I created twocondition tables, Table 991 with Salesorg./Material and Sales org. fields,and Table 992 with only the Sales Org.field.

Step 2. Define Access Sequences(KE48)Create access sequence ZCOM(Access Seq for Commission). Choosethis access sequence and click onAccesses. Click on New Entries andenter two lines with the details on SalesOrg./Material and Sales Org. shownin Figure 3.

Note the Exclusive indicator on thefirst line of Figure 3. If you set it, thesystem stops searching if it finds therecord in the condition table.Otherwise, if the system finds onemore set of records, it adds twice. Itmakes sense to arrange accesses froma more-specific to less-specific order.

Step 3. Create Condition Types(KE47)In this example, you create four con-dition types for storing value fieldsfrom CO-PA. Although information isalready available in CO-PA in termsof value fields VV010, VV020, and

Figure 3 Accesses for Access Sequence ZCOM

1 Condition types from both these modules are stored in the same table T685 (T685 –Conditions: Types; T685A – Conditions:Types: Additional Price Element Data). In thistable, however, these condition types are dif-ferentiated with a separate field for application(KAPPL): “V” for SD and “KE” for PA.

Figure 2 Configuration steps for valuation in CO-PA

57



VV030, you need to assign these tocondition types ZREV, ZDIS, andZCOS so that costing sheet calcula-tions take place.

Since values for ZREV, ZDIS, andZCOS are already calculated, youdon’t need to assign access sequencesto them. The amount of discounts orcosts is stored as positive2 in valuefields. However, in costing sheet cal-culations, you subtract them by set-ting the Plus/minus indicator as X,which indicates minus sign only. SeeFigure 4.

Table 3 shows four condition typesand the relevant control settings. Onlythe ZCOM condition has an accesssequence. The remaining three,known as base conditions, do not,because their values are assigneddirectly by the value fields.

Step 4. Maintain Costing Sheets(KE46)Create a costing sheet (Figure 5).Step 40 is a subtotal for steps 10through 30. Although it looks like

CType Name Access Sequence Condition Category Calculation Type Class Plus/Minus

ZREV Revenues K B B

ZDIS Discounts K B B X

ZCOS Cost of Goods K B B X

ZCOM * Sales Commission ZCOM A B

Table 3 Condition types and control settings in CO-PA

Condition category: K (base amount excluding tax)Calculation type: B (fixed amount) A (percentage)Calculation class: B (prices)

Figure 5 Costing sheet

Figure 4 Access sequence for cost of goods, with Plus/minus box checked

2 If you checked the transfer +/- indicator in SD condition type assignment to CO-PAvalue fields (transaction code KE4I),amounts may be stored with negative/positivevalues. In that case, you do not need to setthe condition type in PA with minus signs.

58



Figure 6 Assign conditions to CO-PA value fields

Figure 7 Bidirectional assignment of condition types

addition, Step 40 is actually ZREVminus ZDIS minus ZCOS, because youdesignated condition types ZDIS andZCOS as “minus.” ZCOM should bebased on the subtotal; therefore, setFrom as 40.

Step 5. Assign Value Fields (KE45)Note that the assignment of the condition type to the value field worksboth ways. This is one of the most com-monly misunderstood relationships.Looking at the configuration screen(transaction code KE45), which isshown in Figure 6, you might thinkcondition types are assigned to valuefields. In reality, the assignment is bidi-rectional. To make this point clearer, Ihave depicted the bidirectional mappingin Figure 7. CO-PA value fields areassigned to base condition types(ZREV, ZDIS, ZCOS) in the costingsheet, and the calculation conditiontype (ZCOM) from the costing sheet isassigned back to the CO-PA value field.

Step 6. Define and Assign ValuationStrategy (KE4U)After the building blocks are config-ured, create a valuation strategy: Z01 –Invoice Valuation for Commission(Figure 8). Click on Details and setZCOMMS as the costing sheet withapplication KE and Qty Field for theOperating concern. Assign Val. Strat.as Z01 for real-time for invoices. Setthe PV (point of valuation) to 01,which indicates real-time valuation ofactual data, with Rec. (record type) F(for billing data).

Test ScenarioOnce these configuration steps are com-pleted, test how valuation with costingsheet calculates sales commission in Figure 8 Creating a valuation strategy

59



Tip! I’ll show you a way to test valua-tion and analyze details withoutactually creating an invoice docu-ment. Use transaction code KKEE2211(Create Line Item) to post a CO-PAdocument with record type FF. Enterthe sales organization as 11000000 andthe product as PPCC-110000. Enter theappropriate values in other fields.Enter revenue, discount, and costamounts on the VVaalluuee ffiieellddss screen.

Click on the valuation icon. The system automatically executes valuation and calculates the salescommission amount, which is storedin one of the value fields. The rev-enue, discount, and cost value fieldsare grayed out.

In addition, the Analyze Valuationfunction (AAnnaallyyzzee>>AAnnaallyyzzee VVaalluuaattiioonn)gives you a detailed analysis of thevaluation calculations, including

CO-PA. Create a few Create ConditionRecords for condition ZCOM (menupath Accounting>Controlling>Profitability Analysis>Master Data>Conditions>Create) or transactioncode KE41. See Figure 9.

Create one record each for Salesorg./Material and Sales org.

Access Table 901:

Sales org. Material Rate

1000 PC-100 3.00 %

Access Table 902:

Sales org. Rate

1000 2.00 %

When you post an invoice to CO-PA,observe that the corresponding valuefield VV100 is populated. This value

field is populated in the CO-PA ledgeras additional information.

This exercise was simple to demonstratehow the condition technique works inCO-PA. By now, you are probablythinking of many more useful possibili-ties, such as calculating potential earlypayment discounts, calculating salespromotion discounts, or calculatingestimated freight values.

Figure 9 Create Condition Records for Key Combination

Mitresh Kundalia is a FI/CO consultant withover six years of SAP consulting experience.With an MBA degree in finance, Mitreshconcentrates on Financial and ControllingModules with emphasis on ProfitabilityAnalysis, Cost Center Accounting, GeneralLedger, sub-ledgers, and Special Ledger. He also has experience with InformationConsolidations, SIS, and BusinessInformation Warehouse. He can be reachedby e-mail at [email protected].

CO-PA Valuation Analysis

details about costing sheet calculations.In the SD module, you are able to docondition analysis for pricing with theAnalysis function. (See the figure above.)

This way, you are able to understandhow the system calculates valuation.

You can play around in your develop-ment box (or sandbox) posting differ-ent CO-PA line items (transaction codeKE21) with varied sales organizationand material numbers to see how thevaluation results differ.

60


March 2003 • www.FICOExpertOnline.com

What You Should Know About the SD Higher-Level Item Category’sInfluence on Financial Reportsby Mitresh Kundalia, SAP Practice Manager, Quality Systems & Software

The “higher-” and “lower-level” itemcategory relationships in a sales orderare among the most commonly misun-derstood settings in R/3. You mightthink that the item category (see thesidebar, “SD Item Category”) of a salesdocument is purely a Sales andDistribution (SD) function. It’s true thatit primarily controls how the sales itemis processed within SD. However, someof the settings have a significant influ-ence on the FI module.

If you take the steps required to acti-vate higher vs. lower relationships in asales order, you also create the possibil-ity for two different approaches to grossmargin analysis in CO-PA. This allowsyou to bring profit values into CO-PAin two ways — the revenues and costsof the finished good or the revenuesand costs of each of the components ofthe finished product.

In simple terms, the lower-level item(or sub-item) is assigned to the higher-level item (or main item) to form ahierarchy structure. Accordingly, itemcategories are assigned for both theitems: higher-level item category forthe main item and lower-level item cat-egory for the sub-item.

The reasons to create such relationshipsinclude:

• Product substitution: During sales-order processing, material determina-tion enables the automatic substitu-tion of materials in a sales order. Forexample, during a holiday promotion,

you want to send a product with aspecial wrapper. When the customerorders the product, the R/3 systemsubstitutes the special product. Youcreate the special product with thewrapper as a sub-item to the productthe customer ordered (Figure 1).

• Free goods: It is common to give freeproducts when the customer buys cer-tain products. For example, if the cus-tomer buys two coffee machines, hegets a packet of coffee free. The freeproduct (packet of coffee) is assignedas a sub-item to the product the cus-tomer ordered (coffee machine), themain item.

• Sales BOM (bill of material): In high-tech industries—selling computers, forexample—you create a bill of materialfor sales to process the main computerand its components. The components(sub-items) are attached to main itemin a hierarchical relationship.

Higher-Level Item Categoryfor Sales BOMI’ll use the example of a sales BOM toillustrate the role “higher-level item”category plays in determining whatvalues are posted to financial ledgers.

Say that a product is made up ofvarious components and you sell it as awhole. Technically, this list of compo-nents is a bill of material (BOM). Themain item identifies the BOM, andcomponents or sub-items are linked tothe main item. Take the example of apersonal computer, which is made upof a hard drive, monitor, and keyboard(Figure 2).

The business sells this computer as awhole, including the components. Italso could sell the individual compo-nents separately, a common practice inthe high-tech, make-to-order, andapparel industries.

Figure 1 Material M1 entered in Sales Order Item 10. The system substitutes Material M2 (product with special wrapper) and creates a sub-item 20 assigned to main item 10.

61



R/3 can be made to look for—andautomatically explode—a BOMduring sales order processing. Itenters components as sub-items of themain item when you enter the mate-rial number of the main item. Theadvantage of creating a sales BOM isthat you don’t need to enter all thematerials in the sales order.

For the Sales Order Create process(transaction code VA01), forexample, you enter the materialnumber of the main item and thesystem automatically fills in sub-items representing components.Here’s how it works:

• The system checks whether aBOM exists for the material num-ber entered by the end user.

• If a sales-related BOM exists, thesystem reads the BOM structureand identifies the components.

• R/3 enters these components asadditional items in the sales orderfor you.

To correctly reflect the structure ofthe BOM, R/3 assigns the itemnumber of the main item. See the

Figure 2 Typical BOM for a computer with a main item (computer) consisting of components (hard drive, monitor and keyboard)

Table Configuration settings for typical item categories

Item category, a configuration in the Sales and Distribution (SD) module, isassigned to every sales order item. (See the table below for some common item categories.) Item category controls how the item is processed, such as type andscope for inventory postings, transfer requirements, pricing, billings, and creditcontrol checks.

The figure below shows some of the important item category settings that influencefinancials.

• Relev. for Billing: If the item is checked as relevant for billing, you can see if itis delivery-related or order-related. For example, “delivery-related” billing meansthat the invoice should be created after the product is shipped. In the case of acredit or debit memo that is not related to a delivery, you set the billing relevancyto “order-related.”

• Pricing: The pricing checkbox determines whether pricing calculations arecarried out. If the checkbox is marked with an X, item category TAN is relevantfor pricing, and the customer is charged. A free-of-charge product should not bepriced. Item category TANN is typically used for free items.

• Determine Cost: If this checkbox is set, the R/3 system reads the standard costof the product from the material master and copies the value in the sales orderitem’s pricing screen. Typically, the cost is stored in condition type VPRS (withcondition category G costs) in the pricing procedure.

SD Item Category

Figure Item category settings for TAN (IMG>Sales and Distribution>Sales> Sales Documents>Sales Document Item>Define Item Categories)

62



HgLvIt (higher level item) column inthe BOM structure shown in Figure 3.

Note in Figure 3, column ItCa is auto-matically filled with TAQ for the mainitem and TAE for components. Typically,the user does not enter the item categoryduring sales order processing. The R/3system automatically determines the itemcategory from the item category groupof the material master (Sales 2 view)and the sales order type1 entered by theend user. See Figure 4.

Figure 5 shows allowed item categoriesfor a standard order type (OR) and itemcategory group ERLA (category groupfor items sold as one unit).

Item category TAQ designates the mainitem, as shown in the first row of theconfiguration. The sub-items areassigned to main item. Thus, the com-ponents are item category TAE. (InR/3, TAE is a dummy item category,not relevant for pricing or costs.) Here’show to read the second row in the table.If the higher-level item category isTAQ, then you assign TAE to lower-level items, if they exist.

In the example of the sales BOM, themain item (sales order item 10) isassigned as item category TAQ and thecomponents (sales order items 20onwards) are item category TAE. Allthe sales order items are processedaccording to their respective definitionsof item categories.

Tip! The Structure scope indicatordefined in the item category controlswhether the BOM is exploded or not,and to what extent (Figure 6).

Figure 5 Item categories for a standard order type (IMG>Sales and Distribution>Sales>Sales Documents>Sales Document Item>Assign Item Categories)

Figure 4 Combination of sales order type and item category group from the material master determines the item category. Values in brackets are typical examples.

1 In the strictest sense, even the item categoryusage plays a role in determining the itemcategory. For the purposes of this article, I’mnot taking that into account.

Figure 3 During the Sales Order Create process, the end user enters material number R-1001 as item 10. The system automatically enters items 20 onward. Note that the HgLvIt for items 20 and up is set to 10.

63



Figure 6 The structure scope (StructScpe) indicator of the item category controls BOM explosion in order processing

Postings to Financials With a basic understanding of item categories and how sales BOMs areprocessed, you see how these settingsinfluence what postings are made toFI. In my example of the personalcomputer, I am assuming the salesBOM2 is already created and theappropriate settings for sales order processing are in place.

As a FI/CO analyst, you have twooptions to report profitability:

• Revenues and costs at the main itemlevel

• Revenues and costs at the sub-itemlevel (components)

Option 1: Revenues and costsposted at main item levelIn this case, you want only the mainitem to be posted to FI with revenuesand costs of the main computer. Insales-order processing, the componentsact just for data-entry help and are notposted to FI.

The simple solution is to have thehigher-level item category relevant forprices and costs, whereas the lower-level item category for the componentsshould not be relevant for prices andcosts. In a standard R/3 system, theitem category group ERLA is definedfor this purpose.

Solution: Enter item category groupERLA in the material master (transac-tion code MM02, Sales 2 view) of thepersonal computer. Once an invoice iscreated for this sales order, revenuesand costs for the main item only areposted to the CO-PA ledger. You areable to do gross margin analysis at themain item level. See Figure 7.

Figure 7 In the CO-PA ledger, revenues and costs are posted at the main item level, so you can do gross margin analysis at the main item level.

Figure 8 Item category group ERLA with item category TAQ for the main item and TAE for components. TAQ is relevant for prices and costs, whereas TAE is not.

2 Usually, your colleague responsible for the PPmodule creates a bill of material.

Tip! If the components can also be sold separately, the item category group forthe components should be NORM. In that case, you should have an additionalrecord present in the configuration table for the combination of order type andNORM as shown in the third line of Figure 8.

64



Option 2: Revenues and costs posted at the components levelIn this case, you want to post the com-ponent details3 to FI with revenues andcosts. The lower-level item category isrelevant for prices and costs. The stan-dard R/3 system defines item categorygroup LUMF, which posts componentdetails to FI with revenues and costs,for this purpose.

Solution: Enter item category groupLUMF (Figure 9) in the materialmaster of the personal computer (transaction code MM02, Sales 2view).

Figure 10 Revenues and costs posted at the sub-item level in the CO-PA ledger

Item category group LUMF makesCO-PA postings at the componentslevel. In the CO-PA ledger, you candetermine gross margin analysis forindividual components. See Figure 10.

Now you see how SD item categories,including relationships of higher- and

Figure 9 Item category group LUMF with item category TAP for the main item and TAN for components. TAP is not relevant for prices and costs, whereas TAN is.

3 It does not make sense to do profitability atthe components level if your BOM has lotsof components, as it posts many records inthe CO-PA ledger.

Did You Know? In the apparel industry, sales BOMsare widely known as "prepacks" or"assortments." "Prepack" is an IS-AFS (Industry Solution for Appareland Footwear Systems) term formanaging pricing, inventory, anddelivery at the main item level."Assortment" indicates processing isdone at the components level. Asuit, a typical example of a salesBOM from the apparel industry,might consists of coat, vest, andtrousers. In the case of prepacks,the CO-PA ledger shows profitabilityat the suit level. In the case ofassortments, you can determineprofitability at, for instance, thetrousers level.

lower-level item categories, influ-ence the flow of revenues and costs data to FI. With the help ofpre-defined item category groups(ERLA or LUMF) and item cate-gories, you are able to viewprofitability in CO-PA at both themain item and components level.

Mitresh Kundalia is a FI/CO consultant with over six years of SAP consulting experience.

With an MBA degree in finance, Mitresh concentrates on the Financial and Controlling

modules with emphasis on Profitability Analysis, Cost Center Accounting, General Ledger,

sub-ledgers, and Special Ledger. He also has experience with Information Consolidations,

SIS, and Business Warehouse. He can be reached by e-mail at [email protected].

65

SAP financial concepts, technology, and best practices


Publisher of SAP Insiderwww.WISpubs.com


SAP Financials EXPERT

Search the complete article archive at:

Search:

www.SAPFinancialsExpert.com

A critical part of any finance team’s respon-

sibility is securing the corporate revenue

stream: making sure customers are invoiced

for all amounts owed and that payment is

received. This has always been a crucial

business requirement, even before Sarbanes-

Oxley. Neglecting this process can leave a

large amount of clean-up, and it could have

dire consequences for your revenue.

The accounts receivable team that chases bad

debts for a company only sees what has been

posted to FI-AR. If the FI invoice for an SD

billing document is not posted, the accounts

receivable team does not know about it.

Billing may not occur for several reasons:

lack of data necessary for completion, improper master data setup, or configuration errors.

I will first explain how billing documents are created and where you can look to detect

billing errors. Then I will discuss the major causes of billing errors and how to ensure they

do not reoccur. See the sidebar, “How SD Billing and FI Invoice Work Together,” on page 4

for a detailed explanation of the process.

Invoice Creation Invoices are usually created by an overnight batch job. Check that your batch jobs use the

latest report SDBILLDL, not older reports SAPMV60S or RV60SBAT, which are not as

It is possible to have an SD billing document without a corresponding FI invoice. This type of error

can result in significant under-reporting of revenue. Take these steps to ensure all SD invoices are

reflected accurately in FI-AR.

Secure Your Revenue StreamEnsure That SD BillingDocument Invoices Are Posted in FI

by Rohana Gunawardena, Principal Consultant, Quality Systems & Software, Inc.

March 2006 | Volume 5 | Issue 3

Two R/3 modules, SD and FI, coverthe order-to-cash process. Invoicingrepresents tthhee iinntteerrffaaccee bbeettwweeeenn SSDDaanndd FFII, and there is a high risk if thetwo teams are not working in cooper-ation. If the teams are not aware oftheir actions’ impact on the others,do not understand the end-to-endprocess, and do not have clearlydefined areas of responsibility, or ifthey simply do not talk to each other,the results may be disastrous.

Key Concept>>

9Quick TipWhich Transactions to TestFirst? Use RBE to Prioritize

12Quick TipDisplay Table Contents without Technical Help

14SAP NetWeaver PortalInitiate and Track the Planning Process withCollaboration Rooms

22Quick TipStreamline Your PaymentProcessing with Free Selections

>>inside

66


March 2006 • www.SAPFinancialsExpert.com

comprehensive. SDBILLDL is the same

as transaction VF04. Use transaction

VF06 to set up billing batch jobs using

SDBILLDL. See SAP note 652219 for

more information on setting up back-

ground billing jobs. You can also create

invoices by manual processing from the

work list created with VF04 or by creat-

ing a billing document explicitly via

transaction VF01, where you specify

individually the deliveries or sales orders

to be billed.

When setting up the background billing

jobs using SDBILLDL or VF06, make

sure the Issue collective processing log

check box is set to ensure the error log is

output. If you have problems printing the

error log, refer to SAP note 876183. The

check box List Display controls if a com-

prehensive list of all invoices is output.

SD Billing Error LogOnce the background billing job runs,

check that all of your invoices were

processed successfully. To help you

do this, the SDBILLDL report produces

an error log. Ensure that someone

monitors the billing error log on a daily

basis so that any errors are detected

and rebilled as quickly as possible. Read

the spool list of this batch job to obtain

the billing error log number (Figure 1).

Use this number in transaction V.21

(Figure 2) to read the SD billing log

(Figure 3). The notes icon in the

billing log displays a full list of error

messages that occurred in the billing

run (Figure 4). If many error messages

are displayed, you may wish to ignore

some (e.g., billing block flag on in sales

order). Click on the Cumulated view

button to summarize the messages by

error message number (Figure 5).

SD Invoice Creation The following common errors in the SD

billing error log prevent SD billing docu-

ment and the FI invoice creation:

The spool output of the billing batch job gives a GGrroouupp number used to viewthe error log

Figure 1

Use the GGrroouupp number in transaction VV..2211 to view the billing error logFigure 2

Click on the notes icon to see the error message detailFigure 3

Click on CCuummuullaatteedd vviieeww to summarize the error messages by message typeif many errors exist

Figure 4

Cumulative view of error messages in billing logFigure 5

67

4 © 2006 SAP Financials Expert Reproduction prohibited. All rights reserved.

www.WISpubs.com

document is created but no FI invoice is

created are common. They include:

- Billing date in prior period. The

billing date in an invoice defaults

to the delivery date, and the billing

date becomes the posting date for

the FI invoice. If a sales order had

a billing block kept on for an extend-

ed time, when the block is released,

the delivery date could be in a closed

fiscal period. The result is that the

FI invoice cannot be posted.

In this case, update the SD billing doc-

ument using transaction VF02. Even

though the SD billing document is

created on the billing date, customer

• Billing block. For many business rea-

sons, sales orders and deliveries have

their billing block flag set (e.g., credit

memo needs to be reviewed prior to

release, customer only to be billed after

system installation). Users may forget

about billing blocks they have set. It

is good practice to determine a maxi-

mum billing block delay and review all

billing blocks active after such a period.

Note that the sales order has separate

header and line-item levels for billing

block flags. Use transaction V23 to

monitor transactions blocked for billing.

• Incomplete document. The user

must enter more data in the sales

order. Use the incomplete log function

in the sales order to determine what

data is missing.

• Credit block. If your credit department

does not regularly monitor sales orders

and deliveries blocked for credit, they

may contain items that cannot be in-

voiced. The assumption is that if a docu-

ment is on credit hold, then nothing can

be delivered, so there is no billing impact.

In reality, some situations, such as a doc-

ument being changed after a partial deliv-

ery, result in billing blocks. Use transac-

tion VKM1 to check for documents

awaiting credit hold release regularly.

• FI invoice creation. Errors in the SD

billing error log in which an SD billing

An invoice is actually two documents: an SD billing docu-

ment and an FI invoice. Both must be posted fully to ensure

that your revenue stream is not interrupted between SD and

FI. Figure 1 shows the relationship between the SD billing

document and FI invoice. This example assumes that the

most common type of invoicing, delivery-related invoicing,

is used. Sales order-related invoicing is also possible (e.g.,

service-related transactions where no delivery occurs). Trans-

action VF03, used to display SD billing documents, can also

display the FI invoice if you click on the Accounting button

(Figure 2). In the SD document flow, the two are clearly

separate: the SD billing document, Invoice, and the FI

invoice, Accounting document (Figure 3).

Billing is used as an umbrella term for invoices, credit

memos, debit memos, pro forma invoices, and cancellation

documents.

SD Billing DocumentThe SD billing document drives the customer communica-

tion through the output types assigned to the invoice type.

These control printing of the paper invoice using SAPscript,

sending EDI messages, IDoc creation, or other methods. If

the SD billing document is not generated correctly, customers

are not aware of their obligation to pay you. Note that not

all SD billing documents generate an FI document (e.g.,

commercial invoices or zero value invoices).

How SD Billing and FI Invoice Work Together>>

FI InvoiceThe FI invoice makes the revenue posting to the G/L, making

it responsible for revenue recognition. The FI invoice also

makes the customer AR balance postings, which are shown

on the AR aging report and used by your accounts receivable

department to chase slow payers. This is a critical activity

for assuring your revenue stream. When the customer makes

a payment, it clears the FI invoice line in the customer account.

If a customer pays on an SD billing document with no

FI invoice, there is no matching open item on the customer

Transaction VVFF0033 allows you to display both theSD billing document and FI invoice

Figure 2

Relationship of the two invoicing documentsFigure 1

68



automatically by R/3 (also by

ECC 5.0).

- Error in revenue account determi-

nation. If revenue account determina-

tion cannot select a G/L account or an

account with incorrect settings is

selected, an error occurs. Often, the

error message mentions an unusual

line number (e.g., No account is

specified in item 0000001002). Item

0000001002 actually refers to an

error for revenue account determina-

tion for line item 1 in the SD billing

document. The most common reason

I have found for this type of error is

that the customer master has been

set up with an incorrect customer

account assignment, material account

assignment group, tax fields, and other

primarily FI-related fields can still be

updated (Figure 6).

As soon as you update the incorrect

billing data in the SD billing docu-

ment, using VF02, and save the

changes, the FI invoice is created

The SD document flow shows the SD billing document and FI invoice separately

Figure 3

accounts receivable (FI-AR). The balance may be applied

as a payment on account or be used to clear unrelated

invoices, effectively making the original invoice go unpaid.

Alignment of SD billing document numbering and FI

invoice numbering can greatly assist your accounts receiv-

able department in problem resolution. In Figure 3, the SD

billing document and FI invoices are different. Your trou-

bleshooting can be made much easier if both documents

have the same numbers. To learn how to do this, consult the

article “Align R/3 FI Accounting and SD Billing Document

Numbers to Keep Everyone on the Same Page” by Mitresh

Kundalia in SCM Expert, April/May 2005.

You can view the FI invoice using SD transaction VF03, as

in Figure 2, or FI transaction FB03. When displaying an FI

invoice using FI transaction FB03, you can display the SD

billing document using Environment>Document environ-

ment>Original document. You can see the SD billing

document number in the header data reference field. The ref-

erence type for an FI document created by an SD billing

document is always VBRK. The document type is usually

RV (Figure 4) but can be changed in configuration.

If you are using an external system for invoice generation

with an interface to R/3 or manually creating invoices, you

can have FI invoices without matching SD billing documents,

using transaction F-22 or FB70.

How SD Billing and FI Invoice Work Together, continued>>

FI document header of a FI invoice created by anSD billing document

Figure 4

If the FI invoice has not posted the billing date, you can still update account assign-ment group and other fields in the SD billing document using transaction VVFF0022

Figure 6

69


www.WISpubs.com

log but does not repeat, as the SD billing

document is complete. The SD billing log

is focused on the SD billing document.

Therefore, if the SD billing document is

correctly created, subsequent FI errors

are not considered on later billing runs.

If the SD billing document is not created

(e.g., due to a billing block), this error

appears in every run in the billing log

until it is cleared, because the SD billing

requirement in the billing due list is not

cleared until the SD billing document is

created. The implication of this is that

you must monitor the SD billing log

every day to catch the FI-related errors

or use an FI billing-specific detection

report such as VFX3 in addition to the

SD billing error log.

You can detect missing FI invoices for SD

billing documents with transaction VFX3

(Figure 9). The report lists the SD billing

documents and shows the details of the

interface errors (Figure 10). For more

detailed information on FI/CO interface

errors, select the line item and click on the

release to accounting icon. Messages are

output to the error log. The same messages

are shown if you go to transaction VF02

and select the release to accounting icon.

account assignment group in the

header. Fortunately, you can change

this in the SD billing document, using

VF02. Also look at the material account

assignment group at the line-item level.

In the case of one-time customers,

which SAP refers to as customers per

document (CPDs), the user has to

input the account assignment group

manually in the sales order. CPDs can

be used to represent many customers;

therefore, the system is not able to

determine the account assignment

group automatically.

From transaction VF03 use menu

option Environment>Act.determ.

analysis>Revenue accounts to see the

logic SAP uses to determine the revenue

account selection. This functionality

displays a detailed analysis of exactly

which data in the SD billing docu-

ment was used by the revenue account

determination procedure (Figure 7).

- Pricing error. A pricing error

(Figure 8) can keep the FI invoice

from being posted, but the SD billing

document posts normally. You must

be careful when correcting this type

of error, as the paper or EDI invoice

is already out to the customer. If cor-

rection results in new pricing, then you

need to cancel the invoice already sent

to the customer and reinvoice.

Usually, such a pricing error needs to

be resolved by your SD team.

For more detail on the error, go to

transaction VF02 to display the pric-

ing conditions and carry out new pric-

ing. Click on the Update button and

choose option B, Carry out new pric-

ing. A more detailed error message

appears. In some cases it is not really

an SD pricing issue (e.g., a missing

exchange rate or missing unit of meas-

ure conversion can result in a pricing

condition error). Remember not to

save the invoice after updating the

pricing, which is something only your

SD pricing expert should do. You just

want to see the detailed error message.

FI Invoice Error DetectionDetection methods are available for the FI

invoice errors mentioned above. Normally,

the FI invoice is created at the same time

the SD billing document is created by

SDBILLDL. It is possible, however, to

create an SD billing document with no

matching FI invoice. This is a major area

of concern in the revenue stream. If the

customer does not pay the invoice, you have

no indication on your FI-AR aging report,

and the revenue is not recognized in FI-G/L.

Note that if an FI invoice is not created,

the error shows once in the billing error

Detail of revenue account determination analysis screenFigure 7

Sample pricing error message shown after release to accounting and two more detailed messages displayed when the invoice line item pricing conditions are updated

Figure 8

70



Configuration-Based ErrorsMany of the errors in the billing error log

are due to bad or missing configuration.

Usually correcting the configuration allows

the billing to go through. In some cases, a

user may have made a more fundamental

error (e.g., using an external sales order

type for inter-company sales, which would

require that the whole transaction be can-

celed and reposted). See Table 1 for a list

of common configuration-related billing

errors. It is out of the scope of this article

to go into all possible billing configura-

tion errors. You should work with your

SD colleagues to resolve these issues.

Recommendations To ensure the security of your revenue

stream, run billing batch jobs on a daily

basis. You should monitor the billing error

logs V.21 and VFX3 and the billing block

list V23 on a daily basis. Make sure you

clearly identify which users/departments

are responsible for monitoring the reports

and resolving any issues. It is important

that users form good habits early with

regard to control processes. Regular moni-

toring makes the correction workload

manageable. Finding out about 1,000

blocked invoices just before quarter-end is

not going to make anyone’s job easier. �

Run transaction VVFFXX33 to detect SD billing documents that have not createdFI invoices

Figure 9

View the SD documents with missing invoicesFigure 10

Message Text

VF 027 Delivery type <VAR1> cannot be invoiced with billing type <VAR2>

VF 009 Sales organization <VAR1> is not defined

VF 003 Item category <VAR1> <VAR2> cannot be invoiced with billing type <VAR3>

VF 067 The billing type could not be determined

Common configuration-related billing errorsTable 1

Rohana Gunawardena is a principal consultant with QS&S, Inc., a specialist SAP consulting firm. Rohana has been working with

SAP since 1992, focusing on the FI/CO modules with emphasis on business segment reporting, cross-module integration to

FI/CO, sales cycle accounting, and A/R. He also has experience with SD, MM, and ABAP. He is a Fellow of the Institute of

Chartered Accountants in England & Wales. You may reach Rohana at [email protected].

71

SAP supply chain concepts, technology, and best practices


December 2005 | Volume 3 | Issue 10


Publisher of SAP Insiderwww.WISpubs.com


Search the complete article archive at:

Search:


x Case Study

xx

xx

>>inside

Avoid These 11 Common Unit-of-Measure Errors


Units of measure (UoMs) are a key part of

global configuration affecting all SAP R/3

modules, SAP New Dimension products, and

interfaces to external systems. The impor-

tance of this configuration is signified by its

position at the top of the IMG. Despite this,

little attention is often paid to UoMs during

the configuration of SAP systems. More

often than not, the SAP default values are

accepted without much concern. Luckily,

these work correctly for most companies.

As you roll out your SAP system across

multiple companies and countries, however,

needs like conversion from metric to

US/British Imperial measure arise that neces-

sitate a more detailed analysis of the UoM

configuration. Lack of attention to the

conversion factor for a UoM or other local

settings can, at least, irritate or confuse users.

At worst, miscalculated documents can be

sent to customers or foreign customs offi-

cials, resulting in blocked shipments or

expensive disputes.

Another major area of concern is the conversion of quantities from one UoM to another

and the problems unfavorable rounding differences can cause. This happens most often

with conversion between two US or British Imperial UoMs (e.g., pounds to ounces). In

extreme cases, this type of rounding error can bring your warehouse operations to a halt.

The crucial role of units of measure(UoMs) in SAP is to give context toquantities. A key activity of an SAPsystem is maintaining clear commu-nication with external business partners (e.g., sending a purchaseorder to a vendor for raw materialsor sending an invoice to a cus-tomer). You can accomplish thiscommunication in a number ofways, such as paper invoice, EDIpurchase order, or XML delivery confirmation. Quantity is one of themost important aspects of that com-munication: You need to be surethat an order for five cases of amaterial is not interpreted as fivepieces or five pallets.

Key Concept>>

To keep your SCM operations running smoothly, learn how to avoid and correct these 11 common

unit-of-measure errors that can bring them to a standstill.

72

2 © 2005 SCM Expert • Reproduction prohibited. All rights reserved.

www.WISpubs.com

>> SSUUBBSSCCRRIIPPTTIIOONNSS AANNDD LLIICCEENNSSEESS

SCM Expert (ISSN# 1546-9832) is published

10 times a year. A one-year subscription is $595.

Electronic licenses and group access are available

by calling 1-781-751-8799.

>> DDIISSCCLLAAIIMMEERR

Although we use reasonable care to produce

SCM Expert, we cannot assume any liability for

its contents. In no event will SCM Expert be liable

for costs or damages, direct or indirect, including

special, remote or consequential damages, even

if SCM Expert has been advised of the possibility

of such damages, from any cause, whether in

contract, tort or strict liability, in excess of the

subscription fee paid by the subscriber.

>> CCHHAANNGGEE OOFF AADDDDRREESSSS

If you plan to relocate, please give us four to six weeks’

notice to ensure that you do not miss any issues.

Postmaster: Send address changes to SCM Expert,11300 Rockville Pike, Suite 1100, Rockville, MD

20852-3030, USA.

>> TTRRAADDEEMMAARRKKSS

SAP and mySAP are registered trademarks of

SAP AG in Germany and in several other countries.

All other registered trademarks are the property of

their respective holders.

>>Meet Our SCM Experts

More than 250,000 professionals worldwide rely annually on WIS publications and events for expert strategies, instruction, and best practices to optimize their IT

investments. WIS is the largest independent provider of SAP-related information in the world. WIS publishes these leading publications: SAP Insider,

SAP Professional Journal, SAP NetWeaver magazine, BW Expert, SAP Financials Expert, HR Expert, SCM Expert, and CRM Expert. WIS also produces

the following events in collaboration with SAP: SAP Logistics and Supply Chain Management 2006; SAP PLM 2006; SAP Financials 2006; SAP HR

2006; SAP CRM 2006; and SAP NetWeaver/BW and Portals 2006. WIS is the exclusive US distributor of SAP PRESS books. Visit www.WISpubs.com

for more information.

>>EEDDIITTOORRIIAALL

EEDDIITTOORR--IINN--CCHHIIEEFFBonnie Penzias

AASSSSOOCCIIAATTEE PPUUBBLLIISSHHEERRMichael [email protected]

GGRROOUUPP MMAANNAAGGIINNGG EEDDIITTOORRAndrea [email protected]

AASSSSOOCCIIAATTEE EEDDIITTOORRSSCharis [email protected]

Mary E. [email protected]

AASSSSIISSTTAANNTT EEDDIITTOORRJacquelyn [email protected]

>>SSCCMM EExxppeerrtt

11300 Rockville Pike, Suite 1100, Rockville, MD 20852-3030, USA1-301-287-2691 phone • 1-301-816-8945 fax • www.SCMExpertOnline.com

Four SCM experts are on the technical advisory board for SCM Expert. They evaluate manuscripts, sug-

gest articles, and assist in the writing and editing process. They are also among the many expert

authors who submit articles to SCM Expert.

AAllii SSaarrrraaff ([email protected]) is SCM Expert’s technical editor. He

has ten years of experience as a senior consultant for SAP R/3 logistics modules

and 15 years of IT experience. During much of his career, he has focused on helping his

customers optimize their logistics business processes by analyzing and explaining

cause-and-effect relationships and by bringing the machine and the human sides of

IT closer together.

AAbboouutt EEnnoowwaa CCoonnssuullttiinngg:: Enowa provides predictable SAP project results tied to efficient utilization of

resources. Enowa is comprised of experts who specialize in SAP and IT implementations. Founded by Top

Tier SAP practitioners who have extensive track records, this team brings a broad range of SAP experi-

ence from projects that are small to projects that are in excess of $40 million serving as Project and QA

Managers and Team Experts. For questions or a competitive bid with a minimalist approach to staffing on

an implementation, upgrade, rollout, system merger/de-merger, QA roles, or system redesign, contact

client services at [email protected], 610-296-3641, or

visit www.enowa-consulting.com.

VViijjaayy GGaarrgg ([email protected]), PMP, is a senior SAP supply chain

management consultant and partner with Enowa Consulting. He has more than

eight years of SAP project management and implementation experience with

Fortune 100 companies in the chemicals, pharmaceutical, high-tech, and electron-

ics industries using various R/3 logistics modules as well as APO. Prior to working in

SAP, he had vast experience in the engineering industry, including with software

development and applications.

WWoollffggaanngg EEddddiiggeehhaauusseenn ([email protected]) has over

20 years’ experience in supply chain management and over 12 years in consulting,

helping clients optimize supply chain processes in Australia, Europe, South Africa,

Singapore, Taiwan, and the US. He is a principal with Oxygen Business Solutions in

Australia, a consulting house specializing in SAP-related projects. His area of expert-

ise includes general supply chain management, and he also has detailed knowl-

edge of the APO package. He is a certified SAP consultant in Supply and Demand

Planning (APO), Material Management (MM), Production Planning (PP), and Accelerated SAP (ASAP). He

wrote the first available APO-related book Understanding SAP APO, followed by The APO KnowledgeBook — Supply and Demand Planning.

PPeetteerr CCoollee ([email protected]) works in the SAP practice of Answerthink

Inc. He has nine years of experience in the SAP R/3 logistic modules in mostly inter-

national projects in the chemical, pharmaceutical, and high-tech industries in the

Americas and in Europe. Peter’s process focus has been on the supply chain, in par-

ticular PP, PP-PI, QM, and MRP with a background in Basis and programming. He

participated in two System Landscape Optimization projects, in which two SAP sys-

tems were merged into one client.

73


December 2005 • www.SCMExpertOnline.com


What follows are the 11 most common

pitfalls to watch out for when you are

working with UoMs and quantity fields.

I’ll also give you details to help you fix

and avoid the problems.

1. Incorrect Selection of BaseUoM for a MaterialConsider a company that produces fiber

optic cable and chooses kilometer (KM)

as the base unit of measure. In SAP all

quantity fields are maintained internally to

three decimal places, so the smallest quan-

tity of fiber optic cable that can be deliv-

ered to a customer is 0.001 KM, which is

1 meter (M). So what happens when a

customer wants 10 centimeters (CM) of

fiber optic cable? This would be 0.0001

KM, which cannot be represented in SAP

if KM is chosen as the base unit.

The base UoM defined in the material

master is the UoM, in which the material

is managed by SAP (Figure 1). The SAP

system converts all the quantities you

enter in other UoMs (e.g., alternative

UoMs) to the base UoM. In older versions

of SAP, this field was referred to as the

stock-keeping unit (SKU). For Inventory

Management (MM-IM), the base UoM is

the same as the SKU.

Careful selection of the base UoM helps

minimize rounding errors in stock quanti-

ties. For dimensionless UoMs, choose the

smallest UoM, such as each (EA), instead

of the larger case (CSE). For other UoMs,

choose a base unit carefully. The actual

choice depends on the nature of the mate-

rial. If your base UoM is too small, then

large quantities of the material cause an

overflow in the quantity fields. If the base

UoM is too large, accuracy is lost, since

all quantities are stored at a maximum of

three-decimal-point accuracy. For

example, for length it is often safer to

choose M over millimeters (MM) or KM.

See SAP note 362932 for more informa-

tion about rounding with UoMs. Once

business transactions have started using

the material the base UoM cannot be

changed in most cases, as explained in

SAP note 138767.

The wrong base UoM can also result in

problems with batch splits in deliveries.

For example, say the UoM in the sales

order is different from the base UoM in

the material master and the conversion

factor cannot be described accurately

using three decimal places (e.g., 1 pack

(PK) = 7 EA). In some situations, the total

of the delivery batches does not add up

exactly to the sales order amount. This

results in the sales order not being marked

as fully delivered. See SAP notes 107219,

135821, and 139966 for more details.

2. Failure to ConfigureAlternate UoMs for a MaterialConverting quantities in one UoM to

another UoM and adding up total quanti-

ties in multiple UoMs are frequently

required for logistics activities. For stan-

dard SAP conversions, all UoMs must

belong to the same dimensions for regular

conversion (e.g., length is converted from

inches to M but length in inches is not

converted to weight in kilograms).

Alternate UoMs used as conversion

factors cannot be set up centrally for

dimensionless UoMs or between UoMs of

different dimensions. You can configure

this on a material-by-material basis only

using the alternate UoM functionality. For

more details, see SAP note 523496.

Rounding errors in Warehouse

Management (WM) can result in blocked

shipping, as small variances between

picking and goods issue amounts prevent

goods issues from being posted. Consider

the following example: An item has base

UoM EA and alternate UoM PK, where 1

PK = 7 EA. This becomes 1 EA = 0.143

PK. Since accuracy for quantities goes

only to three decimal places, when this is

multiplied by 7 it results in 7 EA = 1.001

PK in WM. This is different from the

1.00 PK expected in MM-IM goods issue.

The reason for this error is the chained

conversion Alternate UoM>Base UoM>

Alternate UoM, which results in rounding

differences.

Prior to SAP R/3 Release 2.1, this was a

major problem. SAP changed WM func-

tionality to store quantities internally in

the entered UoM and not to automatically

convert to the base UoM. If you make any

manual quantity entries in the WM trans-

action screens, however, even overwriting

a quantity with the same number, a con-

version takes place. The system behavior

of quantity conversion only upon request

is implemented in the entire transfer order

processing, so you can avoid superfluous

quantity conversions. See SAP note 5555

for more details.

A follow-on problem encountered in WM

is almost-empty storage bins, when 0.001

of a material is left in the bin due to

rounding errors. This results in the bin not

being released for reuse. You can correct

Base UoM is defined in the material master. Use the AAddddiittiioonnaall ddaattaa buttonto enter alternate UoMs.

Figure 1

74


www.WISpubs.com

this by making a physical inventory

adjustment or, in more serious cases,

applying SAP notes. See SAP notes

125636 and 162816 for more details.

Click on the Additional data button,

shown in Figure 1, to enter or display

alternate UoMs, in transaction MM01,

MM02, or MM03 (Figure 2).

Alternate UoMs are commonly used at

order entry when purchasing or selling

materials. You can define UoMs other

than the base UoM in the material master

specifically for sales, purchasing, and pro-

duction, as shown in Table 1. In the case

of a base UoM with dimension, you can

use any UoM with the same dimension.

For example, you can order a material

with base UoM of M in KM or CM

without defining alternate UoMs.

One advantage alternate UoMs have for

defining central conversion factors is that

they allow material-specific translation. In

the example of the motor oil in Figure 2, 1

case = 24 quarts, but for orange juice you

may want 1 case = 12 quarts. One disad-

vantage is that the conversion factor needs

to be set up material-by-material, which can

be time-consuming and can easily result in

errors given the number of material master

records most SAP installations have.

If you are defining a common alternate

UoM relationship for many materials, you

can use Define Units of Measure Groups

in the IMG, SAP Customizing>Logistics

- General>Material master>Setting for

key fields>Define units of measure

groups to set up the relationship once for

use in many material master records.

3. Overlooking Costing Lot SizeWhen configuring materials for produc-

tion processes and the associated product

costing, the Costing Lot Size field

(Figure 3) is often overlooked. On a

bill of material (BOM), you might have

fractions of a UoM you normally only

see as whole units (e.g., pallets [PAL]).

For an individual material, you can configure alternate UoMs to allow conver-sion between any types of UoMs

Figure 2

Materialmaster field

Description View Purpose

MARA-MEINS Base UoM Basic data UoM in which stocks of the material are managed. SAP converts all the quantities you enter in alternativeUoMs to the base UoM. This is the stock-keeping UoM.

MARA-BRGEW Gross weight Basic data Gross weight of material for 1 base UoM

MARA-NTGEW Net weight Basic data Net weight of material for 1 base UoM

MARA-GEWEI Weight unit Basic data UoM for net weight and gross weight of material

MARA-VOLUM Volume Basic data Volume of material for 1 base UoM

MARA-VOLEH Volume unit Basic data UoM for volume of material

MARM-UMREZ Numerator forAlternative UoMConversion Factor

Additionaldata > UoMs

Numerator of the fraction that specifies the ratio ofthe alternative UoM to the base unit of measure.Numerator is the number on the top of the fraction.

MARM-UMREN Denominator foralternative UoMconversion factor

Additionaldata > UoMs

Denominator of the fraction that specifies the ratio ofthe alternative UoM to the base UoM. Denominator isthe number on the bottom of the fraction.

MARM-MEINH Alternative unit Additionaldata > UoMs

Alternative UoM

MVKE-VRKME Sales unit Sales org 1 UoM used for selling the material. Only make an entryif it is different to the base UoM.

MVKE-MEGRU UoM group Sales org 1 Key used for grouping several UoMs

MARA-BSTME Order unit Purchasing UoM used for purchasing the material. Only make anentry if it is different to the base UoM.

MARC-FRTME Production unit Work scheduling

When you create a production order for a material,and a production unit has been entered in both thematerial master record and in the routing, the systemchecks whether the quantity entered in the produc-tion order falls within the lot size range in the routing.Only make an entry if it is different to the base UoM.

MARC-AUSME Unit of issue Plant data/stor. 1

UoM in which the material is issued from the ware-house. Only make an entry if it is different from thebase UoM.

MARC-LOSGR Costing lot size Costing 1 Basis for costing material. The costing results areconverted to the costing lot size of the materialcosted (e.g., the finished product) to calculate thematerial costs for the finished product.

UoM-related material master fieldsTable 1

75



Rounding issues related to this UoM can

result in incorrect costing.

Consider the following example. You have

a BOM for producing 1 EA in a box ( i.e.,

lamps in boxes). Usually eight lamps go

on one pallet, so you add 0.125 PAL per 1

EA lamps. For planning purposes you can

use fractions of PAL. When posting, the

number is rounded up to the next PAL.

When you produce one lamp, the produc-

tion/process order contains 1 PAL instead

of 0.125 PAL. When costing such a BOM,

make sure you use the Costing Lot Size

on the material master Costing 1 view,

since costing also rounds up fractions of

PAL. If a lamp is USD 5 and the pallet is

USD 20, one lamp on one pallet would

cost USD 25, whereas if you have a

costing lot size of eight or a multiple

thereof, a lamp would cost (8*USD 5 +

USD 20)/8 = USD 7.50.

4. Incorrect ConversionFactors Consider the following situation: A cus-

tomer orders five miles of fiber optic

cable. The quantity is entered as five

miles, which is the sales UoM, in the sales

order. However, at delivery you find it has

been converted to five meters, the base

UoM. This is due to errors in the conver-

sion factors. To prevent this, make sure

you review the SAP standard conversion

factors. In the R/3 4.7 IDES system used

in these images, for example, the US mile

was configured incorrectly to be equal to

one meter. For a list of key tables used by

SAP for UoM configuration, see Table 2.

Conversion FactorsA key factor in dimension configuration is

the definition of the UoM known as the

System Internationale (SI) UoM, for each

dimension. This is the basic unit employed

in all conversions between different UoMs

with the same dimension (Figure 4). The

SI setting is made by SAP and cannot be

changed. Do not delete the SI UoM for a

dimension under any circumstances, as

conversion between UoMs with that

dimension will be impossible.

In transaction CUNI (IMG path SAP

Customizing>General Settings>Check

units of measure), you can define the

conversion factor between the UoM and

the SI UoM. In the case of metric meas-

ures, these are simple multiples of 10,

which do not introduce any complications.

Conversion TestingTo test UoM conversions when displaying

the UoM in transaction CUNI, use the

convert icon in the toolbar, and enter the

conversion you want to test in the popup

(Figure 5 on the next page). If you do not

have access to transaction CUNI, use

ABAP RSBZME10 instead to test con-

versions. The test popup can give the

misleading impression quantities can be

calculated to 15 DPs — in actuality,

quantity values are stored with three DPs.

In an SAP system with several different

SAP instances, the conversion settings

must be the same for all UoMs used

across all SAP instances. This is of

particular relevance when using New

Dimension products like APO and SRM,

which reside on their own server but com-

municate with the main R/3 system. Refer

to SAP notes 492979 and 595742.

Costing Lot Size in the Costing 1 view of the materialFigure 3

Table Name Short text

T006 Units of Measurement

T006A Assign Internal to Language-Dependent Unit

T006B Assignment of commercial to internal unit of measurement

T006C Assignment of external technical to internal unit of measure

T006D Dimensions

T006D_OIB Add-On for Dimensions

T006I ISO codes for units of measurement

T006J ISO Codes for Unit of Measure Texts

T006M Units of Measure Groups

T006T Dimension Texts

T006_OIB Units of Measurement, Additional Definitions

List of key UoM configuration tablesTable 2

For the dimension length M (meter) is defined as the SI unit in transactionCUNI

Figure 4

76


www.WISpubs.com

5. Rounding Errors DuringConversion of US/ImperialUoMsWhen working with metric measures, con-

version factors are usually very simple

(e.g., 1 KM = 1000 M, 1 L = 1000 ML)

with no concerns about rounding. With

US/Imperial UoMs, however, the relation-

ships are not as straightforward and errors

can result.

As the conversion factors between

US/Imperial and metric UoMs are usually

approximate fractions, rounding differ-

ences nearly always occur when you move

between the two systems and are even

worse when converting between two

US/Imperial UoMs (e.g., pounds to

ounces). The system often converts them

via an intermediate conversion to the

metric/SI UoM (Figure 6), adding round-

ing errors to what should be an exact con-

version (Figure 5 and Figure 6).

To add to the confusion, not all

US/Imperial UoMs are the same. For

example, a US gallon is 3.785 liters, while

a UK gallon is 4.545 liters.

If conversion factors are maintained cen-

trally in customized UoMs, the conversion

is always relative to the respective SI unit.

If the US/Imperial UoM in question has a

small size relative to the main UoM (e.g.,

1 inch = 0.0254 meters), it can be difficult

to maintain the conversion factors accu-

rately in the configuration.

One solution proposed by SAP is to define

all non-metric UoMs as dimensionless.

This allows you to define the conversion

factors with maximum accuracy in the

material master. The disadvantage is that

you have to make sure organizationally

that all materials with the same UoMs use

the same conversion factors in the mate-

rial master. Also, any combinations you

have forgotten to define cannot be con-

verted. This solution helps primarily with

conversion from one US/Imperial measure

to another and not with conversion to

metric units. See SAP notes 20307, 23771,

and 362932 for more information.

6. UoM with IncorrectDimension UoM configuration is done via transaction

CUNI. The initial screen of the CUNI

transaction lets you configure dimensions,

International Organization for Standard-

ization (ISO) UoM codes, and SAP UoM

codes (Figure 9). Select the dimension and

click the Units of measurement button to

see the overview screen in (Figure 7).

When creating a new UoM, you must

choose a dimension to which it belongs

(Figure 8).

A dimension is a set of categories that

group together similar UoMs and assist in

quantity conversions. There are seven

base dimensions, to which all other

Example of rounding error: conversion should be 3 pounds = 48 ounces,using transaction CUNI

Figure 5

Example of rounding error: conversion should be 3 pounds = 48 ounces,using ABAP RSBZME10

Figure 6

UoM display for dimension LengthFigure 7

77



dimensions can be traced back: length,

weight, time, electrical current, tempera-

ture, molecular mass, and brightness.

Quantity conversions can only occur

between UoMs with the same dimension.

Figure 8 shows a sample list of dimen-

sions in SAP. Using alternate UoMs (see

section 2), you can define cross-dimension

conversions on a material-by-material basis.

I often see UoMs created with the default

setting (no dimensions) when the UoM

clearly belongs to a defined dimension.

For UoMs with no dimension, common

UoM conversions (e.g., gallons to liters)

cannot be performed using central config-

uration, but need to be defined on a mate-

rial-by-material basis. This can lead to a

large overhead for maintaining material

master records. It also results in error

messages such as V1 297 Quantity could

not be converted from GA to L.

The reason this occurs is that users do

not understand what a dimension is and

accept the default value, (no dimensions).

For example, assigning the UoM GL for

gallon to (no dimensions) is incorrect,

because GL has the dimension of volume.

As previously discussed, there is a scenario

where you may choose to deliberately

configure US/Imperial UoMs as (no

dimension). Be sure to make this decision

actively.

If a UoM has been configured with an

incorrect dimension, you can delete the

UoM configuration and recreate it with

the correct dimension. Be careful when

doing this, as there is no validation on

existing use of the UoM. Recreate the

UoM as quickly as possible after deleting

it, or you may have materials with an

invalid base UoM that cannot be

processed. Use report ZRBZMEFIND

in SAP note 637003 to search for UoM

use prior to deleting or changing a UoM.

When you do change a UoM dimension,

you must test that the change does not

cause any problems with logistics and

manufacturing transactions.

7. Use of US ANSI UoM CodesInstead of ISO UoM Codes When communicating electronically with

external parties (e.g., vendors and cus-

tomers) through electronic data interchange

(EDI) and other means, a global standard

for UoMs must be used so that all systems

interpret the UoM code consistently. This is

the function of the ISO codes. The ISO

UoM code is assigned to the SAP UoM

code via transaction CUNI (Figure 9).

Many modules in SAP are designed to

work with external data files using ISO

UoMs. With Supplier Relationship

Management - Catalog Content

Management (SRM-CCM), for example,

you must upload an XML or CSV format

file for the SRM-CCM catalog. In this

file, the UoM field needs to be the ISO

UoM code. To ensure the upload works

correctly, you must check the following:

your input file uses ISO UoM, in transac-

tion CUNI the ISO code exists, the ISO

code is assigned to an SAP UoM code,

and the ISO primary code check box is set

correctly. A user logging on to the SRM

system sees the SAP UoM code displayed.

When using CUNI select the dimen-sion first, before clicking the Unitsof measurement button.

Tip!>>

Sample set of dimensions inan SAP system; the specific listdepends on your SAP release

Figure 8

UoM configuration details for Meter (M)Figure 9

78


www.WISpubs.com

One problem area is that in the US, the

American National Standards Institute

(ANSI) UoM codes are used for EDI and

other electronic communication. The ANSI

codes don’t always match the ISO codes

(e.g., ANSI GA vs. ISO GAL for gallon).

In some cases, you may find the ISO code

field is actually populated with the ANSI

code. If you use multiple EDI systems or

standards and one calls for the ANSI code

and the other for the ISO code, this can

lead to mis-conversion of UoM codes.

You have several methods to get around

this:

• Change the ISO field to contain the

ANSI UoM.

• Create a second SAP UoM with the

ANSI UoM in the ISO field.

• Have a custom translation table to con-

vert the ANSI UoM to the ISO UoM

prior to selection of the SAP UoM.

• Add a UoM translation table to any EDI

middleware you may use.

The SAP R/3 and ECC systems determine

which SAP-internal UoM is to be con-

verted into which ISO code. One ISO

code can be assigned to several SAP units

for outbound messages. For inbound mes-

sages, you must also determine which ISO

code is to be converted into which SAP

unit. Use the checkbox Primary code for

this (Figure 12). A common example is

the ISO code PCE for piece, which corre-

sponds with SAP codes AU (activity unit),

PER (persons) and PC (pieces). The SAP

code PC is chosen as the primary code for

translation of inbound EDI messages

(Table 3). See www.unece.org/etrades/

codesindex.htm for more information on

ISO UoM codes.

8. Incorrrect Number ofDecimal Places When calculating quantities or displaying

quantities on documents such as a com-

mercial invoice, you may be under a legal

or contractual obligation to calculate or

display the quantities using a specific

number of decimal places. It is also

common practice in certain industries to

use a specific number of decimal places.

If you fail to configure UoMs to yield the

correct amount of decimal places, at the

very least your output might look a little

odd. At worst, a foreign customs official

may hold up your shipment.

To be sure you get the correct output

format for quantity fields:

1. Configure the DPs for the UoM

correctly in transaction CUNI.

2. Make sure the quantity field has a

related UoM reference field.

3. Make sure the output ABAP or

SAPscript makes use of the reference

UoM field for the quantity.

All quantity data in SAP is stored internally

as numbers with three decimal places

regardless of the number of decimal

places when displayed (Table 4). If no

UoM reference is supplied, SAP uses the

default of three decimal places for display.

However, the majority of UoMs are con-

figured for display with no decimals.

In UoM configuration, there are two fields

for the decimal places with distinct purposes.

Both are configured via transaction

CUNI, as you saw in Figure 9.

The display decimal places field is used

for controlling the number of decimal

places for screen and list output of related

quantities. EA, for example, is usually

shown with no decimal places, while mil-

liliters (ML) is usually output with three

decimal places.

The decimal place rounding field is used to

determine the level of accuracy for internal

calculations using the UoM (e.g., internal

rounding during the creation of a production

order). However, the rounding decimal place

is not considered by every transaction, so

SAP recommends that you set the rounding

decimal places of UoMs to three (like the

number of the decimal places of the quantity

fields), especially when you are using metric

and non-metric units of measure simulta-

neously, which is the case where rounding

differences are most likely. Additional

information is available in SAP notes

77525 and 362932. If you are working with

a UoM in which quantities must always be

calculated to the nearest whole units, set

the rounding decimal place to zero.

Even if a UoM is configured to have

rounding to zero decimal places when

values are entered (e.g., during goods

receipt for a PO), the decimal places are

not rounded off when converting the quan-

tity in the entry UoM into the base UoM

of the material, to help maintain the value

as accurately as possible in the base UoM.

See SAP note 77525 for more information.

SAP UoM code ISO UoM code Primary UoM

AU PCE

PER PCE

PC PCE X

Example of use of Primary UoM checkboxTable 3

UoM Description Decimalplaces

SAP value display withUoM reference

SAP value display with no UoM reference/internal storage

EA Each 0 3 3.000

HR Hours 1 4.7 4.700

% Percentage 2 1.02 1.020

ML Milliliter 3 1.256 1.256

Comparison of SAP quantity display and SAP internal storage depending ondefined number of decimal places

Table 4

79


9. Lack of a UoM Reference FieldWhen a quantity field is output using

SAPscript or ABAP to get the correct for-

matting, the system expects a UoM refer-

ence field. If it does not exist, the quantity

may be output in the wrong format. This can

be particularly important if legislation or

an industry standard specifies the number of

decimal places to be used when printing

quantities. Table 4 shows how quantities are

displayed with and without reference fields.

Whenever a quantity field is defined in the

data structure, a corresponding UoM

reference field needs to be defined and

linked to the quantity field. This is because

a quantity is meaningless unless you know

the units in which it is expressed. In all

tables defined by SAP, a UoM reference

is maintained so that the context for the

quantity is maintained. When you create

your own custom tables for quantities, you

must link them to a reference UoM field.

Use transaction SE11 or SE12 to display

tables containing quantity fields, such

as EKPO, VBAP, or AFKO (Figure 10

and Figure 11).

When viewing data in SE16, SE16N, or

SE17 in the row overview screen, the

values are always displayed to three

decimal places regardless of UoM (Figure

12). In the row detail screen, the value

could be in three decimal places or the

correct number of decimal places, depend-

ing upon how the reference field for the

quantity field was defined.

10. Custom Reporting ErrorsCustom reporting is often used for docu-

ments such as commercial invoices when

an SAP standard SAPscript is modified

for a company-specific format. When

extracting data in custom reports, make

sure programmers use a UoM reference

field. I often come across problems with

quantity reporting when this has not been

done. Here is some sample ABAP code

using a UoM reference field for a write

statement: WRITE EKPO-MENGE USING

UNIT EKPO-MEINS. To see how quantity

values are displayed with and without a

UoM reference field, see Table 2. You can

check for the lack of a UoM reference using

the extended syntax check in the ABAP

editor, accessible through transaction

SE38 or directly with transaction SLIN.

You do not need to have custom rules in

your ABAP programs, hard-coded logic,

or printing with special formats as to get

the correct output of quantity fields. Using

the UoM reference, your SAP system

looks up the correct number of decimal

places automatically and formats the

quantity correctly.

When working with UoM conversions,

SAP provides several standard function

modules that do all the hard work for you,

so you can avoid creating new code to

look up conversion routines (Table 5 on

the next page). If you need to test function

UNIT_CONVERSION_SIMPLE using

SM37, you can run into problems. Use

ABAP RSBZME10 instead.

If you use the ALV grid for reporting,

include the UoM reference field in your

data table and cross-reference the quantity

field to the UoM field in the field catalog.

The ALV grid uses this information to

display values correctly and to subtotal

columns with values in multiple UoM


SE11 display of a quantity and UoM field for table EKPO. Double-click onquantity field MENGE to see detail.

Figure 10

UoM reference field for a quantity field. This popup is displayed after doubleclicking on the previous screen.

Figure 11

Quantity data in SE16 and SE17 overview is always displayed to three decimal places regardless of the UoM

Figure 12

80


correctly (Figure 13). Showing a total of

82,030.88 available stock is meaningless

as it is the sum of L + M2 + PC. Instead,

ALV subtotals by each UoM.

When working with SAPscript, the correct

number of decimal places is displayed if the

quantity field used has the UoM reference

field defined. If your SAPscript is based on

an SAP standard SAPscript and displays data

using one of the standard SAPscript output

structures, such as VBDPA or VBDPR,

make sure you populate the UoM reference

field (e.g., UoM field VBDPR-VRKME

for quantity field VBDPR-FKIMG).

11. Internal Storage Format vs.External Display FormatWhen a UoM is displayed to a user, it is

translated to its language-dependent code.

Internally, the UoM may be stored in a dif-

ferent code. This can cause problems when

dealing with raw codes (e.g., loading data

via a BAPI, preparing a material master

load using ABAP RMMMM, or working

with custom ABAPs).

For example, the UoM EA is commonly

used for “each.” However, your SAP

system stores this internally as ST, short

for the German word for each, which is

Stück. See Figure 14 for codes in differ-

ent languages. This is the SE16 display of

table T006A. This is why a list of UoMs

called up by F4 help may appear to be in a

random order, as it is sorted by the inter-

nal German language codes. With newer

installations, SAP makes the internal code

the English language code instead of the

German, but this applies to new imple-

mentations only and would still be an

issue if your main operating language

were not English. The internal UoM code

is displayed at the top of the UoM config-

uration screen in transaction CUNI. See

SAP note 619937 for more details.

When working with custom ABAPs, use

the following function modules to convert

between SAP internal and external lan-

guage dependant codes: CONVERSION_

EXIT_CUNIT_INPUT and CONVER-

SION_EXIT_CUNIT_OUTPUT. �

www.WISpubs.com

Function Module Description

UNIT_CONVERSION_SIMPLE Used for simple conversion of quantities between two UoMs withthe same dimension.

MATERIAL_UNIT_CONVERSION Used for conversion of quantities taking into account alternateUoMs in the material master, as well as conversion between twoUoMs with the same dimension.

Key SAP function modules used for UoM conversionTable 5

Subtotals by UoM are formed automatically by ALV if a UoM reference field isprovided

Figure 13

The user sees the language dependent UoM code but internally it is alwaysstored with the same code

Figure 14





Rohana Gunawardena will providemore details on UoMs at theLogistics and Supply ChainManagement 2006 conference, tobe held February 27 to March 1 atThe Mirage in Las Vegas. For moreinformation on the conference, go towww.SAPscm2006.com.

Note!>>

81

Have you ever seen the message, Update was terminated,and wondered what it meant? Here’s a more worrisomequestion: Do your FI users know what to do when they seethis message?

Perhaps they click through, thinking it’s just another irritat-ing log-on pop-up message. Since it looks so technical, theymight assume that it does not apply to them. Users oftenfind out otherwise at month-end when their books do notreconcile or they cannot find documents in open item lists.

Many users believe that all their data is safely stored when they click on the Save button and see a message such as Document 3100153969 was posted incompany code 0001. In reality, this may not be the case. To maximize onlineresponse time performance, R/3 sends the data to a background process to updatelater—as long as five minutes with a slow system.1 Sometimes things go wrong, andthe journal you think was posted is only half-posted or not posted at all. Forinstance, it is possible for a G/L, A/R, A/P, or AA document to post to the main document tables, but not to summary tables or to submodules such as the SpecialPurpose Ledger (FI-SL), Cost Center Accounting (CO-CCA), or ProfitabilityAnalysis (CO-PA).

Although such mistakes can occur as infrequently as once or twice a year, the error rate increases in systems with network, database space, or sudden termination

The newsletter for mastering SAP financial

concepts, technology,and best practices

February 2003Volume 2, Issue 2

www.ficoexpertonline.com

© 2003 FI/CO EXPERT • Reproduction prohibited. All rights reserved. 1

Inside This Issue

7Find FI/CO CustomizationDiscrepancies Fast with R/3’sStandard CCSV Tool

10Find the Hidden ConditionTechnique in CO-PA and Fine-Tune Your Profitability Analysis

15Improve the Integrity of YourElectronic Bank STatementUploads with Search Strings

20Even in Release 4.6, Your EndUsers’ Choice of an A/RPosting Key Has a SurprisingImpact on Standard ReportsSuch as the “CustomerAnalysis” Net Sales Columns

‘Update Was Terminated’—What Every FI/CO User ShouldKnow About This Error Messageby Rohana Gunawardena

Continued on page 3

1 This is referred to as an asynchronous update process. There are two types of update processes, V1 and V2. A single SAP transaction will have several different update processes. In either case, if an erroroccurs, details are stored in the update error log, viewed using SM13. V1 updates are the key updatesrelated to a transaction (such as post FI document, print invoice, update monthly balance tables). If anyone of the V1 updates fails, all of the V1 updates are rolled back and no V2 updates take place. Thisensures that only complete documents are posted and no “half-posted” documents occur. V2 updatesare less important update activities (updates to LIS or SIS). V2 updates occur only after all V1 updateshave completed. If a V2 process update fails, the V1 updates are kept and the successful V2 updates are kept. In this case, the main document is posted and secondary data is not fully updated. This isdesigned to stop failures in secondary systems causing the primary documents not to post.

82



problems. R/3 provides several end-usertools to detect and correct these errors.This article explains what lies behindthose error messages (Figure 1) and whatactions you should take when they occur.

First I will show you which ABAPreports detect the errors. Then I willdemonstrate how to correct the incom-plete tables. In most cases, this will allowyou to recover the information andensure your ledgers balance so that userscan trace all transactions.2 These tools areintended to be used by functional experts.However, you may wish to check withyour Basis and DBA teams as wellbefore making these corrections. Formore detail, see “What to Do When YouSee the Message, ‘Update WasTerminated,’” which you can downloadat www.ficoexpertonline.com/downloads/index.html.

Step 1: Use ABAP Reports toIdentify DifferencesThe first step is to pinpoint the docu-ment problem as an update-terminatederror. The following symptoms point toan inconsistent document:

• You cannot view documents usingtransaction code FB03

• Monthly balances in transaction codesFS10/FD10/FK10 do not match theline-item detail when you drill down

• ABAP reports show inconsistent num-bers (RFSSLD00 balances do notmatch RFHABU00 balances, FI-SLreports do not match G/L reports)

• Drill-down of line items not available

If you notice any of these signs, youcan use the appropriate ABAP report todetect documents that have not beencompletely updated. Make sure no post-ings occur while these reports run.Ideally, they should run for closedperiods. You can select one of the fol-lowing three reports:

SAPF190 – Financial AccountingComparative Analysis:SAPF190 checks that the G/L, A/P, andA/R monthly balance tables and second-ary index tables match the line-itemdetail for posted documents. This reportcalls the older SAPF070 and performs

Update Was Terminated Continued from page 1

its own checks. Do not use SAPF070directly as you will miss the more comprehensive checks of SAPF190.You should run SAPF190 at month-endto ensure that no mispostings haveoccurred. It takes a long time, so run it in background mode. The report iscomprehensively documented. OSS note86067 gives more information.

SM13 – Display Update Records:You can find update terminations withtransaction code SM13, which recordsall updates. See Figure 2. Choose All to list all users and change theSelection date to the beginning of thefiscal period.

Figure 1 Update terminated message

Figure 2 Update selection screen

2 From an SAP perspective, a document is post-ed if the BKPF and BSEG entries are consis-tent. In that case, you can recreate all otherentries with correction programs. If data ismissing in BKPF or BSEG, it may be impossi-ble to recover the missing data.

83



Double-click on one of the lines shownin Figure 3 to list all of the updatemodules. In this example, you will drilldown on FB05 in the TCode column.

The Update Modules screen (Figure 4)displays all the individual update modulescalled when you click on the save icon.The specific module that caused theerror is highlighted in red. Double-clickon the Err line to display errormessage details, which may help detectthe cause of the update termination.

RFVBER00 – FI Document: List ofUpdate TerminationsRFVBER00 (Figure 5) is a more prac-tical and detailed report for FI usersthan SM13. It provides an analysis ofall the FI documents within the SM13list in Figure 3. It takes into account FIpostings generated by other modules aswell as direct FI postings using FB01.This report enables you to keep a log of“missing” document numbers if yourauditors are concerned about continu-ous number sequences. To see the list(Figure 6), run report RFVBER00 andchange the selection dates to cover thefiscal period you are investigating.

Step 2: Correct the ProblemVia Transactions After you identify an inconsistency, youselect a report to correct the problem.The report you choose depends on thetable that is missing data. Understandingthe many FI tables affected by the termi-nated update helps you choose the bestmethod of correction. It also helpsexplain why a document missing fromone table, such as a monthly balancetotal, can still be viewed with transactioncode FB03. (See the sidebar,“Commonly Used Tables.”)

You first should try a single-recordupdate with transaction code SM13 –Display Update Records. From the

Figure 3 List of update termination errors that have occurred in the system.

Figure 4 Update Modules screen

SM13 display screen (Figure 7), selectthe item to be updated and chooseUpdate, Repeat update, and Single.This does not always work, as the statusof the R/3 system might have changedsince the update termination occurred.For instance, locks placed on tables mayno longer be valid. If this single-recordupdate does not work, you have to use amass correction program.

The following mass correction transac-tions are available for submoduleswithin R/3. This list contains only the

most common correction programs.

• G/L, A/R, A/P:

SAPF071 – Adjust Balances afterComparing Documents/TransactionFiguresWhen the run of the SAPF190 reportindicates that the monthly balances areincorrect but the index amounts areOK, use SAPF071 to correct monthlybalance tables GLT0, KNC1, and LFC1.Use this program only after thoroughlychecking the prerequisites, which arelisted in the report documentation.

84



RFSEPA01 – Switch On-Line ItemDisplay by Changing Master RecordUse this report when entries are miss-ing in the line-item detail tables, butthe monthly balances are OK—forexample, when the line item displayflag for a G/L account has beenchanged after the account was created.See OSS note 86067 for more details.

RFINDEX/ZFINDEX – FI consistency checkThe report RFINDEX is not suitable forregular reconciliations due to its com-plexity. Start report RFINDEX onlyafter consultation with SAP for problemanalysis. This is an SAP program eventhough the program’s name might beginwith a “Z” in your system. It correctssecondary index tables BSIS, BSAS,BSID, BSAD, BSIK, and BSAK. Youalso can use it to correct monthly bal-ance tables. See OSS note 195515.

Make sure the document is correctlyposted in G/L, A/R, and A/P beforeattempting to correct the submodules.

• FI-SL and EC-PCA: Use transactioncode GCU1, ABAP programRGUREC10, to re-post a G/L docu-ment to FI-SL or EC-PCA. See OSSnote 115840.

• CO-CCA: Use transaction codeOKBA, ABAP program RGUREC10,to re-post a G/L document to CO-CCA. See OSS note 45122.

• CO-PA: Use transaction code KE4S,ABAP program RKERV002, to re-post a G/L document to CO-PA. SeeOSS note 126937.

Posting corrections is not always thesolution in every situation. Here arethree examples when it is not advisable:

• Posting a correction to a prior periodcan affect publicly reported figures orcreate a reconciliation error betweenG/L and another module. If you use

Figure 5 Detailed log section of RFVBER00 at the beginning of the report

Figure 6 Summary section of RFVBER00 at the end of the report

Figure 7 SM13 display screen

85



FI-SL as your book of record forexternal reporting, you may want toupdate directly in G/L, but manuallypost an adjustment in FI-SL in the cur-rent period to avoid changing figuresreported to external parties. If G/L isyour book of record, then considercarefully how to update. A manualentry in the current period may be abetter solution than updating directlyin a closed period.

• Some errors correct themselves andneed no manual intervention. Forinstance, an automated clearing postingmay fail because of a deadlock in thedatabase. As the batch report runs everynight, the clearing takes place on thenext batch run, and a recovery of thetransaction using SM13 is not required.Users may repost documents them-selves when they discover they did notprocess properly, as when an updatetermination in manual invoicing resultsin no invoice being printed. The user

has no paper invoice and repeats theinvoicing. You have to investigate eachupdate termination to see if repostingis required.

• When a company has been through aeuro conversion or other local curren-cy modification, a minor differencebetween the monthly balance amountand the total of the line items is nor-mal. You should not correct this.3 Ifthe error occurs in a closed fiscalyear, correcting the error may causeproblems with roll-forward to futureperiods. This emphasizes the need torun checks of your balances usingSAPF190 on a timely basis.

Although the type of error described inthis article is uncommon, you shouldmonitor for possible errors by runningreport SAPF190 every month after

close. To detect errors before close,review the SM13 logs on a regular basisfor transactions that update FI/CO.

Make all corrections with care. Incorrectuse of the correction programs can resultin major errors in the R/3 system that are more serious than the ones you aretrying to correct. If you are running cor-rection programs, read their prerequisitesand make sure posting periods are closedduring detection and correction. If indoubt, call SAP OSS for support.

Rohana Gunawardena is a senior consultantwith QS&S Inc., a specialist SAP consultingfirm. Rohana has been working with SAPsince 1992, focusing on FI and CO moduleswith emphasis on business segment report-ing, cross-module integration to FI/CO,sales-cycle accounting, and A/R. He also hasexperience with SD and ABAP. He is aFellow of the Institute of CharteredAccountants in England and Wales. You may reach him at [email protected].

3 See OSS Note 151509. SAP does not recom-mend or support correcting the error in aclosed fiscal year.

Commonly Used Tables

R/3 financial document data is typically posted in the following tables. This is not an exhaustive list. Many other summary tables hold FIdata, such as ACCT++ tables. You may need to update tables relating to other modules such as FI-SL, CO-CCA and CO-PA as well.

FI-G/L, A/R, A/P – Secondary Index TablesThe line-item table BSEG cannot be indexed by account, as it isa clustered table. To enable a user to quickly find information,such as the open items for customer 13577, R/3 uses the indextables. Transactions FBL3, FBL4, and FBL5 use these tables.Each time you post a document, these tables are updated.

Table Description BSIS Accounting: secondary index for accountsBSAS Accounting: secondary index for accounts

(cleared items)BSID Accounting: secondary index for customersBSAD Accounting: secondary index for customers

(cleared items)BSIK Accounting: secondary index for vendorsBSAK Accounting: secondary index for vendors

(cleared items)

G/L, A/R, A/P – Document Master TablesThese are the main FI document tables that contain all of the dataentered for a document.

Table DescriptionBKPF Accounting Document HeaderBSEG Accounting Document Line Item

G/L, A/R, A/P – Monthly Balance TablesThese are tables used by R/3 to quickly identify the balance in a given account for a given month, instead of spending a longtime adding up individual line items. The balance sheet reportRFBIBL00 and the G/L report RFSSLD00 use these tables. Each time a document is posted, these tables are updated.

Table DescriptionGLT0 G/L account master record transaction figuresKNC1 Customer master (monthly transaction figures)KNC3 Customer master (special G/L transaction figures)LFC1 Vendor master (monthly transaction figures)LFC3 Vendor master (special G/L Transaction Figures)

86


October 2004 • www.FICOExpertOnline.com

Recently a client company of mine had asurprise when its auditors asked for proofof the G/L stock balances. When thecompany researched this data, it found adifference between the G/L stock balancesand the quantities of stock on hand accord-ing to MM tables. The company took asimple approach to verifying stock bal-ances, which was to take all stock balancesand multiply by the standard price. Theclient company found two key issues withthis approach. First, the simple stock valuecalculation did not work for my client inR/3. Second, the company had configureda custom process incorrectly, whichresulted in stock values not being recordedin the G/L.

In standard R/3 configuration (Releases1.0 to 4.7), return stock is non-valuatedand is only valuated after passing throughQuality Management (QM). My clientcompany worked in the retail jewelrytrade in which returned items have a highvalue even if they are broken, so it wantedreturns valuated immediately on receipt,not after QM. The company had changedR/3 configuration to do this, but had notupdated the configuration of ancillaryMM movement types such as cycle countadjustments. The result was all cyclecount adjustments of returned stock werenon-valuated and over a period of yearsthe small differences had built up to 1million USD.

I’m going to show you how to use transac-tions and reports, e.g., MB5L, to validate

your G/L to stock balances. I will identifya little known report, RM07MMFI, andexplain how to add this to your system ifyou do not have it already. Then I’llexplain how to correct any imbalance.First, though, to understand why this typeof problem can occur, you need to con-sider the following questions:

• How is stock valuated?

• What materials should be reflected inthe FI-GL stock balance?

• How does an individual MM transac-tion update the stock balances?

• How do you determine the total stockbalance?

• Why do differences occur between MMand FI stock balances?

• Which value is correct?

How Is Stock Valuated?A simple description of your stock valueshould be the number of items in stocktimes the standard cost for each material.Unfortunately, the calculation of stockbalances in SAP is not quite this easywhen you have to deal with manycomplex business processes that do notfall into this simple equation (e.g., vendorconsignment stock).

What Materials Should BeReflected in the FI-GL StockBalance?

Not all stock quantities held in the MMmodule are reflected in the FI-GL balancebecause not all stock is valuated stock. Ingeneral, most of the stock that a companyholds is valuated, but stock may not bevaluated in these two situations:

• Process exemption: A business processmay result in materials that are normallyvaluated not being valuated. For exam-ple, a return in standard SAP returnstock is not valuated when QM is active.A record of the quantities returned iskept in MM, but the value is not postedto FI-GL until after the return stock haspassed quality inspection. Another

The answers to six questions along with a little known report can help you to keep your MMand FI stock balances in sync.

Are Your Stock Balances Correct?

by Rohana Gunawardena, Principal Consultant, Quality Systems & Software Inc.

Stock is a major component of acompany’s balance sheets, especiallyfor manufacturing companies.Tracking ssttoocckk bbaallaanncceess in plants is amajor activity for logistic teams. SAPhas two modules dedicated to doingjust this — Inventory Management(MM-IM) and WarehouseManagement (MM-WM). When youlook at the G/L and see the balanceon your stock account, you assumethat this is the value of all of yourstock. However, in some cases thestock shown in the G/L is not anaccurate reflection of the actualstock quantities in the plants. Thiscan lead to misstated financial statements. Often this type of mis-statement occurs because the MMteam implements new businessprocesses that are not reflected in FI.

Key Concept>>

87

8 © 2004 FI/CO EXPERT Reproduction prohibited. All rights reserved.

www.WISpubs.com

example is vendor consignment stockthat needs to be counted but cannot beshown on the balance sheet until it ispurchased from the vendor.

• Material type exemption: Certainmaterial types may be configured to benon-valuated. An example is vendor-

Field Source data creation Explanation

Chart of accounts OB13 The chart of accounts used by the company code

Transaction key Preset values Preset three character codes that represent different types of business transactions. T030 containsentries for many processes not just MM, — e .g. , foreign exchange revaluation accounts. Set of valuespredefined by R/3.

Valuation grouping code OMWD This code is used to group together different company codes so that the same configuration does nothave to be repeated many times

Account modifier OMWB An additional field to allow more detailed account determination than by transaction key alone. Somevalues are predefined — e.g. , transaction key GBB — or they can be user-defined.

Valuation class OMSK A set of values used to segregate different materials. Each material is given a valuation class in itsaccounting view — can be different for each plant.

DR G/L account FS01 The G/L account selected for debit postings

CR G/L account FS01 The G/L account selected for credit postings

Explanation of T030 fieldsTable 1

owned packaging that needs to berecorded and returned to the vendor,such as gas cylinders, but that cannot beshown on the balance sheet as they arenot owned by the company. Anotherexample is DIEN (service material),which represents non-stock items such

as labor. You can see this configurationvia transaction OMS2.

How Does an Individual MMTransaction Update the StockBalances?Every time an MM document is posted fora valuated material with a valuated trans-action, a corresponding FI document isposted that adjusts the value of the appro-priate FI-GL stock account. The value ofthe posting is the standard cost of thematerial times the quantity. Several MMtables also are updated for stock quantityand stock value. See Figure 1 for an MMdocument using MM movement type 501(initial load of stock.). Figure 2 shows thecorresponding FI document.

In a simple chart of accounts design, asingle G/L account is used to store all stockbalances. However, multiple accounts areoften required to break out stock balancesin FI-GL (e.g., raw materials, consignmentstock, WIP, and finished goods).

In R/3, the plant and the material valua-tion class determine which stock G/Laccount is posted for an MM transaction.The determination of the stock account isperformed in R/3 by reading table T030(Table 1). You can configure the tableusing transaction OMWB.

MM document for initial load of stock using 501 MM movement typeFigure 1

Accounting document for an MM documentFigure 2

88



The G/L account is selected from tableT030. The key fields of table T030 areread using the logic shown in Figure 3 todetermine the stock account.

The major tables related to MM stockquantities and values are shown in Table2. It is not an exhaustive list. If you useprocesses such as sales order stock, R/3uses additional tables to store MM quan-tities and values.

Figure 4 is a flow chart showing theMM stock quantity and value updateprocess. This puts together all of thesteps shown above.

How Do You Determine the Total Stock Balance?In the previous section, I discussed howan individual MM transaction updates theFI-GL stock balances. At the initial go-live of an R/3 project, the stock balancesconversion is run with thousands of 501and 521 (commonly used to load openingstock balances) MM movement types toload all of the initial stock, resulting in theinitial stock balance being posted. Oncethe R/3 system is productive, the stockbalances move up or down based on themany daily MM transactions.

You can determine the value of stock for agiven company code in four ways:

• Multiply the stock quantities in theMM quantity tables, MARC, MARD,etc., by the standard price in the MMvalue tables

• Multiply the stock quantities in theMM value tables, MBEW, etc., by thestandard price in the MM value tables

• Add the stock value from the MMvalue tables; note that MM value tablescontain valuated stock quantity, stan-dard price, and the total value of thestock

• Add the balances of the FI-GL stockaccounts

In theory, all four of the methods shouldreturn the same answer, subject to round-ing differences. The key question is: If thevalues are different, which one of the fourmethods gives the true value of stock?

Why Do Differences Occur BetweenMM and FI Stock Balances? Before correcting any differences in thestock balances, you should identify theroot causes and correct them to preventadditional differences occurring after you

How key fields of T030 are read for a stock transactionFigure 3

Table Name Usage

MM quantity tables

MARC Plant data for material Contains material quantities that are plant specific, but not storage-location specific — e.g. , stockin transit

MARD Storage location data formaterial

Contains material quantities that are storage-location specific — e.g. , unrestricted stock. The bulkof the stock quantities are held in this table.

MSKU Special stocks with customer Contains customer-related stocks — e.g. , customer consignment stock

MSLB Special stocks with vendor Contains vendor related stocks — e.g. , subcontracting vendor stock

MM value tables

MBEW Material valuation Contains standard cost, quantity of valuated stock, and the value of valuated stock. The bulk ofthe MM stock valuation is held in this table.

EBEW Sales order stock valuation Contains standard cost, quantity of valuated stock, and the value of valuated sales order stock

QBEW Project stock valuation Contains standard cost, quantity of valuated stock, and the value of valuated project stock

The major tables used for stock valuesTable 2

89

10 © 2004 FI/CO EXPERT Reproduction prohibited. All rights reserved.

www.WISpubs.com

correct the stock balances.

In my experience, these are the mostcommon causes of stock value differences:

• Update terminations have resulted indocuments posting incorrectly. If youhave only a small stock value differencethis is the likely cause.

• Bad configuration or bad processdesign has resulted in differences, e.g.,custom movement type configuredwithout a valuation string. (The valua-tion string is defined for a movementtype in transaction OMJJ. It is used toselect the G/L account for an MMmovement type. If the valuation stringis missing in configuration, no FI-GLupdate can occur.)

• Custom programs that update the MMquantity or value tables. In R/3 youshould always avoid writing customprograms that directly update standardtables.

Over a period of years, a small number oferrors can build up and result in signifi-cant differences between the stated G/Lvalue of stock and actual stock balances.

Which Value Is Correct?When there are differences between theMM quantity and value tables, it is safestto assume that the MM quantity tables arecorrect. These are the values that MMpeople work with and the values that areused for cycle counting and physicalinventory counting. If any differenceswere detected, the quantity tables wouldhave been adjusted during the cycle countor physical inventory count. If you have alarge volume of differences, this is a safeapproach to take. Any incorrect valueswill be adjusted at the next cycle or physi-cal inventory count.

Transaction MB51 (material movementsby material) is another source of stockvalues that is sometimes used to deter-mine the correct stock balance for a

material based on the transaction historyfor the material. I do not recommendusing the MB51 value for adjusting thestock, as the balances may be incorrect ifarchiving has occurred, if MM balanceswere not rolled forward correctly, or ifdocuments are missing because of updateterminations or similar errors. MM quan-tity tables are the best basis for theadjustment. The key is to get the MMquantity and value tables in alignment,

How Do I Validate the TotalStock Balance in FI-GL?Differences in stock values can arise intwo places, first between the MM quantitytables and the MM value tables andsecond between the MM value tables andthe G/L balances (Figure 5). To ensure theaccuracy of FI-GL balance, you mustcheck and correct both points of error.

Transaction MB5K/report RM07KO01compares your MM quantity balances toMM value balances. Transaction

MB5L/report RM07MBST comparesyour G/L balance to the totals in tableMBEW. Also see SAP OSS to downloadthe newer RM07MMFI report: sap note198596 (fast MM-FI balance compari-son). It replaces RM07MBST.

When running stock value comparisonreports, be aware they have long run timesand any MM movements that occurduring the run may produce incorrectresults. It's best to run the reports as abatch job during a quiet time like Sundaymorning.

What Can I Do to Correct Stock Balances?If you have FI-MM reconciliation prob-lems, you probably need to call in SAPOSS to correct the issues for you. See thefollowing SAP notes, which apply to R/34.0 and above:

• 520010: FAQ: inconsistencies ininventory management

Comparison of stock valuesFigure 5

Stock quantity and value update process flowFigure 4

90



Rohana Gunawardena is a principal consultant with QS&S, Inc., a specialist SAP consulting firm. Rohana has been working withSAP since 1992, focusing on the FI/CO modules with emphasis on business segment reporting, cross-module integration toFI/CO, sales cycle accounting, and A/R. He also has experience with SD, PS, HR, and ABAP. He is a Fellow of the Institute ofChartered Accountants in England & Wales. He can be reached at [email protected].

• 34440: procedure for correcting thematerial master

• 32236: incorrect stock quantity/stockvalue in material master

• 204393: error in material accountingview (table MBEW)

•76926: checklist for material inconsisten-cies (value, quantity)

SAP OSS will undertake the stock balance corrections for you. It requires you to loadcorrection programs into your system asidentified in the notes. Because of thesomewhat complex nature of these correc-tions, R/3 works directly in your productionsystem. Immediately after an adjustment is

In the case of the cycle count adjustmentsthat were non-valuated, the client:

• Posted the reverse movement types

• Corrected the movement type configu-ration to be valuated

• Reposted all of the movements so thatthe stock balances were correct and theFI-GL postings were made

This corrected about 80 percent of thestock value differences between MM andFI-GL. Even after the cleanup of cyclecount errors, other small errors werefound and SAP was called in to get a 100percent match between the MM and FI-GL stock balances.

made to the tables, you should select all the materials that were adjusted for cyclecounting. R/3 will provide you with a list of adjusted materials.

How the Correction Was MadeLet’s go back to the client company I originally mentioned, which had to tell itsauditors how its G/L stock balances werecomposed. After reading the article so far,you know that simply multiplying all stockbalances by their standard cost does notgive the correct stock value, as you willinclude non-valuated materials in your cal-culation. Also, many people miss key tablesthat contain stock values by focusing onMARC and MARD quantity balances only.

91


April 2006 • www.SAPFinancialsExpert.com

When performing the basic configuration

for all financial modules, the term “cur-

rency type” inevitably crops up. It’s a key

choice you make early in finance configura-

tion that can be difficult to change later on.

Configuring General Ledger Accounting

(FI-GL) or Special Purpose Ledger (FI-

SL) to store values in multiple currency

types enables you to track a single trans-

action in multiple currencies, referred to

as parallel valuation. This allows you to

perform reporting quickly in different cur-

rencies. For more about parallel valuation

with the new General Ledger (G/L), see

“Streamline Your Parallel Accounting with

the New G/L Ledger Solution,” by Aylin

Korkmaz in this issue.

Consider a UK company, with local cur-

rency (also known as company currency

in SAP) of British pounds (GBP), that is a

subsidiary of a French company with local

currency euro (EUR). For local reporting,

the UK company produces reports in GBP,

while for group reporting the corporate

head office needs consolidated reports in

EUR. Storing transaction values in both

GBP and EUR allows you to meet both

reporting needs quickly. If transaction

values were stored in GBP only, the GBP

values would have to be converted to

EUR whenever consolidated group reports

were required, slowing down the process.

You can also use currency types to store

transaction data at different valuations. For

example, when you make an inter-company

sale using a transfer price, you (the selling

company) make a profit. However, this

intercompany profit can not show on

consolidated group reporting. Storing trans-

actions with both legal and group valuation

allows you to produce both local company

accounts, with the intercompany profit, and

consolidated group accounts, without inter-

company profit, quickly.

I will explain what a currency type is and

how it affects financial reporting. I use

values found in SAP R/3 Release 4.7,

although the information and steps I give

apply to all SAP R/3 releases from 3.0 to

mySAP ERP Central Component 5.0. You

will have the information you need to

determine the currency type configuration

suitable for your organization.

Currency TypesA list of all of the currency types available

in SAP is available in the Downloads

section of SAPFinancialsExpert.com.

Table 1 (on the next page) shows a detailed

list of currency types with references to

tables and configuration transactions. Note

that not all currency types are available in

all modules. For example, Profit Center

Accounting currency is not available in G/L.

Currency Type Table The following are the three most-used

currency types in SAP configuration:

• DC - document (transaction) curren-

cy (00). The user enters the document

currency (also known as transaction

currency) in the document header of

each posting (e.g., transaction FB01

or GD21) or uses the document cur-

rency the system chooses by default.

The transaction currency can be differ-

ent for each transaction posted and

can be any currency configured in

SAP, as long as you maintain the

related exchange rates. This currency

is compulsory for FI-GL, FI-SL, Profit

Center Accounting (EC-PCA), and

other modules.

Do you know what the different currency types are, where they are configured, and when to use

them? Confusion abounds in this area, especially when dealing with parallel valuation. Use this

roadmap to gain control of all of your conversions and valuations.

Currency Types: The Key to Reporting Parallel Valuations


You are probably familiar with thecurrency codes in SAP (e.g., UnitedStates dollars [USD], euro [EUR],Japanese yen [JPY]). These indicatethe specific currencies used torecord transaction values. CCuurrrreennccyyttyyppeess control the specific currencycodes in which financial transac-tions are recorded. In SAP, a singlefinancial transaction is recordedusing multiple currency types. Aminimum of two currency types isused to record all financial transac-tions in General Ledger Accounting(FI-GL), document currency, andcompany currency. Different cur-rency types may map to the same or different currency codes for aspecific transaction based on thedata input (e.g., company code, costcenter, document header currency).

Key Concept>>

92


www.WISpubs.com

• LC - company (local) code currency

(10). Company currency, also known as

local currency, is the currency assigned

to a company code when it is config-

ured in transaction OBY6, table T001.

This currency is compulsory for FI-GL

configuration.

• GC - group (client) currency (30).

This is the client-wide currency of the

group of companies in the SAP system.

The best choice is your corporate exter-

nal reporting currency for a listed com-

pany or head office currency. You con-

figure it once per client using OY24,

table T000. Set the currency before

your system becomes productive. It is

possible but difficult to change group

currency after go-live. Group currency

is a good choice for a consistent multi-

ledger, multi-module currency type

rather than ledger-specific currency

types 20, 80, or 90.

A common problem I encounter is

failure to activate group currency for

FI-GL and CO when they first go live.

Doing so later is often problematic and

requires outside assistance, as I will

discuss later.

See Figure 1 for an example of an FI-GL

document posted with the following three

currency types, where each currency type

maps to a different currency code:

• 00 DC USD

• 0 LC GBP

• 30 GC EUR

When displaying an FI-GL document

you can change the displayed currency

type in the FB03 overview screen

(Figure 2).

Actual selection of currency code for a

currency type depends on each specific

transaction. See Figure 3 for examples

of different transactions and how the cur-

rency types map to actual currency codes.

LedgersIdeally, all ledgers should use the same

currency types to avoid translation and

reconciliation issues, as represented in

the diagram in Figure 4. However,

Type Description Transactioncode

Table Module Valuation Comments

00 Document (transaction)currency

FFBB0011, GGDD2211,etc.

BBKKPPFF, etc. Multiple NA Can be different for every transaction. This currency type isrecorded for each transaction in every ledger.

10 Company (local) currency OOBBYY66 TT000011 FI-GL 11, 12 The primary currency used for legal reporting and is recorded inmost ledgers

20 Controlling area currency OOKKKKPP TTKKAA0011 CO NA Use group currency instead if possible. This currency type ismodule-specific and can cause conversion problems.

30 Group (client) currency OOYY2244 TT000000 Multiple 31, 32 System/client-wide currency type

40 Hard currency OOYY0011 TT000055 Multiple NA Used for high-inflation countries

50 Index currency OOYY0011 TT000055 Multiple NA Used for high-inflation countries

60 Global company currency GGCCGG22 TT888800 FI-SL NA Generally company currency is used instead of global companycurrency.

70 Object currency KKSS0011,KKOO0011, etc.

CCSSKKSS,AAUUFFKK, etc.

CO 71, 72 Usually the same as the company code currency to which theCO object belongs

80 Ledger currency GGCCLL22 TT888811 FI-SL 81, 82 Use group currency instead if possible. This currency type isledger specific and can cause conversion problems.

90 Profit center accountingcurrency

OOKKEE55 TTKKAA0011 EC-PCA 92 Use group currency instead if possible. This currency type isledger specific and can cause conversion problems.

A0 Financial managementarea currency

OOFF1144 FFMM0011 FM NA Use group currency instead if possible. This currency type isledger specific and can cause conversion problems.

B0 Operating concerncurrency

KKEEAA00 TTKKEEBB CO-PA B2 Use group currency instead if possible. This currency type isledger specific and can cause conversion problems.

C0 Consolidation unitcurrency

CCXX11MM TTFF116644 EC-CS C1, C2 Use group currency instead if possible. This currency type isledger specific and can cause conversion problems.

Summary of currency typesTable 1

Currency Type Table

FI-GL document showing different DC, LC, and GC amountsFigure 1


93



Ideal situation: all ledgers use the same currency typesFigure 4

Actual currency code for each currency type depends on the specific transactionFigure 3

DDiissppllaayy ccuurrrreennccyy button allows you to switch currency types in the overview displayFigure 2

>>NoteOther ledgers (e.g., ProfitabilityAnalysis [CO-PA], Enterprise Controlling - Consolidation [EC-CS], EC-PCA, and MaterialLedger [ML]), can have currencytypes configured in similar ways. In most cases the configurationscreens for these modules aresimilar to the FI-SL screen.

94


www.WISpubs.com

different ledgers in your system can use

different currency types (Figure 5). His-

toric configuration in your system or

special reporting requirements may neces-

sitate it. For example, when you first went

live with SAP you did not activate group

currency for FI-GL, but you activated

group currency for FI-SL later. This is

not an ideal situation, as it can lead to

translation issues between ledgers,

which I will discuss. Also, not all currency

types are available when configuring a

ledger. For example, you cannot use the

CO-PA operating concern currency when

configuring EC-PCA.

Currency Type ConfigurationLet’s look at where the currency types

are configured for two different ledgers,

FI-GL and FI-SL. FI-GL currency types

are configured using transaction OB22

(Figure 6). FI-SL currency types are con-

figured once per ledger using transaction

GCL1 (Figure 7). Keep the same settings

for each company code.

When choosing currency types for a

module, try to choose the common

system-wide currency types, DC (00), LC

(10), and GC (30). If you choose a module-

specific currency type (e.g., (currency [80])

for FI-SL, this gives you the freedom to

choose the currency code that maps to the

currency type, but potentially causes trans-

lation problems when data feeds from

FI-GL to other modules. In some cases,

such as controlling area currency (20), SAP

advises you to use group currency (30)

instead. See SAP notes 119428 and 314936.

Sometimes you have no alternative but

to choose a module-specific currency to

meet your reporting requirements. For

example, you have a US-based company,

with group currency USD, with multiple

companies in Europe. The European

region requires consolidated accounts in

EUR. To get this reporting you can create

a new ledger in FI-SL, EC-PCA, or EC-

CS with EUR as a module-specific

Different currency combinations active in each ledgerFigure 5

FI-GL currency type configuration screen, transaction OOBB2222Figure 6

FI-SL currency type configuration screen, transaction GGCCLL11Figure 7

>>continued from page 10

95



the first local currency. See SAP note

335608.

The FI-GL module allows you to config-

ure up to four currency types, while most

other modules, including FI-SL and EC-

PCA, allow up to three for a single ledger.

Should you require more than three

currency types, you have to configure

a parallel ledger in FI-SL. The parallel

ledger has exactly the same structure as

the first ledger you create, except that it

has different currency types configured.

This may be required for EC-PCA if you

activate one of the additional valuation

types and still want to maintain reporting

in legal valuation. Remember that EC-

PCA is just ledger A8 in FI-SL, so create

a custom copy of the A8 ledger, (named,

for example, Z8), in FI-SL. Then config-

ure this ledger with the additional

currency types and have all the same

transactions that post to ledger A8 post to

ledger Z8, the new parallel ledger.

Changing Currency TypeOnce a ledger is productive and transac-

tions have been posted, adding another

currency type or changing a currency

type takes a lot of work. For example,

say FI-GL was configured initially with

DC and LC only, and now you want to

add GC. In these cases you must call in

the SAP System Landscape Optimization

Group to make the change for you (see

SAP notes 27621 and 39919). This change

is not impossible. For example, during the

Euro conversion in 1998-1999, a German

company’s currency code would have

been changed from DEM to EUR and

the LC values of all transactions would

have been converted from DEM to EUR.

There is one exception for CO (see SAP

note 314936).

Currency Type TransactionsThis section covers scenarios that high-

light the problems of misconfigured

currency types for multi-ledger/module

SAP Financials environments. First I will

show how data posted in sender ledgers

FI-GL and CO get to receiver ledgers FI-

SL, EC-PCA, EC-CS, and so on. You use

the RWIN interface (Figure 10) to post FI

data to multiple modules.

With misconfigured ledgers you may

run into problems such as a different DC

value from GC value even if both are the

same currency (Figure 11).

This type of difference can occur when

FI-GL is configured with just DC and

LC while FI-SL is configured with DC,

LC, and GC. When the FI-GL document

is posted the user enters both a DC and

LC value with a manually calculated

exchange rate of 1.70. When the document

is posted to FI-SL, the GC value is calcu-

currency, using currency type 80, 90,

or C0 respectively.

Source Currency TypeWhen configuring the ledger or module,

you can specify the method of calcula-

tion for the additional currency types

(Figure 8). This affects the value of

the additional currency posting. When

posting an FI-GL document, the user can

enter a value in one currency field only

(e.g., document currency) and the SAP

system automatically populates the other

currency fields (such as group currency)

using the source currency rules you

define. You have the choice of transaction

currency or local currency (Figure 9).

SAP recommends converting from

Specify the method of calculation for additional currency types

Figure 8

RWIN is the interface used to post FI data to multiple modulesFigure 10

FI-SL document with different USD values in TC and GCFigure 11

Source currency type optionsfor translation to additionalcurrencies

Figure 9

96


www.WISpubs.com

lated from the LC value using the M rate,

the default rate in SAP, of 1.24. This

results in the DC value in USD and GC

value in USD being different (Figure 12).

Let’s look at a more dramatic example

where the use of ledger currency (80)

instead of group currency (30) in FI-SL

can cause problems when both map to

the same currency, EUR. In this example,

transaction FBB1 is used to make a

group currency only adjustment entry

of EUR 200.00 in FI-GL (Figure 13),

which is expected to flow through to FI-

SL. In FI-SL, use of ledger currency

results in the local currency value 0.00

GBP being converted, resulting in a

posting of 0.00 EUR in FI-SL (Figure 14)

instead of the expected 200.00 EUR.

For more details on this type of problem,

see SAP note 142367.

As mentioned earlier, the specific cur-

rency to which a currency type maps

varies for each transaction depending on

the values entered by the user, such as

company code and cost center. To get the

specific currency code for a currency type,

use function module G_CURRENCY_

FROM_CT_GET found in the function

test bed of transaction SE37. You need

to supply additional transaction data

(e.g., company code) to get the specific

currency code.

Valuation TypesSupplemental valuation methods are

used to store transaction data valuated for

transfer pricing, consolidation, and other

internal valuations aside from the normal

transaction value (Table 2). Create valu-

ation types other than the normal legal

valuation (x0) only as part of an integrated

scenario, which requires you to define an

appropriate currency and valuation profile

for the controlling areas affected.

The currency and the valuation method

are combined in the financial accounting

document to form the currency and

valuation type. For example, if you want

Missing GC in FI-GL leads to inconsistent value in FI-SLFigure 12

Group currency only FFBBBB11 adjustment entry in FI-GL Figure 13

How an incorrect value can get posted to FI-SL when ledger currency is usedFigure 14

List of valuation typesTable 2

Valuation code Description

x0 Legal valuation

x1 Group valuation

x2 Profit center valuation

97



to make a group valuation in the group

currency, SAP uses currency type 31.

Only some currency types allow the

addition of valuation types.

ConfigurationValuation type is configured in the same

transaction as the currency type but in a

different field. For FI-GL configuration,

use transaction OB22. For FI-SL ledger

configuration, use transaction GCL2.

Often multiple valuations are activated

after the SAP system has been active for

several years. If the controlling area cur-

rency is the same as the group currency

and material ledger has not yet been used,

you can activate multiple valuations in the

standard system without having to carry

out a conversion (see SAP note 120380

for more details). You need to compare the

as-is and to-be environment carefully to

determine the level of complexity.

Transfer PricingTransfer price is a negotiated price between

two organizations belonging to the same

group of companies. It may be based on

the market price, or it may be determined

as a markup on the cost of goods manufac-

tured as seen from the legal valuation.

These markups can depend on a number of

factors, such as the profit centers involved,

the product, plant, date, and so on.

Legal ValuationCurrency types ending with a 0 denote

Legal Setting (for example, currency

types 10, 30, 40, and 50). This is the

standard valuation type and represents

normal valuation of business transactions.

Group ValuationMany groups valuate exchanges of goods

between affiliated companies using a group

cost of goods manufactured (i.e., without

internal profits). The receiver profit center

receives a semi-finished product at cost.

In this approach, profit centers only earn

profits with unaffiliated companies and not

for internal transactions.

Used for consolidated reporting where

internal profit or mark-up is not included,

currency types ending with 1 denote a

Group Setting (for example, currency

type 31). It uses transfer pricing to monitor

internal profit and loss between compa-

nies. The ML and CO modules must be

active; EC-PCA does not have to be active.

Profit Center ValuationAs of SAP R/3 3.1, you can valuate busi-

ness transactions in EC-PCA with the

same method used for the individual

financial statements of the companies in

a group. If you use your profit centers to

monitor their internal profits, you must

activate transfer pricing for exchanges

between profit centers. These transfer

prices are selected automatically for goods

movements (stock transfers, goods usage)

between profit centers and are shown as

Internal revenue and Internal costs in

EC-PCA. Thus a goods withdrawal for a

production order is shown as a sale in

EC-PCA, whereas the same transaction

is a consumption posting when seen from

the point of view of the company code.

To activate profit center valuation, the

EC-PCA, ML, and CO modules must be

active (see SAP note 119773 for an excep-

tion). You need to activate special pricing

conditions in SD for internal sales. Internal

revenue and inventory change journal

voucher (JV) lines are added to inventory

postings in the profit center valuation view.

Once you activate profit center valuation

for EC-PCA, legal valuation in EC-PCA is

not possible. You may need a shadow PCA

ledger (see SAP note 861965).

Inflation AccountingIn the 1970s, in addition to bad haircuts,

high inflation rates were all the rage,

sometimes in excess of 1,000% a year.

When accounting for transactions over

one year using a high-inflation currency,

the results were highly unreliable. To

avoid this type of reporting problem,

companies recorded transactions in both

the local currency and a hard or more

stable currency, often USD.

SAP provides two methods of inflation

accounting using currency types, hard

currency (40) and index currency (50).

A hard currency is assigned to a country

code in transaction OY01, table T005.

When a transaction is posted, the system

selects the hard currency based on the

country key of the company code.

The same system works for the index

currency method. Rather than a hard

currency, inflation is calculated using

an index currency, which is a fictitious

currency stipulated for external reporting

(such as tax returns) in some countries

with high inflation. �





98



office, suspecting that this is a timing issue, asks the region tosend a copy of the report. The incorrect report is marked07:00 a.m. 6-May. Knowing whether this is in local or systemtime assists in analyzing the problem.

As part of your general error analysis process, you shouldmake sure that all reports output their runtime on all pages.Even if you do not have entities in many time zones, this isuseful when you run the same report several times aftermaking financial adjustments and are not sure which has thelatest set of figures.

Note! Remember that companies with operations only inthe United States could have users in up to seven timezones if you consider Alaska, Hawaii, and Puerto Rico.

The key to a smooth close is having a well-defined processwith a clear timetable that has been distributed to all the keyfinance users. Users should clearly understand what theirdeadlines are for preparing financial data. The following eight tips can help smooth over problems you may encounterduring close.

1. User Time Zone: Let’s start by looking at the Personaltime zone field, which defines a time zone that represents a

When a global company has a period-end close, a great deal ofcoordination needs to occur among the independent locations tomake sure that tight deadlines are met. Often, month-end issuesand misunderstandings occur because of timing differences.They include confusion over:

• When close activities should be performed

• Timing of batch job start times

• Reading timestamps for SAP transactions

• When a report output was created

Let’s look at an example of the confusion created by lack of clarity as to when reports and batch jobs were run in an organization with users in multiple time zones: A regionalanalyst calls the head office saying a report is wrong. Theregional office has created a Report Writer extract, and itlooks as if an allocation run has not completed. The headoffice investigates, looks at the batch job, and sees that it didcomplete. The head office runs the report and everything is allright. What happened? The regional site ran the report beforethe allocation run completed. However, the Report Writerreport shows the local time in the header, and it looks as if thereport ran after the allocation run.

Making sure the headquarters office and regional sites are clearon timing and time zones can help prevent this type of confusion.The risk of this type of error can be greatest for users who arerelatively close — for example, U.S. Eastern Standard Time(EST) and Pacific Standard Time (PST). As times vary onlyby a few hours, it’s easier to confuse local and system times.

Figure 1 shows a global close for a company with its head-quarters office on the U.S. East Coast. The system time isEST. A regional company has a process going on during itsdaytime, which is overnight for the headquarters office. If abatch job run during the night at headquarters takes 20minutes longer than normal, the subsidiary might run a reportbefore the job completes and think an error has occurred. Theregion then calls the head office to investigate. The head

Account for Time Zone Differences So That They Do Not Affect Your Global Closeby Rohana Gunawardena, Senior Consultant, Quality systems & Software, Inc.

Figure 1 Month-end close processes with local start timesfor a global corporation

99

enables a consistent timestamp to be placed on all transactionsso the correct order of transactions is recorded regardless ofwhere in the world they originated. In the case of Figures 6and 7, you can see that logistics transactions MB11 andVL02 take account of the Personal time zone setting, aswell as FB01.

4. Standard FI report header: Most standard FI reports, usually named RF****** (e.g., RFSSLD00) use a commonheader routine. You can apply SAP notes to show the localtime zone together with the time zone code in the header sothat the exact time is clear on the reports. Check SAP note

user’s home location. This setting is required, as the user maybe located in a different time zone than the SAP systemhardware. The system time zone represents the time zonethat is the basis for SAP system transactions. Usually, this isthe time zone of the company’s head office, which can bedifferent than the time zone in which the SAP system isphysically located.

Users can define their own local time zones in the userdefault settings via transaction SU3 (menu pathSystem>User profile>Own data). Press the Default tab tosee the time zone. Then the system can print the correcttime. (See Figures 2 and 3.) The external format depends onthe user settings for the date format. In this case, the userhas selected the Japanese date format of YYYY.MM.DD.

Sometimes users are not initially set up with the correcttime zones, so do not assume a user in a region has thecorrect regional time zone. For example, a new user couldbe set up in a regional office with a copy of the user ID ofhis head office counterpart and end up with the head officetime zone as the default time zone.

If you are a user located in the head office, the personaltime zone does not present any problems for you. However,if you are located at a regional office, this can be an issue,because R/3 uses the Personal time zone setting to deter-mine how the system behaves. For example, if the headoffice is in New York and the time is 10 p.m., May 25, andyou are a user in Tokyo where the time is noon, May 26,you have different expectations of system behavior.Consider the case that May 25 is the last day of the fiscalperiod. In New York, a user expects transactions to post toperiod 07, while in Tokyo, a user expects transactions topost to period 08.

2. FI Documents (Default Document Date): For FI documententry (transaction FB01), the posting date is always adefault based on the user’s local date (Figures 4 and 5). Say at the end of the day for a U.S. East Coast company that the posting date is 05/25/2003. The company’s Japanesecounterparts, who are just arriving at work, would have aposting date of 05/26/2003 at that time. During most of thefiscal period, this is not an issue. However, at close, the difference can become a problem. During the close periods,all users should be careful of the posting date they use toensure transactions are posted in the correct fiscal period.

3. FI Documents (Entry Date): The entry date in the FI andCO document header is always in system time (Figures 6and 7), regardless of the user’s personal time zone. This

Figure 5 Posting date defaults based on user time zone for auser in New York

Figure 4 Posting date defaults based on user time zone for auser in Tokyo

Figure 3 Set personal time zone in user defaults via transaction SU3 for a user in New York

Figure 2 Set personal time zone in user defaults via transactionSU3 for a user in Tokyo



100



598133 (No time zone in the report header) and note452485.1 (See Figures 8 and 9.)

Note that this company has further modified the header toshow the system name and client on the left side. This isuseful when you are testing reports across systems, so youdon’t get confused between production and developmentsystem results.

5. Report Writer/Painter reports: In your custom ReportWriter/Painter reports, you can set up the header text to showboth local and system time, as shown in Figures 10 and 11.Here you select the fields from the standard variables pop-upmenu, which is available in transaction GR32. To modify areport, go to Texts and select the header, footer, or other textas appropriate. In the text editor, press the standard variablesbutton to get the pop-up:

• Local date LOCAL_DATE• Local time LOCAL_TIME• Local time zone LOCAL_ZONE• Selection date SEL_DATE• Time of selection SEL_TIME

The system time zone is not available as a variable, but youcan hard-code it in the header. It should never be changedafter the system becomes productive, because all previouslystored times would become invalid — e.g., creation time foran FI document.

1 Georg Tewes, FI Development, Germany, wrote this note, which resolvedan issue for a client with whom I was working.

Figure 8 Standard FI report header showing user time zone for a user in Tokyo

Figure 7 FI entry data is in system time for a user in New York

Figure 6 FI entry data is in system time for a user in Tokyo

Figure 11 Definition of header fields for Report WriterFigure 10 Report Writer report with both system and localtime in the header

Figure 9 Standard FI report header showing user time zone for a user in New York

101

8. Configuration: Configuration for time zones is in the IMG.Usually, these settings do not need to be changed by theuser. If you are missing entries in these tables, look at SAPnote 198411, which leads you to an SAP download and references to many related notes.

The configuration for time zone selection based on geographiclocation (transaction STZGC) is used to automatically populatethe time zone in the customer master, vendor master, and otherbusiness objects that use central address management. (SeeFigure 13.) The customer or vendor time zone is used inmany modules to determine the time of service delivery. In theService Management module, the customer’s local time is displayed in a service order so that the user knows when acustomer can be contacted. (See Figure 14.)

Rohana Gunawardena is a senior consultant with QS&S, Inc., a specialist SAP consulting firm. Rohana has been working with SAPsince 1992, focusing on the FI/CO modules, with emphasis on businesssegment reporting, cross-module integration to FI/CO, sales-cycleaccounting, and A/R. He also has experience with SD, PS, HR, andABAP. He is a Fellow of the Institute of Chartered Accountants inEngland & Wales. He can be reached at [email protected].



6. Batch Jobs: When you define batch jobs with transactionSM37, the start time is always in system time, regardless ofyour user time zone. (See Figure 12.) Make sure regional usersare aware of this, as their batch jobs may start at unexpectedtimes. This also applies to all times recorded in the batchjob log. R/3 gives the appearance that batch jobs can bescheduled using local time, as the F4 help pop-up for timehas a button that allows a time zone to be selected.However, this does not affect the batch job runtime.

The time set for the batch job is system time. It is affectedby changes between Daylight Saving Time and StandardTime. As Japan, for example, does not have Daylight SavingTime, a change in the system time to account for daylightsaving has an impact. Users in the home region do not expe-rience any difference, because their daily schedule adjustsfor Daylight Saving Time.

When scheduling batch jobs for regions, keep in mind that itmakes very little difference for the head office if a job runsat 1 a.m. or 2 a.m., but it has a large impact for regionswhere this is the middle of the day.

7. Timestamps in custom reports: Timestamps can oftencause problems in a regional office that go unnoticed in the head office. A regional user may receive a report in themiddle of the day marked 3 a.m. Is this a report that ran at 3 a.m. local time and got stuck in the print queue, or is it areport that ran recently with a head office timestamp? If youwant times to be printed out in custom ABAP reports, decidewhether to use local or system time, and let the programmerknow the specifications. The programmer can use theSY-TIMLO, SY-DATLO, and SY-ZONLO fields toshow local time and the SY-DATUM, SY-UZEIT, andTTZCU-TZONEDEF fields to show system time when programming an ABAP report.

Most companies have ABAP standards so that all reportshave headers with runtime, report name, user name, etc.Check if your standards take account of time zone settings.Ideally, both local and system times with time zone codesshould be printed in the report header.

If you need to perform time zone conversions in your customABAP reports, a programmer can use the WRITE f TIMEZONE tz syntax in ABAP to perform the conversion foryou, or the programmer can use one of the following function modules: TZ_GLOBAL_TO_LOCAL,TZ_LOCAL_TO_GLOBAL, TZ_LOCAL_TO_SYSTEM,or TZ_SYSTEM_TO_LOCAL. Ask your programmer toreview function groups TZN*, using transaction SE37, formore time-related function modules.

Figure 14 Customer’s local time displayed in service order

Figure 13 Time zone field automatically populated basedon country, region, and postal code

Figure 12 Batch job start times and job log times are alwaysin system time

102

A key period-end activity is determiningstock balances and ensuring a clean cutofffor transactions posted in the old periodand the new period. Stock balances areprimarily controlled in the MaterialsManagement (MM) module, but have asignificant impact on the FI balance sheet.Often I am asked what the link is betweenthe MM period close and the FI periodclose, how they impact each other, andwhat to do to ensure a clean cutoff of MMtransactions at month-end.

Companies with plants in multiple timezones have extra considerations for aclean cutoff. Under US GenerallyAccepted Accounting Principles (GAAP),the cut-off for transactions at any locationis midnight local time, not midnight of theSAP system time. For a clean cutoff, youneed to prevent posting of MM documentsto the closed period after the cutoff. Manypeople are unaware that this is possible inR/3. I will show how to prevent this andgive an example in which using MM andWarehouse Management (WM) can add tothe problem.

I will explain the inter-relationshipbetween the MM and FI period close,what the MM period close does, and,more important, what the MM periodclose does not do. Finally, I will show you a scenario in which the MM periodclose can cause problems when you try to reconcile prior period MM balances to the FI balance sheet. Understanding this

is critical if you have to reconcile MMperiod balances to the FI balance sheet.

As I have stated in previous articles, whensetting up interfaces such as period close,the FI and logistics teams need to worktogether closely. The FI team needs toeducate the logistics team on the financialimpact of its transactions and configuration.

MM Period CloseWhat does the MM period close do? Youperform the MM period change withtransaction MMPV, which is the same asABAP RMMMPERI. You can only postMM documents to the current and priorfiscal period as defined by the MM periodchange (Figure 1). The current and priorperiod values are stored in transactionOMSY, table MARV, by company code(Figure 2). Later on I will show you howto restrict MM postings to the currentperiod only. The MM period close used tobe quite time consuming, but runs quickly

after R/3 Release 4.5A. See the sidebar on page 6, “Revise Batch Jobs,” for moredetail.

Understanding what MM period closedoes not do is actually more importantthan knowing what an MM period changedoes. The FI posting date for the FI docu-ment related to a MM document is notcontrolled by the MM period close. Justbecause the MM period has changed, therelated FI documents do not post to a newfiscal period automatically. In practice thismay be what appears to happen, but thedetail is more complex. The posting dateis selected based on the user’s default timezone (Figure 3). After midnight on thelast day of the period, user’s local time,any MM transactions posted by a user


www.WISpubs.com

The posting of MM balances to anMM period is dependent on thefixed time of the MM period roll,while the posting of a FI documentto a FI period is dependent on theposting date, which is derived froma user’s default time zone.

Key Concept>>Your cutoff for transactions at close may be affected if you don’t understand the relationshipbetween the MM period close and the FI period close. You can configure your R/3 system toensure a clean cutoff for MM transactions at period close.

Avoid a Disconnect Between Your MM and FI Period Closes


This error message shows which posting periods are open for MM transactionsFigure 1

103



Transaction OMSY, table MARV, contains MM period settings by company codeFigure 2

Default time zone in user profile controls posting periodFigure 3

changes. Try the values UTC+12 andUTC-12, which are at the extremes of thetime zone scales.

You can see that since the MM periodclose is performed using transactionMMPV and is done once per companycode, it affects all plants at the same timeregardless of their local time zone. In thecase of the matching FI postings, thefiscal period is selected based on theuser’s default time zone, which may varyfrom plant to plant. This is where the dis-connect occurs between the way MM andFI determine in which period a transac-tions falls. In the case of a company in theUS with a plant in New York and a headoffice in Los Angeles, the disconnect lastsfor a three-hour window. If no MM trans-actions occur during this period, there isno problem. However, many companieshave continuous operations at plants orhave late-night shipping as closeapproaches, which results in MM transac-tions falling into the window of inconsis-tent MM and FI period determination.

Consider the case of the US company withheadquarters in Los Angeles (PST) and awarehouse in New York (EST). Getting aclean MM cutoff can be difficult if thewarehouse has a 24-hour operation.According to US GAAP, the cutoff for theperiod is at midnight local time for eachplant, not midnight system time. This isthree hours earlier in New York than inLos Angeles. For the FI cutoff this not anissue because each user is set up with thecorrect local time zone. For the MMcutoff this is a problem because the periodchange can occur only once for the wholecompany code, and usually it is set to bemidnight head office time zone. The MMperiod close can only be run once percompany code, so this is done at the headoffice at midnight, while individual MMtransaction such as a goods receipt orgoods are posted using local time zone ofthe warehouse.

As shown in Figure 4, any MM postingsbetween midnight and 3 am EST posted

Posting periods for MM transactions made in New York are out of sync withthe MM period close for three hours between midnight and 3:00 am EST

Figure 4

LA-PST FI period (LA-PST)

MM period NY-EST FI period (NY-EST)

Pacific StandardTime

Posting periodbased on user'sdefault time zone

Close once for allplants in thecompany

Eastern StandardTime

Posting periodbased on usersdefault time zone

8:00 pm 01/2005 01/2005 11:00 pm 01/2005

9:00 pm 01/2005 01/2005 12 midnight 02/2005

10:00 pm 01/2005 01/2005 1:00 am 02/2005

11:00 pm 01/2005 01/2005 2:00 am 02/2005

12 midnight 02/2005 02/2005 3:00 am 02/2005

1:00 am 02/2005 02/2005 4:00 am 02/2005

Difference

automatically default to a new postingdate and post to the new period in FI.

The impact of the user time zone appliesequally to regular FI postings with transac-

tion FB01. To test this out, change yourdefault time zone via transaction SU3,save the change, log off and log on to R/3,and then call up transaction FB01. Youwill see that the default posting date

104

Note>>

Only a single MM period is open after setting DBp flag in OMSYFigure 6

in New York go to different MM and FIperiods. From a GAAP perspective this isall right, as the transactions posted to thecorrect FI period. Problems occur if yourun any standard SAP MM value reportsusing the prior period setting. Transactionsin the three-hour window won’t match tothe same MM and FI period (e.g., transac-tion MB5L, ABAP RM07MBST). If yourun it with the current period setting, thereport is OK.

If you have the material ledgeractive, then a record of stock bal-ances based on the FI postingperiod is kept and accurate historicstock balances can be viewed. Thisis probably not justification in itselfto implement the material ledger,but if you already have it imple-mented, it gives you an alternatesource to get accurate stock bal-ances. This is especially useful ifyour auditors request you to proveyour FI-G/L stock balances at thematerial level.

As I mentioned, to make sure a cleancutoff is maintained you need to preventMM users from posting transactions to theprior period. Usually the old FI period iskept open for the first few days of the new

The user cannot post to the closed MMperiod (Figure 6).

Note one caution with making this config-uration change. If you have plants in mul-tiple time zones and the MM period closehappens prior to midnight at the plant inthe last time zone (the plant that gets tomidnight last), then the plants operatingafter the MM period close will not be ableto post to the correct period. In the case ofthe example of a plant in New York andhead office in Los Angeles, this is a goodsolution as the MM period close is at mid-night PST after New York has moved to


www.WISpubs.com

>> Revise Batch Jobs

If you set up your MM period change batch jobs when youfirst went live with SAP, review the timing of these jobs asthe period change now takes only a few seconds. In previousversions of SAP the period close could take several hoursand batch jobs were timed for this. After R/3 Release 4.5A,you can easily run the job at exactly midnight to get anaccurate cutoff. The batch job will be for ABAP RMMM-PERI. See SAP note 171465 for more details.

When setting up the batch job choose the Close period onlyoption (Figure 1). The Check and close period option takes

a long time to run. It is best to run the check period option afew days before your actual month-end to detect errors inMM postings and give you time to clean up.

Choose Close pperiod oonly when performing theperiod close

Figure 1

The user can manually adjust the MM posting dateFigure 5

period for close adjustments (e.g., elimi-nation entries, overhead allocation).

As long as the prior period stock balanceaccounts are open for posting, the MMuser can backdate the MM posting date tothe prior period (Figure 5). To ensure aclean cutoff you may wish to preventposting MM transactions to prior periods.In transaction OMSY set the DBp flag todisallow back-posting after a change ofperiod (Figure 2). MM postings can onlyoccur for the current fiscal period. Thefull effect of this setting change onlyoccurs after the next MM period change.

105



It may not seem that MM users woulddeliberately backdate postings such as agoods receipt, so I want to show you aproblem that I have come across at sitesthat have implemented MM-WM. In thecase in which MM-WM is implemented,the post goods issue (PGI) date of an MMdocument is the creation date of the WMtransfer order. In the case of a companywith a period end on Sunday, the transferorder is created late on Friday. The ware-house staff goes home for the weekendand completes picking and the PGI cre-ation date is Monday, the new period. Theposting date of the MM document will beFriday in the old period.

Now let me show you an example (Figure7). In this case, the posting date of theMM document has been copied from thetransfer order (Figure 8), so the correspon-ding FI document is posted incorrectly toP10/2004 instead of P11/2004 when theactual delivery took place. This results inan incorrect cutoff as the COS is posted toP10/2004 when the delivery actually tookplace in P11/2004 (Figures 9 and 10).This is possible because the normal MMperiod close allows posting to the priorMM period and the FI-G/L accounts arekept open for posting during the first fewdays of the new period for period closepostings.

At most companies it is common to keepthe fiscal period open a few days after theactual end date of the period to allowposting of month-end adjustment entries(e.g., accruals, settlement, allocation). Toavoid this type of error you can set MMperiod close to allow only posting to thecurrent period.

SD document flow for delivery with WM transfer order created in one periodand the MM PGI created in the next period

Figure 7

Table showing which period each document in the SD document flow was created

Figure 8

Document/process Day Date Fiscal period

Sales order creation Thursday 10/28/2004 P10/2004

Delivery creation Thursday 10/28/2004 P10/2004

WM transfer order creation Thursday 10/28/2004 P10/2004

Period-end Sunday 10/31/2004 P10/2004

MM PGI creation Tuesday 11/02/2004 P11/2004

MM PGI document header shows document creation in P11, 11/02/2004,but the posting is in P10, 10/28/2004

Figure 9

the new period. If the locations werereversed with the head office in New Yorkand plant in Los Angeles, setting thesingle period flag would not be a goodidea because the MM period close wouldbe set at midnight New York, EST, which

is three hours before Los Angeles movesinto the new period. Therefore, any MMtransactions in Los Angeles between 9 pmand midnight PST would have to post tothe new period, which does not complywith US GAAP.

FI posting for MM PGI document showing posting to P10/2004 even whenthe MM PGI document was created in P11/2004

Figure 10

Rohana Gunawardena is a senior consultant with QS&S Inc., a specialist SAP consulting firm. Rohana has been working withSAP since 1992, focusing on the FI/CO modules with emphasis on business segment reporting, cross-module integration toFI/CO, sales cycle accounting, and A/R. He also has experience with SD, MM, and ABAP. He is a Fellow of the Institute ofChartered Accountants in England & Wales. You can reach him at [email protected].

106


For most users, the change in the way R/3Release 4.5A maintains material masterhistory is transparent, because all SAP stan-dard reports were changed. However, afterRelease 4.5A, when viewing data usingSE16 or SE17, be aware that any fieldsmarked as prior period or prior monthdo not contain valid values. If you havecustom programs looking at historic material master data, you must make surethey follow the new logic.

I will give an overview of this criticalchange in the way R/3 stores materialmaster history after Release 4.5A andexplain how this affects you and yourusers. I’ll also show how you can makethis change work in your favor.

The biggest benefit of the change in mate-rial master history tables is the hugeincrease in the speed of the MM periodclose process. Many companies using

SAP are unaware of this change and arenot making the best possible use of thisfunctionality. Refer to the sidebar, “RevisePeriod Close Batch Jobs,” to see if yourperiod close is set up to take advantage ofthe fast closing.

The new material master history tablestake a monthly snapshot of the materialstock balances, stock values, and standardcosts. This is information that users oftenwant to know, but there appears to be noeasy way to get this information.

Let’s consider the simple case of wantingto find out prior period data about a material and one way you might do this.When you want to look at the history ofa material (e.g., its standard cost twomonths ago), one way to find this is inthe change history of the material mastervia transaction MM03 and menu pathEnvironment>Display changes.

Unfortunately, searching for a particularfield in the change history can be confus-ing (Figure 1). From a technical point ofview, using the document change historytables CDHDR and CDPOS to look atprior values of a material is not very efficient. In addition, these tables do notstore historic stock balances.

MM Period Close Prior toR/3 4.5AWhen the MM period changed, everymaterial valuation record in table MBEWwas updated and the prior period and prioryear fields were updated as appropriate.At month-end, a user would run transac-tion MMPV to change the MM periodand perform the table updates. If acompany code had many material/plantcombinations, the period change couldtake hours. You could not achieve a cleancutover if MM transactions occurredduring this period.

This process was especially problematicfor manufacturing companies with 24/7

June 2005 • www.SCMExpertOnline.com

Starting with SAP R/3 Release 4.5A,SAP added functionality to savemonthly history of the key materialmaster tables. These materialmaster history tables can be auseful source of information andcan form the basis of customreports to meet specific userrequirements. Many SAP standardreports, such as RM07MMFI andFB5L, use these new history tables.

Key Concept>>Abstract: SAP R/3 4.5A stores previous period data for materials in new history tables. Learnhow this change improves the MM period closing process and allows you the unprecedentedopportunity to view historic material master data.

Material Master History Tables

What Happens to Materials in Prior Periods?


Display of change history in the material masterFigure 1

107


operations, with no MM downtime duringwhich to perform the MM period change.SAP’s solution was to link the period rollto ongoing MM transactions, like a goodsreceipt or goods issue, and have all thesetransactions refer to the MM period tableMARV. MARV contains the current MMperiod by company code. A decision couldthen be made as to whether the materialmaster history needed to be updated.

History Record TablesR/3 Release 4.5A introduced materialmaster history tables, which modified theway the MM period change occurred. Theprior period and prior year fields in tableMARD, MBEW, etc., were no longerupdated. Instead, R/3 created materialmaster history record tables such asMARCH, MARDH, or MBEWH.

When the first transactions for a materialor a combination of material or plant areprocessed after the MM period change,R/3 copies the existing material masterdata to the history tables to create aperiod-end snapshot. Figure 2 showsan example of this. The creation of thehistory record depends on the first transaction for the specific key field combination of the original table. Fortable MARD, the combination is mate-rial/plant/storage location and for table

MBEW it is material/valuation area/valuation type.

This means that for a single material,MARD history records are created inMARDH at different times, dependingupon when transactions occur for a spe-cific storage location. Each table has itsown combination of key fields, making 12different combinations. Table 1 is a list ofall the material master tables that havecorresponding history tables.

Impact on Current TablesThe casual user must be very careful whenlooking at fields marked as prior periodvalue or prior year value (in the ShortDescription field of Figure 3) in thematerial master tables. After R/3 Release4.5A, the values in these fields are nolonger valid. Although R/3 does not usethe fields, they have not been removedfrom the tables. The values in the priorperiod and prior year fields often containthe last value prior to conversion toRelease 4.5A.

If you have older Z reports for materialmaster values, you need to determinewhether these are receiving data frominvalid fields. When using SE16 or SE17to browse these tables, shown on the rightof Table 1, make sure you are not misledby the field titles and incorrectly report

www.WISpubs.com

Creation of material master history records for infrequently used materialsFigure 2

>> NoteSee SAP note 171465, “Periodclosing as of 4.5A,” and 193554,“Stock/valuation data of previousperiods,” for more details. Also seethe section, “Material Master(Industry/Retail): Enhancements toPeriod Closing,” of the R/3 4.5Arelease notes.

108


old data. No system safeguard exists toprevent this, so you need to be aware ofwhere the old data is stored so that youdon’t use it mistakenly.

See Figure 3 for an example of some ofthe prior period and prior year fields.Look for other such fields in tablesMBEW and MARD, as well as othermaterial master tables. You can identifythem because they are described as “previ-ous period” or “previous year.”

The previous period fields in tablesMBEW, MARD, etc. are used for displaypurposes only (for example, materialmaster display). These fields are no longerupdated in the database. Instead, entriesare written to tables MBEWH, MARDH,etc., which contain the stock informationfor past periods.

In contrast to earlier releases, the periodfields (fields LFMON, “Current period,”and LFGJA, “Fiscal Year of CurrentPeriod”) in tables MBEW, MARD, etc. nolonger contain the current period. Instead,they contain the specific period in whichfields relevant to inventory management orvaluation were last changed. Such a changemight have been made through a goodsmovement or a valuation, for example.

If a material has had no transaction formany periods, the period fields show aperiod prior to the current period. You canclearly see in the example shown inFigure 4 that the MBEW records for dif-ferent valuation areas have different yearand period values based on when the lastmaterial transaction occurred for the spe-cific material/valuation area combination.

Read History RecordsAs previously mentioned, R/3 creates anew history record when the first transac-tions for a material have been processedafter the MM period change. If there is nomovement for a material in a period, thenno history record is created. Figure 5shows that history records are not createdsequentially by period for infrequently

June 2005 • www.SCMExpertOnline.com

History table Description Original tableMARCH Material Master C Segment: History MARCMARDH Material Master Storage Location Segment: History MARDMBEWH Material Valuation: History MBEWMCHBH Batch Stocks: History MCHBMKOLH Special Stocks from Vendor: History MKOLMSCAH Sales Order Stock at Vendor: History MSCAMSKAH Sales Order Stock: History MSKAMSKUH Special Stocks at Customer: History MSKUMSLBH Special Stocks at Vendor: History MSLBMSPRH Project Stock: History MSPRMSSAH Total Sales Order Stocks: History MSSAMSSQH Total Project Stocks: History MSSQ

List of material master historyTable 1

Be cautious of description fields containing “previous period” and “previousyear” in material master tables

Figure 3

Different records for the same material can have different current year/cur-rent period values

Figure 4

Sample entries from MBEWH, the MBEW history tableFigure 5

109


used materials. History records are createdonly when a material transaction occursfor the specific material/valuation areacombination. History records exist forevery period of frequently used materials.

You can develop a custom report to searchthe material tables for prior periods. If norecord exists for the specific period youneed, then look for a record for the nextperiod. Keep doing this, and if no nextperiod is found, the correct value is in thecurrent material table.

Using the example in Figure 5, if youwanted material values for P03/2001, firstlook for an entry for P03/2001. If there isno such entry, keep adding one to theperiod until you find a record, in this caseP12/2001. If you wanted to find a valuefor P03/2002, there is no history recordfor P03/2002 or any later period. Thismeans that the historic value must be thesame as the current value in table MBEW.

Revise Custom ABAPsNote that SAP has changed standardreports such as MB5L and MB5K,which report on prior period or prior yearvalues, to read the new history tables.SAP R/3 uses function modules such asMBEW_EXTEND and MARD_EXTENDto add the correct historic values to theprior period and prior year fields in theoriginal tables used in the reports. SeeFigure 6 for a full list, which can beuseful when updating your reports to getdata from the new history tables.

The most widespread error I have comeacross with custom reports is the use ofprior-period fields (e.g., MBEW-STPRV)with the assumption of valid values. This

may be due to the continuing use of reportswritten prior to SAP R/3 release 4.5A, or tolack of awareness of the change in SAPlogic when developing new reports.

Revise Period Close Batch JobsThe greatest benefit of this change in R/3Release 4.5A is that the time the MMperiod change takes has gone from a fewhours to a few seconds. Make sure you aretaking advantage of this benefit in yourSAP R/3 system.

If you set up your MM period changebatch jobs when you first went live withSAP, it’s a good idea to review the timingof these jobs, because the period changeused to take much longer and batch jobswere timed for this. After R/3 Release4.5A, you can easily run the batch job forABAP RMMMPERI at exactly midnightfor an accurate cutoff. For more details,

www.WISpubs.com

see SAP note 171465.

Choose the Close period only optionwhen setting up the batch job, because theCheck and close period option takes along time to run (Figure 7). I recommendthat you run the check period option a fewdays before your actual month-end. Thisallows you to detect errors in MM post-ings and gives you time to clean up. ■

Full list of functions used to add correct history data to the original materialmaster tables

Figure 6

Choose Close period only when performing the period closeFigure 7

Rohana Gunawardena is a principal consultant with QS&S, Inc., a specialist SAP consulting firm. Rohana has been working withSAP since 1992, focusing on the FI/CO modules with emphasis on business segment reporting, cross-module integration toFI/CO, sales cycle accounting, and A/R. He also has experience with SD, MM, and ABAP. He is a Fellow of the Institute ofChartered Accountants in England & Wales. You may reach Rohana at [email protected].

If you find problems with the values inthe material master history tables,R/3 will not correct any problemsfound with the material master historytables. This is because they are notnecessary for your R/3 system towork, as stated in SAP note 34440.

Note>>

110

Offerings We offer following complimentary consulting. Are you planning a major SAP initiative like New G/L, ERP Upgrade, merger or de-merger, system landscape Integration? Chat with our practice director and get the complimentary feasibility analysis study. Do you have a specific business issue - be it a configuration or a process issue? Ask the experts at QS&S and its group of companies and we will provide complimentary business solution. Interested to know how we have helped companies overcome business challenges? We will be proud to demonstrate you some of our strategic business solutions and offerings on how we have helped other companies overcome some of the business challenges. Want to get complimentary copies of our consulting solutions? Please register with us to get complimentary copies of our consulting white papers.

Your Partner in Business & Technology Excellence

QSandS Publications Samples

Documents

Transcript of QSandS Publications Samples