Skip to content

Employee leave management

This operation manages EMPLOYEE_LEAVE rows through a mix of direct retrieval SQL and pk82029_titan package calls. The business object validates required fields and date boundaries before any write path executes.

Field Value
Operation ID OP-SB-03
Trigger Caller invokes leave factories or persists a clsEmployeeLeave object.
Inputs Leave sequence, employee ID, investigator, reason, begin/end dates, system type, update user
Outputs clsEmployeeLeave, clsEmployeeLeaveCollection, or write success/failure state
Primary components clsEmployeeLeave.NewEmployeeLeave, clsEmployeeLeave.Criteria.BeforeRetrieve, clsEmployeeLeave.BeforeInsert, clsEmployeeLeave.BeforeUpdate, clsEmployeeLeave.BeforeDelete, clsEmployeeLeaveCollection.GetEmployeeLeave
Entry point Business\SAIF.Business\clsEmployeeLeave.vb

Steps

  1. New-record creation allocates a fresh leave sequence from the framework, stamps the current system type, and initializes create metadata before the object is returned to the caller.
  2. Validate blocks persistence unless investigator, reason, begin date, and end date are all populated (BR-SB-001).
  3. The same validation path rejects begin dates earlier than 1753-01-01, rejects end dates earlier than today, and rejects begin dates later than end dates (BR-SB-002).
  4. Single-record retrieval builds a direct SQL statement keyed by leave_sequence_num and hydrates the business object from EMPLOYEE_LEAVE when the row exists (SQL-027, EMPLOYEE_LEAVE).
  5. Collection retrieval packages the employee ID, system type, and current start date into pk82029_titan.select_employee_leave and materializes the returned rows into a clsEmployeeLeaveCollection (SQL-028, EMPLOYEE_LEAVE).
  6. Insert persistence sends the validated object state to pk82029_titan.Insert_employee_leave, which writes the new EMPLOYEE_LEAVE row (SQL-002, EMPLOYEE_LEAVE).
  7. Update persistence calls pk82029_titan.update_employee_leave, passes the current UpdateUser, and expects the package to report one affected row (SQL-046, EMPLOYEE_LEAVE, BR-SB-013).
  8. If the package does not return exactly one updated row, the object treats the save as a failure.
  9. Delete persistence calls pk82029_titan.delete_employee_leave and also expects a single-row success result (SQL-047, EMPLOYEE_LEAVE, BR-SB-014).
  10. If the delete result is not one row, the caller receives a failure state instead of silent success.
  11. When the caller asks for the related employee object, the leave entity resolves it through clsEmployeeData.GetDataByEmployeeID, allowing directory metadata to be displayed alongside the leave record.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([Leave request]) --> Validate[Validate required fields and dates]
    Validate --> Valid{Validation passed?}
    Valid -->|No| Reject([Return broken rules])
    Valid -->|Yes| Action{Retrieve or write?}
    Action -->|Retrieve| Read[Run direct SQL or package select]
    Action -->|Insert| Insert[Call insert package]
    Action -->|Update| Update[Call update package]
    Action -->|Delete| Delete[Call delete package]
    Read --> Return1([Return leave data])
    Insert --> Return2([Return persisted leave])
    Update --> Return3([Return update result])
    Delete --> Return4([Return delete result])

Failure and edge-case behavior

  • Missing investigator, reason, or date fields stop the operation before any database write occurs (BR-SB-001).
  • Out-of-range or reversed dates are rejected before insert or update processing (BR-SB-002).
  • Update and delete paths treat non-1 row counts as failures because the object expects exactly one affected row (BR-SB-013, BR-SB-014).

Sources

  • Business\SAIF.Business\clsEmployeeLeave.vb