RlpController Manual

Requisition and Login Process (RLP) Module Documentation

1. System Overview

The RlpController is the core engine for managing Requisitions. It facilitates the creation, tracking, and multi-stage approval workflow of RLPs. It integrates material requirements with ledger/account tracking and uses a dynamic approval chain system.

2. Database Architecture

Below are the primary tables used by the RLP system:

Table Name Description
rlp_masters Primary header info (Date, User, Branch, Department, Status, RLP No).
rlp_details Line items for materials/items requested in the RLP.
rlp_account_details Account-specific head details and amounts related to the requisition.
rlp_acknowledgements Approval workflow status for individual users in the chain.
rlp_remarks History of comments/remarks made during the approval process.
rlp_access_chains Definitions of approval paths (e.g., Departmental, Project chains).
rlp_access_chain_users Users associated with specific approval chains and their sequence.

Status & Priority Reference

Common Status Codes:
  • 1: Approved & Locked
  • 3: Rejected
  • 5: New / Draft
  • 6: Partially Approved / Processing
Priority Levels:
  • Low, Medium, High
  • Influences sorting and urgency in the approval dashboard.

3. Core Models & Relationships

Key Eloquent models used in RlpController.php:

RlpMaster

The central model. Relationships include:

  • _item_detail: 1-to-many with RlpDetail.
  • _account_detail: 1-to-many with RlpAccountDetail.
  • _rlp_ack: Workflow tracking via RlpAcknowledgement.
  • _emp_department: Links to HrmDepartment.

RlpDetail

Handles item information. Links to Inventory (Items) and AccountLedger (Suppliers).

4. View Structure

The UI is organized within the resources/views/rlp-module/rlp/ directory:

  • index.blade.php: Listing page with advanced filters (Status, Date, RLP No, Priority).
  • create.blade.php: Complex multi-part form for new RLPs.
  • edit.blade.php: Interface for modifying pending RLPs (restricted if locked/approved).
  • show.blade.php: Detailed read-only view with approval history and status tracking.

5. Controller Functions Detail

index(Request $request)

GET
Fetches RLPs based on user permissions. For non-admins, it only shows RLPs where they are an active part of the acknowledgement chain.

rlpApproveReject(Request $request)

POST
The logic heart of the workflow.
  • Approve: Updates current user status and sets is_visible=1 for the next person in ack_order.
  • Revert: Moves visibility back to the previous order in the chain.
  • Reject: Sets rlp_status=3 (Rejected) in Master table.

store(Request $request)

POST
Atomic transaction to save the entire RLP. It calculates totals, saves master data, iterates through item/account rows, and crucially initializes the RlpAcknowledgement entries derived from the selected chain_id.

edit($id)

GET
Retrieves data for editing. Includes a _lock check; if an RLP is locked (approved or processed), editing is disallowed to maintain audit integrity.

6. Step-by-Step Process Flow

1
Initiation User fills the RLP form. They must select an Approval Chain which determines who will approve the request.
2
Validation & Submission System validates required fields (Prefix, Priority, Organization) and saves items to rlp_details.
3
Chain Initialization Upon save, the system creates records in rlp_acknowledgements for all users in the selected chain. The first user (Creator) is marked approved, and the 2nd user becomes visible.
4
Approval Loop Approvers receive visibility. When they click 'Approve', the ack_order increments, notifying the next person. If the order reaches '4' or the final stage, the RLP moves to 'Approved' status (Status 1).
5
Finalization Approved RLPs are locked (_lock=1) and can then be processed for Note Sheets or Procurement.