Janet Ewing, Nancy Pelis, Sara Colglazier, Kathleen Norton
Amherst College
1
Nancy Finn
Cornell University
4
Ann Crowley, Jackie Magagnosc, Jean Pajerek,Masayo Uchiyama
Duke University
3
Adam Hudnut-Beumler, Bethany Blankemeyer, Julie Brannon
Ebsco
2
Dennis Bridges (EBSCO, Product Owner), Ann-Marie Breaux (Ebsco, Co-Product Owner)
GBV
2
Peter Sbrzesny, Martina Schlidt
Holy Cross
0
Java developer.
1
Kim Wiljanen
Marmot Library Network
0
Middle Tennessee State University
2
Susan Martin (Convener) , Suzanne Mangrum
Missouri State
2
Dwayne Swigert, Mark Arnold
Skidmore College
1
Dung-Lan Chen
Smith College Libraries
1
Lucinda Williams
Stanford University
2
Alissa Hafele, Suzette Caneda
Texas A&M University
9
Heather McMillan (Co-Convener), Frances Dotson, Kimberly Pamplin, Michael Phillips, Okay Okonkwo, Shannon Burke, Winter White, Sarah Dennis, Victoria Anderson
Keep track of all changes being made (by users and those that are system-triggered)
Workflow from user's perspective
In actions menu access to see "change log"
Clicking would take you to a full screen view of changes
Come from PO, land in change log, looks like a standard search and filter layout
Ability to search by keyword, etc.
Details captured: field, updated, source, old value, new value, note
Notes could be recorded regarding changes made
If you select a search result, rather than getting a full screen view of details you would see the notes field
User must go into change log to enter note.
Could be changing a number of things / collection of fields. e.g. Product ID, Qualifier, Product ID type - may be updating some or all
A couple of different approaches:
Possible that we consider edits you are making as a version.
Might be easier to follow what is going on if these are grouped as versions.
You might make your note on the version
Either you can select the version and see all changes in 3rd pane or take an approach with hierarchical lists (version is top line of the table in results list and could be expanded to see all of the changes that were made for that version).
Does this area need to be more of a quick reference?
Sara: Quick browse is definitely necessary. In current system can browse changes as they occur. Somewhat vague but give an idea of who did what when. Like the idea of a note. Having that option when necessary for more detailed information seems cool. If I clicked on something and then saw specific information in a third pane that would be nice.
In hierarchical search, if your search hits on something in the accordion it would display expanded. Maybe also a toggle to open.
Browsability of second version is much higher than where you only have third pane.
From Julie Brannon (she/her) to Everyone 12:24 PM To elaborate on Sara's comments - in Aleph the order log keeps track of defined categories of transactions such as a change to order status, order created, note added so we can filter by type of change made. Not sure if that helps.
And the log includes actions that were taken by the system - it would be helpful to have an entry when the system makes changes to an order based on business logic. For example, the order payment status changes or the order is closed due to activity on a related invoice.
Sara: Have a barcode search that will highlight searched barcode in list. If that was possible here might be helpful.
Dennis: If notes do not show on the order record anywhere, does it still serve a purpose?
Sara: Would there be a flag on the change log that there is a note?
Dennis: Yes, but if you haven't come to the change log would not know that there are notes.
Sara: Would be okay with that.
POL have notes functionality. Might be interesting to be able to link those notes to changes being made in the change log. More complex; only really worthwhile if it were important to see these notes when looking at a POL.
Sara: How easy is it to toggle between order and order log?
Dennis: It is in the action menu. Could also open them in separate windows.
Will rely on source field to indicate whether changes are made by a user or the system.
Types of changes - would need to group all of the order data into categories. (e.g. what are all the status fields?)
Using the accordion headers might be interesting.
These were cost edits, location edits, etc.
From Sara Colglazier (MHC/5C) to Everyone 12:32 PM +1 to accordion headers
Julie: Only will show changes to specific things. Know that if I were coming to find information would not want to have to look through every version or iteration.
From Sara Colglazier (MHC/5C) to Everyone 12:32 PM and source would be so helpful, like App Invoices, vs. EBSCOnet, vs. user X
Dung-Lan: When you showed POL note, under dropdown it has different types of notes you can make. Will change log be a type?
Dennis: If it was going to be valuable then I think we would need to do something like that. Linking would probably involve a specific note type. It wouldn't be easy to do, but if it's valuable would probably look something like that.
Sara: Regarding Helper widget, I think that would be overcomplicating what is needed. Hard to use. Much better to have the free-form box with 250-500 character max where extra information can be added when applicable. Accordion header would be a good first step point.
Discussion regarding note helper app.
Ability to see what fields have been edited
When things have been changed, we identify that they have been changed in the UI.
To get more information would need to look in the change log.
From Sara Colglazier (MHC/5C) to Everyone 12:41 PM I seem to remember from the previous discussion that there was the question of time: how long to do they stick around?
Do you see this making life easier?
From Ann Crowley to Everyone 12:41 PM That would have been valuable trying to figure out the problem invoices we had recently
From Dung-Lan Chen to Everyone 12:42 PM wouldn't publisher info came from source record (MARC) when the instance is overlaid? not from Acq. PO?!
From Sara Colglazier (MHC/5C) to Everyone 12:43 PM I think it would be field specific ... some fields like vendor, fund code ... but not everything
Kristin: If someone edited it 5 years ago may not have as much meaning if edited last week and you're not going to be able to tell. I think the thing that will be more important is understanding when a PO changes its status or state. Having every field with that level of detail could make it hard to see what's really important.
From Peter Sbrzesny to Everyone 12:44 PM Too many highlighted fields could become confusing.
From Julie Brannon (she/her) to Everyone 12:44 PM I put the list of transaction types that are logged in Aleph on our slack channel if that's helpful
Ann Crowley: With the beginning of FOLIO, having this information could be useful over searching email, etc. It might not be as useful 5-6 years down the road, but may be much more useful in the beginning.
Kristin: Maybe show things that have been edited since the last time updated.
Maybe in action menu have a "show edits" option to toggle the red notes.
Is there a use case where it's helpful to you, to just identify what field has been edited so you can go search for that edit?
If you edited a bunch of things, everything will show and may not be useful.
Sara: Certain fields would never normally be changed. If at one point the fund code is changed, gets a little symbol next to it. That is kind of helpful. It's not like you are doing it constantly or very often. Vendor being changed would also be a weird/unlikely thing to do. Flagging that in some way would be valuable. Then would go to log to see when it happened, why, etc. Wouldn't necessarily be information that goes out of date either.
From Martina Schildt to Everyone 12:51 PM +1 to Sara
From Kimberly Wiljanen to Everyone 12:52 PM Things that affect the funds and the expense class should be tracked, one time changes, such as publisher, price etc. only affect the order when it is received and a note in the widget should suffice.
From Bethany Blankemeyer to Everyone 12:53 PM +1 Kimberly
Kristin: Curious with the screenshot, is this tied to an instance in Inventory? Can you edit the publisher? I thought if linked that you could not edit the publisher.
Dennis: Only if it is edited through API.
Ann-Marie: So if you edit it, it doesn't break the link?
Dennis: If you edit it when making the connection would definitely break the link.
56 minutes after
EDIFACT Export
Dennis Bridges
Driving a default that basically says export this order or do not export this order with acquisition method
Requirement originally was that you all can specify based on acquisition method which orders should be exporting and which should not
e.g. with "Purchase" might have checked. With "Purchase at vendor system" might be unchecked because vendor already has purchase in their system
Yes/no to "Automate Export."
Configuring the acquisition method / export relationship per organization.
Is it important to have this be different for each organization?
If there are multiple export methods (two versions of EDI with a particular vendor); is it always consistent for the vendor or would it be valuable to have this be different based on the actual export configuration?
Do acquisition methods need to behave uniquely for each export method / integration method? Or just for each organization as a whole?
Or should it just be even more simply and be a global list?
Dung-Lan: Need to have different ways of ordering through an organization.