Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.



Discussion tems


20minRenewals for 'fixed' loansSean Thomas
Decision: How to handle Fixed Due Date loans with renewals. While fixed loans are renewable, there is no notion now of a renewal length for a fixed loan. The option of 'alternate fixed due date for renewals' would only work for the first renewal. Affects renewal override effort as well.
20minFixed due date schedule maintenance and affect on fixed term loan policiesSean Thomas
Discussion: How fixed due date schedules and policies for fixed loans are maintained in practice. Decision: What, if any, additional functionality is needed to accommodate fixed loans made at or near fixed-term-end dates?
10min1 - Does minimum guaranteed loan length apply independently of a recall and, if so, 2 - Does minimum guaranteed loan length override fixed due date limits for rolling loans?Sean Thomas
Decision: Overriding factor in conflict between fixed due date limits on rolling loans and minimum guaranteed loan length (if min. guaranteed lenth is meant to apply independent of an existing recall). Currently, fixed due date limits may truncate the length of a rolling loan. If that happens, and the loan length would be less than the minimum guaranteed loan length, which setting should be applied to calculate a due date?
10minQuestions about In transit modal textCate BoeremaThe in transit modal text specified (and implemented) for in transit to home location is: Route <title of item> (Barcode: <barcode of item>) to <name of destination service point>. The in transit modal text specified (not yet implemented) for in transit for a request is: Route <title of item> (<material type of item>) (Barcode: <barcode of item>) to <name of destination service point> for a request.1. Do we need to have two different modals for transit to home location and transit for request? Is the distinction important at this point in the process? I'm asking because the impact of this could be that the UI (or other client) will need to understand both that the item is In transit and specifically why it is In transit. This would increase how much understanding the UI needs to have on the various processes which might result in an item being transited. 2. The request specific text also includes the name of the material type. To do this, we would likely need to add an additional step in the API for looking up the material type for the item (slowing down the check in operation) or the UI would need to fetch this information separately. Do we need this when the existing transit modal does not have it?