This page is intended as a brief overview of serials planning code in Koha 3.x , aimed at developers.

Notes:

• Currently the planning code is reproduced in two places:
  1. perl code: calculating next chronology and next enumeration.
  2. javascript: creating the subscription definition requires very similar logic.
  • Discussions on irc & elsewhere indicate a goal of moving js logic to ajax calls.

• This table is a partial implementation of a proper link between serial records and item records.
• Earlier Koha implementation used serial.itemnumber as a varchar list of items.
• serialitems currently is constrained to 1-1, with the expectation that it will be expanded to allow 1-n (serial-item) in the future.

• Currently planning for a given serial issue is based on the current 'expected' issue (serial.status == 1 ).
• Creation of a new planned issue is triggered by the transition of an existing serial record from status == 1 to status == 2.
• Chronology is caluculated from the last entry in the serials table ( the one that just triggered the new issue, by changing status from 1 (expected) to 2 (arrived).
  • This means editing the publication date will affect future planned dates.
• Enumeration is calculated from the subscription table, and cannot be affected by editing serial records.

Here we create a third order enumeration subscription, shown in the screenshot

Note:  the screenshot shows an edit of the original subscription, which is reflected in the values of lastvalue1, etc. below.
A screenshot of the original subscription entry would have shown the first publication date ...  
Since it's an edit, we show the first issue publication date, and the next issue's planned date.
If this screenshot were from an _add_ operation instead of _edit_ on subscription_add, we would not see
this difference.

This results in the following subscription entry...
mysql> select periodicity P,numberingmethod , add1 ADD_X, every1 EA_X,whenmorethan1 ROLL_X, setto1 RST_X, add2 ADD_Y, every2 EA_Y, whenmorethan2 ROLL_Y , setto2 RST_Y ,add3 ADD_Z, every3 EA_Z , whenmorethan3 ROLL_Z, setto3 RST_Z

Here's what happens to the innerloops and lastvalues as we receive a year's worth of issues

And here's what the serials table looks like
mysql> select serialseq, planneddate, publisheddate from serial where subscriptionid=26;