INVENT User Manual

NOTE: Names of fields (e.g. Manufacturer) and values (e.g. Panasonic) are shown in different typefaces, as demonstrated here.

General Guidelines

These are not rules, just guidelines, but be sure you have a good reason for not following them. INVENT does not already adhere to all these guidelines, since it is very old and the changes would require considerable effort. However, it will be brought up to date as time allows.

Rules for Data Entry

Empty Fields

In general, all fields must be filled in apart from Date Out, Date Due Back, Comments, Disposal_Date, Disposal_Method, Income_received, and Buyer. When adding new records, there is a temptation to leave fields empty in order to save time, but this wastes time later on when we try to work out what they were supposed to contain. If a field is empty, we cannot be sure if the value is missing, not available, or not applicable.

If the value for a field cannot be entered for some reason, enter N/A for Not Applicable, or ? for unknown. For numeric fields, enter 0. Boolean fields should be left false.

If there is any doubt, enter a remark in Comments to indicate why a field is empty.

Information Coding

Fields should never be used to store any information relating to anything other than their specified property. Thus, don't try encoding various bits of information into different fields, since this makes it difficult to analyse records later on.

For instance, we used to add an E to Dept No to indicate that an item was electrical, but this made it difficult both to sort records by Dept No, and to filter records into electrical and non-electrical items. The correct solution was to create a separate boolean field to indicate if the item was electrical or not.

If you want to record some information that doesn't apply to any existing field, use the Comments field. If this happens regularly, we can create a new field.


There should be no redundancy (duplication of information) in each record, meaning that the same value should not appear in more than one field.

For example, don't record RS Digital Stopwatch under Name and Description since RS should already be specified under Manufacturer, and Stopwatch should already by stored under Equipment.

Letter Case

All values (except where otherwise noted) should be written in title case. That is, the first letter of larger or significant words should be in uppercase, while all others are in lower case. Generally, lower case is preferred, as it is more readable. Uppercase is preferred for codes such as Serial Number and Model No.

Value Consistency

It is essential to be consistent when entering values in order that searching and browsing work properly. For instance, INVENT used to contain about ten different values for the RS Electronic Components company in the Manufacturer field, including R.S., RS, Radio Spares, RS ELEC., and RS COMP., which made things very difficult!

Therefore, values for all fields should be standardised in terms of spelling, order of sub-values (which should be avoided anyway), capitalisation, and punctuation. If you find that a standard is problematic, or a new one is needed, design one and present it at the TSM meeting. Accepted standards should be documented here.

To get an idea of the existing standards, take a look at some other records of the same type, to ensure the format of the data you enter is consistent with previous entries. Where the values for a field have only a small range, the Limit-to-list feature should be used.

Some fields are restricted so that you can enter only information from a fixed list. When entering information in these fields, a drop-box will appear.

For instance, if you start typing Car in one of the name fields, Access will recognise that you are probably entering Carter, Neil, and will fill-in the rest of the value for you.

Name Values

Personal names (in User/Borrower, and Owner for staff and postgrads must be entered in last name, first name format. It is not necessary to enter all the initials, just the usual forename. For undergrads, it may be necessary to enter all first names, although their student number should be sufficient.

Date Values

Use DD/MM/YY format, and include leading zeros.

Tips for Searching

When trying to find a specific item, don't be too specific when entering a search value. For instance, when searching for a serial number, don't enter the full number, just enter the first few, or perhaps the last few. The reason for this is to allow for typos and inconsistencies (recall the RS example). Also, it can be useful to have items with similar entries shown, as this helps give a better overall picture of the data.

It is usually better to use the Sort or Filter features, rather than a straightforward search. The Sort command will help ensure that if you're looking for HP printers, you'll also see Hewlett Packard printers listed nearby. If you're confident that all entries are consistent, the Filter command may be better, as this limits the size of the list.

When searching throughout a table, make sure that Look In is set to the entire table, Match is set to Any Part of Field, and Search is set to All. Also, ensure Match Case is unchecked.

Missing Items and Records

If there are records for which a physical item cannot be found, there are a few things we can do to find the item. First check that the item has not been sold or scrapped (if it has been disposed of in this way, its record should have been marked as such). Failing that, the item may have been taken off campus, so check the Booking-Out logbook. If that reveals nothing, contact the owner and last recorded user. If it still cannot be accounted for, send an email to all members of the department asking if anyone knows where it is. Finally, if all attempts fail, the device should be reported as missing.

If there are items with no entry in the database (and, presumably, no departmental number on their case), confirm that the device really does not have an entry, rather than adding a new one immediately. It could be that the entry has been marked as scrapped by mistake, or has been given the wrong serial number, etc. — try browsing through the database looking for similar items, in case the record for the item in question is not immediately visible.

No duplicates should be used as much as possible, but only where appropriate.

Field Descriptions

Dept No

This is a five-digit number with leading zeros. Fewer digits means we might run out of numbers, whilst more would be unwieldly and difficult to remember. It is automatically generated, and does not allow duplicate values.

When creating new records, the lowest available number should be used. Gaps in the numbering exist where records were removed when the corresponding item was scrapped. Therefore, these numbers should not be reused. We must retain departmental numbers for scrapped items for auditting purposes, so do not delete records from INVENT; instead, records that we no longer need (for whatever reason) must be marked as scrapped.

The number should not contain any letters or symbols. In the past, some numbers contained an E for electrical, DC, SG, or SF if it belonged to the associated member of staff. These prefixes should all have been removed now. SGxxx was converted to 96xxx, SFxxx to 97xxx, and DCxxx to 98xxx.

Some of the larger gaps were caused by attempts to encode information into the departmental number; special categories of equipment were given departmental numbers that contained code letters indicating their special status. However, this is bad practice; it is important that fields are not 'contaminated' with anything that does not apply precisely to that field. Information should be stored in its own field, or in the Comments field.

The same departmental number should be applied to all parts of a device (e.g. to the PSU for a printer, and to the left, right, and subwoofer speakers for a speaker set), and the number should be written on each part.

Common errors:


This is the nature of the device, such as Audio/Visual or Micro (for computer-related items). Micro should be changed to Computing.

Common errors:


This indicates the basic type of the device, such as CPU or Tachistoscope. You can enter any value here, but use the drop-down list for consistency.

Common errors:


This is a self-referential list, but you can add your own values. The manufacturer called 3M should be recorded as 3M, not MMM.

The true manufacturer can sometimes be unclear due to relabelling by suppliers. For example, Mertec renamed ADI ProVista monitors with their own badge, so it appeared that Mertec was the manufacturer. In these cases, we should attempt to indicate the true manufacturer, rather than the supplier. Use auto-complete as much as possible.

Common errors:

Model No

This is the model code as opposed to the model name (which should go in the Name and Description field). For instance, the HP DeskJet 520, has a model name of DeskJet 520, but its model number is C2170A. We should use uppercase letters in this field.

Common errors:

Name and Description

This should be a very brief description of the device, or its natural name. It should not be a full breakdown of its features. For instance, a monitor could be 14inch CRT, but shouldn't be ADI monitor; the fact that it's a monitor is already indicated in the Equipment field.

Don't include the name of the manufacturer in the Name and Description field; it should already be in the Manufacturer field. Don't include monitor for monitors since this should already be in the Equipment field). The format for CPUs should be CPU; clock speed; RAM; disk space.

Do not include names (eg RAM, HDD), CDROM speed, model number (model name is OK), removable-disk information. Do not use leading zeros. Do not use thousands.

Theoretical aside: we should have a separate table for each type of device (e.g. CPUs, monitors and printers). This is because each device type has different properties. For instance, CPUs have clock speed, whilst monitors have screen size, and printers have paper size, and so forth. Although this structure would make INVENT very flexible and powerful, it would also make it very complicated. To balance complexity against integrity, we use a single general purpose table with the Name and Description configured as a free-form field. However, for ease of reading, it is important that we use consistent values for this field.

Common errors:

Powered By

This field is used to indicate whether a device needs an electrical supply from Mains or Battery. We might add a value of PSU (for Power Supply Unit) for accuracy.

Serial Number

This is an important field, since if this value has been entered accurately, we should be able to identify the item uniquely. Serial numbers are complex, so be careful to get this value right. Serial numbers can contain strange symbols that can't easily be entered, so enter a value that most closely resembles the actual value. Spaces and hyphens should be included (use only a single space for each blank, regardless of the size of the blank on the device). Adhere as closely as possible to the value printed on the device.


This field indicates the general purpose (work area) of an item. The values are limited to Office, Research, Teaching, Technical. It is useful for generating reports of departmental facilities.


This field indicates where the item should be (or where it was when we last saw it). If an item is taken off campus, or has a value that can't be recorded in the ACCOMOD database, then use the value Out, and add the actual location to the Comments field (or, if that's not available, then add any information that would enable us to locate the item). Also fill in the User/Borrower field.

When an item is moved, ensure that its record is updated as soon as possible. An auto-complete listing of all rooms in the department, taken from the ACCOMOD database, is provided for this field.

Common errors:

Usual Loc

This field indicates where an item is normally found, and is useful when items are loaned so that we know where to return them to.


This contains the name of the person who normally or currently uses this item. This person is not necessarily the owner. If the person is a member of the department, their name should be auto-completed for you. For general purpose items, enter the value Dept. See also the Owner field. Clear the value if the item is in the stores.

Date Out, Date Due Back

These fields are used when items are loaned for lengthy periods and when items are taken off campus (but also fill in the pro-forma for removing items from the department). If an item is being borrowed, the date when it was issued and the date when it must be returned are entered here. Both values should be cleared when the item is returned; in other words, these fields should only contain values when an item is out on loan. Date Due Back can be used to raise an automatic reminder.


The person or group that the item belongs to (the holder of the grant that was used to purchase it, for instance). If the grant with which the item was bought has expired, or it was bought with PSD100, it is general departmental property, so enter Dept.

Common errors:


The name of the organisation or individual from where we obtained the item. Auto-complete works provided that the supplier is found in the Suppliers table.

Common errors:

Guarantee Period

The number of years for which the warranty lasts.

Purchase Date

The date when the item was ordered, rather than delivered. This value should be the date on the official purchase order.

Order Number

The identifier number of the official purchase order (assuming one was raised).


VAT-exempt items may be used only on the project for which they were purchased, and by authorised personnel only. It is a boolean value indicating whether the item is VAT-exempt or not. This is a matter of law. In our case, VAT-exempt items are nearly always used for medical research.


What is the price of an item that is bought as part of a group (e.g. VDU as part of a PC system)?


This field can contain any additional information which can't or shouldn't be entered into other fields. It has no specific format.


A boolean field indicating whether the item has been disposed of. We discard items when they are broken and beyond economical repair, obsolete, or surplus to requirements. In addition to campus policy on disposal of equipment, we also obtain a signature of approval from the Head of Department prior to disposal. Once signed-for, items should be stored in the disposal room. To mark an item as scrapped, use the a special button at the bottom of the main form.


This is filled-in for scrapped items only. It identifies the person who received the item (if it was sold or donated).


Indicates when an item was physically removed from the department (not when it was scrapped from the database, or approved by the Head of Department).


How the item was disposed of. It might be discarded as refuse, given to another department, sold, or donated to charity.


The amount of money we received for the scrapped item, if it was sold. 0 is stored otherwise.

Unresolved Matters


A collection of data about a particular group of items structured into a matrix of rows (records) and columns (fields).
The whole collection of information about one specific item (i.e. all the properties of some object). One row of the table.
A specific unit of information in each record (i.e. a property of some object), such as the departmental number Dept No. One column of the table.
The actual data entered into a specific field. For example, the Dept No field for a particular record might contain a value of 00605.
Storing information that is unneeded (useless, or duplicated). For instance, if the value of the Name and Description field is RS Digital Stopwatch, then RS is redundant since it is already stored under Manufacturer, and Stopwatch is also redundant since it is stored under Equipment.
Limit to list
Some fields have a limited range of values (for example, there are only so many people in the department, so the User/Borrower field lists only the current members of the department. In these cases, Access can be used to help fill-in the value automatically. There are several ways of doing this, including look-ups from other tables, or self-referential lists . In either case, this feature can be adjusted so that you can add a new value that does not already exist in the list, or it can force you to use a pre-existing value. This feature helps maintain consistency, and avoids typing and spelling mistakes.
Self referential
Access lists the values that have already been stored in this field.
No Duplicates
If you specify that a field should have No Duplicates, Access ensures that no two records contain the same value in that field. This is handy for fields like Dept No since each value should be unique.

NOTE: A record contains one or more fields, and each field contains (theoretically) only one value.

Home About Me
Copyright © Neil Carter

Content last updated: 2006-10-02