Item Process Statuses in Aleph

For Item Process Statuses, the GUI and Web descriptions do not have to be the same. The GUI descriptions and codes can be found in Aleph in tab15.eng; the Web descriptions can be found in pc_tab_exp_field.eng. The GUI description in pc_tab_exp... has a hard limit of 50 characters. Depending where it's used and how much we can see on the screen without lines wrapping, or if the lines even wrap at all, we may want to impose our own shorter limit sometimes.

Code

Web Description (15 char limit)

GUI Description (50 char limit) Notes
Count: 1/9/02; 2/15/02
AP Pending Apprvl  

Migration: None

Current Use: Assigned automatically by YBP loader for approval books only. Used during the 2 week review period, and changed (automatically) when Acq staff process the order. If there's a budget problem, it will auto-change to OI when the order status changes to a budget related status. Otherwise, becomes OO when the order is RSV (Ready to Send to Vendor).

166;
132
BD At Bindery At Bindery

Migration:
Checkin Boxes: Was used to indicate journal issues at the bindery (was status 8), but not sure if any had this during migration.

Item Records: Was used to indicate pieces at the bindery.

Current Use:
1. Assigned manually by Local Processing (also by Circ in some libraries, and by Cataloging) when a monograph is sent for binding (piece is physically sent to Preservation Services, who decides whether to bind locally or send out to commercial binder).
2. Assigned automatically when Local Processing collapses item records for individual journal or serial issues sent for binding.

Note from CM: According to tab42, BD also prevents display in list of items. You may want to confirm this, and perhaps not use it except for collapsed journal issues.

1175;
1691
BO Back Ordered Back Ordered

Migration:
Checkin Boxes: Assigned manually by Local Processing when an individual piece normally received through the subscription or STO process didn't arrive, and the piece was back ordered through MonoAcq.

Item Records: CM says: I have no idea how many, but it was possible for items to migrate with this status.

Current Use:
Assigned manually by Local Processing for the same reasons noted in migration. For full details see back ordering procedure.

MonoAcq is NOT assigning this IPS in item records. The concept of something being "back ordered" is handled in the Order record itself. Back Issue orders are handled like and use same statuses as all other orders. If we get a BO report from a vendor, this is noted in Order Log.

SerAcq would assign this IPS in the item record if the situation arises. Generally, we are informed that a title hasn't yet been published more often than we are informed of titles being on back order.

348;
370
BR Billed for Repl Billed for Replacement

Migration: This circulation status was assigned in ADV to items that were more than 30 days past their due date. Many of these items will prove to be gone from our collection, but some will also be returned over time. It will take some time to clean these up because of the number of items with this IPS. Stacks will be checked and the IPS for unreturned items will be changed to the appropriate missing status.

Current Use: DO NOT USE

1517;
1498

We will keep these records, but will not be using this IPS any longer. 020214mf

CA Cancelled Cancelled Order

Migration: Doubtful anything migrated with this status, but unsure.

Current Use:
MonoAcq: CM
says: Assigned automatically if the order's status is changed to VC or LC (cancelled by vendor, or library, respectively.) Using this IPS suppresses the item from in the Web OPAC; we are not deleting the item records, though we may also suppress the bib record as appropriate.

SerAcq: Cancelled standing orders or subscription orders would be noted in the order record, and the item records only exist for the pieces that should come on the STO/subscription. This IPS doesn't really apply in the serials workflow.

390;
515
CL Claimed Claimed

Migration: From ADV checkin boxes. This means the piece was claimed to the vendor (something we have not yet received). Claiming for Monograph Acquisitions was done through Order records, so the IPS for items ordered through MonoAcq won't say CL.

Current Use: SerAcq and Local Processing are assigning this IPS manually at the moment for serials and journals claims; not sure exactly how it will function when we are using Aleph's claiming functionality in the SER module.
Claiming for Monograph Acquisitions will continue to happen in the ACQ module. Changing the order status to claimed does not automatically change the IPS to CL, and MonoAcq is not doing this manually.

1601;
1645
CR   Claimed Returned

listed as CR in Item Form, but there is no CM in item form Ask Michael Finigan (see above)

Current Use: system assigned

146;
145
CT In Cataloging In Cataloging

Migration:
For both Checkin Boxes and Item Records, this status was assigned to indicate that the piece had been sent to Cataloging because there was some problem with it.

Current Use:
1. Assigned manually by Local Processing and/or Circ when Precats are sent back to Cataloging.
2. Assigned manually by Local Processing when pieces are sent to Cataloging to fix a problem.
Similar to, but not the same as, PR (Local Processing)

460;
483
DW Dmaged-Withdrwn Dmaged-Withdrwn

Created 030429, to deal with items damaged in a flood at Rotch.

Items with this status will display in the OPAC.

 
IC Missing Improper Charge Created 040916, to be used by circulation staff when a user claims they never checked out a particular item.  
ID Item Due Item Due

Migration: From ADV checkin boxes only. If you checked in no.3, for example, it automatically assigned a checkin status of Item Due to no.2 if you hadn't checked it in yet, assuming that you should get all pieces in sequential order.

Current Use: None. Aleph doesn't assign it; using the above example, no.2 keeps its Expected status when no.3 is checked it (it doesn't change to Item Due)

Stephanie will check with Processing to see if anyone still wants to use this; Kim's feeling is that we shouldn't use it. 020214

2788;
2649
IP Receiv/Not Aval Received/Not Yet Available

Migration:
Only valid for Item records in ADV, and migrated as such.

Current Use:
This status is pending discussion in Barton Advisory Group. But, it is assigned automatically during the Receiving process in the ACQ module. When a piece is received, the IPS changes automatically from OO (on Order) to IP. This status isn't used at all for pieces received (checked in, arrived) in the SER module.

The OPAC group will be discussing this IPS at its next meeting, early March 2002.

5891;
5426
MI Missing Missing from Collection

Christine says: This is, as far as I can tell, a "built in" IPS. It is one of 2 statuses (MI and MS) which can be used with the canned "Missing Report". Jennifer Banks (and others) are working on making a decision here. It's possible the system is auto-assigning this status at some stage. I've run the report, and there are a good number of items on it. [1/8/02]

Migration: No Items marked Missing in ADV were migrated to Aleph Barton.

Current Use: None. DO NOT USE (MF will communicate to Circ Staff not to use this status)

747;
769

MF will investigate who is using this status we want to have go away, 2/22/02

MM Miss Pr May2000 Marked Missing Prior to May 2000

CM and MF say: All the monthly missing statuses prior to May 2000 were combined into this one for migration of items. Should not be in current use, except to report on and process these items. [1/8/02]

1754;
1750
NA

[Not Arrived]

however, these records don't show in the Web OPAC at all

Expected / Not Yet Arrived

Migration: Nothing

Current Use: Assigned automatically to Publication Schedule Records (baby item records) about to become Item Records. It functions like Expected Issue functioned in ADVANCE. When the Item is "arrived," the IPS changes automatically to RD for Received.

5938;
6217
NB New Books Displ New Books Display

Migration:
Valid for Item Records only.

Current Use:
Assigned manually by Local Processing in SCI, HUM, and MUS. SCI and MUS don't circulate, but HUM does? Check on this...

191;
136
NR Never Received Missing

Created 10/17/2002

Current Use:
Assigned manually by checkin staff when a piece of a serial/journal order has not arrived and will not be claimed. Used to indicate that we never got a piece of a run, and we aren't going to pursue getting it. The best example of this is for something like People Magazine, where we keep only the latest year. If we miss a random issue, we aren't going to claim it. However, we want our piece level holdings to show that we *know* we missed the 10/17/02 issue, and we aren't going to get it.

Note: The Item Status for these items should remain whatever it would have been had the piece actually arrived. When/if you actually go to "withdraw" this piece, you should change the Item Status to 69 to suppress the record. The 67 status doesn't make sense, since you can't withdraw something you never actually had.

 
NT Not Yet Publsh Not Yet Published

Migration: From ADV checkin boxes. Usually assigned in response to a claim (i.e., we asked why we hadn't gotten the 2001 ed. and were told it hadn't been published yet; we assigned the IPS NT and generally wrote ourselves an Internal Note to say when it would be published. We adjusted the Expected Date accordingly.

Current Use: For Serials and Journals Items, will function as described above in Migration. For pieces ordered through MonoAcq, this concept would be expressed in the order record (specifically in the Order Log) and not in the Item Record as an IPS.

723;
699
NV Never Published Never Published

Migration: From ADV checkin boxes

Current Use: SerAcq or Local Processing will assign this status to make it clear that a given volume of a serial or journal wasn't published (though it may look like it should have been). For example, there might be an Item Record for 1999 with an IPS of NV to indicate that 1999 was never published. A further explanatory note might be in the OPAC note.

MonoAcq wouldn't use this IPS to indicate a piece was never published. Instead, when notified of a never published piece (usually via a status report from a vendor), MonoAcq will cancel the order record itself (change the Order Status to VC for vendor cancelled), which automatically updates the IPS in the item to CA for cancelled. Items with an IPS of CA are suppressed from in the Web OPAC.

377;
375
OI Order Initiated Order Initiated

Migration: NA

Current Use: Assigned automatically when a Mono order is created but does not yet have the status of RSV (Ready to Send to Vendor). Once the order record status is changed to RSV, the Item Record IPS changes to OO for On Order. Since we do batch printing of orders, RSV happens for a few hours until the day's orders are printed. There has been discussion about whether or not having both IPS is necessary. Note this status is used for YBP's GOBI orders, but not approvals. See related IPS OO

422;
376
OO On Order On Order

Migration: Valid only for Item Records. Was used for migration, and yes a number of orders probably had this. This was the Advance item status for open orders.

Current Use: Once an order record status is RSV (Ready to Send to Vendor), the IPS changes to OO automatically. See related IPS OI

3518;
3470
OP Out of Print Out of Print

Migration: Only used in Checkin Boxes. Normally assigned in response to a claim when we couldn't get the issue.

Current Use: For Serials and Journals Items, will function as described above in Migration. For pieces ordered through MonoAcq, this concept would be expressed in the order record (specifically in the Order Log) and not in the Item Record as an IPS.

351;
346
OS On Search On Search

Migration: Items on search in ADV at the time of migration had this status. Searches were to have been done manually in the last two months of ADV so that nothing would migrate with this status, since the information about for whom the search was being conducted would not migrate, but there were probably some items that migrated with this status.

Current Use: This is assigned manually by circulation staff to items not checked out but not on their shelf location and not found after an initial search. This status needs to be manually deleted when item is found; if the item is not found after a month of searching, staff change the IPS to the appropriate Missing status.

324;
340

OT Other Other

Migration: From ADV checkin boxes. We assigned this as a checkin status in ADV when nothing else made sense, and then wrote an explanatory note to our patrons. Not many boxes had this status (maybe 20?)

Current Use: Should we not use this at all, since we can now define as many IPSs as we need (whereas in ADV we could only have 20 checkin statuses?)

163;
68

SH is working with Processing to clean these up so we can delete this status, 1/11/02

PR Local Process Local Processing

Migration: Checkin boxes just had 15 for In Cat. which migrated as CT. Item Records had PR and went over as PR.

Current Use: Stephanie says it's "hit or miss" if Local Processing uses this. The idea is that you give an IPS of PR when the piece will be sitting in the Local Processing Office because it has some problem to be fixed. Similar to, but not the same as, CT (In Cataloging).
603;
637
RD Received Received

Migration: Boxes with checkin status 1 (Received), 13 (Microfiche), 14 (Microfilm) have this IPS. Item Records didn't have this status in ADV.

Current Use: As items are "arrived" in the SER module (both in SerAcq and in LP), the IPS of RD is automatically assigned. In this way, current journal issues show in the OPAC as "Received" instead of "Journal Loan." For serials, LP is changing both the IS and the IPS to the appropriate codes (IPS to blank and IS to whatever makes sense).

197223;
197608
SF

Missing

[changed label to Missing, 2/14/02. It used to say Review Reorder to the public]

Review for Reorder

Migration: Only valid for Item Records (not boxes).

Current Use: given to an item that is awaiting a reorder decision by a local selector in the case of the item being missing or damaged.

Note: Stephanie checked with Local Processing in Winter/Spring 2002 and people are still using this and want to continue using it.

232;
230

     
ZA Missing

Marked Missing Fall 2003

This was "Marked Missing May 2000" and was changed 031001; items that were marked ZA were recoded as ZD (see below)
24;
29
ZB Missing

Marked Missing Winter 2004

This was "Marked Missing June 2000" and was changed 031001; items that were marked ZB were recoded as ZD (see below)
49;
52
ZC Missing

Marked Missing Spring 2004

This was "Marked Missing July 2000" and was changed 031001; items that were marked ZC were recoded as ZD (see below)
54;
56
ZD Missing

Marked Missing Summer 2000

This was "Marked Missing August 2000" and was changed 031001 to combine everything marked missing from May - August 2000.
80, as of 031001
ZE Missing Marked Missing September 2000  
47;
47
ZF Missing Marked Missing October 2000  
62;
61
ZG Missing Marked Missing November 2000  
25;
27
ZH Missing Marked Missing December 2000  
24;
25
ZI Missing Marked Missing January 2001  
42;
39
ZJ Missing Marked Missing February 2001  
17;
18
ZK Missing Marked Missing March 2001  
74;
66
ZL Missing Marked Missing April 2001  
38;
33
ZM Missing Marked Missing May 2001  
66;
61
ZN Missing Marked Missing June 2001  
705;
706
ZO Missing Marked Missing July 2001  
0;
5
ZP Missing Marked Missing August 2001  
0;
1
ZQ Missing Marked Missing September 2001  
1;
3
ZR Missing Marked Missing October 2001  
28;
34
ZS Missing Marked Missing November 2001  
21;
29
ZT Missing Marked Missing Winter 2002 (previously: Marked Missing December 2001) per Michael Finigan, 2/4/02: The status ZT, which had previously been coded "Marked Missing December 2001", has been recoded "Marked Missing Winter 2002". Staff who mark items missing should continue to use the ZT code through the end of March, 2002.
21;
75
ZU Missing Marked Missing Spring 2002 per Michael Finigan 2/4/02: Covers items marked missing April-June 2002
1
ZV Missing Marked Missing Summer 2002 per Michael Finigan 2/4/02: Covers items marked missing July-September 2002 not yet in use
ZW Missing Marked Missing Fall 2002 per Michael Finigan 2/4/02: Covers items marked missing October-December 2002 not yet in use
ZX Missing Marked Missing Winter 2003 per Michael Finigan 2/4/02: Covers items marked missing January-March 2003 not yet in use
ZY Missing Marked Missing Spring 2003 per Michael Finigan 2/4/02: Covers items marked missing April-June 2003 not yet in use

ZZ

or

zz

    shows up periodically, but isn't a real processing status (you use ZZ elsewhere when you're trying to wipe out a processing status and make it blank, and sometimes people put it directly into the item record by mistake). Christine can run a report to change all these to blank
0;
55
i      

1;
1

BS will do cleanup, 1/11/02

os      

2;
3

BS will do cleanup, 1/11/02

xx      

2;
1

BS will do cleanup, 1/11/02

zt      
1
zz      
116
      actually blank
1466785
      two spaces
9000

IPSs that have gone by the wayside...

BN: Bound
Migration:
Check Boxes: If the checkin box had a status of Bound, we took the Received date and status instead, so nothing came over from checkin boxes as BN. Item Records: None migrated with this IPS.
Current Use: None. Binding is handled differently in Aleph. Therefore, BN as an IPS is officially retired 020214kam.

CM: Claimed Returned (use CR Claimed Returned instead)
in pc_tab but not tab15? Christine says: CM missing in tab15 is probably an oversight, but check with Michael, maybe it's now handled in another way. To add it to tab15, I'll need circ info for the other columns.
MF says: We may have to talk about this one in person or on the phone. I think this may be, as Christine calls it, a "built-in" ips in Aleph. However, it was also a circ status in Advance (none of which migrated, BTW. These were all changed to Missing April, May or June 2001 as part of a pre-migration cleanup). Clicking on the "claimed returned" button for an item in a user's record changes the ips to Claimed Returned. We just need to figure out whether that's a CM or a CR in Aleph. [1/9/02]
Current Use: None; use CR instead. Therefore, CM as an IPS officially retured 020214kam.

DS: Document Services
MF says: This is one of those ADVANCE circ statuses that for some reason got included in the Aleph IPS list even though the circ implementation team said it shouldn't be. Nothing migrated with this status (can't even remember now why it was set up, although I think this was the way DS first "checked out" items . Kill it, but gently. They're nice folks at DS. Officially retired 020214kam

HA: On Hold in Archives
Michael Finigan says: This was specially set up in Advance to tag any theses which Archives had recalled from the public for security or legal issues. We thought nothing migrated with this status, but 4 did. They have since been cleaned up, and we are dealing with this concept differently now in Aleph. Therefore, HA as an IPS is officially retired 020207kam.

IT: In Transit
This was an ADVANCE circulation status attached to items returned to a library other than the owning library; item remains in transit until checked in at owning library. Items with this status in Aleph were in this nether-world at the time of migration. Stacks were checked and this IPS removed for items found; the search process has begun for items not found. No items currently have this IPS, and it is officially retired. [020227kam]

LO: Declared Lost
ADVANCE circulation status assigned to an item when a user indicated it was lost and there was no way on earth it would ever be found.
This status distinguished these items from items that had simply not been returned by users. Not often used, and these were cleaned up by changing the IPS to the appropriate missing status for the month/year item was declared lost. No longer in use in Aleph, and officially retired. [020311kam, and retired again 020619]

LP: Lost and Paid
Michael Finigan says: Anything that had this status in Advance migrated with a billed for replacement status. As of July 1, 2001, there were 23 items with this status in Advance. As of January 9, 2002, there were only 6. They were cleaned up, and this IPS is now officially retired. [020207kam]

OH: On Hold
Anything that migrated with this status from ADVANCE is certainly off the hold shelf now and has a normal status. All items in Aleph with this IPS were cleaned up, and the IPS is now officially retired. [020227kam]

OL: Checked Out
Only one item record existed with this IPS on January 9, 2002, and it has been changed. Aleph deals with checked out items differently than ADVANCE, and this IPS is not necessary. Officially retired 020207kam. [Note: There are now 2 items with this IPS on 2/14/02; Michael is investigating.]

OR: On Route
MF says: I don't think any items in ADVANCE had this status, so nothing migrated. Not used in Aleph, where things are "in transit" between libraries. Christine says: It was possible for this to have migrated. Don't know what it means tho. However, in a check on 1/09/02, no records had this IPS. It isn't auto-assigned by Aleph, so we are officially retiring it 020214kam.

OV: Long Overdue
Items in ADV which were past their due date but had yet to be billed for replacement migrated with this circulation status. Not used in Aleph. All items cleaned up, and status retired 020628 per MF.

RE: Recalled
Items recalled from circulation in ADVANCE at the time of migration have this IPS in Aleph. Since Aleph has a different way of dealing with recalled items, these items were cleaned up in Aleph, and this IPS is now officially retired. [020227kam]

RR: RSC Repair
Was used by RSC in ADVANCE, not used in Aleph. All of these were changed, and the IPS officially retired 020221kam.

TR: In Transit
Items returned to a library other than the owning library in ADVANCE became "in transit" (IT). An item not checked in at the owning
library after ten days became in transit - long overdue. Items with this IPS migrated from ADV with this status. We cleaned these up in Aleph, and have retired this IPS. [020311kam] [removed from drop down menu 020628]


Created January 4, 2002. Last updated September 16, 2004 by Kim Maxwell, kmaxwell@mit.edu