Describing the Solution Use Cases

There are three core use-cases for performing profit center reorganization.

• Introduce profit centers to your system.

  It could be that you don't have profit centers set up in your system but you plan to start using them. For this, you need to create all the profit center master data and assign them to all the different objects such as materials, cost centers, assets, etc. You would use the profit center reorganization tool to change from an empty profit center to a new profit center. Based on a validity date the tool updates and assigns profit centers to master data and also transfers the existing balance sheet values to the new profit centers.

• Correct wrong profit center assignments.

  You might have created a material master record and assigned the wrong profit center and even just an hour later you figured out it was the wrong profit center. You need to change it but someone else already created a purchase order for it. There is no chance to change the profit center directly anymore in the material. You use the profit center reorganization tool to define a reorganization: you enter the material and the new profit center assignment and directly process the correction. The tool then updates the profit center and the master record and checks to correct the inventory total. This is typically a scenario that focuses on only a few objects, not thousands of master data. In the case of corrections, you might not have an explicit reorganization date, so, there is no need to perform this at the beginning of a year or at the beginning of a period.

• Reorganize the organizational structure of your company.

  Complex reorganizations, when you need to replace and reassign profit centers in many and many types of master records will have a major impact on the profit center and balance sheet reporting. For these it's always best to have a clearly defined reorganization date, usually the start of a new financial period, so that the profit center balance sheet reporting has a clear separation. The tool takes care of the profit center replacement in all master data and performs transfer postings along the value chain. For example, for a material, the system updates not only the material master, but also all relevant purchase, sales, and production orders. It also performs the required transfer postings in inventory, including the work in progress and the goods received ensuring the consistency of the balance sheet values.

The use cases all only support transfer postings for balance sheet values. The tool doesn't transfer profit and loss values. The history of the profit and loss is always maintained.

In a merging scenario, you might for example have 10,000 profit centers and be unhappy with the maintenance and posting complexity. The system performance might suffer at times and you also question the added value of the very granular level of reporting detail. So, you rethink the profit center model and decide to slim the structure down to something like 200 profit centers for the whole group. Such profit center merge scenarios could potentially be defined by stating profit centers A, B, C, and D should be merged into the new profit center 1. But, in SAP S/4HANA the definition of the reorganization is not done on the profit center level, it's done on the lower level of the master data which carries a profit center.

In a splitting scenario, you might have a profit center A, and the business is growing quite a bit over the last few years, so, you would like to split the profit center into smaller pieces for better control. You decide to split profit center A to 1, 2, and 3. But how to do such a split? You could take all the amounts and allocate one-third to every new profit center, this might be okay for high-level reporting, but which profit center shall a material carry which so far had profit center A? Should it be assigned to 1, 2, or 3? This decision or definition of the new profit center is done individually for all relevant objects in the reorganization apps.

This singular, consistent logic can make the definition of profit center merge scenarios more complex but it means there is no differentiation in the tool between merging and splitting scenarios.

Note: You can use a business add-in (BAdI) for defining custom rules, for example, to identify all master data to be assigned below a new profit center in merge scenarios.