This is the work of the mini-group that has been meeting over the past month or so, we presented this at a sig a few weeks back, made some changes since then but we wanted to post this to start getting your feedback. There is only one page at this point. Once we get your feedback we are going to turn this into code and build out all the other screens.
Visit prototype here: http://ux.folio.org/prototype/en/vendors
I’m not sure how functional this version of the prototype is supposed to be, but most of it is not working for me. However, as is, I can provide one piece of feedback:
There is only one page at this point. Once we get your feedback we are going to turn this into code and build out all the other screens.
Hi Kevin,
I gathered some thoughts about the vendor information screen. If you have any questions I will join the RM SIG meeting today and please feel free to send me an email if you have questions.
[General]
For most customers we have to fill out online forms with our financial data (vat number, corporate structure,…). Folio could provide such a form (or a plain list export) as well. And I think we should try not to duplicate financial data with other vendor information systems in the libraries financial department (e.g. sciquest).
[Summary]
[Contact Information]
[Contact people]
[Agreement]
[Classification]
There are four types of “vendor classes” -> access provider, governmental, licensor, material supplier. This might be to general and a free text field would be more useful?
In Harrassowitz’s case the “expected invoice Interval” is to limited. We have an individual invoice schedule for most of our customers (journals) and with books the invoice comes with the delivery.
“renewal activation Interval”: Harrassowitz has a renewal deadline that can be prolonged if needed, not an activation interval
“Estimated discount” might be to general again. There could be more than one discount agreement with one vendor.
[Tax]
[EDI Information]
[Interface]
For our online interface structure at the moment there is a need to put in several interfaces [Fokus & OttoEditions].
The username/password depends on the individual user in the customers library. Displaying them here could be a challenge.
[Statistics]
[Account]
The fields “Payment Method” and “Contact info” should be linked to the respective fields above under [Vendor Information] and [Contact people]
Discounts, Service charges,… could be filled in in this paragraph
Again, please feel free to contact me with any questions.
Sebastian
One additional thought: The vendor screen could be the place to upload Due Diligence documents like anti-harrassment policies, environmental policies,… or is this out of scope for the ILS system and beeing handeled somewhere else?
Two questions/comments…
Following up on the discussion about linking the vendor record to licenses, can you please make this connection possible from either side (from the vendor record or from the license record…would also need the ability from the resource record level)? In a previous library several years ago, our ERM allowed you to attach a vendor or specific database to the license from the license record (with about six clicks required), but you could not originate the connection from within the vendor record. FOLIO should not have the same limitation.
Would it be possible to have a short Notes text box (or Language Specialist or something like that) appear if you change the vendor’s Default Language to something other than the library’s default language? If the vendor’s language matches the library’s, this box would not be generated. Our acquisitions team orders from a number of non-English vendors, and it would be nice to have this text box appear for non-English vendors so we can specify the name of our language specialist who helps with the ordering of those resources. Not sure if this would be helpful elsewhere, but it would help with the “who handles orders for Korean/Spanish/etc. materials” question.
I agree that both of Steven’s suggestions would be useful.
I have some questions about the Statistics and Interface sections:
I am not sure whether “Statistics” should be a section attached to the vendor record, but might make more sense on the vendor interface/platform record. When I think statistics, I am usually thinking about usage data, and that is often (but not always) platform specific, so storing that information at the platform level seems more appropriate, and then it would be linked through the platform to the vendor. I could see there might be the possibility of duplicating it if the statistics site covers more than one platform. But if we store it at the platform level, it would need to be repeated for multiple locations, and then we’d need to indicate the platform to which the statistics information is referring to.
Again, because I am thinking of statistics from a usage stats perspective, information about COUNTER should be here. Log-ins may be needed, and we may wish to record SUSHI data here. I don’t know that FOLIO will be building a SUSHI harvester, but I could see value in being able to communicate with other programs that already exist that collect statistics.
Sometimes the statistics site shares the same administrator user name and password, sometimes it is separate. Right now it seems like Interface (which I think will need to end up being its own record in FOLIO, and that is the direction we are already going) and statistics are separate sections. The Interface/Platform will need to some additional fields:
This is a great idea.
I shared this with the Head of Payments. She has some suggestions:
Currently, we store copies of W8 and W9 forms in a folder on the shared drive. We keep a copy of them on the shared drive because we cannot access a copy of them on the University’s system once we submit them to Financial Services. They are organized alphabetically, which works for the most part. I think it would be great to be able to store one or more copies of W8 and W9 forms at the vendor screen level. I say one or more because a vendor may have more than one of such forms due to address changes, multiple “doing business as” names, etc.
It would also be great to be able to link other forms directly to the vendor page. For example, we have to complete a wire request form to upload to the University’s ePayment system whenever we process a wire payment. Currently, we store a re-usable copy of this form for each vendor, again, in a folder on the shared drive, which has their specific account information in it. If we could attach this to the vendor page, or be able to store this info on the vendor page, and then have the ability to create forms that pull info from those fields, it would be useful.
I also like the idea of having a place to make notes regarding contact with the vendor. Currently, I rely on my email (I don’t delete much), to remember when and why I last contacted someone. [Kristin editorially adds: this speaks to Filip’s desire to have generalized notes and someone to integrate email into FOLIO, even though we struggled with how best that could be done].
Finally, it would be good to have some sort of notification that would pop up when someone creates a new vendor profile that is a potential duplicate of one already in the system to prevent unnecessary profiles from being created. Or, if a second profile is required for a vendor, perhaps the vendor pages for the original profile and the new one could be linked?
A few comments and questions after reviewing the screen and the discussion:
I think an activity log would be helpful.
Accounts
It seems that this is where reference to discounts, service charges, shipping fees, etc. should reside since different accounts/subaccounts with the same vendor often have different terms. Perhaps allow entry for positive or negative values expressed as fixed amounts or percentages with a local label.
Acct. Payable Sys. No. is usually the same for all accounts for a vendor, though not always. Does this belong at the Account level only? Or is this the same as the Financial Sys. Code under Vendor Information where it could apply to all accounts?
Agreement(s)
It would be desirable to access any documents related to the agreement (contracts, MOUs, etc.). If it only applies to a subset of subaccounts, perhaps links to the Accounts (or a link under Accounts).
Tax
A link to the various tax documents required seems desirable here. In the US, these include W8Ben and W9 documents. There may be issues with some W9 documents being open—some include a Social Security Number.
Scott
I checked with staff in Acquisitions Accounting here at Duke and they are in agreement with Chicago’s Head of Payments:
Makes sense to me. We don’t currently keep the W8 or W9 forms once they are submitted to Accounts Payable. We rely on email to submit vendor setup/changes in SAP. Penny creates/changes the vendor in Aleph.
We also have to fill out a wire form. The forms are currently processed through Buy@Duke where a copy of the submitted forms are attached.
In my “pie in the sky” scenario for how FOLIO could work, we could store all of this information in the vendor record and there would be an automated (probably would need to be configured locally) way to transfer it to AP so that there is no manual email intervention.
An activity log is, in my experience, always helpful, so I second Scott’s suggestion.
Rather than displaying Agreements at the Account level, I would prefer to be able to view them all at the Vendor level and associate a subaccount with it, if applicable.
We definitely will have notes all over the place in the various records in acquisitions - either embedded in the pages or as part of a separate Notes app that FOLIO will build. For categories of AKAs, they could either go in as part of the vendor name, or actually have a separate category. It may depend on what we’re actually trying to accomplish with categories. If trying to show relationships between different organizations, we probably need more formal categories. If just needed for searching purposes, then maybe we don’t need the extra overhead of a special field. In any event, it’s a good suggestion. Regardless of the categories, we’ll want some plain AKA/keyword capabilities too. For example, the vendor code in for Harrassowitz in Harvard’s long-ago NOTIS system was HRSW. Having HRSW as an AKA in FOLIO would make for much easier searching than typing Harrassowitz and hoping I got the numbers of R’s and S’s correct!
Hi Sebastian, I’ll take a quick stab at some of these, then leave more details for the next RM SIG meeting
General: I agree that we need to keep duplication with external financial systems to a minimum. Hopefully a link to the university accounting system, which is usually the accounting system of record, would be enough in most cases. For the form - do you want FOLIO to output a blank form for the vendor to fill out, or a filled-out form based on info stored in FOLIO?
Activity log: we definitely want some sort of log at the bottom of the vendor record that shows all edits/updates to the vendor record. For orders/invoices, do you think we need a log in the vendor record itself, or just links that would take you to orders/invoices? If we put a list in the vendor record, it could get pretty huge. And for correspondence/calls with various contacts, I could definitely see logging that in the vendor record (or having a link from the contact in the vendor record to more detailed contact and contact log info in the contact app).
Summary: not sure why we left out the notes field here, since we put it everywhere else. We’ll definitely ensure there’s a notes field that can be used for a summary of services or whatever else a library wants to not about a vendor.
Currencies: just need to be on the screen somewhere, so we’ll make sure they get into the code, and then folks can review in the first code iteration
URL for the vendor website (not the vendor ordering or admin tool): makes sense - should be on the screen someplace
Addresses - we clearly blew it for international addresses and phone number country codes - will be sure to correct that
My thought is that contacts and addresses don’t always go together. Sometimes you have an address (like for physical returns or payments) that doesn’t correspond to a specific person. When an address does correspond to a person, that can be noted in the contact notes field. Or if FOLIO ends up with a separate contact app, it may addressed in some other way.
For companies and/or people, we may need to include LinkedIn, Skype, XING, WhatsApp, etc. Before we go too far down this path, hopefully the overall FOLIO development community can confirm whether contacts will be handled as a separate app. If so, we wouldn’t have to build all of these fields into the vendor screen, just harvest from the contact app if present, and display in the vendor screen.
Agreement: this is not meant to be all details and exact terms, but a quick summary, with a link to more detailed contract or terms if needed. Is there a way to build this fairly simply for v1 that would still have some utility?
Vendor classification: we would want to include some standard categories to start with, but allow a library to adjust those categories to suit their needs. Perhaps include an “other” or free-text category as well?
Definitely want to review invoice and renewal intervals in future SIG meetings - are these useful fields or not?
Tax - we’ll want a read from the SIG - would it be useful to link to a vendor’s tax form from this record, or just know that it’s stored in the higher-level accounting system? Same with the other registration forms that you mention.
EDI: we wanted to leave it flexible, so that the vendor or the library could decide how best to manage directories. In Harrassowitz case, it sounds like you would perhaps recommend a default setting, unless the library prefers something different. That’s usually how YBP works as well. Other vendors may have more rigid directory or file name structures.
Interface: definitely understand that this needs to be a repeatable section. I agree about the name and password, especially if the vendor record stores an admin level password, when regular acq/CD staff perhaps should not have that level of access. There’s also the question of other types of admin systems for conditioning eContent platforms, plus the eContent platforms themselves. All of this needs to be discussed more within the SIG and within the context of the work that the RM/Austin development team is doing.
Statistics: needs more discussion at RM SIG
Under account, payment method, discount, service charges will flow down from the default, unless a different payment method is defined. Thus, if a library pays via EFT for most accounts, but 1 account is paid via deposit funds, they would just need to update the payment method for that one deposit account. I’m not sure the best way to connect contacts and individual accounts. Individual account numbers are most important for sorting out EDI details. In the contact section, you could have a contact type for “standing orders” or “payments” or “customer service” or whatever, plus more details in the notes field of the contact.
Anti-harrassment, environmental, minority hiring practices, accessibility due diligence documents - I agree that these could be linked here, or maybe handled by the higher-level accounting system. Let’s be sure to discuss at RM SIG.
Phew!
A-M
Hi Steven,
While the Stacks folks are all in Montreal, I’ll take a quick stab at these. Then we can discuss more in RM SIG.
Linking vendor records and licenses. This should be de-able, along with linking to other types of contracts that a library may have with a vendor - in both directions. I’m not totally sure how it would work since I’m not clear on exactly how the license work is developing, and how much is being handled by the Frontside/Austin dev team and how much by Stacks. Definitely something that needs to be discussed and decided.
We’ll definitely have a notes field in the top of the vendor record, plus scattered in all the other sections of the vendor record. Wherever the language field ends up, there should be a nearby notes field that you can use to document the appropriate library staff member for ordering/communication. I could see the same need for library team reminders in the case of other specialized materials such as music, video, archival, specialized subjects, etc.
Hi Kristin,
I’ll take a stab, and then we’ll talk more at RM SIG.
Statistics: I think we need to nail down what is meant by statistics: average fulfillment speed? average discount or service charge? usage of e-resources? turnaways? all of the above? Then figure out all the rest. Is data, reporting, logon info stored here or someplace else, or some in one place, some in another place?
Admin name and passwords: do we want them stored here? If so, would we need to obscure them for staff who should not be able to use them? (e.g. student acq workers, maybe non-admin coll dev staff) If not, where else might they be stored, and then accessed if the person viewing the vendor record had appropriate permissions?
Status, branding, software platform: store here or someplace else? This is where the concept of vendor as the library’s financial partner vs vendor as licensor vs vendor as platform provider gets confusing to me. We definitely need all of this info in FOLIO, either stored as an organization and exposing particular bits in particular apps, or stored in a giant vendor record in Acq that all the other apps access for necessary info.
Thanks,
A-M
Hi Kristin and Virginia,
For W-8s and W-9s, wire worksheets, etc - I agree that being able to link all sorts of docs to the vendor record would be helpful. For v1, maybe it would just be links. For future versions, maybe FOLIO could be autopopulating some of the forms, like the wire transfer worksheet.
We definitely need notes and contact activity associated with the vendor and/or specific contacts. I can see this being important in day-to-day work as well as more concentrated work like contract or license negotiations. If there was info about specific financial terms or hard-fought negotiation wins, would there need to be an additional layer of permissions/security around viewing that info?
Possible duplicates - good point! That feature in Outlook Contacts has probably saved me 100+ duplicate contacts over the years. We’ve mostly been talking about the vendor screen itself and not so much creating/deleting vendors, but hopefully Stacks will be able to take this into account. I also like the idea of notes like in serials cataloging records: “replaced/superseded by…” when you inactivate a vendor that has been bought by another or “replaces” when you build a record for a splitting or renamed vendor, with maybe a way to link to the previous/next vendor record(s). Maybe the linking is v2, but a definitely a good idea to capture.
Hi Scott and Virginia:
Quick reply since Stacks is still in the dev summit:
We definitely need to discuss discounts, charges, fees at RM SIG. If this is meant to do something automatically (e.g. calculate estimated discounted/service fee price for encumbering), then we need very specific details and the ability to vary at the account level, by percentage and/or fixed amount. If it’s just supposed to be informational, with no calculations attached to it, then maybe the info can be free-text summary, with details in a linked contract/statement of work document. I’m not saying one or the other is better or more desirable. Stacks will just need to understand what we’re expecting FOLIO to do with that info in order to determine how carefully and detailed the underlying programming and architecture will need to be.
Accounts Payable System number: ideally would be at the vendor level and the accounts would inherit it. If a couple accounts need a different AP number, then that different number would be recorded at the account level. Either way, we need to make sure our terminology is consistent, and that it’s clear when account-level details can be inherited from the vendor level or changed.
Agreements: sounds like we need a way to link to agreements/documents at both the vendor and account level - right?
Tax docs: this has been raised by others; definitely need a way to link to various tax docs, but also being careful about how much info from the higher-level financial system’s vendor record is repeated in the FOLIO vendor record. And I agree about security/permissions. I’m a little concerned about sensitive pricing info, social security numbers, tax info, etc being available for anyone with vendor permissions to access. There may need to be an additional layer of permissions for access to sensitive legal or financial info.
Hi A-M
I think the discounts/additional charges/service charges/other charges should be able to do something related to encumbering (as well as reporting and here I am thinking of things like forecasts for serial expenditures).
Your description of Agreements sounds like what I had in mind.
Hi Ann-Marie,
Thank you for going through all of my comments.
-> I think some sort of export function would be useful too. Is there a platform wide approach on export functions in FOLIO already? But I was more thinking about a blank form the library can send to the vendor. This way the vendor can fill out most of the data themselves and the library saves time. One could think about uploading this form into FOLIO automatically too. But this might be to much developing time for the benefit.
-> That makes sense. It will be interesting to think about the central contacts app in more detail.
-> This one we’ve talked about already in our last SIG meeting. We just have to be careful to not limit this functionality with defining the quick summary too narrowly.
-> Agreed
-> I think these are important fields. Again they need to be flexible though. In our case we set 11 invoicing dates for subscriptions per year by default or accept an individual invoicing schedule by our customers. This could not be represented by an invoicing interval field. And the invoicing schema varies between books and journals. Regarding the renewal interval we have a default deadline in September that could vary with particular publishers and can be prolonged too. I am not sure what would be the best way to display this.
Thank you, Sebastian
Today at RM SIG meeting, @dennisbridges asked us to think about how the system could help prevent duplicate vendor records. At Chicago, we recommend using fuzzy matching on the name. We don’t create vendors records too often, but if we felt like we needed to, and started to input a name very close to another vendor’s name, the system could come up with a warning that XX vendor may already have a vendor record–is the the same vendor? Then the user inputting the new record could decide, “yes, it’s the same” and cancel the new record to use the existing record, or “Nope, not the same,” and create the new record.
Since we have talked about keeping interface in the vendor record for the moment, and collapsing the statistics sections into the interface, here are my suggestions for additional fields about the interface:
New suggestions (assuming you will get rid of statistics areas)
Branding Image uploaded (checklist for branding information)
Interface type (controlled list to indicate whether it’s an admin platform, user stats platform, vendor order interface, etc. - this should be locally configured)
COUNTER usage statistics? (checkbox)
Other usage statistics (checkbox)
Statistics note
Since we were discussing claiming at today’s RM SIG meeting, this is what I heard from the Head of Acquisitions at Chicago:
Monograph claiming – there isn’t any functionality in OLE, and while we do not do it as a matter of routine, we do claim patron requests, rushes, and reserves. The process is manual and painful. I don’t necessarily need EDI claiming – as many vendors we would claim from wouldn’t have that capability anyway, I would like the ability to set a PO to “claim” or “no claim” and to have a report generated on a weekly, monthly, quarterly, ad hoc, basis for the items needing claiming. An additional functional plus would be to generate claim letters from the system information that we could email out either from the system (ideally) or manually.
I like this idea - simple and puts the decision in the user’s hands.
Sometimes the means of contact with a vendor is via website where we complete a form. This usually is in lieu of a helpdesk@xxx.com address but it could be the principle way of contacting the appropriate representative.
Contact persons may leave a specific vendor and/or join another. We need a way to mark a contact person as “no longer a rep for us” but we don’t want to delete that contact because we need the historical communications.
Include a field for fax numbers. Include fields for multiple phone numbers, i.e. p. for phone, m. for mobile, f. for fax.
In general, don’t be stingy on the character limit!!!
Make the interface searchable by contact name, vendor code, vendor name, etc. Keeping the vendor name first-name last-name fields separate makes searching easier.
It’s not clear there is a way to determine which staff last worked on this app, or any app. That is helpful when questions come up as to why something was done a certain way.