logo

Are you need IT Support Engineer? Free Consultant

What's New in Sales in SAP S/4HANA Cloud Public Edition 2608

  • By Sanjay
  • 21/09/2026
  • 73 Views



This blog shares highlights on Service in SAP S/4HANA Cloud Public Edition 2608 release.

Watch my video to get a glimpse of the new features:

 

 

Expansion of Address Management Capabilities in the SAP Fiori App “Manage Sales Orders – Version 2”

The partner address popup window in the Manage Sales Orders – Version 2 Fiori app has been redesigned with a new layout and an expanded field catalog. Users can access the popup from the partners table at both header and item level, when changing the ship-to party, or when entering a one-time customer. New fields include title, name 3 and name 4 (visible in edit mode only), communication channels such as phone, email, and fax, and street prefix and suffix fields. The address column and address details view now reflect these additional fields where relevant, and “show more” and “show less” toggle options allow users to control how much information is displayed at once.

Dequanxu_1-1789386185755.Png

This enhancement reduces the need to navigate across multiple screens when managing business partner address data, bringing structured and comprehensive partner information directly into the sales order workflow. The consistent field catalog, meaningful section headlines, and flexible display options give users efficient access to complete address and communication data, improving accuracy and reducing the risk of errors in partner data management.

 

Intercompany Pro Forma Invoice for Export Declaration in Advanced Intercompany Sales

In advanced intercompany sales scenarios, goods are frequently shipped across national borders before a commercial invoice is issued — a situation where customs authorities require a valid document as evidence of the cost and value of the exported goods. To address this compliance requirement, SAP has introduced billing document type IVF8, a pro forma equivalent of billing type F8 designed specifically for intercompany processes. The document is created with reference to the outbound delivery and can be generated multiple times per delivery as needed by export and customs departments. Importantly, IVF8 is not an accounting document — it serves exclusively as evidence for export declaration, and a regular accounting document must still be created at the conclusion of the billing process. The feature is tightly integrated with SAP Global Trade Services (GTS), enabling direct creation of customs declarations based on the pro forma invoice, and is available via SAP Fiori billing apps in addition to the standard billing transaction.

Dequanxu_1-1788267035465.Png

 

This capability significantly improves compliance with export regulations by eliminating manual preparation of customs documentation and replacing it with a standardised, system-generated document. The automation of customs declaration creation through SAP GTS reduces manual data entry, lowers the risk of compliance gaps, and improves visibility and auditability across the entire cross-border intercompany billing process. Starting with release 2608, this feature becomes generally available to all customers without requiring a feature toggle activation or an explicit enablement request — a notable change from earlier releases where customers had to separately request activation of this capability.

 

Including Information as Attachments in the Manage Preliminary Billing Documents – Services App

Users can now upload, download, preview, rename, and delete attachments directly within the Manage Preliminary Billing Documents – Services app. Supported file types include spreadsheets, presentations, photos, and specification documents. Attachments can be previewed using an integrated viewer and downloaded individually or in batches, consolidating all relevant supporting materials within the preliminary billing document itself.

Dequanxu_2-1788267035465.Png

 

Keeping communication threads, business data, and supporting materials directly attached to preliminary billing documents reduces the risk of information loss or misplacement and improves collaboration across teams. The clear audit trail created by document-level attachments supports compliance with regulatory requirements and simplifies internal audit processes, while the ability to access all related information from a single location accelerates the processing and approval of preliminary billing documents.

 

Credit and Debit Memo Requests in Manage Sales Documents

The Manage Sales Documents app now supports credit memo requests (CMRs) and debit memo requests (DMRs) alongside existing sales orders and sales orders without charge. Users can list, change, and export all supported document types within a single centralized app, with all categories sharing consistent search, filter, and action patterns. New capabilities include creating DMRs and CMRs directly from sales orders or invoices, creating sales orders by referring to existing contracts or quotations, and using custom fields to filter sales document data. The fuzzy search feature and data-fetch logic for requested delivery date have also been optimized.

Centralizing the management of credit and debit memo requests together with sales orders in a single app eliminates context-switching between transactions and reduces operational friction for sales teams. The consistent user experience across all document types lowers training overhead, while the expanded filtering and creation options give users greater flexibility and control over the full range of sales document workflows from one place.

Dequanxu_6-1789386717017.Png

Supply Block in a Sales Order to Control Subsequent Activities

Sales orders received through any channel may not always be ready for logistics execution — they may be incomplete, subject to a credit hold, or pending an approval workflow. Proceeding with logistics activities in such cases can result in incorrect MRP planning, unnecessary procurement, or premature production. To address this, SAP has introduced an automated, item-level supply block that pauses available-to-promise (ATP) checking, requirements transfer, and purchase requisition generation until the order data is validated and all applicable blocks are resolved. A key improvement over existing mechanisms is that the supply block operates at the item level, rather than at the document level — providing more granular control and avoiding situations where a single incomplete line holds up an entire order. The supply block integrates with three sources: custom logic implemented through the BAdI SD_SLS_FINALIZE, credit check results, and approval workflow status. A unified “SupplyBlockStatus” field on each order item reflects the combined block state from all sources, and a “SupplyBlockReason” field provides additional context. Both fields are accessible via the Sales Order OData V4 API.

When a customer with a failed credit check places an order, the supply block activates automatically on all affected items, suppressing ATP confirmations, requirements, and purchase requisition generation until the block is released. When the credit block is subsequently cleared, the supply block lifts automatically for those items — but items that are also blocked by other conditions, such as an incomplete order line, remain blocked until the underlying issue is resolved. This results in a “partially blocked” status at the order level, giving operations teams precise visibility into which items are ready for further processing and which are not. The feature eliminates the risk of wasted planning resources and erroneous logistics activities, and is applicable to both sales orders and sales orders without charge, without requiring modifications to standard SAP order processing.

This blog explain the feature in detail.

Control Logistics Activities with Supply Block in SAP S/4HANA Cloud Public Edition

 

Dequanxu_5-1789386504168.Png

Schedule Price Calculation – Sales Price List

The new Schedule Price Calculation – Sales Price List Fiori app enables organizations to schedule price calculation jobs and generate comprehensive sales price lists before sales orders are created. This capability has been available in on-premise SAP systems since the ECC era — more than a decade — and is widely used, but was not natively available in SAP Public Cloud prior to this release. Prices are calculated based on document type, pricing dates, sales area, and customer and product data, with the output including net prices, discounts, surcharges, taxes, scale prices, and minimum order quantities. Calculated net prices can optionally be stored as condition records in one of three pre-delivered condition tables: customer-specific (4DA), customer price group (4DB), or generic (4DC). Three self-service configuration UIs (SSCUIs) allow organizations to define condition table mappings, create filter profiles to skip irrelevant pricing procedure steps such as short-term promotions or delivery fees, and map custom fields to pricing communication structures. Jobs can be scheduled as one-time or recurring runs — daily, weekly, or monthly — and large jobs can be split into smaller batches for performance optimization.

Sales representatives can use generated price lists to share accurate pricing with customers without triggering real-time calculations, while pricing specialists can leverage the output as a data source for future pricing planning. Web shops and external systems benefit from using a pre-calculated price snapshot for display purposes, removing the performance overhead of real-time pricing API calls at page load. The ability to persist calculated prices as condition records also supports long-term customer agreements: by locking in a calculated price at a specific point in time, organizations can ensure that future condition record changes do not alter previously agreed pricing. Calculated price lists can be downloaded as files and easily converted to Excel for further distribution or analysis.

Dequanxu_7-1789386782909.Png

 

Sales Price – Retrieve (A2X) API Version 2

Version 2 of the Sales Price – Retrieve (A2X) API introduces support for quantity and unit of measure as input parameters, enabling the API to return sales prices with all involved pricing elements calculated for the specified quantity. The API now also incorporates customer hierarchy into price calculations and can automatically retrieve customer material information when a product is entered.

Supporting quantity and unit of measure as inputs enables accurate, volume-based pricing in external systems and integration scenarios, eliminating the need for workarounds in quantity-dependent pricing configurations. Incorporating customer hierarchy ensures that group-level pricing agreements and tiered pricing structures are correctly reflected in API responses, improving consistency across complex customer organizations and reducing the need for manual pricing corrections downstream.

For more information, go to Sales Price – Retrieve (A2X)

 

Transfer of Sales Contract Reference Information to Sales Orders During Contract Assignment

Two new cloud BAdIs are now available for sales contract assignment. SD_ASSG_CONTRHDR_DATATRANSFER copies additional fields from a sales contract header to the headers of its release orders, while SD_ASSG_CONTRITM_DATATRANSFER copies additional fields from a sales contract item to the corresponding release order items. Supported fields include Price List Type and custom fields created in the Custom Fields app.

These BAdIs ensure that contract-specific pricing information and custom data flow automatically into release orders during contract assignment, eliminating manual re-entry and reducing the risk of discrepancies between a contract and its associated orders. This supports accurate tracking of contract price discounts for compliance purposes, improves visibility into customer commitments and obligations, and accelerates contract-to-order execution by removing the need for post-creation data corrections.

Dequanxu_8-1789386858105.Png

Substitution in Journal Entries Based on Transient Billing Document Data

Custom logic in BAdIs for journal entry substitution can now access transient billing document data at the precise moment a billing document is posted and passed to financial accounting — even before the billing document has been written to the database. This is made possible through a new class, CL_SDBIL_ACCTGINF_BPD_RTME_DTA, which provides access to billing document header and line-item details within the standard clean-core extensibility framework. Custom substitution logic can use this data to populate financial journal entry fields — such as document text, assignment, and reference fields — with billing-specific values automatically during posting, at both header and item level.

This capability eliminates manual post-processing steps previously required to enrich financial postings with billing context, and enables cleaner reconciliation between billing documents and the resulting journal entries by carrying key billing references — including originating sales document and item references — directly into the posted accounting document. By leveraging the standard extensibility framework rather than bespoke coding, organizations reduce upgrade risk and maintenance cost for SD-FI integration scenarios, while satisfying audit and compliance requirements for traceable links between invoiced line items and their corresponding financial postings.

For more information about working with this class, see Knowledge Base Article 3761835

 

Additional Advanced Variant Configuration Capabilities in Sales Order OData V4 APIs

The Sales Order OData V4 APIs now support products configured with SET and ETO (Engineer-to-Order) profiles, extending their coverage of advanced variant configuration (AVC) scenarios. A new action is also available to modify all assigned configuration values for an existing sales order item through the CRUD API, providing greater flexibility for integration scenarios involving configurable products.

These additions unlock integration possibilities for external webshops, quoting solutions, and analytical engines that work with complex configured products, enabling more automated and robust sales processes without relying on older OData V2 APIs. By consolidating AVC capabilities within the OData V4 API layer, organizations can simplify their integration landscape, reduce total cost of ownership, and take full advantage of the ABAP RESTful Application Programming Model and the capabilities of the OData V4 protocol.

Check this blog for details: Additional AVC capabilities in Sales Order OData V4 APIs

 

Billing Plan Capabilities in Sales Order OData V4 APIs

The Sales Order OData V4 API and the Sales Order Simulation OData V4 API now support billing plan entities, enabling external systems to manage milestone and periodic billing schedules through the API. Advanced down payment capabilities are also supported in both APIs.

Support for billing plans and down payments in the OData V4 APIs removes a significant barrier for organizations integrating external systems that require these capabilities, such as project-based sales platforms, webshops, and financial applications. This eliminates the dependency on older OData V2 APIs for billing plan scenarios, simplifying the integration landscape and reducing the total cost of ownership for affected integration projects.

For more information, see Create Sales Order with Billing Plan

 

Related Objects Capabilities in Sales Order OData V4 APIs

A new “Related Objects” entity set is now available at both the header and item level in the Sales Order, Sales Order Simulation, and Sales Order Without Charge OData V4 APIs. This entity allows organizations to add and track external references — such as identifiers from external order management systems, webshops, or quoting tools — directly on sales order records.

Providing a structured, standardized mechanism to link SAP sales order records to external identifiers simplifies integration with external platforms and reduces the need for custom workarounds. The consistent availability of related objects across the Sales Order, Simulation, and Sales Order Without Charge APIs ensures a uniform integration experience, improving traceability across hybrid system landscapes and lowering development complexity.

For more information, see Sales Order (A2X, OData V4)

 

Simulation of Pricing Results by Providing Product Hierarchy in Sales Order Simulation OData V4 API

The Sales Order Simulation OData V4 API now accepts product hierarchy as an independent input parameter. This enables the API to calculate complex pricing logic based on the product hierarchy, independently of the specific product provided, and return pricing results early in the sales process — before a sales order or even a sales contract is created.

The ability to simulate pricing based on product hierarchy gives organizations a powerful tool for early-stage pricing estimation, supporting faster quoting and better-informed commercial decisions. This extends the utility of the simulation API to a broader set of integration and planning scenarios, particularly for external configurators, quoting engines, and analytical systems that need accurate pricing signals at the earliest possible point in the sales process.

For more information, see Sales Order – Simulate (A2X, OData V4)

Flexible Plant Determination Through Cloud Business Add-In (BAdI) in Customer Returns

In large or complex enterprise structures, determining the correct receiving plant for a customer return often requires business-specific logic that cannot be expressed through standard master data, configuration, or reference document copying. The new cloud BAdI SD_SLS_DETERMINE_RETURNS_PLANT addresses this by enabling custom logic to determine the plant for returns order items of document type CBAR. Input parameters available to the BAdI include header fields such as sales organization and order reason, item fields such as product and return reason, business partner data including the ship-to party’s region and postal code, and extension fields from the document header and item. The BAdI is invoked during both the creation of a new returns order item and when relevant fields — such as ship-to party, product, or return reason — are changed on an existing item. When used via the Manage Customer Returns – Version 2 Fiori app or OData APIs, the redetermination behavior on change is controlled by the “Flexible Plant Determination” SSUI switch. This BAdI is exclusively applicable to document type CBAR and does not apply to lean returns.

This feature accommodates a common challenge in large enterprise structures: goods may originally ship from one plant but require return to a different, specialized facility — for example, a regional repair or refurbishment center — based on the customer’s location, the product type, or the return reason. Two implementation patterns are supported: simple rule logic coded directly in the BAdI method for straightforward scenarios, and a custom business object-based decision table for complex or frequently changing rule sets. The decision table approach decouples the determination rules from the ABAP code, allowing business users and configurators to maintain and update the rules without any coding changes. The result is more accurate and efficient plant assignment in returns processing, directly reducing logistics costs and manual intervention.

This blog explains the feature in details: BKP – Flexible Plant Determination Through BadI for Customer Returns

 

SAP Fiori App “Manage Customer Returns – Version 2”: Serial Number Support

The Manage Customer Returns – Version 2 Fiori app now supports serial number assignment for returned products. If a product is serial number-enabled and a serial number profile is defined at the plant level, users can assign serial numbers to return order items directly within the app — either manually or by reference to the originating document or product master data.

Serial number support gives returns processing teams the ability to track individual product units through the returns workflow, improving inventory accuracy and enabling more precise handling of high-value or serialized items. This enhancement empowers returns clerks to manage serial-number-relevant returns efficiently without requiring workarounds, and establishes the foundation for more granular after-sales service processes tied to specific product instances.

Dequanxu_0-1789386056830.Png

 

 

Returns Order API: Related Object Support and New Simulation OData V4 API

The Customer Return (A2X) OData V4 API now supports related objects at both the header and item level, through the new CustomerReturnRelatedObject and CustReturnItemRelatedObject entities. In addition, an initial version of the Customer Return – Simulate (A2X) OData V4 API is now available, enabling simulation of the creation of a standard returns order (document type CBAR), including header and item data as well as partners and pricing elements at both levels.

Related object support provides a standardized mechanism to track external references within returns orders, simplifying integrations with external platforms such as returns management systems, warranty portals, and e-commerce platforms. The new simulation API enables integrating systems to validate and preview the outcome of a returns order creation before committing, improving returns integration accuracy and reducing the effort required for error correction.

Dequanxu_9-1789386907045.Png

 

New SAP Fiori App: Manage Billing Documents – Version 2

The new Manage Billing Documents – Version 2 Fiori app serves as the successor to the existing Manage Billing Documents app, delivering a comparable functional scope alongside significant enhancements in capability, user experience, and technical foundation. New features include the ability to display each billing document’s PDF output directly from the list view, searching and filtering by product and WBS element at the item level, setting a deviating posting date, and creating, updating, or deleting price elements at both header and item level. The underlying technical foundation has been modernized as part of this successor delivery.

The successor app provides billing teams with greater control over billing document attributes and more efficient tooling for common billing tasks, while the streamlined user interface reduces navigational complexity. The modernized technical foundation, based on the ABAP RESTful Application Programming Model, aligns the app with SAP’s clean-core strategy and provides a stable, maintainable platform for future billing enhancements.

Dequanxu_10-1789386939623.Png

Dequanxu_11-1789386961824.Png

 

Advanced Down Payment Processing for Milestone Billing in Sales Orders

Organizations can now run a comprehensive down payment process for milestone billing in sales orders, orchestrated through billing plans and leveraging the standard condition technique for flexible down payment settlement. The process supports customer down payments with reference to sales orders, with the billing plan coordinating the sequencing and amounts of down payment requests, clearing, and final invoicing.

This feature reduces financial risk for project-based and milestone-driven sales scenarios by enabling structured collection of down payments before full delivery, supporting liquidity throughout the project lifecycle. The use of the standard condition technique for settlement provides the level of granularity and transparency required by finance teams, while the guided process experience at each step reduces complexity and the likelihood of processing errors.

Dequanxu_4-1789386410060.Png

 

Configuration of Customer-Specific Sales Order Types Using Sales Order Templates in SAP Central Business Configuration

Configuration experts working in SAP Central Business Configuration can now create customer-specific sales order types based on a predefined template derived from the standard order type (TA). The process is supported by a new application within SAP Central Business Configuration, and the resulting custom sales order types can be assigned to specific business process subsets tailored to defined roles, such as the Internal Sales Representative.

This capability enables organizations to introduce differentiated sales order types that reflect their specific business processes without the complexity and maintenance overhead of traditional customizing. Custom sales order types can be created and deployed with minimal configuration effort while remaining grounded in SAP’s best-practice foundation, reducing upgrade risk and making it straightforward to extend or adjust the configuration as business requirements evolve.

Dequanxu_3-1789386333624.Png

The topic page SAP S/4HANA Cloud Public Edition Sales collects most relevant blogs and documents on Sales.

Dequanxu_12-1789388611272.Png

Watch on demand: Our SAP S/4HANA Cloud Public Edition 2608 Early Release Series! 

Between July 13-17 2026, we hosted a series of 24 expert-led live sessions to highlight the exciting innovations shipped with the SAP S/4HANA Cloud Public Edition 2608 release. On our landing page you can watch on demand for the entire series or pick the sessions most relevant to you. 

Dequanxu_13-1789388611336.Png

Find all our assets  

The release 2608 showcases more than 130 innovation highlights across the portfolio. Check out our release document for all the details!

Dequanxu_14-1789388611286.Png

 

 





Source link

Leave a Reply

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

Chat with us on WhatsApp!