If you wonder what are the options to create user-defined fields/customer characteristics in Margin Analysis and what are the pros and cons of each method, I will try to explain them in this article.
We have now 3 ways of creating COPA characteristics:
(1) Until SAP S/4HANA Release 2020, customer characteristics could be created only with the transaction “Maintain Characteristics” (KEA5) for Profitability Analysis. This is still available, but not recommended anymore. I will detail later the reasons we do not recommend the use of it anymore.
(2) As of SAP S/4HANA Release 2020, you can also create user-defined fields/customer characteristics (COPA characteristics) with the application “Custom Fields and Logic” for the business context “Accounting: Market Segment” for the Profitability Analysis component.
From SAP S/4HANA Release 2021, “Custom Field and Logic” app it is deprecated, you can use “Custom Fields” and “Custom Logic” apps.
(3) A third possibility is to create an append in include INCL_EEW_MARKET_SEGMENT_PS via SE11 and add a custom field (created via SE11) with reference to an existing Data element or using an existing Check Table. Afterwards enable this new field for Business Context: Market Segment via transaction SCFD_EUI, meaning the field will then be available for the “Custom Fields and Logic” app. Even if it looks more complex than option (2), this option may give big customers (using a high number of COPA characteristics) more flexibility than option (2).
Let’s analyze the three options and see what the differences, advantages and disadvantages between the three are.
- As mentioned at the beginning, KEA5 is still available in on-premise, but not recommended anymore. In cloud it is not available.
- Future developments for user-defined fields/customer characteristics will take place only on the basis of “Custom Fields and Logic app” (2) + (3). It is planned that, in time, this app will take over the previous functionalities of the transaction KEA5. Why is this important to know? If you create the user-defined fields/customer characteristics using the old transaction KEA5 (1), these fields will not be available in the CDS views, API`s or SAP Fiori UI`s. Moreover, there is no standard solution to make these fields available in CDS views, API`s or SAP Fiori UI`s for the time being.
- Only user defined fields/customer characteristics created with the “Custom Fields and Logic” app (2) and the ones created via SE11+SCFD_EUI (3) are automatically enabled for CDS views, SAP Fiori Ui`s or API`s.
You might think now:” if I have a customer characteristic created via KEA5 why I would not use option (3) and to enable it for the “Custom Fields and Logic” app using SCFD_EUI”?
- It is not possible to transfer existing characteristics, which were created via transaction KEA5 to the application Custom Fields and Logic app. Activities relating to the transaction “Enable Fields for Custom Field App” (SCFD_EUI) are not available for the old characteristics. SAP strongly recommends that you do not migrate these characteristics to the applications “Custom Fields and Logic” in any way. This would result in data loss and system unusability.
- About the standard fields which can be used as COPA characteristics and are available for CDS views, SAP Fiori UI`s or API`s, well not every standard field is available. Only those documented in the following link: APIs for General Ledger Accounting
(2) How to create user-defined fields/customer characteristics with the Custom Fields and Logic app
In the Custom Fields and Logic app, select the Business Context: “Accounting Market Segment”. Only fields created for Business Context: “Accounting Market Segment” can be assigned to an operating concern.
There are 3 types of user-defined fields/customer characteristics
If you choose to use type Code List a Check Table will get generated automatically, you need to fill the length of the fields and you have the possibility to maintain the values or load them from csv file directly in the app.
The check table cannot be maintained via SM30, the characteristics can be maintained only via the “Custom Fields and Logic” app, manually or via file upload. Once the user-defined field/customer characteristic is being created/changed/updated it needs to be published. This requires development rights.
Why option (3) is important as a variant of option (2)?
When you create the new custom field, with this option, you might use existing Data element or using an existing Check Table you have created, it doesn’t have to be the tables which are automatically generated as with the option (2). You can create your Check Table which can be still maintainable via transaction SM30.
For some customers it is important to be able to use SM30 to add COPA characteristics from an authorization point of view. Let me explain. When you are creating a new custom field or change it (this includes adding new values to the Check Tables) via “Custom Fields and Logic app” you need to publish it, that requires development rights.
These custom fields are usually maintained by the business users and most customers are reluctant to give them development rights.
If you use option (3) to create custom characteristics you can create your own Check Table, maintainable via transaction SM30, and you only need to give business users authorization for this transaction.
(3) How to create user-defined fields/customer characteristics with SE11 and enable the fields in “Custom Fields and Logic” app with transaction SCFD_EUI
The steps to create user-defined fields/customer characteristics via option (3) are:
- Create custom field via SE11 with reference to an existing Data element or using an existing Check Table. Please note that instead of the Check Table generated automatically starting always with ZZ* we have used an existing table which can be maintained via SM30.
Create an append in include INCL_EEW_MARKET_SEGMENT_PS also via SE11. In transaction SE11, open include INCL_EEW_MARKET_SEGMENT_PS, click Goto ->Append Structure
- Enter your DDIC objects or use the standard ones to add details such as Data element, Check Tables etc. for Code List fields. Activate the append structure.
- Before enabling a field of type Code List, create 2 CDS views Value Help View and Description View as shown below.
Value Help View:
@AccessControl.authorizationCheck: #NOT_REQUIRED @EndUserText.label: 'Code View for Product Type' @AbapCatalog.sqlViewName: 'ZZWWNTY_MSE_VIEW' @Search.searchable @ObjectModel.compositionRoot: true @ObjectModel.usageType.serviceQuality: #A @ObjectModel.usageType.sizeCategory: #S @ObjectModel.usageType.dataClass: #CUSTOMIZING @Analytics.dataCategory: #DIMENSION @ObjectModel.representativeKey: 'Code' define view ZZWWNTY_MSE_CODE as select from t2501 association [0..*] to ZZWWNTY_MSE_TEXT_VIEW as _Text on $projection.Code = _Text.Code { @ObjectModel.text.association: '_Text' @Search.defaultSearchElement: true key cast( wwnty as rkeg_wwnty ) as Code, @ObjectModel.association.type: [#TO_COMPOSITION_CHILD] _Text }Description View:
@AccessControl.authorizationCheck: #NOT_REQUIRED @EndUserText.label: 'Text View for Product Type' @AbapCatalog.sqlViewName: 'ZZWWNTY_MSE_TEXT' @Search.searchable @ObjectModel.usageType.serviceQuality: #A @ObjectModel.usageType.sizeCategory: #S @ObjectModel.usageType.dataClass: #CUSTOMIZING @ObjectModel.dataCategory: #TEXT @ObjectModel.representativeKey: 'Code' define view ZZWWNTY_MSE_TEXT_VIEW as select from t25a1 association [0..*] to ZZWWNTY_MSE_CODE as _Code on $projection.Code = _Code.Code association [0..1] to I_Language as _Language on $projection.Language = _Language.Language { @Search.defaultSearchElement: true key cast( wwnty as rkeg_wwnty ) as Code, @Semantics.language: true @ObjectModel.foreignKey.association: '_Language' //Use this for language-dependent descriptions: key spras as Language, //Use this for language-independent descriptions: //key $session.system_language as Language, @Search.defaultSearchElement: true @Semantics.text: true bezek as Description, @ObjectModel.association.type: [#TO_COMPOSITION_ROOT, #TO_COMPOSITION_PARENT] _Code, _Language } - Enable these fields for Business Context Market Segment via transaction SCFD_EUI. Then the fields will be available in “Custom Fields and Logic” app. Once these fields are available in the “Custom fields and Logic” app will also be available in CDS Views, API`s, UI`s.
When we enable the field, SAP generates/propose the code, then you just need to build it in a view, just like when creating the table fields and maintaining the Foreign Key.
Important to mention here is the naming convention for the newly created custom fields. To avoid name clashes of the manually created extension fields (e.g., during activation or system upgrade), SAP strongly recommends creating them also with a Field Suffix, which belongs to the Business Context of the relevant extension include (see transaction SCFD_REGISTRY). In our case the Business Context it is Accounting: Market Segment. Create your fields beginning with name ZZ_ or YY_ plus the Field Suffix at the end, e.g., ZZ_WWNTY_MSE.
This rule it is applicable for every custom field in SAP S/4 HANA. More details can be found on the link: Handling of Legacy Fields in SAP S/4HANA – SAP Mobility – Support Wiki.
Also make sure you have applied SAP note 2899836 – Custom Fields: Avoid Field Collisions in ABAP Managed Fields – SAP ONE Support Launchpad to detect possible name clashes for future system upgrades in the enabling tool.
- The last step is to check the fields in the “Custom Fields and Logic” app.
For more details on user-defined characteristics in business context “Accounting: Market Segment” in SAP S/4HANA Margin Analysis check also the content mentioned below:
3095004 – How to add user defined characteristics in Margin Analysis Fiori Apps
Custom Field Fiori App ( ID F1481)
Custom Fields App and Custom Logic App
2453614 – FAQ: Universal Journal Extensibility
Brought to you by the SAP S/4HANA RIG
