It would be a nice enhancement to be able to separate Donors from Vendors. Right now some libraries are using Vendors to track Donors. Overtime, this creates an unmanageable number of vendors not used for day-to-day ordering or receiving. Libraries like to create baskets and add donor items via Acquisitions because it enables them to track the value of donations. This expands some of the ideas in Bug 37674 and Bug 37677. There may be a number of approaches on how to implement this. If a Vendor had a donor flag, the donor could live on a separate table, but still be available to use when an item is "ordered" through acquisitions. If there was a Donor page with its own result list, it opens up some interesting tracking possibilities and the ability to search Donors separately from Vendors.
Hi Esther, some ideas about this for a possible workaround or starting a solution: * Create a vendor type of Donor to assign to these vendors. This will help to distinguish them in reporting and maybe later other functionality will be added to allow for filtering. * Use a "Donor" vendor for all of them and a "Donor fund". The statistics fields linked to the fund could then be used to track more information about the individual donor either as pull downs or free text. I guess it depends on how much information about the Donor is needed and how structured it needs to be.
+ 1 We would love to see this differentiation. We have thousands of individual donors all mixed in with purchasing vendors. We have created different authorized values to distinguish them, but we can't sort them or isolate them that way - it's just a label for us. Have a different page would save a lot of time and help our vendors load faster.
Katrin, The workaround is to do as you suggest. However, if a library tracks individual donors rather than a generic vendor of Donor, it becomes problematic because they can create thousands of donor vendors. Thus the need to separate vendors from donors. There are few library examples with 8,000 vendors and 99.9% of them are actually donors. This number of vendors can cause slow page loading and searching, which I think has been addressed in other bugs.
(In reply to Esther Melander from comment #3) > Katrin, > > The workaround is to do as you suggest. However, if a library tracks > individual donors rather than a generic vendor of Donor, it becomes > problematic because they can create thousands of donor vendors. Thus the > need to separate vendors from donors. There are few library examples with > 8,000 vendors and 99.9% of them are actually donors. This number of vendors > can cause slow page loading and searching, which I think has been addressed > in other bugs. Hi Esther, thanks for explaining! I think some of these problems will be improved by the work on moving vendors to vue and making things all API driven. I hesitate to move them to a separate table in the database, I think a lot of the issues could be solved by filtering and having different "types".