1. The serials binding process (including services bind-01 and bind-02) versions 17, 18 and 19 ELUNA Second Annual Conference 2007 Ex Libris North American 2007 Technical Seminar Presenter: Yoel Kortick

2. The serials binding process 2 Copyright Statement All of the information and material inclusive of text, images, logos, product names is either the property of, or used with permission by Ex Libris Ltd. The information may not be distributed, modified, displayed, reproduced – in whole or in part – without the prior written permission of Ex Libris Ltd. TRADEMARKS Ex Libris, the Ex Libris logo, ALEPH 500, SFX, SFXIT, MetaLib, DigiTool, Verde, Primo, MetaSearch, MetaIndex and other Ex Libris products and services referenced herein are trademarks of Ex Libris, and may be registered in certain jurisdictions. All other product names, company names, marks and logos referenced may be trademarks of their respective owners. DISCLAIMER The information contained in this document is compiled from various sources and provided on an "AS IS" basis for general information purposes only without any representations, conditions or warranties whether express or implied, including any implied warranties of satisfactory quality, completeness, accuracy or fitness for a particular purpose. Ex Libris, its subsidiaries and related corporations (the "Ex Libris Group") disclaim any and all liability for all use of this information, including losses, damages, claims or expenses any person may incur as a result of the use of this information, even if advised of the possibility of such loss or damage. © Ex Libris Ltd., 2007

3. The serials binding process 3 Introduction Within ALEPH, binding is defined as the process whereby a group of items are "bound" into a single new item (the bound volume), and consequently deleted from the system (although still kept in the system as "historical" items). The way in which the OPAC indicates that volumes/items have been removed for binding purposes is also part of the process. Binding usually, though not exclusively, relates to serial issues or series volumes

4. The serials binding process 4 Binding workflow part one of two 1.A Journal exists with subscription and the subscription includes a binding procedureA Journal exists with subscription and the subscription includes a binding procedure 2.The binding procedure is defined as desired in ADM $data_tab/tab_binding and $data_tab/pc_tab_exp_field.lngThe binding procedure is defined as desired in ADM $data_tab/tab_binding and $data_tab/pc_tab_exp_field.lng 3.A binder exists and is registered as a patron with local record and as a vendorA binder exists and is registered as a patron with local record and as a vendor 4.Circulation policy exists for the patron (who is actually a vendor) including tables tab15.lng, tab16, tab31, tab37 pc_tab_exp_field(_extended).lngCirculation policy exists for the patron (who is actually a vendor) including tables tab15.lng, tab16, tab31, tab37 pc_tab_exp_field(_extended).lng 5.Serial items arrive consituting at least one binding volumeSerial items arrive consituting at least one binding volume 6.Service bind-01 is run and report and output file are produced, process status is automatically changedService bind-01 is run and report and output file are produced, process status is automatically changed

5. The serials binding process 5 Binding workflow part two of two 7.Service bind-02 is run and report and pickup slips are produced, hold request is automatically made for issues to binder.Service bind-02 is run and report and pickup slips are produced, hold request is automatically made for issues to binder. 8.Issues ready for binding are collected by library using the report printed from bind-02. Slips from bind-02 are placed in each set of binding volumesIssues ready for binding are collected by library using the report printed from bind-02. Slips from bind-02 are placed in each set of binding volumes 9.The issues are loaned to the binder. Loan is made in standard way via circulation moduleThe issues are loaned to the binder. Loan is made in standard way via circulation module 10.Items are returned from binder and returned via the circulation moduleItems are returned from binder and returned via the circulation module 11.Items are "bound" via the "bind/changes" button of the items list in cataloging or serials moduleItems are "bound" via the "bind/changes" button of the items list in cataloging or serials module 12.New description and process status is given to the new bound item.New description and process status is given to the new bound item.

6. The serials binding process 6 A brief word about External Binding Software The external binding preparation software packages ABLE ™ and LINCPlus can be used with ALEPH. This requires Ex Libris licensing (it is not included in the standard ALEPH 500 software package). This presentation will not include the use of external binding preparation software. There is no conflict between using the external binding preparation software and using the services bind-01 and bind-02. In fact, they complement each other. If you do not use ABLE of LINCPlus then skip this slide

7. The serials binding process 7 A brief word about External Binding Software When using external binding preparation software an item is “checked out”, which means that it is sent to the bindery. This is done in one of two ways: 1.Set the item's process status to a status that reflects that it was sent to binding. 2.Loan the item to the binder with the due date for the loan set to the expected arrival date of the bound item back in the library. See link here for more information If you do not use ABLE of LINCPlus then skip this slide

8. The serials binding process 8 A brief word about External Binding Software Check in: When an item is received from a bindery it is “checked in” to ALEPH. This is done in one of two ways, that correspond to the check out process: Reset the item's process status to the original status that existed before it was changed to sent to binding. Return the item that was loaned to the binder. If you do not use ABLE of LINCPlus then skip this slide

9. The serials binding process 9 A brief word about External Binding Software Thus when using the external binding software check in and check out is used via a change in the item process status of via a loan procedure. The automatic change of the item process status may be done via the service bind-02, which will be discussed in this presentation. The loan is done via the circulation process. For more information on External binding software see chapter six of the ALEPH 18.01 user guide – items. If you do not use ABLE of LINCPlus then skip this slide

10. The serials binding process 10 Terminology Serial Volume = the amount of issues which comprise one volume for a serial. For example an annual serials will usually have 12 issues per volume Binding Volume = the amount of issues bound together for a specific serial. For example an annual serial with thick issues may be bound in two physical volumes, issues 1-6 and 7-12. In this case the binding volume would include 6 issues.

11. The serials binding process 11 Our Example (slide 1 of 4) In order to show the process we will have a real journal with a real subscription. Here we have system number 50861 in USM01, “Nature structural biology”.

12. The serials binding process 12 Our Example (slide 2 of 4) It is linked to Holding Record 50238 contains 852 field in the CAMPD (Downtown campus) sublibrary. contains a monthly prediction pattern

13. The serials binding process 13 Our Example (slide 3 of 4) The serial subscription is connected to the Holding record

14. The serials binding process 14 Our Example (slide 4 of 4) And in tab 3 we can see the “discard/binding” pull down box

15. The serials binding process 15 tab_binding and pc_tab_exp_field.eng (1 of 9) Each of the options in the the “discard/binding” pull down box comes from the pc_tab_exp_field.eng of the ADM library (Internal command BIND-DISCARD-TYPE ) The numerical value in the last column corresponds to tab_binding in the ADM library.

16. The serials binding process 16 tab_binding and pc_tab_exp_field.eng (2 of 9) tab_binding in the ADM library.

17. The serials binding process 17 tab_binding and pc_tab_exp_field.eng (3 of 9)

18. The serials binding process 18 tab_binding and pc_tab_exp_field.eng (4 of 9) We will now describe the columns of tab_binding Col. 1 Binding rules identifier. This is the number which is entered in the Binding/Discard field of the Subscription form, it corresponds to the text added in pc_tab_exp_field.eng Col. 2 Grouping argument. This parameter defines the method used for determining "number of issues" considered to make up a volume. Presently this column can contain only: 01

19. The serials binding process 19 tab_binding and pc_tab_exp_field.eng (5 of 9) Col. 3 No. of issues that constitute a volume for binding. This is the number of issues received in the group (since the last bound volume) - i.e., the nth issue in a volume. 999 denotes last issue of a volume. Example: if a volume is complete in 12 issues, but is bound in 2 volumes, this can be set to "6"; if a volume is complete in 4 issues, which are bound in a single volume, this can be set to 999. Col. 4 Delay. This is the number of days to elapse after arrival of last issue of a "volume" for binding alert. Example: 365 denotes that the issues should be sent to binding one year after the last issue has been received.

20. The serials binding process 20 tab_binding and pc_tab_exp_field.eng (6 of 9) Col. 5 EDA Delay. This is the number of days which elapse after Expected Arrival Date of last issue of a "volume ”. Example: If this is set to "60", the group is considered complete, even though the last issue has not arrived when 60 days have elapsed since its expected arrival date. Col. 6 Priority. This is used to describe binding priority. E.g high, secondary, low. Note: the text placed in this column must be exactly the same as the text set in the menu BINDING-PRIORITY, column 4 of the table pc_tab_exp_field.eng

21. The serials binding process 21 tab_binding and pc_tab_exp_field.eng (7 of 9) Col. 7 Type. This is used to describe the standard of binding e.g.: high, average, basic. Note: the text placed in this column must be exactly the same as the text set in the menu BINDING-TYPE, column 4 of the table pc_tab_exp_field.eng Col. 8. Binder. If the library might open Z70 Vendor records and/or Z303 Patron records for Binders, in which case this parameter will be the relevant code/ID.;

22. The serials binding process 22 tab_binding and pc_tab_exp_field.eng (8 of 9) We will now add the following line to tab_binding: !1 2 3 4 5 6 7 8 !!-!!-!!!-!!!!-!!!!-!!!!!!!!!!-!!!!!!!!!!-!!!!!!!!!!!!!!!!!!!! 09 01 006 0003 0060 high basic SMITH_BINDERS Thus the “binding rules identifier” is 09. Every 6 issues will be bound. Three days after the last issue of the volume to be bound is received the library will be alerted. Binder with code SMITH_BINDERS will be used. Col. 5 is 60, thus the group will be considered complete even if the last issue has not arrived and 60 days have elapsed since its expected arrival date BIND-DISCARD-TYPE L Smith binders, type 09 09 Here is the new corresponding line in pc_tab_exp_field.eng

23. The serials binding process 23 tab_binding and pc_tab_exp_field.eng (9 of 9) Thus now we have a monthly journal in which each six issues constitute a volume for binding The journal has 12 issues per volume The “binding” volume has 6 issues per volume In this case the binding identifier is 09 and the binder is SMITH_BINDERS Note: The next five slides will briefly stray from the subject at hand to discuss circulation matters regarding the binder

24. The serials binding process 24 Binder as Patron and Vendor (1 of 5) Code SMITH_BINDERS is registered for Smith Binders as a global patron record. It is also recommended to create a Vendor Code SMITH_BINDERS. Thus the binder is registered as a vendor.

25. The serials binding process 25 Binder as Patron and Vendor (2 of 5) Code SMITH_BINDERS is registered for Smith Binders as a vendor.

26. The serials binding process 26 Binder as Patron and Vendor (3 of 5) Note: This “patron” (binder) will eventually make a hold request and loan the items (issues to be bound). Thus proper circulation setup should be made for a specific patron status which is “binder” This should be done in: pc_tab_exp_field.eng or pc_tab_tab_exp_field_extended.eng tab16 tab31 tab37

27. The serials binding process 27 Binder as Patron and Vendor (4 of 5) Here patron status 64 is defined as a binder, and he can loan any item of any status or process status for 21 days

28. The serials binding process 28 Binder as Patron and Vendor (4 of 5) The binder (patron) can then be given a local patron record as binder

29. The serials binding process 29 Choosing the new binding setup Now our new binding definition (which we defined in tab_binding and pc_tab_exp_field.eng) may be chosen in tab 3 of the subscription

30. The serials binding process 30 Issues of at least one binding volume have arrived The first 13 items have arrived:

31. The serials binding process 31 update Z30 set Z30_ARRIVAL_DATE = '20060101' where Z30_BARCODE = '50861-10'; update Z30 set Z30_ARRIVAL_DATE = '20060201' where Z30_BARCODE = '50861-20'; update Z30 set Z30_ARRIVAL_DATE = '20060301' where Z30_BARCODE = '50861-30'; update Z30 set Z30_ARRIVAL_DATE = '20060401' where Z30_BARCODE = '50861-40'; update Z30 set Z30_ARRIVAL_DATE = '20060501' where Z30_BARCODE = '50861-50'; update Z30 set Z30_ARRIVAL_DATE = '20060601' where Z30_BARCODE = '50861-60'; update Z30 set Z30_ARRIVAL_DATE = '20060701' where Z30_BARCODE = '50861-70'; update Z30 set Z30_ARRIVAL_DATE = '20060801' where Z30_BARCODE = '50861-80'; update Z30 set Z30_ARRIVAL_DATE = '20060901' where Z30_BARCODE = '50861-90'; update Z30 set Z30_ARRIVAL_DATE = '20061001' where Z30_BARCODE = '50861-100'; update Z30 set Z30_ARRIVAL_DATE = '20061101' where Z30_BARCODE = '50861-110'; update Z30 set Z30_ARRIVAL_DATE = '20061201' where Z30_BARCODE = '50861-120'; update Z30 set Z30_ARRIVAL_DATE = '20070101' where Z30_BARCODE = '50861-130'; commit; Note: when testing, demonstrating or presenting this subject the arrival dates may be manipulated in SQL as follows Manipulation of arrival dates for testing procedure Issues of at least one binding volume have arrived

32. The serials binding process 32 Bind Alert Report (bind-01) We will now run “bind alert report” (bind-01). Here is what it will do: Generate a report that alerts staff to journal volumes and their issues which are ready for binding. Identify the titles and volumes that, according to parameters set by the library, are ready for binding or discarding (according to the setup in tab_binding and policy chosen in subscription) Prepare a printed report of issues ready for binding, and an output file to be used as input for the Serial Binding Slip (bind-02) service.

33. The serials binding process 33 Bind Alert Report (bind-01) We have 13 items which have arrived. They have arrival dates 20060101, 20060201, 20060301, 20060401, 20060501, 20060601, 20060701, 20060801, 20060901, 20061001, 20061101, 20061201, 20070101 We stated that we should bind them three days after the last one of the “volume” has arrived. We also stated that every six issues will be bound. !1 2 3 4 5 6 7 8 !!-!!-!!!-!!!!-!!!!-!!!!!!!!!!-!!!!!!!!!!-!!!!!!!!!!!!!!!!!!!! 09 01 006 0003 0060 high basic SMITH_BINDERS

34. The serials binding process 34 Bind Alert Report (bind-01) Thus, we should get a report for the first 12 of the 13 items. The report should tell us that the first 12 items should be bound in two “binding volumes” of 6 items each. The thirteenth item arrived on 20070101. This is more than three days ago, but it is only one of a six issue unit which should be bound. Thus it should not be included in the report.

35. The serials binding process 35 Bind Alert Report (bind-01) bind-01 and bind-02 are accessed from within the Acquisitions/Serials Module

36. The serials binding process 36 Bind Alert Report (bind-01) Report will be called “ bind-01-report ” Output file will be called “ bind-01-output ” We run for all sub libraries Item process statuses will be changed to “ At Bindery ” (BD) We will run with option to update the database

37. The serials binding process 37 Bind Alert Report (bind-01) The report appears in the task manager:

38. The serials binding process 38 Bind Alert Report (bind-01) The report includes the first 12 issues in two groups of 6 each continuation

39. The serials binding process 39 Bind Alert Report (bind-01) And if we look at the items which are in the report: We see that the process status has changed for the first twelve issues

40. The serials binding process 40 Bind Alert Report (bind-01) Additionally, an output file has been created in the $data_scratch directory of the ADM library: il-aleph02-18(1) USM50-YOELK>>ls -lrt bind-01-output -rw-rw-r-- 1 aleph exlibris 1644 Apr 16 12:37 bind-01-output This is the output file name which we designated when running the service “ bind-01 ”.

41. The serials binding process 41 Bind Alert Report (bind-02) We will now use the output file of bind-01 as an input file in service “ Serial Binding Slip (bind-02.) ” Bind-02 service produces a printed report, pickup slips, and hold requests (optional), for volumes and issues that are considered ready for binding Hold requests on each issue may be created thus preventing the issues from being loaned before being sent to binder The creation of hold requests also allows the librarian to be able to view all issues which are ready to be sent to binder (by viewing hold requests of binder-patron)

42. The serials binding process 42 Bind Alert Report (bind-02) Part one of the service Input file is output file from bind-01 We will print a report and slips Report file name Slips file name All sub libraries

43. The serials binding process 43 Bind Alert Report (bind-02) Part two of the service All binding priorities All binding types Binder code SMITH_BINDERS Create hold requests for patron SMITH_BINDERS

44. The serials binding process 44 Bind Alert Report (bind-02) Note: When clicking the three dots next to “ Hold Request ID ” the system brings the list of patrons which have a local z305 record. When clicking the three dots next to “ Binder Code ” the system brings the list of vendors (Z70).

45. The serials binding process 45 Bind Alert Report (bind-02) Hold requests have been created in the patron record. This is in order to prevent the items from being loaned until they are sent to binder. They may be loaned to the “ patron ” (which is really the binder) when they are sent to the binder. This way the library (and end user) knows where they are. These 12 hold requests are the 12 issues which must be sent to the binder. The hold requests were created automatically when bind-02 was run

46. The serials binding process 46 Bind Alert Report (bind-02) Issues “ On Hold ” for the binder.

47. The serials binding process 47 Bind Alert Report (bind-02) The report and the slips appear in the task manager

48. The serials binding process 48 Bind Alert Report (bind-02) Here is an example of a slip to be given to the binder with the issues he needs to bind:

49. The serials binding process 49 Bind Alert Report (bind-02) One slip is printed for each “ binding volume ”. In this case one serial volume has two “ binding volumes ”. Vol. 3 iss. 1-6 Vol. 3 iss. 7-12

50. The serials binding process 50 Preparing to send issues to the binder (1 of 2) At this stage the technical work of bind-01 and bind-02 has completed The physical issues must now be gathered by the library and sent to the binder The reports created by bind-01 and bind-02 may be used to help in the “gathering” process.

51. The serials binding process 51 Preparing to send issues to the binder (2 of 2) Issues are sent to the binder in one of two ways: 1.Set the item's process status to a status that reflects that it was sent to binding. 2.Loan the item to the binder with the due date for the loan set to the expected arrival date of the bound item back in the library.

52. The serials binding process 52 Sending the issues to the binder If the library uses option 1 (setting the item's process status to a status that reflects that it was sent to binding) then this has already been completed when service bind-01 was run. If the library uses option 2 (Loan the item to the binder) then this has already partially been done via bind-02, where a hold request was made for the binder. We will now do the rest of option 2 and loan the items to the binder. See link here for information pertaining to External Binding Software

53. The serials binding process 53 Sending the issues to the binder All issues which the binder should loan will be loaned to him Issues may be given to binder together with the slip produced in service bind-02 Loan is made in standard way via circulation module

54. The serials binding process 54 Sending the issues to the binder The issues are registered as “At Bindery” on loan to Smith Binders with due date

55. The serials binding process 55 Sending the issues to the binder Web OPAC end user also sees that items are at the bindery, and he sees when they are expected back This text may be changed for web OPAC via table tab_www_item_desc.eng

56. The serials binding process 56 Returning the issues from the binder When the items are returned from binder they may be returned via the circulation module. 12 issues were sent out, and now 2 volumes of 6 issues each are returned. All 12 issues should be registered as returned in ALEPH.

57. The serials binding process 57 Registering the bound volumes When the items have been returned they may be registered as bound. This may be done via the items list “bind/changes” button in either the cataloging or Acquisitions/Serials module.

58. The serials binding process 58 Registering the bound volumes We will select the first six items in left pane and via the arrow move them to the right pane. We are selecting the first six items because this is the first bound volume

59. The serials binding process 59 Registering the bound volumes When items have arrived to right pane we click “Bind”

60. The serials binding process 60 Registering the bound volumes The “item expand” form for the new bound item will open

61. The serials binding process 61 Registering the bound volumes after Update is clicked on the modified Item Form, the following changes occur: A new value, ISSBD, is entered into the Material Type field A new value, BD, is entered into the Item Process Status field. ISSBD is a special material type automatically assigned by the system to bound volume items, allowing them to be sorted as serial issue items.

62. The serials binding process 62 Registering the bound volumes BD is automatically allocated to bound volume items to indicate to the OPAC users that those items are in binding. However, it is possible for the system librarian to allocate another Item Process Status and accompanying text in a table. Example: In our case the process status remained BD after binding. If we had this line in tab42 then it would have automatically changed to VO: Instead of: ITEM ##### BD BD ## Put: ITEM ##### BD VO ##

63. The serials binding process 63 Registering the bound volumes The new “bound issue” The description will by default be the description of the first item which is bound, it may be manually changed as was done here. Here BD was changed to VO (Volume)

64. The serials binding process 64 Registering the bound volumes Here are the two new “bound issues” All single issues are saved in the history

65. The serials binding process 65 Registering the bound volumes Note: The items which comprise a newly-bound volume item are automatically discarded in the process, but they are still kept in the system as historical records. By viewing the loans and Hold requests tab of the item history it is possible to know when the item was sent to binder and returned.

66. The serials binding process 66 Registering the bound volumes

67. The serials binding process 67 Registering the bound volumes Here are the new bound issues in the web

68. The serials binding process 68 Completed Volumes Report APPENDIX There is an additional way to make a completed volumes report From the items list in the cataloging module it is possible to click the “Completed Vols” button

69. The serials binding process 69 Completed Volumes Report Via this button you can view or print a report for a given title, listing volumes which have all their issues checked in but have not yet undergone the binding process. This can be useful for the binding preparation process. This report can include volumes with issues that have not arrived, according to a parameter set up by the System Librarian. That parameter defines a maximum number of days for issues to arrive following their Expected Date of Arrival (EDA), after which the volume containing them is considered complete despite their unavailability in the library, and appears in the report.

70. The serials binding process 70 Completed Volumes Report The parameter in $alephe_root/pc_server_defaults serial_bind_period defines “The maximum number of days for serial issues to arrive after the Expected Arrival Date, after which a volume containing them will be considered complete to appear in the Completed Volume Report” setenv serial_bind_period 10 For example …

71. The serials binding process 71 Completed Volumes Report Vol. 7 has 12 issues The first 11 issues have arrived The twelfth issue has issue date April 1 2007 Today is April 18 2007 Issue date is 17 days ago If serial_bind_period is 18 then Vol. 7 will not appear in the report If serial_bind_period is 16 then Vol. 7 will appear in the report

72. The serials binding process 72 Completed Volumes Report