Payment Request Workflow¶

This document outlines the complete workflow for the payment request process in the PRS system, from payment request creation to approval.

User Access Overview¶

The following user types have access to payment request functionality:

Workflow Diagram¶

flowchart TD
    Start([Create Payment Request]) -->|Save as Draft| S1[PR Draft]
    S1 -->|Edit| Start
    Start -->|Submit| S2[For PR Approval]
    S2 -->|Approve| Check{All Approvers<br/>Approved?}
    Check -->|No| S2
    Check -->|Yes| S3[Closed]
    S2 -->|Reject| S4[PR Rejected]
    S4 -->|Edit & Resubmit| S2
    S3 -->|API Integration| S5[Posted to Legacy System]
    S3 -->|Transfer Materials Request| GP[Generate Gate Pass]
    GP --> S6[Attach to Requisition Slip]
    PDF[Download PDF]
    Monitor[Amount Monitoring]
    S2 -.-> PDF
    S3 -.-> PDF
    S4 -.-> PDF
    Start -.-> Monitor

Status Definitions¶

Detailed Workflow Steps¶

1. Payment Request Creation¶

Actors: Purchasing Staff, Purchasing Head

Prerequisites:

• Purchase Order must be in For Delivery status
• Purchase Order must have associated invoice report
• Associated invoice report must have associated receiving report
• User must have "Create Payment Request" access

Actions:

• Create a new payment request linked to a purchase order
• Select and attach invoices related to the purchase order
• Review payment amount, this is the sum of selected invoices
• Check Tick Box if need to include INCIDENTAL COST
• Save as draft or submit for approval
• System auto-generates PR Number and PR Letter

Status Transitions:

• New → PR Draft (if saved as draft)
• New → For PR Approval (if submitted for approval)
• PR Rejected → For PR Approval (if resubmitted after rejection)

Business Rules:

• Each payment must reference the Purchase Order and related invoices and receiving reports
• Sum of selected invoice amounts determines the PR amount
• Payment terms must comply with the terms specified in the Purchase Order
• PR Number and PR Letter are auto-generated by the system
• At least one invoice must be selected to create/submit a payment request
• Invoices can only be attached to a payment request once, cannot be attached to another payment request
• PO Incidental Cost can only be applied to a payment request once upon submission, cannot be applied to another payment request
• The sum of all payment requests for a Purchase Order cannot exceed the total PO amount
• Payment Request Amount calculation: Total PO Amount - Sum of All Existing PRs = Remaining PO Amount
• Purchase Orders can only be closed when Payment Request amounts equal the total PO amount

2. Payment Request Approval Process¶

Prerequisites:

• Payment request must be in FOR_PR_APPROVAL status
• User must be assigned as an approver for the payment request

Actions:

• Review payment request details and supporting documents
• Approve or reject the payment request
• Add approval notes (optional for approval, required for rejection)
• Add additional approvers if needed (optional)

Status Transitions:

• FOR_PR_APPROVAL → CLOSED_PR (when all approvers approve)
• FOR_PR_APPROVAL → PR_REJECTED (when any approver rejects)

Business Rules:

• Approvers are processed in order by approval level
• Each approver can only approve once
• If any approver rejects, the entire request is rejected
• Additional approvers can be added during the approval process
• All assigned approvers must approve before status changes to CLOSED_PR
• Rejection requires a mandatory reason/comment
• Approval notes are optional but recommended
• See Detailed Approval Business Rules

3. Payment Request Rejection and Resubmission¶

Actors: Any assigned approver (rejection), Purchasing Staff/Head (resubmission)

Prerequisites:

• Payment request must be in For PR Approval status
• User must be an assigned approver (for rejection)
• User must have "Payment Request Approval" access (for rejection)

Rejection Actions:

• Review payment request and identify issues
• Reject the payment request
• Provide mandatory rejection reason/comment
• System sends notification to creator
• System to allow incidental cost to be used again

Resubmission Actions (by Purchasing Staff/Head):

• Receive rejection notification via notification bell
• Navigate to payment request via notification, dashboard, or related documents
• Click Edit button to modify the payment request
• Update editable sections (Request Details, Invoices)
• Resubmit for approval (no draft save option during resubmission)

Status Transitions:

• For PR Approval → PR Rejected (when rejected)
• PR Rejected → For PR Approval (when resubmitted)

Business Rules:

• Rejection stops the approval process immediately
• Rejection reason is mandatory
• Resubmission requires current approver to re-approve
• Purchase Order Details cannot be edited during resubmission
• At least one invoice must be selected for resubmission
• All approver statuses reset to pending upon resubmission

4. Payment Request Processing and Integration¶

System Process: Automatic upon full approval

Trigger: When payment request status changes to Closed

Actions:

• System automatically posts payment request to Cityland's legacy system via API
• Updates payment request with posting confirmation
• Sends notifications to relevant stakeholders

Business Rules:

• Only fully approved payment requests are posted to legacy system
• API integration is automatic and does not require manual intervention
• Successful posting cannot be reversed through the PRS system

5. Gate Pass Generation (for Transfer of Materials)¶

Actors: System (automatic process)

Prerequisites:

• Payment request must be fully approved (Closed status)
• Related requisition slip must have request type of:
• OFM Transfer of Materials, or
• Non-OFM Transfer of Materials

Actions:

• System automatically generates Gate Pass PDF
• Attaches Gate Pass to the related Requisition Slip
• Updates attachment badge with "New Attachment" indicator

Business Rules:

• Gate pass cannot be deleted as an attachment
• Gate pass opens in new tab when clicked
• Multi-page support with continued numbering and repeated headers
• Only generated for approved transfer of materials requests

6. PDF Download Functionality¶

Actors: Purchasing Staff, Purchasing Admin, Purchasing Head, Requester

Prerequisites:

• Payment request must be created and submitted (any status except draft)

Actions:

• Click Download button when viewing payment request
• System generates PDF with legal paper size
• PDF downloads with standardized filename

Business Rules:

• Filename format: Document Prefix + Date Extracted (YYYYMMDD), e.g., "PR20240728"
• Page headers retained on multiple pages with incremental page count
• Available for all payment request statuses except draft

Example Scenarios¶

Scenario 1: Standard Payment Flow¶

1. Purchasing Staff creates a payment request for an approved purchase order
2. Staff selects relevant invoices and submits for approval
3. Supervisor reviews and approves the request
4. Department Head reviews and provides final approval
5. System automatically posts to legacy system via API
6. Payment request status changes to CLOSED_PR

Scenario 2: Payment Request with Rejection¶

1. Purchasing Staff creates and submits a payment request
2. Supervisor reviews and rejects due to missing documentation
3. Staff receives notification and updates the request with required documents
4. Staff resubmits the updated payment request
5. Supervisor and Department Head approve the request
6. System processes the approved request through standard flow

Scenario 3: Payment Request with Gate Pass Generation¶

1. Purchasing Staff creates payment request for a transfer of materials requisition slip
2. Supervisor and Department Head approve the request
3. System changes status to Closed and posts to legacy system
4. System automatically generates Gate Pass and attaches to requisition slip
5. Requester receives notification of new attachment with badge indicator
6. Gate Pass PDF is available for viewing and cannot be deleted

Scenario 4: Payment Request Rejection and Resubmission¶

1. Purchasing Staff creates and submits payment request
2. Supervisor rejects due to incorrect invoice selection
3. Staff receives notification and navigates to rejected payment request
4. Staff edits request details and invoice selection (PO details remain locked)
5. Staff resubmits payment request (no draft save option)
6. Supervisor and subsequent approvers must re-approve the request

Scenario 5: Multiple Partial Payments with Amount Monitoring¶

1. Purchasing Staff creates first payment request for ₱500,000 of ₱1,000,000 PO
2. System validates remaining balance: ₱1,000,000 - ₱500,000 = ₱500,000 remaining
3. Request goes through approval and is approved
4. Later, staff creates second payment request for ₱600,000
5. System rejects creation as it exceeds remaining balance of ₱500,000
6. Staff adjusts amount to ₱500,000 and successfully creates request
7. Once second request is approved, PO is eligible for closure

Error Handling and Validation¶

Common Validation Rules¶

• PO Validation: Ensure Purchase Order exists and is approved
• Invoice Validation: Verify all selected invoices belong to the PO
• Amount Validation: Ensure PR amount doesn't exceed remaining PO balance
• User Authorization: Validate user permissions for each action
• Status Validation: Verify valid status transitions

Error Messages¶

• "Purchase Order not found or not approved"
• "Purchase Order must have delivery report and invoices to create payment request"
• "Selected invoices do not belong to this Purchase Order"
• "Payment request amount (₱{amount}) exceeds remaining Purchase Order balance (₱{remaining})"
• "At least one invoice must be selected"
• "User not authorized to perform this action"
• "Invalid status transition from {current} to {new}"
• "Rejection reason is required"
• "Payment request is not available for approval"
• "Cannot save as draft during resubmission - please submit directly"

Form Validation Rules¶

• Purchase Order Selection: Must have delivery reports and invoices
• Payable Date: Required, current date or future dates only
• Invoice Selection: At least one invoice required
• Amount Validation: Total cannot exceed remaining PO balance
• Resubmission: PO details locked, at least one invoice required