Organizational Changes: Implementing Custom Rules for Profit Center Derivation

[thomas_meder]

About Organizational Changes

The Organizational Changes feature within SAP S/4 HANA accounting allows you to assign new  profit centers to objects, such as materials or sales order items.

It comes with a built-in process that starts with defining the intended change, simulating it, processing the runs to change the objects and create transfer postings. A final step "completion" includes built-in checks. The exact process model is explained in the help pages [1]. What you will learn here are aspects of defining objects for organizational changes via Business Add Ins (BAdIs, see also: [2]).

On Customer Rules (BAdIs)

Who needs to implement custom rules

The feature comes with a built-in default profit center derivation hierarchy. In principle, it is implemented based on default profit center inheritance logic. For instance:

• Sales order items derive their profit center from the material sold.
  In this example, the sales order item is a dependent object of root object material.


• Within enterprise projects (EPPM), work breakdown structure (WBS) elements inherit their profit center from the project header. Here, the project header is the root object.


• Fixed assets inherit their profit center from the cost objects they're assigned to.

The Organizational Changes feature implements exactly this default logic for profit center inheritance. You assign a new profit center to the root object, and it will find the dependent objects.

Often, customers implement profit center substitutions. For instance, for sales order items, many customers use customer or market attributes to find an attribution. So, to overwrite these default inheritance trees, it is possible to implement “custom rules” that allow you to specify the objects that should be reorganized and to determine the new profit center by using your own custom rules.

So, rules are the solution to go for when ...

• Custom profit center derivation rules are in place (e.g. substitutions) and


• It is not possible, too error-prone or too tedious to manually enter or import them using the Organizational Changes app.


• Or, as for sales order items or purchase order items, there's no possibility to enter such objects into the app, because they are constantly created by business operations. For other objects, like fixed assets, it might be easy to import them, because their creation can be controlled.

Limitations and hints

To say it clearly, rules defined in BAdIs are powerful. They allow you to assign a new profit center to objects that have just been created (e.g. new sales documents) and that have been unknown when creating or activating an organizational change. The rules reflect changes to these objects which might even lead to deletion of objects from an organizational change, and they are fast and performant.

Nevertheless, to ensure data consistency, rules allow changes only for objects that are also allowed for entry on the user interface (except for sales order items).

Also, we strongly recommend that you keep rules stable, at least after the activation of an organizational change. Do not change them, except to correct coding errors. Instead of changing the rule implementation, create a second organizational change right after the current organizational change for the correction of wrong assignments over changing the current implementation. Nevertheless, this isn't possible for the same objects and the same effective date.

How rules work

When an organizational change is activated, processed or completed, it tries to determine relevant objects. Those objects are either entered in the Manage Organizational Changes app, added via rules (BAdIs, both as "root objects") or derived as dependent objects. Dependent objects inherit their profit center from a root object. For example, sales order items inherit profit centers from their material when no rule is implemented. Important to know:

• Within this process of determination, the system prioritizes app entries over objects identified by rules.


• Also, objects added as root objects, if added, can no longer be dependent objects.
  For example: Once a sales order item gets a profit center assignment from rules, it is no longer considered as dependent object from its material.


• Objects added via rules are always considered to be a root object.


• Objects are determined in a certain order.

1. 
   
   
   
   1. cost centers
   
   
   2. project definitions (aka "project header")
   
   
   3. wbs elements
   
   
   4. products (aka "material")
   
   
   5. orders and it's variants, such as production orders, internal orders, networks
   
   
   6. network activities
   
   
   7. fixed assets
   
   
   8. sales order items
   
   
   9. inter company sales order items
   
   
   10. purchase order items
   
   
   11. open items
   
   
   
   

To implement a rule, you need to implement these objects:

1. A CDS view which delivers the objects that are subject to change.


2. An implementing class, specifying the name of your CDS view in method change_cds_name().


3. Optionally, an implementation of method change_cds_result(), if it is necessary to iterate over the lines that have been returned by the CDS view.


4. An enhancement implementation for the enhancement spot FINOC_RULE.

Best performance is achieved by avoiding iterations over the CDS result in method change_cds_result(), but this requires some skills within the topic and good knowledge of the data model.

Implementing CDS views

In the table below, you find "base" and "default" views. Default views are those that the system uses in general to determine dependent objects. Here, you'll find implementations for the default profit center inheritance logic, but only for those cases, where we as SAP allow deviations. They give a good orientation about how your CDS View could look like, and how it should reuse parts of this default views.

Objects and Variants	Base CDS View Default CDS View	BAdI Definition
Products (aka Materials)	FINOC_RULE_MAT_BASE FINOC_RULE_MAT_DEFAULT	FINOC_RULE_MAT_ENH
Orders, Networks ....	FINOC_RULE_ORD_BASE FINOC_RULE_ORD_DEFAULT	FINOC_RULE_ORD_ENH
Projects	FINOC_RULE_PRO_BASE FINOC_RULE_PRO_DEFAULT	FINOC_RULE_PRO_ENH
Sales Order Items	FINOC_RULE_SOI_BASE FINOC_RULE_SOI_DEFAULT	FINOC_RULE_SOI_ENH
Cross-company sales order items	FINOC_RULE_SOX_BASE FINOC_RULE_SOX_DEFAULT	FINOC_RULE_SOX_ENH
WBS Element	FINOC_RULE_WBS_BASE FINOC_RULE_WBS_DEFAULT	FINOC_RULE_WBS_ENH
Unassigned open items		FINOC_RULE_MAT_OI

Nevertheless, there are some points to consider when implementing a CDS view:

• Your CDS view must, have at least the fields (some may be empty) that are used in the default view. Nevertheless, you are allowed to add additional fields. This might be necessary when implementing method change_cds_result with your own logic. You can them use these fields in method change_cds_result().


• It is a good idea to use the default view as a template, to restrict the default case (with a where condition <> my special cases) to keep the main logic and to add your special logic below, by specifying a UNION ALL (refer to CDS view FINOC_RULE_ORD_DEFAULT).


• When selecting instances of a certain object, retrieve them from the base view. It will deliver all elements that are allowed for change and handle additional topics such as calculating field prctr_old (the "old profit center") or setting initials for source fields and the profit center derivation source types. Just forward these fields without changes.


• The profit center old must be constant. Consider that, having processed an org change, this field changes to the new profit center. If an organizational change is processed again or the completion is run, it would now no longer consider this object for the organizational change and exclude it from the result. At the end, the object would be deleted from the organizational change and reset to the previous profit center. This is also why you should use the base view as your source of data - this is handled there.


• Source fields are only used in the hierarchy report, and SAP foresees only the fields for the default derivation logic. At best, make sure these fields are initialized (by taking them over from base view), but don't change. The same applies to the profit center derivation source type field.


• Some default views are not returning any result, such as for materials. This is because, by default, materials are only added via the Manage Organizational Changes app, not as dependent objects. Don't get confused by that.

Implementing the method change_cds_name()

Once you have implemented your CDS view, you need to implement method change_cds_name() and set the changing parameter to the name of your CDS view.

Implementing the method change_cds_result()

This method allows you to iterate over the result retrieved from your CDS view - or the default view. Please consider that performance is improved when:

• You add fields to the CDS view rather than reading them in this view.


• You set the profit center new field already in the CDS view.

So, at best, there's no need to implement this method. That's easily said, but sometimes just not possible, or it is much faster for your organizational change project to just add code that already exists here - which is also a valid approach. So, it's also a trade-off between development hours and runtime - and feasibility. But, when implementing this method, make sure to implement a CDS view that returns all the fields and object instances that are needed here.

Examples

This article will be followed by some upcoming implementation examples. Here's the first one.

• Organizational Changes: Example for maintenance orders via BAdI
  In this article, you will learn how to implement a custom rule when the base view already contains all relevant fields.

Further information

• [1] SAP Help "Organizational Changes in Financial Accounting"


• [2] SAP Help "Business Add-Ins for Organizational Changes"

Conclusion

Implementing your own rules for organizational changes is possible using BAdIs, CDS views and by following the hints given above. It needs a developer and a concept, but gives you a lot of freedom to adapt the solution to your business needs.