|
Objects and Their Specifications
|   |
|
Objects and Their Specifications
| |
|
Definitions In FF&EZ, some terms—that might be used somewhat interchangeably in casual speaking—have very specific meanings. These are "specifications," "objects" and "components." Understanding the relation between these concepts is a key to understanding how FF&EZ works and how it can minimize the labor of creating project documentation in many different formats. Specification This term is not too different from the normal definition. As the word itself implies, a specification is the detailed description of a specific product from (eventually) a specific vendor. We say "eventually," because a specification may be created for bidding purposes, with more than one possible vendor competing for the job, and so the vendor of choice may be hidden on reports or simply entered as "TBD" (To Be Determined). But the basic idea is that a specification is...specific. Although a bidding situation may require something more generic, the "Type" field in the specification should normally say what the thing is, e.g. "Chair, stacking, 'Futura' series" not "Chair, conference." There are three key differences between a "specification" in FF&EZ and looser uses of this term:
For example, the specification for one vendor's chair frame does not refer to the specific fabric selected for the frame if that fabric is COM from another vendor (that's a separate specification). It can (and usually should) refer to how any fabric might be used on the frame. As you will see below, FF&EZ then puts the two specifications together on reports to indicate what goes into a finished chair. In contrast, if the fabric is one of the same vendor's standard selections (that is, it could all be ordered with a single purchase order to that vendor and you don't need to track the total quantity of fabric needed), then writing it into the same specification makes more sense. This would also be the case if the fabric is from a different vendor, but the primary vendor will procure all components for a single unit cost. As mentioned above, a special type of specification, the "Image only" spec, is available. This type of spec allows you to add more images to an object by attaching them to a simplified "spec" that will not be included in any orders. It can be used as needed as a component of any type of object. Object This is the "thing" that the client buys, in the sense of a finished product. It may be something as simple as a table lamp or can be a complex object such as a bed made up of a headboard, bed base, mattress set and coverlet, or a finish (one area rug and one square foot of carpet are both considered objects) or an existing item requiring refurbishment. Objects can be understood by looking at several perspectives:
The biggest difference between objects and specs, however, can be explained like this: Objects are what the client buys, while product specifications are what you order from a vendor. There is often a one-to-one correspondence between the two, but not always. Although objects can be created in the system without any associated specifications, we recommend that you always create them with at least one empty "placeholder" spec (more under "Components" below). This lets you set up a detailed project budget for approval, listing the proposed room objects — but without having to return and link specs to them later. Component Here is the key to how objects and specifications are brought together in the program: A component is simply a specification used in an object in whatever quantity is needed for one object. By selecting a product to use and then making it a component of an object, you have changed the object from a "black box" to a real product, with the component or components (that is, specs) describing the actual product or products you've selected and the quantities needed.
The Component List on the Object List screen, showing the components being used for an object (a chair) and the quantity (right-most column) used in one object. The first component is typically the product that most "defines" the object (a chair frame).
To "use" a specification, you either add it to an object's component list on the Object Form, or use the Object function on the Specification Form. Each function does the same thing — "connecting" a component to an object — but is designed to be convenient to different situations. Even more useful, though, when you use the Object List screen's Add command, FF&EZ will automatically connect up to two specs to the new object for you. The specs can be "skeleton" specs created automatically, an existing spec you pick manually or a spec you create or import yourself. You can select the Add command on the Object screen, or you can branch to it as part of adding objects to a room on the FF&E Worksheet.
When adding an object on the Object List screen, FF&EZ will offer to add one or two components to it for you, eliminating multiple data entry steps in one operation. Generally, this is an offer you should not refuse. How Many Components Do I Need? It is possible to have only one component for every object that you use in a project. However, this means that you must create and place an object for every specification in your project, including calculating the quantity needed for supporting specifications such as fabrics. FF&EZ is designed to eliminate all or most manual calculating while it also provides a way to account for all supporting products in every room where they are part of an object. This happens when a supporting product like a fabric has been added as a secondary component of the object (e.g., a chair) in which it is used. Simply placing the chair in a room also automatically "places" and uses the fabric (it appears in the object's detail in the FF&E Summary section of the Worksheet). Fortunately, there are two easy "rules of thumb" to decide when to add a specification as a separate component of an object, plus a couple of exceptions: Rule 1: If you are doing turnkey design, add supporting products as secondary components of the primary object. This approach makes it easy to have multiple images (one for each product) as part of the illustration sheet (project book) report. Rule 2: If you are designing / quoting and purchasing, the number of components in an object typically matches the number of purchase orders needed to make that object appear at the job site. This is especially the case when a supporting product must be shipped to another vendor (controlled in the "Shipping" section of the specification screen). The exceptions to these rules are fairly straightforward, but are more easily explained by restating the rules as a series of cascading questions:
If you create a object like that described above, we recommend that you assign Spec IDs to the components using suffixes that you add to the base Tag or Spec ID. So if a piece of processing equipment contains a primary component and three related components, you could set it up like this:
The resulting purchase order will group all four specified items together, since purchase orders are created in Spec ID sort order for each vendor (we assume that each of these three specs all have the same source). The costs for the pieces could be set individually or rolled into EQ-001A.
Most things tracked by FF&EZ have an "ID" associated with it: Project IDs, Room IDs, Spec IDs, etc. In contrast, objects are identified by the "Tag," a common industry term referring to the ID used on a drawing to identify an item that will be specified later. Part of the planning that goes into using FF&EZ is the development of a systematic approach to creating Tags and Spec IDs (although you can (and sometimes must) vary your approach from client to client and project to project). The approach you use will depend on how you like to organize information and how flexible your system needs to be. If you work in a purchasing firm and want to import products that come from your library or another project, you can easily use the client's ID system as you create objects and specs or change them later to match. FF&EZ does not care (except that the IDs cannot be duplicated within the same project). Tags and Spec IDs are project-specific. You can use one approach to setting them up in one project, and a completely different one in another if that is required for a particular client. Although it makes sense to use standard prefixes for tags and spec IDs to group them by type, we don't necessarily recommend setting up permanent IDs for particular items because of variations that can happen from one project to the next. Below are different approaches to assigning these types of IDs: Tag equals Spec ID One approach to assigning IDs is to have the Tag match the Spec ID for the first component. This is a simple and easy approach, but it has a minor drawback if you want to use alternate components that might be switched in and out as you work with alternate designs, which makes synchronizing the Spec ID a little harder. One distinct advantage to this approach (which is the most common one because of its simplicity) is that if you change an object's Tag and a spec with an identical tag is attached, the system will offer to change the Spec ID to match the new Tag. This does not work in the opposite direction, so change the Tag first. When you create a new object on the Object Screen, the system will offer to create a matching spec with a matching Spec ID. In the same way, when you create a new spec on the Specification screen and use the Save/Object option to save it, the system will default to using a matching Tag to create a matching object. Unless you have a reason to changes these (as explained below), you can accept the suggested entries. Tag based on Spec ID If you use the same spec as the primary component in two different objects (as you should if you create two chairs using the same frame but different fabrics), you can't use the same object Tag for both objects. The solution: Add a suffix to the object Tag to identify variations that use the same main component. So two different chairs that both use Spec CHR001 might have tags of CHR001A and CHR001B:
If you let the price of the object be calculated from the prices of the components (or if this is a cost plus fee project), this prevents the need to create two identical specifications for the same chair frame. This approach also makes sense where the same artwork is being used with different colored frames in a project. Tag unrelated to Spec ID Another approach is to think of the spec as being unrelated to the object. This is technically correct, since you can use any spec in any object. In this case, you might use an object Tag of SEAT001, made up of chair frame CHR001 and COM fabric FAB002. Or you might assign the Spec ID based on an abbreviation for the product itself. With this approach, the object Tag is the "architectural" ID that relates to floor plans, while the Spec ID is the "ordering" ID that relates to product types. Revisions When you need to make changes to objects and specifications, you may be unsure of where to make those changes. Remember, though, that the way FF&EZ links to the source of the data you see creates a clear and simple logic. It will help to remember these rules of thumb:
There is one special case: If the object's "Use Component #1 Type/Product" option is selected (which it is by default), the short "Type" description field of the primary component spec will appear on all reports in place of the object's "Description" field (meaning that the generic object "becomes" the primary product that was selected). If it is not selected, the object description is being used and a change to the "Type" field will only appear when components are listed on reports and other screens.
|
