Child pages
  • Sprint 234
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

  • bug discovered in Max Amounts for Payroll Items
    • We are defaulting the payroll item max amounts to 0
    • We check for null when processing, but a 0 value for max amount it considered value
      • If the amount is 0 it will not withhold the payroll item correctly.
    • The payroll items will need to change the way they check for a valid max amount or stop checking for 0?
    • FISCSUP-101 - Getting issue details... STATUS
    • We were able to get around this bug by simply removed the max amount for the payroll items in question but the user shouldn't be required to do this going forward.
    • USPSR-3757 - Getting issue details... STATUS  will resolve this issue
  • usas account sync
    • The following may not be valid after looking at USAS Account Change service a bit more. Still want to verify with Dave / USAS 
    • usas account transitions are only valid for usps once they have been applied on their side 
    • there is no status or flag to let us know which account transitions are valid
    • usas will need an update to supply this info on the account transition so we can query by the flag or status
    • IF we can assume all transitions are valid...
      • What do we do if we can't find a to or from account?
    • Changes are ready for USAS, USPS Changes pending discussion.
    • Need a USAS Jira issue and Hotfix to commit changes 
  • DeductionHistoryImportImpl on line 109 checks if it is a PayrollPayment before saving a historical payroll item
    • For Refund of Deductions, it is throwing an error because it is not a payroll payment
    • If we are expecting refunds to have payroll items, and are purposely not doing anything with it, this maybe should be a warning?
    • Or do we need to save something in this situation?
  • CheckHistoryImportImpl on line186 is a similar situation.  If we are processing a check from handcheck or something that should not result in a HistoricalEmployeePay being created, we throw an error
    • But if this is the expected behavior for a known situation, should this be a warning instead?
  • Test failing on Bamboo that passes locally:
    groovy.lang.MissingPropertyException: No such property: REPORT_OUTPUT_PDF_INLINE for class: org.ssdt_ohio.model.ReportConstants
    • That constant was recently removed in the Common class

    • But that test does not reference that particular constant???

Meeting Notes




  • No labels