The system currently employs a LIFO (Last in First Out) approach to accrual balances and how hours are used and expire. For example, lets say I earned hours a year ago that are due to expire tomorrow and I earned hours yesterday that expire a year from now. I then used some vacation today. The system will use the hours I earned yesterday first, instead of the hours I earned last year. My remaining balance will then expire tomorrow.
In the same example, if the system used FIFO accounting (First In First Out), the system would use my hours from last year, and my remaining balance would expire next year. I think this makes the most sense, especially if clients accrue time each week that expire in a year. The expiration date on accrueup doesn't really work in these situations, due to the accounting.
I am glad to see this has moved to Design and Discovery!
As a quick update, further testing on the accruals and expiration in the system revealed that expirations don't really follow LIFO rules either. Using "expiration" basically just sets a negative deduction for the balance, equal to the amount that was originally accrued, on the expiration date. This concept works well for an annual accrual that will expire at the end of each year. If the accrual runs any more frequently than that, then the expiration deduction will not take into account the time that has been used and it will incorrectly reduce the balance on the expiration date that was set in the accrual scripting.
I am happy to help in any way possible on this project. Please let me know if I can provide further information.
Attachments Open full size