S/4HANA SD Document Flow Configuration: Order Types, Item Categories, Schedule Lines & Copy Control – Full Hands‑On Guide | Part 24 | FreeLearning365

 

Day 9 – SD Document Flow Configuration: Order Types, Item Categories, Schedule Lines & Copy Control

Functional Consultant Track – Part 24

Welcome to Day 9, where the SD configuration truly comes alive. Yesterday you built the SD master data and organisational backbone. Today, we connect the bones with the muscles and nerves – the document flow. In the real world, a sales order is never just a sales order. It is a living document that morphs into a delivery, then a goods issue, then a billing document, and possibly a credit memo. Every step is governed by document types, item categories, schedule line categories, and the intricate web of copy control that moves data from one document to the next. A misconfiguration here can break your entire order‑to‑cash process.

Our client GlobalTech sells pumps, motors, and spare parts through multiple channels. They need a standard order process, a rush order process that skips credit checks (for VIPs), a returns process that automatically generates a credit note, consignment fill‑up orders for their distributor’s stock, and milestone billing for large capital projects. Your job today: configure every sales document type, item category, schedule line category, copy control rule, incompletion procedure, and billing plan that makes these processes hum. By the end of this 20,000‑word deep dive, you’ll be able to design any order‑to‑cash flow a business can imagine.

1. Sales Document Types – The Master Controllers

Sales document types (e.g., OR, RO, KE) define the entire transaction. They control: the allowed sales area, the number range, the delivery and billing types that can follow, the credit check settings, the partner determination procedure, the incompletion log, and much more. Think of them as the blueprint for every sales transaction.

1.1 Standard Delivered Document Types

GlobalTech will use several standard types, but also create a custom one. Let’s review the heavy‑hitters:

• OR – Standard Order. Used for regular sales. Typically leads to a delivery (LF) and billing (F2). Credit check active.
• RO – Return Order. Used when a customer returns goods. Leads to a returns delivery (LR) and a credit note (G2).
• KE – Consignment Fill‑Up. Sends stock to a customer’s consignment warehouse. No billing until consumption (issue). Leads to delivery (LF) but billing type may be suppressed.
• KA – Consignment Issue. Triggers billing when the customer consumes consignment stock.
• SO – Standard Order (make‑to‑order) – but we can use OR with a different item category for MTO. Actually, standard OR is flexible.
• FO – Framework Order – for long‑term agreements.

1.2 Configuration of a Custom Rush Order Type (ZRUSH)

GlobalTech’s VIP customers sometimes need orders shipped within 24 hours, and the credit check should be skipped because they have prepaid accounts. Standard OR does a credit check; we need a variant. We’ll create a new order type ZRUSH as a copy of OR, then modify.

SPRO Path: Sales and Distribution → Sales → Sales Documents → Sales Document Header → Define Sales Document Types (transaction VOV8).

Select OR, click “Copy”. Change the document type to ZRUSH, description “Rush Order”. Adjust the following:

• Number Systems: Assign a new internal number range (e.g., 15, range 7000000000 – 7099999999) or share with OR (usually separate for reporting). We’ll create a new number range 15 in VN01 (Assign Number Ranges) and assign it to ZRUSH.
• General Control: Under “Transaction Flow”, ensure the delivery type is LF and billing type F2 (same as standard). Check “Order‑related billing” if you want to bill from the order, but GlobalTech bills from delivery, so uncheck.
• Sales Area & Partner: Set the allowed order types for sales areas later in VOV8 → Assign Sales Area to Sales Document Types (actually, it’s a separate step: Sales → Sales Documents → Sales Document Header → Assign Sales Order Types Permitted for Sales Areas). We’ll assign ZRUSH to US01/10/P1, DE01/10/P1.
• Incompletion Procedure: Assign the incompletion procedure later. We’ll keep the same as OR for now.
• Credit Check: The credit check is activated via the order type. In VOV8, under “Credit Check”, for OR the field “Credit check” is usually “D” (automatic credit check). For ZRUSH, we set it to blank (no credit check). That’s the key difference.

Also define the allowed item categories for this order type. In VOV8, after creating ZRUSH, go to Sales → Sales Documents → Sales Document Item → Assign Item Categories (transaction VOV4). This is the first step in item category determination; we’ll handle it fully soon. For now, note that ZRUSH will allow standard item categories like TAN (standard item), TANN (no credit), maybe TAS (third‑party). We’ll configure exactly which ones later.

1.3 Document Type and Number Ranges (VN01)

Number ranges are assigned per sales document type. For ZRUSH, create number range 15 with internal assignment. In VN01 (Maintain Number Ranges for Sales Documents), enter the interval. Then in VOV8, for ZRUSH, set “No. range int. assg.” to 15. This ensures every rush order gets a unique number from that pool.

1.4 Testing the Custom Order Type

Use VA01, select order type ZRUSH, sales area US01/10/P1. Enter sold‑to party (VIP customer with no credit limit), material, quantity. The system should allow the order without credit check. If we try a standard OR for a customer over credit limit, the system blocks. This differentiation is exactly what the business wants.

2. Item Category Determination – The Brain of Each Line

The item category is a 4‑character code that controls the behaviour of a sales document line. It determines: whether the item is relevant for billing, delivery, pricing, and which schedule line categories are allowed. The item category determination uses a simple rule: the combination of the sales document type and the item category group (from the material master) gives you a default item category. You can then override it manually in the order if alternative item categories are allowed.

2.1 Master Data Foundation: Item Category Groups

In the material master (Sales Org 2 view), there’s a field Item Category Group. Standard groups:

• NORM – Standard item (finished goods, trading goods)
• DIEN – Services
• VERP – Packaging
• LEER – Empties (returnable containers)
• TATX – Text item (no delivery/billing)
• NMAT – Non‑stock material (purchased directly for customer)

GlobalTech’s finished goods FERT01 uses NORM. Services (e.g., installation) use DIEN. When a material is entered in a sales order, the system takes its item category group and looks up the allowed item categories for that sales document type.

2.2 Configuration of Item Category Determination (VOV4)

SPRO: Sales and Distribution → Sales → Sales Documents → Sales Document Item → Assign Item Categories (transaction VOV4).

This table holds: Sales Document Type + Item Category Group → Default Item Category. Let’s define for GlobalTech’s document types:

• OR + NORM → TAN (Standard item)
• OR + DIEN → TAD (Service item, no delivery relevance)
• OR + TATX → TATX (Text item)
• ZRUSH + NORM → TAN (Same as OR, but later we might want a separate item category that skips some checks – for now, TAN is fine)
• RO + NORM → REN (Return item)
• KE + NORM → KEN (Consignment fill‑up item)

We also need to define the Allowed Item Categories for manual override. In VOV4, after setting the default, you can click “Allowed Item Categories” and list which other item categories the user can change to in the order. For OR, we might allow TAN (default), TANN (no credit), TATX (text), and AFX (inquiry – but not in order). For returns, only REN is allowed.

2.3 Item Category Configuration (VOV7)

Each item category itself has deep settings. Let’s examine TAN (standard item) in SPRO: Sales and Distribution → Sales → Sales Documents → Sales Document Item → Define Item Categories (transaction VOV7).

Key fields in TAN:

• Billing Relevance: “A” (delivery‑related billing). So when you deliver, the billing due list picks it up.
• Delivery Relevance: blank? Actually, delivery relevance is controlled by the schedule line category, not directly by item category. Wait: the item category has a field “Item type” (e.g., Standard, Text, Value). It also has “Relevance for delivery” – “X” means relevant. For TAN, it’s relevant.
• Pricing: “X” (price is determined).
• Schedule Line Allowed: list of schedule line categories that can be used. For TAN, typical are CP, CN, etc.
• Credit check: Checkbox active? For TAN, credit check is active (which we override at header level but item can also have a setting).

For returns (REN), we need billing relevance “H” (billing is credit memo relevant) and delivery relevance for returns. The item category REN should have: “Item type” = return, “Billing Relevance” = H, “Delivery Relevance” = X (for returns delivery).

2.4 Schedule Line Category Determination from Item Category

The item category doesn’t directly determine the schedule line category; instead, the combination of item category and MRP type (from material master) or requirement type determines the schedule line category. But there’s another table: in VOV7, under “Schedule Line Categories”, you define which schedule line categories are allowed for that item category. Then in VOV5 (Assign Schedule Line Categories), you link the item category and the MRP type to a default schedule line category. We’ll explore this later.

2.5 Hands‑On Item Category Determination Test

Create a sales order with OR, enter material FERT01 (item category group NORM). The system automatically sets item category TAN. Now add a text line: in the order, go to Edit → Text → Create. The text line uses item category TATX automatically, bypassing pricing and delivery. Try to change the item category of the material manually: in the item overview, click the item category field and press F4. The list shows only the allowed item categories we set in VOV4 (TAN, TANN, TATX). This prevents users from selecting an invalid category.

3. Schedule Line Categories – The Pulse of Delivery and ATP

The schedule line category controls how an order item is fulfilled: dates, quantities, availability check (ATP), transfer of requirements to MRP, and delivery scheduling. Each item in a sales order has at least one schedule line. The schedule line category is automatically determined based on the item category and the material’s MRP type (or requirement type).

3.1 Standard Schedule Line Categories

The most common ones:

• CP – Standard (MRP, availability check with ATP, transfer of requirements active).
• CN – No MRP (no transfer of requirements, no availability check against planned independent requirements – but ATP may still check physical stock if configured).
• BV – Individual customer stock (make‑to‑order stock). Used with requirement type KE.
• CT – No planning, no delivery (for text or service lines where no physical delivery occurs).

3.2 Configuration – Defining Schedule Line Categories (VOV6)

SPRO: Sales and Distribution → Sales → Sales Documents → Schedule Lines → Define Schedule Line Categories (transaction VOV6).

Select CP and review its settings:

• Movement type: 601 (for delivery).
• Availability: check “Availability check” active, set the checking rule (e.g., “A” for standard ATP).
• Transfer of requirements: active. This sends the demand to MRP. The requirement type (e.g., 001) is defined here or derived from the item category.
• Delivery scheduling: active, using the scheduling parameters from the customer‑material info record and route.

For CN (no MRP), transfer of requirements is inactive. Use this for free‑of‑charge items or samples where you don’t want MRP to plan production.

3.3 Assignment of Schedule Line Categories to Item Categories (VOV5)

SPRO: Sales and Distribution → Sales → Sales Documents → Schedule Lines → Assign Schedule Line Categories (transaction VOV5).

This is the determination table: Item Category + MRP type (from material master) → default Schedule Line Category.

For GlobalTech, the material FERT01 has MRP type PD (standard MRP). We want the schedule line category CP. So in VOV5, for item category TAN and MRP type PD, we set default CP. For a non‑stock material (DIEN, item category TAD), MRP type is not relevant; we can set schedule line category CT (no delivery) or CP if services can be confirmed? Usually services use CT.

We also need to allow alternative schedule line categories. In VOV5, click “Allowed schedule line categories” for the combination. For TAN + PD, we allow CP, CN (if user wants to skip MRP for a specific line), and maybe BV for make‑to‑order. However, BV requires a different MRP type (like KE) and a requirement type. We’ll handle MTO later.

3.4 Requirement Types and Requirement Classes

The requirement type sits between the sales document and MRP. It links the schedule line to a planning strategy. For standard CP, the requirement type is 001 (or standard). The requirement type is automatically determined by the system based on the strategy group in the material master (MRP 3 view) and the item category. Configuration: Sales and Distribution → Sales → Sales Documents → Schedule Lines → Define Requirement Types and Define Requirement Classes. We won’t deep‑dive into planning strategies now, but we note that the integrity of the link from schedule line → requirement type → MRP demand is crucial.

3.5 ATP (Available to Promise) Check – How It Works

When a schedule line with availability check active is saved, the system runs ATP. It considers current stock, planned receipts (production orders, purchase orders), and planned issues. The ATP quantity is calculated backwards from the requested delivery date. If insufficient, the system proposes a later confirmed date. GlobalTech relies on ATP to give customers realistic delivery promises. We’ll configure the availability check scope in SPRO: Sales and Distribution → Basic Functions → Availability Check and Transfer of Requirements → Define Checking Groups and assign to the material master (Availability Check field in MRP 3). The material uses checking group 01 (daily requirements). The ATP check is then performed when the sales order is saved. If the quantity cannot be confirmed, the order is saved with a warning, and the schedule line shows the confirmed quantity and date.

Test: For material FERT01 with sufficient stock, create an order with 10 units, requested delivery tomorrow. ATP confirms 10 units with the requested date. Now try to order 1000 units. ATP confirms 200 (available) on the requested date, and the remaining 800 on a future date based on planned receipts. The sales clerk can inform the customer of the partial delivery schedule.

4. Copy Control – The Glue Between Documents

Copy control defines what data flows when you create a subsequent document: order → delivery, delivery → billing, order → billing (if order‑related billing), etc. Without proper copy control, you can’t create a delivery from an order or an invoice from a delivery. It consists of a header‑level and item‑level control, and for each combination of source document type and target document type, you specify which item categories can be copied, and which data fields are copied vs. re‑determined.

4.1 Copy Control Entries

SPRO: Sales and Distribution → Sales → Maintain Copy Control for Sales Documents (transaction VTAA for sales document to sales document). For order to delivery: Logistics Execution → Shipping → Copy Control → Specify Copy Control for Deliveries (transaction VTLA). For billing: Sales and Distribution → Billing → Billing Documents → Maintain Copy Control for Billing Documents (transaction VTFA for delivery to billing, VTFL for order to billing).

Let’s walk through the crucial ones for GlobalTech.

4.2 Order to Delivery (VTLA)

Source: Order type OR, Target: Delivery type LF. At the header level, set “Copying requirements” (routine 2 – standard). At the item level, we need an entry for each combination of source item category and target item category. For OR/TAN to LF/TAN (delivery item category is usually TAN for standard items). In VTLA, create entry: Source Item Cat TAN, Target Item Cat TAN, with copy routine “001” (copy quantity). Also, set “Data transfer” routines for header and item if needed. The copy control decides:

• Whether the quantity is proposed from the order (open quantity).
• Whether the item can be split into multiple deliveries.
• Whether the item number is copied or re‑numbered.

For returns (RO), copy control to returns delivery (LR) must exist. So entry: RO/REN → LR/REN.

4.3 Delivery to Billing (VTFA)

Source: Delivery type LF, Target: Billing type F2. Item level: Delivery item category TAN → Billing item category TAN. Copy routine “001”. Also, note the “Billing relevance” field in the delivery item category determines if the item is picked up by the billing due list. If it’s not relevant, even with copy control, the billing document won’t propose it automatically.

4.4 Order to Billing (VTFL) – Used for Order‑Related Billing

For example, for a service order where you bill without delivery, you copy from order directly. For OR, we don’t need it; we bill from delivery. But if we create a service order type (e.g., SV), we’d set up copy control from SV to F2.

4.5 Custom Copy Control for Rush Order

ZRUSH order type uses the same delivery type LF and billing type F2, but we might want to skip certain checks. The copy control entries must be added for ZRUSH → LF. In VTLA, add header entry: Source ZRUSH, Target LF. Then item entries: ZRUSH/TAN → LF/TAN. Use the same routines as OR. Now create a rush order and try to deliver – it works.

4.6 Missing Copy Control – A Classic Error

If you attempt to create a delivery for a sales order and you get “No item relevant for delivery” or “Copy control not maintained”, you immediately know you need to add the entry in VTLA. Many junior consultants forget this and waste hours debugging. Now you know.

5. Incompletion Log – Making Fields Mandatory

The incompletion log is the system’s way of saying “You forgot something important.” It prevents the user from saving, delivering, or billing a document until required fields are filled. You define incompletion procedures and assign them to document types and item categories.

5.1 Configuration of Incompletion Procedures

SPRO: Sales and Distribution → Basic Functions → Incompletion Check → Define Incompletion Procedures (transaction OVF0).

Standard procedures:

• 11 – Sales Order Header
• 12 – Sales Order Item
• 21 – Delivery Header
• 22 – Delivery Item
• 31 – Billing Header
• 32 – Billing Item

For procedure 11 (order header), standard fields like customer PO number, payment terms, and sales area might be mandatory. For procedure 12 (order item), fields like delivering plant, shipping point, and material availability might be mandatory. You can add custom fields via the field catalog, but that’s advanced. For now, we’ll use standard and enhance it.

GlobalTech requires that for rush orders (ZRUSH), the “Customer PO Number” is mandatory because VIP orders always have a reference. We’ll create a new incompletion procedure “Z1” for the order header, copying from 11, and then in the procedure, add the field “VBKD‑BSTNK” (Customer PO number) with status “Error”. Assign this procedure to document type ZRUSH in VOV8 under “Incompletion procedure”.

Similarly, for the item level, we might want the “Plant” field mandatory for all order types; it’s already standard.

5.2 How Incompletion Works in Action

Create a ZRUSH order, enter customer, material, quantity, but leave the PO number blank. When you attempt to save, the system pops up the incompletion log: “Customer PO number is required”. You can either fill it or save the document as incomplete (allowed if you set the “Save without completion” checkbox in VOV8). If you save as incomplete, the order is stored but cannot be delivered or billed until completed. The sales clerk can later complete it via VA02. Incomplete documents appear in transaction V.02 (List of Incomplete Sales Documents), which is a manager’s daily check.

6. Billing Plan Configuration – Milestone and Periodic Billing

A billing plan allows you to split an order’s value into multiple billing dates. This is essential for project‑based businesses (milestone billing) and subscription‑based services (periodic billing). GlobalTech sells large pump installations with three milestones: 30% on contract signing, 40% on delivery, 30% on commissioning. They also offer annual maintenance contracts billed monthly.

6.1 Billing Plan Types

SPRO: Sales and Distribution → Billing → Billing Plan → Define Billing Plan Types (transaction OVBS).

Standard types:

• 01 – Periodic billing (e.g., monthly rent).
• 02 – Milestone billing (fixed dates or events).

GlobalTech will use type 02 for installations and 01 for service contracts. We can copy standard types and assign to our item categories.

6.2 Assign Billing Plan Type to Sales Document Type and Item Category

SPRO: Sales and Distribution → Billing → Billing Plan → Assign Billing Plan Types to Sales Document Types (transaction OVB0). For OR, we assign billing plan type 02. For a service contract order type (which we’ll create as copy of OR, say ZSERV), we assign 01.

Then, in the item category, we must allow billing plans. In VOV7 for TAN, under “Billing Plan”, we can set “Billing plan allowed” to “X”. Or we can create a specific item category for milestone billing. For simplicity, we’ll allow billing plan for TAN.

6.3 Creating a Milestone Billing Plan in a Sales Order (VA01)

Create order OR, material PUMP01 (a new high‑value material, division P1). After entering the line, go to “Item” → “Billing Plan” (or press the billing plan button). The system proposes the plan type 02. Enter milestones:

• Milestone 1: 30%, date = today (contract signing). Rule: fixed date.
• Milestone 2: 40%, date = in 2 months (delivery).
• Milestone 3: 30%, date = in 4 months (commissioning).

Each milestone generates a billing due date. When the date arrives, the billing due list (VF04) picks it up, and you can create a billing document for the specified percentage. Only the first milestone is due now, so the system creates an invoice for 30% of the total. The order line remains open for the remaining amounts. This avoids manual tracking and speeds cash flow.

6.4 Periodic Billing for Maintenance Contract

Create order type ZSERV (maintenance contract) with billing plan type 01. In the order, enter the material “MAINT‑CONTRACT”, billing plan: start date today, end date in 12 months, billing frequency monthly. The system automatically creates 12 billing dates. Each month, VF04 proposes an invoice for 1/12 of the total. Perfect for recurring revenue.

6.5 Integration with SD Billing and FI

Each billing plan line, when billed, creates a separate billing document (unless you use collective billing). The FI posting is standard: debit customer, credit revenue. The revenue recognition under IFRS 15 (over time) may require additional CO‑PA or Results Analysis, but that’s a later topic. For now, the billing plan automates the invoicing schedule.

7. Full Scenario – A Day in GlobalTech’s Sales Office

Let’s run a complete end‑to‑end test of all configurations we made today.

Morning: A VIP customer calls to order 10 pumps. The sales rep creates a rush order (ZRUSH), enters customer CUST‑SOLD01, material PUMP01. The incompletion log prompts for the PO number; the rep enters “VIP‑2025‑001”. The order saves without credit check. Schedule line CP is determined; ATP confirms 10 units from stock. Delivery date tomorrow.

Mid‑day: A return request comes in. The sales rep creates a return order (RO), referencing the original invoice. Item category REN automatically assigned. Copy control ensures the return delivery is generated.

Afternoon: A large capital project order is created for a pump installation. The sales rep uses OR, enters PUMP‑INSTALL material, and sets up a milestone billing plan: 30% now, 40% on delivery, 30% on commissioning. Billing due list immediately shows the first milestone; billing clerk creates invoice for 30%.

End of day: The logistics team runs delivery creation (VL10A) for all due orders. The rush order delivery is created without issue because copy control ZRUSH→LF exists. Picking, packing, and post goods issue. Billing due list then proposes the final invoices (for delivered items). All output determinations fire off invoices and delivery notes. The month‑end revenue is accurate.

Every document type, item category, schedule line, copy control, incompletion rule, and billing plan played its role flawlessly.

8. Best Practices, Pitfalls, and Alternatives

Best Practices:

• Keep the number of sales document types to a minimum. Over‑customisation leads to maintenance nightmares. Use item categories to differentiate behaviour rather than creating a new order type for every variation.
• Copy control should be tested for every document flow. Create a matrix of source and target document types and verify.
• Use incompletion procedures to enforce data quality but don’t make too many fields mandatory – it frustrates sales reps and delays order entry. Balance is key.
• For billing plans, always test the “billing due list” (VF04) to ensure milestones or periods are correctly proposed. Check that partial billing doesn’t fully close the sales order line until the final billing (configure “Completion Rule” in the billing plan type).
• Schedule line category CP is the workhorse. Understand the difference between CP and CN deeply – using CP when no MRP is wanted can create unwanted demand; using CN when MRP is needed can cause stock‑outs.

Common Pitfalls:

• Forgetting to assign the new document type to the sales area (in VOV8 via Assign Sales Order Types Permitted for Sales Areas). Even if all else is correct, the user will see “Order type ZRUSH not allowed for this sales area”.
• Item category determination not working because the material’s item category group is not maintained in the Sales Org 2 view. It defaults to “NORM”, but if you blank it, the system can’t determine.
• Copy control missing for returns: you can create a return order, but cannot create a returns delivery because the item category REN → delivery item category entry is missing.
• Billing plan not appearing: the item category must have “Billing plan allowed” set, and the billing plan type must be assigned to the sales document type. Both are required.
• Availability check not working: check that the checking group is maintained in the material master (MRP 3 view) and that the schedule line category has “Availability check” active. Also, the ATP scope of check (OPJJ) must include the relevant elements.

Alternatives and Advanced Options:

• Instead of a separate rush order type, some companies use a “Reason Code” or “Credit Check” override via authorisation, but a separate type gives clearer reporting and control.
• For complex availability checks, use “Product Allocation” (COPA) or “Capable‑to‑Promise” (CTP) in conjunction with PP/DS.
• Billing plans can also be integrated with Project System (PS) milestones to automatically trigger invoicing when a milestone is confirmed.

9. Conclusion – You Are Now a Document Flow Architect

Day 9 has transformed you into a SD document flow master. You can define and assign sales document types, master item category determination, configure schedule line categories with ATP and MRP integration, build copy control that glues documents together, enforce data completeness with incompletion logs, and set up milestone and periodic billing plans that automate invoicing. This is the core transactional engine of SD – the part that makes the daily work happen.

Tomorrow, on Day 10 (Part 25), we explore Returns, Complaints & Special Sales Scenarios – Credit Notes, Free Goods, Consignment, Third‑Party, MTO vs MTS, and Inter‑company Sales. It’s a jam‑packed session that will complete your SD configuration toolkit. Get ready for the most diverse and fascinating SD config yet.

@FreeLearning365 – Tech Partner @techbook24