Hi all —

Apologizes for the wall of text but I would deeply appreciate any guidance or feedback from the TMS community on some issues relating to crate management. I didn’t find any previous post on the list-serv archive about these particular issues so I apologizes if this is already well-trodden ground.

The Gallery has begun to review data about our crates and as well as how we manage that data in the future. During this process we have discovered a few things and wanted to bring them to the attention of the community and see if anyone else has encountered these problems.

The first issue (which is more a cautionary tale than an actual problem) is that CrateNumber alone is not required to be unique because it also relies on auxiliary fields Project and Type to enforce uniqueness. While there are probably valid use cases for this implementation it does cause some overall issues. At the Gallery we had assumed (for many years) that CrateNumber alone is unique for all crates and had an issue where duplicate crate records were created because the Type and Project were different. Thus for our implementation we had the same “crate” in two different locations. Fortunately, once we identified the problem the data cleanup was pretty straightforward but it did require us to add the CrateID (not CrateNumber) field in the Advanced Query window so they could move items from one specific crate record into the correct crate record. It also requires that we mark the duplicate crate as ‘Inactive’ which itself is problematic (see issue #2).

This problem of duplicate crates was partially obscured because the Container Number pick-list in the Move Assistant groups by Container Number, only showing one entry when multiple containers with the same Crate Number exist. If you do have multiple crates with the same crate number it will pick the first crate record not alerting you that multiple crates do exist. If you click on the ellipsis and use the search function then all create records will show. Using the ellipsis and search it probably the safest way to link a crate however, most users use the pick-list because it is much faster. This may be a training issue but this is also very confusing from an end user perspective.

The second issue deals with the Active/Inactive property of crate records. Does anyone utilize this property to manage their crate inventory? We have found that although it presents itself as comparable to the Active/Inactive property of a TMS Location record it does not function in the same way. Setting a crate as “inactive” does not prevent its continued use and does not throw an error when marking a crate as inactive when there are objects currently in that crate. We have tested (and confirmed) that users are able to relocated an object using the Barcode manager into a crate which is marked as inactive in TMS and that users can mark a crate as inactive which currently contains objects. If either of the operations were attempted with a Location record they would be prevented with an error message.

I will note that marking a crate as inactive will drop it off the Container Number pick-list in the Move Assistant window.

All of these issues are compounded by the documentation which says that:

The Active checkbox in the Container/Crate Utility indicates whether or not the crate is currently in use. If a crate has been destroyed or discarded, you should uncheck this box (i.e., deactivate the crate), so that it will not be used for a move transaction.

Deleting a Container/Crate from the Crate Utility
You cannot delete a crate from the Container/Crate Utility, once it has been used to move an object to a location. Even if the object is no longer located in the crate, the object was on loan and has been returned, etc., because the crate is part of the object’s location history (which is permanently stored in the database), the crate cannot be deleted from the utility.

Suggesting that marking a container as inactive is the only way to prevent its continued use since deletion is not possible.

Our solution to these issues is to write nightly SQL alerts that will email the registrars when either:

1. There are duplicate active crates (using only CrateNumber for comparison)
2. There are inactive crates being used as a current location

This way they can stay ahead of the curve and deal with any problems before they cause too many issues. While neither of these solutions is ideal I believe it the best option for us at this point in time. Has anyone else experienced these issues? How are you managing crates in TMS? Have I missed something in either the documentation or implementation of Crates that would account for this (apparently) inconsistent behavior?

We are still using TMS2010 R2 but based on conversations with GS staff I assume that these issues impact all TMS versions.


Many thanks,
Scott



To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

     signoff TMSUSERS

     //  eoj


You will receive a confirmation that your subscription has been removed.