Vendor data should be definable at the consortial level for any member library to reference
- Dennis Bridges
Problem(s):
The central office of a consortium may want to maintain an "official" list of certain types of records - Organizations in particular - for members to access and use and attach their own member-specific information in appropriate accordions.
The main information (e.g. name, code) should only editable centrally. Other information (e.g. contact persons, account info, integrations) should be customizable at the member level.
Use Cases & Requirements:
Legend |
Scope may require separate feature |
Requirement | Status | Use cases |
|---|---|---|
Allow Organization record to be shared at the consortia level. Allow user to share local organization record with entire consortia | Verified | Organizations generally have data that is universal and some that is specific to their relationship with a given library. Like Contact people. |
Allow contact people to be assigned locally to shared vendor records. These contact people should only be visible when viewing the organization in the tenant in which the contact people were created | Verified | Individual libraries or departments may deal with specific people/representatives of the organization. In consortia there is confusion around who's contact is who’s. The list of contacts being shared is even an issues because you need to differentiated the actual contact records from one another. |
Allow Privileged donor information to be assigned locally to shared vendor records. These Privileged donor information should only be visible when viewing the organization in the tenant in which the Privileged donor information were created | Verified | Individual libraries or departments will have specific Privileged donor information regarding their dealings with a given organization Same issue as above regarding donor information |
Allow notes to be assigned locally to shared vendor records. These notes should only be visible when viewing the organization in the tenant in which the notes were created | Verified | Individual libraries or departments will have specific notes regarding their dealings with a given organization. Library specific notes. Eg, “really liked working with so and so”, remember to pay X, Had trouble dealing with X. Ideally these are shown only to members of library as they are very specific to that library. Not necessary a security/privacy risk. These may even confuse other libraries that deal with different people etc. These would also be much more useful if searchable |
Allow Interfaces to be assigned locally to shared vendor records. These Interfaces should only be visible when viewing the organization in the tenant in which the Interfaces were created | Verified | Individual libraries or departments will have specific Interfaces regarding their dealings with a given organization. Generally libraries have their own credentials for interfaces so currently sharing interfaces is problematic. However when each library creates their own it becomes difficult to identify who’s is who’s in the list of interfaces. |
Allow Integration details to be assigned locally to shared vendor records. These Integration details should only be visible when viewing the organization in the tenant in which the Integration details were created | Verified | Individual libraries or departments will have specific Integration details regarding their dealings with a given organization. Some libraries have different integration for different orders AND for different sub-libraries as well. |
Allow Account numbers to be assigned locally to shared vendor records. These Account numbers should only be visible when viewing the organization in the tenant in which the Account numbers were created | Verified | Individual libraries or departments will have specific Account numbers regarding their dealings with a given organization. Shipping and Billing addresses as well as account numbers must be unique. If not it is possible for parts of the workflow to confuse orders for different libraries. Payment method could be different between different libraries in a system even for the same vendor. One might use physical check and the other ACH (Automated Clearing House) Each institution has unique accounting codes. |
Allow Vendor terms to be assigned locally to shared vendor records. These Vendor terms should only be visible when viewing the organization in the tenant in which the Vendor terms were created | Verified | Individual libraries or departments will have specific Vendor terms regarding their dealings with a given organization IT’s possible that libraries will have different discount rates and these discounts should not be disclosed to other institutions. |
Existing Accordions for Reference
Summary
Notes
Contact information
Contact people
Privileged Donor information
Interface
Vendor information
Vendor terms
Integration details
Accounts
Proposed workflow:
Questions:
Question | Status | Conclusion | Comments |
|---|---|---|---|
Should local data be visible to other member libraries at all? Say you add a note, are there situations where you would want other libraries to be able to see that. | Open |
| No specific use cases have been raised for making certain local data “shared”. |
Are there specific fields in Summary, Vendor information, vendor terms accordion that should actually be localizable? | Open |
| Yes in some cases discounts should not be disclosed. However, other settings in vendor terms and information are general |
Functionality Potentially Impacted by Changes:
Functional area | Records | Potential impact | Suggested Regression Testing |
|---|---|---|---|
|
|
|
|
|
|
|
|