1 <?xml version="1.0" encoding="UTF-8"?>
\r
2 <chapter xml:id="releasenotes" xmlns="http://docbook.org/ns/docbook" version="5.0" xml:lang="EN"
\r
3 xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:xlink="http://www.w3.org/1999/xlink">
\r
5 <title>2.0 Feature List</title>
\r
10 <title>Circulation</title>
\r
12 <title>Patron Registration Enhancements</title>
\r
14 <listitem>Zip code information can be added to a local table which will pre-populate the City/State fields during patron registration. </listitem>
\r
15 <listitem>Added the ability to delete patrons by anonymizing the patron's personally identifiable data and purging the related data from other tables
\r
16 without destroying information important to the integrity of the database as a whole (does not delete the actor.usr row). </listitem>
\r
17 <listitem>Supports the ability to merge patrons; when it is determined that more than one account exists for a single patron. There is an interface for
\r
18 side-by-side comparison of the records; ability to delete addresses on merged accounts, delete cards and deactivate cards. Patrons with a status of in collections
\r
19 are not eligible for merging. </listitem>
\r
20 <listitem>Added quick links for staff to copy and paste patron address information. Information will paste in a standard mailing format. </listitem>
\r
21 <listitem>Patrons with an address alert (invalid/bad address) will be displayed at the top of a duplicates list. </listitem>
\r
22 <listitem>Patrons may create library accounts through the OPAC. These are set as pending until they can be confirmed by staff. The backend support for this
\r
24 <listitem>The system recognizes certain categories of patrons like Card Canceled, Deceased, etc. and will not place holds for these categories. </listitem>
\r
26 <listitem>The patron record screen obscures certain information which can be considered sensitive. </listitem>
\r
27 <listitem>Patrons may create library accounts through the OPAC. These are set as pending until they can be confirmed by staff. The backend support for this
\r
29 <listitem>Evergreen has the ability to automatically enter date, user, and location in messages and notes.</listitem>
\r
33 <title>Item Checkout enhancements</title>
\r
35 <listitem>During check-out, the patron's fines list appears first if there is a balance. If there is an alert, the alert page will show first, then fines
\r
37 <listitem>Evergreen has the ability to track hourly checkout stats. Self-check now operates by workstation and it's possible to gather statistics for checkouts
\r
38 between staff workstations and self-check workstations. (There is a workstation registration wizard built into the self-check UI.) </listitem>
\r
39 <listitem>Audible cue support, for successful and unsuccessful check-out, at self check-out stations has been added. This is customizable at the database level.</listitem>
\r
40 <listitem>Evergreen has fast-add capability. During check-out, if an item is found not to be cataloged,you can pre-cat the item quickly, we've added other field
\r
41 such as library, ISBN and circ modifier to this pre-cat. </listitem>
\r
42 <listitem>The system supports sets or kits of items and has the ability to display the number of items and a list of descriptions. </listitem>
\r
43 <listitem>Evergreen allows patrons to renew a title as long as they have not exceeded the allowed number of renewals and there are more available items
\r
44 than there are unfrozen holds. This is an administration setting. </listitem>
\r
48 <title>Self Check module enhancements</title>
\r
50 <listitem>In self check and SC, if a staff member checks out an item to a patron that is already checked out to that patron, the item will simply renew. This does
\r
51 have configurable age-based parameters to prevent a double scan at checkout resulting in a renewal. </listitem>
\r
52 <listitem>For self check receipts, receipts include the same information for renewal as checkouts and includes notes on items that failed to renew. </listitem>
\r
53 <listitem>In the self-check UI, patrons can view holds and patron position vs. the number of circulating copies. </listitem>
\r
54 <listitem>The self check-out station displays holds ready for pickup, then removes each hold as the item is checked out. </listitem>
\r
55 <listitem>Evergreen supports the ability to pay fines with a credit card at self check-out stations. This requires the library to have a merchant account with a credit
\r
56 card processor like Paypal. The current supported processors include Authorize.net and Paypal.</listitem>
\r
60 <title>Item Check-in enhancements</title>
\r
62 <listitem>Evergreen supports a set number of claim returns allowed; beyond that, additional claim returns require supervisor authorization. This is based off the
\r
63 claims returned counter. This only blocks another claim returned, and circulation can still occur. Also, there is a new permission to allow changing the claims
\r
64 returned count for a patron. In order to use this feature, staff needs to have the appropriate permission. </listitem>
\r
65 <listitem>There's a new calendar widget in the backdating function in the item check-in module. The system has the ability to select items already checked in
\r
66 and retroactively backdate those items, using a button with a calendar selector. Any fines resulting from original check-in are removed. When a check-in is backdated,
\r
67 the item record retains both the actual date of check-in and backdate used. This information will display in the copy details interface. </listitem>
\r
68 <listitem>When marking an item damaged, several library settings are checked to determine whether the patron should be charged the copy price and/or a processing fee.
\r
69 Staff is prompted with this amount, which can either be applied or modified or canceled. </listitem>
\r
73 <title>Holds Enhancements</title>
\r
75 <listitem>Evergreen allows for hold slips to be customized to include any field from the patron record and/or item record, in any position and orientation on the
\r
76 slip. Font, font size, and font weight are customizable. In addition, the hold slip may include a branch symbol (gif or jpg format) </listitem>
\r
77 <listitem>Evergreen supports behind the desk indicator printing on holds slip for patrons who have this flag in their patron record. (This would be for libraries
\r
78 with public hold shelves.) </listitem>
\r
79 <listitem>In Evergreen, between the time that a hold is checked in and a hold is placed on the hold shelf, there is a configurable delay before the status is changed
\r
80 to On Hold Shelf. </listitem>
\r
81 <listitem>Evergreen has the ability to ensure that manually edited copies (either deleting or changing to a non-holdable status) will have their holds
\r
82 retargeted. </listitem>
\r
83 <listitem>In Evergreen, between the time that a hold is checked in and a hold is placed on the hold shelf, there is a configurable delay before the status is
\r
84 changed to On Hold Shelf. </listitem>
\r
85 <listitem>The system supports a Clear Hold Shelf process. First, it removes holds from items that have expired on the hold shelf, and generates a report (aka clear
\r
86 hold shelf report) listing items to be cleared from hold shelf. Then staff can print the list, go out and physically pull the items off of the hold shelf. Next,
\r
87 staff scan the items in EG to either reset the items to the correct shelving location, capture the next hold or put the items in transit to the correct owning
\r
88 location.</listitem>
\r
89 <listitem>Staff can extend pickup deadlines for holds.</listitem>
\r
90 <listitem>In the patron view in the SC (staff client), you can select multiple holds in actions for selected holds and choose to change the pickup location.
\r
91 Evergreen has the ability to change the pickup location for all of a patron's holds in a single process. Additionally, Evergreen has the ability to modify all
\r
92 holds attached to a bibliographic record, including the ability to change the hold expiration date. This functionality is covered with current bib holds list
\r
93 interface. </listitem>
\r
94 <listitem>Evergreen allows patrons with specific permissions to place holds on items they have already checked out. All other patrons cannot. This works by warning the
\r
95 user that the item is already checked out to them and, if they have the permission, the system gives them the ability to override. </listitem>
\r
96 <listitem>The system supports the ability to place holds on titles with status on-order. For additional information, see the Acquisitions notes later in this
\r
97 document. </listitem>
\r
98 <listitem>Evergreen has the ability to designate specific org units that will not trigger a hold upon check-in. </listitem>
\r
99 <listitem>Evergreen added logic to hold targeting to skip branches that are closed at the time of hold placement and <varname>x</varname> time (<varname>x</varname>
\r
100 time being a set interval). This is
\r
101 to prevent the hold being targeted at branches that will be closed Saturday and Sunday (for example), making it impossible for patrons to receive their hold. This
\r
102 presumes there is another copy available at another branch. </listitem>
\r
103 <listitem>There are more options now for hold settings. One option is library weighting as well as looping. If looping is set, the holds targeter will skip any
\r
104 libraries that it targeted in a previous loop and will continue doing so until it has tried all libraries at which point it will start the process over again. If max
\r
105 loops are being used in hold management, at the end of the last determined loop, if there are no copies that could potentially fill a hold, the hold may be canceled.
\r
106 If there are checked-out copies, the hold stays in queue; otherwise, the hold is canceled and a cancellation notice is sent to the patron. </listitem>
\r
107 <listitem>The system offers the ability to secondarily sort the Holds Pull List by physical shelving location within the library.</listitem>
\r
108 <listitem>The system offers the ability to distinguish between staff-placed holds and patron-placed holds through a column in the holds interface. </listitem>
\r
109 <listitem>Hold cancellation can be displayed, along with information regarding the cancellation (e.g., cause, cancellation type, date, item, patron, etc.) </listitem>
\r
110 <listitem>There is support now in the system to allow configuration to disallow holds for items that are on the shelf at the location from which the patron is
\r
111 searching. </listitem>
\r
112 <listitem>The system supports patron specific hold notes that can display in the OPAC and print in the hold notice, but do not necessarily print on hold slips. </listitem>
\r
113 <listitem>The system supports ability for staff to move someone to the top of the holds queue. This was developed due to cases where a patron picked up a hold but the
\r
114 item was damaged. Since the patron had picked up the hold, it was considered filled. </listitem>
\r
115 <listitem>The patron can change the pickup location before the hold is ready for pickup. Then, the item is put in transit & a new holds slip is printed with a
\r
116 special symbol to indicate that the pickup location has been changed. If the location is changed while the item is in transit, than at next checkin the item is put
\r
117 in transit to the new location. A new holds slip is printed. </listitem>
\r
118 <listitem>The system supports a separate hold note field for staff use that can print on hold slip.</listitem>
\r
119 <listitem>Ability for patrons to view recently canceled holds and easily re-place holds.</listitem>
\r
124 <title>Staff Client Interface Enhancements</title>
\r
126 <listitem>Evergreen includes color-coding into staff view of patrons when there is a bad or invalid address. Also included is an alert to patrons in the My Account view
\r
127 in the OPAC to alert them to the bad address problem. System automatically blocks /unblocks a patron when an address is marked invalid/valid. </listitem>
\r
128 <listitem>Ability to have the staff client automatically minimize after a settable period of inactivity to protect patron privacy. This is controlled through an org
\r
129 unit setting.</listitem>
\r
130 <listitem>Summary of bills, checkouts, and holds are visible from all of the patron screens.</listitem>
\r
131 <listitem>Historical summary of paid fines is sortable by column and displays sub-totals for each column; also allows the ability to limit by voided/non-voided
\r
132 payments. Fines history detail includes more information including location and time/date where item was returned and much more. </listitem>
\r
133 <listitem>More streamlined display of copy information including number of copies, copy status, and number of holds in both staff client interface and patron
\r
135 <listitem>The system supports the ability to edit item records from any item record access point. </listitem>
\r
136 <listitem>From holding maintenance or item status by barcode, you can retrieve more item details. For example, total circulations by current and previous year, last
\r
137 status change, last checkout date & works station, last checkin time and workstation, and more. </listitem>
\r
138 <listitem>The system includes a separate date field for the last change to the item in the item record. </listitem>
\r
139 <listitem>In the item record, the system displays total check-outs and renewals for year-to-date, previous year, and lifetime. </listitem>
\r
140 <listitem>Better audio signal handling.</listitem>
\r
141 <listitem>In Evergreen, there is an org setting to disable all staff client circ popups unless an unhandled exception occurs. The exception handling has been automated
\r
142 as much as possible, based in settings, to prevent the amount of popups that require staff attention at the circ desk. Alerts are communicated visually (e.g., screen
\r
143 color change) or audibly. </listitem>
\r
144 <listitem>The system supports two views of patron information: horizontal and vertical. </listitem>
\r
145 <listitem>From the patrons screen, under holds, clicking place hold will bring up an embedded catalog. Placing a hold from the embedded catalog will automatically
\r
146 generate a hold for the current account of the patron you are viewing. </listitem>
\r
147 <listitem>The system supports a new messages (notes) UI in the info tab of the patron screen. </listitem>
\r
148 <listitem>The system supports a new interface that shows the most recent activity on the workstation (checkout/checkin/ renewal/ patron-reg activity, with links to
\r
149 relevant patron from each item). This would be helpful to a supervisor trying to backtrack an issue to assist a staff member. </listitem>
\r
150 <listitem>The system now captures and displays check-in and workstation history. </listitem>
\r
151 <listitem>Added the ability to pre-define messages, populated in a drop-down menu, to be applied to patron accounts. Includes: the ability to configure the message to
\r
152 act as a penalty (if desired), record the date and staff who applied the message, include a flag to mark item as resolved. If item is marked as resolved it will not
\r
153 display as an alert. </listitem>
\r
154 <listitem>Under grocery billings in Evergreen, billing type can be pre-populated with a list of common fine events (such as types and costs). </listitem>
\r
155 <listitem>Evergreen has the ability to retrieve users by numberic ID (separate from the barcode) in the staff client. This functionality is optional and set to false
\r
156 by default. </listitem>
\r
157 <listitem>Backend support for other types of receipts (like holds/fines).</listitem>
\r
161 <title>OPAC and My Account Enhancements</title>
\r
163 <listitem>There is backend code support for a method to allow patrons to link their records in a way that grant privileges. This could be utilized in future
\r
164 implementations for social networking features. </listitem>
\r
165 <listitem>Patron passwords are now more flexible in length and content (shorter and numeric-only passwords are now allowed). Libraries can set minimum and maximum
\r
166 limits on password length in Password format in the Library Settings Editor. </listitem>
\r
167 <listitem>Patrons can select a username, which can then be used to access OPAC and self check-out stations.</listitem>
\r
168 <listitem>My Account can allow patrons to update some information including: street address, e-mail address and preferred pick-up library for holds. Changes to address
\r
169 will be marked as pending in the patron's file until a staff member verifies the new address and completes the change. </listitem>
\r
170 <listitem>From the My Account interface, patrons can see their estimated wait time for a hold. Evergreen calculates the estimated wait time from the circ mods on the set
\r
171 of potential copies available to fill the holds on that title. Hold wait estimate is configurable at the consortial level and each Evergreen implementation would need
\r
172 to take into consideration their avg circulation time, hold wait time or other factors like transit time which might influence hold wait estimates. </listitem>
\r
173 <listitem>Patrons can title their bookbags (aka reading list) and place holds from it. </listitem>
\r
174 <listitem>Backend support has been developed to allow patrons to waive certain kinds of notices. </listitem>
\r
175 <listitem>The system supports combining multiple notices of the same type to the same patron into one event, so long as the system is configured to batch notices
\r
176 on an approximately daily basis.</listitem>
\r
180 <title>Billing, Collections and Fine/Fee Enhancements</title>
\r
182 <listitem>Fines now consistently link to item record details.</listitem>
\r
183 <listitem>The fine record includes a comments field, editable by staff. Staff can annotate payments and add notes to a specific billing. Staff can sort on payment
\r
184 type. When adding note, the current text shows as default in a pop-up window, so it can be appended or over-written. </listitem>
\r
185 <listitem>Staff and users can now only pay using the latest user data, which prevents accidental/duplicate payments against the same transaction or against stale
\r
187 <listitem>The system supports setting the maximum fine based on item type (e.g. generic=.50) AND not to exceed the cost of item. This works as an inheritable OU
\r
188 setting, circ.max_fine.cap_at_price, that changes the max_fine amount to the price IF the price is not null and is less than the rule-based max_fine amount. </listitem>
\r
189 <listitem>The system has the ability to run a report of accounts with users with overall negative balances, including the balance owed and last billing activity
\r
190 time, optionally filtered by home org. There is an option for issuing refunds for selected accounts on the resulting list. The report also captures patrons with
\r
191 any refundable transaction. </listitem>
\r
192 <listitem>Evergreen provides 3 distinct and independent types of blocks: system, manual and collections. Manual and collections are set manually by staff. </listitem>
\r
193 <listitem>A new penalty type of <varname>PATRON_IN_COLLECTIONS</varname> has been added. Its set when the collections agency puts the patron into collections, staff can define the blocks
\r
194 and clear threshold for each group, etc. The system supports removing collection block immediately once charges are paid down to zero (applies to both ecommerce and at
\r
195 CIRC desk).</listitem>
\r
199 <title>Action/Triggered Event and Notice Enhancements</title>
\r
201 <listitem>Action Triggers (AT) support many new notices for events such as items that are about to expire off of the hold shelf; items that are on hold and are about
\r
202 to reach the max hold time (if one is set); courtesy notices that are prior to due date. AT also logs all notices sent to patrons and this is accessible to staff in the
\r
203 SC to view all notices or cancel all pending notices.</listitem>
\r
204 <listitem>The system has the ability to cancel unsent notices before they are sent and the ability to search pending notices by item barcode.</listitem>
\r
205 <listitem>Administrators can choose to implement a collections warning prior to sending patrons to collections. When the account balance of the patron meets a
\r
206 certain threshold, they are sent a bill notice. This is driven by the total amount owed, not by individual bills. The patron is sent to collections after a
\r
207 configurable number of days since the bill notice was sent. The billing notice is handled with a new PATRON_EXCEEDS_COLLECTIONS_WARNING penalty. Files can be sent via
\r
208 <systemitem class="protocol">SCP</systemitem> and <systemitem class="protocol">FTP</systemitem>.</listitem>
\r
212 <title>Acquisitions</title>
\r
214 <listitem>From within the general acquisitions search page, users are able to search on many fields in the acquisitions /serials workflow. For example on attributes
\r
215 of invoices, purchase orders, selection lists, bib records, etc.</listitem>
\r
216 <listitem>General catalog searching is now supported for explicit truncation/wildcard searches.</listitem>
\r
217 <listitem>Acquisitions line item searches support NOT searches. </listitem>
\r
218 <listitem>Money can be transferred from one fund to another (or to none).</listitem>
\r
219 <listitem>All transactions (except batch EDI delivery to vendors) post in real time including: purchase orders, invoices, fund balances, vendors balances, vendor
\r
220 statistics and history. EDI delivery delay is configurable at the system level admin interface.</listitem>
\r
221 <listitem>In the User Interface, users now have access to all active funds, spanning multiple years, in the various ordering/invoicing/etc interfaces.</listitem>
\r
222 <listitem>There is support for year-end fiscal turnover process that closes out funds and transfers encumbered amounts into a new fiscal year. This includes the ability
\r
223 to selectively roll certain funds over, while not rolling over others. </listitem>
\r
224 <listitem> Evergreen handles validation of ordering, receiving,and invoicing processes, using validated data, to satisfy auditor requirements. In the staff client,
\r
225 there is a menu option which allows staff to locate the PO that resulted in the purchase of that copy.</listitem>
\r
226 <listitem>Selection lists are collections of bibliographic records (short or full) that temporarily store titles being considered for purchase. Selection lists can be
\r
227 shared for collaborative input.</listitem>
\r
228 <listitem>Library staff have the ability to create distribution formulas for ease of receiving, processing and distributing materials. Branch, shelving location, and fund need
\r
229 to be separate from the distribution formula, so that staff can enter the distribution sets. Staff are able to use that formula for any shelving location they decide. Staff
\r
230 also have the ability to add multiple distribution formulas together and the ability to override distribution formulas. After applying the distribution formula; it will be an
\r
231 all or none redistribution of copies from one branch to another. Staff can add or delete individual copies because the distribution pattern may not account for the exact total
\r
232 of copies. If the total number of copies has not been allocated, the user will receive a flag or warning. This puts the use count for each distribution formula in the DF
\r
233 dropdown for users to see.</listitem>
\r
234 <listitem>The system supports Batch ISBN/UPC search. This is located in the general Acquisitions search page, where you can choose to search by single isbn, upc, or you can
\r
235 choose to upload a batch of isbns. The ISBN search method looks at MARC tag 024, where UPC codes are supposed to live. For LI searching, the system uses
\r
236 open-ils.acq.lineitem.search.ident. Catalog records are included in the batch isbn/upc search and staff can now search catalog records in the acq search. </listitem>
\r
237 <listitem>Backend support has been integrated to give patrons the ability to submit purchase requests through the OPAC. The UI for this has not yet been integrated into the
\r
239 <listitem> The system supports claiming, specifically there is:
\r
241 <listitem>a place to store the default claim interval for each vendor</listitem>
\r
242 <listitem>a way to show the selected claim date during the order</listitem>
\r
243 ` <listitem>a way to show the selected claim date during the order</listitem>
\r
244 <listitem>a way to override the claim date during order</listitem>
\r
245 <listitem>a way to list items/orders that have reached the claim date.</listitem>
\r
247 A list of items that meet claims requirements can be generated, but claims must be initiated by librarians. </listitem>
\r
248 <listitem>From the UI, staff can access the lineitem and PO history. Entries in the history table are ordered from most recent to oldest.</listitem>
\r
249 <listitem>The purchase order printout is customizable, including the ability to break up a single order into separate purchase orders. Also, staff can print groups
\r
250 of POs from a search as a single printout, which can be used to generate physical POs for vendors who do not support EDI. Staff can add notes and there is an indicator
\r
251 in the PO interface of the existence/number of attached notes. </listitem>
\r
252 <listitem>Staff are able to see all of the lineitems (with prices, copy counts, etc.) for a set of Pos and summary information is listed along the top of the page.
\r
253 The summary information includes: total price, total # lineitems, and total # of copies. Additionally, staff can do a PO search by vendor for all
\r
254 activated-but-not-yet-sent Pos (i.e., show me what we are about to order) and view the results.</listitem>
\r
255 <listitem>The system supports flagging prepaid orders so that invoicing is handled correctly.</listitem>
\r
256 <listitem>The system allows building orders based on templates (distribution formulas); by shelving location or owning library.</listitem>
\r
257 <listitem>The system supports the ability to gather orders together and send them all at once, instead of manually and individually, a rolling FTP function that runs
\r
258 every 15 minutes (or other set interval) with detailed log information and control of frequency and action. Additionally, there is an automatic retrieval of status
\r
259 reports records from the vendor, which are then automatically inserted into the order records. </listitem>
\r
260 <listitem>Staff have the ability to apply and view notes and cancel causes on purchase orders as well as cancel causes on lineitems. In the UI, there is a staff client
\r
261 menu entry for cancel cause.</listitem>
\r
262 <listitem>There is an interface in the ACQ system for viewing what was sent to vendors via EDI. There are two ways to approach the viewing of sent orders: via PO
\r
263 search interface (for the general case) which gives finer detail on EDI orders and the ability to reset failed outbound EDI deliveries. </listitem>
\r
264 <listitem>Pending final UI work in the OPAC, the system has the ability to allow patrons to place volume level and issue level holds. </listitem>
\r
265 <listitem>Ability to create and print routing worksheets for manual receiving processes.</listitem>
\r
266 <listitem>Nothing in the selection lists is holdable (either by patrons or by most staff, apart from acquisitions staff). When an on-order title has been canceled and
\r
267 the lineitem is canceled, the corresponding bib record and on-order copies will be deleted so the copies will no longer be holdable. The lineitem has a cancel cause to
\r
268 show why order was canceled. Selection list records are never visible in the OPAC. Catalog records with no visible copies (within the search scope) do not show up in
\r
269 the public OPAC. This also applies to on-order records. </listitem>
\r
270 <listitem>Deleted bibs, callnumbers, copies, and patrons are retained for reporting purposes. Only patrons can be purged (by staff). “Deleted” items are more
\r
271 accurately described as “inactive.” However, patrons can now be complete purged, however this isn't recommended as you lose historical data.</listitem>
\r
272 <listitem> The system supports shared and floating items by collection. Item records can be added or removed from the collection group and can be updated in batch
\r
273 via buckets in the copy edit interface.</listitem>
\r
274 <listitem>ACQ permissions control which workgroups have view/edit access to lineitem and catalog records while PO/PL and copy-level ownership and permission depths
\r
275 affect viewing in other, more location-specific interfaces. </listitem>
\r
276 <listitem>The system supports the ability to transfer patron holds queue from one bibliographic record to another, singly or in batch, while preserving the original
\r
277 hold order. </listitem>
\r
278 <listitem>The system has a reporting view which allows staff to identify bibs (shows ISBNs) for which the last item was removed based on the date of removal.
\r
279 Report templates can be built from this view for external processes.</listitem>
\r
280 <listitem>The system supports lineitem alerts, lineitem receive alerts, and lineitem detail alerts for EDI messaging.</listitem>
\r
281 <listitem>The system supports the ability to exclude some types of items from patron hold limits.</listitem>
\r
282 <listitem>There is support for new, locally defined, cancel reasons for EDI. There is also support for EG interpretation of EDI defined cancellation standards. </listitem>
\r
283 <listitem>The system supports the ability to send batches of orders to vendors, including orders for multiple accounts. The process of breaking outbound EDI messages
\r
284 into controlled and timed batch sizes is automated but settable to a specific, preferred, time interval.</listitem>
\r
285 <listitem>The system supports the ability to FTP orders directly to vendors and receive acknowledgements and status reports from vendors. More specifically, the
\r
286 system supports push and pull of files via <systemitem class="protocol">FTP</systemitem>, <systemitem class="protocol">SFTP</systemitem> and
\r
287 <systemitem class="protocol">SSH</systemitem>. </listitem>
\r
288 <listitem>The system supports MARC file import with PO data.</listitem>
\r
289 <listitem>The OPAC accepts enhanced content from the following vendors: ChiliFresh, Content Café & Novelist. (note that these are subscription services)
\r
291 <listitem>You can set up vendor profiles and flag those that are active. Those that aren't can be saved for historical purposes.</listitem>
\r
292 <listitem>The system supports the ability to “flag” vendor records for vendor who require pre-payment of purchase orders with a number of visual cues in the UI. During
\r
293 PO creation, the pre-payment flag in the form will show and pre-populate it's value with the value from the chosen provider. During PO activation, if prepayment
\r
294 is required, a confirmation dialog is inserted before sending the activate request. It indicates in the PO summary when a PO requires pre-payment. </listitem>
\r
295 <listitem>The system supports sequential barcode generation for ease of receiving and processing of new items and easily changing large groups of barcodes. There is
\r
296 a choice to use auto generated barcodes in interfaces where they would normally be used (such as receiving). Some parameters about the barcode symbology may need to
\r
297 be entered in the admin interface to correctly calculate the barcodes.</listitem>
\r
298 <listitem>The system supports the ability to manually select libraries to receive items when partial orders are received or when items come in multiple deliveries.
\r
299 Orders with multiple copies will have an owning library per copy, so staff can pick which copies to mark as received.</listitem>
\r
300 <listitem>The system is compatible with Zebra Z4M thermal transfer printers. </listitem>
\r
301 <listitem>The system supports the ability to create, format and print spine labels. </listitem>
\r
302 <listitem>In the ACQ UI, there is a batch fund updater. When there is a given set of line items, the batch fund updater updates the fund for all attached copies in
\r
304 <listitem>The system has a configurable drop-down of alerts for line items that staff can control. </listitem>
\r
305 <listitem>The system supports the ability to update order records at the receiving stage; the ability to receive partial orders and unreceive orders; and the order
\r
306 record is updated automatically when the balance of a partial order is received. </listitem>
\r
307 <listitem>The system supports the ability to transfer item records from one bibliographic record to another. </listitem>
\r
308 <listitem>The system supports a worksheet for each title received, to include title, call number, number of copies received, distribution, and processing notes. </listitem>
\r
309 <listitem>The system supports the ability to easily scan over a “dummy” or placeholder barcode in a temporary, brief or on-order record by simply scanning the
\r
310 <quote>real</quote> barcode.</listitem>
\r
311 <listitem>The system supports the import/export of MARC bibliographic and authority records via Vandelay. An option has been added to use the internal bib ID as the TCN
\r
312 for all records while retaining the OCLC number in the record. The authority import now matches bib import in overlay/merge functionality.</listitem>
\r
313 <listitem>The system is fully compatible with OCLC Connexion for editing and transferring bibliographic and authority records (Z39.50). </listitem>
\r
314 <listitem>The system supports the ability to create a <quote>short bib</quote> record pending creation of the full MARC record. Short bibs can be created from a lineitem
\r
315 search. </listitem>
\r
316 <listitem>The system supports a utility to facilitate searching for full bibliographic records and create temporary <quote>short</quote> bibliographic records if no full
\r
317 records are found. </listitem>
\r
318 <listitem>Added the ability to perform electronic receiving and invoicing as follows: ability to receive electronic packing slips and invoices by purchase order or
\r
319 invoice number; ability to edit number of copies, amount due, freight and service charges, and tax; ability to delete line items; ability to recalculate total
\r
320 amounts; ability to authorize payment within ILS.</listitem>
\r
321 <listitem>System supports the ability to do both regular and generic or blanket invoicing (refers to invoices without a purchase order number, e.g., direct charges to
\r
322 a fund).</listitem>
\r
323 <listitem>System supports simultaneous access to invoice interface.</listitem>
\r
324 <listitem>System supports a number of fields including: date, invoice number, invoice type, shipping vendor name, billing vendor, purchase order number, title,
\r
325 author, number of copies ordered, number of copies paid or received, number of copies available for payment, number of copies being paid for, amount, notes,
\r
326 invoice subtotal, freight charge, service charge, tax, invoice total, & vendor order was placed with. </listitem>
\r
327 <listitem>The system prevents overpayment in the invoice view page by linking invoices to PO/Lineitems. </listitem>
\r
328 <listitem>Staff can print a list of invoices paid before/after a specified date. When searching for invoices in the unified search interface, there's now a button that
\r
329 will print a voucher for whichever invoices have checked checkboxes.</listitem>
\r
330 <listitem>The system supports the ability to search invoices by number or vendor name, with links to vendors, and vendor records include links to invoice history.</listitem>
\r
331 <listitem>Staff can retrieve a PO or lineitem and access all the related invoicing data. </listitem>
\r
332 <listitem>The system supports reopening a closed invoice (example: an invoice was paid from the wrong fund; staff wants to go back and change the fund). There is
\r
333 a <guibutton>Reopen</guibutton> button, which requires permissions. </listitem>
\r
334 <listitem>The system has the ability to pay a partial invoice for partial receipt of shipment, and then generate claims for the items that were not received. Also,
\r
335 the system supports invoicing extra copies when a vendor sends more copies than what staff ordered and staff decides to keep the extra copies. </listitem>
\r
336 <listitem>Issues can be automatically moved to a configured shelving location upon receipt of the newer issue. This can be done on a per item basis and is based on
\r
337 the owning library of the copies. </listitem>
\r
338 <listitem>When using full serials control, the default behavior for serials issue sorting and display in the holdings display will be reverse chronological order.</listitem>
\r
339 <listitem>Staff can label serials issuances with easily identifiable text such as <quote>YYYYMONTH</quote> or <quote>V.12 NO.1</quote>.</listitem>
\r
340 <listitem>In serials receiving staff are able to choose which issues to receive and distribute to which locations.</listitem>
\r
341 <listitem>Staff can add regular, supplemental, and index issues in the serials interface. </listitem>
\r
342 <listitem>The system supports purchase alert query (aka holds ratio report, holds alert report) compares holds to items and flags titles that need more copies.
\r
343 The option exists to include inprint/out-of-print status from the bibliographic record. The system also handles the ability to add query results directly to
\r
344 selection lists, singly or in batch, and the ability to create order records directly from query results. This is handled by an interface for uploading a CSV file
\r
345 to generate a page of bib records that can have lineitems created from them to go into selection lists and/or POs.</listitem>
\r
projects / working / Evergreen.git / blob