Handling Organizational Changes with SLO and Company Code Split

sap slo datavard

In this fifth installment of my blog series about SLO (System Landscape Optimization), I will go further into how SLO can handle business transformation projects while minimizing impacts on ongoing business. In my previous posts, I focused on SLO’s tools for ensuring SAP data integrity and flexible go-live dates on Divestitures and Mergers and Acquisitions (M&A) during large-scale transformation projects.

Company code splits and plant reallocation

Now I will get into the details of splitting company codes. When separating a company, you will have to deal with all kinds of co-mingled data. In the best case, you can separate the data regarding logistics based on plants. For this, you can obviously reallocate a plant to either a brand new company code or a previously existing one.


Several solutions exist for splitting company codes in SAP LT (Landscape Transformation). However, none of these are released for customers yet. But I still want to address it (even if only briefly) because the situation is very important for many SAP customers.

A common reason for splitting company codes is the addition of a plant in a foreign country. For such a plant, taxes are reported for storage locations or sales offices via a domestic company code. For European Union countries, taxes can be reported as single reports or collected reports for each country. In general, such a foreign plant only makes sense and is legal if no other requirements to legal reporting exist than the tax reports themselves.

To implement a foreign plant experienced FI users or consultants are required to define the relevant business processes, align the procedure with the company’s auditor and make the relevant settings during customization.

It’s often the case that a plant in a foreign country already exists before it’s brought into the SAP system. But it must be set up to belong to a company code which is in the same country as the plant. Mostly this is because of historical reasons because when implementing SAP, the functionality of foreign plant is not available yet. If this is the case, then implementing the foreign plant would mean creating entirely new custom codes for the plant which leads to a break in the business processes. In the newly configured plant, these processes would start anew. In finances this is not a problem because the financial department generally views changes in business processes as desirable. Changes bring either process simplification, tax savings or both.

For logistics, however, a break in processes can be expensive and cumbersome. For example, for receiving goods and deliveries, all existing scheduling agreements and open purchase orders need to be adjusted. To avoid this overhead, the conversion approach of SAP LT can be used. However, the scenarios where such conversions are required often depend heavily on customer-specific aspects such as customizing and processes. Often, customization is needed. SAP’s SLO consulting team can provide the plant relocation scenario (which is technically a company split) as a consulting solution. Some of these scenarios are available from selected SAP LT partners. The most commonly used solution for the SAP consulting team is called SWB (Scenario Workbench) and is based on SAP LT’s conversion technology.


To use this consulting solution for splitting company codes, consultants perform an in-depth analysis of the SAP system. This helps to determine the use of SAP modules and data volumes. Workshops with key users and architects from the client’s team are then held to clearly document the goals of the conversion. The conversion covers changing company codes based on plants. This changes the company code for single plants within the logistics modules of the SAP ERP system.

As a result, plants are relocated to other company codes, i.e. the assignment of plant codes to company codes changes, effectively splitting existing company codes. In finance, balances and open items are usually posted in the new company code. One of the challenges when posting in finance, but converting within logistics modules, is minimizing process breaks. To help with this, the newly posted finance documents are entered into existing documents of logistics processes.


Concepts and blueprint documents are created in workshops to determine the scope of the data transformations for the areas MM (Materials Management) and SD (Sales and Distribution). These documents describe how different business objects are to be handled in the transformation. Different aspects are evaluated for the business objects, including:

  • Data selection — When determining data of relevant plants in logistics, be sure to filter the data. One reason for this would be to filter data of material numbers to include only transactional data belonging to materials of a certain material group.
  • Expected data volume of the selection — Use some examples to determine the expected volume and result of a selection. For testing data transformations, an indication as to the expected data volume may help to identify the quality of a data conversion. There is a difference between cases involving only a few versus hundreds of thousands of data records as the result of a conversion. Also, to gauge potential runtime improvements of the conversion (downtime minimization), an idea as to the expected data volumes helps.
  • Conversion logic and transformation — Which fields or relations to other business objects need to be adjusted? Typical examples are storage location, shipping point and sometimes customer numbers and addresses.


Technology used to transform

Let’s look at the technology and the logic used for conversions. For example, a conversion using SAP LT (SWB) or performing postings using the SAP application (e.g. via BAPIs or batch input).

Figure 1 shows the procedure for splitting company codes and the different technologies used for different SAP ERP modules.

slo datavard code split

Figure 1: Graphical representation of a company code split


The result is a mapping between these characteristics to a list of business objects of different SAP modules. This list should include the following business objects in the area of the MM module:

  • Material numbers
  • Purchase orders, scheduling agreements and contracts (e.g. tables EKKO, EKPO)
  • Purchasing info records and purchase requisitions (e.g. table EBAN)
  • Order book (e.g. table EORD)
  • Inbound deliveries (e.g. table LIPS)
  • Material documents (Table MKPF)
  • Inbound invoices in the area of logistics (e.g. table RSEG)
  • Handling units (e.g. table VEPO)
  • Deliveries / stage of shipments (e.g. table VTTS)
  • MRP documents (e.g. table MDKP)
  • Stocks and special stocks
  • Batches

For the SD module (Sales and Distribution) these objects have to be analyzed and the conversion logic has to be determined:

  • Shipping documents (contracts, orders, etc.)
  • Index tables (e.g. table VAPMA)

Leave a Reply

Your email address will not be published. Required fields are marked *