High- Level Specification

Functional Overview

Business Requirement

For sales order items that are specification-based, the specification must remain fixed once production has started.
This ensures:

• Full alignment between Sales and Production

• Prevention of mismatches between planned vs. produced specifications

• Protection of product quality and compliance once manufacturing begins

In addition to locking specification fields, the business also requires control over other critical fields that impact production, and planning once a Process Order is in Released (REL) status.

1. Prevent changes to the Specification fields after Process Order Release.
   If the sales order item is spec-based and the linked Process Order is in Released (REL) status, no change to the specification fields at item level is allowed. This ensures alignment between Sales and Production, prevents mismatches between planned vs. produced specifications, and protects product quality and compliance once manufacturing has started.

2. Prevent changes to the Single Parent Batch indicator (ZZ_SINGLEPB) after Process Order Release.
   If the item is flagged for Single Parent Batch and the linked Process Order is Released, no change to this indicator is allowed. This ensures batch traceability, manufacturing consistency, and prevents downstream variance.

3. Issue a warning when the Confirmed Delivery Date is changed after Process Order Release.
   Changes to the confirmed date after production has begun may impact planning, ATP, loading schedules, and customer commitments; therefore, the user must be alerted.

4. Issue a warning when the Confirmed Quantity is changed after Process Order Release.
   Changing the confirmed quantity after the order is in production may impact material staging, availability checks, and production planning. A warning is required to make the CSR aware of potential downstream impacts.

Scope and Objectives

Scope and Objectives

This WRICEF covers a system validation enhancement in Fiori App: Manage Sales Orders – Version 2 (F3893) and in SAP GUI transaction VA02, executed during sales order change mode.

The objective is to:

• Detect when a sales order line item is linked to a Process Order

• Confirm whether the Process Order has system status REL

• Prevent any modification to Specification fields once REL status is reached

• Prevent any modification to the Single Parent Batch indicator (ZZ_SINGLEPB) once REL status is reached

• Issue a warning when the Confirmed Delivery Date is changed after REL

• Issue a warning when the Confirmed Quantity is changed after REL

• Display an error message and block the save action for fields that are restricted after REL

Apply this rule only to:

• Sales orders that have Specification IDs maintained at line item level

Ensure no impact to:

• Other Sales Orders

• Non–spec-based items

The Process Order link is determined via the Z-table maintained by the PCCD tool (“new IPA”). Jira-1022

WHY STANDARD IS NOT SUFFICIENT

SAP standard does not provide functionality to restrict updates to sales order specification fields based on the status of a linked Process Order.

Key limitations include:

• SAP does not cater for specification fields at sales order item level; these fields are custom (Z-fields). Therefore, standard SAP cannot control, validate, or freeze them based on production status.

• This is not a standard Make-to-Order (MTO) scenario; instead, the sales order and Process Order are connected via a “soft” link in Production. 

• No standard integration exists between specification data and the Process Order system status (REL).

• Standard logic cannot prevent late specification changes that would desynchronize Sales and Production.

• High operational risk remains that outdated or incorrect specifications could be used once production has already started.

The scope of this enhancement is depicted in process step Other Sales Order Changes below. For the full Signavio, please go to 02.04.02.09. Manage Sales Order Execution Exceptions

Assumptions

1. Process Order Linkage Is Available and Accurate

• The linkage between Sales Order Item → Process Order is derived from the Z-table maintained by the PCCD (“new IPA”) tool. https://syensqo.atlassian.net/browse/ERP-1022

• It is assumed that this table is correctly and consistently updated prior to any sales order change.

2. Process Order Must Be in “REL” Status to Trigger the Restriction

• The enhancement assumes that system status REL (Released) is the correct and only status during which specification fields must be frozen.

• Any earlier process order statuses (e.g., CRTD, PREL) will not trigger restrictions.

3. Only Certain Fields Are Blocked

• The enhancement restricts changes only to the following fields when the linked Process Order is in Released (REL) status:

  • Specification Z-fields (blocked)

  • Single Parent Batch indicator (ZZ_SINGLEPB) (blocked)

  • Confirmed Delivery Date (warning)

  • Confirmed Quantity (warning)

4. VA02 (SAP GUI) and the Fiori App “Manage Sales Orders – Version 2 (F3893)” are the user interfaces in scope for this enhancement, with the Fiori application serving as the primary UI.

5. Error and Warning Messages Will Enforce Controls

• For fields that are restricted after Process Order Release (REL)—namely the Specification fields and the Single Parent Batch indicator (ZZ_SINGLEPB)—the system must raise an error message.
  This error must block the user from saving the sales order.

• For fields that must remain editable but require user awareness—namely the Confirmed Delivery Date and Confirmed Quantity—the system must raise a warning message.
  Warnings must allow the user to continue and save the sales order.

6. Applicable Only to Open Sales Orders

• The enhancement applies only to sales orders that are still open.

• Orders that are fully delivered, billed, or otherwise closed are excluded from scope.

Dependencies

• The linking between the Sales Order and the Process Order within PCCD. https://syensqo.atlassian.net/browse/ERP-1022 - Production Confirmation Consumption Dashboard (New IPA) Draft
• The Creation and Maintenance of Speficications at line item level:  https://syensqo.atlassian.net/browse/ERP-264
• The Creation and Maintenance of Speficications at line item level: https://syensqo.atlassian.net/browse/ERP-265
• ERP-622 Single Batch & Single Packing List Check Boxes

Security, Integrity and Controls

The enhancement will follow the SAP standard security and authorization framework.
The authorization to maintain these fields should be included in the Customer Representative Role as part of the Manage Sales Orders v2  - F3893 and VA02 (SAP GUI)

.

Configuration Requirements

Not Applicable

Language Requirements

Not Applicable

Special Requirements

Not Applicable

Design Rationale

Functional Requirements

This enhancement applies in Manage Sales Orders v2 (F3893) — the primary UI — and in VA02 (SAP GUI).

• Applicability Conditions for Restricting Specification and Related Field Changes

  Sales Order Item Processing Status Validation
  Specification and related field restrictions apply only when the sales order item’s Overall Processing Status:

  • VBSTT-GBSTA_BEZ ≠ Completed

  “No Spec Required” Indicator Validation 

  • https://syensqo.atlassian.net/browse/ERP-148
  • Restrictions apply only when: The “No Spec Req” indicator is not selected

• Sales Order → Process Order Linkage

The system must determine the linked Process Order via the existing Z-table maintained by the PCCD (“new IPA”) tool. https://syensqo.atlassian.net/browse/ERP-1022 - Production Confirmation Consumption Dashboard (New IPA) Draft

1. Specification ID Selection & Change Prevention

When the linked Process Order is in REL status:

• No new Spec ID may be selected via the Specification Selection Screen
  (Reference: ERP-148)

• The existing value in ZZ_SPEC_ID may not be changed.

• Any attempt to assign, replace, or update the specification must be blocked with an error.

• This rule applies even if the specification was previously defaulted.

2. Single Parent Batch Change Restriction

When the linked Process Order is in REL status:

• The Single Parent Batch indicator (ZZ_SINGLEPB) cannot be changed.
  (This includes selecting or deselecting the indicator.)

• Any adjustment must trigger a blocking error message.

3. Confirmed Delivery Date Change Warning

When the linked Process Order is in REL status:

A warning message must be issued when:

• The Confirmed Delivery Date (VBEP-BEDAT) is changed.

This is an informational control and does not block saving.

4. Confirmed Quantity Change Warning

When the linked Process Order is in REL status:

A warning message must be issued when:

• The Confirmed Quantity (VBEP-BMENG) is changed.

This is also informational and does not block saving.

5. Process Order Status Validation Logic

To determine whether restrictions or warnings apply, the system must evaluate the status of the linked Process Order using standard SAP tables.

1. Determine the Linked Process Order

Read the Process Order number from the Z-table maintained by the PCCD (“new IPA”) tool.

2. Retrieve the Process Order Object Number

• Read table AUFK using the Process Order number.

• Extract the Object Number from field: AUFK-OBJNR

3. Read Active Status Records (JEST)

Using AUFK-OBJNR:

• Read table JEST

• Filter for active statuses:

  • JEST-OBJNR = AUFK-OBJNR

  • JEST-INACT = space

• Retrieve status codes from field: JEST-STAT

4. Check for Released (REL) Status

• If any active JEST-STAT value corresponds to the REL (Released) status → Restrictions and warnings apply

• If REL is not present → All field changes remain allowed

5. Optional Status Text Retrieval

If status text is needed for display or logging:

• • Read table TJ02T using the status code from JEST to retrieve the status description.

6. Proposed Error Text:

• Specification changes are not permitted. The linked Process Order is already Released
• Delivery Date / Qty changed. Process Order is Released and may be impacted.

Proposed Technology to Use

Typically, an enhancement will be based on an existing SAP BADI / user exit. If this is the case, please provide the proposed details of the BADI / user exit.

Data Source Considerations

Include an overview of the source. Can be deleted if not needed.

Data Validation Considerations

Include an overview of the data validation requirement. Can be deleted if not needed.

Custom Tables

If any custom configuration tables are required, which will be read by the enhancement logic, then specify them here. Can be deleted if not needed.

Master Data

<Title Custom Table 1>

<Include an overview of the table and what it’s used for>

Configuration Table

Title Configuration Table 1

Include an overview of the table and what it’s used for

Selection Screen Enhancement

This section will give the details on the selection screen parameters, parameter type and whether it’s obligatory or not. This section can be used to define the Import Export parameters for Function Module or User Exit or Screens. Can be deleted if not needed.

Processing Logic

This section defines the detailed step-by-step logic implemented within the BAdI/User Exit to process the data received from the standard SAP program and database retrieval. It explains the operations performed on the data, the expected outcomes in different scenarios and how the system should behave in response to specific conditions.

Volumetrics

Provide volumetrics details: Initial load volumes, Number of Records, Expected Frequency, Expected Long term Growth)

Performance Considerations

Specify if there are any specific performance factors that need to be taken into consideration during development i.e. enhancement must be able to be executed by 10 users at the same time, etc.

Error Handling

Detail how errors will be handled: Notification, Restart/ Recovery and Re-Processing Procedures

Testing

How to Test

Please provide some guidance and/or test data to help the developer unit test the enhancement. Please include both positive and negative testing (to validate error situations handling). The developer will need to test repeatedly, so where appropriate provide instructions to reverse the actions performed so the test may be run again or explain how to create new input data to the test. The developer will need logons for test users representing the various roles within the approval process.

Test Conditions and Expected Results

Test Considerations/Dependencies

List any considerations essential for application test planning (e.g., test this before ABC along with DEF separate from GHI). If the development encompasses a user interface, explain how to test it. List any insights as to how this component could be tested the most efficiently.

Other Information

Development Details

Package

Enhancement Implementation

Other Development Objects

Appendix

Custom Authorization Group Naming Convention

This table is based on the Syensqo development standards document. It provides the naming conventions for authorization groups to associated with custom reports and tables to comply with security requirements.

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log