NextGen FSM
2026 Wave Two 2026 Wave One 2025 Wave Two 2025 Wave Three
NextGen FSM
2026 Wave Two 2026 Wave One 2025 Wave Two 2025 Wave Three
Breadcrumbs

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.