-
Notifications
You must be signed in to change notification settings - Fork 44
Products and Vendors
Every store sells things. Most stores also buy things. The relationship between things the store sells and things the store buys can be complex. This document does not attempt to cover every variation of this relationship. An item that is manufactured in house (e.g., the output of a deli kitchen) using several component items (and extra labor!) is drastically different than a can of beans that simply goes on a shelf. This document covers the latter situation often referred to as "center store items". Fresh produce may or may not fit with this model. Potential differences with produce include greater degrees of product loss, greater price volatility, and many suppliers for the same logical item.
For consistency in terminology, things the store sells will be referred to as products. Products in the store are uniquely identified by a UPC (for purposes of this discussion, a PLU is just a special type of UPC that includes a lot of zeroes). Products must be uniquely identified. When a cashier scans or enters a UPC at the lane, no more than one item can come back as a result. This uniqueness constraint makes tracking exactly what the store sold very easy.
Vendors are entities the store buys things from. A vendor might be the manufacturer of an item if the store is buying items directly from the manufacturer, or a vendor might be a larger distributor that sells good from many manufacturers at wholesale prices. For consistency in terminology, things the store buys from vendors will be referred to as vendor items. To track cost changes or inventory levels, we must map each vendor item the store buys to a product the store sells. While each product must be unique, there is no such constraint on vendor items - i.e., there may be multiple vendor items associated with a single product. Creating and maintaining this mapping can be difficult. The quality, consistency, and format of information available from vendors will vary.
Manually mapping vendor items to products is the most time consuming but does illustrate the relationship. To get started, go to the Item Maintenance menu and choose Manage Vendors. Then choose a vendor. For the moment ignore the Mapping section; that deals with issues internal to a single vendor's catalog of items. The basic tools for associating vendor items with products are in the Catalog section.
- Add existing items to catalog will create a vendor item for every product marked as coming from this vendor. The generated vendor items still need to be reviewed and edited. This tool is just for initially bootstrapping the system.
- Edit vendor catalog lists all vendor items from the vendor in an editable format. Note that this is only available for catalogs with less than a thousand items. This is mostly to avoid crashing the browser with a massive table of information, although vendors that size are probably also capable of providing their catalog in a digital format.
Editing a vendor catalog exposes a new piece of terminology: SKU. Just like each product the store sells must be uniquely identifiable, each vendor item from a given vendor must be uniquely identifiable. SKUs uniquely identify vendor items in the same way UPCs uniquely identify products. SKUs can be numbers, letters, or a combination of both. A vendor invoice or catalog may well not have a column titled SKU. But it might have an "Item No." or "Part#" or "Order Code". The goal is to capture whatever convention the vendor uses to identify their items. When I receive the first invoice from a vendor, I have to manually create a mapping from their identifiers (SKUs) to my identifiers (UPCs). But when I receive the second invoice from that vendor, I can quickly locate the correct vendor item by SKU.
Some very small vendors will not have any kind of unique identifier for their items. Their items still need to be assigned SKUs. This means the store creates/generates them. Using the store's UPC as a SKU works fine although isn't particularly helpful in processing paper invoices. A brief textual SKU (e.g., "SYRUP12OZ") might work better. There's no simple answer. Invoices with no identifiers (or inconsistent identifiers) are inevitably more work to deal with.
The brand and description fields are provided for identification purposes as well. A vendor item brand and description are not required to match a product brand and description. In situations with a reliable SKU identifier this is a moot point, but having the vendor item brand and description match what appears on invoices can be helpful in other cases. Unit size fills a similar mostly informational role.
The case qty and unit cost fields describe how quantities purchased related to quantities sold. Every vendor item must have a case quantity although it is perfectly acceptable to have a case quantity of one. If an invoice line lists a quantity of 1 for a box containing 10 15oz cans of beans and the store is going to sell those cans individually, the case quantity is 10 and the invoice price needs to be divided by 10 to get the unit cost.
If the vendor provides a catalog spreadsheet or order form, that information can be imported directly. Saving spreadsheets as CSV is recommended although not strictly required. The minimum requirements for an importable spreadsheet are: SKU, UPC, and description along with either unit cost or both case size and case cost. The basic catalog import tool is found under Manage Vendors in the Item Maintenance menu. The catalog section for a vendor includes Upload new vendor catalog. Custom, vendor-specific import tools can be created if necessary to enforce extra logic or make adjustments to the data. Note that uploading a new catalog replaces all vendor items as opposed to adding new ones and updating existing ones.
This is a terrible section header and "mapping" is overused. Yes, terminology needs work here. The Manage Vendors tool in the Item Maintenance menu contains a subsection titled Mapping that we ignored earlier. These have to do with periodically rewriting parts of a vendor's catalog of vendor items.
The first is PLU/SKU mapping. This only pertains to vendors whose catalog is routinely imported from a spreadsheet. The relationship between products and vendor items is a UPC/SKU mapping and PLUs are just a subset of UPCs. However, importing a catalog involves deleting the entire catalog and deleting any existing UPC/SKU mapping. The PLU/SKU mapping is stored separately from the vendor items catalog so this mapping can be restored after the catalog is deleted and rebuilt.
The canonical use case for a PLU/SKU mapping is a large vendor catalog containing both SKUs and UPCs where most but not all products are sold using the listed UPC. Catalog vendor items with SKUs in the PLU/SKU mapping will use that PLU instead of the UPC listed in the catalog.
The second is Breakdown mapping. This pertains to vendor items that correspond to multiple products. The canonical use case is a six pack of soda. The vendor's catalog contains a single SKU for a six pack of soda. The store sells this item as two separate products: a six pack of soda and a single bottle of soda. The Breakdown mapping says that the six pack SKU vendor item needs to be "broken down" into the UPC (or PLU) of the single bottle product. In this situation unit size is very important to track costs correctly. A slash notation is common - e.g., "6/12oz".
Once all the mappings are in place, the Run Breakdowns button creates additional vendor items. In the example above we would have two (vendor item, product) pairs:
- Six pack: (vendor SKU, product six pack UPC)
- Single: (breakdown-generated SKU, product single UPC)