GitLab

Clearance Technical Debts

There are many causes that the technical debts have accumulated especially in clearance module.

• Required to implement the module as soon as possible (due to pandemic).
• Some specific AMTI departments have specific way of dealing with clearance routed to them.
• Some specific AMTI Approvers have specific timeline to process the clearance.
• Routes are dynamic and varies to employee application.
• Unforeseen specification that was eventually needed and was not advised early on regarding such scenario.
• I'm partly to blame as I haven't expected such features to be requested.

However, this is not a wiki to discuss the reasons why I have technical debts.

Tech Debt 1: Approver and Route Management

Managing route and approvers is identical as it relies heavily on the AIS Hierarchy Module. This can be solved in a single module page only by filtering the clearance Form Types only - AFC and - ONSITE.

But I have planned to separate this inside a single web page but have two (2) tab page to separate the data tables per form allowing us also to have separate Add, Edit and Archive.

Changing the forms

Ongoing Solution for solving this: Route Management

Tech Debt 2: Sales Logistics Special conditions

This is a requirement that was only brought up after the day the clearance has been implemented. The approvers of the Sales Logistics Department (Part of the standard route) should be dynamic according to employee department.

Sales Logistic Department has many BU/Teams under its wing, and those BU or Business Units are managed by two (2) AMTI Employees.

"In my current tenure, the Sales Logistics Approver is Ma'am Donna Perez have two AMTI employee's under her. Ma'am Lorry and Ma'am Jaymee. This is an unhandled on the initial implementation of the clearance module. However a work around was made to comply their requirements. - matt"

    # The following code is at:
    # FILE: clearance.php
    # CLASS: Clearance
    # FUNCTION: addClearance()
    case 'AFC':
        $clearanceId = $this->clearance_model->insertClearance($clearance); // insert clearance
        // ======= SPECIAL SCENARIO FOR SALES LOGISTICS UNDER MA'AM DONNA. =======
        $msJaymee = ['D0066', 'D0053', 'D0040', 'D0004', 'D0005', 'D0072', 'D0007', 'D0008', 'D0009', 'D0044'];
        $msLorry = ['D0010', 'D0022', 'D0027', 'D0028', 'D0029', 'D0030', 'D0012', 'D0023', 'D0024', 'D0025', 'D0026', 'D0032'];
        $salesSubApprover = null;
        // if employee is under ms.Jaymee. Remove (51 = Miss Lorry) 
        if (in_array($clearance['dept_ID'], $msJaymee)) $salesSubApprover = '51';
        // if employee is under ms.Lorry. Remove (21 = miss jaymee)
        else if (in_array($clearance['dept_ID'], $msLorry)) $salesSubApprover = '21';
        $clearanceRoutes = $this->clearance_model->routesAFC($clearance['supervisor_id'], $salesSubApprover);
        echo json_encode(['code' => '0', 'msg' => 'success']);
        $isClearanceInserted = true;
        // ===================== SPECIAL SCENARIO ENDS HERE =======================
        break;

Prospect solution: This could be solved in a single table inside the clearance database to be a managed data. But this must be in synced with the current sub-approvers of Sales logistics. Else this could pose an error to the function.

Tech Debt 3: Clearance Routes is inserted on clearance submit application .

This is an old tech debt that I am fully aware of since the day of implementation but unable to publish the updates due to the requirements being requested occasionally outdating the pending updates further more.