NextGen FSM

Copy workflow

Copy Refused Procurement Request: Functional Overview

The Copy functionality allows an Operations Manager or Warehouse Clerk to duplicate a Procurement Request (PR) that has reached the Refused status. This feature is designed to speed up reprocessing after a submission failure, significantly reducing manual data entry efforts and minimizing errors when recreating similar requests.

When triggered, the system generates a new Procurement Request prefilled with the data from the refused one, resets all delivery and integration-related fields, and places the new document in a Draft status for user review.

Preconditions & Eligibility

The Copy action is conditionally available based on the current state of the document.

  • Status: The action is only visible and available when the Procurement Request header status is exactly Refused.

  • Supported Types: The copy operation is supported for both TR Linked and Independent Procurement Requests.

  • The new Procurement Request is generated only after all eligibility rules and validations are successfully passed.

Phase 1: Type Handling & Validation Rules

Before executing the copy, the system evaluates the PR type to enforce strict business rules:

  • Independent Procurement Requests: Copying is always allowed without cross-document restrictions. A new Independent PR is generated.

  • TR Linked Procurement Requests: * Validation Rule: The system strictly enforces a 1:1 relationship between an active PR and a Transfer Request (TR). For a given TR, only one PR may exist in a status other than Canceled.

    • Success: If there are no other active PRs associated with the same originating Transfer Request (meaning any other PRs are Canceled), the copy proceeds.

    • Failure: If another active PR exists for the same TR, the system blocks the copy operation entirely and displays a clear error message.

Phase 2: Data Initialization

New Header Initialization

When the copy is created, the new Header is generated with the following rules:

  • ID: [Read-only] A new, system-generated unique identifier is assigned.

  • Code: [Editable] Derived from the original Code, with a suffix appended containing the current date and time to ensure immediate uniqueness. The user can modify this before saving.

  • Description: [Editable] Derived from the original Description.

  • Header Status: Set to Draft. (This status may be updated later upon saving the purchase request).

Position (Line) Initialization

For each material position included in the original PR:

  • All base header and position data is copied over, EXCEPT the following fields which are strictly set to Null:

    • Delivered Quantity

    • Delivered Serials

    • Reservation Code

  • Line Status Re-evaluation: After copying the data, the system automatically re-evaluates the status of each individual row:

    • Complete: If all mandatory configuration fields are present.

    • Incomplete: If any mandatory fields are missing.

Phase 3: Save & Workflow Behavior

  • Edit Mode: Immediately after generation, the new Procurement Request opens directly in Edit Mode.

  • Modifications: The user can review and modify editable data (such as the Code or Description) before the initial save.

  • Standard Workflow: Standard Save logic applies, including all standard header and position validations. Once saved, the copied request behaves exactly as a newly created Draft or Confirmed request within the standard workflow.