Updating expected dates ensures that serials continue to be received by the university in a timely manner, and if they are not, we can claim them.
For some serials, the updating process is a simple operation. But for others (extrapolated cards) extra steps must be taken. Extrapolation is a tool used to create check-in cards for serials that have unusual publication details, by mimicking a previous pattern. Because of their complexity, extrapolated check-in cards require extra steps to ensure that the expected dates update correctly.
Here’s how to tell which mode of updating you’ll need….
A serial can be updated normally if it meets the following conditions:
A serial needs to be updated differently if it meets the following conditions:
1.The system assumes that the winter issue of a seasonal quarterly goes to the old year, and updates accordingly. If a publisher gives its winter issue the new year, you must extrapolate (or leave the cover dates blank and manually input them) to ensure that future winter issues will be checked in correctly.
2.When the cover date is the year only, the system often misses a cover date change during update, as it does with continuous issues missing a volume change. Extrapolating, or updating in whole volumes only, is recommended.
Considering the points above will help you determine which type of updating you will need. Most extrapolated cards contain record notes alerting you that cards are added using extrapolation (more examples of such notes can be found here). When you see such a note, you must follow the updating expected dates on extrapolated cards procedure described in the next section.
Keep in mind that you do not need to update expected dates after checking in every issue. You should, however, routinely check the future expected boxes in the card to make sure that the expected dates fall within a reasonable time frame for when we can expect each issue to arrive. When reviewing future issue boxes (yellow) to check this, it is good to compare them with boxes for recently arrived issues (green), within the past year or volume or so. This will help you predict the publisher's current shipping schedule, and ensure that the expected dates are in range of the shipping schedule. If you see that the shipping schedule indicated by recently arrived issues is out of sync with the expected dates of future issues, then you would want to use the "update expected dates" feature (more on that in the next box) to adjust the future expected dates to conform with the recent arrived dates, which give an idea when future issues will most likely be shipped.
For example, consider the following row of check-in cards, especially taking note of the arrival and expected dates:
These dates are good. For example, v.72:2 arrived in late October 2019, so the expected date of early November 2020 for v.73:2 is appropriate. Also, the transaction dates for v.72:3 and v.73:3 are very close, within the same week. Therefore, it is not necessary to update the expected dates for this card unless the publisher or vendor gives us specific information as to when we should expect future issues.
If the expected dates were significantly off from the arrived dates, we would want to update them. For instance, if v.72:3 arrived in February 2020 but v.72:4 had an expected date of March 2020, v.73:1 had June 2020, etc., we should probably update the expected dates for all future boxes so that they follow a schedule closer to the one shown above, to prevent the next expected issue from coming up for claims too soon.
Updating this journal was successful. Autumn 2014 arrived in December and it's a quarterly, therefore we can expect the next issue in March 2015, then another in June 2015, and so on.
To update expected dates on extrapolated check-in cards you follow the same general procedure as normal check-in cards, but exactly how you update the card will vary from journal to journal. Because you are working with complex publication schedules with more variations, you must be cautious to ensure that the card reflects the correct expected dates.
Always begin by examining the record notes of the extrapolated card. The notes should alert you that the card is extrapolated, and in some cases, provide further instructions. Extrapolated notes should appear at or near the top of the check-in record notes and be set off by five asterisks to indicate their importance.
In this case, due to the journal's unique publication schedule and mix of formats, a decision was made to set the expected dates in one way for print issues and another way for online issues during card creation, and to not change those dates at any time.
In some cases, there will also be a message note added to alert you to not update expected dates when you open the check-in card:
Similarly, when you see notes like this one it is important to NOT UPDATE expected dates, and to leave them set per the instructions (unless new information is received from the vendor or publisher):
When deciding how to update an extrapolated card, you should look for some signs, most commonly:
Note this publication:
Because Jul/Aug and Dec/Jan are combined issues, the card is extrapolated and must be updated accordingly. For example, if you were checking in the February issue, you would ONLY update expected dates from February through July/Aug. You do not want to update across the double issue into the rest of the card.
Let's say you wanted to update the next few expected dates for the sample journal below, which is monthly through June, then switches to bimonthly. After checking in the newest issue, highlight the newly arrived issue box and the number of boxes that you want to update. For this journal, the default frequency in Sierra was set to monthly, since the majority of issues are monthly. As a result, when you update expected dates, any updated dates will follow monthly increments. Therefore, unlike a normal check-in card, you can't simply highlight all the boxes, since updating all of the boxes at once will result in incorrect expected dates for the bimonthly issues.
For example, if you wanted to update from the March 2015 issue for more realistic expected dates, you would only want to do so through the June 2015 issue, since it switches to bimonthly issues for July through December, which are expected to begin arriving in late July and two months apart:
On this card, the final six months are published bi-monthly. The expected dates here should be left as is, because if you were to update from June to December, you would end up with incorrect expected dates:
As you can see with the screenshot above, if you were to update from June 2015 through the end of the card at Nov/Dec 2016, it would throw many of the expected dates off. For instance, it would say that January 2016 is expected to arrive in October 2015, which isn't very likely. Therefore, with this card, you can only update boxes as a group from January-June. For the July/Aug, Sept/Oct, and Nov/Dec issues, you would need to update those expected dates manually as needed.
Keep in mind, that if you do update the expected dates and see an error, you can undo your mistake by right clicking on the card and hitting undo (ctrl+z). In some cases, trial and error may be necessary.
Note: On cards that have been extrapolated because Winter is received with the new year, updating expected dates can follow the normal procedure since the issues are still published in regular intervals.