SD / O2Cintermediate

SD Schedule Line Categories Part 2: Configuration and Determination (VOV6 / VOV5)

Key takeaway

Configure schedule line categories in VOV6 — delivery block, movement types, purchasing data (order type, item category, account assignment), transaction flags for ATP and requirements, incompletion — and determine them in VOV5 from item category and MRP type with manual alternatives.

Explanation

📌 KEY POINTS
✅ VOV6 (table TVEP) defines each category; VOV5 (table T184L) determines it from item category + MRP type (MARC-DISMM).
✅ Transaction flags "Availability" and "Req./assembly" switch ATP and transfer of requirements on or off — the requirements type and checking group then decide how.
✅ Purchasing fields (order type NB, item category, account assignment category) make CS/CB create purchase requisitions.
✅ Movement type (601, 651) decides the goods issue posting in the delivery.
⚠️ A blank MRP type row in VOV5 is the default for all materials without a specific entry — changing it affects everything.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 explained what schedule lines do. Now we configure and determine the categories.

━━━━━━━━━━━━━━━━━━━━
▶ 1. BUSINESS DATA (VOV6)

Delivery block (e.g. for free-of-charge approvals).
Movement type, movement type 1-step (for one-step stock transfers).
Relevant for delivery indicator.

━━━━━━━━━━━━━━━━━━━━
▶ 2. PURCHASING DATA

Order type (NB), item category (5 third-party, blank standard), account assignment category (1 for third-party).
Creates PR automatically for CS/CB.

━━━━━━━━━━━━━━━━━━━━
▶ 3. TRANSACTION FLOW

Incompletion procedure for schedule lines.
Availability check, product allocation, requirements/assembly.

━━━━━━━━━━━━━━━━━━━━
▶ 4. DETERMINATION (VOV5)

Key: item category + MRP type (DISMM from MRP 1 view of the plant).
Blank MRP type row = default; specific rows (e.g. ND no planning → CN).
Up to several manual alternatives (e.g. CP ↔ CN).

━━━━━━━━━━━━━━━━━━━━
▶ 5. WHEN THE MRP TYPE CHANGES

Only new schedule lines are affected; open orders keep their category until redetermined.
New MRP types need VOV5 entries or fall back to the blank row.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Copy CP to ZCP in VOV6 if behavior must differ.
Maintain VOV5: item category + blank MRP type → default, add specific MRP types.
Check flags for ATP and requirements.
Test with materials of different MRP types.

✅ CHECKPOINT: a TAN item for an ND material gets CN, for a PD material CP.

Code example

ABAP Code

===== STEP 1: define (SPRO > Sales and Distribution > Sales > Sales Documents > Schedule Lines >             Define Schedule Line Categories)  (VOV6)  table TVEPField                 | CP   | CN   | CS   | CB   | DNDelivery block        | –    | –    | –    | –    | –Movement type         | 601  | 601  | –    | 601  | 651Order type (PR)       | –    | –    | NB   | NB   | –Item category (MM)    | –    | –    | 5    | –    | –Acct assignment cat.  | –    | –    | 1    | –    | –Relevant for delivery | X    | X    | –    | X    | XAvailability          | X    | –    | –    | X    | –Req./assembly         | X    | –    | –    | X    | – ===== STEP 2: determine (Assign Schedule Line Categories)  (VOV5)  table T184LItCa | MRP type | Default | Manual alternativesTAN  |          | CP      | CNTAN  | ND       | CN      |TAS  |          | CS      |TAB  |          | CB      |REN  |          | DN      |AGN  |          | BN      | ===== STEP 3: master data input =====MM02 > MRP 1 view (plant) > MRP type DISMM (PD, VB, ND, X0 ...)

Real project scenario

A client introduced a new MRP type X1 for a vendor-managed warehouse. VOV5 had no entry for X1, so TAN items fell back to the blank-row default CP — correct by luck. Later a consultant changed the blank-row default to CN for a different reason, and suddenly all X1 materials lost ATP and requirements. The team added explicit VOV5 rows for every MRP type in use and documented the blank row as a controlled "default for unknown MRP types".

Common mistakes

Forgetting VOV5 entries for new MRP types.
Changing the blank-row default without impact analysis.
Copying CS without purchasing fields, so no PR is created.
Turning off requirements transfer while keeping ATP, or vice versa, without a reason.
Modifying standard categories instead of copying.

Best practices

Maintain explicit VOV5 rows for all MRP types in use.
Treat the blank MRP type row as a controlled default.
Copy standard categories to Z for changes.
Align ATP and requirements flags with planning.
Test every item category × MRP type combination.

Interview angle

Questions: "How is the schedule line category determined?", "Which VOV6 fields make a third-party PR?", "What happens if a material has a new MRP type?"
Strong answer: VOV5 uses item category + MRP type (blank row as default) with manual alternatives; VOV6 holds delivery relevance, movement type, purchasing data (order type NB, item category 5, account assignment 1 for CS) and flags for ATP and requirements; new MRP types need entries or fall back to the default.

Practice this lesson

Quick check

1. Which VOV6 setting decides the goods movement posted when the delivery is goods-issued?

2. Which two inputs determine the schedule line category in VOV5?

3. A new MRP type X1 is introduced for some materials. What happens to TAN items if VOV5 has no row for X1?

Interview questions

1. How would you configure item category determination for a customer scheduling agreement so that materials produced under a make-to-order strategy correctly trigger production-relevant schedule line categories instead of standard make-to-stock delivery processing?

Answer it in your own words first, then compare.

2. A standard order is showing an unexpected schedule line category that bypasses the availability check, causing delivery creation without confirmed stock. How would you diagnose and resolve the root cause?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.