- Demos of Completed Work
- Discussion Items
- Identify and estimate work for this Sprint
On the legacy ODJFS report it is counting attendance outside of the quarter date range. It seems to be calculating any week (starting on Sunday) before the quarter into the count week calculation. An example is a person who had attendance on 9/30/2014 (a Tuesday) the legacy report is going back to that Sunday (9/28/2014) and counting this attendance on the 4th quarter ODJFS report. Alternatively, the legacy report excludes the 9/30/2014 date from the 3rd quarter. The redesign report does not work this way, the date has to be within the quarter date range to get counted in the count week. Is this correct?
Is the TransactionManagerTest needed? A repository call starts a new transaction, this test does not seem to accomplish anything asserting that an object was saving within the TransactionManager.
ODJFS Max Weeks is not implemented. This will need to be added after adjustments are added from USPSR-1389
Cascade Types for the following relationships will need to be discussed.
- Absence/Attendance @OneToOne with LeaveTransaction. This will still need a REMOVE cascade. When we remove the Absence/Attendance we need the transaction to be deleted also. We have a listener but we only pass the UUID of the Absence/Attendance when deleting and the LeaveTransaction doesn't have a reference back to the Absence/Attendance.
- The Position @OneToOne with PayrollAccounts causes some really annoying code. Because this is a bidirectional reference one object must be persisted before setting the reference to the other. Also OrphanRemoval has to be true. I believe we can make make this a unidirectional relationship. A quick search shows we don't use position.payrollAccounts that often. We could just hit the database instead.
- The pages that need to MERGE an employee use the query pager. So I think we will need to add listeners to update the Employee (and other objects that need it) if we are going to let them edit different objects on the same page.
AchSource is currently being useded as a @ManyToOne reference inside of the Ach-Submission package (AchSource @ManyToOne DirectDeposit. We should discuss if this is correct since the relationship is labeled @OneToOne
EmployeePayRepository.getByNumberAndPayroll method takes an Employee and a Payroll object. The name is misleading, I feel like it should be named "getByEmployeeAndPayroll".
Default Job Calendar issues:
- Default job calendar of '$$$' is created if neither compensation nor position's pay group has a calendar on import (warning is issued)
- PositionPay, OdjfsChunkProvider and RetirementServiceImpl check specifically for a jobCalendar of "DEF"
- FuturePayAmountImportImpl (line 146) creates a compensation (and hence a job calendar) if it doesn't already exist - should this be an error instead?
FuturePayAmount handling in PayrollServiceImpl: instead of reading through all positions (including inactive) and looking up futurePayAmounts, futurePayAmounts are searched directly instead. If the employeePay/positionPay already exist in the payroll, the new payAmount is added, otherwise they are generated while processing futurePayAmounts.