Child pages
  • Sprint 136
Skip to end of metadata
Go to start of metadata



  • Retrospective
  • Demos of Completed Work
  • Discussion Items
  • Identify and estimate work for this Sprint


Discussion Items

  1. Currently some pages that have nested beans that are edited in their own window behave differently. i.e. Position's compensation editor, saves/updates the position then refreshes the bean in the position editor. Current Pay will not save until the Aggregate is saved. Both work, but we should discuss which way we want all views that are applicable to behave. 
    1. May want to have this discussion with USAS as well. We tend to like the idea of deferring the save of compensations until the position save button is clicked, however in this case we need a way to notify the user the unsaved changes are pending. 
  2. When importing district data to test the preview release, I imported on the pay date of the last completed payroll for the district.  Therefore, any max amount payroll item was stamped with a specific date to calculate payroll item history from.  The importer uses the date the imports are ran, so the specific date on the max amount payroll items matched the pay date of the last payroll ran by the district.  When I ran the next payroll, the method that calculates the amount withheld from history then included amounts from the last payroll.  We really only want to use history that was not imported.  It may be that districts will need to import after their last completed payroll pay date.
  3. What is the best way to prevent the user's from importing data more than once.
  4. WCESC Payroll  
    1. All non contract jobs were pulled into the payroll. Still looking into why that is happening. Pay Group 01 failed because of this. Over 1,000 Sub non contract jobs were pulled into the payroll, but in the Legacy side none of them are there. 
    2. I turned on logging to see what was going on....and it magically worked. All the totals match
    3. Ran into problems with payroll items by position. Andy discovered we aren't importing the payroll items correctly. I will revisit this district once this has been corrected. (Other numbers looked correct)
  5. Archbold Import
    1. There are job calendars with a blank type associated with a paygroup for substitute teachers.  Calendar is not imported, but didn't seem to cause a problem, but the most recent calendar on file for that "type" was July 2015.
      1. Should blank job calendar types be allowed/handled differently?  
      2. Calendars with a blank type are invalid per classic rules, however it is unclear how these got in the file. The add and copy options of CALMNT do not allow a blank type to be entered, but these are indeed in the file. We may want to investigate on the backend how this happened, but I believe the importer is correctly excluding them. These cannot be assigned to a job in classic since the type is blank.
    2. PositionImportImpl.loadPosition2 checks for 'template' employee/position of '111111111', but later (line 266) assumes that a compensation will be on file, causing the Exception 
      1. Exception is "Cannot set property 'checkStubDescrip' on null object'
    3. DirectDepositDistributionImportImpl.getAchDestination attempts to create an achdestination for a '111111111' employee entry in employee_dirdep_ded
      1. The template entry has a blank routing/account number, causing "ERROR: null value in column \'routingnumber\' violates non-null constraint ..."
    4. updcal_fut_payamount
      1. "Record has been posted for ..." in log.  These correspond to future pay amounts with a P "include in current pay" flag, presumably meaning it has already been paid, but not yet purged
        1. Should these messages be logged?
      2. "Invalid PAY_COUNTER for employee ..."
        1. Initially thought this was a problem but now I don't
        2. the records in question contained a pay counter of three tabs (tab numeric value is 9, so maybe it was 999?)
        3. not sure how these got in there, but UPDCALFUT ignores them, so it is probably correct to exclude them with an error
        4. it was questioned why we needed the pay counter at all, but it appears to be used during import to match up historical accounts internally
    5. updcal_fut_acct
      1. Many "Future pay amount cannot be found for employee ..." messages.  These are related to the fact that future pay amounts are not imported if they have a 'P' 'include in current pay' flag or a missing pay counter
  6. Other problems
    1. It is currently possible in PayrollDetailView to Modify a payroll, change pay date, delete/add pay groups, all while a Payroll posting batch is taking place for that payroll.  Probably same is true during populate batch processing.
    2. When modifying a payroll in PayrollDetailView, it is possible to change the pay date to be before the end date for the payroll.
    3. Should changing the Pay Date trigger a repopulate?
    4. Changing the 'Suppress Voluntary Deductions' option on PayrollDetailView does not appear to trigger a repopulate.
    5. It appears to be possible for a single position to be included in more than one in-progress payroll with same payDate and payPlan.  Warning?  Error?
  7. JobCalendarView?
    1. This view is not in the menu - should it be?
      1. There are two outstanding issues, 1511 to create the view and 1840 to convert it to DataManager
    2. This really isn't a bug except that it isn't in menu and perhaps isn't completed?
  8. Payroll update view
    1. We may also want to rethink this UI more generally
      • for instance should the delete button immediately remove the pay group (it currently does) or "queue" this deletion, but require the update button be clicked before the deletion occurs
      • also should the update payroll button be renamed to "save" and should we also create a cancel button that returns the payroll details to "view" mode? This would seem to more closely follow the standard pattern we have created in other areas of the app. It would however require that we queue the pay group deletions, so we could discard them on a cancel.
    2. in addition is the "re-initialize jobs" flag shown during payroll initialization even used? It feels like this is a hold over from the old tapestry way of maintaining pay groups.


Meeting Notes




  • No labels