Page Comparison

• Will discuss updates from last call. Updated a few mockups around editing a link and moving associated holdings items.
• Review Wiki page for processing invoices against previous years.
• Also a new item to agenda if time:

Discuss order edit history requirements. Feature for keeping a change log (this is quite old, and information is more general).

Talk more about this in the context of orders.

Becoming more pressing that we keep track of the changes that are happening over time.

Editing the instance connection of a purchase order line.

Suggestion was to display the actual item records that will be moved. This pattern borrowed from invoice duplicate check.

Workflow:

• • Decide to edit connection (pick new instance)
  • Save
  • Intercepted by modal confirming that you meant to change the instance link.
  • Making you aware that you need to make a choice on whether to move items or not.

Display:

• • Item details just as displayed on the instance record under holdings. Same table with the same details.
  • Bar scrolls over to see other fields.
  • Iteration 1: This is an all or nothing choice. Either moving everything or nothing. Otherwise go to inventory and move things manually.

If you do decide not to move things, will perhaps give a link to inventory so you can go work on it manually.

Still working on best way to display that link.

From Virginia Martin to Everyone:  12:06 PM

i like it!

From Sara Colglazier (MHC/5C) to Everyone:  12:06 PM

Yes, we definitely need to know what item or items we did not move so that we can later find them to do so in Iventory

Potentially a lot of information from the item record. If it turns out to be a performance problem may need to discuss narrowing down.

Would you be editing this link many years down the road when there are hundreds of items received against something? And want to move the items?

Virginia: Yes, think of serials title change situation where you move order to the new bib record. Imagine you would leave items associated with previous title. Might move a few items if you catch the title change late. Can’t think of off the top of my head where you would want to move all of a lot of items.

From Dung-Lan Chen to Everyone:  12:09 PM

Yes to what Virginia mentioned!

From Jackie Magagnosc to Everyone:  12:09 PM

+1 to that. And it’s easy to miss a serial title change given how FOLIO is structured

Dennis: Are there use cases where you might want to search and confirm is this item one of the ones I’m potentially moving?

Virginia: Scrolling is sufficient. Biggest thing I want to see is the enumeration associated with the item. As long as that is pulled in, that’s what I care about when picking the items.

From Sara Colglazier (MHC/5C) to Everyone:  12:10 PM

Or copy number for monos

Dennis: Might want to talk about a different order for these fields.

Sara: When on this screen and you say don’t move any of the items because maybe it is better to do it in inventory, want to have some kind of record of what instance it was associated with before. Sometimes you can get interrupted or want to hand it off to someone else and tell them which items to move. Will be crucial that we have the UUID or something so we can backtrack and go there. Don’t want to just scribble something down on a paper.

Dennis: Perfect candidate for order history. Could store the previous instance record there or force the user to confirm that they have actually done the moving they want to do. Check box that says "I’ve now moved my items save this purchase order line." Would probably make more sense to keep a history of the things that are edited. Maybe out of scope for this initial change because it could be better handled by another piece of functionality.

If you’ve decided not to move items automatically, click submit and maybe another modal is presented that asks: "Have you moved all the items you wanted to move?"

Sara: Maybe it could say, “Do you really want to move the order from this instance ID copy icon to this instance ID copy icon?” Then can copy that number and throw into another tab to save.

From Jean Pajerek (Law Library) to Everyone:  12:16 PM

+1 Sara

From Sabrina Bayer to Everyone:  12:17 PM

+1 to Sara

Dennis: If you move past the modal will not know the previous instance. The only place we keep this connection is in the POL. No POL reference in the instance.

Dung-Lan Chen: If you switch the title to a different instance, how do you differentiate which payment is made under which title?

Dennis: Separate relationship between purchase order line and invoice line. Changing the instance will not manipulate that relationship at all. If you have paid invoices related to this order they will remain related to this order. Invoice contains reference to the purchase order. Information in the invoice line is captured, not reference information.

Dung-Lan Chen: Different scenario for firm orders and ongoing orders. For firm orders you may accidentally link POL to electronic record but were actually ordering a print book. Or if you wanted to order a different edition, but selected an earlier edition by mistake. But for ongoing orders, probably want to start a new PO with the new title.

Julie Stauffer: Trying to use this particular dialog box to deal with some of the complications related to ongoing orders may not be the best way to handle some of those.

Question about firm orders and wrong edition. At point of something getting cataloging in inventory, the title is changed in inventory. Does that have any effect on the title that displays in the purchase order? Title is changed in inventory that’s linked to the PO.

Dennis: At the moment there is no synchronization. Order title field is not updated.

Julie: What we are trying to solve here is really more about moving the purchase order line to a different instance than correcting the title.

Sara: Could it not be used that way?

Dennis: If we allow you to edit, then an externality would be if you go to edit a POL and you use the title lookup and select the same instance again it will update the bibliographic information that is populated when you connect an instance.

Ann-Marie: If I ordered this saying 24 greatest hits and then cataloger updates to 25 greatest hits, the way to get that updated in the PO line if I felt like it needed to be updated would be to edit the purchase order line and do inventory look up again and select the same instance. Once selected 25 would show up and updated author.

Dennis: Do we want to prevent that from being possible?

Multiple: No!

Ann-Marie: Maybe there is value in having an option that would let you automatically update the POL to match an updated instance record. At least for monographs, once you have got that thing in, as long as linked to the instance, not sure if it matters that it stays updated. Could see it for ongoing.

From Jean Pajerek (Law Library) to Everyone:  12:31 PM

If the title in the POL is inaccurate, it can make selecting the correct POL for an invoice difficult.

Virginia: Goes both ways. Integrating resources that are online such as databases, you may be purchasing modules or component parts. Would not want changes made to that integrating record to make the POL change. There are examples where you wouldn’t want automated changes to occur and examples where you would.

Dennis: Technical challenge of how to properly keep data in sync. Still a topic. If you have information in two different modules, how do you responsibly keep that data in sync? Implementing this change will at least give you the ability to update POL when desired. If in the future we have a solution for synchronization, then we can revisit this discussion and possibly have more automation here.

Process invoices against previous fiscal years

https://wikifolio-org.folioatlassian.orgnet/wiki/display/ACQ/Process+invoices+against+previous+fiscal+years

No specific feature created for this yet, but it seems like it is of interest to more folks. Review as a group and see if it does need representation. Currently a similar feature in other direction encumbering money against future years. This is almost the opposite, processing invoices against previous fiscal years. Creating payments or credits against previous fiscal years.

Problems identified so far:

• • Possible that an institution does not resolve all of its invoices before the fiscal year ends. Commitments that you cannot resolve without manipulating your fiscal year period. Don’t want to pay invoices in current year because intended for previous budget dollars.
  • Other problem talked about, the idea that you may have budgets that for whatever reason are not exactly balanced from previous fiscal year and may need a mechanism to correct discrepancies for reporting or auditing reasons.

Some use cases collected so far:

• • Duke – process invoices 2-3 weeks after the last day of the FY because of way AP system is handling things.

From Virginia Martin to Everyone:  12:41 PM

Really it's not invoices, it's adjustments

Dennis: Adjustments in the context of FOLIO, or more general sense?

Virginia: Not that we are processing new invoices, but making adjustments. Often do not get final numbers from financial system until after July 1. Need to be able to make final adjustments in FOLIO to reflect things like exchange rate discrepancies. Usually only a week out.

From Scott Perry (he/him) to Everyone:  12:43 PM

For us it is often foreign currency transactions.

Dennis: Would you create a separate invoice for that?

Bill Verner: We would usually add an additional invoice. Would not go back and try to redo anything on the previous fiscal year.

From Lloyd (Marmot Library Network) to Everyone:  12:45 PM

We do have libraries that would like to invoice against the previous fiscal year.

From Bill Verner to Everyone:  12:46 PM

We usually stop processing invoices with enough time for currency variations to sort themselves out in advance of the end of the FY.

Lloyd: Book was purchased in previous year and library would prefer to purchase in the same year that it was ordered.

Martina: For us the fiscal year rollover is around Christmas. Usually have some people on leave. Colleagues can invoice them in the next fiscal year.

From Scott Perry (he/him) to Everyone:  12:47 PM

Yes, most are done early enough, but sometimes

there are delays in accounts payable.

Virginia: Things a little different at Duke. Fiscal year may be over, but we will not actually have done rollover. Will do final reconciliations and then will do rollover.

Sara: When we rolled, realized that things had been paid by college, but not paid in Aleph. Wanted it to be properly documented in ILS system and re-ran the report. They had been paid, but not recorded.

From Virginia Martin to Everyone:  12:50 PM

ah, yes, Sara, that is an excellent example of a reconciliation need

Dennis: In that case it would be a full invoice? If the transaction dates were the current day, would that be problematic? Or expected? Approval date would be after fiscal year rollover, but would count against last year.

Sara: In our case, jumped over approval and made it paid. Made it last day of the fiscal year. Can manipulate the date.

From Dung-Lan Chen to Everyone:  12:50 PM

Voyager allows two different fiscal years open at the same time that you just need to choose which fiscal year you are paying the invoice for.  Can this be considered for Folio environment?

From Lloyd (Marmot Library Network) to Everyone:  12:52 PM

@Dung-Lan Sierra is the same.  We would like that too.

Dennis: From a technical perspective there is nothing preventing us from allowing that. The one key detail would be that you would have to activate the budget again. Depends on how you do your rollover. If budget is closed cannot make a payment against it. The other barrier is that you cannot choose what fiscal year you want to make the payment in. Right now when you approve & pay the system uses today’s date to decide what period you are in.

From Ann Crowley to Everyone:  12:54 PM

We have never had an overlap, the system closes one day and we open the new fiscal year the next day. And I believe this has been based on the idea most of the adjustments that we might need to make are general small amounts

From Scott Perry (he/him) to Everyone:  12:55 PM

+1 Ann

From Bill Verner to Everyone:  12:55 PM

Yes, at Duke we would just absorb these small amounts into the new FY.

Lloyd: Don’t know that we need to change the date of the transaction if we can make it against the previous fiscal year’s fund.

Dennis: Maybe could allow you to choose a transaction date or you could just select the fiscal year, but transaction would be happening the day it was happening.

Will take these use cases and distill this into some actual requirements. Will review as a group in the next couple weeks.

From Virginia Martin to Everyone:  12:57 PM

(at Duke we absorb small amounts into the new fiscal year except for the reconciliation adjustments we have to do)

BugFest still going on. Closing in the next couple of days. Keep on test cases and retest those that are possible to retest now.

Will see you all next Tuesday.