SAP Community - SD (Sales and Distribution)

Import Sales Documents - Part 2: How to upload numbers with different separators

2025-05-15T12:11:43.174000+02:00

Dears,

I am glad to introduce you how to upload numbers with different decimal/thousands separators in “Import Sales Documents” apps.

Decimal/Thousands Separator Setting in Excel

Basically, the decimal and thousands separator in excel are using the system separators by default (Path: File/Options/Advanced/Use system separators).

If you want to display the numbers with different separator, you can also uncheck the ‘Use system separators’ option and define your own. For example, you set decimal separator to comma, thousands separator to dot. You will see the number as following in excel (2.38 -> 2,38, 3,456.45 -> 3.456,45).

Notes: Please make sure that the cell format is type of number. The default format is Text.

Limitations in Different Cell Format

There are some limitations due to the design of this app.

Number Value with Number Format

No matter what decimal separator you are using in the excel and in the launch pad user setting, you will preview the number value in the app with dot decimal separator only.

But please be confident that the value will be correctly assigned to the sales document.

Number Value with Text Format

In case you are using the default Text format, currently, we only support dot decimal separator without any thousands separator. For example, if you have a condition value 3,456.45, you must place it in excel cell as 3456.45. Otherwise, you probability will receive ‘Invalid Format’ error after uploading.

Related Information

The Link Collection for Import Sales Documents | SAP Blogs

Import Sales Documents - SAP Help Portal

Exploring SAP ERP: A Complete Guide to Key Modules and Business Processes

2025-05-16T09:37:07.963000+02:00

SAP ERP Modules Explained

Initially, when I coming to know SAP, I had no idea about ERP, MM, SD, FI, etc. So, I took the time to learn these concepts, and that's why I’d like to share what I’ve learned. I believe this will definitely be helpful for understanding how ERP works. SAP ERP is an enterprise resource planning system that integrates core business processes across Organization. This blog covers an overview of SAP ERP core modules and concepts ideal for both beginners and professionals looking to refresh their knowledge.

ERP Module Categories

Technical Modules

Technical modules involve the development of SAP modules, which can be categorized as standard or custom. Standard modules can be extended based on requirements, and custom modules can be developed to meet new requirements. This process includes designing the system architecture.

Functional Modules

Function Modules are between the end user and business which I elaborate in below

Master Data vs Transactional Data

Master Data: This is static data like customer, material, or supplier records.
Transactional Data: This is a dynamic data which changed constantly for every transaction like purchase orders, sales orders, and invoices. For both master and transactional data below is the example and what they record during the process.

Understanding SAP Clients

A Client that Holds the separate system for the different scenario like development, quality, production, sandbox, support, Quality for support and they name it as different as D52, P52 etc. it differs from organization to organization.

Types of SAP Clients:

Production – Live environment
Quality Assurance (QA) – For testing
Development - For developing
Sandbox – For experimentation
Training – For end-user training

SAP Security Roles

Security has complete control over who can access what, and they have the sole authority to make those decisions. For example, developers cannot access every transaction available in SAP Logon they have certain restrictions.

Access Control Can Be Based On:

Company Code
Plant
Sales Organization
Transaction Codes (allowed or denied)
Launchpad Tile (allowed or denied)

Key SAP Modules and What They Do

1️ SAP Financial Accounting (FI)

It captures every financial transaction across and within the organization. It helps manage financial records and supports the business in financial decision making.

General Ledger

It this every crucial part that holds financial information such as Bank statement and balance sheet like database.

Accounts Payable (AP)

It manages the payment for suppliers and records the financial activity between supplier and organization.
It handles credit memos, invoices, and reporting

Accounts Receivable (AR)

It manages the money that comes into the company, for example, customer payments for a car.

Asset Accounting

Fixed asset that used throughout the organization for managing the company example chairs, laptops etc.
The lifecycle of entire Asset Accounting is acquisition, depreciation and Retirement. Acquisition is records the purchase of machinery, lease the building etc., depreciation is calculation decrease period the purchased asset for the company and retirement is disposing the Asset.

Bank Accounting

It helps to Manages bank statements, payments, and reconciliation.

Procure to Pay (P2P):

Procure to Pay (P2P) is an end-to-end business process that begin with purchasing goods and services and ends with vendor payment. It integrates procurement process and finance functions, ensuring purchasing operations and timely supplier payments to record. It starts with a Purchase Requisition, which is a request for goods and services. After that, an order is created and the material is dispatched. Once the item is dispatched, it must be received in the inventory, and the system should be updated with the details of what materials and how many units were received. After that, the invoice is collected, and finally, the payment is processed.

In SAP, P2P is primarily handled through the MM and FI where procurement process is managed and Payments are processed.

2️ SAP Controlling (CO)

It handles overall cost spending of the company that tracks internal costs, internal project, external project cast and monitors company spending etc.

Key Components:

Profit Centre Accounting: It tracks profit of the organization
Cost Centre Accounting: It Monitors departmental expenses
Internal Orders: It tracks cost of the internal project
Product Costing: It calculates the cost of the product.
Profitability Analysis: Analysis the profit based on the region and customer

Record to Report (R2R)

The below image provided the Record to Report (R2R) process in SAP operations. R2R refers to the end-to-end process of recording transactions, closing financial periods, and generating reports for stakeholders. It records the every transaction and report the transaction finally.

It provides a structured approach to capturing the business transaction, Jornal Entries and sub ledger updates, Month end year end closing activities, financial report of balance sheet and tax reports, check accounting accuracy, closing books efficiently, and reporting.

3️ SAP Sales & Distribution (SD)

Sales Distribution it very essential part of sales process it track from sale of the car to billing by the customer.

It initiates with the pre-sales process, which involves inquiries about the product and receiving quotations. After that, the customer decides whether to proceed with the purchase. Once confirmed, a sales order is created. After finalizing contracts and agreements, the process moves to the delivery stage. Required documents are prepared, items are picked from inventory, packed, and shipped to the specified address. Finally, the order is billed based on the invoice, payment is received, and the order is considered dispatched.

Integration Example:

The sales part integrate with both FI and MM part

Sales Order Creation

Checks stock availability in MM
Runs credit checks in FI

4️ SAP Material Management (MM)

It insures the material availability throughout the lifecycle.

Procurement Lifecycle:

Material procurement in SAP MM (Materials Management) encompasses the complete lifecycle of acquiring goods and services from external suppliers, using MM we can manage all procurement activity. SAP MM equips organizations with tools to streamline and manage procurement activities efficiently. Below is a simple steps involved:

Initiating Purchase Requisition (PR) - It is the process that creating purchase requisition as an internal request to procure the goods and services. It can be either manually or automatically based on availability.
Issuing Request for Quotation (RFQ) - If it external an RFQ is generated and sent to selected vendors it helps to prepare RFQ to suppliers.
Evaluating Vendor Quotations
Once vendors respond, quotations are evaluated within SAP MM If it external an RFQ is generated based on some criteria like cost, quality and time taken for delivery.
Creating Purchase Order (PO)
Once vendor selection is completed, a purchase order is created containing all procurement detail such as quantity, pricing, delivery schedule, and payment terms.
Recording Goods Receipt (GR)
Delivery, a goods receipt is entered in SAP MM. This step confirms receipt and automatically updates inventory levels. It records every detail about the goods.
Invoice Verification
Following the Good Receipt, the vendor submits an invoice. SAP MM supports three-way matching invoice, Purchase order, Goods Receipt to validate before forwarding it for payment.
Processing Payments
Verified invoices are handed off to SAP FI for payment processing, ensuring vendors are paid as per agreed terms also records any money balance.
Vendor Performance Evaluation
Visit the vendor’s location to evaluate the quality and safety standards and determine whether to continue working with the vendor in the future.
Maintaining Material Master Data
It has complete data of vendors such as vendor details, and pricing is crucial throughout the procurement process.
Utilizing Reports & Analytics
SAP MM offers powerful reporting tools to track procurement performance and identify the place to optimize and efficient.

Inventory & Physical Stock Management:

Physically goods are stored and managed here.

Source to Pay (S2P):

Source to Pay (S2P) is a process for finding and managing suitable suppliers to purchase goods and services. It involves supplier identification and providing the RFQ. Once bid evaluation is completed, contract negotiation begins, and the requisition is approved. After that, a purchase order (PO) is created, goods receipt (GR) is generated, inventory is updated, and finally, the invoice is verified and payment is processed.

5️ SAP Production Planning (PP)

SAP Production Planning (PP) module is used to help plan manufacturing for sales and distribution of products.

Manufacturing Types:

Repetitive Manufacturing: products stay the same over a long period of time
Discrete Manufacturing: product is customize or change frequently

Key Components:

Bill of Materials (BOM): Complete list of the material and assemblies needed to manufacture a product
Routing: routing used for finished or semi-finished product calculate operation cost for finished product.
Capacity Planning: Used to balance production across different work centre.
Material Requirement Planning (MRP): Ensures material is available, key feature of MRP is that when it run, it will create procurement proposals. It ensures production can happen to meet our demand and it minimize the cost of holding too much unnecessary inventory.

6️ SAP Quality Management (QM)

SAP Quality Management deals with managing quality throughout a company’s processes.

Key Processes:

Quality Inspection: determine if the units inspected meet defined quality requirement.
- Unit quality is measured.
- Result and defect recording
Quality Control: Preventive, Monitoring and corrective actions
Quality Notifications: It involves in Record poor quality of internal or external issues. It can be created anywhere in the product cycle. This includes incoming inspection when a product has been purchased externally and final inspection before sending finished products out to our customers. It measures and monitor the quality against

7️ SAP Plant Maintenance (PM)

SAP Plant maintenance to manage the equipment and infrastructure of the plant.

Inspection: Measures condition of a production area.

Preventive maintenance: Maintains condition of a production area.

Repair: Restore condition of a production area.

8️ SAP Project System (PS)

SAP Project System that enables companies to manage all projects, large or small scale throughout the project lifecycle. It includes project planning, execution and completion.

Internal financed projects – funded by company themselves.

External financed projects – sponsored by clients and are executed to meet client requirement.

Key components of PS:

WBS (Work Breakdown Structure)
- Shows amount of work
- Shows how long.
- Shows cost involved.
Once work breakdown is calculated, we’re able to accurately begin process planning, cost planning, scheduling and date and capacity planning.

9️ SAP Human Capital Management (HCM)

SAP HCM is a comprehensive solution designed to Manage all human resource and all these functions rely on organizational management.

Organizational Management: Where organizational populated, with different areas, position, and employee names.

Employee Administration: Which handle employee address, bank details and tax information.

Time Management: To record attendance, shift management and leave.

Benefits Management: Where companies can create their own unique benifit packages.

Recruitment: Includes Application tracking and reporting.

Learning Management: It helps enable online training and to track the completion of course by employees.

SAP Navigation for End Users

Clients

Different clients = different environments (e.g., 100, 110 etc…)

Transaction Codes (T-Codes)

Shortcut commands for SAP tasks
Ending with:

01: Create
02: Change
03: Display

Starting with:

Y or Z: Custom codes

/n → Open transaction in the same session
/o → Open transaction in a new session

Conclusion: The SAP Advantage – Integration and Efficiency Across Functions

SAP ERP modules are the principal of enterprise systems, integrating various business processes across organization. Whether it's managing FI (Financial Accounting), MM (Material Mangement), SD (Sales and Distribution) Modules and etc. Processes like Source to Pay (S2P), Procure to Pay (P2P), Record to Report (R2R) and Order to cash (O2C) demonstrate the inter connection of strategic and operational activities within an organization. With SAP’s modular approach, businesses can achieve efficiency process the overall lifecycle of the product so and so, accuracy, and transparency across their procurement and finance functions. By understanding the process and how it works throughout the organization, you can make decisions based on the data collected during the process, which increases the performance of the organization.

SAP Embedded TM single journey E2E process along with integration SD-MM-FI-CO-CCM: Part I

2025-05-20T15:36:54.493000+02:00

Small Intro of myself:

Working as Senior SAP SD, Embedded TM & S/4 HANA Service Management consultant. Have worked on ECC, S/4 HANA On-Premise, Hybrid Cloud, Public Cloud & Private Cloud. Having various capacities including Implementation, rollouts, Upgrades, Support & Enhancements in different industry verticals including Pharmaceutical, Manufacturing, Engineering, FMCG, Bio Organics, Electronics, Service, retail, education etc.

Worked on 1 Green Field Rise with SAP Implementation on Global Template, 2 Plant Roll-Outs as a SAP SD Consultant, 2 Company Code Roll-Outs as a Senior SAP SD Consultant & SAP Embedded TM Lead Consultant, 1 Upgradation Project, 1 SAP Audit & 10+ AMS Projects so far.

Certified Rise with SAP S/4 HANA Public Cloud - Sales Implementation 2208, 2302 & 2308
Certified SAP S/4 HANA Sales 2022
Certified SAP S/4 HANA TM 2020
Certified SAP Field Service Management
Certified Application Specialist – SAP S/4 HANA Cloud – Private Edition Implementation with SAP Activate
Certified Application Associate – SAP S/4 HANA Cloud – Public Edition Implementation with SAP Activate

Done Master studies under the course "Masters in ERP with SAP", where I learned 12 different modules in SAP from scratch.

This is the first time I am writing a SAP blog and will try my best. I decided to share with this community, as it can be a good reference if you have to start from scratch or even redesign your process. This document is more focused on Transportation and Integration but it has a nice overview of all touch point / cross-module required for the E2E process flow.

By knowing the length of this E2E process and also to facilitate the lecture, I divided this blog post in 3 parts:

I. - Freight Unit Generation (This post is covering part I)

II. - Transportation Process Execution

III. - Settlements

I hope you enjoy reading as much as I enjoyed writing and I hope that you will like this and it will be helpful for your future engagements. If you like it, I appreciate you rating this blog post.

First, we need to create an Inquiry (It’s an optional step). In SAP S/4 we can create an Inquiry via VA11 transaction code. Maintain information in the below highlighted field based on your configuration setup.

Press enter and below screen will appear.

Maintain Sold-to-Party and press enter, system will fetch the Ship-to-Party from Business Partner. If you have multiple Ship-to-Party maintained in the business partner then system will show pop-up like below from where you can pick/select the correct Ship-to-Party for the respective order.

Maintain details as per the example given below.

Maintain the material along with the quantity.

Save inquiry.

If you want to display the Inquiry, you can access it via VA13 transaction code.

Now, go to VA21 transaction code for creating a Quotation in SAP S/4 and maintain details in the below highlighted fields based on your configuration.

Click on “Create with Reference” button and pass your Inquiry document number to create the Quotation with the reference of Inquiry which you have created for the respective customer & material and then click on “Copy”.

System will copy all the data from Inquiry to the Quotation. Maintain “Customer Reference, Customer Reference Date & Quotation Valid From-To Dates”. Also, from the condition/pricing master data system will pick up the pricing in the Quotation.

Save it.

If you want to display the Quotation then you can do via VA23 transaction code.

Go to transaction code VA01 for creating a Sales Order and maintain the details in the below highlighted fields based on your configuration setup.

Click on “Create with Reference” button and pass your Quotation document number to create the Sales Order with the reference of Quotation which you have created for the respective customer & material and then click on “Copy”.

System will copy all the data from Quotation to the Sales Order. Maintain “Customer Reference & Customer Reference Date.

System has determined the Shipping Condition as “P1 – P&B: Dom. OTR”. Based on my configuration system will trigger/create the FU (Freight Unit) against the Sales Order (Once order is created).

I have maintained the credit card info in the order.

Save it.

If you want to display the Sales Order then you can do via VA03 transaction code.

System has performed the digital payment authorization and generated the Auth Number & Token.

Go to the “TM Status” and there we can find out the SAP-TM Document Flow.

Here we can find out which FU (Freight Unit) system has been generated for the respective sales order.

This is the end of the Part I - Freight Unit Generation. Check here for the Part II - Transportation Process Execution and here is the Part III - Settlements.

Note: Will try to add SAP S/4 HANA Service Management process as well in this blog series as part of Post Sales activities.

If you liked, please, rate this blog. Thank you.

Navdeep Parmar,

Senior SAP SD, Embedded TM, S/4 HANA Service Management Consultant

CMR Creation with Reference: Process Flow in Subsequent Billing Doc Differs with Reference Level

2025-05-26T07:42:36.844000+02:00

You can create credit memo requests with header reference, item reference, or both. The process flow in subsequent billing documents varies according to the level of reference you use.

Item reference, or header and item reference

When you create a credit memo request with item reference, the referenced document will show in the process flow in the subsequent billing document.

Example: An invoice (INV0003130) is referenced on header and item level to create a credit memo request. You can see the invoice in the process flow of the subsequent billing document in the Manage Billing Documents app.

Header reference only

When you create a credit memo request with header reference only, the referenced document will not show in the process flow in the subsequent billing document.

Example: An invoice (INV0003129) is referenced only on header level to create a credit memo request. The invoice is not shown in the process flow of the subsequent billing document in the Manage Billing Documents app.

Note: Although not shown in the process flow (in the Manage Billing Documents app), the preceding invoice (INV0003129) can show in the document flow (in the Display Billing Documents and Change Billing Documents apps). This is because the document flow always exposes the entire related document chain, while the process flow offers a simplified representation of the document chain that focuses on documents central to the responsibilities of the billing clerk.

How to debug an error message during S/4 HANA Billing document creation(VF01)

2025-05-27T08:54:40.176000+02:00

Hi everyone,

Have you ever been stuck during the billing document creation with an error message, and you couldn't debug it?

Let's imagine that you are using transaction VF01, you have entered a SD document, and the system only issues the error message "No billing documents were generated. Please see the log".

This is not enough for you, so you hit the "Log", and system will display the actual error raised.
In this scenario, we have error with Message ID "VF", Message class "017".
If you simply try to add a breakpoint to Message ID "VF", Message class "017" on debugger, system won't stop at program that issued this message.
This is caused by the fact that the Billing errors are stored into table VBFS, instead of using statement MESSAGE, in order to not stop the Billing document creation via batch job, but still shows the user the error to why that SD document was not invoiced.

To debug this message, you can add a breakpoint into include LV60AA98. This include is related to form VBFS_HINZUFUEGEN, called by Billing programs to issue the error on the programs of package VF.
Then, after adding the breakpoint and starting the billing creation again, you can go one step back on the call stack to find the program/logic that have called this include.

In this example, the system have issued VF017 because it failed on the validation of the "Billing status"(VBUK-FKSTK), so it called VBFS_HINZUFUEGEN to store the error.
This error is related to a Copy control routine, but this error is also issued for regular program messages like VF188/VF056(related to billing cancellation error).

If you are adding some non-standard logic to billing document creation, make sure to always store the errors in VBFS via VBFS_HINZUFUEGEN(LV60AA98).
You may also check SAP KBA 2107348 - Whole billing job cancelled due to a message in a single sales document that explains what happens if you issue a MESSAGE during a batch job.

I hope this quick explanation can ease your analysis of the billing errors during debugging!

How to Manage Third-Party and Individual Purchase Order Procurement Processes in SAP SD-MM

2025-05-29T11:05:43.640000+02:00

In today’s customer-centric business environment, organisations must ensure the efficient fulfilment of customer demands, even when products or services are not available in-house. This is where Third-Party Procurement and Individual Purchase Order processes in SAP play a vital role. These functionalities, part of the seamless integration between SAP Sales and Distribution (SD) and Materials Management (MM) modules, enable companies to procure goods directly from external vendors to meet customer requirements without holding inventory.

This blog aims to provide a clear understanding of how SAP handles third-party order processing and individual purchase orders, highlighting the underlying configuration, document flow, and business benefits.

Step 1: Configuration Steps

Maintain Purchase Organisation

Path: SPRO -> Enterprise Structure -> Definition -> Materials Management -> Maintain purchasing organization

Step 2: Assign Purchase Organisation

Path: SPRO -> Enterprise Structure -> Assignment -> Materials Management -> Assign purchasing organisation to company code

Path: SPRO -> Enterprise Structure -> Assignment -> Materials Management -> Assign purchasing organisation to plant

Step 3: Assign Item Categories

Path: SPRO -> Sales and Distribution -> Sales -> Sales Documents -> Sales Document Item -> Assign Item Categories

Step 4: Create a customer Record (Transaction: BP)

You can refer link below and follow the suggested steps to create a BP record.

Business Partner(BP) Complete Configuration Guide in SAP S4 HANA

Step 5: Create Material Master Record (Transaction: MM01)

Maintain the General Item Category group and Item category group data in the sales org. view 2

Step 6: Define Schedule Line Categories

Path: SPRO -> Sales and Distribution -> Sales -> Sales Documents -> Schedule Lines -> Define Schedule Line Categories

Order Type: It enables the automatic generation of a purchase requisition in the background during the creation of a sales order in a third-party process.

Item Category: In the third-party procurement process, the PR is generated automatically in the background. To facilitate this, the system derives and passes the required item category information from the schedule line category to the purchase requisition.

The item category 5 ensures that when MIGO is performed in a third-party scenario with a shipping notification, the system treats it as a dummy goods movement, meaning the stock is not updated in inventory.

Step 7: Define Shipping Points

Path: SPRO -> Materials Management -> Purchasing -> Purchase Order - > Set up STO -> Define shipping points

Step 8: Create Sales Order (Transaction: VA01)

Check for PR Number in Display Sales Order

Step 9: Convert Purchase Request into Purchase Order (Transaction: ME21N)

Check the Sales Document process flow

Step 10: Post Incoming Invoice (Transaction: MIRO)

Individual Purchase Order Process

The IPO process is triggered during sales order creation when a specific item category (e.g., TAB) is assigned. This item category configuration signals the system to create a Purchase Requisition (PR) automatically, linking it to the sales order item. Unlike standard procurement, the goods procured are not stocked for general use - they are tied exclusively to that customer order.

Step 1: Assign Item Categories

Path: SPRO -> Sales and Distribution -> Sales -> Sales Documents -> Sales Document Item -> Assign Item Categories

Step 2: Create Material Master Record (Transaction: MM01)

Maintain the General Item Category group and Item category group data in the sales org. view 2

Step 3: Define Schedule Line Categories

Path: SPRO -> Sales and Distribution -> Sales -> Sales Documents -> Schedule Lines -> Define Schedule Line Categories

Step 4: Create Sales Order (Transaction: VA01)

Check the PR Number in the Display Sales Order

Step 5: Convert PR into PO (Transaction: ME21N)

Refer to step 9 above for more detailed steps

Step 6: Check Stock (Transaction: MMBE)

Step 7: Post Goods Movement (Transaction: MIGO)

Check stock

Step 8: Post Incoming Invoice (Transaction: MIRO)

PO History

Regards,

Leelamohan Mannem

Unlocking the Key Determinations in SAP SD

2025-05-30T09:16:38.474000+02:00

Understanding SAP SD Determinations: The Backbone of Seamless Transactions:
In every SAP SD implementation, determination procedures play a vital role in ensuring accurate and automated processes across sales, delivery, and billing. In this blog, I’ve compiled the most critical determinations—like pricing, tax, route, shipping point, plant, and more—along with configuration steps, key T-codes, and practical error-resolution tips to help consultants and end users alike.

1. Revenue Account Determination = Application +Condition Type+ Chart of Accounts + Sales Organization +Customer Account Assignment Group (In customer master Billing Tab) + Material Account Assignment Group (In material master sales org 2 view) + Account Key

T-code: VKOA

Error: Revenue account posting fails in billing

Cause:

Condition type not assigned to correct account key in V/08.
Maintain missing GL Account for relevant key in VKOA.

2. Pricing Determination = Sales area+ Document pricing procedure in (VOV8) + Customer pricing procedure in (Customer Master sales Tab) + Condition type

T-code: OVKK

Error: Pricing procedure not determined in Sales Order

Cause:

Missing or incorrect assignment in OVKK (Pricing Procedure Determination).
Missing access sequence in pricing condition type (V/06).

3. Tax Determination = Destination country of the Ship to party + Departure country of the Shipping point+ Tax classification for customer master (Billing Tab in CM) + Tax Classification for Material Master (Material Master-Sales org 1 view)

T-code: OVK1

Error: Tax is not calculated, or incorrect tax amount appears in the invoice.
Cause:

Tax classification missing in Customer Master (XD01)
Tax classification missing in Material Master (MM01)

4. Route Determination = Shipping conditions (in customer master shipping tab) + Transport Group (sales general/Plant view in MM) + Destination Zone of the Ship to party + Departure Zone of the Shipping point. T-code: OVL4

Maintain Route Determination

Error: Incorrect or missing route in the sales order.

Cause:

Transportation zone not maintained in Customer Master
Route determination is not configured in OVL4.

5. Plant Determination= While System pulls Plant into the order, firstly it checks at CMIR level. Maintain Plant in T-code VD51

If the plant is maintained there, the plant will be determined into sales document, otherwise system checks for plant at customer Master level.

If the plant is maintained there, plant will be determined into sales document Automatically, otherwise system checks for plant at material master level.

If Plant is not available at material master level also, we must maintain plant manually.

T-code: OVL2

Determines from which plant the goods will be delivered.

Error: The system fails to determine the plant in a sales order.

Cause:

Material Master (MM02 - Sales Org 1 View) lacks plant assignment.
Customer Material Info Record (VD51) missing plant assignment.
Customer Master (XD03 - Sales Area Data) does not have a default plant

6. Shipping Point Determination= Plant+ Shipping Conditions (in Customer master shipping Tab) +Loading Group (sales general/plant view in MM)

T-code: OVL2

Error: Incorrect or missing shipping point in the delivery.
Cause:

Shipping conditions are missing in Customer Master (XD03 - Sales Area Data).
Loading Group missing in Material Master (MM02 - Sales Org 1 View).
Plant-Shipping Point assignment not maintained in OVL2.

7. Storage Location Determination= Storage Conditions (In MM Plant Data/ Storage 1 View) + Plant + Shipping Conditions (Shipping Tab in Customer Master)

T-code: OVL3

Storage location gets determined at delivery level and Maintain Determine storage location should be Checked in Delivery Item Category (OVLP).

Storage location gets Determined based on 3 rules

In OVLK, if Storage location Rule assigned to Delivery Type is MALA, System Considers

Storage Conditions + Shipping Point + Plant

In OVLK, if Storage location Rule assigned to Delivery Type is RETA, System Considers

Storage Conditions + situation + Plant

In OVLK, if Storage location Rule assigned to Delivery Type is MARE, System Considers

Firstly, the System considers MALA to determine storage location, if it is not possible it will choose RETA as Back up Procedure

Determine the correct Storage Location for picking goods.

Error: Storage location is not automatically picked in the delivery.
Cause:

Storage location not maintained in Material Master
Storage location determination missing in OVL3 (Plant & Shipping Point assignment)

8. Delivery Item Category Determination= Delivery Type + Item Category Group +Item Usage + Higher level Item Category.

T-code: 0814

It is used while creating a Delivery Document without Sales order. By Default, there is Standard order type (DL), item category (DLN), schedule line (CP) and Delivery type (LO) available in the system by SAP.

9. Item Category Determination= Sales Document Type +Item Category Group + Item Usage+ Higher Level Item Category.

T-code: VOV4

System Considers Item usage and higher-level Item category in scenarios like

Cross-selling
Material Determination
Free Goods Determination
BOM

The reason being that all the above scenarios have subline items determined into the sales Document and to determine Item category to the subline items system considers item usage and higher-level item category

Error: missing item category in the sales order.
Cause:

Incorrect assignment in VOV4 (Item Category Determination).
Item category group missing in Material Master (MM02 – Sales Org 2 View).

10. Scheduled Line Category Determination= Item category + MRP Type of the material.

T-code: VOV5

Error: Schedule line category missing or incorrect confirmed quantity in sales order.
Cause:

Schedule Line category not mapped in VOV5.
MRP type missing in Material Master (MM02 - MRP 1 View).

11. Delivery Document Determination = it is achieved through Maintaining Delivery type in Corresponding Sales Document Type in VOV8

When a sales order is created, the system checks the assigned delivery type and automatically determines the relevant delivery document in VL01N.

12. Billing Document Determination = it is achieved through Maintaining Billing type in Corresponding Sales Document Type in VOV8

When a sales order is created, the system checks the assigned Billing type and automatically determines the relevant Billing document in VF01.

Conclusion

Determinations in SAP SD automate business processes by ensuring accurate data flow across sales, delivery, and billing, reducing manual effort and errors. They enable seamless integration between sales, logistics, and finance, enhancing efficiency and compliance. Proper configuration ensures smooth transaction execution, improving accuracy and customer satisfaction.

Quantity Contract & Scheduling Agreement in SAP SD

2025-06-13T10:16:09.261000+02:00

Introduction:
In this Blog, we will take a deep dive into Contract Types in SAP SD, covering their significance, configurations, and real-time business applications. In SAP Sales and Distribution (SD), contracts play a crucial role in long-term business agreements between a
company and its customers. SAP SD offers different contract types, each catering to specific business needs. These include:
❖ Quantity Contract.
❖ Scheduling agreement.

Quantity Contract:

Interpretation: It is a long-term agreement between a customer and a company for supplying goods of Particular Quantity within a specific validity period of time.
Business Scenario: Let’s Assume a customer commits to purchase 500 laptops and 200 Desktops from HP in a year, customer places sales order as much as till the target quality is referenced.
Configuration Steps:
Sales organization =HLSO, distribution channel =01, Division =01
Here Sales Document type = CQ.
Define sales document type in VOV8 and assign it to sales area using OVAZ
Item Category =KMN.
Define item category in VOV7 and do item category determination in VOV4 KMN = CQ+NORM
Scheduled lines = CN
Define schedule lines in VOV6 and do schedule Line determination in VOV5 CN = KMN+ND
Create Quantity contract using T-code VA41.

Now Save it.

Create sales order in VA01 with reference to Contract, followed by delivery and Billing.

Click on Create with Reference.

Go to Contract tab and Contract Number and Click on Copy.

Go to VA43 to observe How much quantity is used out of target Quantity

In the Above Screenshot , sales order has been created with 20 quantities for item 10 and an additional 20 quantities for item 20 and the system still allows the creation of sales orders with 30 quantities for item 10 and 10 quantities for item 20. Also, if we observe Overall Status is In Process which implies there still Order Quantity Leftover to create Sales Order’s w.r.to Quantity Contract.

Again, Trying to Create sales order with Reference to Quantity contract.

Now Again Go to VA43 to observe How much quantity is used out of target Quantity Here, we can Observe that Contract is Fully Referenced and Overall Status is Completed.

Go to VA43 and click on Document flow Icon, to see how many sales orders were created against this quantity Contract and their status

As we observe, in the Document there are 2 Sales Orders have been Created as shown above and Overall Quantity Contract Status is Completed, since w.r.to Quantity Contract, Order Quantity have reached the limit.

Scheduled Line Agreement:

Interpretation: Scheduled Line Agreement is an agreement between a customer and an organization for supplying goods with predefined confirmed quantity and delivery dates.

Business Scenario: A customer from Walmart gets into a Scheduling Agreement with Apple for 600 MacBook Pros over the next six months with deliveries of laptops on : 03/25/2025 of 150 quantities with deliveries of laptops on 05/24/2025 of 250 quantities with deliveries of laptops on 07/22/2025 of 200 quantities.

Configuration Steps:

Let’s say, Sales organization =HLSO, distribution channel =01, Division =01

Sales Document type = DS

Define sales document type in VOV8 and assign it to the sales area using OVAZ

Item Category =LPN

Define item category in VOV7 and do item category determination in VOV4 LPN=DS+NORM

Scheduled lines = CN

Defining scheduled lines in VOV6 and do schedule line determination in VOV5

CN=LPN+ND

Assign Delivery Document Type and Billing document Type in VOV8.

Create Scheduling Agreement using T-code VA31 and go to Schedule lines Tab and Maintain Confirmed Quantity and Delivery Dates.

Click on Material.

Go to Schedule Line Tab and Fill the Details as per the Schedule Line Agreement.

After creating a Scheduling Agreement using transaction VA31, you can proceed to create deliveries with reference to the agreement.

When creating deliveries, it is crucial to ensure that the delivery date selected is not earlier than the scheduled line-item dates maintained in the scheduling agreement.
The system will only allow delivery creation based on the confirmed quantities and their respective confirmed delivery dates.

For example, consider the following scheduled delivery dates and quantities:

April 25, 2025 – 4 unit , May 15, 2025 – 3 units , June 01, 2025 – 3 units

If you try to create a delivery with a date earlier than the scheduled line dates, the system will not allow it unless the quantities have already been confirmed.
If you provide a delivery date of May 15, 2025, the system allows you to create a delivery for the April 25 and May 15 schedule lines, assuming the quantities are confirmed and still open.
However, if you select the last confirmed delivery date (e.g., June 01, 2025), the system can allow the creation of a delivery including quantities from earlier confirmed dates (like March and May), assuming they are still open for delivery and not yet fulfilled.

Make sure to give Relevant Schedule lines to create delivery otherwise system throws below Error.

Create Deliveries with Reference to Scheduling Agreement in VL01N.

Now Create the delivery with 1st Schedule Line:

Now Create the delivery with 2nd Schedule Line:

Now Create the delivery with 3rd Schedule Line:

To monitor the status of a Scheduling Agreement and the deliveries created with reference to it, use transaction VA33 and click on Document Flow to view the complete history and status.

After creating the delivery, perform picking for each delivery document using VL02N by entering the picked quantity.

Once picking is completed, execute Post Goods Issue (PGI) to confirm that the goods have left the warehouse.

After PGI, create the billing document using VF01 with reference to the delivery to generate the invoice.

Conclusion:

Quantity/Value Contracts → You create a release order (i.e., sales order) referencing the contract.

Scheduling Agreements → You don’t create separate sales orders; instead, you maintain delivery schedules directly in the scheduling agreement.

How to Force Close Outbound Delivery in SAP After Partial Picking

2025-06-24T06:20:17.389000+02:00

In SAP SD-WM, Outbound Delivery is created when goods are ready to be shipped to a customer against a Sales Order. Normally, all quantities requested are picked, packed, and posted. However, in real-world scenarios, full quantity might not be available (due to stock issues, damage, etc.), and the business may decide to ship only the available quantity and close the delivery.

This process is known as Force Closing an Outbound Delivery — where the remaining unpicked quantity is not expected to be shipped later, and the delivery is closed with only the picked stock.

Step by Step-by-Step Process Explanation

Step 1: Create Sales Order (Transaction: VA01)

Create a Sales Order (e.g., Customer: 26, Qty: 5 EA)

Step 2: Create Outbound Delivery with ref to Sales Order (App: Create Outbound Delivery or Transaction: VL01N)

Reference the Sales Order to create Outbound Delivery (e.g., Delivery No: 80000169)
Delivery Qty: 5 EA

Outbound Delivery Created 80000169.

Step 3: Create Transfer order (partial Pick)

Tcode: LT03
Alternative: From the Outbound delivery screen via the menu:
Subsequent Functions → Create Transfer Order

Enter partial quantity (e.g., 2 EA), and provide Source Bin Details

Click on Yes and then Click on Posting to save the Transfer order

Step 4: Confirm Transfer Order (Transaction: LT12 or navigate from TO Screen)

Confirm the picked qty (e.g., 2 EA)

Step 5: Check Outbound Delivery Status (transaction: VL03N)

Pick status will be updated as Partially Picked

For Partial Qty pick status will be updated as C, confirmed

Step 6: Force Close the Outbound Delivery

Tcode: VL02N
Navigate to delivery and choose:
- Edit: "Copy Picked Quantity as Delivery Quantity"
- This updates:
  - Delivery Qty = Picked Qty (e.g., 2 EA)
  - WM Pick Status = C (Confirmed)

Step 7: Post Goods Issue

Tcode: Still in VL02N, Click Post Goods Issue
The system posts the material movement and updates inventory.

Step 8: Review the Document Flow

Tcode: VL03N → Menu: Document Flow

If you found this guide helpful, don’t miss my other SAP MM WM blogs covering real-world automation, configuration tips, and best practices for procurement, inventory management, and warehouse management.

Click to view other SAP MM Blogs - SAP Community

Regards,

Leelamohan

Step-by-step Configuration of Business Partner in SAP S/4 HANA

2025-07-08T00:07:18.369000+02:00

Configuration Guide: Creating a Business Partner with Custom Roles in SAP S/4HANA

This document provides a detailed, step-by-step configuration guide for creating a new Business Partner (BP) in SAP S/4HANA with custom roles, using the same number for both the Business Partner and Customer.

Overview of Key Terminologies

Business Partner Role Category: Groups similar business partner roles (e.g., Sales, Purchasing, etc.) and can be used for programming or categorization.
Business Partner View: Used to customize the field attributes (mandatory, optional, hidden) on the BP screen.
BP Grouping: Determines the number range for BPs and is essential to synchronize BP and Customer numbers.

Configuration of Business Partner

Step 1: Defining the BP Role Categories

Path: SPRO>> IMG>>Cross Application Components>>SAP Business Partner>>Business Partner>>Basic Settings>>Business Partner Roles>>Define BP Roles - BP Role Categories

Define the BP role category: BP Role Categories are defined for Company Code, Sales, and Purchasing

ZGG000

ZLCU00

ZLCU01

Step 2: Defining Custom BP roles and assigning the BP Role Categories

Path: SPRO>> IMG>>Cross Application Components>>SAP Business Partner>>Business Partner>>Basic Settings>>Business Partner Roles>>Define BP Roles - BP Roles

Define BP Roles

BP roles for each function have been created, and each BP role is assigned to the BP role Category defined in the previous step.

BP Roles Defined:

ZGG000 - General BP Role

ZFCU00 - Assigned with the BP role Category ZLCU00 - Customer Company Code

ZFCU01 - Assigned with the BP role Category ZLCU01- Customer Sales Area

Step 3: Defining Number Ranges for Business Partner

Path : SPRO>> IMG>>Cross Application Components>>SAP Business Partner>>Business Partner>>Basic Settings>> Number Ranges and Groupings - Define Number Ranges.

New Number Range is created.

Note : The External Check box is Unchecked, BP Number will be generated based on the number range interval.

Step 4 : Defining BP Grouping

Path : SPRO>> IMG>>Cross Application Components>>SAP Business Partner>>Business Partner>>Basic Settings>> Number Ranges and Groupings - Define Groupings and Assign Number Ranges.

New BP Grouping is created and Assigned to the number range defined above

Step 5: Define Customer Account Group

Path: SPRO>>IMG>>Financial Accounting>>Accounts Receivable and Accounts Payable>>Customer Accounts>>Master Data>>Preparation for Creating Customer Master Data>> Define Account Groups With screen layout

Customer Account Groups are created for SP, SH, BP, and PY Partner Functions.

Step 6: Define Number Ranges for Customer Account Group

Path: SPRO>>IMG>>Financial Accounting>>Accounts Receivable and Accounts Payable>>Customer Accounts>>Master Data>>Preparation for Creating Customer Master Data>>Create Number Ranges for Customer Accounts

Number Ranges for Customer Account Groups are created, and the External Check Box is selected. The Number for the Customer role (ZFCU00 and ZFCU01) will be the same number determined for the BP role ZGG000.

Note: The Number Ranges of Customer Account Group should be the same as the Number Ranges for Business Partner

Step 7: Assign the Number Range to the Customer Account Group

Assigning the number ranges to the Customer Account Groups

Step 8 : Master Data Synchronization

Assign the Customer Account Group to BP Grouping

Path: SPRO>> IMG>>Cross Application Components>>SAP Business Partner>>Master Data Synchronization>>Customer/Vendor Integration>>Business Partner Settings>>Settings for Customer integration>>Define BP role for Direction Customer to BP

Assign the Number Assignment for Direction BP to the Customer.

Note: The Same Number Check box needs to be checked to have the Same Number in BP and Customer.

Step 9 : Partner Determination

The New Customer Account Groups created should be assigned with the partner Determination procedure.

Path: SPRO>>IMG>>Sales and Distribution>>Basic Functions>>Partner Determination>>Setup Partner Determination- Setup Partner Determination for Customer and Supplier Master

9.1 Define New Partner Determination Procedure

Path: SPRO>>IMG>>Sales and Distribution>>Basic Functions>>Partner Determination>>Setup Partner Determination- Setup Partner Determination for Customer and Supplier Master - Partner Determination Procedure

9.2 Assign Partner Functions to the Partner Determination Procedure

9.3 Assign the Partner Determination procedure to customer Account Group

Configuration of the Business Partner With the Same number for BP and Customer is completed. Now we will create a new BP and check the configurations.

Creation of a Business Partner

Step 1: Select the Transaction BP and click on create Organization. Select the BP Grouping "ZBPG". Provide

The General role for the BP is created, a new entry in the Table BUT000 is created upon successfully saving the BP

Step 2 : Click on the Change Mode in BP Screen and enter the BP Number "2213" and select the role "ZFCU00" to create the customer.

Customer Master is created with the same Number as BP, and the Customer Master table is updated with the company code data and General Data.

KNA1 Table - General Data

KNB1 Table - Company Code Data

CVI_CUST_LINK table is also updated.

Step 3 : Click on the Change Mode in BP Screen and enter the BP Number "2213" and select the role "ZFCU01" to create the customer sales Area Data.

Sales Area Table for the Customer is updated.

Plant Maintenance Integration with FICO,MM,PP, QM,HCM,EHS and other modules

2025-09-01T13:41:22.090000+02:00

Plant maintenance integrates with many of the modules and below are the some of the modules that plant maintenance integrates with:

FICO(Finance and controlling) :-

Below are the integration points of plant maintenance with FICO.
Company Code: - A plant will always be assigned to the company code.
Cost center: - Cost Center is an organizational unit within a controlling area that is used to collect and record costs incurred from business activities.
Investment order: - investment order needs cost budgeting for an order will be done.
Allocation Structure: - In the allocation structure the cost elements will be taken from the CO in which these cost elements will gets reflected is any maintenance order have consumption of materials, Labour cost, 3rd party material procurement etc... which will flow the costs to the FI.
Asset master creation: - When an equipment is being created then the asset will be created with a configuration.
Settlement Of an Order: - The settlement of an order is actually being done for an order because at the cost needs to be settled.
Settlement Profile: - The settlement profile will be assigned to the order type.
Activity Type: - In activity type the price or the cost for labour per hour will be determined by FICO consultant and we need to maintain the activity type in the work center.

PP(Production Planning) :-
Work Center: - In work center the capacity will be determined by the production planning team. Here the capacity refers to the availability of people and resources for maintenance work.
Equipment Master Data: - In equipment master data there is a field work center in the Location in which we need to give the production planning work center and whereas in the organization.
Spare Part Preparation: - For example the spare part cannot be procured externally then the spare part will be produced by the production order and the settlement rule of order will be done to the maintenance order.
Refurbishment of Material:- Refurbishment of material will be done if any material in production needs to be repaired as soon as possible then we will just refurbish the material and replace the material within the machine as it was there before the breakdown.

MM(Material Management):-
Components:- The components that are required for maintenance of machine will be taken from the inventory.
Service Entry Sheet:- To procure the service from external that is the maintenance has to be done for a machine and there is no team that is present in the plant(internal team) then we will just raise purchase requestion from the maintenance order and after it the material management people will procure the service through ML81N."
Split valuation:- Split valuation for a material has to be configured so that we can perform the refurbishment order.
Details of plant:- The details of plant related namely Purchase Organization, Vendor, Supplier, Outline agreement number etc..
Serial Number Profile:- A serial number profile must be configured for the material to enable the creation of equipment for that material.
Goods Issue:- Goods issue needs to be done for the order otherwise the technician cannot perform the maintenance activities that are present in the order.
Goods Receipt:- Goods receipt has to be done for the Internal Refurbishment Order and the settlement will be done for the material.
Material Reservation:- after creating the maintenance order the materials will be reserved in the inventory automatically.
Procurement:- Procuring of non-stock material, service entry sheet through purchase requestion.

Quality Management:-
CatLog Profile:- Catlog profile will be configured by the quality management team and it will be assigned for the equipment , functional location.
Calibration Order:- In calibration order inspection will be done and thereby the equipment can be used or not will be determined by the quality management team.

SD(Sales And Distribution):-
The place where the sales and distribution as well as plant maintenance will gets integrated is in customer service module.

EHS(Environment Health & Safety):-
The integration part of PM with EHS comes only at the product safety, Work permit - while performing any maintenance at the dangerous or hazardous material or equipment's.

FREM(Flexible Real Estate Management):-
Flexible real estate management and plant maintenance both comes under Enterprise Asset Management in SAP S/4 Hana.
Real Estate Object: - Real estate object will be considered as functional location/equipment.
Work order:- Notification and work order management à maintenance requests originating from RE-FX can be turned into PM notifications/ orders but this will be done with the help of CRM.
Service Provider Coordination: - PM order can trigger external services with the help of MM (material management) to work on RE-FX managed asset.

HCM(Human Capital Management):-
Person Responsible:- Here the person can be assigned to the work order , work center, Technical Object, Operations in work order too.

DMS(Document Management System):-
Documents can be uploaded for the technical objects, notifications , work orders etc... for information or to follow the rules to keep the equipment runs smoothly.

The above are some of the modules for which the plant maintenance will integrate with.

Hope its informative and feel free to comment for any improvements or suggestions.

Regards,
Neeraj.

Customer Invoice to Sales Order Reversal Process with Minimal Customizations

2025-09-02T09:41:07.621000+02:00

Backend System – SAP S/4HANA 2020FP02

Business Scenario

There was a scenario where the business generated a large number of incorrect invoices due to faulty automation in the process from sales orders to invoicing. As a result, it became necessary to perform bulk operations to cancel the invoices, reverse the PGIs, delete the deliveries, and reject the associated sales orders. To address this unique situation, a solution was provided with minimal customization.

Bulk Invoice Cancelation

A LSMW was provided to handle the cancellation of the identified invoices. The relevant user was able to upload the necessary invoice data and perform bulk cancellations efficiently.

PGI Reversal

As a solution for the PGI reversal, a custom upload program was developed using the standard BAPI WS_REVERSE_GOODS_ISSUE. Users could upload an Excel file in the required format and execute the program to reverse the PGIs in bulk. The program also included a test run option to help identify any potential issues with the deliveries before performing the actual reversal.

The main reason for developing this custom solution was a specific business requirement: the ability to reverse PGIs based on the posting date, which is not feasible in standard transaction VL09 for bulk processing.

While VL09 allows individual PGI reversals and provides the option to change the reversal date, it does not support bulk processing. Hence, a custom solution was necessary to meet the business requirement for reversing multiple PGIs at once with the ability to specify a reversal date.

Delevery Deletion and Sales Order Rejection

Delivery deletion and sales order rejection can be performed simultaneously using transaction code VKM4. Deliveries that have already been reversed can be deleted through this transaction. On the selection screen, the delivery numbers should be entered in the 'SD Document' field, and the 'Deliveries' checkbox must be selected to ensure proper filtering and execution.

The user can then execute transaction VKM4. On the next screen, the 'Processing Status' checkbox should be selected, and the user should choose the 'Reject' option to proceed with the delivery deletion and sales order rejection.

The user has the option to decide whether to perform both delivery deletion and sales order rejection simultaneously, or to carry out only the delivery deletion. Based on the requirement, if both actions are needed, the user must select a rejection reason from the search help, click the 'Copy' button, and then click 'Save' to complete the process. In this case, the entire sales order will be rejected using the rejection reason specified in VKM4.

On the other hand, if the user's requirement is to delete only the delivery without rejecting the sales order, the 'Reason for Rejection' field should be left empty and no value should be selected from the search help. As with the previous case, the user should then click the 'Copy' button followed by the 'Save' button to complete the delivery deletion process.

Special thanks to the @Chathuranga_Rajapaksha

Use of Settlement Material in SAP S/4HANA Condition Contract

2025-09-05T12:33:30.036000+02:00

Overview

Entering a settlement material in a condition contract is optional. However, in scenarios such as those involving product groups, where multiple materials are assigned to a specific product group, it is more efficient to perform settlement using a “settlement material” rather than settling each individual material. In such cases, specifying a settlement material in the condition contract becomes necessary.

Key Process Consideration

The material will always be transferred from source document to settlement document if you are using a profile of business volume with a split criteria MATNR (material number). When creating a condition contract, you can enter a settlement material that represents a group of products. Then, when you run the final settlement, system uses this single reference instead of listing every product.

If you want system to use the settlement material instead of the actual product from the original document, you must do following additional settings:

# In split criteria for settlement of profile for BV determination change usage control to “1: Is used – Unless Deactivated via process variant”

# Create a new process variant & define a field MATNR in the split criteria and select “1: Do not use as a split criterion” in usage as split criteria”.

Then, create the condition contract and enter the settlement material. define which product group it applies to in business volume selection criteria. Then run the settlement using transactions like WB2R_SC or WB2R_SV. The system will show the settlement material in the final document.

To get the best results make sure your product groups are well set up. Test your setup in a sandbox system to avoid issues. Use clear names for settlement materials so reports are easy to understand. Also, make sure your setup matches how your business tracks volumes and sales.

Using settlement material also helps simplify accounting because you don’t need a separate rule for each product. It makes reporting easier since you can track performance using one reference. You can even automate the selection of settlement materials to save time. And if business handles thousands of products, this feature can really speed things up.

Conclusion

Settlement material is a powerful tool in SAP S/4HANA that can make contract and settlement management much easier. It helps you work faster, stay organized & get clearer insights. With the right setup and testing it can be a big help for both customer and vendor settlements.

Happy Learning!

How to create a new ship-to address and assign it to delivery on creation using exit in ECC?

2025-09-12T15:55:30.426000+02:00

User exit: MV50AFZ1

Routine: userexit_save_document_prepare

DATA: ls_adrc TYPE addr1_data,
ls_adrc_new TYPE addr1_data,
l_h32 TYPE guid_32,
l_handle TYPE szad_field-handle,
l_ag TYPE adrc-addr_group,
l_ret TYPE szad_field-returncode,
l_ref TYPE addr_ref,
l_nadrnr TYPE adrc-addrnumber,
lt_errtab TYPE TABLE OF addr_error WITH DEFAULT KEY.

LOOP AT xvbpa ASSIGNING FIELD-SYMBOL(<fs_vbpa>) WHERE parvw = 'WE'. " Ship-To
"Read current address
SELECT SINGLE * FROM adrc INTO @DATA(wa_adrc)
WHERE addrnumber = @<fs_vbpa>-adrnr.

MOVE-CORRESPONDING wa_adrc TO ls_adrc.
ls_adrc-street = ls_dts-shipaddress-street1.
ls_adrc-str_suppl1 = ls_dts-shipaddress-street2.
ls_adrc-str_suppl2 = ls_dts-shipaddress-street3.
ls_adrc-str_suppl3 = ls_dts-shipaddress-street4.
ls_adrc-city1 = ls_dts-shipaddress-city.
ls_adrc-post_code1 = ls_dts-shipaddress-zip.
ls_adrc-region = ls_dts-shipaddress-state.
ls_adrc-country = ls_dts-shipaddress-country.

TRY.
"Generate 32-char UUID and use first 16 chars as handle
l_h32 = cl_system_uuid=>create_uuid_c32_static( ).
l_handle = l_h32+0(16).

"Insert new address
CALL FUNCTION 'ADDR_INSERT'
EXPORTING
address_data = ls_adrc
address_group = wa_adrc-addr_group
address_handle = l_handle
IMPORTING
address_data = ls_adrc_new
returncode = l_ret
TABLES
error_table = lt_errtab
EXCEPTIONS
OTHERS = 1.

IF l_ret <> 'E'."Valid Address
SELECT SINGLE appl_table appl_field appl_key addr_group owner
FROM adrv
INTO (l_ref-appl_table,l_ref-appl_field,l_ref-appl_key,l_ref-addr_group,l_ref-owner)
WHERE addrnumber = <fs_vbpa>-adrnr.

CALL FUNCTION 'ADDR_NUMBER_GET'
EXPORTING
address_handle = l_handle " Handle used in address creation
address_reference = l_ref " Optional: reference object
IMPORTING
address_number = l_nadrnr
EXCEPTIONS
address_handle_not_exist = 1
internal_error = 2
parameter_error = 3
OTHERS = 4.

IF sy-subrc = 0."Successful New Address number
CALL FUNCTION 'ADDR_MEMORY_SAVE'
EXPORTING
execute_in_update_task = ' '
EXCEPTIONS
address_number_missing = 1
person_number_missing = 2
internal_error = 3
database_error = 4
reference_missing = 5
OTHERS = 6.
IF sy-subrc = 0."Successful save of New Address number
<fs_vbpa>-adrnr = l_nadrnr.
ENDIF.

ENDIF."End of if Successful New Address number

ENDIF."End of if Valid Address
CATCH cx_uuid_error INTO DATA(lx_err).

ENDTRY.
ENDLOOP.

The Ultimate SAP S/4HANA Guide for the Order-to-Cash Process

2025-09-21T19:16:48.969000+02:00

Introduction

Welcome to your end-to-end guide for navigating the sales process in SAP S/4HANA. Whether you're creating your first sales order, configuring the system, or testing a full business process, this document is for you. We will demystify core concepts, provide step-by-step instructions, and explain the "why" behind the "how."

Key Concepts in S/4HANA

SAP Fiori Launchpad: Your modern, role-based entry point to all applications. Instead of memorizing transaction codes, you'll use intuitive tiles to launch your tasks.
Business Role: Your Fiori Launchpad is tailored to your job. A Sales Representative sees different apps than a Warehouse Clerk or an Accounts Receivable Accountant.
Single Source of Truth: S/4HANA's in-memory database provides real-time insights. The data you see in sales is the same data seen in finance and logistics, instantly.

Chapter 1: The Foundation - Master Data

Before any transaction can occur, the system needs to know the "who," "what," and "how." This is the role of master data. It's the static data that is used repeatedly in your business transactions.

1.1. Business Partner (Customer)

In S/4HANA, the classic "Customer Master" is replaced by the Business Partner (BP). A single BP can have multiple roles, such as Customer, Supplier, or Contact Person.

How-To: Create a Customer

App: Open the Manage Business Partner Master Data Fiori app.
Click Create -> Organization.
BP Role: Select FLCU00 - FI Customer to create the financial accounting data. Enter company code, reconciliation account, and payment terms.
Click Save. The system will assign a BP number.
Extend the BP: Re-open the BP you just created. Click Edit. In the "Create in Role" dropdown, select FLCU01 - Customer to add the sales-specific data.
Go to the Sales and Distribution tab. Here you will enter the Sales Organization, Distribution Channel, Division (the Sales Area), as well as key data like Shipping Conditions, Delivery Priority, and Billing information.
Click Save.

1.2. Product (Material Master)

The Product Master (or Material Master) contains all information about a product or service that your company buys, produces, sells, or stores.

How-To: Create a Finished Product

App: Use the Manage Product Master Data Fiori app.
Click Create.
Enter a Product Number (or leave blank for internal numbering), Product Type (e.g., FERT for Finished Good), and a Base Unit of Measure (e.g., EA for Each).
Views: The Product Master is organized into views. For a sellable product, you'll need to create at least the following:

Basic Data: Description, unit of measure, dimensions.
Sales: The delivering plant, tax classifications, and sales unit.
MRP 1-4: Data for production planning, such as MRP Type (e.g., PD for MRP) and Availability Check group. This is crucial for determining product availability during a sales order.
General Plant Data / Storage: Storage conditions and handling information.
Accounting: Valuation Class (which drives G/L account determination) and the price (standard or moving average).

Populate the required fields in each view and click Save.

1.3. Pricing Condition Records

This master data determines the price of a product for a customer. It's the foundation of your pricing strategy.

How-To: Set a Product Price

App: Use the Manage Prices - Sales Fiori app.
Select a Condition Type, such as PR00 for a basic price or K007 for a customer-specific discount.
Enter the Sales Organization and Distribution Channel.
In the table, enter the Product, the Amount (e.g., 100 EUR), and the Unit (e.g., 1 EA).
Set the Validity Period for which this price is active.
Click Save.

Chapter 2: The Sales Order - Heart of the Process

The sales order is the central document in the sales process. It's a contractual agreement between your company and a customer to deliver products or services. Here, we'll see how various configuration elements come together to control the document's behavior.

2.1. Creating a Sales Order

The primary Fiori app for this is a modern equivalent of the classic VA01 transaction.

How-To: Create a Standard Sales Order

App: Open the Create Sales Orders Fiori app.
Order Type: Enter the order type, for example, OR for a Standard Order.
Organizational Data: Enter the Sales Organization, Distribution Channel, and Division.
Header Data:

Enter the Sold-To Party (the customer number). The system will automatically populate related partners like the Ship-To Party.
Enter a Customer Reference number (their PO number).

Item Data:

In the "Items" table, enter the Product number and the Order Quantity.
Press Enter. The system will perform a series of background actions: pricing, availability check, text determination, etc.

Review the details, check the confirmed quantities and dates, and click Save.

2.2. Understanding the "Why": Order Reasons

Concept: An Order Reason is a code that explains why a customer placed an order. This is invaluable for sales analysis and reporting. Was it a result of a marketing campaign? A replacement for a damaged shipment? This information helps you understand your business drivers.

When you create a sales order, you can assign an order reason at the header level, which then applies to all items.

Examples of Standard Order Reasons:

001: Poor quality
002: Transport damage
006: Machine trials
008: Other

How-To: Assign an Order Reason

In the Create Sales Orders app, go to the Sales tab at the header level. You will find the Order Reason field. Use the dropdown to select the appropriate reason.

Consultant's Corner: Customizing Order Reasons

You can define your own Order Reasons to match your business needs.

SAP GUI: Transaction OVAU
SPRO/CBC Path: Sales and Distribution -> Sales -> Sales Documents -> Sales Document Header -> Define Order Reasons

2.3. Controlling Line Items: Item Categories

Concept: The Item Category is one of the most powerful control elements in SD. It is automatically determined by the system based on the Sales Document Type and the material master, and it dictates the behavior of a line item in a sales document.

Key Questions the Item Category Answers:

Is this item relevant for pricing? (e.g., a standard item is, but a free-of-charge item is not).
Is this item relevant for delivery? (e.g., a standard product is, but a text item is not).
Is this item relevant for billing? (e.g., a standard item is, but a free sample might not be).
Does this item consume stock?
Should a schedule line be created for this item?

Common Standard Item Categories:

TAN: Standard Item. Relevant for pricing, delivery, and billing.
TANN: Free of Charge Item. Not relevant for pricing, but is relevant for delivery.
TATX: Text Item. Not relevant for pricing, delivery, or billing. Used for adding notes.
TAD: Service Item. Relevant for pricing and billing, but not for delivery as there is no physical product movement.

Consultant's Corner: Customizing Item Categories

Item categories are highly configurable to support a wide variety of business scenarios.

SAP GUI: Transaction VOV7
SPRO/CBC Path: Sales and Distribution -> Sales -> Sales Documents -> Sales Document Item -> Define Item Categories
Assignment: The system determines the item category using an assignment table. You can view this in transaction VOV4. The path is ... -> Sales Document Item -> Assign Item Categories.

2.4. Ensuring Data Quality: Incompletion Procedures

Concept: An Incompletion Procedure acts as a data quality checklist for your sales documents. You can define critical fields that must be filled in before a document can proceed to the next step in the process. If a mandatory field is missing, the system flags the document as "incomplete" and can block subsequent functions like delivery or billing.

For example, you can configure the system to prevent delivery creation if the customer's PO number is missing from the sales order.

How it Works:

Status Group: First, you define a Status Group which specifies what functions are blocked. For example, a status group might block "Delivery Creation" or "Billing Document Creation."
Incompletion Procedure: Next, you create a procedure where you list the mandatory fields (e.g., table VBAK, field AUGRU for Order Reason).
Assign Status Group: For each field in your procedure, you assign a Status Group. This tells the system what to block if that specific field is empty.
Assign Procedure: Finally, you assign the entire incompletion procedure to a Sales Document Type (for header fields) or an Item Category (for item fields).

Example in Action:

A user creates a sales order but forgets to enter the Payment Terms (VBKD-ZTERM).

The Incompletion Procedure assigned to the sales order type contains this field.
The procedure is configured to block Billing if this field is empty.
When the user saves, a pop-up appears listing the missing data.
The user can save the incomplete document, but when someone later tries to create an invoice, the system will issue an error message stating the sales order is incomplete.

Consultant's Corner: Customizing Incompletion

This is a multi-step configuration process that offers powerful control.

Define Status Groups: SAP GUI OVA0. Path: ... -> Basic Functions -> Log of Incomplete Items -> Define Status Groups.
Define Incompletion Procedures: SAP GUI OVA2. Path: ... -> Basic Functions -> Log of Incomplete Items -> Define Incompletion Procedures. Here you will add the tables, field names, and assign the status groups.
Assign to Document Types/Item Categories: Path: ... -> Assign Incompletion Procedures to the Sales Document Types.

Note: The custom schemas Z1, Z2, ZG, ZN from the source documents would be implemented as new entries in these standard configuration tables.

2.5. Rejecting Unwanted Items: Rejection Reasons

Concept: A customer may decide not to proceed with a specific item in their order after it has been created. Instead of deleting the line, the best practice is to assign a Rejection Reason.

Why Reject instead of Delete?

Traceability: It maintains a record of what was originally requested and why it was cancelled.
Reporting: You can run reports to analyze why items are being rejected (e.g., "Too Expensive," "Long Delivery Time"). This provides valuable feedback to your sales, product, and logistics teams.
System Impact: Assigning a rejection reason automatically nullifies the item. It is no longer considered in MRP (demand planning) and cannot be delivered or billed.

Common Rejection Reasons:

01: Delivery date too long
02: Poor quality
03: Too expensive
04: Competitor has better service

How-To: Reject a Line Item

In the Change Sales Orders (VA02) app, navigate to the line item you wish to reject.
Go to the Reason for Rejection tab.
Select an appropriate reason from the dropdown list.
Click Save. The item will be updated and will no longer be active.

Consultant's Corner: Customizing Rejection Reasons

You can create reasons that are specific to your industry or business.

SAP GUI: Transaction OVAG
SPRO/CBC Path: Sales and Distribution -> Sales -> Sales Documents -> Sales Document Item -> Define Reasons For Rejection

Chapter 3: Availability Check and Delivery Scheduling

Once a sales order is entered, the system must answer two critical questions:

Can we fulfill this order? (Availability Check)
When can the customer expect it? (Delivery Scheduling)

3.1. The Availability Check (ATP)

Concept: The Available-to-Promise (ATP) check is a real-time process that determines if the requested material will be available on the requested date. It doesn't just look at current stock; it's a dynamic calculation that considers:

Current unrestricted stock
Inbound movements (e.g., planned production orders, purchase orders)
Outbound movements (e.g., other sales orders, reservations)

The rules governing this check are defined by the Checking Group in the material master and the Checking Rule from the SD transaction (e.g., 'A' for sales order). Together, they determine the scope of the check.

S/4HANA introduces Advanced ATP (aATP), which offers more sophisticated features like real-time, multi-level checks and intelligent backorder processing.

Backorder Processing: When new stock arrives, a backorder processing run can automatically re-evaluate open sales orders and re-confirm them against the new inventory, potentially improving delivery dates for high-priority customers.

Consultant's Corner: Customizing ATP

Configuring the ATP check is a cross-functional effort involving SD and MM/PP consultants.

Define Checking Groups: SPRO -> ... -> Basic Functions -> Availability Check and Transfer of Requirements -> Availability Check -> Availability Check with ATP Logic or Against Planning -> Define Checking Groups.
Define Checking Rule for Backorders: SAP GUI OMIH. Path: ... -> Determine Rule for Control of Backorder Processing. This is where you assign a checking rule per plant for backorder processing runs.

3.2. Delivery Scheduling

Concept: Delivery Scheduling calculates the actual dates for the entire shipping process. The system performs backward scheduling from the customer's requested delivery date to determine if it's feasible.

It calculates the following key dates:

Goods Issue Date: The day the goods must leave the plant.
Loading Date: When loading must begin.
Material Availability Date: The latest date the material must be available for picking and packing to start.
Transportation Planning Date: When transportation planning must begin.

This calculation depends on several factors:

Transit Time: Time from your plant to the customer (from the Route).
Loading Time: Time to load the truck (from the Shipping Point).
Pick/Pack Time: Time to gather and pack the goods (from the Shipping Point).

Scheduling Control:

By Sales Document Type: You can switch scheduling on or off for an entire document type. For example, you would enable it for a standard order (OR) but disable it for a contract (CQ), as a contract doesn't trigger an immediate delivery.
By Shipping Point: Each shipping point can have its own working hours (via a Factory Calendar) and default times for picking, packing, and loading, making the calculation highly specific to the fulfillment location.

Consultant's Corner: Customizing Scheduling

Activate for Sales Doc Type: SAP GUI OVLY. Path: ... -> Basic Functions -> Delivery Scheduling and Transportation Scheduling -> Define Scheduling By Sales Document Type.
Define for Shipping Point: SAP GUI OVLZ. Path: ... -> Logistics Execution -> Shipping -> Basic Shipping Functions -> Scheduling -> Delivery Scheduling and Transportation Scheduling -> Define Scheduling By Shipping Point.

3.3. Controlling Procurement and Delivery: Schedule Line Categories

Concept: If the Item Category controls the what of a line item, the Schedule Line Category controls the when and how of its fulfillment. For each item in a sales order, there can be one or more schedule lines, each with a date and a confirmed quantity.

The Schedule Line Category determines:

Is this schedule line relevant for delivery?
Does it generate a transfer of requirements to planning (MRP)?
Does it trigger a specific inventory movement type (e.g., 601 for goods issue for a delivery)?
Can it be part of an availability check?

Common Standard Schedule Line Categories:

CP: Standard. Relevant for MRP and delivery.
CN: No MRP, no delivery. Used for items that are not planned or shipped (like services).
DN: Returns. Used in return orders to manage the inbound goods movement.
CB: Individual Purchase Order. This schedule line will automatically trigger the creation of a purchase requisition to procure the goods specifically for this sales order.

Consultant's Corner: Customizing Schedule Line Categories

Define Schedule Line Categories: SAP GUI VOV6. Path: Sales and Distribution -> Sales -> Sales Documents -> Schedule Lines -> Define Schedule Line Categories.
Assignment: The system determines the schedule line category based on the Item Category and the MRP type from the material master. This is configured in SAP GUI VOV5. Path: ... -> Schedule Lines -> Assign Schedule Line Categories.

Chapter 4: Logistics and Fulfillment (LE, EWM, TM)

With a confirmed sales order in hand, the process moves from Sales to Logistics. The goal is to physically pick, pack, and ship the goods to the customer.

4.1. Creating the Outbound Delivery

The outbound delivery document is the starting point for all shipping activities. It contains all the data needed for picking, packing, goods issue, and transportation planning.

How-To: Create an Outbound Delivery

App: Use the Create Outbound Deliveries from Sales Orders Fiori app. This app provides a worklist of sales orders due for shipment.
Enter your Shipping Point and the selection dates.
The system displays a list of open sales order items ready for delivery.
Select the items you want to deliver and click Create Deliveries.
The system creates the outbound delivery document(s).

4.2. Applying Brakes: Delivery Blocks

Based on source document: Définir motif blocage liv.doc

Concept: A Delivery Block is a mechanism to temporarily halt the shipping process for a specific order or even a single schedule line. The block can be set manually by a user or automatically by the system.

Common Reasons for a Delivery Block:

01: For commercial approval
02: Credit limit exceeded (often set automatically)
03: Price not available
06: Political reasons

A delivery block prevents the creation of an outbound delivery document. The block must be removed in the sales order before the logistics process can continue.

How it's Used:

Header Level: Set in the sales order header (in the Billing Document tab), it blocks the entire order.
Schedule Line Level: A block can also be set for a specific schedule line, allowing other parts of the order to be delivered. This is useful if one item is on hold but others are cleared for shipment.

Consultant's Corner: Customizing Delivery Blocks

Define Delivery Blocks: SAP GUI OVLS. Path: Logistics Execution -> Shipping -> Deliveries -> Define Reasons for Blocking in Shipping.
Here you can define the block reasons and specify their impact. For example, you can have a block that stops delivery creation but still allows requirements to be passed to MRP.

4.3. Warehouse and Transportation Processing (EWM & TM)

Once the outbound delivery is created, it flows into the warehouse and transportation systems.

Extended Warehouse Management (EWM):

The outbound delivery triggers the creation of a Warehouse Request in EWM.
This leads to the creation of Warehouse Tasks (e.g., picking tasks).
A warehouse operator, often using an RF scanner, executes the tasks: picking the goods from a storage bin.
The goods are brought to a packing station where they are packed into Handling Units (HUs), like boxes or pallets.
The packed goods are moved to the goods issue area.

Transportation Management (TM):

The outbound delivery creates a Freight Unit in TM.
The planner combines freight units into a Freight Order.
The planner performs carrier selection and tenders the freight order to a shipping company.

4.4. Post Goods Issue (PGI)

This is the final step in the shipping process. Posting the goods issue legally transfers ownership of the goods and has significant financial implications.

Key Impacts of PGI:

Inventory Reduction: The stock of the material is reduced in inventory management (MM).
Financial Posting: A financial journal entry is created automatically:

Credit (-) Inventory Account
Debit (+) Cost of Goods Sold (COGS) Account

Delivery Status Update: The status of the outbound delivery is updated to "Completed."
Billing Due List: The delivery document is now ready for invoicing and will appear on the billing due list.

How-To: Post Goods Issue

PGI can be done from several Fiori apps, including Manage Outbound Deliveries or directly by the EWM system upon confirmation of loading.

Chapter 5: Billing and Financial Integration

The final step in the O2C process is to invoice the customer and receive payment.

5.1. Creating the Customer Invoice

The billing document is created by referencing the outbound delivery (for goods) or the sales order (for services).

How-To: Create an Invoice

App: Use the Create Billing Documents Fiori app.
The app presents a worklist of documents due for billing (the Billing Due List).
Select the deliveries or sales orders you want to invoice.
The system creates the billing documents. You can review them before saving.
Upon saving, the invoice is created.

5.2. The Financial Impact

Saving the billing document triggers another automatic, real-time integration with Finance:

Debit (+) Customer Accounts Receivable (AR) sub-ledger. This means the customer now owes you money.
Credit (-) Sales Revenue Account.
Credit (-) Tax Payable Account.

A corresponding journal entry is posted automatically in the Universal Journal.

5.3. Receiving Customer Payment

The final step is processing the incoming payment from the customer, which clears the open receivable on their account. This is typically handled by the Accounts Receivable department using Fiori apps like Post Incoming Payments.

The Ultimate SAP S/4HANA Test Plan for the Order-to-Cash Process

This test plan provides practical, hands-on exercises to validate the end-to-end O2C process flow and the specific business controls detailed in the guide.

Introduction

Purpose: To provide a structured approach for testing the O2C cycle, ensuring business requirements are met and the system behaves as expected.
Prerequisites: Ensure the required master data (Business Partner, Product, Pricing) has been created. The sample data below can be used as a template.

Test Master Data:

Data Element	Example Value	Description
Business Partner (Customer)	CUST-01	"Global Bike Shop"
Product 1 (Standard)	PROD-STD-01	"Standard Bicycle Frame"
Product 2 (Free)	PROD-FREE-01	"Free Water Bottle"
Price (for PROD-STD-01)	500 EUR per EA	Standard List Price
Shipping Point	SP01
Sales Area	SA01/D1/S1	Sales Org / Dist Channel / Div

Test Scenario 1: Standard Order-to-Cash (Happy Path)

Objective: To validate the core O2C process flow without exceptions.

Test Role: Sales Rep, Warehouse Clerk, Billing Clerk.

Step	Test Step Description	Action to Perform (Fiori App)	Input Data	Expected Result
1.1	Create Sales Order	Create Sales Orders	Type: OR, Sold-To: CUST-01, Product: PROD-STD-01, Qty: 10	Order is saved with a unique number. Confirmed quantity is 10. Net value is 5000 EUR.
1.2	Create Outbound Delivery	Create Outbound Deliveries from Sales Orders	Shipping Point: SP01, Select the sales order from step 1.1	Outbound Delivery document is created with a unique number. Delivery quantity is 10.
1.3	Pick & Pack (Simulated)	Manage Outbound Deliveries	N/A	Statuses for picking and packing can be updated. This step simulates warehouse execution.
1.4	Post Goods Issue	Manage Outbound Deliveries	Select the delivery from step 1.2 and click "Post Goods Issue".	Delivery status changes to "Completed". A material document and an FI/CO document are created. Stock for PROD-STD-01 is reduced by 10.
1.5	Create Invoice	Create Billing Documents	The delivery from step 1.2 should appear in the billing due list.	Billing Document is created. An FI document is created, debiting the customer account and crediting revenue.
1.6	Review Document Flow	Manage Sales Orders	Open the order from step 1.1 and view the Process Flow.	The graphical process flow should show the Sales Order, Delivery, Goods Issue, and Invoice documents, all linked and with a "Completed" status.

Test Scenario 2: Testing Business Process Controls (Exception Paths)

Objective: To validate the specific configurations for data quality and process control.

Step	Test Case	Action to Perform (Fiori App)	Input Data	Expected Result
2.1	Incomplete Order	Create Sales Orders	Enter an order for CUST-01 but do not enter the Customer Reference (PO number).	When you try to save, the system should display an "Incompletion Log" pop-up, warning you that the PO number is missing. It should still allow you to save the incomplete document.
2.2	Order Item Rejection	Change Sales Orders	Create an order with two lines. On line 2, go to the "Reason for Rejection" tab.	Select 03 - Too expensive.
2.3	Delivery Block	Create Sales Orders	On the order header, go to Shipping tab and set Delivery Block to 02 - Credit limit.	The order is saved with the block. When you try to create a delivery in the Create Outbound Deliveries app, this order should not appear in the list of documents due for shipping.
2.4	Free-of-Charge Item	Create Sales Orders	Line 1: PROD-STD-01, Qty 1. Line 2: PROD-FREE-01, Qty 1.	Line 1 should have Item Category TAN and a price of 500 EUR. Line 2 should have Item Category TANN and a price of 0 EUR. Both should be deliverable. When billed, only line 1 should be on the invoice.
2.5	Using an Order Reason	Create Sales Orders	At the order header, go to the Sales tab.	Set the Order Reason to 002 - Transport damage.

Test Scenario 3: ATP and Backorder Scenario

Objective: To test the system's behavior when there is insufficient stock and how it handles new inventory.

Step	Test Step Description	Action to Perform (Fiori App)	Input Data	Expected Result
3.1	Create Order with Stock Shortage	Create Sales Orders	Prerequisite: Ensure available stock for PROD-STD-01 is only 5 EA. Order PROD-STD-01 with a quantity of 15.	The system should create two schedule lines for the item: Line 1 with a confirmed quantity of 5 for today's date. Line 2 with a confirmed quantity of 0 (or 10 for a future date, depending on ATP config).
3.2	Receive New Stock (MM)	Post Goods Receipt for Purchasing Document (or other GR app)	Post a goods receipt for PROD-STD-01 for a quantity of 20.	The available stock for the product is now 25 EA.
3.3	Run Backorder Processing (aATP)	Schedule BOP Run	Create and schedule a run for the relevant material/plant combination.	The BOP run should identify the open sales order from step 3.1. It should re-evaluate the availability and update the order, creating a single schedule line with a confirmed quantity of 15 for today's date.
3.4	Deliver Full Order	Create Outbound Deliveries		You should now be able to create a delivery for the full quantity of 15 EA.

Expiring Price Handling Powered by Joule

2025-11-03T12:42:58.772000+01:00

The Joule capability "Expiring Price Handling" has been released in SAP S/4HANA Cloud Public Edition 2502.3. This blog introduces this feature in detail, so that you can interact with Joule smoothly and manage expiring prices efficiently.

Overview

You can ask Joule to fetch prices (stored as condition records for pricing in sales in the system) that will expire soon. For expiring prices, Joule can help renew them by extending their validity periods and adjusting the condition amounts or ratios according to your requirements. After you confirm to extend the expiring prices, a price renewal background job will be created. You can also check the progress and result of the price renewal job via Joule.

Figure 1

Please check out the following help document and demo for a glimpse.

Feature in Details

Definition of "Expiring Price"

Before using this feature, it's important to understand what qualifies as an "Expiring Price". Joule retrieves prices that expire between the current date and the given date (including both dates) without a successor record. Only records without a successor are considered "Expiring".

Case 1 and 2: Prices without a successor --> considered "expiring".
Case 3: Even if its Valid-To date falls between the current date and the given date, it has a successor with a continuous validity period starting right after its Valid-To date --> not considered "expiring".
Case 4: Already expired prices --> not considered "expiring".

Figure 2

Note that, this feature only retrieves/renews the prices approaching expiration (meaning still valid for the time being), but cannot fetch/renew the prices which are already expired (Case 4 above).

How Are Expiring Prices Renewed?

Instead of updating the original Valid-To date of the expiring price, Joule creates a new continuous validity period for the expiring price (with Valid-From date set to the date one day after the Valid-To date of the expiring price). Optionally, the new validity period could have a new condition amount/ratio. The purpose of this is to keep the existing "Expiring Price" unchanged, but create its successor only.

Do take note that, the new validity being created could possibly overlap with the existing validity that lies in future, such as the Case 2 above. Assume that the gap between the expiring price and its future validity is 9 months long. If we extend the validity period of the expiring price by 1 year, the new validity and existing future validity will overlap for 3 months. In this case, the new validity will overwrite the existing validity during the overlapped period.

Always Start from "Show Expiring Prices"

You can activate the "Expiring Price Handling" feature by talking to Joule with phrases like below:

"Show me prices for sales organization 1710 that expire before December 31, 2025."
"List the prices with condition type PPR0 that are expiring before Dec 31, 2025."
"Are there any prices for condition type PPR0 and sales organization 1010 expiring before December 31, 2025?"

Even if you ask Joule to extend the expiring price directly, you will be redirected to show expiring prices, because the extension/renewal could only be performed on the expiring prices already listed in Joule.

Figure 3

Expiration date is a mandatory for querying expiring prices. If the date is not given, Joule will prompt you to provide one, so that it can proceed to search for the expiring prices.

Figure 4

For best results, include at least one of the following filters in your query. Currently, these are the only fields supported as the filter.

Condition type
Sales organization
Distribution channel
Product
Customer
Customer project ID

Expiration Urgency Level

The expiring prices will be listed and sorted by urgency:

Red: ≤30 days left before expiration
Orange: 31~60 days left before expiration
Green: >60 days left before expiration

Figure 5

Dynamic Grouping

At the time this blog is being written, Joule can display up to 30 prices per message. If more than 30 expiring prices are found, they will be grouped dynamically, for example:

By condition type + sales org. + urgency level.
By condition type + urgency level.
By urgency level only.

This ensures the total number of groups is kept ≤30.

Figure 6

Check Price Renewal Job Log

After clicking "Confirm" to extend prices, a mass creation job will be created in the background to create the new validity periods. You can check progress and result of the renewal job by clicking the "Check Progress" button. The job result is summarized in a card format. You can click "Open in App" to navigate to the "Manage Prices - Sales" app to check the details of the job.

Figure 7

Alternatively, you can also go to "Manage Prices - Sales" app --> click "Monitor Imports and Jobs" at the upper-right corner. --> switch to "Scheduled Jobs" tab. All the previously created jobs are listed, including the mass creation job created from "Manage Prices - Sales" app. Note that the price renewal jobs created via Joule are always named "Price Renewal xxxxxxxxxxxxxx".

Figure 8

Limitations

Instability of Resolving Expiration Date

If you ask Joule to show the prices expiring in N months/days, Joule may occasionally resolve the expiration date incorrectly. This can lead to an inaccurate or empty results. This is because the current LLMs do not inherently have awareness of real-time information.

Thus, we recommend providing specific dates to Joule, such as "Show me prices that are going to expire before 31 Dec, 2025" or "List prices due to expire on 31/03/2026".

Short Request Timeout

There's a short request timeout (only 15 seconds) imposed by Joule on any API call to backend. If you don't provide any filter criteria, you may encounter a timeout.

Figure 9

Therefore, always include at least one of the supported filters while asking Joule to show the expiring prices.

SOLUTION ORDER

2025-11-13T09:44:14.327000+01:00

SAP S/4HANA Public Cloud is an architecturally innovative ERP solution that addresses the need for businesses to integrate their end-to-end processes. One of the critical components offered by this platform is the Solution Order structure, which consolidates multiple business objects under a single operational document. For example, when a technology company sells a new server to its customers, it can combine the server's installation service, annual maintenance contract, and even a custom software integration project under a single Solution Order. This allows all processes to be easily tracked and managed from one central order document.

1 Solution Order Architecture

In SAP S/4HANA Public Cloud, the Solution Order acts as a master document, centrally managing different item categories (e.g., product, service, project, subscription). This structure is designed to support customer-centric, hybrid sales scenarios, in contrast to silo-based order models in traditional systems.

Technically, when a Solution Order master document is created, the system automatically triggers and generates different follow-on documents corresponding to these item categories in the background. For instance:

product item transforms into a Sales Order document, initiating relevant logistics processes (shipping, delivery).
service item triggers a Service Order or Service Notification document, starting field service management processes.
project item links to a Project document, creating work breakdown structures (WBS) and activities within the project management module.
subscription item generates a Subscription Contract document, enabling recurring billing processes.

This approach ensures that all these disparate business objects are linked within the document flow, making the Solution Order master document a single operational monitoring point.

2 Technical Differences from Standard Sales Order

The Solution Order offers a more integrated and dynamic data model compared to the traditional Sales Order structure.

Data Model and Integration: While a standard sales order typically focuses solely on product management (SD) and logistics processes, the Solution Order leverages SAP S/4HANA's unified data model to combine different modules such as SD, Service, Project Systems (PS), and Subscription Billing into a single process. This ensures data consistency and integrity.
API Integration: SAP S/4HANA Public Cloud is developed with an API-first approach. The Solution Order object can be created and managed via OData services from external systems (e.g., CPQ - Configure, Price, Quote - solutions or custom customer portals). This provides a flexible platform for end-to-end process automation.
Billing Processes: While standard sales orders typically generate a single invoice document, the Solution Order can trigger different billing plans with a central billing engine. This allows for managing various billing methods under a single order, such as milestone billing for projects, time-and-materials billing for services, or recurring billing for subscriptions.

3 Advantages and Disadvantages

Advantages

Process Orchestration: Enables different business units (sales, finance, project, service) to collaborate in a unified operational process.
Data Integrity: Provides a single, consistent view of data as all process documents are linked to one master document.
Automation and Scalability: API integration allows for automated document creation and process management with external systems, increasing operational efficiency.

Disadvantages

Structural Complexity: The integrated and multi-module nature of the process may require deeper technical knowledge and system configuration during implementation and adaptation phases.
Configuration Dependency: Due to the Public Cloud's strategy of adopting standard processes, the flexibility of the Solution Order structure depends on predefined business processes. Custom developments (extensibility) might be limited for highly specific or non-standard processes.

The Solution Order in SAP S/4HANA Public Cloud provides a strong foundation for managing the complex and integrated business models required by the digital economy. This structure is a core component of the "Intelligent Enterprise" vision, enabling businesses to enhance customer value by offering integrated solutions rather than merely selling products.

4 Configuration

There are two main customization steps for the solution order. These customizations can be accessed through the following tabs.

Solutions --> Solution Management --> Solution Orders --> Solution Order Management

4.1 Copy Sales Order Type in Solution Orders

With this customization, determination of which sales order document types can be used with reference to a solution order is carried out.

4.2 Copy Item Categories of Sales Items in Solution Orders

With this customization step, it is determined with which order document type and which item category the item category selected in the solution order will be created in the next step.

In this customization, the key fields are the solution order item category and the sales order document type. This means that by assigning two different sales order item categories to a single solution order item category across two different sales order document types, it allows different processes to be executed.

5 Example Process

Within the Manage Solution Orders application, click the New button to navigate to the solution order creation screen.

First, the header information screen appears. On this screen, the customer and the contact person can be selected.

At the item level, a material is entered and in the Item Category column the processes to be followed are selected. Here, a variety of different scenarios can be chosen. The relevant scenarios are as follows:

Rental Item	3rd Party w. SN FoC	FOC MainItmPr. (BOM)
3rd Party with SN	3rd Party w/o SN FoC	Pri. at Subitm (BOM)
3rd Party w/o SN	Bought-In Sales FoC	FOC Pr. at Sub (BOM)
Bought-In Sales Item	Sales f. Service FoC	Log. Item w. Billing
Sales Itm f. Service	Non-Stock Sales FoC	Pric. Head/Log. Item
Non-Stock Sales Item	Explanation in BOM	Head FOC B/Log. Item
Sales Item	Main Itm Price (BOM)	Non-Stock Item
Sales Item FoC

As mentioned above, many different detailed pieces of information can be entered; however, the information I have shared above is sufficient to save the solution order.

Once the requested information is entered, click the save button located at the bottom right, and the solution order can be saved.

When attempting to proceed with the steps of the created solution order, enter the solution order, go to the "Items" tab, and once "Release" is clicked, the process steps will automatically progress for each item.

After the release, the documents progressed according to the selected processes, and their display are as follows.

After the sales order is created, the corresponding document follows the exact same process as the SD (Sales and Distribution) process.

6. Conclusion

The Solution Order functionality in SAP S/4HANA Public Cloud represents a major step forward in the evolution of enterprise process integration. By consolidating multiple business objects—products, services, projects, and subscriptions—under a single operational framework, it enables organizations to deliver holistic, value-driven solutions to their customers rather than isolated products or services.

Through its API-first architecture, modular flexibility, and end-to-end visibility, the Solution Order empowers businesses to orchestrate sales, service, and project operations seamlessly, reducing administrative overhead while enhancing process transparency and customer satisfaction.

While its implementation requires careful configuration and a solid understanding of SAP’s integrated data model, the long-term benefits—such as consistent data management, improved collaboration across departments, and scalable automation—make it an essential capability for any organization aiming to become an Intelligent Enterprise.

In essence, the Solution Order is not just a technical enhancement; it is a strategic enabler that bridges business innovation with operational excellence, driving the digital transformation journey in the most comprehensive and structured way possible.

How to Assign Item Category to Material While Syncing to SAP CPQ – And Why It Matters

2025-11-29T11:35:51.006000+01:00

When integrating SAP CPQ (Configure, Price, Quote) with SAP S/4HANA or ERP, ECC, one critical step often overlooked is assigning the Item Category to materials during synchronization. This seemingly small detail plays a major role in ensuring smooth downstream processes like Sales Orders, Solution Quotations, and Solution Orders.

What is an Item Category ?

An Item Category in SAP determines how a material behaves in a document. It controls:

Whether the item is relevant for pricing.
If it requires a delivery or billing.
Whether it’s a service, a configurable product, or a standard material.
How it integrates with BOMs or solution components.

Reference Article/Blog explaining Item Categeory & group : Link

In short, the Item Category defines the business logic for the material in transactional documents.

Why Assign Item Category During Sync to SAP CPQ?

When materials are synced from SAP ERP to SAP CPQ, they carry essential attributes like material number, description, and pricing conditions. However, without the correct Item Category, CPQ cannot:

Determine if the material is a physical product, service, or text item.
Apply correct pricing and tax rules.
Generate accurate solution structures for complex configurations.

This impacts the integration when below are created:

Sales Orders: Applies for all ERP, S/4 HANA Public & Private Cloud
Solution Quotations: S/4 HANA Private Cloud or On-prem versions (Sales, Service & Subscription)
Solution Orders: S/4 HANA Public Cloud Edition (Sales, Service & Subscription)

Material Exists in ERP/S4 with Item Category Group

Materials in S/4 contain:
- Material Type
- Item Category Group (e.g., NORM, DIEN, LEIS)
- Sales views (pricing, tax, units)
Item category determination in Sales Orders is based on Sales Document Type + Item Category Group + Usage + Higher-Level Item Category

Standard Replication Using SOAP XML iFlow (Standard Integration for CPQ)

ERP/S4 sends materials to CPQ via standard iFlow (SOAP XML).
Limitation: SOAP payload does not include Item Category. [community.sap.com]
CPQ receives only:
- Material code
- Description
- Pricing conditions
- Basic classification

Push Item Category to CPQ using REST API

Since SOAP doesn’t carry the value, CPQ must be updated afterward:

Use Product REST API to update field:
```
itemCategory
```
representing the ERP Item Category or mapped equivalent.
This ensures CPQ interprets the product correctly (service vs good, configurable vs text item).

Integration with SAP CPQ for Material Replication

SAP CPQ provides Product RestAPI to update itemcategorygroup for Materials..

Technical Note: Updating Item Category in SAP CPQ

SAP CPQ provides a Product REST API that allows you to update the itemCategory field for products. This is useful when you need to dynamically adjust item categories after initial synchronization or based on business rules.

Field: itemCategory
Purpose: Stores the ERP item category value or a mapped equivalent.
Usage: Can be updated via REST API calls for products in CPQ.

Integration Considerations

The standard SAP CPQ–SAP ERP/S4 HANA integration iFlow currently uses SOAP XML for material synchronization. This means:

Item category values from ERP cannot be included in the SOAP payload. (Help Doc)
If additional updates are needed post-sync, you can leverage the REST API for CPQ to patch the itemCategory field.

Conclusion:
Assigning the right Item Category during material sync to SAP CPQ is not just a technical step—it’s a business-critical process that ensures seamless integration, accurate pricing, and smooth execution of sales and solution orders.

S/4HANA Logistics: Solving the "Not Possible to Determine Shipping Data" Block in STO

2025-12-26T06:22:07.272000+01:00

S/4HANA Logistics: Solving the "Not Possible to Determine Shipping Data" Block in STO.

Published By:-

Er. Pratik Das

B.Tech in Mechanical Engineering

SAP Functional Consultant / SAP Coach

Published: December 2025 Target Audience: S/4HANA Functional Consultants (MM/SD)

.........................................................................................................................................................................................................................................................

One of the most common tickets we see during the integration testing phase of an S/4HANA rollout is the missing "Shipping" tab in the Stock Transport Order (STO). When you check the logs, you’re hit with the hard error: "Not possible to determine shipping data for material &" (Message no. 06280).

In S/4HANA, the integration between Purchasing and Logistics Execution is significantly more rigid due to the Business Partner (BP) approach and the mandatory requirement for synchronized Master Data. If you are facing this error, the system is essentially telling you that the handshake between the Supplying Plant and the Receiving Plant is broken at the organizational level.

Below is a technical deep dive into the four critical configuration pillars required to resolve this.

The BP Linkage (The S/4HANA Foundation)

In ECC, we dealt with Vendors and Customers. In S/4HANA, we deal with Business Partners. For an STO to function, the Receiving Plant must be represented as a Customer BP.

Verification: Ensure the BP representing the Receiving Plant is extended to the Sales Area (Sales Org/Dist. Channel/Division) associated with the Supplying Plant.
The "Link": In the Supplier Role (FLVN01), navigate to the Purchasing Data tab. Go to Additional Purchasing Data and ensure the Plant field is populated with the Supplying Plant ID. This is a mandatory link for the system to recognize the internal procurement relationship.

Plant-Level Shipping Configuration (V_T001W)

This is the most common point of failure. The system needs a specific mapping to know which "Sales Entity" the Supplying Plant belongs to.

Path: IMG > Materials Management > Purchasing > Purchase Order > Set up Stock Transport Order > Define Shipping Data for Plants.
Action: 1. Select the Supplying Plant: Maintain the Sales Organization, Distribution Channel, and Division. 2. Select the Receiving Plant: Ensure the Customer Number (the BP created in Step 1) is assigned here.
Note: If the Customer Number is not assigned to the Receiving Plant in this table, the "Shipping" tab will never trigger in the PO.

Material Master Extension (Sales Views)

It sounds fundamental, but it is often overlooked during mass data uploads (LTMC/Migrate Your Data).

The Requirement: The material must be extended to the Sales Org/Dist. Channel of the Supplying Plant.
Key Fields: * Loading Group: (Sales: General/Plant Data) – Mandatory for shipping point determination later.

Material Tax Classification: Must be maintained, or the delivery creation will fail downstream.
Availability Check (Group): Ensure this is maintained to allow the system to calculate the delivery date.

Delivery Type & Checking Rule Assignment

The system needs to know which document type to trigger (e.g., NL for Intra-company or NLCC for Inter-company).

Path: IMG > Materials Management > Purchasing > Purchase Order > Set up Stock Transport Order > Assign Delivery Type and Checking Rule.
Logic: Look for your PO Document Type (usually UB or NB) and your Supplying Plant.
Common Fix: Ensure that for your combination, the Delivery Type field is not blank. For S/4HANA Inter-company, this is typically NLCC.

Debugging Checklist for the Field

If you have performed the above and still face Message 06280, check these "hidden" culprits:

Sales Area Alignment: Is the Sales Area assigned to the Supplying Plant in V_T001W exactly the same one the Material is extended to? A mismatch in Division is a frequent silent killer.
Customer/BP Status: Check if the Customer BP has a "Central Deletion Flag" or "Sales Block." S/4HANA is much stricter about master data status than ECC.
Ship-to Party Assignment: Does the Customer BP have a valid Ship-to Party (SH) partner function maintained for the specific Sales Area?

Conclusion

Message 06280 is a "Gatekeeper" error. It prevents you from proceeding because the foundational SD data is missing. By ensuring the BP is correctly mapped to the Plant and the Material is extended to the correct Sales Org, you can resolve this and enable the full Logistics Execution flow.

End-to-End Automatic Order to Billing Process in SAP SD (Low-Coding Approach)

2026-02-24T07:29:02.824000+01:00

In line with the customer requirement, an automatic process was designed covering delivery creation, goods issue posting, and billing immediately after sales order creation.

The solution was implemented based entirely on standard SAP SD principles and designed under a low-coding approach, minimizing custom developments while preserving full control over the process.

1. Excluding Specific Customers from the Automatic Process

During the analysis phase, it became necessary to exclude certain customers from the automated flow.

To achieve this:

A custom indicator field was defined under Business Partner – SD (FLCU01) view.
Using transaction CMOD, field KDGRP4 was renamed as “Automatic Billing Exclusion”.
For customers that must remain outside the automated process, value “X” is maintained via customizing.

This design ensures flexibility and allows business users to control participation in the automated process without additional development.

2. Sales Document Configuration (VOV8)

Within VOV8 sales document type configuration, the relevant document types were adjusted by activating the Immediate Delivery setting.

This configuration enables the system to automatically trigger delivery creation directly from the sales order.

3. Dynamic Control in MV45AFZZ (SAVE_DOCUMENT_PREPARE)

At enhancement point MV45AFZZ – SAVE_DOCUMENT_PREPARE, a class-based method was implemented instead of writing logic directly into the include.

The method dynamically reads Business Partner data and manipulates field TVAK-LISOF depending on defined conditions.

Key Logic Summary:

If the document creator is not the workflow user (SAP_WFRT), automation is cancelled.
KNVV-KVGR4 is checked for the exclusion flag.
If the customer is marked with “X”, the automation flag (TVAK-LISOF) is cleared dynamically.
Otherwise, the process continues automatically.

This approach ensures that:

Standard configuration remains intact.
Automation can be centrally controlled.
Sales document level settings can be programmatically overridden when necessary.

METHOD zsd_save_document_prepare_1.

* inserted by serdar ulgen. 19.01.2026 11:01:55 .

  i_knvv-kunnr = i_vbak-kunnr.
  i_knvv-vkorg = i_vbak-vkorg.
  i_knvv-vtweg = i_vbak-vtweg.
  i_knvv-spart = i_vbak-spart.

  FIELD-SYMBOLS <lv_lisof> TYPE any.
  ASSIGN ('(SAPMV45A)TVAK-LISOF') TO <lv_lisof>.
  IF sy-subrc <> 0.
    RETURN.
  ENDIF.

  IF i_vbak-ernam <> 'SAP_WFRT'.
    CLEAR <lv_lisof>.
    RETURN.
  ENDIF.

  SELECT SINGLE kvgr4
    FROM knvv
    INTO @i_knvv-kvgr4
    WHERE kunnr = @i_knvv-kunnr
      AND vkorg = @i_knvv-vkorg
      AND vtweg = @i_knvv-vtweg
      AND spart = @i_knvv-spart.

  IF i_knvv-kvgr4 = 'X' AND <lv_lisof> = 'A'.
    CLEAR <lv_lisof>.
  ENDIF.

* if u any question please contact with me.

4. Automating Goods Issue and Billing

After completing the Sales → Delivery flow, the next phase covered:

Goods Issue posting
Billing creation

Alternative Approach (Not Preferred)

An alternative solution could involve sequential BAPI calls for goods issue and billing within a custom program.

Although technically feasible, this method requires careful handling of:

ENQUEUE / DEQUEUE locks
Document synchronization
LUW management

Improper lock handling may lead to document conflicts.

5. Leveraging Standard Output Type REA0

In this implementation, we leveraged the fact that standard SAP output type REA0 can directly trigger billing.

The approach:

The standard program used in REA0 was copied.
A Goods Issue BAPI call was added at the beginning.
Billing creation was kept as standard.
Output determination was assigned correctly to the relevant delivery types using VV21.

This step is critical — without correct output assignment, the automation will not execute.

6. Technical Highlights

Goods issue is triggered via WS_DELIVERY_UPDATE_2
Billing is created via /SPE/CREATE_NEW_BILLING_CALL
Error handling is managed through NAST protocol updates
Separate LUW handling is ensured via /SPE/CALL_PROC_IN_NEW_LUW
Minimal custom coding
Maximum reuse of SAP standard structures

REPORT  zsd_***_****.

TABLES: nast.
CONSTANTS: c_allready_billed TYPE fkstk VALUE 'C'.
DATA: gs_nast            TYPE nast,
      lt_delivery_data   TYPE leshp_delivery_t,
      ls_delivery_data   TYPE LINE OF leshp_delivery_t,
      lt_delivery_items  TYPE leshp_delivery_item_t,
      ls_doc_pos_ver_req TYPE /spe/doc_pos_ver_req,
      lt_doc_pos_ver_req TYPE /spe/doc_pos_ver_req_t,
      lv_dummy_message   TYPE bapiret2-message,
      lt_bapiret2        TYPE bapiret2_t,
      ls_bapiret2        TYPE bapiret2,
      ls_leshp_data      TYPE leshp_data.

FIELD-SYMBOLS: <ls_billing_req> TYPE LINE OF leshp_delivery_item_t.

*&---------------------------------------------------------------------*
*&      Form  ENTRY
*&---------------------------------------------------------------------*
*       create new bill
*----------------------------------------------------------------------*
FORM entry USING returncode  TYPE sy-subrc
                 use_screen  TYPE c.

  DATA: ls_vbeln_vl TYPE vbeln_vl,
        lv_leave    TYPE c,                                 "n_1238590
        lv_error    TYPE c,
        ls_vbkok    TYPE vbkok,
        lt_prot     TYPE TABLE OF prott,
        lv_text     TYPE t100-text,
        lv_delivery TYPE vbeln_vl.

  FIELD-SYMBOLS: <ls_return> TYPE bapiret2.

  IF sy-uname = 'SAP_WFRT'.

  lv_delivery = nast-objky.
  ls_vbkok-vbeln_vl  = lv_delivery.
  ls_vbkok-wadat_ist = sy-datum.
  ls_vbkok-wabuc     = abap_true.

  CALL FUNCTION 'WS_DELIVERY_UPDATE_2'
    EXPORTING
      synchron      = abap_true
      vbkok_wa      = ls_vbkok
      delivery      = lv_delivery
    TABLES
      prot          = lt_prot
    EXCEPTIONS
      error_message = 1
      OTHERS        = 2.

  LOOP AT lt_prot ASSIGNING FIELD-SYMBOL(<error>).
    IF <error>-msgty = 'E' OR <error>-msgty = 'A'.

      SELECT SINGLE text FROM t100 INTO @LV_text WHERE sprsl = @SY-langu AND arbgb = @<error>-msgid AND msgnr = @<error>-msgno.

      IF sy-subrc = 0 AND lv_text IS NOT INITIAL.
        MESSAGE lv_text TYPE 'E'.
      ELSE.
        MESSAGE ID <error>-msgid TYPE 'E' NUMBER <error>-msgno.
      ENDIF.

      returncode = 1.
      RETURN.
    ENDIF.
  ENDLOOP.

ENDIF.


* Redirect this NAST processing to separate LUW - in case it is
* called with dispatching time 4 (immediate processing)
* during update task                                        "v_n_1238590
CALL FUNCTION '/SPE/CALL_PROC_IN_NEW_LUW'
  EXPORTING
    is_nast  = nast
  IMPORTING
    ef_leave = lv_leave.
IF NOT lv_leave IS INITIAL.
*   Per default we set the status on error, so that it can be reprocessed
*   in error processing (RSNAST0F) if there is any syntax error / update
*   termination / ... in the decoupled NAST processing.
  returncode = 4.
  RETURN.
ENDIF.                                                    "^_n_1238590

returncode = 0.
* Get Item Data of Delivery
*  ls_leshp_data-item = 'X'.                                  "n_1822545
* Get Status of Outbound Delivery
ls_leshp_data-head_status = 'X'.
* Copy Nast Entry
gs_nast = nast.
ls_vbeln_vl = nast-objky.

CALL FUNCTION 'LE_DELIVERY_GET_BUFFERED'
  EXPORTING
    if_vbeln               = ls_vbeln_vl
    is_data                = ls_leshp_data
  CHANGING
    cx_deliveries          = lt_delivery_data
  EXCEPTIONS
    no_item_selected       = 1
    selected_item_enqueued = 2
    no_key_specified       = 3
    OTHERS                 = 4.
IF sy-subrc <> 0.
  MESSAGE e267(/spe/vl) WITH ls_vbeln_vl INTO lv_dummy_message.
  returncode = sy-subrc.
ELSE.

* only one delivery can be found by premisses (VBELN).
  READ TABLE lt_delivery_data INDEX 1 INTO ls_delivery_data.
  IF sy-subrc = 0.
    IF ls_delivery_data-head_status-fkstk = c_allready_billed.
* Allready billed.
      returncode = 0.
      MESSAGE i265(/spe/vl) WITH ls_vbeln_vl INTO lv_dummy_message.
    ELSE.
*        lt_delivery_items = ls_delivery_data-item.         "v_n_1822545
*        LOOP AT lt_delivery_items ASSIGNING <ls_billing_req>.
*          MOVE-CORRESPONDING <ls_billing_req> TO ls_doc_pos_ver_req.
*          APPEND ls_doc_pos_ver_req TO lt_doc_pos_ver_req.
*        ENDLOOP.
      ls_doc_pos_ver_req-vbeln = ls_delivery_data-head-vbeln.
      APPEND ls_doc_pos_ver_req TO lt_doc_pos_ver_req.    "^_n_1822545

      CALL FUNCTION '/SPE/CREATE_NEW_BILLING_CALL'
        EXPORTING
          it_billing_req     = lt_doc_pos_ver_req
          iv_version_checked = 'X'
        IMPORTING
          et_return          = lt_bapiret2.
      LOOP AT lt_bapiret2 ASSIGNING <ls_return>.
        IF <ls_return>-type = 'E'.
          lv_error = 'X'.
        ENDIF.
      ENDLOOP.
      IF lv_error = 'X'.
        returncode = 1.
        use_screen = ' '.
      ELSE.
        returncode = 0.
      ENDIF.
    ENDIF.

  ELSE.
* No Entry found !!!
    MESSAGE e267(/spe/vl) WITH ls_vbeln_vl INTO lv_dummy_message.
    returncode = 9.
  ENDIF.
ENDIF.
CALL FUNCTION 'NAST_PROTOCOL_INITIALIZE'.
LOOP AT lt_bapiret2 ASSIGNING <ls_return>.
  IF <ls_return>-type = 'E'.
    lv_error = 'X'.
  ENDIF.
  PERFORM protocol_update_return USING <ls_return>.
ENDLOOP.
IF lv_error = 'X'.
  returncode = 1.
  use_screen = ' '.
ELSE.
  returncode = 0.
ENDIF.

IF sy-subrc <> 0.
  PERFORM protocol_update.
ENDIF.
ENDFORM.                    " ENTRY

*---------------------------------------------------------------------*
*       FORM PROTOCOL_UPDATE                                          *
*---------------------------------------------------------------------*
*       The messages are collected for the processing protocol.       *
*---------------------------------------------------------------------*

FORM protocol_update.

  CALL FUNCTION 'NAST_PROTOCOL_UPDATE'
    EXPORTING
      msg_arbgb = syst-msgid
      msg_nr    = syst-msgno
      msg_ty    = syst-msgty
      msg_v1    = syst-msgv1
      msg_v2    = syst-msgv2
      msg_v3    = syst-msgv3
      msg_v4    = syst-msgv4
    EXCEPTIONS
      OTHERS    = 1.

ENDFORM.                    "PROTOCOL_UPDATE
*&---------------------------------------------------------------------*
*&      Form  protocol_update_return
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->P_<LS_RETURN>  text
*----------------------------------------------------------------------*
FORM protocol_update_return USING p_return TYPE bapiret2.

  CALL FUNCTION 'NAST_PROTOCOL_UPDATE'
    EXPORTING
      msg_arbgb = p_return-id
      msg_nr    = p_return-number
      msg_ty    = p_return-type
      msg_v1    = p_return-message_v1
      msg_v2    = p_return-message_v2
      msg_v3    = p_return-message_v3
      msg_v4    = p_return-message_v4
    EXCEPTIONS
      OTHERS    = 1.

ENDFORM.                    " protocol_update_return

7. Final Architecture Principle

Standard-first approach

Low-coding strategy

Dynamic control via enhancement

Output-driven automation

Controlled customer-based exclusion

Lock-safe execution

8. Conclusion

This solution delivers a fully automated Order → Delivery → Goods Issue → Billing process while maintaining:

High adherence to SAP standards
Minimal custom development footprint
Flexible customer-level control
System stability and scalability

By combining standard configuration (VOV8, VV21), enhancement logic (MV45AFZZ), and output-based processing (REA0), an end-to-end automated and maintainable SD process was successfully implemented.