1. Possible cause is that the "Year 2025" Balance for SL10 is -8 hours
2. This could be adding up on the transaction report showing a 72 hour (less by 8 hours) opening balance
3. Leave allocation screen is correct in its opening balance value
4. Transaction listing is correct as it shows the overdrawn amount for SL10 in year 2025

Next step:

1. Investigate how this was processed when SL10 has a "Minimum allowed balance" of 0.
2. Review Payslip report to determine if showing the overflow of Year 2025 balance is the corrrect reflection of this leave, or if this needs to be ignored

Hi guys, I have done the investigation for you. All this data can be seen from the front screens.

Here is my analysis:

1. When the user rolled over 2025, the leave adjustment showed as 56 hours unused.
2. On the 6th of January 2026, after rolling over, A leave entry was backdated to 29/12/2025 and marked as Taken. This caused the 2025 Leave balance of 56 hours to be off by 8 hours
3. The pay calendar for DEC 2025 was closed at 7am on the 6th Jan 2026

The system does not let us do this. 

The only way to correct this is to reduce the "56" hours to"48" hours to allow for the leave that was processed in Jan 2026 but dated Dec 2025.

I will need to investigate further as to what the issue is.

The following steps were taken on Waseli database:

1. Database from 01/01/2026 was restored. 
2. Calendar is in December 2025
3. Leave transaction ID LE0003092 is dated 30/12/2025 is approved and can be marked as taken before December 2025 is closed. Payslip is correct. Opening balance shows 80. 
4. If Leave transaction ID LE0003092 is marked as taken, and the year is closed and moved to Jan 2026. Payslip is correct. Opening balance shows 80hrs. Previous years (2025) SL10 adjustment is 48 hrs
5. If Leave transaction ID LE0003092 is not marked as taken, and the year is closed and moved to Jan 2026. Leave transaction ID LE0003092 will no longer be able to close. Payslip is correct. Opening balance shows 80hrs. Previous years (2025) SL10 adjustment is 56 hrs

Conclusion

1. We have not been able to break the Payslip using the front screens

Next Step

1. Check what version the client was on the 6th January 2026 when the issue happened.
2. Need to find out how this happend before we decide on a correction. 
3. Ask EDGE to help explain how this could have been done and if there are other databases that have this same issue

Investigation notes:

1. Client was on Version 15.90 on the 6th of Jan 2026
2. Restored database and setup version 15.90
3. Processed leave transaction ID LE0003092 while leave calendar was in december 2025, then rolled over to 2026. Leave allocation and balance is reflected correctly. Opening balance shows 80hrs. Previous years (2025) SL10 adjustment is 48 hrs. Payslip is correct.
4. Restored database to test processing leave in 2026
5. Rolled over year to 2026. Opening balance shows 80hrs. Previous years (2025) SL10 adjustment is 56 hrs. Payslip is correct.
6. Processed leave transaction ID LE0003092 (December 2025) while leave calendar was in 2026. System does not allow this as leave is dated December 2025 while current leave is in 2026

Conculsion:

1. The system is correctly handling leave allocation and rollover. Therefore we don't have any corrections to make.
2. This seems like a data correction issue for specific clients.
   

Next step:

Option 1 - Change payslip to use  current leave allocation (instead of history transactions) to display leave details.

Option 2:

1. Edge to setup clients databases on QA5 that need this correction.
2. For each client, provide which leave is incorrect
3. We will then create a corection script
4. For Walesi, we will use the existing training database to reduce the hours of Employee: WPL0022 from 56 to 48 (for 2025 SL10)

In the process of testing Leave Accrual and Rollover in the demo evironment to confirm rollover correcltly reflects in the pay slips.

First 12 months processing correctly reflects.

Next step. Rollover and process year 2.

The plan is:

1. To conform the system is corrrectly processing leave. If this is the case, we will need to look at each clients data individually.
2. If leave calculation and rollover is incorrect, we can make the corection and issue a script to address the issue.

Completed processing multi year leave with Sick Leave, Breavement Leave and Annual Leave across multiple years. All balances are correct and show correctly n the pay slip.

Next step:

1. Review Walesi leave and see what the issue is for client WPL0022

Hi guys, the analysis of employee "WPL0022" shows the following:

1. For leave year 2024 - When the initial leave was setup,it was configured for 64 hours brought forward. The system then allocated 80 hours as it was configured this way. This has caused a cascading effect as this leave was initially setup to "carry Forward"
2. For leave year 2025 - 8 hours leave was taken after the SL10 was rolled over to 2026. this created 8 hours overdrawn.

To correct this, we need to do the following:

1. VOID leave for 2024 as it was incorrectly imported/initiated
2. VOID leave transadction 'LE003092' as it was processed after the leave was closed.

I have applied this to the AZURE training environment.

Next step:

1. Review employee WPL0022 and confirm this is correct
2. Meet with Sanjay to determine the next steps in other leave issues and how to find them
3. Make corrections

@Sitla, please complete item 1  and update this case with results so I can rrange a meeting for item 2.

1. The change will be available in version: 16.02.260326

2. The following changes were made (Include Database object names, Program classes, and any other relevant information):

1. Added the option to Edit "Leave Allocation" and "Leave Allocation History" so that users with "EDIT" access can edit the "VOID and NOTES" fields when Leave entries need correction.

3. Affected Areas:

1. Menu "Leave Management ~> Leave Allocation", Detail Section Tab Named "Leave Allocation History"

4. The issue was caused by:

1. Added feature to allow users to correct Leave Allocation History

5. Other Relevant Notes: 
6. Next Step (Review and System Test (Developer) -> UAT (Quality) -> Documentation): UAT and completion of tasks allcated

PART B - Development Reference (Place descriptor for objects changed): IMPORTANT NOTE - Users access to EDIT and DELETE needs to be revised to ensure users do not inadvertently edit Leave History.

No response from @Edge - See comment 17

Closing case as the change to facilitate VOID incorrect leave has been implemented.