logo

Are you need IT Support Engineer? Free Consultant

End-to-End Business Process Extensibility for Customer Projects in SAP S/4HANA Cloud Public Edition

  • By Sanjay
  • 10/08/2026
  • 89 Views



End-to-end business process extensibility in SAP S/4HANA Cloud Public Edition empowers organizations to enhance standard business processes with remarkable flexibility – while keeping applications simple and development clean. This is enabled by both the extensive set of process extensibility contexts and the modern Financials architecture based on the Universal Journal.

Professional services organizations need flexible time tracking with additional attributes that can also be used for reporting. Invoicing also requires a high degree of flexibility.

In this blog, we'll explore how these extensibility capabilities enable powerful business process extensions through practical examples based on the Professional Services scenario.

Enjoy!

Stefan Walz and Andreas Hammerschmidt

 

Introduction

There are multiple ways of extensibility in SAP S/4HANA Cloud Public Edition; please refer to this overview on the SAP Help Portal. We will focus in this blog on key user extensibility by adding custom fields. This is in SAP S/4HANA Cloud Public Edition already very powerful as it allows a simple and fast way to adopt applications and their UIs based on customer’s need. However, the underlying business scenarios are even more powerful as they allow to forward the custom fields and its values to subsequent documents and objects. In that way, a custom field that is filled on the project or sales order can flow the complete end-to-end process until the invoice printout.

In total, there are three main end-to-end extensibility business scenarios, along with some adjacent ones:

1. Custom fields are transferred from the Customer Project/Sales Order to the Billing Document. They can be used to print additional invoice information, such as a “service period”, or to influence the invoice, for example its layout or form template. This scenario has no direct impact on journal entries in Financials.

The next two end-to-end extensibility scenarios involve Financials. In both cases, the custom field is entered in each service confirmation – time or expense – and carried through the entire process. Coding block extensibility enables this integrated flow from confirmation to Financials.

2. Custom fields are transferred at the CO line-item level for each service confirmation. For example, a consultant can enter a ticket number during time recording and pass it through Financials and the Universal Journal to billing preparation and invoice printout. 

3. Custom fields are transferred from the CO line-item level to the billing item level and can also be marked as pricing-relevant. For example, work locations such as on-site or off-site or overtime can be configured with different maintained prices.
This blog gives an overview of these three relevant business scenarios of custom fields for Customer Projects in SAP S/4HANA Cloud Public Edition. The affected scope items are J11, J12, J13, 4E9, and J14. Please refer to this blog for details on Project Billing. In addition, the three options for key user extensibility in Finance are also explained in detail.

 

Scenario 1: Customer Project / Sales Order to Billing Document

Figure 1: Process Extensibility From Customer Project/Sales Order To The Billing Document

The first and most commonly used scenario automatically transfers sales order header and/or item fields to Project Billing and to the header and/or item of the Billing Document Request. Subsequent billing documents, such as the Preliminary Billing Document and Billing Document, retain the extensibility field values.

The relevant business scenarios are:

  • Sales Order Header to Billing Document Header for Project Billing
  • Sales Order Header to Billing Document Item for Project Billing
  • Sales Order Item to Billing Document Item for Project Billing
  • Sales Order Item to Billing Document Header for Project Billing

Once a business scenario is enabled within one business context, the other relevant business contexts are activated automatically. The relevant business contexts are:

  • Sales: Sales Document
  • Sales: Sales Document Item
  • Project Billing Element
  • Sales: Billing Document
  • Sales: Billing Document Item

Activating multiple business scenarios for a single extensibility field is not intended. To use all four business scenarios, for example, you need to create four separate custom fields and assign each field to the corresponding context and scenario. If multiple business scenarios are still activated, sales order item fields usually take precedence over header fields. For more information, see SAP Help Portal.

Be aware that enabling these scenarios can affect split criteria in billing. For example, if different custom field values at sales order item level are transferred to the billing document header, multiple billing documents may be created. For more information, see SAP Help Portal.

The business scenarios listed above apply not only to Project Billing (scope item 4E9), but also to Intercompany Billing (scope items 16T and 4AN). For example, you can transfer custom fields from the Intercompany Sales Order SO03 to the Intercompany Billing Document CI02.

Typical business examples, in which these scenarios are used:

  • Different content and layout definitions for the output form templates, e.g. some projects require a detailed invoice output, whilst for others a high-level aggregation is sufficient.
  • Tax Exempt for certain services provided such as insolvency consulting
  • Service Period that is printed on the invoice

Additionally, further business scenarios might be required to enable the field in adjacent processes. Most common ones are for the billing document are:

  • Billing Document Request Header Level to Billing Due List (e.g. filter and combine multiple billable SD documents in the Create Billing Documents app)
  • Billing Document to Journal Entry on Item Level
  • Billing Document to Account Determination on Header Level
  • Billing Document to Account Determination on Item Level
  • Billing Document to Pricing Communication on Item Level
  • Billing Document to Pricing Communication on Header Level

System example for determination of different form templates

This business scenario lets users define, during project/sales order planning, how the invoice printout sent to the customer should appear. For example, they can choose whether to include no itemized time and expense details, time postings only or expense postings only. These options can be configured flexibly by the key user and are used for the determination of different form templates.

The application “Custom Fields” (F1481) is used to create a new extensibility field for Business Context “Sales: Sales Document” (SD_SALESDOC). The type code list is used to define the different options.

Figure 2: Custom Field For Defining Different Print Details

In a next step, the extensibility field is enabled for the “Plan Customer Projects” application.

Figure 3: Enablement Of Extensibility Field In The &Amp;Ldquo;Plan Customer Projects&Amp;Rdquo; Application

Once the Business Scenario “Sales Order Header to Billing Document Header for Project Billing” is enabled and saved, other Business Contexts are enabled automatically depending on the enabled Business Scenario. Here, it is the Business Contexts “Project Billing Element” and “Sales: Billing Document”.

Figure 4: Business Contexts For The Extensibility Field Print Details

The Business Context “Project Billing Element” is used to enable the custom field for the “Manage Project Billing” application (Project Billing Element SB for UI), and the Business Context “Sales: Billing Document” is used to enable the custom field for the “Manage Billing Document Requests” and “Manage Billing Documents” application. Additionally, for the latter, the “Billing Document Output Management: Parameter Determination” is enabled in the User Interfaces tab. If the output form template itself needs to display the custom field, you can also enable it for the necessary form templates.

Once the custom field is published, it can be added by key users via the “Adapt UI” functionality (part of the user actions menu when clicking on the user icon in the upper right hand corner of the FIORI launchpad) in the “Plan Customer Projects” application. For more information, see SAP Help Portal.

Additionally, the custom field can be added and used in the “Output Parameter Determination” app (OPD) as new condition column. Depending on the value of the custom “Print Details” field, different Form Templates can be determined during (preliminary) billing document creation. For more information, see SAP Help Portal.

Figure 5: Custom Field &Amp;Ldquo;Print Details&Amp;Rdquo; In Output Parameter Determination

In this example, we select option 1 for no details.

Figure 6: Custom Field &Amp;Ldquo;Print Details&Amp;Rdquo; Added To Plan Customer Projects App

In subsequent applications, end users can add the custom field using the gear wheel settings button. Note that the Manage Project Billing application currently has one restriction when extended fields are updated; see the details here.

Figure 7: Custom Field For Print Details In Manage Project Billing Application

Figure 8: Custom Field For Print Details In Manage Billing Document Requests Application

Figure 9: Custom Field For Print Details In Manage Billing Documents Application

Custom fields are not only manually filled by an end user, but are often also determined and filled automatically via a custom logic. In this end-to-end process across sales and billing, the Custom Data Transfer for Billing Process Documents BAdI (SD_BIL_DATA_TRANSFER) is usually used. More information on SAP Help Portal.

 

Scenario 2: Coding Block extensibility to Itemized List on Invoice Printout

The second process extensibility scenario starts differently – already with the confirmation. It is relevant for T&E and Usage Based contracts only. There are additional information provided in the time or expense journal entry, assigned to the project, which could even impact pricing or only provide additional information for the billing document respectively itemized list – like in our example. For this we use coding block extensibility.

A common business example for this type of custom field is adding ticket details or similar information by the consultant during time recording so that they can later appear on the customer invoice.

Figure 10: Process Extensibility From Source Confirmation (Time Or Expense) To Coding Block And Itemized List

The relevant Business Contexts are:

  • HCM: Timesheet Fields
  • Accounting: Coding Block
  • Procurement: Service Entry Sheet Item (external workforce)

The relevant Business Scenarios are:

  • Project Based Services: transfer from Time recording to Invoice printout (internal employees)
  • Project Based Services: transfer from Time recording to Service Entry Sheet (external workforce)
  • Project Based Services: transfer from Service Entry Sheet to Goods Reciept (external workforce)

As in the first scenario, activating a business scenario for a custom field automatically enables the other relevant business contexts.

System example: Printing ticket details on customer invoice printout (internal employees)

In the following system example, the custom field “Ticket Details” was created as numerical text with 10 characters, and the business scenario for internal employees (Project Based Services: transfer from Time recording to Invoice printout) was activated.

The following user interfaces of the business contexts were enabled:

  • HCM: Timesheet Fields: Manage my timesheet Time Entry Details
  • Accounting: Coding Block: Project Billing Element Entry Flow, Project Billing Request SB for UI, Project Margin, Display Line Items in General Ledger, Direct Activity Allocation (if required for activity allocation postings)

Additionally, the Professional Services form templates were enabled in the Coding Block Business Context.

Please ensure that Extensibility Mode is activated in the timesheet data entry profile (configuration activity 102509). This allows key users to add the custom field to the Manage My Timesheet application using Adapt UI via the “Adapt UI” functionality (part of the user actions menu when clicking on the user icon in the upper right hand corner of the FIORI launchpad).

Figure 11: Manage My Timesheet App With Custom Field &Amp;Ldquo;Ticket Details&Amp;Rdquo;

After the time record is approved and transferred to Financials, it becomes available in the Universal Journal (ACDOCA) and in related financial line-item reports, such as “Project Financial Booklet – Professional Services” or “Display Line Items in General Ledger”.

Figure 12: Display Line Items In General Ledger App With Custom Field &Amp;Ldquo;Ticket Details&Amp;Rdquo;

In the Prepare Billing UI of the Manage Project Billing application, you can add the custom field through the settings.

Figure 13: Custom Field &Amp;Ldquo;Ticket Details&Amp;Rdquo; In The Prepare Billing Ui Of The Manage Project Billing Application

After the Billing Document Request and Billing Document are created, the custom field is included in the XML and can be added to the PDF output that is sent to the end client.

Figure 14: Custom Field &Amp;Ldquo;Ticket Details&Amp;Rdquo; In The Xml Of The Billing Document Output

System example: Printing ticket details on customer invoice printout (external workforce)

When the same system example should also apply to contingent workers, the other two business scenarios (Project Based Services: transfer from Time recording to Service Entry Sheet, Project Based Services: transfer from Service Entry Sheet to Goods Reciept) need to be activated.

In addition, the following user interfaces of the business contexts were enabled:

  • HCM: Timesheet Fields: Service Entry Sheet: Time Recording
  • Procurement: Service Entry Sheet Item: Service Entry Sheet Extensibility Model (which enables multiple required CDS Views automatically)

Once the contingent worker creates a time record with the “Ticket Details” custom field, it is automatically forwarded to the Service Entry Sheet item:

Figure 15: Service Entry Sheet With Custom Field &Amp;Ldquo;Ticket Details&Amp;Rdquo; On Item Level

The subsequent flow to accounting and project billing remains the same:

Figure 16: Display Line Items In General Ledger App With Custom Field &Amp;Ldquo;Ticket Details&Amp;Rdquo; In The Contingent Worker Scenario

Figure 17: Custom Field &Amp;Ldquo;Ticket Details&Amp;Rdquo; In Project Billing In The Contingent Worker Scenario With Procurement On Project

This flow supports purchase orders assigned to either projects or cost centers. If procurement is performed on a cost center, both the CO activity allocation and goods receipt line items contain the custom field in the Universal Journal/ACDOCA. For more details about these processes, see this blog.

Further considerations for expense confirmations

Extensibility fields can also flow from an expense confirmation to the coding block and further. Depending on the cost posting process/application, different capabilities need to be used. Two examples for manual supplier invoice and Concur are mentioned below.

Create Supplier Invoice

With the activation of the “Manage Supplier Invoice” user interface in the “Accounting: Coding Block” business context, the custom field gets available in the G/L Account Items section of the Create Supplier Invoice application.

Figure 18: Custom Field &Amp;Ldquo;Ticket Details&Amp;Rdquo; In The Create Supplier Invoice Application

The subsequent flow to accounting and project billing remains the same.

Concur

You can transfer Concur-specific extensibility information to S/4HANA Cloud by using the predefined custom fields available in the Concur data model and maintaining the required values in those fields within the expense report.

Starting with release 2608, SAP's Concur-specific substitution rules were enhanced to support Coding Block extension fields, and the Manage Concur Substitution Rules application (App ID: F6846) can map Concur custom fields to S/4HANA Cloud extensibility fields such as Journal Entry Header and Journal Entry Item/Coding Block fields.

While Concur does not support fully dynamic “extensibility on the fly” or generic coding-block extensibility across all applications, the combination of Concur custom fields and substitution/derivation rules provides a supported way to bring extensibility data from Concur expense recording into S/4HANA Cloud Accounting.

More information can be found in this blog.

Scenario 3: Journal Entry to Billing Document Item

Figure 19: Process Extensibility From Source Confirmation (Time Or Expense) To Billing Document Item

Scenario 3 starts similarly to Scenario 2, but changes significantly when custom CO line-item fields are transferred not only to the itemized list, but also to the item level of subsequent billing process documents, such as the Billing Document Request. Because these item fields can also be passed on to pricing, they can influence aggregation between Project Billing and Sales Billing.

In the Figure 19 above, the two T001 Junior Consultant postings share the same attributes, such as WBS and work item, except for custom fields EXT1 and EXT2. For example, if on-site and remote work have different maintained prices, the postings create two separate items in the Billing Document Request instead of one aggregated item.

Typical business examples for this type of custom field include:

  • Differentiating between remote and on-site work with different pricing rates.
  • Splitting intercompany billing invoices based on the work location.
  • Creating separate invoices based on specific attributes, such as the employee.

This blog covers these examples in detail.

The relevant Business Contexts are:

  • Accounting: Coding Block
  • HCM: Timesheet Fields
  • Procurement: Service Entry Sheet Item (external workforce)
  • Entries for Project Billing Element
  • Items for Project Billing Request
  • Sales: Billing Document Item
  • Sales: Pricing Communication Item (if custom field is used in pricing)

The relevant Business Scenarios are:

  • Coding Block to Billing Document Item for Project Billing
  • Journal Entry Item to Billing Document Item for Project Billing
  • Billing Document to Pricing Communication on Item Level (if custom field is used in pricing)
  • Billing Document Item to Coding Block (if the custom field is required on the billed revenue journal entry items)
  • Project Based Services: transfer from Time recording to Service Entry Sheet (external workforce)

Project Based Services: transfer from Service Entry Sheet to Goods Reciept (external workforce)

System example: Custom overtime category for contingent workers (external workforce)

In the professional services industry, effective tracking and management of time confirmations are important – for both employees and subcontractors. Frequently, there's a necessity to enhance these confirmations by incorporating additional attributes. This is particularly crucial in scenarios involving remote versus on-site work and overtime, as it not only influences workforce and financial reporting but also can impact pricing.

For overtime there is a standard field available, overtime category. But this cannot be activated in the S4H_EXT timesheet data entry profile for contingent workers (configuration activity 102509) – as described in this blog. As of release CE 2608, the overtime category is not available in purchasing processes, including purchase orders, service entry sheets, goods receipts, and supplier invoices.

However, the extensibility framework makes it possible to create a custom overtime category with nearly the same functionality as the standard one. External workers can select different overtime categories during time recording, and these values are carried forward to subsequent procurement, financial, and billing processes. The custom field can also be made available for pricing, enabling different prices or surcharges based on the overtime category. Unlike the standard overtime category, extensibility-based overtime cannot influence the cost rate because the cost rate table is not extensibility-enabled.

In the following example, the custom field “Overtime Category 2” is shown in the end-to-end process for contingent worker confirmation – including impact on pricing by the custom condition type “ZOV2 Overtime 2”.

Figure 20: Custom Pricing Procedure With Custom Condition Type Zov2 And Different Account Key

Figure 21: Different Prices Defined For Custom Field &Amp;Ldquo;Overtime Category 2&Amp;Rdquo;. Ov1/Regular Overtime Has A +10 % Surcharge

Figure 22: Time Recording Of Contingent Worker With Ov1/Regular Overtime For Custom Field &Amp;Ldquo;Overtime Category 2&Amp;Rdquo;

The following figure shows the journal entries generated from the subcontractor’s time confirmation (procured on cost center). The first reference document represents the activity allocation, which debits the project and credits the cost center, and the matching revenue recognition document. The second reference document is created from the service entry sheet respectively goods receipt, for which the GR/IR account is credited, and the cost center is debited with expenses. The subcontractor’s employment number is stored in all journal entry items. The cost analysis resource, derived for the postings on the project, determines that an external resource confirmed the time. The reference to the purchase order is only available in the Goods receipt posting on the cost center.

Please note: The overtime category is updated in the activity allocation and service receipt posting, but it is not transferred to the revenue recognition journal entry items. With release 2608, for time and expense contracts using revenue recognition key SPTMWP, only the hours, (bill-) product, employee, and cost analysis resource are transferred to revenue recognition journal entry items. Therefore, the standard overtime category is not included in EBRR postings.

Figure 23: The Custom Field &Amp;Ldquo;Overtime Category 2&Amp;Rdquo; With Ov1/Regular Overtime In Financials

The following figure shows all confirmations, including several with other overtime categories and two items without an overtime category.

Figure 24: The Custom Field &Amp;Ldquo;Overtime Category 2&Amp;Rdquo; With Ov1/Regular Overtime In Project Billing

When all items are billed, the two time recordings without an overtime category are aggregated into a single billing document item. For records with different overtime categories, the custom field acts as a pricing-relevant attribute, resulting in multiple billing document items.

Figure 25: The Custom Field &Amp;Ldquo;Overtime Category 2&Amp;Rdquo; With Ov1/Regular Overtime In The Billing Document Item

The overtime categories are also derived in the billed revenue journal entry items. By adding a dedicated condition type with its own revenue G/L account for the overtime surcharge, you can analyze the additional revenue generated from overtime.

Figure 26: The Custom Field &Amp;Ldquo;Overtime Category 2&Amp;Rdquo; With Ov1/Regular Overtime In The Billed Revenue Lines. The Different Account Keys Lead To Separate Accounts Being Determined

 

Key User Extensibility in Financials

There are three options to enhance the Universal Journal and thus your reporting structure with additional fields, which are identified by choosing a business context in the app Custom Fields.

Coding block extensibility

The Coding block is integrated into many business transactions. For example: activity allocation, expense reposting, Post General Journal entry, supplier invoice, goods issue and purchase order. If you add a field in coding block, it is available almost everywhere in the system. Particularly with the fact, that there are extensibility context for time sheet and billing and a solution to transfer extensibility fields from CONCUR. Thus, coding block extensibility is already a process extensibility. You use this, if you need to enter fields manually for some transactions, like app Post General Journal Entry or Activity Allocation.

Note: these business transactions with coding block post costs/expenses. Thus, coding block extensibility works only for P&L, no impact on balance sheet.

Restriction: Only CHAR and NUMC data types allowed (see SAP Note 130174).

Journal entry extensibility

You use this if you can derive the field or it is provided from preceding applications. There can be a process extensibility in place, for example in our scenario 2, in which we defined an extensibility field in a preceding application.

You can also create custom fields without restrictions on data types.

Market segment extensibility

Here you can enhance the market segment by adding an additional field. You can enter the field value manually in the account assignment view for profitability or you can derive it. The advantage is that you can use the field in subsequent transactions like top-down allocation. And you can update the fields with realignment, if you have defined a derivation logic.

 

For all three methods you can define a derivation logic with the app Manage Substitution and Validation Rules and the respective Business Context “Coding Block”, “Journal Entry” and “Market Segment”.

Added key user fields are part of the Universal Journal/ACDOCA and can be selected with the existing CDS view and included in the standard reports.

The architecture of the Universal Journal simplifies extensibility in Financials. As reporting works on single line items – and no persisted aggregates are needed anymore – and all financial applications are included in the Universal Journal, an extensibility field needs to be added only once. It is available in all financial applications and their reports.

Figure 27: Market Segment Extensibility In Universal Journal

For example, an extensibility field in the project master can be used via derivation logic to derive another extensibility field in Finance, such as a journal entry extensibility field.





Source link

Leave a Reply

Your email address will not be published. Required fields are marked *

Chat with us on WhatsApp!