The extensibility framework delivered with S/4HANA Cloud supports multiple extension approaches for adapting applications to various business needs or requirements. It covers –
· Key user extensibility, which is supported by in-built solution capabilities (In-app or managed).
· Side-by-side extensibility, which uses SAP Cloud Platform for extensions.
The approach you choose may differ based on the type of changes you wish to make to the application.
The focus of this blog is to explore some of the important features offered with in-app extensibility for key users. This functionality allows the key users with limited or no coding skills to create the required custom fields on the transactional UI and reports with a specific business context.
For business situations where certain custom logic is required; managed extensibility can be used. However, it requires certain coding skills to implement the custom logic.
Within the S/4HANA Cloud Sales, one of the apps extensively used by the enterprises is the ‘Track Sales Order’ app
(Business Catalog: Sales Order Processing & Business Role: Internal Sales Representative).
This app allows to monitor the status of a sales order with respect to its fulfillment. That is, you can check whether a sales order has been shipped, invoiced, or even if a journal entry for a specific transaction has been posted and cleared.
There could be few instances where enterprises may need to view some additional information in this app, which is not supported in standard solution and is critical for making valuable decisions. To achieve this, key users can leverage the in-app extensibility to add new custom fields and implement the required custom logic applicable for specific business contexts.
The use case mentioned below, demonstrates how to create new custom fields in the Track Sales order report and the associated business transactions (sales order and delivery). Additionally, this example involves custom logic to achieve the desired result which is implemented through managed extensibility. Details of implementing the custom logic will be published in another blog.
Business need – to display the field ‘Carrier Reference Number’ in the ‘Track Sales Order’ Report. This reference number is manually entered in the delivery document header during shipment processing.
Background – Many companies rely on multiple transportation carriers for making timely delivery to their customers. Each shipment handled by a transporter or a carrier is linked to a reference number (carrier reference number), which is entered manually in the delivery document during shipment processing. The reference number provides essential information about the carrier responsible for delivery and allows to track the delivery status of a shipment.
Additionally, enterprises would be interested to know the volumes handled by each transport carrier for a specific period to decide on the business continuity with those carriers. Hence, the ask is to display the carrier reference number in the “Track Sales order” app.
Companies usually engage several selection parameters such as service efficiency, delivery urgency, geographic location etc. to short list and employ a carrier for delivery. Additionally, few companies may also employ a tendering technique to fulfil the delivery execution.
§ The track sales order app displays information from CDS views/UI based on sales order and the field ‘Carrier Reference Number’ is not available as a standard field in sales order or delivery document to make it accessible and display in ‘Track Sales Order’ app.
§ Further, in a typical business scenario, the carrier reference number is not available during sales order creation and is assigned to deliveries within the close-proximity of shipment execution. This is entered in the delivery document by the warehouse or the logistics execution team.
§ To address this business requirement, a new custom field ‘Carrier Reference Number’ is created in sales order and delivery document at header level.
§ The reference number manually entered by business teams in the delivery document can be updated back into sales order using custom logic (managed extensibility).
Let’s look at the solution details of this example below –
Step 1: Create custom fields ‘Carrier Reference Number’ in Sales order, delivery and track sales order app.
Access the app ‘Custom Fields and Logic’ under Extensibility. This app can be used to create your own fields and implementations to customize applications and their UIs, reports, email templates, and form templates.
Create custom field “carrier reference number” with business context: Sales – Sales Document to make it available in sales order and delivery (as shown below). Appropriate label can be chosen for this field as per the business requirement.
Within the UIs and reports tab in the app, you can select the transactions for which you would like to make your field available and decide whether the content of your field should be included in free-text searches. In this case, the custom field is enabled for “sales order” and “track sales orders”.
Enabling the relevant business scenarios allows to automatically create the custom field in the subsequent document i.e. delivery document in this case. Based on the business scenario selected, carrier reference number is automatically created for business context shipping: delivery (as shown below).
Save the newly created custom fields and publish them. Once published, the new custom fields will reflect in the Sales orders / Delivery (under customs tab, header level) and Track Sales order app.
Step 2: Custom logic to update carrier reference number from delivery to sales order (managed extensibility)
Access the app ‘Custom Fields and Logic’ under Extensibility to create custom logic for the business requirement mentioned earlier.
o Select the relevant business context where the BAdi needs to be triggered i.e. delivery document in this case (Shipping: Delivery) and BAdi description: Modify Standard and custom fields for delivery header.
o This Business Add-In (BAdI) is used in the LE-SHP component. You can use this BAdI to modify standard and custom fields on header and item level. This BAdI can be called shortly before saving the delivery document.
o An ODATA API https://api.sap.com/api/API_SALES_ORDER_SRV/resource should be called within the Badi mentioned above to update the carrier reference number from delivery to sales order. This service will use the patch operation to update carrier reference number in the sales order header.
To demonstrate the example for this blog, I have manually updated the carrier reference number in the delivery and sales order documents. With the implementation of above mentioned BAdi, the update of this field from delivery to sales order will happen automatically. Subsequently, the carrier reference number will appear in the ‘Track Sales Order’ app as shown below.
In general, key users in an organization hold vital knowledge on the business processes and their corresponding IT applications. This in-depth understanding helps them to make decisions on how IT applications can be adapted to bring more value to ever changing business needs.
The In-app extensibility is quite different from traditional methods of extension as it does not involve any source code modifications and do not have any impact on the SAP delivered innovations or quarterly upgrades. The built-in Fiori based extensibility tools are intuitive and easy to navigate and allow key users to enhance an applications appearance and business logic without solely relying on IT developers in most cases. This new extensibility approach allows to provide comprehensive business solutions tailored for organizational needs.