NextGen FSM
NextGen FSM
Breadcrumbs

Cancellation process

Cancel Procurement Request & Positions: Functional Overview

Based on the latest technical implementation, the cancellation functionality has been completely restructured to support a seamless workflow both before and after a Procurement Request (PR) has been transmitted to an external system (e.g., SAP).

The system now intelligently distinguishes between simple internal cancellations (pre-integration or error states) and complex asynchronous cancellations (post-integration) that require grouping by material Reservation Codes and waiting for external confirmation.

Phase 1: Action Visibility & Eligibility Rules

The UI dynamically enables the cancellation actions at both the Header and Position levels based on precise state conditions.

Header-Level Cancellation Eligibility:

The "Cancel PR" action is visible and enabled if the PR Header status is:

  • Draft

  • Open

  • Authorization Pending

  • Successfully Sent (Sent OK)

Position-Level Cancellation Eligibility:

The "Cancel Position" action is available for an individual material line only under these specific combinations:

  • Pre-Integration: Header is Draft or Open AND Position status is not Cancelled.

  • Error Recovery: Header is Sent with Errors AND Position status is Technical Error or To Review.

  • Post-Integration: Header is Successfully Sent AND Position status is Sent.

Phase 2 - A: Execution Logic (Pre-Integration & Error States)

When the user cancels items that have not yet been successfully acknowledged by the external ERP, the execution is immediate and synchronous.

  • Trigger: The user cancels a position in an early state (Draft/Open) or an isolated failed line (Tech Error/To Review).

  • System Action: The system logically deletes the row by updating the position status directly to Cancelled. No external communication is required.

Phase 2 - B: Execution Logic (Post-Integration via Reservation Code)

When a PR has already been transmitted to SAP (Successfully Sent), cancellation becomes an asynchronous request driven by the Reservation Code.

  • Item Grouping: In external systems, multiple items can share a single Reservation Code. Therefore, canceling a Sent item triggers a request to cancel the entire Reservation Code.

  • User Confirmation: When a user clicks cancel on a Sent item, the system extracts its Reservation Code and displays a mandatory alert: "The cancellation request of reservation code {X} will be sent. Continue?"

  • Strict Validation: The system verifies that ALL positions sharing that Reservation Code belong to the same PR Header and are currently in the Sent status. If any item is in a different status, the action is blocked with an error.

  • System Action: If validated, the system updates all affected items to Cancellation Pending and publishes a notification event to the integration layer (SAP).

  • Header-Level Trigger: If the user cancels the entire PR from the Header while in Successfully Sent, the system automatically gathers all Reservation Codes associated with Sent items and dispatches cancellation requests for each one simultaneously.

Phase 3: External Confirmation Workflow (APIs)

Because post-integration cancellations are asynchronous, the system exposes specific endpoints to receive the external system's decision.

  • Cancellation Confirmed: SAP approves the cancellation. The system processes the incoming API patch and transitions the affected items from Cancellation Pending to Cancelled.

  • Cancellation Rejected: SAP denies the cancellation (e.g., the material is already on a truck). The system processes the rejection and reverts the items from Cancellation Pending to Sent. (Note: If an item somehow reached a final state during this window, it remains untouched).

The system also supports a global Header-level confirmation API that cascades the confirm/reject decision to all pending Reservation Codes within that specific PR.

Phase 4: Header Status Recalculation

To ensure absolute alignment between the line items and the master document, the PR Header status is dynamically recalculated based on the following strict priority rules:

  1. Sent with Errors: If there is at least one item in To Review or Technical Error, the Header becomes Sent with Errors.

  2. Cancelled: If ALL items within the PR are strictly in Cancelled status, the Header becomes Cancelled (Terminal state).

  3. Cancellation Pending: If ALL items are a mix of only Cancelled or Cancellation Pending statuses, the Header becomes Cancellation Pending.

  4. As-Is: If none of the above apply, the Header retains its calculated operational status (e.g., Successfully Sent).