At the moment, there is a VERY simple system which allow people to create an item as soon as they receive a new issue. It is then stored into the database along with bibliorecords.

But it lacks :

• a real link between serial table and items.
• The possibility to receive multiple items at one time.
• a clear and simple way to modify a serial after reception is a real mess since one should modify both items and serial.
• A clear and simple interface to enter serials items.

What I suggest is to use serials-receive only for issues not yet received. When saving changes to a not yet received serial status, one would be prompted to a page where new items would be prepared for input. Saving that page would check for existing barcodes in database, enter validated items to the biblio. If an item is not validated then would report the problem.

To modify existing serial, we would then use full history collection displayed by year of arrival or publication year or even by status. Clicking on anexisting serial would lead to a page where the information would be in one block with serial information (publisheddate, serialseq, maybe branch, itemcallnumber and some repeated information from subscription) and items one would be displayed and editable in a table.

What I propose would require

• a new TEXT field called itemnumbers in serial table that would store itemnumbers separated by commas or one space
• a new INTEGER field called itemcount in subscription table that would store the count of items expected at once
• some new links to field in items in biblio framework namely
  • serial.serialid (in a $8 subfield for instance)
  • serial.serialseq (same as item.itemnotes, always ?)
  • serial.publisheddate (taht would be a brand new field)

Maybe it could be good to use MARC (eg :UNIMARC fields 310, 316, 317, 318 may be candidates) fields to store statecollection rather than using a new table. Thus it would be displayed easily and could be checked when deleting an item. Bute then we should report the changes.

Another improvement would be to create a new biblio for each issues and then create items and automatically link the issue biblio with the serial biblio. This would be possible if we had a kind of bibliographic “level” in itemtypes. That type on information would allow to chose a father or son itemtype. Then we would be able to display root level then firstchild and second child. And some information in the son's biblios would be derived from the father…. But I lack some sleep.