Hello Irene,
That sounds like a very interesting project. To your point, I assume that
you scan the boxes before you send them offsite, yes? Perhaps you could link
the scanned output data to your access database (not sure how feasible this
is). It seems like you have a lot of fields in your database, you may want
to consider condensing that a bit. Here are my thoughts on each of your
questions:
To Question 1- whatever you do here, be consistent. If you delete, then
delete in the access database and in your records database. If you keep the
record, then keep it across all databases. Consistency is the key here.
To Question 2- A permanently released file should be deleted from your
database. If you need to have a final tally of boxes at the end of the year
it will make things much more complicated to have permanently released
barcodes mixed into your database of active boxes.
To Question 3- whatever you do it should be consistent. If you change the
box number then you MUST update the database to reflect that. There is no
reason to keep the old barcode. In fact, it would be advisable to notify
your offsite shipping vendor to immediately delete
To question 4- implement a consistent and thorough refile approach in which
you track files that have been removed from boxes.
I hope I have answered some of your questions here. Please inform us of the
outcome. Good luck to you!
Best,
Alexander L. Campbell
Records Clerk I
Latham & Watkins
New York, NY 10022
*Disclaimer: the views set forth do not necessarily represent that of my
employer.*
**
On Fri, Oct 8, 2010 at 11:56 AM, Irene Eklund <[log in to unmask]>wrote:
> Hello Everyone,
>
> I am working on a project in order to standardize the way information is
> entered into our storage database. This database is run through
> Microsoft Access and allows us to track the files we have sent off site
> to our off site storage company.
>
> Information which we can currently enter and track in our database is as
> follows - (1) File Number, (2) Storage box number, (3) Department, (4)
> Storage Date, (5) Destruction Date (we enter a standard 10 years from
> the storage date for this), (6) Closed Date (date the file closed out),
> (7) Attorney, (8) Client, (9) Claimant, (10) Box Contents, (11) Notes,
> (12) Recall Date, (13) Recall Return Date, and (14) Recall Requested by.
>
>
> There has been some debate among the Records staff members on the best
> way to standardize certain entries into the storage database. In
> particular, I am looking for feedback on ways that you would "best
> recommend" standardizing entries for the following situations -
>
> 1) How do you handle an entry when you recall a file from storage that
> is being reopened? Do you delete the record? Do you leave the
> record? Do you override the box field and enter in the word "remove"?
>
> 2) How do you handle an entry for files/boxes that have been permanently
> removed from storage?
>
> 3) A file is recalled from storage that is not being reopened but the
> box has been returned to storage? How do you handle updating the
> database? Do you override the existing entry and completely change the
> box number? Do you make a whole new entry? If you make a whole new
> entry, what do you do with the existing entry in the database? How do
> you avoid having duplicate entries
>
> 4) How do you generally ensure that your records are kept up to date
> when files are removed from boxes?
>
> Thank you for all your helpful information and feedback
>
> Irene Eklund
> Records Specialist
> Donovan Hatem LLP
> Boston, MA
>
>
>
> Irene Eklund
> Donovan Hatem LLP
> Seaport East
> Two Seaport Lane
> Boston, MA 02210
>
> 617.406.4607 (direct)
> 617.406.4501 (fax)
> mailto:[log in to unmask]
> --------------------------------------------------------------------------
> Confidentiality Notice: This message is intended only for the designated
> recipient(s). It may contain confidential or proprietary information and may
> be subject to the attorney-client privilege or other confidentiality
> protections. If you are not a designated recipient, you may not review, copy
> or distribute this message. If you receive this in error, please notify the
> sender by reply e-mail and delete this message. Thank you.
> --------------------------------------------------------------------------
>
> List archives at http://lists.ufl.edu/archives/recmgmt-l.html
> Contact [log in to unmask] for assistance
> To unsubscribe from this list, click the below link. If not already
> present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the
> message.
> mailto:[log in to unmask]
>
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]
|
