quality expertise & sap services enabling business...

Quality Expertise & SAP Services

Enabling Business & Technology solutions

Enhanced Efficiency, Improved Effectiveness

Lower Costs, Higher Profitability

Phone: (408) 242-7588 E-mail: [email protected]

4264 Nerissa Circle, Fremont, CA 94555

Dear colleague,

Let me take this opportunity to introduce you 'Quality

Systems & Software’ or ‘QS&S’ for short. We spe-

cialize in SAP.

While the strategic importance of SAP technology is

crystal clear, companies still fail to reap all the bene-

fits it offers. In fact, many firms continue struggle just

to get their systems run. QS&S offers the expert

experience required by companies to fully exploit

their SAP investment.

We believe that finally it boils down to Quality of

expertise- and we pride in bringing quality expertise

on the table. Quality is embedded in our company.

That's our name.

At QS&S "Quality" says it all! It's in our name and in

everything we do. With our quality consulting, com-

panies achieve world-class performance and realize

their latent business and technological potential.

You'll find QS&S consultants everywhere. We are reg-

ular participants at the premier SAP events such as

ASUG, SAP Financials, SAP Supply Chain, and

Managing SAP Projects conferences. We are also fre-

quent contributors to the industry's leading publica-

tions including SAP Financials Expert, BW Expert, HR

Expert, SCM Expert, SAPInsiderOnline, SAPtips, and

SearchSAP.

I am enclosing some of our white papers for your ref-

erence. These represent some of the common busi-

ness challenges you wrestle everyday. We can help

you overcome many of the business challenges of

your toughest SAP projects.

Let us know your business goals and we will be

proud to offer you our strategic business solutions.

I look forward to hearing from you.

Mitresh KundaliaDirector - SAP PracticeE-mail: [email protected]

About Quality Systems & Software . . . . . . . . . . . . . .2

Services and Solutions . . . . . . . . . . . . . . . . . . . . . . . .3

Clients & Industry Associations . . . . . . . . . . . . . . . .3

Abstracts of White papers . . . . . . . . . . . . . . . . . . . . .4

White paper - “Plan and Monitor Your Sales

Campaigns in the CO-PA Ledger” . . . . . . . . . . . . . .7

White paper - “10 Best practices for

Designing Summarization Levels” . . . . . . . . . . . . .14

White paper - “Extract pricing conditions

from the R/3 Module into BW” . . . . . . . . . . . . . . . .19

White paper - “Copy control gives you

Flexibility to manage Your SD document flow” . . .22

White paper - “CO-PA archiving - Why and

How?” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

TABLE OF CONTENTS

About QS&S

Quality Systems & Software (QS&S) and its group companies,

operating in three countries, are SAP specialists offering a

wide range of consulting services.

We strongly believe that finally it boils down to Quality of

expertise- and we pride in bringing quality expertise on the

table. Quality is embedded in our company. That’s our name.

At QS&S "Quality" says it all! It's in our name and in everything

we do. With our quality consulting, companies achieve world-

class performance and realize their latent business and tech-

nological potential.

While the strategic importance of SAP technology is crystal

clear, companies still fail to reap all the benefits it offers. In

fact, many firms continue struggle just to get their systems

run. QS&S offers the expert experience required by companies

to fully exploit their SAP investment.

QS&S consultants are well versed in R/3 applications, Upgrade

projects, New dimension tools (BW, SEM, SCM, CRM,

Portals), R2-decommissioning, Archiving solutions, Remote

consulting, Production support and IT staffing. We pride our-

selves on expertise we deliver to our client. Quality expertise

grounded in practical experience.

We have deep insight into strategic, business and operational

aspects of an organization. We understand the birds-eye-view

and we understand the nut-and-bolts too.

QS&S's core strength is SAP. Our consultants have skills and

knowledge across all modules of SAP including Financials (FI,

CO, BW, SEM), Logistics (SD, MM, PP, PM, WM) and HR (PD,

PM, Payroll).

We provide solutions and services spanning all functional

areas of an organization, be it Finance departments, Logistical

depots, Sales Offices, HR Departments or IT data centers. We

can provide our expertise in these functions:

Finance, Logistics & HR solutions

IT solutions

Business solutions

Finance, Logistics and Human Resources Solutions

With dynamic and fast changing environment, corporate finan-

cial departments are facing critical challenges. Regardless of

industry, pressure is mounting to build more efficient and

accurate financial supply chains that can reduce costs, accel-

erate speed and comply with statutes.

QS&S's Finance Solutions professionals help finance leaders

rapidly identify and implement proven best financial and

accounting practices. We use our extensive expertise of

finance functions - right from planning and reporting to shared

services to financial management. We want CFOs to have con-

fidence in the accuracy of the financials of the organization

and we enable finance functions to align with strategic goals

or the organization.

QS&S's Logistics Solutions professionals help companies

enable and integrate key processes and applications through-

out the supply chain.

QS&S's Human Resources Solutions professionals help com-

panies enable and integrate key personnel applications

throughout the organization.

IT Solutions

No doubt, IT has become integrated part of a business. One of

the most strategic catalysts, IT enables business processes

can dramatically improve the overall performance.

QS&S started as an IT software company; provided cus-

tomized IT solutions to meet the specific requirements of the

organization. We provide technical expertise in all the major

areas in SAP including ABAP development, Web enablement.

Business Solutions

QS&S provides various other services to organizations to

enable companies to constantly improve and continue achieve

excellence.

RReessoouurrccee ssuupppplleemmeennttaattiioonn

Whether you require assistance of a qualified expert for one

day or for longer, QS&S can provide you with an immediate

cost effective solution to support your needs.

SSyysstteemmss AAuuddiitt aanndd pprroojjeecctt rreevviieeww

QS&S can audit your systems and project plans and provide

reassurance to the owners of applications.

RReemmoottee CCoonnssuullttiinngg

QS&S can also provide you remote consulting, ideal for organi-

zations requiring assistance for specific issue.

PPrroodduuccttiioonn SSuuppppoorrtt

QS&S consultants can help you support your day-to-day busi-

ness and applications. We provide expertise in Functional as

well as technical modules of SAP.

2

Services & SolutionsWe help companies achieve world-class performance with

enablement of business and technology solutions. We use

Industry-wide best-practice configuration guides and proven

implementation tools to integrate complex business processes

with the SAP system. With the combination of Quality of

expertise from us and strength of SAP system, we enable

companies realize enhanced efficiency, improved effective-

ness and overall business goals.

Among other things, specifically, we can provide our expertise

in these functions:

SAP Applications - Finance, Supply Chain & HR solu-tions

Initiatives - Upgrade projects, new Dimension tools(BW, SEM, SCM, CRM, Portals)

Optimizing solutions: R2-decommissioning, Archivingand Data Management

IT Automation solutions

IT Staffing

Remote consulting

System audit and Project review

On-site and Off-shore development and system support

Business productivity solutions - business process re-engineering (BPR)

Clients & Industry Associations

We have successfully completed SAP consulting engage-

ments for various fortune 1000 clients in a variety of indus-

tries, including, High tech, Manufacturing, Networking,Pharmaceutical, Entertainment, Consumer Goods,Financial Services, Automotive, Services and more.

If you have any industry-specific business challenge, be it,

determining customer profitability, managing discount pro-

grams, improving SAP investment, providing flexible reporting

and more, let us know and we will be proud to offer you our

strategic business solutions.

3

Following represents the partial client list, where we have pro-

vided our consulting services.

Bridgestone Firestone

Daimler Chrysler

Baldor Electricals

Century Aluminum

Google

Applied Materials

Palm

3Com

Tractor Supply Company

Sloan Valve

Astex

Video Server

eZenia

Syngenta

In addition, you'll find QS&S consultants everywhere. We are

regular participants at the premier SAP events. We are also fre-

quent contributors to the industry's leading publications.

Following is the partial list of professional associations:

America's SAP Users Group (ASUG)

Managing SAP Projects Conferences

SAP Financials Conferences

SAP CRM Conferences

SAP SCM Conferences

SAP BW Conferences

SAP Basis/Admin Conferences

SAP Financials Expert (FICO Expert) Publications

CRMExpert Publications

SCMExpert Publications

BWExpert Publications

SAPInsiderOnline

SAPtips

SearchSAP

Our White Papers

We have published more than 25 consulting white papers,

which cover many of business challenges you wrestle every-

day. Here are the abstracts of some of these white papers. If

you want to discuss business cases involving these 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].

For ease of reference, these white papers are categorized

under: Consulting Notes, Reporting, Productivity Solutions and

Project Management.

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 creat-

ed and offers you a solution on how to avoid this inconsisten-

cy.

"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 require-

ments. 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.

"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 valua-

tion of the product. However, very few are aware that some-

thing called as 'future price' of the product also has notewor-

thy 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 incor-

rect results.

"What Is so Special about Statistical Conditions?"

Needless to mention that pricing procedure is one of the most

powerful 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 pric-

ing 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 clari-

fies 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-tun-

ing 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, alloca-

tion 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

4

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.

"Omnipotent Condition Technique"

Condition Technique is one of the most powerful tools avail-

able in SAP. It is extensively utilized within various SAP func-

tions. 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.

"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.

BW Reporting

"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 solu-

tion and explains how to extract SD conditions to BW.

"Should You 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.

Reporting

"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 develop-

ing customized solution is not only inefficient you lose the flex-

ibility 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 per-

formance"

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 opti-

mize reporting performance. In this paper, author demon-

strates 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.

"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.

Productivity Solutions

"Plan and Monitor Your Sales Campaigns in the CO-

PA Ledger"

Offering discounts is one of the most common business prac-

tices to increase the business volume. SD module has rich

functionality to handle special prices and discounts. Planning

5

and executing a successful promotion campaign is critical to

your business. You want to find out how successful your dis-

count 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?

"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.

"Use CATT to Test Your End-to-End Business

Processes"

Computer Aided Test Tool (CATT) is SAP's testing tool for test-

ing various SAP transactions. Though using CATT is fairly sim-

ple, many companies do not fully exploit the features. This

might be due to several misconceptions - that you need strong

technical skills to use it, or it is difficult to test the transactions

which are dependent on other transactions/results. In this arti-

cle, the author demonstrates how CATT can be used to pass

test results from one transaction to the subsequent transac-

tion. This method can be very useful to test end-to-end

process like Purchase-to-Pay or Order-to-Cash and you don't

have to create multiple redundant test cases. Also, the author

documents best practices to design and develop test cases.

"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 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 vari-

ables for variants makes the usage more effective and effi-

cient. Instead of creating a new variant or changing the exist-

ing 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 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 prac-

tices on managing these TVARV variables to get maximum out

of it.

Project Management

"How to Manage User-exits for multiple projects"

It is common for companies to have many user exits, for man-

aging multiple initiatives in the organization. Managing user-

exits is a challenge, as these user-exits are dependent on vari-

ous factors and many times may hinder the go-live plans. In

this article, the author exhibits a technique on how to manage

user-exits so that these are seamlessly integrated with all the

business initiatives.

6

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.

7

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

8


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

9



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

10


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

12



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

13


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.

14



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

15



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.

16

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

17



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.

18


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.

19

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

20



• *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].

21

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.

>>continued on page 3

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>>

22

>>continued from cover

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>>

23

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

24


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

25


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

26


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.

27


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.

28

SAPtips © 2004 Klee Associates, Inc.

Page 1

0

SAPtips has already publisheda number of data archiving arti-cles by Breck Whitten, DataArchiving Manager at Hallibur-ton. Now, we are expanding ourcollection with a new contribu-tion from Mitresh Kundalia, anexpert CO-PA consultant andguest FI/CO contributor. On hisprojects, Mitresh has used CO-PA data archiving techniques toreduce the size of CO-PA tablesand increase system perform-ance for his clients. In this illus-trated, step-by-step guide,Mitresh explains how to applythese data archiving techniquesto keep CO-PA table sizes undercontrol. Throughout this article,Mitresh draws on his subjectmatter expertise in CO-PA topoint out some of the uniqueissues that an archiving teamfaces on CO-PA projects.

IntroductionNo doubt, archiving is

important. However, wedon’t see enough atten-tion paid to it—perhapsdue to other project dead-lines, "we’ll worry aboutit later" attitudes, orother genuine and not-so-genuine reasons. Needlessto mention, archivingbecomes critical as soonas the business communi-ty starts complainingabout performancedegradation, or the tech-nical community startscomplaining about man-aging a huge, unwieldydatabase. In particular,once the ERP projectshave gone-live, the vol-ume of transactions

increases to the extent that, aftersome time, system performancedeteriorates.

Over a period of time, especial-ly after a couple of fiscal years,businesses won't have much needto access historical transactions.Even though businesses won’tneed to access many of these doc-uments, you don’t want to purgethese records. You will need tostore these for legal, compliance,or audit requirements. This isespecially critical in light of "Doc-ument Retention and DestructionIssues" relating to the Sarbanes-Oxley Act (SOX). In summary,historical data cannot be deleted;it has to be kept for reference.Data archiving is the solution.

Why CO-PA Archiving?Simply because of its huge

database, archiving becomes of

paramount importance to CO-PA.Being a downstream module, CO-PA collects information frommany upstream applications likeSales & Distribution (SD), Pro-duction Planning (PP), Financials(FI) and Controlling (CO). Sinceit collects data from many othermodules, in addition to its owndata, the CO-PA module is noto-rious for huge data.

The introduction of new fea-tures in CO-PA also increases thedatabase size. For example, withthe introduction of dual-currencytransactions in CO-PA, you cannow store the records in bothCompany Code currency andOperating Concern currency. Bydoing so, the number of transac-tions into CO-PA is doubled.

Although CO-PA provides manyperformance improvement tools

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

JournalJ

ourn

al

CO–PA Archiving – Why and How?By Mitresh Kundalia, SAP Practice Manager, Quality Systems & Software.

Figure 1: Growth of the CO-PA Database

SD FI COPC

Line Items

SummarizationLevels

CE2

CE1

CE4

CE3

COIX

SegmentLevel/Table

SummarizationData

SL

SL

SL

29


Page 1

1

like Summarization Levels, Sum-marization Data, and FrozenData, none of these tools can stopthe CO-PA database from"exploding" with data as pictori-ally shown in Figure 1. All themore reason that the CO-PA mod-ule becomes a leading candidatefor archiving.

In this article, I will demon-strate how to archive CO-PA datato keep the database size in checkso that overall performance isoptimum. Before I explain thedetailed steps of CO-PA archiving,I will provide some brief back-ground information about archiv-ing to understand how really itworks.

Please note that "Archiving" isa fairly complex and involvedsubject matter. It involves formu-lating strategies for definingminimum number of years thedata has to be in the system (res-idence time), how and when thedata can be archived (Archivingprocess), how archived data canbe accessed (display functions),

and technical architecture. Afterreading this article, if you'relooking for even more informa-tion on data archiving method-ologies, refer to Breck Whitten'sseries of articles on data archiv-ing in the SAPtips documentlibrary.

Basics of ArchivingPut simply, Archiving primarily

consists of two steps: (1) Writearchive files, and (2) Delete data,as shown in Figure 2.

Let's review these two steps inmore detail.

1. Writing data to archive filesand storing them in the filesystem:

"Write program" selects thedata objects from the database forthe specific selection criteria andchecks whether the data can bearchived. Once these checks aresuccessful, it writes the data ontothe archive file. Note that the datais still not deleted from the data-base.

2. Deleting the data which wasarchived:

"Delete program" first readsdata from the archive file to checkwhether the data was archivedsuccessfully. This ensures that thedata was archived before deletingfrom the database.

Write and Delete programs arepre-defined depending upon whatbusiness data you want to archive.Archiving programs, structure,and composition of data to bearchived are defined in somethingcalled the "Archiving Object."

What Is an ArchivingObject?

Technically, the ArchivingObject is defined as "smallest unitthat can be wholly archived anddeleted from the database."

Since the Archiving Object isone of the most important defini-tions for data archiving, let’s lookat it more closely.

For example, as we know, SAPstores CO-PA doc-ument details invarious databasetables like CE1,CE2, CE3, etc. Ifyou want toarchive and deleteone CO-PA docu-ment, you alsohave to delete cor-responding entriesfrom these tables.Not only that, youhave to also man-age the order inwhich the entriesshould be deletedfor dependencies.So, instead ofrequiring you tomanage these

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

JournalJ

ourn

al

Figure 2: Archiving Consists of Two Steps: Write Job and Delete Job

ArchiveFiles

ArchiveFiles

Data Object

R/3Write

Program

DeleteProgram

Data Object

R/3

X

30


Page 1

2

steps manually, SAP hasdeveloped this very flexibleconcept of an "ArchivingObject." Whenever you talk ofarchiving, you always refer toa specific Archiving Object!One of the most popular trans-action codes in the archivingworld is "SARA," whichshows corresponding detailsfor an archiving object.

As shown in Figure 3, anArchiving Object primarilycontrols configurationparameters for what data toarchive and what programsto use. Typically, the Archiv-ing Object refers to (a) theTables it is going to deletedata from, (b) the programsthe system uses to write anddelete, and (c) the customiz-ing parameters one can set for thearchiving.

Archiving ProgramsSAP has developed programs

for creating archive files anddeleting corresponding entriesfrom the database. For everyArchive Object, it lists the archiv-ing programs: write, delete, reloadprograms, etc.

How Are Tables Listed?For the Archiving Object, all

those table entries that will bedeleted are listed. This is alreadypre-defined.

Can You Customize anArchive Object's Parameters?

SAP lets you set various param-eters for archiving. For example,you can set the file size of thearchive, or whether the deleteprogram should be executed auto-matically after the write program.

Programs and Table compo-nents of an Archiving Object are

pre-defined by the SAP system,whereas you should always set thecustomizing parameters for everyArchiving Object.

Customizing parameters for anArchive Object are further catego-rized into:

• Archive Object-specificparameters

You can set the parameters forthe size of an archive file, settingsfor deleting programs, and con-nections to the archive system.

• Basis customizing for filenames/pathsYou can set the logical filenames and directory pathswhere these files will be stored.Typically, your colleague fromthe Basis team will set theseparameters with the help oftransaction code "FILE."

• Application-specific parameters

Optionally, you can set a fewapplication-specific parameters.

For example, in the case ofFinancial Documents (ArchiveObject FI_DOCUMNT), you canset the retention periods for G/Laccounts or the minimum reten-tion days for document types.

Creating a CO-PA Archive Now that we are familiar with the

basics of data archiving, let's applythis knowledge to our CO-PAarchiving project. Our first majorstep is to create and customize theCO-PA Archiving Object.

1. Set Up the Archiving Objectfor CO-PAThe Archiving Object for Cost-

ing-based PA is "COPA1_xxxx"(where: xxxx is the name of theOperating concern). The corre-sponding archiving object foraccount-based PA is"COPA2_xxxx".

Note: For the purpose of demon-stration, I will show the steps forsetting up the Costing-based PAobject with "IDEA" as an Operat-ing concern from IDES.

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

Figure 3: Archiving Object

ArchivingObject

Jou

rnalJournal

Tables

Programs

Customizing

31


Page 1

3

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

The first step is to call ArchiveAdministration via transactioncode "SARA" and enter"COPA1_IDEA" as the ArchivingObject. You are then brought tothe initial screen of ArchiveAdministration as shown inFigure 4.

Alternate approach: instead oftransaction code "SARA" if youaccess "Archive Administration"directly from the CO-PA applica-tion menu, relevant parametersare already set. For example, tostart CO-PA archiving, if youchoose the menu path: "Control-ling -> Profitability Analysis ->Periodic Processing -> Archiv-ing", the SAP system automati-cally sets the Archive Object as"COPA1_IDEA" for you. Eitherway, the system calls transaction"SARA" for archive administra-tion. Although the alternatemethod sounds easier, in theworld of archiving, you get usedto "SARA".

2. (Optional) List the DB TablesBeing ArchivedClick on "DB tables," the icon

to list which table entries will bearchived (and deleted) for thisArchive Object. This step is forinformation only; it is not manda-tory (see Figure 5).

�TipDid you observe that the CE4entry (CE4IDEA) is missing fromFigure 5? No, nothing is wrong.The CE4 table primarily acts as amaster table, and therefore, theCE4 table is not part of CO-PAarchiving. No data is deleted fromthe CE4 table.

The following archive programsare available for the"COPA1_IDEA" ArchivingObject:

Write program RK4Axxxx

Deletion program RK4Bxxxx

Reload program RK4Cxxxx

Note: When you generate theOperating Concern (xxxx), theSAP system automatically gener-ates these programs, along withthe two Archiving Objects.

Figure 4: Call Archive Administration Via Transaction "SARA" for Specific Archive Object

Figure 5: DB Tables for Archiving Object COPA1_IDEA

Jou

rnalJournal

32


Page 1

4

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

3. Customizing the ObjectParametersClick on "Customizing" icon todefine archiving parameters forCO-PA data (see Figure 6).

Customizing parameters for anArchive Object are categorized into:

• Optional application-specificparameters.For CO-PA, there are no appli-cation specific parameters.

• Basis customizing for filenames/paths.You can define the logical filenames, corresponding physicalfile names, and paths forarchiving.

• Archive Object-specific parameters

Click on "Technical settings"(see Figure 6) to define specificparameters for archive object"COPA1_IDEA" (see Figure 7).Various important archive set-tings for the archive file, such as

connections to the archive systemand delete program, are set here.

Our new CO-PA Object is nowconfigured. Let's review some ofthe key characteristics and controlfeatures of this new object.

Logical File Name The logical filename is the plat-

form-independent name for thefile, which is stored in the file sys-tem. At runtime, the actual phys-ical filename is derived from thelogical filename.

Archive File SizeBased on the default parameters

(which you can adjust), SAP willcreate a new archive file once ithas crossed 100MB, or 300,000data objects are written. It isadvisable to keep the file size limitFigure 6: Customizing Settings for Archiving Object COPA1_IDEA

Figure 7: Technical Settings for Archive Object "COPA1_IDEA"

Jou

rnalJournal

33


Page 1

5

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

to 100MB for themost optimal tech-nical performance.The SAP systemautomatically cre-ates a new archivefile either when the300,000 objects arearchived in one fileor the file sizeexceeds 100MB.

If you want tostore archive filesautomatically onstorage media, setthe indicator"Start automatic"in the "File stor-age to storage sys-tem" box.

Settings forDelete Program

If you check thebox "Start auto-matic", the deleteprogram is auto-matically triggeredonce the write job is finished.Variants should be created for"Test run" and "Production run"(see Figure 8).

Observe that in Figure 8, thecheckbox "Test run" is checked.In this case, the system will simu-late deleting data from the tablesand issue log. Figure 9 shows howto activate the actual deletionprocess by leaving the "Test run"box unchecked. Always perform a"test run" before you initiate aproductive run.

Performance is one of the mostcritical issues when it comes toCO-PA reporting. The trick is topre-summarize data in advance sothat the system does not have togo through the huge transactiontables. Instead, it goes to the so-

called "summary" tables. SAPoffers various techniques to pre-summarize: summarization levels,summarization data, frozen data,and so forth. Note that if the datafrom the CO-PA tables is gettingdeleted, the pre-summarized datamay not be in-sync with the trans-actions data.

�TipSummarization levels, summariza-tion data, and frozen data shouldbe consistent with segment levels.Therefore, it is recommended todelete pre-summarized data andrebuild summarization levels, oncearchiving is completed.

Writing the CO-PA archivefile

Once you have set the cus-tomization settings for the

Archive Object, you are ready tobegin archiving.

1. Click on "Archive" in"Actions" box on the initialArchive Administrationscreen (as in Figure 6). Cre-ate a variant with variant-name "FISCAL_2000" (if youwant to archive CO-PA datafor the fiscal year 2000),select the appropriate selec-tion-criteria and save thevariant (see Figure 10).

2. Enter the appropriate selec-tion-criteria to choose the CO-PA data that needs to bearchived. In this case, since Iwant to archive the entire fiscalyear (2000), I have entered thecriteria for the fiscal year only(see Figure 11).

Figure 8: Variants for Delete Program. For Productive Run, Uncheck the "Test Run" Option.

Figure 9: Variants for Delete Program. For Productive Run, Uncheck the "Test run" Option.

Jou

rnalJournal

34


Page 1

6

Before you write yourarchive, if you want to applyadditional criteria based onperiod, plan/actual indication,plan version, and record type,keep the following considera-tions in mind:

• Provide selection-criteria forarchiving and save theparameters as a variant.

• Fiscal year: One of the mostcommon parameters is toarchive by year. It is advisableto archive for a single fiscalyear in one archiving run.

• Period: You can furtherrestrict the data to bearchived by providing addi-tional criteria for periods. Ifthe volume of yearly data ishuge, you might considerarchiving on a quarterly oreven on a monthly basis.

• Plan/Actual Indicator andVersion: For archivingplan data, provide thename of the version usedfor planning.

• Record Type: For additionalarchiving parameters, youcan provide record types.Record types identify thesource of transactions postedto the CO-PA database. Hereare some sample CO-PArecord types:

Record Type Name1 User-Defined RecType A Incoming sales order B Dir. posting from FI C Order/proj.settlemnt D Overhead costs F Billing data G Customer agreements H Stat. key figures I Order-rel. project

• Create archive: Set the check-box to create an archive file.

• Deletion program in testmode: Uncheck the checkboxto actually delete the datafrom CO-PA tables.

• Only archive line items: As wehave seen earlier in "DBtables," data from CE1, CE2,and CE3 is archived and delet-ed. If however, you don’t wantto archive "Segment level"data (i.e., CE3), you shouldselect the "Only archive line

items" checkbox. In this case,only data from CE1 and CE2tables is archived.

3. Enter the schedule and spoolparameters for this write pro-gram. Execute the archive pro-gram and a "write job" isscheduled. You can monitorthis job by clicking the "Joboverview" icon or via transac-tion "SM37."

Once the write job is over, makesure that the archive file is writtento the operating system correctly.

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

JournalJ

ourn

al

Figure 10: Maintain CO-PA Archiving Variant

Figure 11: Maintain and Save CO-PA Archiving Variant

35


Page 1

7

Feb

ruary/M

arc

h 2

004 V

olu

me I

I Is

su

e 1

ww

w.S

AP

tip

s.c

om

SAPtipsSA

Ptips

Deleting CO-PAdata

Now it is time todelete the CO-PAdata from SAPsystem.

Click on "Man-agement" icon onArchive Adminis-tration: InitialScreen (SARA) andyou will see the listof earlier archivejobs.

Choose the writejob created in theearlier step andschedule the deletejob. This deleteprogram will readthe data from thearchive file and delete only thatdata—this ensures only CO-PAdata that is archived successfullyis deleted (see Figure 12).

Once data is deleted from CO-PA tables and archived, it is agood idea to build your pre-summarized data. Re-build andupdate summarization levels(transaction code KEDU) sothat it is in-sync with line itemsdata.

If you want to access archiveddata for reporting purposes, SAPoffers an option (Extras > Perfor-mance) at the time of designingyour CO-PA reports.

SummaryProperly executed, a CO-PA

archiving strategy can greatlyenhance the performance of yourSAP system without losing accessto data your users rely on. It maysound obvious, but the archivingof CO-PA data can be one of thesolutions to your CO-PA Report-ing performance issues. As

always, make sure thorough testsare performed in your develop-ment system before implementingyour archiving plan in the pro-duction environment.

Mitresh Kundalia, Quality Sys-tems & Software. Mitresh headsthe SAP practice division at Qual-ity Systems & Software(www.QSandS.com). QS&S helpscompanies achieve world-classperformance by realizing theirlatent business and technologicalpotential with emphasis on SAPsystems. QS&S uses Industry-wide best practices and provenimplementation tools to integratecomplex business processes withthe SAP system. With an MBAdegree in finance, Mitresh imple-ments Financial and Logisticsapplications with specialization inManagement reporting, Prof-itability Analysis, Informationsystems, and Business Informa-tion Warehouse. He can bereached by email [email protected]. �

Figure 12: Choose the Archive File to Schedule the "Delete" Job.

Jou

rnalJournal

36

www.QSandS.com

4264 Nerissa CircleFremont CA 94555

E-mail: [email protected]: (408) 242-7588

Offerings

We offer following complimentary consulting.

Are you planning a big SAP initiative like Upgrade, merger or de-merger, system landscapeIntegration?

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 helpedother 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.

www.QSandS.com