Backend: Add "agedToLostDelayedBilling" property to loan schema

Holly can't actually test this without a UI, but will be able to test that this works later. Thanks!

Per meeting with Marc on March 25, 2020:

UNAM will add "agedToLostDelayedBilling" property with:

• lostItemHasBeenBilled

• dateLostItemShouldBeBilled

P.S. Originally we discussed calling property "agedToLost" but Holly wanted to make it clear that it is not used for all aged to lost items.

: Hi Marc. Thanks for your comments about this feature. I brought Automated Patron Blocks and Overdue Fines to you and Jakub for technical review but didn't think that Aged to Lost required that level of scrutiny. We would like to meet with you to discuss the Aged to Lost process. I know what we are trying to accomplish, but not necessarily the best way to accomplish it. I am happy to try whatever technique works best. Israel and Isela will attend the meeting as well. I will contact you via Slack to set something up. Thanks, Holly

I have been trying to review this change (following our brief conversation on Slack), it is challenging without more context. I've read [UIU-1165] to try and get more a sense of the work (I found it daunting trying to take in all of the flows at once).

billedLostItemFlag is a new Loan Record back-end field that will be used to indicate if the aged to lost fee has been billed (for use where delayed billing is set up)
dateBillLostItem is a new Loan Record back-end field that will be used to indicate when the aged to lost fee should be billed (for use where delayed billing is set up)

As expressed in our earlier conversation, I have concerns that we are trying to use the loan record to store information about the aged to lost process, in particular the billing part of it. This is not the first feature to do this, and so I think this is likely a more general modelling challenge in FOLIO.

I think we need to talk about possibly being a candidate for a peer reviewed technical design, in the new development process (as I briefly discussed with and ). I'm aware that development needs to continue and that the technical design process is in it's early days so could present some challenges.

In the meantime, as we continue modelling this state on the loan, I'd like to make some suggestions:

• keep properties relating to the aged to lost process in a separate place to make it clear that they are for managing this process. In the schema, this could be an object property called agedToLost.

• rename billedLostItemFlag to lostitemHasBeenBilled to make it clear this is to signify whether it has been billed for or not. Do we need this property, if it has been billed won't there be a fee or fine representing that bill?

• rename dateBillLostItem to dateLostItemShouldBeBilled to make it clear that this is about what we want to happen in the future

Determine if items previously marked as aged to lost (i.e. flag billedLostItemFlag = "false"), but not billed, are ready to be billed now

Does that mean this flag being present, and set to false, rather than not present, is an implicit indicator that this loan should be billed in the future?

If I get much further into the process conversation I think I need to move my comments to either [UIU-1165] or (from a technical perspective, an event based approach to this could work really well, however it is likely too soon to advocate for that).

What do folks think about my suggestions? And about a design review for this feature?