Confirm procurement request

Confirm Procurement Request: Functional Overview

The Confirm action triggers a structured, sequential validation process before allowing a Procurement Request (PR) to progress in the workflow. This functionality ensures that data quality is guaranteed prior to external transmission, strict governance is enforced, and integrations with external ERP systems are triggered reliably.

The system performs validations in a strict sequence:

• Header Validation

• Line Validation

• Threshold Evaluation

• Status Transition

• Event Publication

The process is atomic and stops at the first failed condition, returning actionable feedback to the user.

Preconditions & Availability

The Confirm action is systematically restricted. To trigger the confirmation process, the following conditions must be met:

• Status: The Procurement Request header status must be Open.

• Permissions: The operating user must have the proper authorization/permission to confirm the request.

• Note: If the PR is in any status other than Open, the Confirm action is completely disabled or hidden.

Phase 1: Header Validation

Upon attempting to confirm, the system first evaluates the master record (Header).

Validation Rules

• The Header status must be Open.

• A Responsible for Pickup must be explicitly specified.

• The assigned Responsible for Pickup must have a valid Identity Document attached to their master data profile.

• All mandatory header fields (as defined in the system's configuration parameters) must be fully populated.

Failure Behavior

If any of the above conditions fail, the process stops immediately. The system displays a clear error message indicating the missing or invalid field. No status changes occur, and no data is persisted beyond the manual corrections already made.

Phase 2: Line (Position) Validation

If the Header validation succeeds, the system proceeds to verify every individual material line linked to the request.

Validation Rules

For every position:

• Material is specified (Always mandatory).

• Requested Quantity is specified and > 0 (Always mandatory).

• All other mandatory fields defined via system configuration are present.

• The Position (Line) Status must be strictly Complete.

Failure Behavior

Validation stops at the first failing position. A specific error message guides the user to the exact line and field that requires correction. The user must fix the data before retrying the Confirm action.

Phase 3: Threshold Evaluation & Status Transition

Once all data integrity checks (Header and Lines) pass successfully, the system evaluates the request against configured authorization thresholds.

Standard Evaluation Logic

The system counts the total number of material positions in the PR and compares it to the configured threshold value:

• If Positions > Threshold:

  • Header Status transitions to Pending Authorization.

  • The PR is saved transactionally.

  • No external integration event is published yet (awaits manager approval).

• If Positions <= Threshold:

  • Header Status transitions to Confirmed.

  • The PR is saved transactionally.

  • The system proceeds to the Event Publication phase.

Extensibility Requirement

The threshold evaluation logic is designed as a pluggable component. Project implementers can override the default rule to support custom evaluation criteria (e.g., triggering authorization based on total financial amount, specific material categories, or warehouse types).

Phase 4: Event Publication (Integration)

If the Procurement Request successfully reaches the Confirmed status (either directly or after subsequent authorization), NextGen triggers the integration layer.

• The system publishes an event on the message queue asynchronously.

• Event Type: Procurement Request Ready for Delivery

• Payload: Includes essential tracking data (at minimum: PR ID, PR Code, and Timestamp).

• This event notifies the external system (e.g., ERP) that the physical material reservation can proceed.