A Case Study in SAP R3 Organization Structure Design Taking FI COs One to Many Path to Speedier...

7/27/2019 A Case Study in SAP R3 Organization Structure Design Taking FI COs One to Many Path to Speedier Global Rollouts

http://slidepdf.com/reader/full/a-case-study-in-sap-r3-organization-structure-design-taking-fi-cos-one-to-many 1/16

73No portion of this publication may be reproduced without written consent.

A Case Study in SAP R/3 Organization Structure Design

A Case Study in SAP R/3

Organization Structure Design:Taking FI/CO’s “One-to-Many”Path to Speedier Global Rollouts

Kurt Goldsmith

Kurt Goldsmith of ICM

America LLC specializes

in the repair of broken,

loose, and otherwise

unpleasantly surprising

R/3 integration designs

areas including: CO-PA

to G/L Reconciliations,

Automatic Inventory/Sales/

Procurement Accounting, Make-to-Order Sales, Chart

of Accounts Redesign,

Purchase Requisition

Release Strategies, and

ABAP/Query.

Can a decision regarding something as innocent-sounding as a Chart

of Accounts code significantly impact the rollout speed, quality, and cost

of a Phase I design to multiple sites, particularly those in other coun-

tries? And, are the rollout issues raised by an Organization Structure

decision in the Accounting module the same as those raised by Organi-

zation Structure decisions that must be made in the Logistics modules?

The answer to both questions is, “Yes.” The R/3 Organization Structure

you adopt can have a profound effect on the speed with which you are

able to migrate an R/3 design from one site to another.

As we will see, a most interesting irony occurs in many Phase IIrollout projects. Project managers and team leaders feel pressure from

the rollout sites to adapt the Phase I design to meet “local” needs in

all areas of the software — SD, MM, PP, and FI/CO. This pressure is

especially strong when the rollout sites are in foreign countries where

unique laws and customs might exist. Not wanting to disrupt the

current “live” sites, the rollout leaders look at certain R/3 “one-to-one”

Organization Structure design options that allow each site independent

settings as a very attractive way out of the “local vs. global” tradeoff.

Available “one-to-many” design options get discarded as too restrictive.

But, as in life, R/3 offers few free lunches. Where one tradeoff disappears, another pops up to take its place. What? “Pops up where?”

you might ask. Would you believe in the end user’s face? The attempt

to help Phase II site users via 1:1 Org Structure accomodation can

actually cause their transition to SAP to become more painful than it

otherwise would have been. More time. More consulting cost. More

pain. I told you it’s an irony!

(complete bio appears on page 88)



SAP Professional Journal May/June 2000

www.SAPpro.com ©2000 Wellesley Information Services. All rights reserved.74

I’ll attempt to prove this premise as I share the

details of a US-based R/3 rollout to four European

countries (UK, France, Germany, and Italy) at a

company called Graham Packaging Co. L.P.1 And,

although the article will have an Accounting angle toit, this case study provides a useful context for more

than just the “bean counters” among us. The study

also touches on the concerns of R/3 project managers,

CIOs, and project team leaders by illustrating the

three generic problem areas that Phase I designs run

into during Phase II rollouts:

Configuration table maintenance

• Master data synchronization

• Knowledge sharing between Phase I and Phase II

end users

Again, it is my firm belief that decisions to accept

all of SAP R/3’s available “Organization Structure”

design flexibility can inadvertently make these three

problem areas more challenging than they otherwise

would be, regardless of which module we’re talking

about. However, since in many rollouts the Organi-

zation Structure element that typically has the most

pervasive impact on a rollout is the FI/CO module’s

“Chart of Accounts,” I’ve elected to make this ele-

ment the focal point of the real-life global rollout

case study profiled in this article.

For the Non-Bean Counters,A Brief Introduction to the “Chart of Accounts”

In SAP R/3, the term “Chart of Accounts” (COA) can

mean two things. It can mean an actual itemized list

of general ledger (G/L) account numbers (100000,

100010, 100020, etc.), which are available to record

and describe business transactions. Or, it can mean

the four-digit code that the system uses to distinguish

one particular list of G/L accounts from another

(US01 vs. GKRW vs. ZZ32, etc.).

Sometimes during a project, you’ll hear team

members saying “Chart of Accounts! Chart of Accounts!” as if that term means just one thing. It

doesn’t. It means two things. (1) Four-digit codes.

(2) Lists of account numbers. Each four-digit Chart

of Accounts code can exist by itself, without any

attached list of account numbers. But, each Chart of

Accounts list of G/L accounts can only exist if associ-

ated with a single four-digit code. Any two Chart of

Accounts codes can have the exact same list of G/L

accounts, a completely distinct list of accounts, or a

mixture — some shared accounts and some distinct

accounts. But, any two Chart of Accounts lists of

accounts (whether the accounts in those two lists are

identical, completely unique, or a mixture) must have

completely unique Chart of Accounts four-digit

codes. Chart of Accounts codes enjoy being put into

places such as R/3 configuration and master data

tables. Chart of Accounts lists of accounts don’t

really go anywhere inside R/3. You will find such

lists, however, taped to the desks of new-hire worker-

bees in the Accounting department each summer.

Poor little bumblebee. So many G/L accounts. So

little time to memorize. But, back to our story!

In an immediate and direct way, decisions on both

pieces of the Chart of Accounts term have an effect on

the SD, PP, and MM end users. Take a look at the

contents of the “Chart of accounts” field shown in

Figure 1. This four-digit code (“GCOA”) points to a

specific list of G/L account numbers that are stored as

master data in the FI module. In order to execute any

financially relevant transaction in Logistics — whether

SD Billing or PP Backflush for a Production Order or

MM Material Price Change, for example — the Com-

pany Code that the Sales Org or Plant belongs to must

be assigned to exactly one of these four-digit Chart of

Accounts codes. This way, when R/3 tries to auto-

matically update the G/L in response to one of these

kinds of Logistics transactions, it has a way to verify

which particular list of G/L account numbers the

Accounting department wants as valid for each of the

many different Sales Orgs and Plants. Each Sales

1 The SAP R/3 release at the time of the case study rollout was 3.1H.

The allotted time frame for bringing up six sites in the four countries

was five months, between July and December 1999.





Figure 1 IMG Configuration Table Linking One Four-Digit COA Code to One Company Code

Figure 2 P.O. Data Entry Screen Where End User CanInput a G/L Account and Cost Center to Charge

Org or Plant links to exactly one Company Code.

And, each Company Code links to exactly one

Chart of Accounts (COA) code.

For example, let’s say that someone creating a

“P.O. for a Cost Center” in hypothetical Plant 0111

attempts to input a G/L account number to charge a

P.O. expense. If that account number is not currently

listed in the COA assigned to Plant 0111’s Company

Code (Figure 2), then R/3 presents that end user with





an error message like the one you see in

Figure 3.

The fact that Logistics people aren’t able to

enter any old G/L account number they feel like

makes us bean counters very happy! (Sigh. Yes,

an accountant’s life is that lonely!) But, in a much

larger sense, both uses of the “Chart of Accounts”

code — G/L account numbering and Chart of

Accounts — have a far greater role in every multi-

national SAP implementation project. Two vital

decisions must be made. One on account numbering.One on how many Chart of Accounts codes to go with.

The decision on G/L account numbering typically

consumes many painful hours of discussion at the

beginning of a project when the Accounting depart-

ment realizes that their existing account numbering

is not well-suited to R/3. Any attempt to document

what goes on in these Numbering Redesign meetings

would require me to put a “No Children Allowed”

warning sticker on my article. Don’t be fooled by

the button-down shirts and the 10-key calculators.

Accountants can talk some trash when you start

messing with their G/L account numbering. And,

that’s before the meeting begins!

The decisions made on the Chart of Accounts

code are equally important. How many different codes

should be used? One per site? One per business

division? One per country? One per continent? One

per end user? Does it matter? How? Why? When?

While the decision on G/L account numbering

does not have a profound impact on a rollout in terms

of configuration table maintenance, master data

synchronization, and knowledge sharing between

Phase I and Phase II end users, the decision on how

many four-digit codes to go with does. In the next

sections, we look at what traits of the COA

Organization Structure item cause this impact.

What You Need to Know About the R/3 Organization Structure

Take a look at Figure 4. Shown here are the manda-

tory building blocks that relate to one another in

hierarchical fashion in the overall R/3 Organization

Structure.

Each name that you see (e.g., “Controlling Area”)represents one field in a database table. We need

database tables to store the details on such items as

saved sales orders, saved inventory movements, and

saved G/L journal entries. When a transaction such

as a new sales order is recorded, it gets stored into its

database table along with specific values for one or

more of these “Org Structure” things. In the case of

Figure 3 R/3’s P.O. Data Entry Error Message Whenthe Entered G/L Account Can’t Be Validated





a new sales order, you’d also be storing one specific

“Sales Org” value, “Distribution Channel” value, and

“Division” value.

The purpose of officially linking each and every

“Plant” to one “Company Code,” each and every

“Company Code” to one “Controlling Area” and one“Chart of Accounts,” and linking each and every

“Controlling Area” to one “Operating Concern” and

one “Chart of Accounts,” and so forth, is to help

create and enforce business logic. Now, business

logic is a good thing, of course. You wouldn’t want

your sales order data-entry people to accidentally

invent unauthorized combinations of Sales Orgs/

Distribution Channels/Divisions just because they got

bored one fine day, and started to daydream about

(pick one) Cindy Crawford/Mel Gibson. Hmmm.

Sounds like fun, actually.

From a practical viewpoint, however, what

benefits other than basic “entity combination” logic

come from linking together the different pieces of the

Org Structure like some sort of adult Lego set?

In a word: several. But, let’s focus for now on

just one — the one related to creating business

rules in the system. What do I mean by “business

rules”?

Presumably, you would like to be able to custom-

ize R/3. You would like to make the software uphold

some of the unique rules and policies your businessneeds to operate under. And, it sure would be nifty if

certain “follow-on” business transactions could be

100 percent automated without the need for someone

to “follow-up” the next day to fix a whole bunch of

automatically processed errors.

To achieve this, you’ll need two things: master

data and configuration table entries. These two

things contain settings — or business rules — that

tell R/3 what to do in response to your end users’

oftentimes clever attempts to jam square pegs intoround holes. The relationships that you declare

among your Organization Structure pieces are what

simplify this “rules-setting” process in master data

and configuration table entries.

As you establish the relationships, you want to be

mindful of three Org Structure traits:

Figure 4 The Overall R/3 Organization Structure

Note: Sales Org is below Company Code, but any Plant can link to any Company Code

whether or not that Plant also links to a Sales Org. If it does link to a Sales Org, then it canonly link to the Company Code linked to that Sales Org. The Org Structures DistributionChannel and Division are unique to the SD module only, and do not have their own relationshipsto Plants, Company Codes, et al.

Client

Chart of Accounts

Chart of Accounts

Operating Concern

Controlling Area Controlling Area

Company Code Company Code Company Code

Sales Org

Sales Org

Sales Org

Sales Org

Division Division

Dist. Channel Dist. Channel

Division Division Division

Dist. Channel Dist. Channel

Division

Plant Plant Plant Plant Plant Plant Plant





• Org Structure Trait #1:

Lower Levels Love Lounging.

In general, any structure (such as “Company

Code”) that appears above another structure (such

as “Plant”) in the hierarchical diagram in Figure 4is subject to much more data processing. It sits as

a field in a greater quantity of database transac-

tion tables. Thus, it made sense for R/3’s pro-

grammers to also use it as a mandatory “If/then”

variable in more of the master data and configura-

tion table entry settings.

But database activity volumes are not the only

reason for having higher-level structures (such as

“Sales Org”) appear in more customization set-

tings than lower-level structures (such as “Divi-

sion”). Another reason deals with the number of configuration table entries you are forced to set

up when implementing your R/3 system. For

example, the typical R/3 installation will have

larger numbers of Divisions than it does Sales

Orgs. Thus, by putting the Sales Org data field

— but not the Division data field — as a variable

in a configuration table, the customization effort

becomes faster, with fewer entries required in each

table, and thus, simpler. True, not all configura-

tion tables follow this approach. But, as we’ll see

later, some of the most important ones do.


Higher Levels Hate Hiding.

Structure pieces at the top of the pyramid (Chart

of Accounts in FI, Controlling Area in CO, Plant

in MM, Sales Org in SD) don’t like to stay at

home when someone is throwing a “Let’s Create

Some Master Data” party. You can hire some

big, muscular people to stand guard at the front

door, and it won’t matter. You just can’t have

your party in your SAP module without the top

Org Structure.

For example, suppose you have a Plant called

XYZ, and suppose you want this Plant to have

four different “storage locations.” Now, suppose

you stock your Material #12345 in all four of

Plant XYZ’s different storage locations. Natu-

rally you’d like the opportunity to set up some

unique (Material) master data settings for that

Material in each of XYZ’s four locations — a

unique storage unit of measure/unit of issue, for

example. It would be highly inefficient, though,if somebody had to fill in Plant XYZ’s Material

Master “Tax Status” field over and over — once

for each of the four times you’ll need to create

and save a “Storage Location” view for the mas-

ter. No one wants to sign up for this boring data-

entry activity. It takes up time. And, it’s easy to

make a typo.

Therefore, SAP provided you both a “Plant” field

and a “Storage Location” field in the Material

Master. Data such as Tax Status, Standard Cost,

and Planner (MRP Controller) remain as con-stants for a given Material/Plant combination,

after the first time this data is entered and saved.

You thus save time by only having to enter this

Plant-specific information as master data once,

no matter how many different Storage Location-

specific views you need to activate within that

Plant.


Double-Dippers Deepen Drill-Downs.

Looking back at the Org Structure diagram in

Figure 4, do you notice anything unique about the

Chart of Accounts (COA) organization element?

It links twice to lower-level elements. Twice!

Once to the Controlling Area level, and once to

the Company Code level. Of course, there is one

teensy catch: SAP R/3 documentation of Com-

pany Code to Controlling Area FI/CO linking

rules! In addition, the Controlling Area is the

highest level in which reports can be created,

since master data and Chart of Accounts

are stored here. To make CO allocations between

different Company Codes or the correspondingreports, you must assign all Company Codes,

when possible, to a single Controlling Area.

The Company Codes must agree in the number

of posting periods (fiscal year variant) and in

the Chart of Accounts, but can use different

currencies.





In English, that means that you cannot link a

Company Code to a Controlling Area unless each

shares the same COA code and fiscal calendar.

More to the point, the practical impact of this

double-dipping is that it impacts which of theonline transaction drill-down paths from CO

reports to FI source documents become possible.

Once a Controlling Area and Company Code are

linked, the end user can use standard “drill-down”

functionality to navigate from a cost-center or

profit-center line-item display of account activity

to that linked Company Code’s originating trans-

action. You do not need to declare this path in

any configuration table. Merely linking your Org

Structure elements establishes this automatically,

putting your end users in immediate double-click

heaven.

How 1:1 Org Structure Relationships Can Challenge a Rollout

Of course, “traits” in any software system represent

double-edged swords, wielding both potential free-

doms and prison sentences. So, deciding on what Org

Structures to declare, omit, and link to one another in

your R/3 system can become something of a mental

hurdle.2 The temptation exists to simplify this pro-

cess by establishing as many one-to-one relationships

as R/3 will allow — one Chart of Accounts (COA)

code for each Company Code, for example.

But how does reaching for this system-available

design option impact your rollout in terms of configu-

ration table maintenance, master data synchroniza-

tion, and knowledge sharing between Phase I and

Phase II end users? And why? As we look at each of these areas, take note of how each trait of Organiza-

tion Structure comes into play:

1. Configuration table maintenance: The

COA code acts as a mandatory variable in

the three dozen or so customization tables

for automated sales, inventory, and

procurement accounting.

But, the Company Code is not a mandatory

variable! Remember, Lower Levels (of Org

Structure) Love Lounging. So, if the Phase I

design had one Company Code in scope, adding

a new Company Code for Phase II does not,

by itself, cause a need for maintenance in

these configuration tables. But, if the Phase I

design had one COA code in scope, then however

big the “automatic accounting” configuration

tables are now, adding one more COA doubles

the size of each table. Adding two moreCOA codes triples the size. Adding three

more quadruples the size. Soon, the depth and

complexity of what’s in there is so great that

only an expert can interpret the tables. This

can slow down the rollout — not only

because somebody actually has to add lots

of entries to all those tables for each new

Chart of Accounts code, but also because

of all the potential maintenance and diagnostics

efforts that will be consumed when some

unexpected result occurs during rollout

testing.

Of course, “ traits” in any software system represent double-edged swords,

wielding both potential freedoms and prison sentences. So, deciding on whatOrg Structures to declare, omit, and

link to one another in your R/3 systemcan become something of a mental

hurdle. The temptation exists to simplify this process by establishing

as many one-to-one relationships asR/3 will allow — one Chart of Accounts(COA) code for each Company Code,for example.

2 If you have doubts as to what the correct decisions are, you’d be well

advised to enlist the support of a consultant.





The particular table in Figure 5 says to record the

actual exchange rate Gain/Loss to accounts

702010 and 702000 for any foreign currency

balance in G/L account #113101. Notice that

although G/L account balances are logically

specific to a given “Company Code” (i.e., a G/L),

the Company Code itself is not an account deter-

mination variable in this table. Instead, the Chart

of Accounts code that is assigned to the Company

Code acts as the determination variable. This

allows — or forces, depending on how you want

to look at it — each Company Code assigned

to a single Chart of Accounts to have consistent

accounting results, and to have simplified

configuration table maintenance.

2. Master data synchronization: The COA code

acts as a data-processing variable in the creation

of G/L account master data. On the surface,

this may sound tame. But, remember that thetypical SAP implementation project — like the

one at Graham Packaging, our case study —

has three totally separate active systems (Devel-

opment, Quality Assurance, Production) that

combined contain upward of 10 individual

“clients” (see Figure 6). And, all master

data in R/3 can be created just one “client”

at a time. Hmmm.

If we are to assume that a typical site requires

400 G/L accounts, then each new Company Code

brought into scope for Phase II does not necessar-

ily force the need to add new master data. If all

Company Codes share the same COA code, then

it only forces the rollout team to activate the

existing master data for the new Company Codes

(i.e., create new “views”). But, remember that

Higher Levels Hate Hiding when it comes to

master data. As a result, each new COA code

brought into scope forces the need to add

another 400 G/L account masters!

As the quantity of these G/L account masters

(or any master data, for that matter) increases, it

becomes more and more difficult to keep each

SAP “client” in synch with the others. It’s simplytoo easy for people feeling time pressure to create

a master in one or two clients as new business

requirements pop up here and there during rollout

testing, and in the process forget to add that to the

other clients when time allows the next day or the

next week. In a mere two or three months, a

Figure 5 Example of One of R/3’ s “ AAA” Configuration Tables





client — or even an entire system — can become

so dissimilar in its master data to the others that it

is unusable for its intended purpose. This can

slow down a rollout by both producing unreliable

testing results and, in extreme cases, forcing a

system to become unavailable for one or two days

while the Tech Heads — uh, okay, Basis profes-

sionals — refresh a client with a copy from

another system.

3. Knowledge sharing between Phase I and

Phase II end users: The COA code acts as

a control element for which businesses (i.e.,

Company Codes) can have their transaction

data accumulate in a single cost accounting

reporting and allocation ledger (i.e., Controlling

Area).

This has a direct effect on what people are look-

ing at on their screens — i.e., in “drill-down”

reporting. Or, as paraphrased earlier, Double-

Dipping Org Structures Deepen Drill-Downs.

So, when a Phase II end user from one site

phones a Phase I end user from another site with

a question, the two people very well might not be

able to see the same data on the same screens,

hampering the knowledge-sharing process. If the

rollout plan calls for site visits by the Phase I

participants to perform the end-user training for

Figure 6 Graham Packaging SAP Implementation Project — System Landscape

DEV

Client 000 -SAP Delivered

(Empty)


(Example)


(Early Watch)

Client 100 -Customizing

(Development)

Client 110 -Unit Testing

Client 120 -ABAP Testing

Client 130 -Prototype

(Sandbox)

Client 140 -Refresh

(copy of 010)

Client 150 -Authorizations


(Empty)


(Example)


(Early Watch)

Client 300 -Production

QAS


(Empty)


(Example)


(Early Watch)

Client 200 -Quality Assurance

Configuration

Client 110 -Quality Assurance

Testing

Client 260 -Training Master

Client 270 -User Training

CTS

CTSSCC1

PRD





the Phase II participants, this becomes perhaps

a minor slowdown risk. However, after the

cutover, this becomes a serious risk to the speed

at which Phase II participants are able to absorb

the new processes, and to stop making data entryand data interpretation errors.

Taking into consideration the impact from all

three Org Structure traits, the project managers for

the Phase II rollout of Graham Packaging’s Phase I

design chose to use one COA for all sites worldwide.

Each Company Code participating in the global

rollout got linked to just a single COA code, estab-

lishing a “one-to-many” Org Structure relationship.

The real-life impact of this decision vis-à-vis our

three generic problem areas is discussed in the nextsection.

The Main Benefits of a Single Versus a Multiple COA’ s Code Choice

The option of using less when more is available

always begs the question: “Do we need to sacrifice

important local needs in order to do that?” Some-

times the answer is, “Yes” — standardization forces

sites to do with fewer options than they would prefer

and/or require.

However, in the case of Graham Packaging’s

COA code decision, a little digging showed that they

could both standardize and customize.

Let’s begin the case study with implementation

problem area #1: the maintenance of configuration

tables.

Maintenance of Configuration Tables at Graham Packaging

First, let’s clearly identify the “local,” country-

specific requirements as compared to the Phase I

design for the automatic sales, inventory, and

procurement configuration tables:

• Phase I design: The tables had been set up to

respond to attempts by end users to save Logistics

data entry transactions such as “Create a SD Bill-

ing,” “Backflush a Manufacturing Order,” and

“Enter a Vendor Invoice against a P.O.” Thisresponse was to automatically find G/L account

numbers to debit and credit, based partly on what

the Logistics end user’s data entry values were (e.g.,

which Plant, which Material, which Sales Org).

• Rollout specifications: All sites in the rollout,

regardless of which country they were in, planned

to use many of the exact same end-user transac-

tions. The Plants, Materials, and Sales Orgs

would be different, however. Graham Packaging

Co. L.P. wanted the G/L account numbers to be

the same anywhere in the world for the same

Logistics transaction, in order to create standard-

ization. Yet they also wanted to leave room for

country-specific accounting results on a single

Logistics transaction, should that become neces-

sary (perhaps legally necessary) someday in the

future.

Second, let’s bring in some screen shots of the

configuration tables to see how the use of a single,

worldwide COA code accomplished the same thing

that a “one COA per Company Code” design wouldhave (i.e., meet the specifications), while avoiding the

latter’s negative side effect on the rollout.

Notice in Figure 7 how four variables determine

an “automatically derived” G/L account number. For

our purposes, we do not need to learn what these

things called “Process” and “Account Modifier” and

“Valuation Class” mean. But, we do need to remem-

ber that R/3 “finds” the Chart of Accounts code (e.g.,

“GCOA”) because of our linking of each Company

Code to one and only one Chart of Accounts code.

And, we also need to know about one additionalvariable that Graham Packaging elected not to

activate yet, and which therefore is not visible in

Figure 7. This variable is called the “Valuation

Grouping Code.” It represents one or more Plants.

And, where is “Company Code” in Figure 7?





The answer is that the “Company Code” is merely an

indirect factor in the determination of G/L accounts

for automated inventory accounting. It plays a role

because all inventory-related end-user transactions

require the data entry of a Plant, and because all

Plants must be assigned to exactly one “Company

Code.” That Company Code, in turn, points to

exactly one Chart of Accounts code. And that, inturn, acts as a direct variable in most automated ac-

counting tables, such as the one shown in the example.

Therefore, keeping in mind the Phase II goals

of consistent accounting and future flexibility, we

can see the following conclusions from Graham

Packaging’s decision to go with a single COA

code for all Company Codes worldwide:

• Many of the automated accounting tables (such

as this GBB Process thing, shown in Figure 7)required zero additional entries when adding

new Graham Packaging sites to the rollout !

• In the future, if some sort of new country-specific

law forced some of the sites to adopt unique

inventory accounting, then this could easily be

accommodated by activating the “valuation

grouping code” variable. For example, Graham

Packaging could create two valuation grouping

codes — AAA for sites in the affected country,

and BBB for all other sites. While this would

double the size of the tables, that is far better than

what would happen if all the sites of a given

country had their very own COA code, since that

would force new entries in the table for each andevery Company Code.

Master Data Synchronization at Graham Packaging

Earlier I mentioned the rollout challenge of keeping

master data of all types in synch among the 10 or so

“clients” of a typical project. But, we also mentioned

the pressure to address “local” needs, especially

country-specific legal requirements. Graham Packag-

ing faced this dilemma during their Phase II rolloutswith their G/L account master data:

• Because all G/L master data would be linked to

one four-digit code, the use of a single COA

worldwide makes it much easier to do “client

compare” type analyses regarding which master

data is in one “client” but missing in another.

Figure 7 Determining an Automatically Derived G/L Account Number





• But, countries such as France and Italy impose

legal requirements on businesses to report their

financial results to the government using specific,

predetermined G/L account numbers. So, that

requirement might suggest the need to give sites

in those countries their own unique Chart of

Accounts.

This apparent tradeoff turned out to be a non-

issue for Graham Packaging, thanks to some SAP R/3

functionality that allows each “Company Code” that

uses a particular G/L account master to have unique

settings on certain things. One of those things is

something called the “alternative account number.”This field allows all financial transactions to get

recorded against two account numbers — the

“normal” and the “alternate.” Thus, if this field is

populated for all G/L accounts, then all financial

balances can be shown either using the business’s

account number, or using the government’s account

number.

Notice in Figure 8 and Figure 9 the difference

between the “Chart of Accounts View” and the

“Company Code View” screens of G/L Master

#211000.

In Figure 8, all Company Codes assigned to Chart

of Accounts “GCOA” that use G/L account #211000

must accept that text description, that balance sheet

vs. P&L setting, and so forth. These settings stay in

force regardless of which Company Code assigned to

the “GCOA” Chart of Accounts is involved.

But what Figure 9 shows us is that each Company

Code assigned to Chart of Accounts “GCOA” thatuses G/L account #211000 can have unique settings

on things such as an “alternative account number”

value.

Therefore, keeping in mind the rollout goals of

master data synchronization among all the “clients”

and meeting the country-specific financial reporting

Figure 8 The “ Chart of Accounts View ” Screen





laws of France and Italy, we can see the following

conclusions from the decision to use a single COA

code worldwide:

• Although allowing business units in France and

Italy to have their own unique COA codes would

have enabled those sites to address their country-

specific accounting regulations without directly

impacting any other Graham Packaging site, this

would have meant much more difficult “client

compare” monitoring of the G/L master data.

Some of Graham Packaging’s G/L account masters

would have linked to COA code #1, some to COA

code #2, and some to COA code #3, rather than allof it being linked to just a single COA code.

• The use of a single COA code worldwide in no

way impacted the ability of the France and Italy

sites to uniquely address their legal requirement.

The France sites could use French government

“alternative” account numbers. The Italy sites

could use Italian government “alternative”

account numbers. And, all other sites could

simply leave that field blank.

Knowledge Sharing Between Phase I and Phase II End Users at Graham Packaging

Finally, what kind of knowledge sharing is important

to Financial Accounting end users? And, how did the

decision to use just a single COA code support this?

• Typical end-user question: “Which account num-

ber do I use for business transaction XYZ?”

• Graham’s goal: Worldwide consistency in aggre-

gate, consolidated reports — Graham wants the

same accounts to have been used the same way

by all sites, if the business purpose is identical.

The first step in reaching this goal was to create

Figure 9 The “ Company Code View ” Screen





what Graham’s executives called a “Descriptive Chart

of Accounts.” This was a document published on

its internal Web site that contained a two- or three-

sentence description of when to use each and every

G/L account related to its single “GCOA” onlineChart of Accounts in R/3. And, because Graham

went with just the one COA code in their final design,

they eliminated the possibility of end-user confusion

when somebody used R/3 to view standard reports

that list “their” Chart of Accounts account numbers.

Anywhere in the world, the G/L account numbers that

an end user was viewing would always match up to

the account numbers in this “Descriptive Chart of

Accounts” document.

The second step toward realizing the goal of

knowledge sharing was to ensure that all end usersaround the world would be able to look at the same

kinds of reports for the same kinds of source transac-

tions. This way, if somebody in Germany wondered

which G/L account number to use for purchasing a

certain category of freight supplies, he or she could

view a report for that kind of business activity

recorded by sites in other countries, and then “drill-

down” into the source documents. By looking at

the source documents of a G/L account’s balance

(rather than just its balance), or by phoning the person

who created the source document, the end user in

Germany could more easily form an opinion on

how closely that transaction resembled his or her

current “freight supplies” purchase.

What makes this “shared” drill-down reporting

possible is the shared COA code. Remember that

Company Codes can only be assigned to a single

Controlling Area when the COA code is identical.

Otherwise, each Company Code must have its

own, unique Controlling Area (refer back to the

SAP R/3 documentation of Company Code to

Controlling Area FI/CO linking rules discussedin Org Structure Trait #3).

These “Controlling Area to Company Code”

linking restrictions, in turn, impact the reports that

end users view, as most of the standard reports in the

CO module are sensitive not only to the Controlling

Area code, but also to the “standard hierarchies” of

the Controlling Area code, such as the “cost center”

and “profit center” standard hierarchies.

Without the use of a “one-to-many” Org Structurerelationship, an end user in Germany viewing a

Graham “Profit Center” report (such as the report

shown in Figure 10) would not be able to drill-down

into the US-based source document for G/L account

#590000, as shown in Figure 11.

Therefore, keeping in mind the knowledge-

sharing rollout goal of consistent G/L account usage

worldwide for similar business transactions, we can

form the following conclusions about the single

COA code design decision:

• End users from all countries will see exactly the

same list of G/L account numbers when viewing

R/3’s “Display a Chart of Accounts” online

report. These account numbers will correspond

one-for-one to Graham’s offline “Descriptive

Chart of Accounts” document.

• An end user from one country can “drill-down”

into a G/L account’s source documents (such as a

goods receipt or a purchase order) from another

country, using standard CO module reports. This

gives that end user a common basis for compari-

son to his or her own questions about when to

use a certain G/L account, and a common visual

reference when talking by phone to that foreign

site’s end user.

Conclusion

Graham Packaging demonstrates a firm with business

needs that fell within the capabilities of a “one-to-

many” FI/CO module Org Structure design. Not allSAP R/3 installations will be like that, and the point

of the case study is not to promote “one-to-many”

designs at all costs.

But, my thoughts at the end of their rollout

project were clear. First, Graham Packaging’s





Figure 10 A “ Profit Center ” Report

Figure 11 Drilling Down into G/L Account #590000 of the “ Profit Center ” Report




www SAPpro com ©2000 Wellesley Information Services All rights reserved88

corporate site city of York, Pennsylvania, is a

wonderful place for a wandering consultant such as

myself to one day return and plant some roots. So

many golf courses. Unpretentious, affable popula-

tion. Bountiful and inexpensive Diet Coke machines.

Second, decisions about Org Structure relation-

ships during a Phase II rollout aren’t just an Account-

ing department interest. They’re everybody’s inter-

est. The potential impact — on configuration table

maintenance, on master data synchronization, on

knowledge sharing among end users — is too fasci-

nating to keep to just the bean counter’s group. R/3

is an integrated system. A clear relationship exists

between the degree of “one-to-one” relationships used

in its Org Structure design and the degree of difficulty

posed by those three rollout issues. The case studysuggests that it pays to search hard for ways to live

within the constraints of “one-to-many” Org Structure

relationships, especially in regards to the FI/CO

module.

Third, every project seems to generate new SAP

R/3 jokes, riddles, and stories. I’ll end this article by

sharing one from the Graham Packaging rollout team.

It goes like this: “How many ways is R/3 like a box

of chocolates?” Give up? The answer is four. It’s

pretty on the outside, messy on the inside. There are

different tastes and textures depending on which end

of the box you’re reaching into. There’s no “one”

right method for achieving the desired results. And,

when you’re finished, all you want to do is sleep.

Kurt Goldsmith specializes in the repair of broken,

loose, and otherwise unpleasantly surprising R/3

integration designs. Areas of particular enjoyment

include CO-PA to G/L Reconciliations, Automatic

Inventory/Sales/Procurement Accounting,

Make-to-Order Sales, Chart of Accounts Redesign,

Purchase Requisition Release Strategies, ABAP/

Query, and the fine art of phrasing new OSS notes

to successfully avoid the infamous “How About

Some Remote Consulting” response.

When not wearing his SAP hat, Kurt can be found

either at the local horse-racing track, in the

bubble bath, or in his home city of Austin, Texas. A 1995 graduate of the U.T. Austin MBA program,

Kurt gained initial R/3 project work through Thom

Morgan and Warren Norris of SAP America’s

Dallas office, multinational R/3 work through

John Wade and Bill Arrigo at IBM in New York,

and eventually full-module integration work

through Winni Hesel and Julian Pasley-Smith

at the Malvern, Pennsylvania, offices of ICM

America LLC.

You can contact Kurt with questions or comments

about this article at [email protected].

About ICM America LLC

International Consulting Munich (ICM) has offices globally, and specializes in the full suite of R/3 and

R/3-related product implementations. For information on and assistance with R/3’s e-commerce options —

including “Business-to-Business” and the “mySAP.com Workplace” — please contact Managing Partner

Winni Hesel at the ICM America offices (610-578-4807). For information on and assistance with R/3’s

backend New Dimension products — including the Business Warehouse and Customer Relationship

Management — please contact Managing Partner Julian Pasley-Smith at the ICM America offices

(610-578-4808).

Date post:	14-Apr-2018
Category:	Documents
Upload:	ryozan
View:	216 times
Download:	0 times

A Case Study in SAP R3 Organization Structure Design Taking FI COs One to Many Path to Speedier...

Documents