2019-03-20 USPS New Issue Review and Prioritization

Owned by Former user (Deleted)
Last updated: Mar 20, 2019
2 min read

Prioritization Items to Discuss

  1. 132d Support?

    1. We know of two districts that are currently implementing this through a vendor called Cpplus. 

    2. They are allowing money to be tax sheltered for things like union dues, school supply purchases by teachers, etc.

    3. The money is not eligible for STRS retirement withholding and is sheltered from taxes. 

    4. The money is being paid directly to the employee and documentation concerning the expenses is handled by the vendor. 

    5. There is a way to support this in the software, but it is fairly cumbersome. 

    6. There is a very small number of districts doing this at the moment (two in the whole state to our knowledge)

    7. Is this something that the software should be enhanced to support more directly?

  2. Implementing unsupported SOAP-bridge methods

    1. This is another issue that came up recently and is currently impacting a very small number (we believe one in this case) of districts

    2. Though we tried to keep the SOAP-bridge API as close to possible as the classic API there are some method calls that are unsupported due to changes in the data model

      1. One such method is updatePayRecords, which allows posting to UPDCAL future in classic. 

      2. We do not support this through the SOAP-bridge in USPS-R

      3. This is causing issues for a redesign district trying to use a feature in Strategic Solutions software that uses this call.

      4. What is the priority in your opinion in supporting these API calls either via the SOAP-bridge our through a new web based API? 

  3. Employer Distribution Charging for Positions With No Employer Distribution Accounts

    1. Classic handled this situation somewhat strangely as if a position had no accounts assigned to marked for employer distributions it would charge the entire amount to the accounts configured on position one.

    2. USPS-R will handle this scenario by prorating the amounts from that job across all eligible accounts 

      1. This is consistent with all other charging behavior in this application

    3. A request was received to revert back to the classic method

    4. Is there a reason this is better? Are their others that are relying on the classic behavior?

All Issues Created Since 02/20/2019