Tracking Journal Issues in a Library App: Was the Issue Never Published, Never Received or Lost Later?

A paid journal subscription does not tell a library which individual issues it actually holds. If you commission a periodicals workflow, separate the publication's numbering and expected issues from recorded receipt and later availability. A gap may mean an issue never existed, a delivery is overdue or a previously received copy has gone missing. Those require different follow-up.

This is useful for a specialist library, an association reading room or an organisation maintaining a physical reference collection. It concerns individual issues within a continuing publication, not customer subscription billing or the general scheduling of recurring tasks.

Describe an issue before predicting its arrival

Ask the collection owner to bring examples of the publication's actual numbering, including a year boundary and any known exceptions. A volume number, issue number and printed date are not interchangeable. The application should let staff recognise the publication's label without inventing a fresh issue merely because the calendar advanced.

Koha's official serials manual illustrates this separation. Subscription setup includes frequency and a numbering pattern. Its prediction test shows the issues that the pattern will generate and allows selection of issues that do not exist. The manual also distinguishes keeping or skipping the issue number when handling an irregularity.

For a custom app, request a reviewed preview before generating the working list. A hypothetical journal might omit one publication slot while continuing its issue numbers sequentially. Staff should agree what the next actual label will be rather than deleting an apparently missing issue and hoping the numbering repairs itself.

Record the publisher information behind a correction. A pattern is a planning aid, not evidence that a particular issue was published or delivered.

Keep receipt separate from the prediction

The useful working question is “which exact issue arrived?” rather than “did anything arrive for this subscription?” Match the physical issue to its title, enumeration and date before confirming receipt. Preserve a separate receipt date if the organisation needs it.

Koha uses Expected for a newly created issue that has not arrived and is not yet late, and Arrived for an issue received by the library. Its receiving workflow can also create an item record when configured to do so. These are product-specific examples, not a promise that every catalogue automatically tracks individual copies.

Decide whether your app needs an issue record alone or separate copy records as well. Two copies of the same issue are not two successive issues. If copies are lent, moved or separately labelled, agree how staff find the relevant copy without changing the publication sequence.

Give each gap the right explanation

An overdue expected issue should enter a follow-up list. A publisher-confirmed non-issue should not remain a supplier delivery complaint. A copy lost after receipt should not be reported as never received.

Koha's documented states make this distinction concrete: Missing has more specific variants including never received, sold out, damaged and lost. Claimed means the issue has not arrived but a claim has been sent to the vendor. The manual describes selecting late issues and a notice template before sending a claim.

For your requirements, make the explanation and next action visible. Store which issue the enquiry concerns, who contacted the supplier and what reply was received. An outgoing claim is not proof that a replacement will arrive. Keep follow-up communication separate from receipt confirmation.

Also define lateness deliberately. Koha documents a grace period and mechanisms for updating late states; do not assume a chosen date will create dependable follow-up without the required running process. Ask the developer to demonstrate your actual overdue-work behaviour.

Test exceptions, not just twelve ordinary receipts

Use fictional publications to demonstrate an omitted slot, an unusual numbering boundary, a late delivery, a claim and a later arrival. Add two copies of one issue and a copy lost after receipt. Check that the holdings view tells a reader what is actually available without presenting predictions as possessions.

For each case, staff should be able to explain the issue identity, evidence, current state and next action. A numbering correction should not erase a genuine historical receipt or silently close an unrelated claim.

Bring these examples to a library workflow app discussion. Before commissioning custom software, compare them with an established library system. The deliverable is an understandable issue-level record, not a bespoke subscription screen for its own sake.

Primary source and boundary

Koha Manual: Serials, especially Adding a subscription, Receiving issues, Claiming late issues and Serial statuses. The manual supports the described Koha prediction, receipt and status behaviour. Evidence retention, copy relationships, reader-facing wording and acceptance tests above are proposed project requirements, not independently tested Koha capabilities.