TABLE OF CONTENTS


Recently shipped as our newest system automation, the AEF Asynchronous Validation (aka AEF Async) is a significant design improvement that completely changes your experience of checking and approving filed AEFs. 


What is the purpose of AEF Async?


It’s been designed to perform the following: 1) validate the data encoded on filed forms, and 2) speed up the acceptance of filed forms, all the while the system handles complex business rules. 


The workflow goes as: While the system cross-checks every bit of the user information along with the business rules and system requirements, it validates and then accepts the filed forms. 


In the past, the system did all of these in the front-end (web validation). 


What was the challenge before? We observed that there was too much data being processed in the front-end, causing a slow response in the acceptance of filed forms.


That’s when it hit us - we aim to make the system validate lots of information quickly without sacrificing user experience therefore, we came up with the idea of classifying validation conditions that are to remain in the front-end (web validation) and that are to be moved to the back-end for our worker validation.



How does the AEF Async behave?


There are two (2) main points to emphasize about the behavior of our AEF Async: 1) validation of encoded data on filed forms, and 2) speeding up the acceptance of filed forms.


  1. Validate the Data Encoded on Filed Forms


Data validation is primarily checking if the filed form conforms with the system requirements, even with only the bare minimum. It validates the form by asking the following questions:

  1. Does the filed form have any duplicates?

  2. Has the user reached his/her maximum limit for filing forms?

  3. Does the filed form comply with the filing rules?


Nonetheless, the logic does not stop at this point as you may have noticed that there are 2 types of validation aforementioned. What’s the difference?


Basic Validation (Web)

    This refers to the validation process happening in the front-end, whereby parameters and conditions are quickly cross-checked with the AEF during its filing. The conditions retained on the front-end are the generic ones and are applicable to all AEF types. Examples of these conditions are effective dates, hiring dates, separation dates, adjustment limits, etc.


Customized Validation (Worker)

    This refers to the validation process performed on the server-side (worker), whereby more detailed conditions for certain form types are considered. Now, taking LOA as the sample form type, we have the following conditions for its customized leave credit validation in chronological order: maximum usage or limit, master schedule, consume first, leave on a non-regular day, change work schedule with different hours per day, no balance, and eligibility date.

        

Table 1: Validation Types and Their Conditions


Validation Types

AEF Types

BASIC VALIDATION (FRONT END)

CUSTOMIZED VALIDATION (BACKEND/ WORKER)

LOA

> Effective date < Separation date

> With Pay Freq Setup

> Effective date is within

> Adjustment Limit

> Check for filing date suspension

> Check for duplicate/combination of forms

> Check for max allowed forms per cutoff

> Effective date > Hire date

> Effective date within the prescribed filing date

> Leave Validation

1. Maximum Usage

2. Master Schedule

3. Consume First

4. Leave on non-reg

5. CWS with different hrs per day

6. No Balance

7. Eligibility date

CTO

> Effective date < Separation date

> With Pay Freq Setup

> Effective date is within

> Adjustment Limit

> Check for filing date suspension

> Check for duplicate/combination of forms

> Check for max allowed forms per cutoff

> Effective date > Hire date

> Effective date within the prescribed filing date

> CTO Validation

1. Master Schedule

2. CWS with different hours per day

3. CTO on non-reg

4. The filing date is not between the eligibility dates.

5. No balance

OT

> Effective date < Separation date

> With Pay Freq Setup

> Effective date is within

> Adjustment Limit

> Check for filing date suspension

> Check for duplicate/combination of forms

> Check for max allowed forms per cutoff

> Effective date > Hire date

> Effective date within the prescribed filing date

> Check OT Eligibility

> Check OT hours vs Cutoff hours account setup

> Check OT hours if, within Max OT hours setup per crew

CWS

> Effective date < Separation date

> With Pay Freq Setup

> Effective date is within

> Adjustment Limit

> Check for filing date suspension

> Check for duplicate/combination of forms

> Check for max allowed forms per cutoff

> Effective date > Hire date

> Effective date within the prescribed filing date

> Check shift vs MS setup and if with existing LOA form


  1. Speed Up the Acceptance of Filed Forms


Since the customized validation happens in the back-end, we have created 2 new form statuses as part of the AEF Async to show where the filed forms are in the process, namely “On Going Validation,” and “System Disapproved.”



After the filed form has gone through the validation process, its status will change to either System Disapproved or On-Going Validation.


System Disapproved

    This status appears right after an AEF, which did not meet the set validation conditions and system requirements, has been filed. 


On Going Validation

    This indicates that the system is still cross-checking set validation conditions against the filed form, which usually takes a few seconds before the filed form is accepted and the status becomes “For Approval.” 


With our enhanced workflow, we’ve expanded the system’s flexibility in terms of validation and accepting more complex business rules. 


Where can we see these changes?


The changes, especially the new statuses, are implemented on the AEF module, particularly on AEF Filed, Approval, and Inventory screens.