Business changes can create the requirement that a plant is assigned to a different company code. These can include changes in the legal structure for tax purposes, a reorganization for process improvement or the divestiture of a portion of the business that currently operates in the same company code as lines of business being retained.


Whatever the reason to change the company code assignment of a plant, there are two approaches to the change. One is to use the standard SAP system functionality and the second is to use the System Landscape Optimization (SLO) or Landscape Transformation (LT) solution. We will discuss both methods. In addition, some of the key considerations when making the change will be discussed.


Standard approach


Using standard SAP functionality to change the company code of a plant involves creating a new plant in configuration. Any other changed organizational elements such as sales organization or purchasing organization are also created. The new plant is assigned to the desired company code and all relevant master data and open/in-process transactional data is recreated for the new plant and company code. This approach closely resembles a reimplementation of SAP for the changed plant.


The standard approach is appropriate when the amount of activity in the plant to be changed is small. For example, if there are not many sales orders or purchase orders that are open at any given time, then this approach is a good fit.


However, when a large number of open transactions exist in the affected plant, the standard approach can cause significant disruption to business operations. Sales order and purchase order numbers which have been communicated externally will be changed. Since the plant number is changing, users will need to change what they enter in the system. In this case, where the high volume of activity makes the change difficult for the business, the SLO / LT approach should be considered.


System Landscape Optimization / Landscape Transformation (SLO/LT) approach


The SLO/LT approach uses a combination of standard functionality and special conversion programs.


Financial data such as customer and vendor open items and assets are transferred to the new company code using standard transactions. This maintains the auditability of the financials.


Logistics data like sales orders and purchase orders are transferred to the new company code using programs that convert any data elements having to do with the company code assignment of the plant. These may include company code, business partner, profit center, etc. After the conversion, the logistics data appears as it has always existed in the new company code. Converting the data at the table level using ABAP programs allows the business to continue processing existing sales order and purchase orders. For example, a purchase order that existed on Friday afternoon before the conversion can be received on Monday morning after the conversion using the normal transactions and procedures and the same purchase order number. The changed data causes the posting to occur in the new company code. The impact on the business and external partners is significantly decreased.


This same SLO/LT approach can also often be used to split plants and other organizational elements such as sales organizations and purchasing organizations if required.


Conclusion


The business environment sometimes requires changes to the organizational structure maintained in the SAP system. These changes can most often be accomplished with minimal impact to the business using the special tools and techniques of the SLO/LT approach. However, it is important to note that the details of the required conversions depend on the specific functionality and processes used in the system. The details and approach for your system are determined after an analysis done by experts experienced in these changes.


If you are facing this challenge let us know. One of our experts can discuss the options with you.

Updated: Nov 5, 2018



Growth, reporting/visibility challenges, acquisitions by the company, a new CFO desires different structure for the chart or perhaps original chart never fully met your needs. There are probably a dozen reasons to make a change to the general ledger account structure in SAP.



We have seen companies with regional entities spread across North America, South America, Europe, Asia and Africa desire to shift from a holding company mindset to an operating company approach. The CFO wanted all financial and controlling objects standardized globally. The number one object to harmonize was the chart of account. Another common scenario, we have seen is acquisition driven harmonization. The acquired companies have their chart of accounts aligned with the new parent company. This is typically a reporting and visibility initiative. At times the original chart of accounts in use doesn’t meet the needs of the company. It can be that be the length, logic, and structure did not properly capture the business and reporting needs of the company.


Regardless of the reason for the need to change the chart of account structure in SAP, there are two basic approaches to changing the GL account structure. One is the standard functionality within SAP and the other is the SLO (system landscape optimization) or LT (landscape transformation) solution. We will talk about both methods. Additionally, we discuss some of the key considerations when making a change.


Standard approach:

SAP supports the ability to create a new general ledger account. The new account is then posted to while the existing account is offset. Below is an example.


Your original account was numbered 100 with the text 'cash' with a balance of $1000.


100 - Petty Cash

$1000


You create a new a general ledger account 11000 with the description of 'petty cash.' The current balance of the new account will be zero until a posting occurs.


11000 - Cash

$0


Postings:

Credit GL Account 100 for $1000 and Debit GL Account 11000 for $1000


After posting

GL Account 100 -Petty Cash

$0


GL Account 11000 - Cash

$1000


That works. However, it is a point in time posting. That means going forwards GL Account 1100 is used after a specific posting period. If one looks at history, you will find the historical balances under the original GL account 100 and the current values going forwards under GL Account 11000.


Your GL account balances will look like the following. Let’s assume the change was made in April with the example.


Balances with two different accounts

This approach uses the SAP application. It can be automated to a degree, but remains a semi-manual process. More importantly, history stays with the ‘old’ account definition. Perhaps, there are unique country tax reasons for this approach. Yet, as you can see it is a ‘two-step’ approach that leaves history with the ‘old’ gl account. This implies a mapping exercise with reporting over multiple periods that span the postings to both the old and new accounts.


LT (SLO) approach:

SAP’s Landscape Transformation changes all usage of the GL account within the system. This means history is also adjusted. It doesn’t matter if it is open, or a closed item posted last period or several years ago, all data is consistently adjusted.


During the mapping effort, there are many consistency checks to validate that the mapping is supported by the SAP application. These checks range checks on the main GL master data in table SKA1 and the company code level GL accounts within SKB1 (master data table for the GL accounts by company code). These checks are very important in merge scenarios and look at the grouping of accounts by the balance sheet, P&L, open item managed, non-open item managed, reconciliation, currencies, postings and even more detailed items.


In contrast to the posting approach your account balances will look as if they were always using the new GL account number.


Accounts with SLO approach

The SLO/LT approach ensures a consistent transformation of the GL account structure across transactions, master data and customization data. The process can be a rename / renumbering of individual accounts to a merge of several accounts into a single account.


Regardless of the reason a company needs to change their general ledger account structure, there is a proven approach that consistently converts the system. Over the years we have gathered a few lessons learned while doing many chart of account conversions. If you would like some information or a consultation on the best practices one of our experts can help you.



Transformation project testing building blocks

A good testing plan needs a few basic building blocks; otherwise, transformations can have unexpected issues at go-live. Testing best practices for transformations have building blocks to help avoid testing shortcomings around data, systems, processes, and people.



It is not glamorous, testing needs to focus on the basics when it comes to transformation projects. No surprises during go-live are the desired outcomes of testing a transformation project.


Basic Building Blocks:

Data representative of production

Transformation projects need a solid depth and breadth of data. The optimal approach is to use copies of production data for test cycles. This supports a complete data set for tests with a mix of various data states (e.g. open, closed items). Data volumes similar to production support realistic metrics for the actual go-live (e.g. durations, performance tuning). The goal is simple, practice and test what you will actually transform in production.


System that supports technical aspects of a transformation

Transformations are best supported by a test system with a similar code base and data dictionary objects as production. More specifically, these test systems need a cycle with the ability to perform integrated tests. In addition, keeping track of other functional / technical items in the promote to production landscape. Avoid promoting untested objects. Once again it is about the simple goal of practicing and testing what you will do in production.


Understand processes that are impacted

Business processes need a testing focus during a transformation. It is a mistake to validate only programmatically or manually the changed objects (e.g. ABC is now XYZ), only check total record counts or summations. A process needs to be validated end to end. With transformations, it is testing the actual process that occurs in production.


Involve the business people that understand the processes

People that understand the events and processes that occur in the production environment are critical to your transformation success. It is not just the daily transactions actions but also the periodic events that can be a weekly, monthly, quarterly or year-end that need inspection.


Changes revisited

Little things can lead to bigger things. If a change is made to logic, or mappings during a transformation it needs to be retested. It is just that simple.


Process should be repeatable, focused and documented

Testing should be a well-documented and cataloged set of tasks. They should be easily repeated. Scripts are focused on content areas. It is more than doing the verifications, and totals check. Specific processes are documented and tested from both a reporting and transaction processing perspective during a transformation project.



We have had over a dozen years of transformation project experience and these testing building blocks have been present with successful transformations. Projects that stay disciplined using best practices have successful go-lives.


An outside review of your approach by our team of experts will help with your transformation project success.

© 2017 by FormBit. Designed by Stark Raving Kalm