tbl_expenceapproval

Primary key
Format: Long (auto-increment)
Used as: Unique identifier for each approval workflow record.

FK: public.tbl_company.CompanyID
Purpose: Scopes the approval record to a specific company in multi-tenant implementations.
Usage: Ensures company-specific approval workflows and data isolation.
Business Logic: Different companies may have different approval hierarchies and rules.

FK: public.tbl_ExpenceClaimMaster.ExpID
Purpose: Links this approval record to the specific expense claim being processed.
Cardinality: One-to-One relationship (each expense claim has one approval record).
Usage: Establishes direct relationship between claim details and approval workflow.

Format: String
Purpose: Approval decision from the first-level representative in the workflow.
Common Values:
- “PENDING”: Awaiting first approver review
- “APPROVED”: First approver approved the claim
- “REJECTED”: First approver rejected the claim
- “RETURNED”: Returned to employee for clarification
- “ON_HOLD”: Temporarily paused for additional information
Business Logic: First approver typically the employee’s direct manager or department head.

Format: String
Purpose: Approval decision from the second-level representative in the workflow.
Common Values:
- “PENDING”: Awaiting second approver review (or skipped if Rep1 rejected)
- “APPROVED”: Second approver approved the claim
- “REJECTED”: Second approver rejected the claim
- “RETURNED”: Returned to first approver or employee
- “NOT_REQUIRED”: Second approval not needed based on amount or type
Business Logic: Second approver typically finance manager, senior management, or specific role-based authority.

Format: String
Purpose: Overall final status of the expense claim after complete approval workflow.
Common Values:
- “PENDING”: Still in approval workflow
- “APPROVED”: Fully approved and ready for payment
- “REJECTED”: Finally rejected by approvers
- “CANCELLED”: Cancelled by employee or system
- “PAID”: Payment processed successfully
- “PARTIALLY_APPROVED”: Partial amount approved
Business Logic: Derived from Rep1Status and Rep2Status based on approval rules.

Format: String
Purpose: Tracks the payment processing status after approval.
Common Values:
- “PENDING_PAYMENT”: Approved but payment not yet processed
- “PROCESSING”: Payment in progress
- “PAID”: Payment successfully completed
- “FAILED”: Payment processing failed
- “ON_HOLD”: Payment temporarily held
- “CANCELLED”: Payment cancelled
Integration: Links approval workflow with accounts payable or payment processing system.

Format: String
Purpose: Documents the reason for claim cancellation, rejection, or return.
Usage Examples:
- “Policy violation - expense exceeds category limit”
- “Insufficient supporting documentation”
- “Duplicate claim identified”
- “Employee cancelled request”
Audit Value: Essential for compliance and employee communication about decision rationale.

Format: String
Purpose: Additional comments or specific instructions from the second approver.
Usage Examples:
- “Please use corporate card for future hotel bookings”
- “Attach taxi receipts for all travel segments”
- “Approved as exception, update policy awareness”
- “Coordinate with project manager for budget allocation”
Business Use: Provides contextual feedback and process improvement suggestions.

Format: Timestamp
Purpose: Exact date and time when the first approver processed the claim.
Usage:
- Approval process SLA monitoring
- Approver performance analytics
- Audit trail for compliance requirements
- Workflow efficiency analysis
Business Logic: Captures when Rep1 made their decision, regardless of outcome.

Format: Timestamp
Purpose: Exact date and time when the second approver processed the claim.
Usage:
- End-to-end approval timeline analysis
- Bottleneck identification in approval workflow
- Compliance with approval policy timelines
- Second-level approver accountability
Business Logic: NULL if Rep2 approval not required or claim rejected at Rep1 level.

FK: public.tbl_employee.employeeid
Purpose: Identifies the employee who acted as first approver.
Usage:
- Approver accountability and authorization tracking
- Workload distribution analysis
- Approval authority validation
- Escalation path identification
Business Logic: Typically the employee’s direct reporting manager or designated department approver.

FK: public.tbl_employee.employeeid
Purpose: Identifies the employee who acted as second approver.
Usage:
- Final authorization accountability
- Cross-departmental approval tracking
- Senior management oversight
- Finance or compliance approval tracking
Business Logic: NULL if second approval not required based on amount thresholds or claim type.