Convert Manually Created Append Fields to Real Key User Custom Fields

[Karsten_Schaser]

Convert Manually Created Append Fields to Real Key User Custom Fields

Have you ever wondered how to convert your manually created "old" append fields into real key user custom fields? Doing so lets you easily expose these fields to OData services, SOAP services, SAP GUI transactions, and more, utilizing the same feature set. Have you ever wondered how to do that without losing your data and preserving your old field name, so that you don’t have to adapt your extension coding which consumes this field?

If your answer is yes, then this blog post is just for you.

Pease note that this blog does exclusively address SAP S/4HANA Cloud Private Edition and SAP S/4HANA On-Premise and doesn’t address SAP S/4HANA Cloud Public Edition.
In this blog we use S/4HANA as an abbreviation for SAP S/4HANA Cloud Private Edition and SAP S/4HANA On-Premise. In addition, for key user custom fields we use the abbreviation custom fields.

This blog post covers the following topics:

• In which cases you can convert your manually created append fields and
• How to convert your manually created append fields to custom fields

Custom field technology supports the conversion of manually created append fields to custom fields using transaction SCFD_EUI. These types of custom fields are called ABAP Managed Fields (abbreviation AMF).
This is especially helpful in the following two cases:

1. You already have a manually created append in the application database table. Due to the high migration effort needed otherwise, you need to keep this field. However, you also have the requirement to bring this field into Fiori UIs, APIs, or analytical applications using the Custom Fields Fiori app.
2. You have specific requirements regarding the data element of your custom field, which is not supported when using the Custom Fields Fiori app:
   1. Either you need a specific conversion exit on that field or
   2. You need to use a specific check table, which is then used in SAP GUI transactions, for example

Please note that whenever possible, you should use standard custom fields instead of ABAP Managed Fields. Using ABAP Managed Fields significantly increases complexity, especially in software logistics. We will dive into the details of this issue later in this blog post.

Please also note that in case you utilize ABAP Managed Fields based on your manually created append fields these append fields are taken as is...there names are not changed and they are not duplicated in any way.

How do you enable an append field for the Custom Fields app?

Let’s assume you have an old append field ZZVOUCHER_CODE at hand, which has been added to the extension include structure SDSALESDOC_INCL_EEW_PS. This structure is included in database table VBAK.
You need to preserve the data of this field because the effort of migrating data and custom code to a new custom field with a different field name is too high.
First, make sure that you are in your key user development system and client. In this client, the Adaptation Transport Organizer must be set up. Second, check that you’re using the correct apps for transport handling (also refer to note 2660797) to assure a correct setup for custom field creation. Further details regarding the setup are addressed in the blog post Key User Custom Fields in S/4HANA Cloud Private Edition and On-Premise: Dos and Don’ts.

If everything is ready, open transaction SCFD_EUI. You will see the following selection screen:

Transaction SCFD_EUI: selection screen

In this selection screen, you can filter for database table and field name. An example: enter “VBAK” as database table name and “ZZ*” as database field name. If there are too many fields, you could also enter the entire field name ZZVOUCHER_CODE.
Please note that you get built-in documentation describing the details of transaction SCFD_EUI by clicking the Information button on the top of the transaction.

Transaction SCFD_EUI: resulting list of fields

Now, you see the list of fields that apply to the selection criteria, including your field ZZVOUCHER_CODE.
When you select ZZVOUCHER_CODE, a details section below the field list displays additional information for the selected field. Looking at the Field Status column, you see that the content is different for the listed fields. Whereas the status for field ZZVOUCHER_CODE is Can be Enabled, there are also other values possible. All of these are documented and explained here: Enabling Custom Database Fields for Usage in SAP Fiori Applications.

The next step is to click Enable in the button bar on the top. Now, the pop-up Enable Fields for Use in App Custom Fields and Logic is displayed:

Transaction SCFD_EUI: Enabling an append field

The pop-up allows you to specify the Custom Field ID and other semantics of the custom field (in the screenshot, the value help for the Semantic Type has been selected). Since this needs to be a new custom field and not link to an existing one, we leave the default Enabling Type unchanged.
Note that in transaction SCFD_EUI you can’t influence the prefix of the Custom Field ID, as this must be the customer namespace you configured in the Adaptation Transport Organizer settings. This setting is done via the Prefix field in transaction S_ATO_SETUP.

The field ZZVOUCHER_CODE is character-like and should have a value help assigned. Therefore, we need to change the Semantic Type from the default Text to Code List. Please note that possible semantic types depend on the technical type. In this case, it could also be Email Address, Phone Number or Web Address.

As soon as you select Code List as semantic type, the Value Help View field becomes editable. You can either enter the name of an already existing CDS view or enter the name of new CDS view and select Generate right next to the Value Help View field. Clicking Generate will show a pop-up containing templates for both the CDS Code view and the CDS Text view. You can create the two respective views using ABAP development tools for Eclipse (hereafter abbreviated as ADT), copy the templates, and finally, replace the contained placeholders.

Note that both CDS Code view and  CDS Text view must strictly have the format given within the templates. Also, the CDS Text view must be language-specific. However, the template includes a comment with instructions for alternative actions.

In our case, both CDS views have been prepared in advance: the CDS view ZZVOUCHER_CODE_V as code view and the CDS view ZZVOUCHER_CODE_T as text view. The final data source of these CDS views is the manually created database table ZZD_VOUCHER_CODE. All three artifacts are shown below:

CDS Code View ZZVOUCHER_CODE_V:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Voucher Code'
@AbapCatalog.sqlViewName: 'ZZVOUCHER_CV'
@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 ZZVOUCHER_CODE_V
  as select from ZZD_VOUCHER_CODE
  association [0..*] to ZZVOUCHER_CODE_T as _Text
    on $projection.Code = _Text.Code
{
@ObjectModel.text.association: '_Text'
@search.defaultSearchElement: true
key cast( code as ZZVOUCHER_CODE ) as Code,
@ObjectModel.association.type: [#TO_COMPOSITION_CHILD]
_Text
}

 CDS Text View ZZVOUCHER_CODE_T:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Voucher Code'
@AbapCatalog.sqlViewName: 'ZZVOUCHER_CT'
@search.searchable
@ObjectModel.usageType.serviceQuality: #A
@ObjectModel.usageType.sizeCategory: #S
@ObjectModel.usageType.dataClass: #CUSTOMIZING
@ObjectModel.dataCategory: #TEXT
@ObjectModel.representativeKey: 'Code'

define view ZZVOUCHER_CODE_T
as select from ZZD_VOUCHER_CODE
association [0..*] to ZZVOUCHER_CODE_V 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( code as ZZVOUCHER_CODE ) as Code,
@Semantics.language: true
@ObjectModel.foreignKey.association: '_Language'
//Use this for language-dependent descriptions:
//key <Name of Language Field in Data Source> as Language,
//Use this for language-independent descriptions:
key $session.system_language as Language,
@search.defaultSearchElement: true
@Semantics.text: true
Description as Description,
@ObjectModel.association.type: [#TO_COMPOSITION_ROOT, #TO_COMPOSITION_PARENT]
_Code,
_Language
}

Database Table ZZD_VOUCHER_CODE (base table of the views):

@EndUserText.label : 'Voucher Code'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zzd_voucher_code {

  key client  : mandt not null;
  key code    : zzvoucher_code not null;
  description : cfd_field_code_description;

}

After creating these CDS views, enter the name of the Code CDS view and click OK. This action carries out the enabling process. Make sure to have note 3355846 installed to avoid timeouts while enabling.

Upon confirmation of the dialog (pressing F8 or OK), you’re prompted to enter a package and a transport request for the objects, which are being created by the system to enable your field for the SAP Fiori app Custom Fields.

 Transaction SCFD_EUI: package selection

After the enabling process is finished, you can see all artifacts generated during the enabling process using the support transaction SCFD_FIELDVIEWER. There, double-click your new custom field ZZ1_VOUCHER_CODE in the list on the left side of the screen and then select the Enhancement tab on the right side.

Let’s assume that we also want to expose our field ZZ1_VOUCHER_CODE in the Fiori app Manage Sales Orders - Version 2.
Open the app and navigate to the details of one of the sales orders. Then, switch into the Adapt UI mode. Select the section (the Basic Data – Order Data section) where you’d like to add your ZZ1_VOUCHER_CODE field. Then, right-click and select the “+ Add: Field” option. Within the pop-up, select the “+” button in the upper right corner. As soon as you’ve done that, the Custom Fields app will be started with the context of the app to be extended.

In the Custom Fields app, search for your Voucher Code field and navigate to its details. Since the SAP S/4HANA 2023 release, you’ll get a pop-up asking if you want to enable the field for the correct service. In older releases, you need to click on the User Interfaces tab and within that, select the Services tab. Now, look for the OData entity with the description “Manage Sales Orders - Version 2” and enable the entry for this OData service or OData entity by clicking Enable Usage. Then, click Save and Publish to generate the custom field.

 Enable field ZZ1_VOUCHER_CODE for Fiori App “Manage Sales Orders – Version 2”

As soon as this is done, reload the Fiori App Manage Sales Orders – Version 2 and then redo the steps you did before. This time, when you click the “+” button, you’ll see the Voucher Code field in the list of available fields. Select the Voucher Code field and click Ok.

In case there are too many fields displayed, you can enter the field name in the search field at the beginning of the dialog.

 

Add “Voucher Code” field to Fiori App “Manage Sales Orders – Version 2” using Adapt UI

Activate this UI change by selecting the magic wand icon on the upper left corner.
Leave the Adapt UI mode and switch into Edit mode. Now, you’ll see the Voucher Code field on the UI, rendered as field with value help.

 Using the “Voucher Code” in the Fiori App “Manage Sales Orders – Version 2”

Are ABAP Managed Fields lifecycle-stable, and do they follow the clean core principles? These questions are addressed in the blog post Key User Custom Fields in S/4HANA Cloud Private Edition and On-Premise: Dos and Don’ts.

Please note that the translations for texts like the labels and tooltips of ABAP Managed Fields can not be maintained using the key user custom fields Fiori app. They have to be maintained by providing translations for the respective manually created data elements. This behavior is different for key user custom fields which are no ABAP Managed Fields. For these the translations for texts can be maintained directly in the key user custom field app.

Please note that in case it turns out that you want to change the data element for a key user custom field you created using SCFD_EUI in a safe and simple way please have a look at note 3701379 - Custom Fields: Report to change the data element for fields created with SCFD_EUI.

Now, you are done! Congratulations!
With this, you’re now equipped to

• convert a manually created append field to a custom field using transaction SCFD_EUI
• know in which cases this is the right thing to do.

Please note that this blog has been elaborated by a team of experts. I want to thank Yasmina van Rooij (YasminavanRooij), Daniel Wachs (DanielWachs), and Georg Wilhelm (georg_wilhelm) for their extremely helpful contributions.

Feedback, Comments, or Questions:

You’re cordially invited to provide feedback, comments, or questions in the comments section below. Please follow our profiles to get updates when we publish more posts on these topics.
Feel invited to post and answer questions here (https://answers.sap.com/tags/270c4f37-c335-46e1-bfad-a256637d5e26) and read other posts on the topic (https://blogs.sap.com/tags/270c4f37-c335-46e1-bfad-a256637d5e26/).

Other related blog posts:

1. Key User Custom Fields in S/4HANA Cloud Private Edition and On-Premise: Dos and Don’ts
2. How to implement a custom field of type “Code List based on CDS view” with a developer extensibility... 
3. How to implement a custom entity in the ABAP RESTful Programming Model using remote function modules    
4. How to configure the value help as a context-dependent value help 
5. How to configure intent-based navigation on a key user custom field of type “Code List based on CDS ...    
   and in this case, how to easily find the fitting semantic object and semantic object parameter: Custom field type “Code list based on CDS view”: Finding/defining the right value help view and the ... 
6. Custom Fields in S/4HANA: How to control field properties like mandatory, read-only, and visibility 
7. Key User Custom Fields in SAP S/4HANA SAP GUI UIs: How to control field properties (mandatory,...) 
8. Key User Custom Fields in Fiori UIs based on SEGW OData Services: How to control field properties 
9. Key User Custom Fields in Fiori UIs based on OData Services exposed with Service Binding 
10. Custom fields in S/4HANA: Key User versus Developer Extensibility 
11. SAP Screen Personas: How to position key user custom fields exactly where you want them to be