During the course of managing a project, you may need to change the IDs being used. This might be needed for a number of reasons:

• A prototype project was cloned or prototype rooms were imported and the Room IDs need to be changed to reflect those in a specific project.
• The client for a brand-oriented project already has a system of IDs and Tags to which you must conform.
• The normal editing process has left gaps in the sequences of Tags and/or Spec IDs (CHR01, CHR02, CHR05, etc.) that you prefer to close instead of using a "NOT USED" label in the description (note that an unused object will never appear in the FF&E Worksheet's presentation reports, because it has to be placed in a room to be included in the report). They will appear in Specification screen reports.
• Typing errors and imports from other projects have left some Tags and Spec IDs with inconsistent prefixes (e.g., one spec with the ID "FLOOR01" and another with "FLR-02")

Most changes are simple

The good news is that you can change any ID at any time without having to worry about updating the rest of the system. Once you change the ID of any item on its editing screen (that is, changing a Room ID on the Rooms screen, an object Tag on the Object screen, etc.), this change will be reflected throughout the whole project after any screen updates occur.

If you are trying to close gaps in  sequentially numbered groups, the easiest way to do it is to change the last ID in that group to the first ID that fills the gap. So if you have CHR001 through CHR010 and CHR002 is not being used, you can preserve the sequential numbers (if desired) by:

1. Deleting CHR002 (if it still exists)
2. Editing CHR010 and changing its Tag to CHR002.

Alternatively, you can preserve the original CHR002 content by renumbering it to a high unused number like CHR099 before editing CHR010. If the new CHR099 is not placed in a room, it will not appear on any of the FF&E Worksheet presentation reports.

Important: If you have the Design/Purchasing version, you should not change the Spec IDs after an object has been ordered, nor "re-use" an already-ordered Spec ID for a different product in the same project. There are update functions in the Purchasing module that you can use to "update" an existing order item, but you may get unexpected results if someone has redefined the original specification for a different purpose.

This is all you need to know about changing most IDs in the system, with one exception involving matched object Tags and Spec IDs.

One exception: Synchronized Tags and Specs IDs

Many if not most designers use the same Spec ID for the primary component of each object (e.g., the primary specification for chair object CHR001 uses "CHR001" as the Spec ID, while a secondary fabric spec may use a very different ID). However, the Tag and the Spec ID are not automatically linked, because there are reasons why the Tag and Spec ID might be handled differently—for instance, if you use the same primary spec in several objects with different Tags or if the Spec ID is related to an external inventory system instead of floor plan tags.

As an example, the requirements of a client's tagging system may specify that the same piece of FF&E might have different tags in different wings of a hotel. So, if you need objects tagged as NW-ART01 and SW-ART01 for the same artwork used in the North and  South Wings, respectively, you can still use the same spec (with just one Spec ID: ART-01) to create the two objects needed to satisfy the client's tagging scheme.* Take-offs then accurately total the number of artwork ART-01 needed, while splitting the total for the different "uses" of that product.

The good news: Since most designers want the Tags and primary Spec IDs to match, this "exception" isn't that much of a problem: FF&EZ will automatically change a Spec ID to match a change in the Tag if:

1. The existing Tag and Spec ID exactly match...
2. You edit the object Tag first, and...
3. You confirm that changing the Spec ID to match is what you want when prompted.

Simply change the Tags first when you need to modify the tag/spec ID scheme. Then deal with the remaining exceptions as needed.

*Note that this kind of approach, where location information is embedded in an object Tag, should be discouraged because FF&EZ already tracks where objects are located without extra coding in the tag scheme. These approaches are often holdovers needed for more manual spec writing systems, and they tend to create unnecessary extra work to manage objects that should be able to be used anywhere without regard to their tags.