9.2 Incompletion Procedures, Status Groups, and Log Configuration

Incompletion Procedures, Status Groups, and Log Configuration

In high-volume commercial enterprises, sales orders are frequently initiated with partial information. A customer service representative might receive an order over the phone with an agreed product quantity and price, but the buyer has not yet confirmed the final receiving plant dock, payment method, or Incoterms destination clause.

Rejecting incomplete orders outright creates friction, hampers customer service, and loses revenue. Conversely, allowing incomplete orders to flow unchecked into warehouse shipping systems causes picking errors, stuck shipments, and unbilled receivables. The SAP S/4HANA Incompletion Control framework resolves this operational dilemma by allowing documents to be saved as drafts while selectively applying targeted execution blocks to downstream logistics and billing activities.

---

The Architecture of Incompletion Control

Incompletion processing is governed by four interdependent customizing elements:

1. Incompletion Procedures (OVA2 / TVUV): Catalogs of critical technical fields that must be populated.
2. Status Groups (TVUVS): Control switches that dictate which downstream business processes (delivery, billing, pricing, goods issue) are blocked if a field is missing.
3. Assignment to SD Objects: Linking procedures to document types, item categories, schedule line categories, partner functions, and delivery documents.
4. Incompletion Log UI: Interactive interface allowing users to review missing data and navigate directly to the target dynpro screens to resolve omissions.

┌────────────────────────────────────────────────────────┐
│         Incompletion Procedure (Table TVUV)            │
│  Field: VBKD-INCO1 (Incoterms 1)                       │
│  Screen: 4301 (Commercial Header Screen)               │
│  Status Group: billing-only example group              │
└───────────────────────────┬────────────────────────────┘
                            │ Assigned via VUA2
                            ▼
┌────────────────────────────────────────────────────────┐
│         Sales Document Type OR (Standard Order)        │
│  Order saved without Incoterms                         │
│  Result: VBAK-UVALL = incomplete (general)             │
│          VBAK-UVVLK = complete for delivery            │
│          VBAK-UVFAK = incomplete for billing           │
└────────────────────────────────────────────────────────┘

---

Incompletion Procedure Structure (Transaction OVA2 / Table TVUV)

In transaction OVA2, incompletion procedures are defined for specific Sales Objects:

• A — Sales Document Header (VBAK, VBKD)
• B — Sales Document Item (VBAP, VBKD)
• C — Schedule Lines (VBEP)
• D — Partner Functions (VBPA)
• E — Sales Activities
• F — Delivery Header (LIKP)
• G — Delivery Item (LIPS)

Field-Level Customizing Attributes

Within an incompletion procedure (table TVUV), each field record contains five essential parameters:

1. Table Name: The database table hosting the field (e.g., VBAK for header, VBAP for item, VBKD for commercial terms, VBPA for partners, VBEP for schedule lines).
2. Field Name: The technical field name evaluated for completion (e.g., INCO1 for Incoterms 1, ZTERM for Payment Terms, WERKS for Plant, ROUTE for Route, BSTKD for Customer PO Number).
3. Screen Number (Dynpro): The specific SAPGUI screen number or Fiori UI fragment to which the system navigates when the user clicks Complete Data in the log.
4. Status Group: A 2-digit alphanumeric key (table TVUVS) that defines which specific business actions are blocked when this field is blank.
5. Warning Flag: If activated, the system issues a warning message during document entry when the field is empty; the field is still recorded in the incompletion log according to its status group.

---

Status Groups and Execution Blocks (Table TVUVS)

A Status Group is a collection of logical control flags (switches) stored in table TVUVS. It decouples the missing field from the operational penalty. Instead of every missing field blocking the entire order, the status group specifies exactly which downstream documents are restricted.

The Switches in a Status Group

A status group contains indicators for the functions it affects: general (the document counts as incomplete), delivery, billing, price, goods movement, picking/putaway, and packing. If a field with that status group is missing, the marked functions are blocked or flagged; the unmarked functions can continue.

Example Status Group Design

The status groups delivered with your system have their own keys and settings, so check them in Customizing. A typical design separates the consequences like this:

---

Incompletion Procedure Assignments across SD Objects

Once procedures are constructed, they must be assigned to transactional customizing:

                                Incompletion Procedures
                                           │
        ┌───────────────────┬──────────────┴─────┬───────────────────┐
        ▼                   ▼                    ▼                   ▼
┌───────────────┐   ┌───────────────┐    ┌───────────────┐   ┌───────────────┐
│ Sales Doc Type│   │ Item Category │    │ Schedule Line │   │ Partner Role  │
│ (Trans. VUA2) │   │ (Trans. VUP2) │    │ (Trans. VUE2) │   │ (Trans. VUPA) │
└───────────────┘   └───────────────┘    └───────────────┘   └───────────────┘

1. Assign to Sales Document Types (Transaction VUA2)

• Links a Header Incompletion Procedure (e.g. 11 - Standard Order Header) to a Sales Document Type (e.g. OR / TA).
• Incompletion Messages Indicator (sales document type, VOV8): If set, an incomplete document cannot be saved: on save, the system shows the incompletion log and the user must complete the data first. If not set, the system points out the missing data when saving, but the user can save the document as incomplete.

2. Assign to Item Categories (Transaction VUP2)

• Links an Item Incompletion Procedure (e.g. 20 - Standard Item) to an Item Category (e.g. TAN, TAD, TAP).
• Enforces line-level data completeness, such as plant, storage location, gross weight, or item cost.

3. Assign to Schedule Line Categories (Transaction VUE2)

• Links a schedule line procedure to schedule line categories (e.g. CP, CN).
• Evaluates missing delivery dates or confirmed logistics quantities.

4. Assign to Partner Functions (Transaction VUPA)

• Links an incompletion procedure to individual partner functions. Evaluates missing street addresses, postal codes, or tax identification numbers.

5. Assign to Delivery Types and Delivery Item Categories (Transactions VUA4, VUP4)

• Controls incompletion in deliveries, where missing fields can block picking, packing, goods issue, or billing (section 7.6).

---

End-User Experience: The Incompletion Log

When working in transaction VA01 or VA02:

1. The user can manually inspect document completeness at any time via menu path: Edit $\rightarrow$ Incompletion Log.
2. The system displays a structured tree view listing all missing fields, categorized by Header, Item, and Partner levels.
3. The user double-clicks an entry or selects the row and clicks Complete Data (F5).
4. The system automatically navigates directly to the target Dynpro screen (configured in TVUV), positioning the cursor on the missing input field.
5. Once the missing data is entered, the item disappears from the log. When all entries are cleared, the system displays the confirmation: "Document is complete."

---

Lists of Incomplete Documents

Besides the log of a single document, sales users work with lists of incomplete orders (for example, transaction V.02 or the corresponding SAP Fiori apps), which show all incomplete documents of a sales area so they can be completed in one pass.

S/4HANA Status Table Architecture Simplification

In legacy SAP ERP Central Component (ECC), document incompletion status was stored in dedicated header and item status tables:

• VBUK — Sales Document Header Status
• VBUP — Sales Document Item Status

The S/4HANA Clean Architecture

In SAP S/4HANA, as part of the simplified data model, tables VBUK and VBUP were eliminated to remove database locks and optimize high-throughput database inserts. Status fields are now embedded directly within the primary transactional document tables: