Alissa Hafele, Ann Crowley, Bethany Blankemeyer, Dennis Bridges, Dung-Lan Chen, Dwayne Swigert, Emily Robertson, Jackie Magagnosc, Jean Pajerek, Julie Stauffer, Kimberly Pamplin, Kristin Martin, Linh Chang, Lisa Maybury, Lisa Smith, Lloyd, Martina Karlsson, Martina Schildt, Masayo Uchiyama, Nancy Finn, Natalya Pikulik, Okay Okonkwo, Owen Stephens, Sabrina Bayer, Sara Colglazier, Scott Perry, Scott Stangroom, Victoria Anderson, Virginia Martin, Winter White
Updates from Data Sync Working Group (they presented here too)
Considering how to manage meetings and input across the global - new cross-council group investigating (Sharon Wiles-Young, Anya Arnold, Peter Murray, Mike Gorrell)
Discuss Implementer's Topics starting #25 and continue as time allows - (#25 - #29 are invoice related topics) – details see Implementer's Topics list -Acquisitions/Resource Management implementers)
Implementer's Topic # 24: Invoices: Export to Accounting checkbox default value
Dennis
Would be easier if payment type governed what exported to accounting for Duke.
Discussion beginning around 14 min.
From Lisa Smith to Everyone 08:15 AM I don't have audio - we do need to switch from EFT to check to credit card for various vendor
From Sara Colglazier (MHC/5C) to Everyone 08:15 AM For us at MHC, mostly yes, payment type ...if a check needs to be cut, then it has to go to AP
From Ann Crowley to Everyone 08:16 AM Agree linked to payment type would be helpful
Proposal is to have this as a setting that could be configured at each school.
Easy to miss check box.
Discussion around credits.
From Lisa Smith to Everyone 08:18 AM MSU does have instances where we don't want to export a physical check to accounting - example, any check $215,000+ We send credits & invoices to accounting, and the check stub reflects the info for the vendor
From Scott Perry (he/him) to Everyone 08:22 AM If we can allow for the current functionality of export to accounting—which is working very well for us—I don’t have a problem with expanding functionality. I can certainly see the use case for payment type and think it’s a great idea.
If an invoice was over a certain amount would you still want it to export to accouting or just stop you for a moment to do appropriate approvals? (~25 min.)
Some transactions submitted manually. Using same approved step, submit external account numbers.
From Lisa Smith to Everyone 08:26 AM As long as we could easily update the 'export to accounting' choice, we can do this. MSU 'approves' each invoice in FOLIO, even if we don't 'export to accounting.' We do this to balance our FOLIO accounts with our University accounts.
Summary around 27 min.
Might be helpful to have linked to payment type via Settings
Having a limit may be complicated:
If combination of invoices create the limit, etc.
Small portion of invoices created.
Operator can still decide on individual level and user is managing the exceptions.
8:30
Implementer's Topic # 25: Invoices: Can't search or filter by FOLIO invoice #
Dennis
Ability to search by FOLIO invoice #
Used to appear in more places in the UI; over time replacing with vendor invoice #. More often than not that is the ID # that users are concerned with.
From Owen Stephens to Everyone 08:31 AM Is the “Folio Invoice Number” a human readable ID or UUID?
It's a human readable ID.
Group in favor of deprecating the FOLIO invoice number and removing from UI.
Not consistently used by libraries.
From Lisa Smith to Everyone 08:35 AM I currently use it in the POL invoice line, to get to the invoice. It would be nice if I could see vendor inv#, subscription coverage, comment without going into invoices.
From Ann Crowley to Everyone 08:36 AM The only time this might be handy is when vendors reuse invoice numbers
Discussion around how one would use the FOLIO number in regards to duplicate numbers (~37 min.)
Replace in POL with vendor invoice number and be consistent.
Vendor invoice number + date would help in differentiating duplicate numbers.
8:40 AM
Implementer's Topic # 26: Invoices: Hide accordions in Invoice view where there is no content
Dennis
Difference between invoice view and invoice line view of fund distribution and adjustments.
When looking at invoice level made it possible to add adjustments mostly so you could add one adjustment for multiple lines instead of to each line.
Could we make it easier to review all of fund distributions and adjustments?
Confusing that there is an accordion for fund distributions and adjustments that doesn't represent all fund distributions and adjustments.
When there is not any data to display there, it is confusing to display the accordions. e.g. Is there not a fund distribution? etc.
From Sara Colglazier (MHC/5C) to Everyone 08:45 AM It seems like a labeling issue, so it is clear what is Invoice level and what is Invoice Level Level
From Virginia Martin to Everyone 08:45 AM agreed, Sara. our first choice would be not to display them, but clearer labels would also be an improvement
Discussion about whether you display an accordion or not.
Part of argument is that having the accordion there does supply information.
Can be misleading here with lack of fund distribution information.
From Scott Perry (he/him) to Everyone 08:48 AM It’s confusing to users since this is asserting no fund distributions.
51 min. - Question about invoice level adjustments and example demonstration to discuss.
Summary - Key things that would be an improvement:
Labels at invoice level should be different than invoice line level.
Do not need to appear if empty at the invoice level.
8:55 AM
Implementer's Topic # 27: Invoices: "Add" and "New" Invoice line button labels
Dennis
Updated for Lotus.
Actions menu added to make buttons more self-explanatory.