/
2021-04-29 Acquisitions Group Meeting Notes

2021-04-29 Acquisitions Group Meeting Notes

Owned by Heather McMillan
Apr 29, 2021

Attendees

Alice Daugherty

william.verner

Dennis Bridges

Dung-Lan Chen

Heather McMillan

Jackie Magagnosc

Jean Pajerek

Julie R. Stauffer

@Katy Kazee

Kimberly Pamplin

Lindsey Lowry

Lisa Maybury

 @ Loyd Marmot

Martina Schildt

@Masayo Uchiyama 

Michael Phillips

@Okay Okechukwu 

@Sashirley

Scott Perry

Scott Stangroom

Shannon Burke

@Shyama Agrawal

susan.martin@mtsu.edu

@Suzanne Mangrum

tbethard



Discussion items

Announcements

Poll - Refining available columns in order search results

Dennis
  • Poll: Created poll so community can vote for what they would like to see in the order search results.
  • Refining available columns in order search result list#ballot-polinedescription-a,
  • you must be logged into the wiki to participate.
  • Being able to do a poll on the wiki is a tool that has been added. We can do this for several issues moving forward.
  • Each field is its own question to help you express which field you want to see in the order search result.
  • Deadline – Voting ends end of day next Tuesday (May 3)

Multi line po

UIOR Jira ticket 694 -


Dennis - for the video, this started about 10 minutes into the meeting. 
  • UIOR Jira ticket 694
  • https://folio-org.atlassian.net/browse/UIOR-694
  • Now have a design proposal for how to handle this.
  • Goal to not have to go back to main po every time you add a line.
  • Proposal, buttons at the bottom, adding a 3rd option to toggle….. fill out order form, then buttons become active, then when you save you can check the box ‘create another’, it will save the po and you can add another po line.
  •  Chat: From Scott Perry (he/him/his) to Everyone:  12:15 PM: Although this is unrelated to the specific multi-line po issue, can a form similar to this be used with invoices for adding pols? No need to answer today so I’m not interrupting the agenda, but I wanted to throw this out there
  • Dennis: the challenge is linking invoice lines to po’s. If we had the ability to add the pol connection when you are creating a new invoice line, we could use a similar workflow. At the moment the way to connect the po is to use the ‘add’ function.
  • Scott – Right now it’s taking about 25 seconds to retrieve po and click add. The system is slow because of that. Would like a system to add po number and amount. The way it’s currently set up is cumbersome.
  • Dennis: you can select multiple lines to add at one time. We are working on improvements to search performance that might help this. Need to implement the ability to edit the connection. To do that will use a similar pattern to  connecting the instance and order together. Will see if he can get feed back from developers on possible workflows,

Relaxing account field requirements


  • This is in the Organizations record. 
  • There has been concern about specific fields being required. 
  • Right now, what is required is
    • Name
    • Account number
    • Payment method
    • Account status
    • Library code
    • Library EDI code
  • Dennis: Is anyone using library code for a specific purpose? * No one on the call does
  • Proposal 1: The suggestion is that we treat Library EDI code the same way we treat the accounting code. Each account could have a unique EDI code.
  • If the Library EDI code is being used, at the moment, it’s all being managed independently of import. Once it is implemented, then if it’s EDI code is there, each account can have a separate edi code.

  • Dennis: Uncertain on the library code…. Is this a necessary field?

  • Definition of Library code: “The library supplied code for the account with the vendor.”
  •  Account number is given by the vendor. The intention of library code is the library may describe the account in a different way. We identify this account number with our own code.
    • No one on the call would use this. Dennis thinks this can be removed.
    • Bill: Duke has not looked at this field. We may have something that we might want to migrate into this field. But can place somewhere else if this goes away.
      • Bill will ask at Duke if there is a use case for this.
    • Accounting code: Comes from library side, the library’s information on what account to use.
    • Dennis: If there is not a specific use case that supports the Library Code field, we should remove. Will come back to this later.
  • Payment method field: We can relax this field as well. This was to inform the creation of invoices. So if you select specific organization x, then if you selected a default payment method for the vendor, then it’s auto filled in.
  • We can treat this as the account has a payment method associated with it. An account shouldn’t have to have a unique payment method. Could just be a possibility for accounts.
  • Is it a common use case to have one vendor with multiple payment methods for?
    • Not a common thing.













Related content