Configure Products

What is a Product in OpenBoxes?

Products are one of the most important objects in OpenBoxes. A product record describes a specific physical item for tracking in inventory, shipments, and purchase orders. Products are identified primarily by a name and a unique code. The product code, called a SKU in some systems, functions as the main identifier for the product within all areas of the system. The product name tells the user what the product is. Here are some examples of possible product names and codes in OpenBoxes:

You can see from this list that there are many different ways to define and code a product in OpenBoxes. One organization may choose to define all exam gloves as the same product. This makes it easy to track and report on exam gloves as a group, but information about the size or material of the gloves will be lost. Another organization may choose to define a product as a particular model number from a manufacturer. In this case, they will likely have many different products for the same size and material of exam gloves, but they will be able to track all gloves by manufacturer code. We will discuss the possible product configurations in more detail below. For now, one key thing to remember is that users should be able to tell what your product is based on the name alone. While products contain a large amount of information, including model number or manufacturer code, category, NDC, and others, that information is not visible in every screen in every workflow in the system. The product name is always visible, so users should be able to understand the key features of the product by the name alone.

Fields on Product:

Active: Check the box to make the product visible and searchable

Product type: Default unless organization is using special product config. See https://openboxes.atlassian.net/wiki/spaces/OBW/pages/1741258759

Code: unique ID autogenerated by OpenBoxes. Can be configured for different formats

Name: A description of the product that defines what it is for users

Category: Select a category from the defined category tree

GL Account: This will be visible if accounting is enabled in your instance. Select from the dropdown.

Unit of measure: The unit that you are tracking the inventory in. This is a free text field

Cost: The cost of the product. This may be auto-updated by purchase orders depending on how your administrator has configured your settings

Product Description: Additional description of the product up to 250 characters

Tags: Add any relevant tags. See more about tags here

ABC Classification: Enter the ABC classification letter for the product here. Free text.

Handling Requirements: Check any handling requirements for the product. Product will show the handling icon associated with that requirement

Inventory Control: Check lot and expiry control if you want OpenBoxes to require lot and expiration for this product

Brand Name: Enter brand if the product is brand-specific. If not leave blank.

Manufacturer: Enter manufacturer if the product is manufacturer-specific. If not leave blank.

Manufacturer code: This is the sku number the manufacturer uses for the product. Enter if the product is manufacturer-specific. If not leave blank.

Manufacturer Name: This is the name the manufacturer uses for the product. Enter if the product is manufacturer-specific. If not leave blank.

Model No: Enter model number if the product must be a specific model number. If not, leave blank.

Vendor: Enter vendor if the product is vendor-specific. If not leave blank.

Vendor Code: This is the sku number the vendor uses for the product. Enter if the product is vendor-specific. If not leave blank.

Vendor Name: This is the name the vendor uses for the product. Enter if the product is vendor-specific. If not leave blank.

UPC: Enter the Universal Product Code if known

NDC: Enter the National Drug Code if known

Grouping and Categorizing Products

There are a variety of ways to sort OpenBoxes products into groups or categories.

Category

Category is a required field for all products, and functions as the main method of organization for products. OpenBoxes allows administrators to define their own category tree, or to import categories from the UNSPSC. Each product must be assigned to one category within the category tree.

Formulary/Catalog

Catalog, also called formulary, is an optional grouping system for products. This feature allows users to create a catalog that lists all products for a certain location or service. Products can be part of multiple different catalogs. Catalogs can also be color-coded, so products in those catalogs appear in the designated color within the UI.

Tag

Tags are very similar to catalogs, except they are designed to be slightly more informal. Catalogs must be created within the catalog menu, while tags can be created by simply typing into the tag field for a product. Tags cannot be color-coded.

Generic Product

Generic product is a grouping above product designed to group similar products for reporting purposes. For example, if your instance of OpenBoxes has a specific product for each size and specification of exam glove, but you want to be able to report on all exam gloves at once, you can create a generic product called “exam glove” and assign all exam glove products to that generic. Then you can run certain reports by generic product to see information for all exam glove products at once.

Substitutions

Substitutions are not exactly a way to group products - instead, they allow a user to indicate that one product is a substitute for another. Substitutions are integrated into the picking and request fulfillment process, and as such are a very powerful tool for distribution management. Products can have multiple substitutions, and substitutions can be either uni or bi-directional.

Often organizations use categories, tags, catalogs, generic products, and substitutions in combination to group products in distinct ways. For example, Ofloxacin eye drops might have a category “Antibiotic,” a catalog “District Hospital,” and tags “ophthalmology” and “primary care.” Together, these grouping show that ofloxacin is an antibiotic required for two serves: ophthalmology and primary care, at the district hospital level. Ofloxacin eye-drops are associated with a generic product “Ofloxacin,” so clinicians can view data on all formulations of ofloxacin in the system. It is also has a linked substitute of ciprofloxacin eye-drops, indicating that if it is stocked out, cipro eye-drops can be used for the same purpose.

Possible Product Configurations

Define product by manufacturer code:

This is the preferred configuration for most organizations that sell product. A product is defined as a specific manufacturer-code combination (or potentially vendor/manufacturer/code combo). The benefit of this system is that it is extremely specific. It tracks the exact product purchased from the manufacturer, through inventory, all the way to sale. This is perfect for companies that need to track what was sold against what was purchased, by brand. The data might look something like this:

As you can see from the data, there are some downsides of this method for organizations that are actually delivering care. While for a medical distributor, the three amoxicillin 250mg products are fundamentally different, for a clinician or hospital administrator they are functionally the same. While it is possible to make this product structure work for care delivery using substitutions and generic products, service delivery organizations may want to consider a more generic structure.

Define product by relevant characteristics:

In this product structure, an administrator or group of administrators defines a product based on its most important characteristics. If two items have the same key characteristics, they are the same product, regardless of manufacturer information. In general, this system is preferred for organizations that are end users, not sellers, of products. The data might look something like this:

In this data set, supplier and manufacturer information is irrelevant. All amoxicillin 250mg tablets fall under the same product, regardless of pack size or manufacturer. For exam gloves, there is a defined set of characteristics listed in the name that determines the product. All small latex powdered gloves are CD167, even if some gloves are extended or beaded cuff, but a powder-free glove is a different product.

While this method has the benefit of being focused on the attribute of a product that the end user cares about, it also has some significant downsides. The most obvious one is that it doesn’t track which supplier or manufacturer a given quantity of product came from. This information can be tracked via the product source function, and recalls can be managed via lot tracking, so many non-seller organizations find that they do not need the additional detail. The more significant downside to this method is the level of judgement and expertise required by users and administrators. Defining products by relevant characteristics means that there must be a group of administrators responsible for defining what characteristics are relevant for each group of products. For certain products this can be quite complex. This system also requires either that purchasers deeply understand the characteristics of products they are buying, or that subject matter experts are heavily involved in documenting which purchasing options meet spec.

Combination Method

This method is essentially a variation on the “define product by characteristics” method, where the manufacturer information is one potential characteristic. For an organization with a wide range of products, it is likely that certain product categories are better tracked by manufacturer code, while other categories are better at a more generic level. There is no reason why different type of products cannot be tracked differently. The data in this case might look like this:

In the example above, our amoxicillin and exam gloves are still defined by their generic characteristics. However, medical equipment and car parts are defined by manufacturer code. You can see by the name the both TG407 and BF305 that both products are infant resuscitation systems. However, infant resuscitation systems have a wide range of specifications, and it wouldn't be realistic to list them all. Therefore, the different models are tracked as separate products while the name acknowledges that they serve the same basic function. For vehicle parts, every part is designated by a unique manufacturer code, and parts are never interchangeable with one another. So vehicle parts are tracked by code, with some information in the name to provide context for the user.

This method has the same requirement for knowledgeable administrators as the characteristics method, but it does remove a large administrative burden if there are clearly defined categories that should always be tracked by manufacturer code. It is also the most flexible, and the most desirable for final end users in a system because products are always tracked based on the information they need for their work.

Other methods:

While the methods listed above are the ones most commonly used in LMIS systems and are the ones recommended for OpenBoxes, the flexible product structure can accommodate a wide range of possible configurations. If your organization has another method in mind, the best approach is to mock up some demo data and try it out!