> ## Documentation Index > Fetch the complete documentation index at: https://docs.tryoto.com/llms.txt > Use this file to discover all available pages before exploring further. # Product catalog and SKU configuration > Set up products and SKUs: barcodes, bundles and kits, serial numbers, variants, handling rules, per-channel settings and bulk import of your catalog. > [!NOTE] > > **Where to find it:** Settings → Management → Products — [Open in OTO ↗](https://app.tryoto.com/products) The product record is the single most leveraged piece of data in the platform. A barcode typed in once decides whether a picker can scan a box three years later; a weight left blank turns up as an unexpected carrier charge every month until someone fills it in. ## Where the catalog lives **Settings → Management → Products**, with four tabs: | | | | - | - | | **Products** | The catalog itself. Columns: **Product Name · SKU · HS Code · Barcode · Price · Pre order Only · Variants Enabled**. | | **Categories** | How products are grouped — and therefore how [shipping rules](https://docs.tryoto.com/modules/shipping-management/shipping-automation.md) and [routing rules](https://docs.tryoto.com/modules/omnichannel-oms/order-routing.md) can address them in bulk. | | **Product Attributes** | Your own fields, beyond the standard ones. | | **Attribute Groups** | Attributes gathered into sets, which appear as their own tab on the product form. | Three buttons sit above it: **Add Product**, **Upload Multiple Products** for a bulk import from a template, and **Synchronize Products** to pull the catalog from your connected sales channels. ![The Products page](https://mintcdn.com/oto/ft-bRlLvOnJkbVoC/images/inv-11-products.png?fit=max\&auto=format\&n=ft-bRlLvOnJkbVoC\&q=85\&s=fa87906da04ddad0df9e3dd4b33fcc99) Fig. 1 — Every row carries a thumbnail, and Pre order Only and Variants Enabled read as Yes/No chips rather than raw values. ## The product record ![The top of the Add Product form](https://mintcdn.com/oto/YkJay8Y-1RDv8ciw/images/inv-12-add-product-top.png?fit=max\&auto=format\&n=YkJay8Y-1RDv8ciw\&q=85\&s=2008c3832b6a76311fc6cd04e32b63f1) Fig. 2 — Only Product Name, SKU and Price are required. The tab row grows as options are switched on — here Product Variants and Variant Configurations have appeared. ### Identity | Field | What it is for | | - | - | | **Product Name** | What a picker, a packer and a customer all see. | | **SKU** | The unique code. Everything else in the platform refers to a product by this. | | **Barcode** | The primary scannable identifier. | | **Other Barcodes** | Additional barcodes, added as a list — see below. | | **Category** · **Brand Name** | Classification, both searchable. Automation rules can act on either. | | **Tags** | Free labels, added as a list. Useful for the groupings that are not categories. | | **HS Code** | The customs classification, searchable *by code or by product type* so nobody has to own a tariff schedule. It feeds cross-border paperwork — see [HS Code Corrector](https://docs.tryoto.com/modules/omnichannel-oms/prefulfillment.md). | | **Description** · **Image** | The image is worth filling in: it is what appears on the picking and packing screens, and a photograph is a faster check than a name. | ### Commercial **Price** and **Tax Amount** each carry their own **currency selector**, so a catalog can hold products priced in different currencies rather than forcing one and converting. **Pre order Only** marks a product that may be ordered before stock exists; orders containing one are held rather than released — see [Pre-fulfillment checks](https://docs.tryoto.com/modules/omnichannel-oms/prefulfillment.md). ### Weight and dimensions **Length**, **Width** and **Height** in centimetres, **Total Weight** in kilograms, and **Cubic Meter** in cm³ — each with a stepper, and each unit shown in the field so nobody has to guess. ![The rest of the product form](https://mintcdn.com/oto/ft-bRlLvOnJkbVoC/images/inv-13-add-product-lower.png?fit=max\&auto=format\&n=ft-bRlLvOnJkbVoC\&q=85\&s=779eea1e7d83cfc35e68e7a40c667d8e) Fig. 3 — Dimensions, the bundle and serial switches, tags, the two kinds of barcode, and the packaging-barcode table once it is enabled. > [!TIP] > > **This is the field people skip and then pay for** > > Carriers charge on whichever is greater, actual or volumetric weight, and they reweigh at their own depot. A catalog with missing dimensions produces shipments quoted at one price and invoiced at another, and the difference only surfaces in [invoice reconciliation](https://docs.tryoto.com/modules/shipping-management/shipping-invoices-reconciliation.md) weeks later. Filling these in once is the cheapest shipping saving available. ## Multiple barcodes per SKU One product can carry several barcodes, and there are two distinct reasons to want that. ### Other Barcodes Several codes that all mean *one unit of this product*: a manufacturer’s EAN, a warehouse-applied label, an old code from a previous supplier, a marketplace’s own identifier. All of them scan to the same product, so nothing has to be relabelled and no picker has to know which generation of sticker is on the box. ### Packaging Barcodes A different idea, turned on with **Enable Packaging Barcodes**. The product’s own description: *“Allow products to have packaging-specific barcodes with custom quantities per scan (e.g., boxes, cases, pallets).”* Switching it on opens a table with three columns, one row per packaging level: | | | | - | - | | **Barcode** | The code printed on that packaging. | | **UOM** | What the packaging is: **UNIT**, **BOX**, **CASE** or **PALLET**. | | **Units per Scan** | How many sellable units one scan of that barcode represents. | ![The packaging-barcode table with the UOM list open](https://mintcdn.com/oto/YkJay8Y-1RDv8ciw/images/inv-14-uom.png?fit=max\&auto=format\&n=YkJay8Y-1RDv8ciw\&q=85\&s=3f25cbde73ddf542ea8a2dd4d60fd17d) Fig. 4 — Four levels, so a product can carry a barcode for the unit, the box, the case and the pallet at once. > [!TIP] > > **One scan, twenty-four units** > > A case of twenty-four has its own barcode and its own row, with **Units per Scan** set to 24. Without this, receiving a pallet means opening cases and scanning singles, or trusting a typed number. With it, the case barcode *is* twenty-four — the scan carries the quantity. > > The saving compounds at every touch: goods-in, putaway, counting and transfers all stop being per-unit work on products that arrive by the case. And because all four levels can coexist on one product, the same item can be received by the pallet and picked by the unit without anyone changing a setting. ## Bundles and kits Turn on **Bundle Product** and the product becomes a container. A table opens beneath it, one row per component: ![A bundle and its components](https://mintcdn.com/oto/ft-bRlLvOnJkbVoC/images/inv-18-bundle.png?fit=max\&auto=format\&n=ft-bRlLvOnJkbVoC\&q=85\&s=76a88d6e79582f549115f3e39c326c70) Fig. 8 — Two columns and nothing more: which SKU goes in, and how many of it. Each row is confirmed with a tick before it counts. | | | | - | - | | **SKU** | The component, chosen from the catalog. Components are ordinary products with their own stock, barcodes and dimensions. | | **Quantity** required | How many of that component go into one bundle. | The bundle is sold as one line and handled as its parts. The order shows a gift set; the warehouse picks and packs the items inside it separately, each against its own stock. So a component running out makes the bundle unsellable automatically, without anyone maintaining a second stock figure for the bundle itself. > [!TIP] > > **Quantity is what makes this more than a grouping** > > A bundle containing two of one component and one of another is not a list of three products — it is a recipe. Getting the quantity into the definition means the picker is told to fetch two, the availability calculation knows that a bundle needs two, and a stock of five of that component supports two bundles rather than five. > > It is the difference between a bundle that stays sellable because nobody did the arithmetic, and one that goes out of stock at the right moment. ## Serial number tracking Two fields govern it: **Serial Number Requirement** and **Serial Number Type**. Requirement is what decides whether an operator is stopped, prompted, or never asked. ![The Serial Number Requirement options](https://mintcdn.com/oto/YkJay8Y-1RDv8ciw/images/inv-15-serial-req.png?fit=max\&auto=format\&n=YkJay8Y-1RDv8ciw\&q=85\&s=50aa17ec0a2d57b6ede8cdf58efd9fb6) Fig. 5 — Three states, and the middle one matters: Not Applicable is an explicit answer, not an empty field. | | | | - | - | | **Required** | The serial must be captured. Picking cannot be completed without a valid one. | | **Optional** | The prompt appears; the operator may skip it. | | **Not Applicable** | No prompt at all — this product is not serialized. | Validation runs at **both** picking and packing. On the pick screen, once an item is picked — scanned or entered by hand — a **Serial Number** button appears for products whose requirement is set to required or optional. The operator enters or scans the serial, and it is validated immediately: if it does not validate, picking cannot be completed for that order until the correct serial is supplied. > [!TIP] > > **Catching it at the pick, not the pack** > > Validating only at packing means a wrong unit has already been walked to the bench before anyone notices, and the picker who fetched it has moved on. Validating at the pick means the correction happens at the shelf, where the right unit is within arm’s reach. > > It is the same check in both places, so the cost of adding the earlier one is a second per serialized item — against a returns case that costs considerably more than that. Serial numbers matter wherever a warranty, a recall or a dispute attaches to a specific unit rather than to a SKU: electronics, appliances, anything with a registration. ## Variants **Product Variants**, in the product’s own words, lets you *“add different options like size or color.”* Switching it on adds two tabs to the form — **Product Variants** and **Variant Configurations** — and the catalog list carries a **Variants Enabled** column so you can see at a glance which products are structured this way. ![The Product Variants tab](https://mintcdn.com/oto/ft-bRlLvOnJkbVoC/images/inv-16-variants.png?fit=max\&auto=format\&n=ft-bRlLvOnJkbVoC\&q=85\&s=15f5337fc804b33f50c21ec4083df488) Fig. 6 — A variant is a name and a list of options. Add Another Variant stacks a second dimension on the first. | | | | - | - | | **Variant Name (English)** | The dimension — the placeholder suggests *Size, Color*. | | **Variant Name (Arabic)** | The same, in Arabic. Captured alongside rather than as a translation step afterwards. | | **Options** | The values along that dimension, added one at a time. | > [!TIP] > > **Naming in both languages, at the point of creation** > > A storefront serving Arabic and English readers needs both names for every variant dimension. Capturing them together, on the form that creates the variant, is what stops the second language becoming a migration project later — and it is why the field sits beside the first rather than in a translation screen. ## Handling that depends on the goods Some categories carry requirements that change what the warehouse is allowed to do with a unit rather than just describing it. Not all of them live on the product record — an expiry date, for instance, is captured on the receipt that brings the stock in. | Requirement | What it governs | | - | - | | **Batch and lot management** | Units grouped by production run, so a quality problem can be traced to a batch and that batch alone withdrawn — rather than every unit of the SKU. | | **Expiry dates** | Captured per line when stock is received, not on the product record — because shelf life belongs to a delivery rather than to a SKU. See [Inbound inventory](https://docs.tryoto.com/modules/inventory-management/inbound-inventory.md). | | **Temperature-controlled goods** | Products that must stay within a range. It constrains which carriers and which vehicles may take them; **Temperature Control** is available as a condition in [shipping automation](https://docs.tryoto.com/modules/shipping-management/shipping-automation.md), so the rules can route these orders to carriers equipped for them. | ## Per-channel settings on the product The form’s **Sales Channel Sync** tab is a table, one row per channel this product is listed on. ![The Sales Channel Sync tab](https://mintcdn.com/oto/YkJay8Y-1RDv8ciw/images/inv-17-channel-sync.png?fit=max\&auto=format\&n=YkJay8Y-1RDv8ciw\&q=85\&s=98049b5a5761ef963640b00da241f1d5) Fig. 7 — Each row ties this product to its identity on one channel — and can override how stock is calculated for it. | | | | - | - | | **Sale Channel & ID** | The channel, chosen from your connected ones. | | **Inventory Calculate Method** | How availability is worked out for *this product on this channel*. | | **Sales Channel Product ID** | What the channel calls this product. This is the link that makes sync possible at all. | | **Channel Category ID** · **Channel Category Name** | Where it sits in the channel’s own taxonomy. | | **Inventory Sync** | Whether this product syncs to this channel. | > [!TIP] > > **Two levels of the same control** > > **Inventory Calculate Method** and **Inventory Sync** both appear here *and* on the channel’s own [sync settings](https://docs.tryoto.com/modules/inventory-management/inventory-sync.md). The channel setting is the default; the product row is the exception. > > That is what lets a single line be protected with safety stock on a marketplace that penalizes cancellations, while the rest of the catalog on that same channel sells down to the last unit — or lets one problem SKU be taken out of sync without touching anything else. ## Custom attributes When the standard fields do not cover what your business needs to record, **Product Attributes** adds your own: a name and label, a type, an optional default value, and a flag for whether the attribute appears in imports. Attributes can be gathered into **Attribute Groups**, and each group becomes its own tab on the product form — so a form stays readable however many fields a category needs. ## Getting the catalog in | Method | When | | - | - | | **Add Product** | One product, all fields. | | **Upload Multiple Products** | Bulk, from an Excel template downloaded from the page. | | **Synchronize Products** | Pull the catalog from connected sales channels — the fastest way to start, and the way to keep two systems agreeing. | Bulk uploads are tracked at **Settings → Data Center → Data Uploads**, which reports what imported and what did not, with the errors named per row. Worth opening after every import rather than assuming a file that uploaded also landed. ## Related * [Inventory sync](https://docs.tryoto.com/modules/inventory-management/inventory-sync.md) — keeping channel catalogs aligned. * [Picking methods](https://docs.tryoto.com/modules/warehouse-management/picking-methods.md) — where barcodes and serials are used. * [Invoice reconciliation](https://docs.tryoto.com/modules/shipping-management/shipping-invoices-reconciliation.md) — what wrong dimensions cost. ## Related topics - [Carrier integration and configuration](https://docs.tryoto.com/modules/shipping-management/carrier-integration.md) - [Sync inventory to your sales channels](https://docs.tryoto.com/modules/inventory-management/inventory-sync.md) - [Sales Channels](https://docs.tryoto.com/modules/sales-channels/overview.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.