SAP Community - SD (Sales and Distribution)

SAP BRIM Subscription Order Management (SOM)

2023-11-07T20:25:15+01:00

SAP BRIM Subscription Order Management (SOM):

SAP Billing and Revenue Innovation Management (SAP BRIM) Subscription Order Management (SOM) is designed to help businesses efficiently to manage the complete lifecycle of subscription-based services. It plays an important role in managing all aspects of subscription orders, from initial creation of subscription order to billing and then revenue recognition.

SAP BRIM Subscription Order Management is a solution that streamlines subscription management, improves billing accuracy, and supports revenue optimization through effective pricing, discount management, and revenue recognition.

SAP BRIM SOM is typically used in industries such as telecommunications, utilities, and media.

SAP Subscription Order Management (SOM) Configuration Steps:

SAP BRIM Subscription Order Management (SOM) involves the following configuration steps to set up subscription order process. Some of the configuration steps may vary depending on the business requirements, here is a general information of the key configuration steps:

Master Data:

Business Partner:

The following role assignments are suggested:

Customer Role FLCU01 - For business partners to be used as contract partners in subscription order processing.

FI Customer Role FLCU00 - For business partners to be a part of sales processes carried out within SAP S/4 HANA.

Contract Partner Role MKK - For business partners involved in provider contracts within SAP Contract Accounts Receivables and Payable (FI-CA).

Create Product:

In SAP BRIM Subscription Order Management (SOM), product types are defined based on subscription-based products or services. These product types help to define the attributes, pricing, and billing rules specific to each type of product or service.

The following are the different product types:

Standard Product SUBS - SUBS is a Standard Products that are offered to customers as part of the standard service catalog. It is including predefined features, pricing, and billing terms.

Partner Agreement Product SUBP – SUBP is a Partner Agreement Products that are associated with partner agreements or partnerships.

Sharing Product SUBC - SUBC is a Sharing Products that involve sharing or collaboration between customers or entities for example shared subscriptions, shared access, or any offerings that involve multiple users or entities sharing the same product or service.

The following are the different Product Item Category Groups.

These item categories help to categorize and manage different types of charges and line items within subscription orders.

Subscription Usage Product PRRP – This Product Item Category Groups used for subscription services such as data usage, call minutes, or other consumption-based charges.

Subscription Recurring Product PRSR - This Product Item Category Groups used for Subscription Recurring Products such as monthly subscription fees, service charges, or any other regularly occurring charges used for subscription service.

Subscription Fee PRSV - This Product Item Category Groups used for fixed fees, periodic charges, or other flat-rate costs associated with the subscription service.

Subscription order Item Categories:

In SAP BRIM Subscription Order Management (SOM), item categories are PROR, PROP, PROF and PROS which are used to identify different types of line items or charges within subscription orders. These item categories determine the different types of charges and line items associated with subscription orders.

Here is a brief overview of these item categories:

Recurring PROR – The item category PROR is used for recurring charge within a subscription order such as monthly subscription fees, service charges, or fixed periodic charges.

Usage PROP - The item category PROP is used for usage-based charges such as data usage charges, call minutes, or data overage charges.

One-off PROF - The item category PROF is used for one-time charges or fees that are not part of the recurring subscription costs such as setup fees, activation charges, installation fees, or any other one-time costs.

Sales Item PROS - The item category PROS is used for sales-related items which are not the core subscription charges such as accessories, add-ons, or complementary items.

Create Contract Account:

In SAP BRIM Subscription Order Management (SOM) contract is used to set up agreements or terms between the service provider and the subscriber for the delivery of subscription services. These contracts specified with the specific conditions, pricing, and other details related to the subscription. Standard transaction code /nCAA1 is used to create contract.

Subscription Transaction (Order) Types:

In SAP BRIM Subscription Order Management (SOM), different order types are used for various types of subscription orders and transactions.

Subscription Order PRVO – The order type PRVO is used for subscription services, and it is involving the creation or modification of subscription agreements. These orders specify the terms and conditions of the subscription such as start date, end date, pricing, and services.

Pattern Agreement Order PRPO - The order type PRPO is used for managing pattern agreements and it is recurring contractual agreements with customers. These agreements include regular deliveries, services, or other recurring transactions.

Solution Quotation SRVP - The order type SRVP is used to provide quotations to customers for solutions or services. This order type is frequently associated with sales and quoting process, their associated costs, and terms to potential customers.

Subscription Contract PRVC - The order type PRVC is used for subscription contracts which is used to decide and manage agreements between a service provider and a customer for subscription-based services. These contracts describe the terms and conditions of the subscription, such as pricing, duration, service levels, and any additional details relevant to the subscription.

Subscription Contract: Subscription contract is used to manage subscription-based services. Subscription contracts help service providers and customers to define their mutual obligations and ensure that services are delivered and billed accurately. Standard transaction code /nFP_VT3 is used for Subscription Contract.

Copy Control for Transaction Types and Item Categories:

Review copy control setting for the subscription order Transaction Types and Item Categories in Implementation Guide (IMG) – Service.

Integration with SAP Convergent Invoicing (CI):

Discount and Charges –

Contractual discounts are the discounts agreed upon in contracts with specific customers or groups of customers. They are usually based on negotiated terms and conditions. It can be discount on Master Agreement or Provider Contract.

Charges in SAP BRIM SOM include various types of fees and costs associated with subscription.

Billing Plan -

When creating the provider contract, we determine the right billing plan type based on the transaction type and item category of the subscription contract item, which in turn helps identify the assigned billing plan and item type.

You can set up the following configuration in the Implementation Guide (IMG) for the billing plan.

Define the billing plan.

Define the billing plan item type.

Maintain the settings for the Billing Cycle.

Maintain the settings for Recurring Fees.

Assign Billing Plan Types and Billing Plan Item Types to Transaction Types and Item Categories

Implementation Guide (IMG):

Refer Implementation Guide (IMG) for the details of Subscription Order (SOM) configuration.

SOM Subscription Order - SPRO → Service →

CI Billing Plan - SPRO → Financial Accounting → Contract Accounts Receivable and Payable → Convergent Invoicing

Thank you for taking the time to read this article.

Encryption & Masking in SAP - key points

2023-11-16T09:33:56+01:00

Introduction :

As many posts/blogs are extensively available online for the above subject, the purpose of this post is to highlight a few key points, differences & relv. SAP Notes consolidated.- on a high level.

The basic point to be kept in mind is that, STD SAP does NOT permit the flow/default of Payment Card # from the CMR into an SO. They have to be entered manually by an user at SO level.

The above is applicable for S/4 HANA systems too.

For copying the payment card # automatically from the CMR into the SO, a custom code is to be implemented at USEREXIT_MOVE_FIELD_TO_VBAK ( Include: MV45AFZZ)

Encryption	Masking
For unstructured data like files, videos, images, etc	For structured data like Payment Cards,SSNs,etc
Focuses on data being secured	Focuses on data being functional
Reversible	Irreversible

SAP STD Program	Purpose
CCARDEC_TRANSFORM_SD	To check & encrypt values in SD
CCARC_CHECK	To check the encryption
CCARDEC_CHECK	To ensure that the encryption tool is working correctly
CCARDEC_TRANSFORM_VCKUN_VCNUM	for the retrospective encryption of the card data in the CMR

Desc	SAP Notes #
FAQs : Credit Card encryption in R/3 systems	766703
FAQs : Credit Card encryption & master data	836079
Encrypting Credit card data	633462
FAQs/Collective note for Payment Cards ( Consulting/modif)	914603
Payment Card # all digits masked	1820234 ( KBA)
Security when displaying credit card no:s	1105524
FAQs : Credit card encryption in CRM	1034482
SSF Encryption using the SAPCryptolib	662340
Payment card not masked in SO	1947100

Feedback/suggestions are improvement are welcome.

Thank you for your time.

Sumanth Gururaj

ODN (Official Document Number) configuration settings for India (SD/MM/FI) for GST

2023-11-24T12:12:06+01:00

ODN is used for documents that are, issued to customers & received from Vendors – to be submitted to the tax authorities.

ODNs must be consecutive, w/o any gaps.

We can also use a 2-digit prefix, for any specific identity in SAP.

Below notes should be implemented fully and correctly

Desc	SAP Notes #
GST India: Data Dictionary Activities for Official Document Numbering	2487589
GST India: Official Document Numbering	2472623
GST India: Official Document Numbering	2489866
GST India: Corrections to Official Document Numbering Solution	2490434
GST IN: Invoice and ODN numbers are skipped while saving billing document in transaction VF01	2487781
GST India: ODN Corrections to note 2490434	2496105
GST India: Customer exit to enable ODN for payment vouchers & other relevant transactions	2496588
GST India: ODN Corrections to populate fiscal year for billing documents	2497855
GST India: ODN Corrections to enable BAPI_ACC_DOCUMENT_POST & additional functionality	2497727

The steps are broadly classified as below:

Maintain Document Classes

Assign Document types to Document Classes

Maintain Groups

Maintain Number ranges for Official Document

Assign Number ranges to Business Places

Maintain Document Classes

Execute the Tcode: SM30

Enter the Table/View - V_DOCCLS &click on “Edit” button

Enter the country key as ‘IN’

Click on “Enter” button. Then, click on “New entries” button in the next screen.

Document classes are to be maintained as per Business requirements.

Reference entries are illustrated below:

Assign Document Types to Document Classes

Execute the Tcode: SM30.

Enter the Table/View - J_1IG_V_T003_I & click on “Edit” button.

Click on “New Entries” button.

Maintain the entries as per your business needs.

Reference entries are illustrated below:

PS: It is recommended to maintain the ODN control as ‘C’ which is w/o Date Control for country ‘India’.

Maintain Number Groups

Execute the Tcode: SM30.

Enter the Table/View - J_1IG_V_NUMGRP & click on “Edit” button.

Click on “New Entries” button.

Maintain the number groups.

Maintain Number ranges for Official document

Execute the Tcode SNRO.

Give object name as ‘J_1IG_ODN’ & click on “Intervals” on the tool bar

To be maintained for the corresponding Number Groups: (Sample Illustration, below)

Assign Number ranges to Business Places:

Execute the Tcode: SM30.

Enter the following Table/View - J_1IG_V_OFNUM & click on “Edit” button.

Click on “New Entries” button.

Assign the number group to the combination of Company code, Business Place & Official Document Class.

Pls find below the sample illustration:

The following (highlighted in yellow) is the reflection of the ODN set – at the front-end:

Hope, the above is helpful.

Suggestions for improvement are welcome.

Thank you for your time.

Sumanth Gururaj

Flexible Workflow for Sales for Public Cloud - Complete Guide

2023-12-01T12:21:40+01:00

Sales Flexible Workflow in SAP S/4HANA Public Cloud - Complete Guide.

Introduction

In this blog, we'll discuss the step-by-step implementation of S/4HANA Public Cloud Flexible Workflow for Sales, including scenarios.

It's a highly requested feature in SAP S/4HANA Public Cloud, allowing for simplified workflow setup without complex development. Flexible Workflow, part of SAP Business Workflow, covers various lines of business like Finance, Procurement, HR, Manufacturing, and Sales. This blog is your complete guide to Flexible Workflow for Sales in the Public Cloud.

This blog is your complete guide to Flexible Workflow for Sales in the Public Cloud.
I hope you enjoy the Journey.

Blog Agenda:

Flexible Workflow for Sales:

Sales Flexible Workflow Introduction for Public Cloud

Environment Setup For Public Cloud

User and Role Authorization

Cloud BAdI Overview for Manage Sales Document Workflows

Create Workflow for Sales

Testing Scenarios.

Useful Apps

Issues and Solution

Conclusion

1- Sales Flexible Workflow Introduction for Public Cloud:

In certain cases, it can make sense to make sure that a sales document is first approved by a sales manager and C-Level Manager before the internal sales representative or returns and refund clerk can process it further, If everything is fine, the document could be approved and proceed, Our Blog today will show a case of Sales Order Workflow.

2- Environment Setup For Public Cloud:

Before we configure the Workflow, there are a few steps that need to be done by the Key User / System Admin / SAP Public Cloud Business Consultant with Access to CBC, to make sure our process works smoothly.

Create Approval Request Reasons via Configuration Activity [Node ID:102751] (Role: SAP_BR_BPC_EXPERT)

Define reasons that are displayed in sales documents or preliminary billing documents to let the business user know why these documents need to be approved.

You must define at least one reason for approval requests to set up the approval workflow for sales documents.

Assign Approval Request Reasons via Configuration Activity [Node ID:102752] (Role: SAP_BR_BPC_EXPERT)

Assign the approval request reasons that you have defined to document categories.

Once you have defined approval request reasons, you specify which documents these reasons are valid for by assigning them to one or more document categories.

3- User and Role Authorization:

There are Two Ways to Assign the User to Workflow One Is By User and the Second By Teams, We Will Explain One by One.

Workflow by User:

User needs the role: SAP_BR_SALES_MANAGER (This makes sure that the user is available in the value help of the user assignment in the manage sales document workflow app)

The user also has access to the My Inbox app to see the approval tasks

The user has an Employee Role from the Manage Workforce App

Once you have created the role in the User from the Manage Workforce App, it will be shown in the Maintain Business Partner App with the Personnel Number.

Workflow by Teams:

The user needs the role: SAP_BR_BPC_EXPERT

Launch application Teams and Responsibilities

Choose Category Sales

Define a new team and assign team members

A very nice video to watch: Learn about Responsibility Management.

4- Cloud BAdI Overview for Manage Sales Document Workflows:

In this step, we will activate the BAdI which is responsible for activating the Workflow for Sales, this step is done by the SAP Business Consultant / System Admin.

The user needs the role: SAP_BR_ADMINISTRATOR

Understand the Logic of the BAdI Code

Understand the Logic of the Business Need from the Workflow

The above figure provides an overview of the approval workflow, starting with the creation of a sales document.

1. Go to Custom Logic App.
2. Create a BAdI copied from the pre-defined (SD_APM_SET_APPROVAL_REASON).
3. Add your custom logic in the BAdI (check the example code below).
4. Save and Publish your newly created BAdI.

The above screenshot provides an overview of the BAdI, Check this SAP Help

Setup Example: Approval Workflows in Your System.

Business Logic:

If document category = C (Order Category)
And Document Type Internal Key = TA (Sales Order Type = OR)
And Sales Organization = 5910
And Approval Reason = ZOR1 (Approval Reason we've created)
=
Starts Sales Workflow

Example Code 1:

*trigger a workflow by setting approval request reason ZOR1.



if salesdocument-sddocumentcategory = 'C'  and "Sales Order document category is "C"; Beware Sales Order without charge is "I"

   salesdocument-salesdocumenttype = 'TA'  and "Internal Key values are available in the Badi (TA and not OR)

   salesdocument-salesorganization = '5910'.

   salesdocapprovalreason = 'ZOR1'.

   return.

endif.

Example of Order Category :

Order Category	Order Category Code
Sales Quotation	`B`
Sales Contract	`G`
Sales Order	`C`
Sales Order Without Charge	`I`
Customer Return	`H`
Credit Memo Request	`K`
Debit Memo Request	`L`

Example of Internal Key:

Sales Document Type	Internal Key
QT (Quotation)	AG
CR (Credit Memo Request)	G2
DR (Debit Memo Request)	L2
OR (Standard Sales Order)	TA

More Examples:

Example Code 2 for Quotation:

** Example 2: All sales quotations containing a customer with a specific customer abc classification

** shall trigger a workflow by setting approval request reason ZQT1.

*

*    data lv_customerabcclassification type if_cmd_validate_customer=>ty_bp_sales-customerabcclassification.

*    if salesdocument-sddocumentcategory = 'B'. "Sales quotations

**   As the customer abc classification is not availble directly in the importing parameter we need to

**   select the customer classification from released CDS view I_CustomerSalesArea

*      select single customerabcclassification from i_customersalesarea into @lv_customerabcclassification

*         where customer            = @salesdocument-soldtoparty and

*               salesorganization   = @salesdocument-salesorganization and

*               distributionchannel = @salesdocument-distributionchannel and

*               division            = @salesdocument-organizationdivision.

*      if lv_customerabcclassification = 'A'.

*        salesdocapprovalreason = 'ZQT1'.

*        return.

*      endif.

*    endif.

Example Code 3 for Sales Order with Payment Terms:

** Example 3: All sales orders with order type “Standard Order”, for which the terms of payment have been changed

** from a non-initial value shall trigger a workflow by setting approval request reason ZOR2.

** As you already see here the Example 1 and Example 3 could intersect in conditions.Kindly take care

** of this in the real implementation.

*

*    data lv_customerpaymentterms type dzterm.

*

*    if  salesdocument-sddocumentcategory = 'C'.  "Sales Orders

*      select single customerpaymentterms from i_salesorder into @lv_customerpaymentterms where salesorder = @salesdocument-salesdocument.

*      if lv_customerpaymentterms is not initial and "Check for non-initial

*         lv_customerpaymentterms ne  salesdocument-customerpaymentterms. "Check for value change

*        salesdocapprovalreason = 'ZOR2'.

*        return.

*      endif.

*    endif.

Example Code 4 for Credit Memo Request:

** Example 4: All sales documents of type credit memo request independent of the credit memo request data

** like credit memo request type, sold-to party, order reason, etc. shall trigger a workflow by setting

** approval request reason ZCR1.

*if  salesdocument-sddocumentcategory = 'K'.  "Credit Memo request

*   salesdocapprovalreason = 'ZCR1'.

*   return.

*endif.

Example Code 5 for Sales Quotation with Net Value:

** Example 5: A sales quotation which is status "not relevant" could be approval relevance because of some changes;

** like the net amount is decreased signficiantly and the sales manager needs to be made aware of the change.

** Here we have approval process for 2 scenarios. Either incase the sales quotation net amount is greater than

** 10000 EUR or 12000 USD (assuming business is done only in these currencies) or incase the the net value

** reduces by 50%. These cases shall trigger a workflow by setting approval request reason ZQT2 (NetValue related approval)

*

*    data lv_totalnetamount like salesdocument-totalnetamount.

*    if salesdocument-sddocumentcategory = 'B'. "Sales quotations

*      select single totalnetamount from i_salesquotation into @lv_totalnetamount where salesquotation = @salesdocument-salesdocument.

*      if sy-subrc = 0.

*        if lv_totalnetamount > 0.

*          if ( ( lv_totalnetamount - salesdocument-totalnetamount ) / lv_totalnetamount ) * 100 > 50. " Reduced greater than 50%

*            salesdocapprovalreason = 'ZQT2'.

*            return.

*          endif.

*        endif.

*      else. " New Quotation.

*        if  ( salesdocument-totalnetamount > 10000 and salesdocument-transactioncurrency = 'EUR' ) or

*            ( salesdocument-totalnetamount > 12000 and salesdocument-transactioncurrency = 'USD' ).

*          salesdocapprovalreason = 'ZQT2'.

*          return.

*        endif.

*      endif.

*    endif.

Code Reference: Public Cloud 2308 BAdI.

5- Setup Flexible Workflow for Sales:

After we finished the configuration of BAdI and made sure the user was already maintained, it's time to finish the last step, which is the Flexible Workflow for Sales.

Steps to Follow:

1. Go to Manage Sales Document Workflow
2. Select Workflow for Sales Order from the Drop-Down List.
3. Click Create Button
4. Add Workflow Name, Description, Validity of Workflow, And Define Conditions.
5. Add Recipients (Teams or Users) and Rework Cases
6. Create and Activate the Workflow

The above screenshot provides an overview of the creation of Sales Order Workflow such as Name and Conditions and Description.

The above screenshot provides an overview of the creation of Step One of the User Assignment.

The above screenshot provides an overview of the Define Action Result for Workflow when the Approver Requests a Rework of the Sales Order.

The above screenshot provides the last step of the Workflow Creation and Activation.

6- Testing Scenarios:

Test Case Scenario:
*Sales Order Creator: CB9980000013
*Level One Approver: CB9980000015
*Responsible of the Rework: CB9980000013

*White Theme = Creator = CB9980000013
*Black Theme = Level One Approver = CB9980000015

Case 1: Creation of Sales Order.
Case 2: Changing the Sales Order.
Case 3: Checking Notification and Request Rework.
Case 4: Reject the Workflow.
Case 5: Approve the Workflow.

Case 1: Creation of the Sales Order Using the Manage Sales Order Version 2 App

Creation of the Sales Order, After Activating the Workflow.

Once the Sales Order (6) is Saved, the Approval Reason will Appear means the Workflow is Started.

Case 2: Changing the Sales Order from Creator Using: Manage Sales Orders Versions 2 App and from Approver Level One Using: GUI App VA02.

Once the Workflow is Started, No Changes are Allowed.

Case 3: Checking the Notification on the Fiori Home, Check the Sales Order from My Inbox App, Request Rework with Comments Added.

Request Rework for this Workflow Task.

Rework will Trigger the Creator of the Sales Order, with Comments Shown to User, and the Edit Option will be Allowed.

Case 4: The Impact of Rejecting a Sales Order.

Rejecting a Sales Order will Reject all Items with Rejection Reason: Rejected by Approver (77).

Case 5: Approving the Sales Order.

Approved Sales Order Status.

7- Useful Apps:

While I was creating the workflow for Public Cloud, I had to use it to track the process and issues,
This is My Most Useful App I Used for the Workflow.

App 1: Flexible Workflow Administrator
Benefits of this app:

Display a list of all flexible workflow instances.

Filter and sort the displayed flexible workflow instances.

Cancel one or several selected flexible workflow instances in one go.

Resume one or several selected flexible workflow instances in one go.

Forward Workflow to a Secleted CB User.

Display detailed information about the flexible workflow instance.

Check Step Log.

Check the Workflow Log.

App 2: Workflow Administrator GUI (t.code: SWIA)
Benefits of this app:

Restart a workflow instance.

Cancel a workflow instance.

Resume stuck workflows.

Find invalid user assignments.

Forward dialog work items.

Configure a substitute for an absent user.

Trigger a new determination of the potential processors of a task.

8- Issue & Solution:

Issue 1:

Issue 2:
Issue 3:
Solution: Workflow Trigger Issue Solution: SAP Note

9- Conclusion

Flexible workflows in SAP S/4HANA Public Cloud can be customized through the scenarios that can be created and made suitable according to the needs thanks to the BAdI of your processes without hard-coding development. Also, key users can make changes and edit these scenarios without needing developers.

Reference Blog: Flexible Workflow in Sales Documents

Thank you for reaching the end of this journey
I really appreciate your lovely feedback.

- Mohamed El Khawanky

How to Hide Sub-items of BoM Items in Sales Document Output

2023-12-21T09:36:35+01:00

Background

A BoM item usually contains a head item and several sub items. In the output form of sales document, both the head item and subitems will be displayed. For some suppliers, they prefer not to show the subitem information to their buyers. Therefore, they want to hide the subitems in the final output form. With the solution we provided, you can customize your output form to hide the BoM subitems that have no price.

Standard Output

Prerequisite

A business role that contains the following business catalogs is assigned to your user:
- SAP_CORE_BC_OM (Output Management)
- SAP_CA_BC_IC_LND (End to End Implementation Experience - Implementation Cockpit)
- SAP_CA_BC_OC_PC (Output Management - Output Control)

You have installed the Adobe LiveCycle Designer app.

Procedure

Logon to the Fiori Launchpad as a key user (extensibility specialist)

Search and enter the Maintain Form Template app.

Choose the Predelivered Templates tab.

Search for the output form template you are using, for example, SD_SLS_ORDER_CONFIRM (sales order confirmation), and open it

Download the form template.

Drag the .xdp file to the Adobe LiveCycle Designer app to open it.

Open the Hierarchy window and the Script Editor window from the menu and find the item node named "rowItem"

*Note: There are two nodes called "rowItem". Be sure you chose the second one.

if( ( frmHiddenItem.txtHigherLevelItem.rawValue ne  "000000" ) and ( frmHiddenItem.decNetValue == "0.00" ) )   then

  this.presence = "inactive";

endif;

// hide subitems with net value 0.00

In the Script Editor, write the following code to hide the sub-items whose item net value is zero.

Save the form.

In the Maintain Form Template app, create a custom form template.
1. For the form template file, choose the file that you adapted earlier.
2. Choose the correct data source (for example, FDP_V1_ORDER_CONFIRM_SRV for sales order confirmation).
3. Choose the Content form type.

Assign your custom for template.
1. In your configuration environment, open the configuration activity Assign Form Templates.
2. Create a new entry. Use, for example, SALES_DOCUMENT as the application object type and ORDER_CONFIRMATION as the output type. For the form template ID, use the one of the custom form template that you created earlier.

Define business rules for custom form template
1. In the Output Parameter Determination app, show the rules for the sales document and the determination step for form templates.
2. Select the relevant rule (for example, for order confirmations), and edit it.
  
  Note that alternatively, you can also create a new rule.
3. Change the form template name to the one of the custom form template that you created earlier.

Now you can create a sales order with BoM items and check the output form:

Post M&A considerations, including shared services (Enterprise Business Services).

2024-01-04T01:27:34+01:00

Post M&A considerations, including shared services (Enterprise Business Services).

Carroll Oglesby III, Randy Garrison, Dmitry Melnik, SAP

* * *

This blog is based on SAP customers who underwent Mergers and Acquisitions or Divestitures (M&A/D). While we sanitized the names and used only public information, this material reflects actual post-merger integration (PMI) considerations, priorities, and PMI execution experiences of SAP customers. As such, this content will be helpful to any CIO team members facing similar challenges amidst business combinations. Moreover, to help you, our reader, we incorporate the first-hand perspective of an imaginary person, John, who serves as the Chief Information Officer of a company in the middle of an M&A deal. Think of this as Harvard Business Review type case.

Prologue

John put the phone down and sat back in his chair. The evening was settling in but John, the Chief Information Officer, felt like his day was only starting. The CEO on the phone a minute ago was very clear: since the Board had just approved the hotly debated M&A deal, in two days John must present to the Directors a detailed IT plan of the post-merger integration. His company was merging with a similar size competitor and the combined company was expected to compete fiercely in the rapidly changing fashion retail market. In his IT career, John had gone through a few M&A deals and understood the risks very well. The situation was further complicated by the fact that the combined company had to realize some $100m in synergies within the first year of operations. And the Board was looking for fast answers. Which PMI actions would be the most urgent? Most impactful? How would the architecture evolve? John had to address these and myriad other topics very fast.

Situation: M&A as a risky move

Much research has been done on the topic of M&A. Some numbers, though, tend to stand out amidst all the data and analyses: how quickly value can be destroyed in mergers and acquisitions. Some researchers found that while a typical “full control” premium paid by the acquiror can reach 30% of the acquired entity’s value, the returns to the buying shareholders are far from certain and exhibit an almost 60 percentage points range, from “negative thirties” to “positive thirties”. Examine the chart below: business combinations pose substantial risks in terms of the shareholder returns.

John typed his company’s stock ticker and stared at the screen. Yes, his company was paying an even higher full control premium, over 50% of the target’s recent stock price. So predictably, the market reacted negatively on the M&A news: John’s company lost 20% of its value in just one day. The stock performance chart (please see below) was quite telling…

[sanitized depiction of an actual situation]

What is the programmatic way to reduce the risks which are so well reflected in the market sentiment?

The experiences of our customers reveal three major milestones in the post-M&A, or PMI, effort:

Harmonize and Unify, -

Integrate and Operate, –

Evolve and Grow.

While somewhat of an oversimplification, these milestones provide a solid framework for your PMI actions, from immediate to long-term.

The Harmonize & Unify phase focuses on the data. How can the combined entity report its results to the shareholders? What nomenclature should it use going forward: SKU definitions, Business Partners, people (employees and contractors), operating units (business segments) vs. legal entities, and many other similar considerations form the basis of the data unification. This phase is usually urgent due to the reporting needs but also lays the foundation for the long-term growth.

The second phase, Integrate and Operate, focuses on synergies. For example, for a deal to be valuable to the shareholders, it needs to be accretive. Combined company net income expressed as net margin (Net Income / Revenue) must be higher than the net margin of the acquiring entity. Synergies are the costs which “sit in the middle” and should be taken out. Other types of synergies relate to revenue and include the ability to cross-sell and cultivate each company’s customers for a higher share of wallet. This is where the two short- and mid-term phases graduate into the thirds one, Evolve and Grow.

The chart below reflects this simple framework. On the right-hand side you can see the market shares of the key players in this market. We sanitized the names, but the numbers represent actual estimates by the Wall Street Journal; John’s company would become a larger player after this deal, capable to compete more successfully in the long run.

John re-examined the 3-phase PMI framework which had proven helpful in the past and contemplated the first few months post-closing of the deal. Yes, problems always pop up and multiply. He recalled the example of an acquisitive SAP customer in fashion and jewelry design where the business and IT colleagues had to solve various PMI issues.

Then another thought occurred to John as he started typing an email to his DBA team lead: reporting. Clearly, there will be no shortage of topics to address and problems to solve, but reporting would quickly become the highest priority to address with the CFO as well as colleagues from the acquired entity: the first quarterly report… John sighed and dialed the CFO. Night was young…

SAP customers utilize various means to report their combined operational and financial results. As integration deepens, the CFO and other executives get more details and insights. But here we emphasize the initial reporting needs and the process to build a solid long-term foundation. This brings up one of the options, SAP S/4HANA Group Reporting.

The below chart summarizes the workflow and distinguishes between fully automated and manual steps. On the left-hand side of the chart, you can see four different ways to bring in the data for group reporting, from completely manual data collection on the bottom to a fully automated and integrated approach on the top. Clearly, the actual world is more nuanced, but our takeaway is simple: the more integration effort channeled at the data unification upfront, the easier group reporting will become.

Combined company reporting is one of the many processes dependent on the unified and harmonized data. However, many other processes can be standardized across the two entities which after the deal operate as one. These processes often reside within the shared services or, as we call it nowadays, Enterprise Business Services (EBS).

Customers often prioritize the EBS standardization between two entities in the following way: start with the processes which are identical and do not touch the essence of the business, i.e., which are “undifferentiated” in the marketplace. For example, for John’s company invoices between the company and its 3PL (logistics) vendors are hidden from the end consumer, therefore we can call them “undifferentiated”. On the other hand, the product returns and exchanges constitute a major part of the consumer experience and therefore are “differentiated”, i.e., they separate the company from its competitors. Once you move the undifferentiated processes to the combined EBS, the next wave covers the processes which do differentiate the company and can be automated. For example, product delivery for online orders is one of those differentiated processes for John’s company. Finally, address the processes which can “make your smart people smarter”. These may include a wide range of processes in analytics, budgeting, even product GTM planning, and so on. And this is where you can extend the integration and automation from the headquarters (HQ) to the business unit (BU) level.

Chart below summarizes such prioritization and lists a few SAP customers who have achieved improvements in their respective process areas, from expense reports processing to direct customer service and product innovation. Please do follow the links and examine, for example, the case of the Huabao Group which utilizes SAP Intelligent Technologies to create consumer-specific custom-tailored fragrances.

John made a few notes to cover the EBS topics during his tomorrow’s team call to action. In his mind, the picture was emerging clearly: start with the data harmonization, proceed to the immediate and long-term reporting needs, extend the integration effort to other shared service (EBS) processes to help the combined company operate more efficiently. He smiled satisfactorily: this effort will also aide his team in pursuit of the synergies.

Complication: publicly announced synergies

Synergies, both on the revenue and the cost sides, are one of the reasons for business combinations. In the end, these synergies ensure the “2 + 2 = 5” value creation. However, the imperative to realize synergies quickly puts pressure on the PMI activities and can present a significant challenge to all Lines of Business (LOB), including IT. John’s company - while announcing the offer to buy shares of its former competitor and future business unit - stated that some $100 million of synergies will result from the combination in the first year. This expectation often goes under a magnifying glass of the shareholders and analysts so that the combined company ends up periodically reporting on the progress of such synergies.

A business combination (M&A/D) provides an opportunity to reflect on the business evolution and reassess various improvement options. Here is one of the many examples and case in point.

John quickly made some calculations and paused, pondering each phrase of his report to the Board. Some de-duplication of systems and other items of the IT budget were clear, but they would not come even close to the required $100 million synergy target. John recalled the previous M&A/D and formulated his request to the Board: Directors’ guidance would be critical. He would ask the Board about the business direction before committing to a specific course of action in IT.

Consider a typical profit and loss statement (P&L) specific to this market (chart below). Start with the revenue on the left-hand side and move to the right. This is an actual SAP customer and the numbers come from their annual report. Costs of Sales, or COS, include direct procurement, inbound logistics, warehousing and other directly attributable costs. Will synergies come from here? Then organizational capabilities around centralized procurement and inbound logistics will most likely have to evolve, and this will present a specific set of IT implications. On the other hand, marketing and selling costs such as real estate (shops), sales commissions, distribution costs (outbound and last mile delivery) may provide another source of synergies; then the IT implications may be very different.

In both cases, customers often differentiate between process de-duplication and process evolution. The former is relatively straightforward, but its optimization impact is usually one-time. The latter requires more change management but may result in long-term (repeatable) efficiency gains.

We can summarize this based on the discussion we have had to this point:

Enterprise Business Services of the combined company will generally take care of the process de-duplication, especially for the processes which span across all business units (finance, logistics, procurement, etc.) Of course, processes “below”, i.e., specific to each BU, need to be addressed carefully, one by one.

In parallel, various Intelligent Technologies can evolve the combined company processes, in some cases creating completely new processes and abilities which did not exist before.

But at any rate, business picture including the clear map of the synergies will drive the respective organizational capabilities development and, as a result, the underlying IT architecture. “Tell me what the business wants – we will formulate how to get there.”

Resolution

In the morning the sun looked warmer… John finished his coffee and pressed the send button. His tomorrow’s Board presentation was ready and just went on to the CFO and CEO for preview. Once he formulated the “must do” topics as well as “need your guidance” ones, the entire picture made sense, at least as the immediate action plan for the combined company’s IT function. Much work was ahead but the path was clear. Half a day after the M&A news and the CEO directive John was ready and eager to start his team meeting.

Let us recap the discussion so far.

Data is easily the most urgent topic for the PMI activities.

Combined company reporting becomes the critical capability which balances both the compliance needs (“must have”) and executive insight imperatives – and stands on the solid data foundation.

As the companies start operating as one, shared services, or Enterprise Business Services (EBS) become the “common denominator” which can glue the companies together; reporting is just one of such EBS but the list of shared services is much larger.

As the Board is “on the hook” for reportable synergies, business should define key source areas and IT should devise the roadmap to realization, taking into consideration the evolution of the architecture and new technologies available to turn this vision into reality.

Does this roadmap tell the full picture? Of course, not. This is merely a summary of key actions and focus areas during a typical PMI. Each company situation is unique and may differ based on the “pre” architecture, industry and market dynamics, urgency, constraints, and a multitude of other factors. In other words, your specific situation - and therefore roadmap - may differ. But we hope that this discussion may help you to frame your roadmap process based on the experiences of many SAP customers.

One question arises in relation to this picture: what lies ahead in the longer term? In other words, what is to the right of this graph? We cannot answer this question in simplistic terms: the further away we look into the future, the more the paths diverge. However, let us finish this discussion with one customer example. This organization went through a series of significant M&A/D transactions aimed both at creating more muscle and tuning it up (making it leaner, if you will). This is how they formulate their next horizon goals in terms of revenue and growth, direct-to-consumer business, Free Cash Flow and so on:

Epilogue

Party was in full swing. First anniversary as a combined company was indeed a great achievement. John glanced at his combined team and recalled the start of this merger. Much changed since then, and his team members – located across the globe and rooted in both companies – came a long way since a year ago when they barely knew and trusted each other. He smiled and raised a toast to all who turned a vision of the successful integration into reality.

Role-Based Access to Price Elements in SAP S/4H 2023

2024-01-10T09:28:10+01:00

Hi Friends ,

In this Blog, we will discuss about how to control business users' access to price elements in specific SD document.

Business Requirement : Is it possibly to hide a price element/condition types (such as the Profit Margin and Internal Cost) from some business users in specific sales documents or customer invoices

Solution : In S/4H 2023 , SAP has enabled the new feature i.e. Role- based Access to Price Elements with this we can hide a price element (such as the Profit margin and Internal cost ) from some business users in specific sales documents or customer invoices. With this feature, the system to automatically control the type of access (no access, display access, change access) that business users have to price elements of an SD document on header or item level. With this , we can also prevent some business users from editing specific price elements in sales orders. We can use this function to control business users' access to price elements in sales orders, returns orders, credit memo requests, and debit memo request

Define Access Levels for Price Elements Customizing activity.

Assign Access Levels in Pricing Procedure : New field is introduced in pricing procedure i.e. Access Level .Here the Business experts can determine which access level is assigned to which Pricing condition /Pricing Elements .

Authorization Roles setting

The access level can be assigned as per requirement . In the example below

The logistic expert can only view/display the pricing elements assigned to the access level 1000.

The Internal Sales Representative can view all pricing elements as he/she is given a display of both access level(1000-8000)

The sales Manager has the ability to change and display all pricing elements as he /she has both access level and change the access((1000-8000) .

PRCG_ACC authorization object as follows

Field	Change Access	Display Access
KAPPL (Application)	V (Sales/Distribution)	V (Sales/Distribution)
PRCG_SOT (SAP Object Type)	Sales Order Billing Document Preliminary Billing Document Billing Document Request Invoice List Credit Memo Request Debit Memo Request Customer Return	Sales Order Billing Document Preliminary Billing Document Billing Document Request Invoice List Credit Memo Request Debit Memo Request Customer Return
ACTVT (Activity)	02 (Change), 03 (Display)	03 (Display)

I hope this will helps you.

Thanks,

Sreenivasulu.

Insights on Columnar store for SAP Functional Consultants

2024-02-16T08:29:30.650000+01:00

Introduction:

I hope its not a surprise for any one reading this Article that SAP S/4HANA uses HANA DB and HANA DB uses Columnar Data Storage for most of its critical table. There is boat load of Articles around why Columnar Data Storage is good for the world and its blazing speed. My initial thoughts when I learnt how Columnar Daomta Storage works is, it is "less intuitive" than Row Data Storage. Row Data Storage (the old way that we had in ECC) was always nice and simple like "filter MKPF for the Posting date, collect all the Material docs, pass on the same to MSEG and voila you have all the item level details for a given posting date". You can play around these table joins more intuitively to create any report. Why would some one try to mess up with this familiarity?

There is a real good reason. Columnar Data Storage is REAL REAL fast, its not 1x or 2x fast. In my observation it is 100x or 1000x faster in some of the queries that we regularly use for the Business. For instance for one of the query which we used run on the weekends for a procurement report which used to take 6 hours or so in ECC, when we moved to S/4HANA (and little tweaking of the query) it took us only few seconds. It was too good to be true. Upon validation, we were surprised that it is "too good and true".

That led to my curiosity on how the Columnar Data Storage works. Being a tech dummy I had to research for sometime to get the details, I have tried to explain the same in a "Functional Consultant friendly" manner. Please note I could have over simplified the data and examples to make it more understandable.

The Classic Row Data Storage, how it looks like in DB:

Lets consider the following data of Material Document (simplified the no. of columns). The first column here is the Row No.

Fig 1:

When this data gets stored in our classic Row Data Storage, it would be something like the below:

Fig 2:

In a Row stores, its plain and simple, the data is stored one row after another. For simplicity I have made 1 row of Material document details in 1 "Block" in Database, but in reality 1 DB Block would be much bigger (few KBs or even MBs) and would be storing several rows of Material documents continuously.
Lets not bother too much on what a Block is. Its a Database concept, you can consider this as chunk of Data that gets pulled for every IO (Input/Output) operation. So when my program requires data on say Material doc no. 5000000001, it pull all the data in Block 1. If my program requires data on Material doc no. 5000000003, then it still starts from Block 1, since its unable to find, it will discard the Block 1 and move to Block 2 to find, and continues this search till it finds the Block n where the data is.

Lets take a functional requirement to sum up all the "Amount" values of consignment items, this means wherever there is a Special stock K, accumulate the Amount value.

Lets see how the Row store handles this and how many “Blocks” it has to read before coming up with a value. As you can see below with the Row store the system reads all the Blocks from the DB before it calculates the final "Amount" value, like shown in the below fig.

Fig 3:

To explain it a bit, it goes to the first row, goes to the field Special Stock type and checks for “K”, if not, goes to the next row and repeats the cycle. When it finds a “K”, it sums up the “Amount”.

Although this method is simple (at least to explain), this scans the entire table, which could be in Billions. For one of the Retail clients that we were working, the projected Material Documents growth is 9.46 Billion/year, so you can imagine, how such a query would work in real time.

This is how Column Data Storage stores the data:

Fig 1 again:

With the same raw data example that we started with, the column store would look like the below:

Fig 4:

The above fig is more for your visualization that the Blocks in the DB are filled column wise, a more realistic fig would be the below, which is just a transpose of the Fig4.

Fig 5:

Lets take it a bit slow, as I mentioned column store is not very intuitive. Few note worthy points:

Columnar Data Storage fills the DB bocks column wise. When a new Material Document say 5000000007 comes next, the Doc no. would go to Block 1, the Posting Date would go to Block 2...Plant would go to Block 6 etc.
The row nos. will still be tagged to each of the field value (represented the row nos in Red in the above table and in other tables as well). Note this is a very important concept, this tagging of row nos. to the field value connects them together although they are in different block.
Reiterating that the above is a simplified example for easier understanding, in real world we could have millions of Material doc Nos. and the contiguous blocks containing Material doc Nos. could be in 100s.

Compression in Columnar Data Storage:

This is where it gets interesting. As you can see in each of the Blocks in Fig 5, in each of the Blocks there are many duplicate field values. For instance Material document 5000000001 is repeated twice, 5000000002 is repeated thrice in Block 1, Plants are repeated even more in Block 6. This is where the compression kicks in and de-duplicates these field values.

Fig 6:

Its very important to note here, the Row tagging are still on. For instance 5000000001 is still tagged to Row no. 1 and 2.

Its worth reminding ourselves, in SAP most of the transaction data field values are actually either a Master data (like Material no. in above example) or Configuration data (like Plant, S.Loc, UoM, Stock type etc in the above example). So the scope of of compression is very high since these Master data and Config data are very few in nos when compared to transaction data. This is the reason the "Data Foot Print" is less in S/4HANA, when compared to ECC. So when you migrate from ECC to S/4HANA you would require much lesser disk space.

Final piece - How the queries are blazing fast:

It took us sometime to understand how the Columnar Data Storage works, but I hope its worth it. Next comes Querying. Faster Querying is the other big advantage, rather the USP of Columnar Data Storage . Lets see with an example. Lets get back to our functional requirement of "sum up all the Amount values of consignment items" and see how the Columnar Data Storage method fares here.

Fig 7:

Here the system directly goes to Block 8 where the special stocks there and checks for “K” and the Row nos tagged to K. It then goes to Block 12 and sums up all the “Amount” values tagged with those Row nos. Compare this with Fig 7 with Fig 3 (Row Based) where there were multiple read of Blocks from the DB which is very expensive from a performance stand point. Finally it made sense to me how a 6 hour query in SAP ECC could get executed in less than 10 sec in S/4HANA.

The not so good about Columnar Data Storage:

1. As you can see Write/new record inserts are not as good. While in a Row Data Storage a new record insert (like a new Material document creation) is much simpler and has to go and get updated in the next available Block in the DB, in Columnar Data Storage various field values have to get distributed across multiple Blocks. SAP HANA manages this through techniques like Delta Merge (refer: https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/bd9ac728bb57101482b2ebfe243dcd7a.html)

2. Thoughtful Querying required. Lets say when we write a statement like Select * (means all field values) data When Stock type = K, this will try to pull all the field values, and remember these field values are spread across multiple blocks so there would be too many DB reads which will slow down the system again. We have seen real life cases where some bad queries would make S/4HANA much slower than ECC.

Conclusion:

I hope this Blog provided you with a glimpse of what's under the hood for Columnar Data Storage. As most Organizations are moving from ECC to S/4HANA, I feel it is all the more crucial now to understand these intricacies to implement and run the business.

Please share, Like and Comment anything else you want to share or add points.

Adding a Standard field/ custom field to the standard SD Migration cockpit templates.

2024-02-27T18:29:23.747000+01:00

In this blog, we will discuss the step-by-step process to add a Standard field/ custom field to the standard SD Migration cockpit templates.

Eg: While uploading the Open Sales orders Header currency field won’t be there, so to change the currency we can add the currency field to the template and upload. Along with the Currency field, we will add the below fields as well.

Header Data – Shipping type, Currency Key, Your reference.
Item Data - Sales Unit, Item Number of the Underlying PO, Storage Location

Procedure:

Create a Project (Migrate using Staging Tables) to upload Sales orders.

Input Project Name. Search and Select the Migration object SO- Sales order (Only open SO) to upload Sales orders and Save.

2.Goto LTMOM tcode, Select the project created and go to edit mode.

3. Select Source Structures and select Header data on the right screen. Click on highlighted Add Field to add the custom fields in the template.

4.Add the required fields like shown below.

5. Similarly, add other fields to corresponding source structures.

6.Once all the required fields are added, the field mapping is to be performed (The added fields are to be linked to the corresponding target structure fields (FM field)). Goto Field Mapping and on the right side the Target structures will be displayed. Drag the added field from the source structure and map the same to the corresponding field in Target Structure. Follow the same process and link all the added fields.

Note: All the fields which we are adding should be available in the source structure.

Author

M Tharun Kumar

SAP ERP Functionality for EDI Processing: Material Determination for Inbound Orders

2024-03-06T08:54:28.061000+01:00

Creating Sales orders based on EDIFACT ORDERS or X12 850 messages is considered a usual task for SAP SD implementation and support. However, both the SAP and EDI worlds are quite broad and varied, and there are plenty of requirements at the intersection of these worlds, as well as numerous options to meet them. Working as an SD consultant since 2013 and focusing on EDI tasks, I have encountered and implemented various techniques and am now eager to share my knowledge, based on my experience in Consumer Products and Wholesale Distribution areas. I aim to provide a comprehensive view of typical requirements and SAP-standard options, including benefits and drawbacks.

In this post, I want to explore one topic: how to determine the SAP material number based on customer order data during the creation of a sales order.

The material number is essential information for creating a sales order, and during manual processing, a user can determine a number and enter it in the proper field. However, it's not as straightforward for automated sales order creation based on an EDI message. In most cases, customers do not know our material numbers. Let's see what they usually use (and the order will become clear later):

Customer material number (CMIR) - every customer has their own ERP system and therefore their own material number, as well as any other coding created by the customer.
Vendor material number - a customer may consider placing this number on the order. However, it might be related to some outdated, incorrect, or reference material.
EAN/UPC - a barcode and a number used internationally for marking products.

The European Article Number (also known as International Article Number or EAN) is a standard numbering system used in global trade to identify a specific retail product type, in a specific packaging configuration, from a specific manufacturer. The most widely used variant is EAN-13 (13 digits, the last digit is the check digit). The Universal Product Code (UPC) is a standard numbering system mostly used in the USA and related markets. UPC (UPC-A) consists of 12 digits that are uniquely assigned to each trade item. The last digit is the check digit. With the addition of a leading 0, UPC is compatible with EAN.

I can distinguish two approaches depending on industry and company types: Contracts and Catalogues.

Contract means a predefined ordering scope: customer and vendor approve a list of saleable items with identifiers for ordering. The most common way in this case is CMIR, mapping for a certain customer according to the contract. Also, Vendor numbers or EAN might be used, sometimes as additional information. This approach is preferred for FMCG and some DIY markets, for customers with a complicated listing procedure.
Catalogue means a more flexible approach: the vendor publishes a product catalogue with identifiers, and customers send orders using identifiers from the catalogue. Therefore, CMIR is not applicable here, and vendor internal or catalogue numbers or EAN/UPC are used in such cases. This approach is preferable for Trading platforms, Construction as well as some DIY and FMCG working with SMB Retail.

A challenge that must be considered for EAN/UPC numbers: while this number clearly identifies a trading item for the customer, it might be related to several material numbers on the vendor side. E.g., a different SAP number might be used for items packed in 6 or in 12; with regular and seasonal label design; with some promotional co-packed free item or produced in different plants, however, the EAN will be the same, so a special selection/substitution technique must be anticipated.

Let's imagine that our customer ordes an item with EAN 8427324815226, customer number ACME-1521 and vendor number 1521 and includes all this data to the message. Depending on EDI standard it might look like following:

EDIFACT ORDERS

X12 850 Purchase Order

an EDI-provider XML

EDI interchange using the IDOC-based approach is still widely spread in the SAP world, even during the transition to new S/4 systems. SAP standard IDOC processing provides very useful ready-made solutions. There is a segment, E1EDP19 Document Item Object Identification, dedicated to material determination and qualifiers for identifiers in question:

001 Material number used by customer
002 Material number used by vendor
003 International Article Number(EAN)

As result all three examples above are mapped in the same IDOC data as following:

If the SAP standard FM IDOC_INPUT_ORDERS is assigned for processing inbound orders, the sequence of determination steps will be as follows:

SAP material number, Qualf = 002. If the value is wrong, IDOC fails regardles of other qualifiers
CMIR, Qualf = 001. If the value is wrong, the system tries EAN or fails if EAN isn’t provided
EAN, Qualf = 003. If the value is wrong, the IDOC fails

Let's examine this logic in more detail. The FM IDOC_INPUT_ORDERS processes IDOC data into a structure and then creates a sales order through batch processing. As a result, order creation is almost the same as manual entry. Based on this, it's easier to understand the opportunities and limitations of the processing.

First of all, the vendor number is considered. If the value with qualifier 002 exists in the message, the system tries to use this value for the Material field of the sales order. The value will be accepted in two cases: if it's a correct SAP material number or if a material substitution record is created for this value (t-codes VB11, VB12, VB13) and a correct SAP material is provided by the substitution. However, if a correct SAP number is not determined, sales order creation fails regardless of other material information in the IDOC.

At first glance, it looks great for the vendor that a customer sends an SAP number. However, it's my least favorite option, especially if the vendor doesn't use substitution. First of all, the existence of a vendor number blocks the use of CMIR, along with its flexibility and transparency. Moreover, a customer might send a wrong or outdated number, causing the IDOC to fail even if other material identifiers are correct. Additionally, a customer might use a catalog vendor number that corresponds to several SAP numbers on the vendor side. On top of that, it's a headache during the go-live of a new ERP. Coordinating the replacement of outdated vendor numbers with new ones is quite challenging, especially if new materials have been created a couple of weeks before go-live. To sum up, using vendor material numbers is the simplest but not flexible enough approach. To mitigate these drawbacks, I usually use the following methods:

Be prepared to use VB12 for error handling and understand the limitations for CMIR usage.
If the CMIR technique is the preferred approach, but some customers provide only the vendor number, it may be reasonable to map the vendor number to the CMIR segment and process it as CMIR.
If we have reliable CMIR or EAN, it may be reasonable to exclude the vendor number from the logic by changing the IDOC mapping. Vendor material might be stored in the sales text or as E1EDP19 with a custom qualifier to bypass the standard step.
Custom extension of IDOC processing to adjust system logic (though I consider this a last resort).

If the vendor number is not provided (fortunately, as you now understand), the next step is CMIR determination.

SAP standard CMIR determination is based on customer-material info record functionality (transaction codes VD51, VD52, VD53). In the manual sales order creation process, a user may fill in the customer material field, and the material field will be populated if a relevant record exists. Similarly, during IDOC processing, the customer material field is populated by the value from the E1EDP19 Qualf = 001 segment, and then the material might be determined. If no CMIR record is found, IDOC processing moves to the next step, EAN-based determination, which is a flexible and reliable approach.

Also, you can gain additional flexibility by combining the CMIR technique (VD52) with Material Substitution (VB12). Technically, CMIR replaces the customer material number with the so-called "material entered," which is subject to replacement by Material Substitution. So, just remember the correct sequence: VD51 is the first step, followed by VB12.

The CMIR technique is simple, clear, and robust, directly meeting widely spread customer requirements. However, it entails some trade-offs and limitations.

The main trade-off of this approach is the effort required for the maintenance of customer-material info records. However, this might also be an advantage if it reflects contractual conditions and provides the required control of ordered materials.

Another limitation is that validity dates functionality is not provided for CMIR. It's not possible to change material mapping in advance or use different mappings at the same time for different delivery dates. A partial solution to this limitation is combining CMIR with Material Substitution, which supports validity dates. It's possible to keep CMIR unchanged and add date-dependent logic to VB12.

Also, Unit of Measure (UoM) determination isn't supported by CMIR. If a customer sends orders with definite UoMs, it's not an issue, but sometimes more flexible logic is required. In any case, UoM determination is a pretty interesting topic and is worth a separate post.

If Vendor material and Customer material haven't been provided, or if CMIR hasn't been recognized, the third step is applied: EAN-based determination. This step is fairly simple; a value from segment E1EDP19 Qualf = 003 is used as entered material, and the related SAP material might be determined if a Material Substitution record (VB12) exists. Or if the EAN equals the SAP material number, but it's supposed that nobody uses EANs as system material numbers. The most important thing to know is that there is no connection with the Material Master. EANs are usually maintained in a related field of material master records, assigned to certain UoMs. But standard IDOC Orders processing doesn't use this information; only Material Substitution records are considered. There are two important consequences of this. Firstly, extra effort is needed to maintain and keep consistent EANs for order processing and master data EANs. And a more distant consequence is related to outbound messages, like ORDRSP (X12 85), DESADV (X12 856), and INVOIC (X12 810). While Order creation ignores material master data, outbound messages use EAN from the material master only. It may cause an issue if a customer needs the same EAN in ORDERS and in outbound messages.

Let me provide you with some examples to clarify the description provided above. These examples are individual steps, and you can imagine how they work in combination, as previously described

1. Customer material info record

Item 10: E1EDP19 QUALF = 001, IDTNR = ACME-1521

Customer-material info record exists, ACME-1521 is mapped to material number 1521 (VD52):

In this case, material 1521 will be used for order creation.

2. Customer material info record + Material substitution

Item 20: E1EDP19 QUALF = 001, IDTNR = ACME-1531

Customer-material info record exists, ACME-1531 is mapped to material number 1531 (VD52):

Also material substitution record exists and is valid for the delivery date (VB12): 1531 -> 1561

In this case, material 1561 will be used for order creation.

3. Vendor material number

Item 30: E1EDP19 QUALF = 002, IDTNR = 1521

In this case, material 1521 will be directly used for order creation.

4. Reference vendor material number

Item 40: E1EDP19 QUALF = 002, IDTNR = 1500-000

Material substitution record exists and is valid for the delivery date (VB12): 15000-000 -> 1521

In this case, material 1521 will be used for order creation.

5. EAN-based determination

Item 50: E1EDP19 QUALF = 003, IDTNR = 8427324815219

Material substitution record exists and is valid for the delivery date (VB12): 8427324815219 -> 1521

In this case, material 1521 will be used for order creation.

In conclusion, I believe that consultants need a deep understanding of the outcomes and trade-offs of standard techniques. This often helps to meet customer requirements without any development or to reveal complicated scenarios at the early stage of a project.

I hope you find this material informative. Please share your comments and any other interesting techniques in the EDI area.

Acknowledgements and System Overview

Thanks to my colleagues at Capgemini and others who explored this topic with me across numerous projects. Also, thanks to Capgemini for providing me with a sandbox system, which was S4HANA ON PREMISE Release 2022 SP 01 (02/2023) FPS, SAP S/4HANA 2022.

Top 10+1 productivity boosting features that excite the business users of SAP S/4 Hana Sales

2024-03-08T03:01:55.376000+01:00

What this post is about?

Nothing excites the time-crunched business users more than a productivity hack that has the potential and power to make their lives simple & easy by saving them some time and effort. Knowing these features also gives them edge over others as it boosts their performance. Who doesn’t like a performance boost after all!

Having worked with a wide variety of sales business users, I have compiled the below 10+1 features of SAP S/4 Hana Sales, which I call the productivity boosters for business users. They have helped many business users outshine others and I am confident that these can help you as well. Some of these can be more obvious than others and their power is really manifested in practice.

The Features!

I have compiled these features in the form of a FAQ to make it more readable and intuitive.

Q1: I need to create a new sales order with similar data as for an existing sales order. Can I create my new sales order from this existing sales order so that I don’t have to re-enter all the details again? What are the important things to know here?

Ans: Well, it’s an absolute yes. You can create a brand-new sales order “with reference” to an existing sales order. When you create Sales Order “SO-0021” with reference to Sales Order “SO-0011”, the complete data from SO-0011 is copied over to SO-0021. Here are a few important things to know here:

A new sales order can also be created with reference to any of these documents – Enquiry, Quotation, Order, Contract, Scheduled Agreement, Billing Document.
It’s a best practice to create a sales order with reference to Billing Document for creating Return Orders
You can do "Copy" or "Item Selection" for creating the new order. Copy refers to copying all details from the source order. Item Selection allows us to choose the items and quantities into the new order from the source order.
Document flow is maintained for the reference orders.
Remember, while copying from one order to another, Customer Reference is NOT copied.

Q2: I need to update Shipping Point for a bunch of line items in my sales order. Can I make updates on all or multiple line items in a sales order in one step? How? What other data can be updated?

Ans: Yes, and more! You can make changes in one step for all or a set of line items in a sales order. Here is how it can be done:

Select the Items on which you want the change to apply.
Click on More -> Edit -> Fast Change of -> Select here the parameter that want to change, shipping point in this case.

Here are some of the examples of the fields where this can be done:

Reason for Rejection
Delivery Block
Billing Block
Shipping Point
Delivery Date
Delivery Priority
Plant
Route
Cancellation Date

Q3: I find myself toggling between screens looking into customer, material, and order details in separate screens while creating my sales order. Can I jump directly into Customer or Material record from within a Sales Order?

Ans: Absolutely. Customer Master and Material Master are the two main building blocks of a sales order. And you can jump straight into these from within a sales order. Here is how:

Press F6 to jump straight into Customer Master Data
Press F8 to jump straight into Material Master Data

Quick, isn’t it?

Q4: I have a bunch of sales orders and I need to update Plant field for all of them. Can I mass change a certain field in a bunch of sales order together?

Ans: Yes. Transaction VA05 is the friend you need here. VA05 allows you to do a mass change on several orders together. It works for multiple fields like the ones below:

New Plant
New Material
New Price Determination
New Currency
Change Partner

Q5: I created a sales order and I want it to be delivered as part of an existing delivery documents. Can I add my sales order into an existing delivery?

Ans: Yes, that’s possible however, a new sales order can be added to a Delivery only if the Post Goods Issue is not yet done for the delivery.

Follow the path: Menu à Outbound Delivery à Deliver Sales Order

Q6: I created a delivery and need to add a new line item into it. Can I add a new line item into a Delivery Document?

Ans: Yes, that’s possible. This option can be particularly useful when adding packaging materials or material used during shipment in delivery as these materials may not be known in advance at the time of creating the sales order. What’s more, line items can also be deleted in the delivery. However, that’s not a best practice.

Q7: I need to create an invoice out of a delivery however I want to pick a set of items and not all items on the delivery. Can I create an Invoice only for selected items of a delivery? How?

Ans: Yes, use the button Select Lines for selecting the specific line items to be billed out of a delivery.

Q8: Is it feasible to deliver or bill an order immediately? How?

Ans: Yes. This is usually used in Credit/Debit memo processes. Here is how:

Immediate Delivery: Menu -> Sales Document -> Deliver
Immediate Billing: Menu -> Sales Document -> Billing

Q9: For one of my delivery documents more than 1 billing docs have been generated which wasn’t expected. Can I run an analysis to understand why this split happened? How?

Ans: Yes. This can be analyzed in VF02. Here is how:

Input one of the two billing docs
Go to Menu -> Environment -> Split Analysis
Enter the second invoice number and click continue.

Q10: Can I also analyze a delivery split? How?

Ans: Yes. Head to VL10A

Click on Collective Processing Logs
Analyze these logs for your delivery splits.

Note: For the log to be saved, below two settings need to be maintained in advance:

User Parameter to be set. [Transaction SU03]
Field "Display Info" under Background Processing in Shipping Point Definition must be set/checked. [Transaction SPRO]

Bonus Question: I need to verify the revenue account determined in my billing document. Can I analyze this? How?

Ans: When you create a billing document, an accounting document is also created automatically based on the current accounting determination. Go to VF02, enter the billing document, and click on Account Determination to analyze this.

While these features are fairly simple, they are very powerful in practice and are really handy in day-to-day usage of the sales processes. And this is not all. There are many-many more useful and subtle features that can come into play while trying to improve the productivity of our business users. I will probably write a sequel to this post to capture a few more that I have known to be of much help to the business users. For now, I hope you enjoyed reading this post and that it enriched you in some way. I THANK YOU for your time to read this post and wish you the best!

POD & Valuated Stock in Transit Configuration

2024-03-08T13:43:37.939000+01:00

The agenda of this blog is to enable the process of making the COGS (Cost of goods sold) hit at the later stage of delivery i.e once the stock is handed over to the customer.

In order to execute this we are required to make use of concept called Valuated stock in transit where ‘Stock in transit’ refers to the goods that have left the physical plant, but the control of them isn’t transferred to the buyer at the same time. These goods are still in the control of the company that ships the goods and are still part of the valuated stock of that company.

This process where the stock is been transferred to valuated stock in transit is then been used to hit COGS at the time of POD ( Proof of delivery ) by which invoicing can be carried out immediately right after the confirmation from customer on stock received where by invoicing and cogs can be made to hit right after each other.

Change the movement type field in schedule line with ‘687’ from ‘601’ GM del to issue valuated stock in transit. This field helps in transferring the goods to valuated stock in transit instead of hitting the cogs.

Maintain Movement type issue valuated SiT with the movement type which hits COGS (601) so this accounting would be carried out at the time of POD.

While executing the transaction make sure you have activated the customer as POD relevant and maintained the necessary configuration for POD on item categories as well. When enabled POST GOODS ISSUE button at top would have been disabled at the time of creation of delivery where by we are required to go to change mode to post goods issue which creates an accounting document as mentioned below.

And after saving the POD document you can find the COGS been hit in following document which would have been created.

And we can carry out invoicing as we do and document flow is given for reference.

MM-SD SCHEDULE AGREEMENT INTEGRATION

2024-03-19T10:30:40.073000+01:00

MM-SD SCHEDULE AGREEMENT INTEGRATION

A customer scheduling agreement is an outline agreement with the customer containing delivery quantities and dates. These are then entered as schedule lines in a delivery schedule. You can either create schedule lines when you create the scheduling agreement, or you can create them later.

You fulfill a scheduling agreement by creating the deliveries in the schedule as they become due. You process deliveries for a scheduling agreement in exactly the same way as you process a normal delivery. After you have completed the delivery, the system updates the Delivered quantity field in the scheduling agreement item with the delivery quantity.

In this blog, you can find EDI integration of purchasing and sales schedule agreements in the same or different system and the necessary adaptations to automate the process.

Organization Information

Receiver Company

Company Code: 1000
Purchase Organization: 1000
Supplier: 2000000000
Material Number: 10

Sales Company

Company Code: 1001
Sales Organization: ZPRO
Customer: 7000000001
Material Number: 9

1 Customizing

1.1 Define Unloading Point Partner Description is Plant

The system determines relevant sold-to party number based on data in the delivery schedule sent in by customer with Electronic Data Interchange.

SPRO à Sales and Distribution à Sales à Sales Document à Sales Scheduling Agreements with Delivery Schedules à Control EDI Inbound Processing à Execute Sold-to Party Assignment for Release Orders

1.2 Define Special Features for Delivery Schedules

You must define for each sold-to party or combination of sold-to party and unloading point how delivery schedules received through Electronic Data Interchange (EDI) are to be processed.

Note: You must create a record for each sold-to party. The system checks this record for every incoming delivery schedule.

SPRO à Sales and Distribution à Sales à Sales Document à Sales Scheduling Agreements with Delivery Schedules à Control EDI Inbound Processing à Define Special Features for Delivery Schedules

1.3 Assign Company Code

For each EDI partner, you assign the company code (that contains the payable to be posted) to the name for the invoice recipient in the EDI invoice.

Financial Accounting à Accounts Receivable and Accounts Payable à Business Transactions à Incoming Invoices/Credit Memos à EDI à Assign Company Code for EDI Incoming Invoice

1.4 Enter Program Parameters

For each EDI partner and invoice company code, you enter parameters for the content and the procedure, which determine how the EDI invoices are posted in the system.

Financial Accounting à Accounts Receivable and Accounts Payable à Business Transactions à Incoming Invoices/Credit Memos à EDIà Enter Program Parameters for EDI Incoming Invoice

1.5 Assign Tax Codes

For each EDI partner, you assign the tax code defined in the SAP System to the tax type and the tax rate determined by that partner.

Financial Accountingà Accounts Receivable and Accounts Payable à Business Transactionsà Incoming Invoices/Credit Memos à EDIà Assign Tax Codes for EDI Procedures

1.6 EDI Configurations

Transaction Code: WE20

1.6.1 Output Type LPET

Outbound Configuration

Basic Type: DELFOR01

Inbound Configuration

1.6.2 Output Type LAVA

Outbound Customizing

Basic Type: DESADV01

Inbound Customizing

1.6.3 Output Type RD04

Outbound Customizing

Basic Type: INVOIC01

Inbound Customizing

2 Condition Records

2.1 Create Customer-Material Info Record

Transaction Code: VD51

Must 18 characters customer material number.

2.2 Create Output Condition Record for Purchase Schedule Agreement

Transaction Code: MN10

Output Type: LPET

2.3 Create Output Condition Record for Outbound Delivery

Transaction Code: VV21

Output Type: LAVA

2.4 Create Output Condition Record for Billing Document

Transaction Code: VV31

Output Type: RD04

2.5 Master Data

Transaction Code: BP

You must enter Partner Description in step 1.1. purchase schedule agreement into Partner Description.

Note: Must enter supplier number into Acct at cust. (KNVV-EIKTO) field.

3 Process Step

3.1 Create Purchase Schedule Agreement

Transaction Code: ME31L

Agreement Type: LP

3.2 Create Sales Schedule Agreement

Transaction Code: VA31

Agreement Type: LP

3.3 Add new schedule line in Purchase Schedule Agreement

Transaction Code: ME38

When add new schedule line, output which LPET is trigger automatically. After that IDOC which basic type is DELINS is created for output and input.

Note: The system checks M_VLPMA table for matching sales and purchase schedule agreement document.

After this step sales schedule agreement will be update automatically.

3.4 Create Outbound Delivery

Transaction Code: VL01N

When delivery is posted goods issue, LAVA output triggered automatically.

IDOC which is created automatically by the reference of outbound delivery, triggered inbound delivery in the system.

3.5 Create Billing Document

Transaction Code: VF01

Finally, RD04 output is triggered automatically and MM invoice is created automatically screenshot is like below.

Backorder Processing in aATP - SAP S4 HANA

2024-03-21T15:17:09.837000+01:00

Backorder Processing (BOP) involves the bulk handling of orders in batch mode, wherein adjustments to order confirmations are made to align with business priorities and respond to shifts in the demand/supply dynamics within your order fulfillment process.

In the context of aATP BOP, a novel notion of requirement classification is introduced, enabling the confirmation of orders based on predefined criteria. This system comprises five classifications (win, gain, redistribute, fill, and lose), each equipped with a distinct rule governing the prioritization of order confirmations. For instance, the winner and the gainer hold the utmost priorities and retain their confirmed quantities without any reduction, while the loser consistently forfeits all confirmed quantities to any other classification.

Let’s go through the each BOP segment to get a thorough understanding.

Different BOP segments and behavior

---------------------------------------------------------------------------------------------------------------------------------------------

Example Scenario:

Assumption: The “Scope of check” only considers the on hand stock. Not future stocks.

Organization ABC is receiving some purchase order from different customers and they raise sales orders in the below sequence.

Sales Order creation sequence in the model scenario

In accordance with the aforementioned illustration, organization ABC is generating multiple sales orders for its clientele. The first order pertains to a customer with a delivery priority of 3, who is not classified as one of the premier clients of organization ABC.

The second order is attributed to a customer of neutral standing, characterized as a regular and recurrent purchaser. At the point of initiating the sales order, the available on-hand stock is documented at 4000 pieces, considering that 8000 pieces have already been confirmed for the preceding order out of the total inventory of 12000 pieces. Additionally, the complete requisition cannot be confirmed due to the specified quantity for order 2 amounting to 6000 pieces.

Concluding the sequence, the third sales order is allocated to a premium customer. Upon commencement of the sales order, the on-hand stock will be depleted to zero. This is where the back-order processing functionality within aATP comes into play. Subsequently, an examination of how BOP navigates and manages the aforementioned situation shall be conducted.

BOP variant simulation result for the model scenario.

As depicted above, the BOP (Back Order Processing) variant initiates the process by revoking the entire confirmation attributed to customer 01. This action is prompted by the customer's adherence to the LOSE strategy, allowing the unconfirmed quantity to become available for utilization by the WIN, GAIN, and REDISTRIBUTE strategies. In this specific business scenario, customer 03 aligns with the WIN strategy. Consequently, the unconfirmed quantity originally associated with customer 01 is reallocated to customer 03.

Nevertheless, achieving full confirmation for customer 03 remains unattainable, given their requirement of 9000 pieces. The deficit of 1000 pieces can be offset by sourcing from customer 02, characterized by a delivery priority of 02 and an inclination towards the REDISTRIBUTE strategy.

The critical aspect lies in discerning the disparity between LOSE and REDISTRIBUTE strategies within this context. Following the complete un-confirmation of the prior commitment to customer 01, a shortfall of 1000 pieces persists for the fulfillment of customer 03's requirement. This shortfall is addressed through a partial confirmation extended to customer 02.

This elucidates how BOP adeptly manages and automates the resolution of issues arising from incongruities between requirements and demands, a process that traditionally necessitated human intervention.

In order to simplify the understanding process, i have simulated the same business scenario in my system environment and below is the BOP variant simulation result that could observe.

WIN

REDISTRIBUTE

LOSE

---------------------------------------------------------------------------------------------------------------------------------------------

In SAP S/4HANA, the Enhanced Available-to-Promise (aATP) feature provides a range of SAP Fiori applications designed for the automated handling of backorders and the manual authorization of orders for delivery. These applications cater to various business document types, including sales orders and stock transport orders.

Each of the subsequent applications enables you to set up a particular step before initiating backorder processing or to oversee the outcomes of a concluded backorder processing operation:

Configure BOP Segment

This application allows you to establish a set of criteria for selecting priorities in distributing supplies when the demand for materials in sales and stock transport orders surpasses the existing inventory or capacity. Through the utilization of selection and exclusion conditions, along with prioritizes, you can automate the rescheduling and redistribution processes in alignment with your company's strategy. Following this, the Configure BOP Variant application can be employed to create a variant, facilitating the direct execution of the corresponding backorder processing run within the app or through the Schedule BOP Run application. Access to this app is contingent upon the assignment of the Order Fulfillment Manager (R0226) business role to your user account.

Configure Bop Variant

Utilizing this application, you have the capability to establish a variant for backorder processing (BOP), incorporating optional filters and prioritizers. This allows for the automated rescheduling and redistribution of materials in restricted supply. The outcomes of successive backorder processing runs can be viewed in the Monitor BOP Run application.

Configure Custom BOP Sorting

Using this application, you have the capability to generate sequences for prioritizing requirements originating from sales and stock transport documents based on attributes that are not amenable to straightforward alphanumeric sorting, such as customer or sold-to party. In this process, you establish a logical framework for prioritizing requirements, which is subsequently applied in the Configure BOP Segment application and in subsequent backorder processing runs initiated from either the Configure BOP Variant or Schedule BOP Run applications.

Schedule BOP Run & Monitor BOP Run

Using these applications, you can set up and timetable tasks to execute backorder processing (BOP) runs. This involves specifying the technical parameters governing the selection criteria, operational characteristics of the run, and, if necessary, simulative and recurring runs, as well as subsequent update processes and logging. The outcomes of any scheduled run through this app can be monitored in the Monitor BOP Run application.

This concludes this article and the main object of writing this to give you all a high level understanding of Backorder Processing in aATP, SAP S4 HANA. Please do share all your insights.

In the next article, i will be discussing on complete E2E configuration steps for BOP in aATP. Thanks in advance for the time that you spent to read this article.

Why missing milestone button

2024-03-26T15:48:49.905000+01:00

As you can see that I missing the milestone button, could you help me check, thanks.

I can't find in my screen (missing milestone button) like bottom.

LSP Scenario in Transportation: Freight Settlement / Forwarding Settlement Document Posting errors

2024-04-03T10:47:20.608000+02:00

Some of the errors found during the setup & respective solutions:

1. Cannot apply distribution level; cannot distribute costs

Forwarding order is completely independent and does not refer to an order-based transportation requirement (OTR) or delivery-based transportation requirement (DTR). hen you calculate charges, the system cannot distribute costs because there are no order or delivery items in the freight order.

Uncheck the “enable cost determination” in the FSD type(see image below).

Change the “distribution level” setting to “Forwarding Order” in the SPRO>Define Cost Distribution profiles

2. Agreement not found for organizational unit TM_SORG1 and party 17186002

Make sure Soldto/Shipto Party is extended to the TM SalesArea in the BP transaction.

3. Accruals posting failed as posting period is closed

Check & close posting periods using MMPV & MMRV

4. Unable to determine tax country for the billing document in SAP TM

Maintain the country in the shipto/soldto address.

5. Sales area is not defined error

Maintain the default distribution channel & division in the SPRO> “Define General Settings for TM “

6. ‘Billing document creation failed’ during FWSD posting.

Under VOFM, use the appropriate copy routines in the copying requirements.

Finally, posted both the FSD & FWSD to the S4 core system.

I hope this is helpful to the TM consultants & I would like to receive any feedback or comment from you.

Thanks for reading.

_Amar_

SD (Sales and Distribution) MM (Materials Management) SAP S/4HANA Finance FIN Controlling

SAP Transportation Management SAP S/4HANA SAP Supply Chain Management SD Billing SAP Invoice and Goods Receipt Reconciliation MM Invoice Verification MM Purchasing LE (Logistics Execution)

How to add a new field to the VL06O,VL06I, VL06G… screens?

2024-04-03T10:55:12.936000+02:00

This article explains step by step what to do when adding a new field to vlo6*(VL06O, VL06I, VL06G, VL06P, VL06T, VL06F, VL06C, VL06IP, VL06IC, VL06IT, VL06IG, VL06IF) screens

you can check https://me.sap.com/notes/128150

Scenario: let's add the definition of delivery type(VTEXT field)

In transaction code CMOD, choose 'Utilities -> SAP Enhancements

Enter the name of the enhancement 'V50Q0001' and execute

Double click on exit name to display function exits

We have to check if the includes are active

If exits are active, when we click on CMOD components they should appear active as follows. If it does'nt appear active in this way, we can assign

Then we go to SE11 to LIPOV which is the structure where we will add the field

Give database table and in change mode.

Click append structure and give new name.

Double click the component type and add related fields to structure VTEXT

Check that the relevant field is active and saved in the append structure as follows

The field we added comes to VL06O empty

We write the following code block in exit for the definitions to come in

Delivery type definitions come like this

I would be happy to read your thoughts and comments and if there are better ways to fulfil the requirement, please leave them in the comment section below.

Thanks so much

How to Create Outbound Delivery With order reference in SAP VL01N

2024-04-05T16:27:49.370000+02:00

Outbound Delivery Replication in SAP - TCODE- VL01N

1. Introduction

Outbound Delivery in SAP (Systems, Applications, and Products in Data Processing) refers to the process of fulfilling customer orders by shipping goods or products from a company's warehouse or production facility to the customer's specified location. This documentation provides a comprehensive guide to understanding and executing Outbound Delivery processes within SAP.

2. Purpose

The purpose of Outbound Delivery in SAP is to streamline the logistics and shipping operations of a company, ensuring accurate and timely delivery of products to customers. By efficiently managing outbound deliveries, businesses can enhance customer satisfaction, optimize inventory management, and improve overall operational efficiency.

3. Key Features

Creation of Outbound Delivery Orders (ODOs) based on sales orders or stock transport orders.
Packing of goods into delivery packages or handling units.
Generation of delivery documents such as delivery notes and shipping labels.
Integration with transportation management systems for route optimization and carrier selection.
Confirmation of goods issue to update inventory levels.
Monitoring and tracking of delivery status in real-time.

4. Process Flow

The typical process flow for Outbound Delivery in SAP involves the following steps:

Sales Order Creation: Customer orders are received and entered into the SAP system as sales orders.
Outbound Delivery Order Creation: Based on the sales orders, Outbound Delivery Orders (ODOs) are created in SAP. These ODOs contain information such as the items to be shipped, quantities, delivery dates, and customer shipping details.
Packing: Goods are picked from the warehouse shelves or production lines and packed into delivery packages or handling units. The packing process involves assigning materials to specific delivery units and determining packaging materials.
Goods Issue: Once the goods are packed and ready for shipment, a goods issue is posted in SAP to signify the removal of goods from inventory. This updates inventory levels and triggers the billing process.
Delivery Document Printing: Delivery documents such as delivery notes and shipping labels are generated in SAP and printed for inclusion with the shipment.
Shipment Execution: The goods are physically transported to the customer's location using selected carriers or transportation methods.
Delivery Confirmation: Upon successful delivery, the delivery is confirmed in SAP to update the delivery status and trigger subsequent processes such as billing and customer invoicing.

T.code:-

VL01N – With / Without Reference to Sales Order.
VL02N – Single Document Change.
Vl03N – Display Delivery Document.

In the initial Screen of Create Outbound Delivery Need to provide below information.
Shipping Point: Get the shipping point from the shipping tab of sales order line item.
Selection Date : It should be either the material availability date or the system copies the item into the delivery.
Sales Order Number: The sales order number against which the delivery document needs to be created.
From and to Item Number: Line item number of sales order against which needs to be created delivery, if a user does not specify any line item then the system will consider all line items of sales order for delivery creation.

Create outbound delivery without order reference

Then the system will land to the user on Create Delivery Overview screen like the below screenshot.

Picking Tab display

Plant code: Delivery plant
Storage location
Delivery Quantity
UoM
Picked Quantity

The picked quantity is grey out mode that means we have to transfer the order to pick the material.

Transport tab provide information

Transportation Planning date
Transportation Planning status.
Route
Gross weight
Volume

The goods movement tab provides information that which movement type is used for this delivery document.

Select any one line item of the delivery document and click on the item Details button. It will display item data of that line item.

The predecessor data tab provides information about

Reference Document number e.g. Sales order number.
Reference Item: line item number of Sales order number.
Reference Type: Document category.

Click on SAVE button.

Now, the delivery document has been saved with the delivery number.

5. Benefits

Improved order fulfilment accuracy and speed.
Enhanced visibility and traceability of outbound shipments.
Reduction in shipping errors and delays.
Optimal utilization of warehouse resources.
Better customer service and satisfaction.

6. Conclusion

Outbound Delivery in SAP plays a critical role in ensuring the smooth and efficient execution of logistics and shipping operations. By leveraging SAP's robust functionality and integration capabilities, businesses can effectively manage outbound deliveries, meet customer expectations, and drive operational excellence.

How to turn off the delete function in VA02?

2024-04-05T16:29:58.812000+02:00

Scenario: The delete function is active in VA02 for an empty order in the document flow. How can we disable this function for some users

Go to Se38

MV45AF0C

We will write in the following include MV45AF0C_CUA_MODIFIZIEREN

As below, we add exite by giving the user information of which user will not be active

IF SY-UNAME EQ 'TZORLU' and US_STATUS eq 'U'.
    READ TABLE cua_exclude WITH KEY 'LOES' TRANSPORTING NO FIELDS.
    CHECK SY-subrc ne 0.
    append 'LOES' to CUA_EXCLUDE.
  ENDIF.

User TZORLU is still unable to delete a delivery with empty document flow in VA02

Active on other user

I would be happy to read your thoughts and comments and if there are better ways to fulfil the requirement, please leave them in the comment section below.

Thanks so much

SAP ERP Functionality for EDI Processing: UoMs Determination for Inbound Orders

2024-04-10T08:45:50.213000+02:00

Don't ignore Units of measures!

In the previous article on Material determination, I deliberately ignored the requirements and features related to units of measure (UoM). While this topic may seem simple for companies that only use "pieces" in sales orders, most distributors require the flexibility to process at least pieces and boxes. And in some cases, they meet overwhelmingly complicated requirements, such as when "eaches" and "pieces" have different meanings, or when packages must be mapped to different UoMs depending on the customer and material.

It's also important to highlight the specific nature of UoM conversion. Whereas material determination data, as well as partner determination data, clearly relate to Master data, UoM mapping is not as variable and is usually considered as settings. The main outcome of this is that an EDI provider (or EDI VAN in the US) might provide some mapping and processing, which is definitely not applicable for Master Data.

UoMs in SAP Sales and Distribution

Basic UoM determination

The process of handling units of measure (UoM) during the creation of a sales order deserves explanation. Consider the simplest case illustrated below: an IDOC ORDERS containing two items, with quantities of 10 PCE (Piece) and 5 CT (Carton), as shown in the screenshot below (transaction code WE19). The UoM is stored in the field E1EDP01-MENEE.

In the sales order created by this IDOC you will see 10 PC and 5 CAR

And in the VBAP table you can also find ST and KAR as unconverted value for these UoMs.

What's connection between these PCE, PC and ST?

The basic UoM setting are maintained by T-Code CUNI Units of measure , also available in IMG SPRO > SAP NetWeaver > General settings > Check Units of Measurement. This data is stored in T006 Units of Measurement table and some other related tables. As you can see below, unconverted system units KAR and ST are assigned to language-dependent codes CAR and PC, which are visible for user logged in English, as well as language-dependent descriptions.

And drilling down to the UoM record you will find CT and PCE, which were used in the IDOC.

Carton, CAR, KAR, assigned to CT

Piece, PC, ST, assigned to PCE

To sum up, for inbound order processing customers use external codes, called ISO code by SAP, and during IDOC processing SAP internal UoM is determined based on CUNI settings and displayed to user with language-dependent code and description. This step is specific for IDOC ORDERS processing.

Errors during basic UoM determination

Let's explore potential errors that might occur during this UoM determination step.

In the example below, there are KT (Kit) and CG (Card). These UoM codes are recognized by both ASC X12 and EDIFACT standards; however, in the standard installation of SAP ERP, CG isn't listed as an ISO code, and KT, while listed, isn't assigned to any UoM.

This discrepancy causes the IDOC to fail with the same error for both item lines:
"Message No. VG011 ISO unit of measure CG is not assigned (item )"

To resolve this error within the basic determination technique, an ISO code must be created and assigned to a UoM. This highlights a significant limitation of the basic technique: it's impossible to map multiple external codes to a single system UoM. For instance, if customers send EA and PCE while you only want to process PC, you can set up PCE as the ISO code for PC. However, you can't assign EA as an ISO code to the same PC because the field is already occupied by PCE. Below, I'll suggest several ways to handle such cases, using some tricks and advanced techniques to satisfy this common requirement.

UoM check during Sales order creation

For successful Order creation, it's also crucial that the UoM is determined for the material.

The same as during manual sales order creation, a UoM can be applied to the material, if it's defined in MM03 Material master > Additional data > UoM. In the example below, PCE and CAR are determined for the material, but EA is not.

As a result, this UoM isn't allowed during the creation of a sales order.

As the creation of Sales order during IDOC ORDERS processing works as Batch processing, about the same as manual creation, the same error appears during IDOC processing.

Errors during UoM check

Let's examine the errors that occur during UoM determination. For instance, a customer sends EA (Each), which is converted to EA according to CUNI settings. However, EA is not determined for this material in the master record.

This discrepancy causes the IDOC to fail with the same error for manual creation:
Message No. V1384 Sales unit EA is not defined for item 000010

To address this issue directly, the UoM must be determined for the material. However this solution leads to a challenging trade-off: maintaining several UoMs with the same meaning in the system just to meet customer requirements.

Trade-offs and Benefits of Standard UoM Determination

Let me recup the basic technique and its subsequent trade-offs and benefits:

Customers orders goods in pieces using external codes PCE and EA.
By CUNI settings, PCE and EA are converted to PC and EA, accordingly. Within the basic technique, it's not possible to convert both PCE and EA to the internal PC.
Both EA and PC are determined for the material with the same meaning (1 PC = 1 EA)
Sales orders are created using PC for some customers and EA for others.

This approach has its benefits and drawbacks.

The main and, I can say, only drawback is that a multi-UoMs approach must be accepted by the entire organisation. Sales, accounting, logistic execution - all departments must be prepared to handle situations when both PC and EA, both CT and BX, are applicable with the same meaning but for different customers.

However, there are some benefits:

First, it allows for simple and transparent UoM processing by SAP-standard technique
Second, it meets customer requirements for both inbound and outbound transactions. Typically, if a customer sends EA in the sales order, they expect EA in subsequent outbound messages, such as ORDRSP, DESADV, and INVOICE (or, for X12, 855 Purchase Order Acknowledgment, 856 Ship Notice, and 810 Invoice). Sometimes, they also require their UoMs in paper documents and labels. Keeping the customer's UoMs in SAP documents allows direct use for outbound transactions, without special adjustments.
Furthermore, using several UoMs doesn't affect Material Management and Logistics execution processes. Regardless of the Sales UoM used for an order item, the basic UoM is always determined and then used for interchange with other SAP modules.

Unfortunately, even "multi-UoM" approach can't solve all possible cases. For example, customers might send the same UoM with different meaning, or one customer uses a UoM with different meaning. Fortunately, some alternatives and advanced techniques might be applied for such and other sophisticated requirements.

UoM conversion by EDI Service Providers or Middleware Mapping Tool

The first option to handle complicated requirements is located outside the SAP ERP core solution. Typically, all EDI messages are processed through EDI Service Providers, also known as EDI Value-Added Network (EDI VAN) in North America. Unlike SAP ERP, EDI providers actually focused on the message transmission and conversion and have convenient tools for mapping. UoMs can be considered as configuration with a fairly limited range of rules to implement, as opposed to master data like material and partner determination. Following the previous example, an EDI provider might implement a rule to convert inbound EA to PCE, resulting in SAP ERP receiving and processing only PCE. Also, an EDI provider might establish a customer-related rule to convert PCE to EA for outbounds. Another useful trick is to copy the customer UoM to the dedicated item sales text. The EDI provider adds such standard SAP text to IDOC ORDERS, then this text is stored in the sales order and copied through standard sales text techniques to subsequent documents. As SAP ERP includes all texts in outbound messages, this data is available for outbounds, and the EDI provider might use the stored value to send it to the customer.

The advantage of this approach is that it keeps SAP ERP simple and clear. The disadvantage is that it usually takes time to implement a rule on the EDI provider's side, up to 2-6 weeks. And such specific mapping might be provided for free as part of the service contract, or it might require an extra cost for adjustment. However, it's usually cheaper than any development on the SAP ERP side.

Similar conversions can also be implemented on some middleware if it's used in a landscape, such as SAP PI/PO/XI, SAP Integration Suite, or one of the wide range of solutions available on the market. Typically, it's maintained by another team, so the advantages and disadvantages in this case are similar.

UoM determination by Material substitution technique (VB12)

The material substitution technique for EDI ORDERS processing, as detailed in my previous article on Material determination , can also apply to UoM determination. If a material substitution rule is activated and the UoM is unspecified in the message, the UoM from the rule is applied.

Let's see how this technique works based on the most valuable business case: EAN based material determination for goods with multiple retail packaging options.

In the example below material 1521 is linked to two EANs: 8427324815219 for a single item and 8427324815226 for a pack, which is a twinpack.

In retail, these differing EANs enable the sale of both single items and twin packs. On the customer side, these are considered distinct products and counted in EA, leading to orders like:

Item 10: 10 EA of EAN 8427324815219 - ordering 10 single items
Item 20: 10 EA of EAN 8427324815226 - ordering 10 twin packs

In order to process such order following technique might be applied:

Material substitution records for EANs must be created and PAC UoM is assigned to the relevant EAN.

Then a customer UoM has to be excluded from the inbound IDOC, by an EDI provider, a middleware, or by IDOC ALE technique, which will be described in the next section.

As result for the item 10 UoM PC is applied because this is Sales UoM determined in the material master record. And for the item 20, PAC is determined based on material substitution record.

In the example above determination is set based on material level. For more flexibility also customer/material and other reliable determination levels might be applied.

As you can see, this approach might be pretty valuable if it meets some business conditions. However there are some inconvenient limitations, e.g. ignorance of customer UoM.

Converting Data Between Sender and Receiver by ALE for IDOCs

Special thanks to David Knight for introducing this technique to our current project. Prior to this, I addressed such requirements either through the EDI provider or with ABAP extensions.

This feature is a part of IDoc Interface / Application Link Enabling (ALE) functionally which is available for SAP ERP, both ECC and S/4. This technique provides wide range of conversions and editing options for IDOCs and also suitable for EDI processing. Essentially, this technique allows to establish a rule to replace some value to another value for a certain field of IDOC from a specific sender.

The related settings might be find by following way:

t-code SALE > Modelling and Implementing Business Processes > Converting Data Between Sender and Receiver
IMG SPRO > ABAP Platform > Application Server > IDoc Interface / Application Link Enabling (ALE) > Converting Data Between Sender and Receiver > Converting Data Between Sender and Receiver
Direct access using t-codes:
- BD62 - Define Segment Conversion Rule
- BD79 - Maintain IDoc Conversion Rules
- BD55 - Maintain IDoc Conversion

Let's see how it works base on the following example:

A customer places an order using UoM BX (box, crate), which has to be converted to CAR (Carton), but this UoM is already assigned to ISO code CT. Without additional settings BX fails with an error ISO unit of measure BX is not assigned (item ).

By following configuration, the rule for conversion BX to CT might be added, as result BX will be processed as required.

Create a new rule title: BD62 - Define Segment Conversion Rule
Create a name and short description of the rule and assign to related IDOC segment

Conversion rule: Z_UOM_CONVERSION_1
Description: UoM conversion for Inbound sales ORDER
IDOC segment name: E1EDP01

Define conversion: BD79 - Maintain IDoc Conversion Rules

Chose Maintain for the conversion rule created above

Select and drill-down to the field MENEE

Select Convert sender fields radio button, add field MENEE to "Sender fld"
Drill down to Conditions, add a record to convert BX to CT (watch out, source value is in the right field, target is in the left field)
Set up defaults: select Copy sender field and define Sender field MENEE

As a result BX value will be converted to CT while all another values will keep unconverted.

Assign created rule to required interchange: BD55 - Maintain IDoc Conversion

Select required message type on the first screen.

Add a record for required interchange. Sender and receiver data are set according to converted IDOC data and assigned to the segment E1EDP01, and conversion rule Z_UOM_CONVERSION_1 created above.

As a result, the conversion rule will be applied to every IDOC that meets conditions described. In this example, sender is set as an LS Logical system, which aligns with the strategy of creating a single LS partner for the EDI provider in WE20 Partner profiles. Consequently, all orders received through this provider will utilize this partner record, and the conversion rule will be applied to all relevant customers. Alternatively, if the KU Customer partner profile is established for every single customer, the created rule might be assigned to one or several customers, with other rules applied to different customers. The second option provides greater flexibility but requires more maintenance effort.

Let's discover conversion example:

According to the conversion rule, BX is converted to CT at the preliminary step of IDOC processing and, as a result, CT is visible in the saved IDOC.

Conversion using IDoc / ALE functionally is widely applicable and flexible, capable of incorporating complex rules and extensions.. However it's pretty far from well known business related transactions, requiring intricate maintenance and lacking transparency for key users.

In conclusion, I need to admit that not all customer or business requirements can be addressed by the techniques mentioned above. I such cases, custom development becomes a necessary last resort. Nonetheless, I hope that a thorough understanding of SAP’s standard features can help minimize unnecessary development, which is often more complex and costly over the system’s lifecycle."

UoMs in Other SAP Modules

One might hope that SAP ERP utilizes a consistent logic for handling messages across all its applications. Ideally, such a holistic approach would simplify processes, but, unfortunately, this is not the case. The logic described earlier, where an external code in an IDOC is mapped to an internal code, applies specifically to Sales and Distribution applications. However, expecting the same behavior from other SAP modules could lead to misunderstandings. Let's delve deeper into this topic.

IDOCs, widely used for external interchange, actually based on "ISO code" approach. For instance, basic types like ORDERS05 and INVOIC02 utilize the same segment type E1EDP01 with a single UoM field, MENEE. Similarly, basic types like DELVRY07 and SHPMNT06 use segment E1EDL24, fields VRKME and MEINS, and basic type DESADV01 use E1EDP09-VRKME. For inbound messages based on these types an ISO code, e.g. PCE, is required, and for outbound messages, the ISO-code is filled by the system. However let's learn a couple of examples with a different approach, more closely related to Warehouse Management System (WMS) or 3PL integration rather than traditional trading interchange.

One such example is MBGMCR03 Post Goods Movements with MB_CREATE_GOODS_MOVEMENT. This message aligns with the BAPI BAPI_GOODSMVT_CREATE, and contains two fields for UoM in the item segment E1BP2017_GM_ITEM_CREATE:

ENTRY_UOM for the system code, e.g., PC.
ENTRY_UOM_ISO for ISO code determined in CUNI, e.g. PCE

Another case that initially caught me by surprise, and significantly drew my attention to this topic, involves WMMBID02. This IDOC type, used for stock movements from external systems, contains the segment E1MBXYI, which only has one field for the system code, ERFME (e.g., PC), without a corresponding ISO code field.

Within the SAP environment, this discrepancy typically doesn't cause issues, as both the sending and receiving functionalities are designed to process the required data format. It’s often overlooked that the nature of fields can differ; for example, if EA is assigned as both the system code and the ISO code, neither users nor counterparties may notice that SHPCON and WMMBXY use different data types. However, unexpected system behavior can sometimes lead to surprises.

This became apparent during one of my projects where we set up a series of messages for interchange with a Third-Party Logistics (3PL) provider. We meticulously prepared DESADV based on DELVRY06 and SHPCON based on DELVRY03, then implemented WMINVE, ACC_DOCUMENT, ORDERS, and WMMBXY. The primary UoM for interchange was BX (box), assigned as both the system code and the ISO code. In the rare situations where a box was broken down, the piece UoM was used and, for all messages, was described and tested as PCE. WMMBXY was one of the last messages tested, and the development team on the 3PL side, adjusting their non-SAP system, applied the same logic to WMMBXY. Smoke testing with BXs was successful. However, during User Acceptance Testing, a scenario failed because SAP sent PC in WMMBXY, while PCE was expected! Explaining to external developers why “our SAP” couldn’t use the same UoM for every message, and agreeing on a CR with project managers during the UAT phase, was not straightforward.

Acknowledgements and System Overview

Thanks to my colleagues at Capgemini and others who explored this topic with me across numerous projects. Also, thanks to Capgemini for providing me with a sandbox system, which was used for investigations, creation of test examples, and preparing screenshots. The sandbox was SAP S/4HANA 2022 (S4HANA ON PREMISE Release 2022 SP 01 (02/2023) FPS).

Appendix: The Zoo of Units of Measure in EDI Projects

In my EDI projects, I've encountered a wide variety of units of measure (UoMs), far exceeding the range preinstalled in SAP ERP settings. To fully grasp this diversity's origins and compare it with SAP's methodology, it's essential to understand the frameworks governing the EDI world.

There are two main framework standards in EDI world for trading messages: the global UN EDIFACT and ASC X12, which is dominating in North America. Both standards include comprehensive code lists for UoMs.

UN EDIFACT

UN EDIFACT: this standard defines a QTY Quantity segment, containing the 6411 Measurement unit code element . Instead of providing its own UoM list, UN EDIFACT references UN/ECE Recommendation 20, Codes for units of measurement used in International Trade , a global standard for units of measurement in international trade developed by The United Nations Economic Commission for Europe.

Sales units defining quantity of goods belong to "Level 3 – informative units omitted from the normative annex, Annex I, but found in the informative annexes, Annex II and Annex III", and are listed in Annex II/III. Also some of them also relevant to UN/ECE Recommendation 21, Codes for Passengers, Types of Cargo, Packages and Packaging Materials . For example, BX box, CT carton and PK pack are considered as a part of Recommendation 21, and included into Recommendation 20 as informative units. However as Sales units and type of packaging are different entities for SAP ERP data model, I suppose Recommendation 20 is more relevant for understanding of quantity UoMs. UoMs listed in Rec 20 might have length 2 or 3 characters, while all the listed in Rec 21 have length 2 characters. Also, based on my experience, I can conclude, that all the UoMs which are relevant for sales order quantity, are 2 characters long.

ASC X12

The Accredited Standards Committee X12 (also known as ASC X12) is chartered by the American National Standards Institute (ANSI) and have developed and maintained the X12 Electronic data interchange (EDI) standard.
This standard defines an element 355 Unit or Basis for Measurement Code which is widely used within different messages. Starting form 325 UoMs according to the release 2010 published in 1987, the current 8050 release (2024) enlists 927 UoMs. All the UoMs codes related to this element are 2-characters long.

SAP UoMs

As it was described above, there are two UoM coding entities in the SAP ERP. So called ISO code is a list of external codes which might be assigned to internal ones. Internal code is a list of UoMs which might be assigned to countable items, and this code is represented as an unconverted technical code, invisible for users and as language-dependent name.

Frankly speaking I haven't find what was a source of the SAP UoM code systems, please add your comment if you know this. In general, we need to consider that SAP codes sometimes match EDIFACT or X12, but might be unique.

I've collected some remarkable examples for you:

EA means Each for X12, EDIFACT Rec 20, and for SAP ISO, SAP unconverted and converted to English
BX means Box for X12, EDIFACT Rec 20 and Rec 21 and SAP ISO, although named Crate
CT means Carton for X12, EDIFACT Rec 20 and Rec 21 and SAP ISO
PC means Piece for X12 and SAP converted to English, however means Parcel for EDIFACT Rec 21 and not listed for Rec 200
PCE means Piece for SAP ISO only, not listed in other standards
KG means Kilogram for X12 and SAP unconverted and converted to English, while for EDIFACT Rec 20 and Rec 21 and SAP ISO it means Keg
ST means Set for X12, Sheet for EDIFACT Rec 20 and Rec 21 and SAP ISO and Piece (Stuk) for SAP unconverted

SAP Community - SD (Sales and Distribution)

SAP BRIM Subscription Order Management (SOM)

Encryption & Masking in SAP - key points

ODN (Official Document Number) configuration settings for India (SD/MM/FI) for GST

Flexible Workflow for Sales for Public Cloud - Complete Guide

Sales Flexible Workflow in SAP S/4HANA Public Cloud - Complete Guide.

Introduction

Blog Agenda:

Flexible Workflow for Sales:

1- Sales Flexible Workflow Introduction for Public Cloud:

2- Environment Setup For Public Cloud:

3- User and Role Authorization:

4- Cloud BAdI Overview for Manage Sales Document Workflows:

More Examples:

Code Reference: Public Cloud 2308 BAdI. Show Sample Code

5- Setup Flexible Workflow for Sales:

6- Testing Scenarios:

7- Useful Apps:

8- Issue & Solution:

9- Conclusion

How to Hide Sub-items of BoM Items in Sales Document Output

Background

Prerequisite

Procedure

Related Links

Post M&A considerations, including shared services (Enterprise Business Services).

Role-Based Access to Price Elements in SAP S/4H 2023

Insights on Columnar store for SAP Functional Consultants

Adding a Standard field/ custom field to the standard SD Migration cockpit templates.

SAP ERP Functionality for EDI Processing: Material Determination for Inbound Orders

Acknowledgements and System Overview

Top 10+1 productivity boosting features that excite the business users of SAP S/4 Hana Sales

POD & Valuated Stock in Transit Configuration

MM-SD SCHEDULE AGREEMENT INTEGRATION

MM-SD SCHEDULE AGREEMENT INTEGRATION

1 Customizing

1.1 Define Unloading Point Partner Description is Plant

1.2 Define Special Features for Delivery Schedules

1.3 Assign Company Code

1.4 Enter Program Parameters

1.5 Assign Tax Codes

1.6 EDI Configurations

1.6.1 Output Type LPET

1.6.2 Output Type LAVA

1.6.3 Output Type RD04

2 Condition Records

2.1 Create Customer-Material Info Record

2.2 Create Output Condition Record for Purchase Schedule Agreement

2.3 Create Output Condition Record for Outbound Delivery

2.4 Create Output Condition Record for Billing Document

2.5 Master Data

3 Process Step

3.1 Create Purchase Schedule Agreement

3.2 Create Sales Schedule Agreement

3.3 Add new schedule line in Purchase Schedule Agreement

3.4 Create Outbound Delivery

3.5 Create Billing Document

Backorder Processing in aATP - SAP S4 HANA

Why missing milestone button

LSP Scenario in Transportation: Freight Settlement / Forwarding Settlement Document Posting errors

How to add a new field to the VL06O,VL06I, VL06G… screens?

How to Create Outbound Delivery With order reference in SAP VL01N

How to turn off the delete function in VA02?

SAP ERP Functionality for EDI Processing: UoMs Determination for Inbound Orders

Don't ignore Units of measures!

UoMs in SAP Sales and Distribution

Basic UoM determination

Errors during basic UoM determination

UoM check during Sales order creation

Errors during UoM check

UoM conversion by EDI Service Providers or Middleware Mapping Tool

UoM determination by Material substitution technique (VB12)

Converting Data Between Sender and Receiver by ALE for IDOCs

UoMs in Other SAP Modules

Acknowledgements and System Overview

Appendix: The Zoo of Units of Measure in EDI Projects

UN EDIFACT

ASC X12

SAP UoMs

Code Reference: Public Cloud 2308 BAdI.