Managing Colours, Sizes, SKUs, Barcodes and Stock Across Multiple Shops
A practical guide for garment and footwear wholesalers managing colour-size variants, SKU barcodes, low stock and inventory across shops and godowns.
Garment and footwear inventory should be organised as one product with separate SKUs for its sellable colours and sizes. Each SKU needs its own quantity, price, cost, image, barcode and location-level stock, while the common product keeps the shared name, item code, category, HSN and GST details.
This structure lets a wholesaler see that a shirt design is available without pretending every colour and size is in stock. It also allows Inventory Manager, Order Manager, Staff Bill and the My Local Shops website to refer to the same stock identity.
At a glance
| Question | Recommended structure |
|---|---|
| Is one design in four colours one product or four products? | One product with separate colour SKUs |
| Is Medium stock the same as Large stock? | No. Each size needs its own SKU and quantity |
| Can different types have different prices? | Yes. Price and cost belong to each SKU |
| Can each colour have its own photo? | Yes. Each SKU can retain its own image |
| Should staff type SKUs manually? | No. Inventory Manager generates and protects the SKU |
| What does the printed barcode contain? | The exact system-generated SKU in Code 128 format |
| Is a random QR code accepted as a product? | No. Product scanning is restricted to valid system SKU barcodes |
| Can one SKU exist at several shops? | Yes. Its total is divided into quantities by location |
| Does a transfer change total business stock? | No. It moves quantity and stock value between locations |
| What happens if another device sells the stock during a transfer? | The transaction rereads the current quantity and rejects an unavailable transfer |
| Should zero-stock SKUs fill the Low Stock list? | No. They belong in the Out of stock view |
Why colour-size stock cannot be one combined number
Suppose a wholesaler receives a printed T-shirt in three colours and three sizes. There are 3 pieces of each combination, so the order contains 27 pieces.
Recording only “Mickey Mouse T-shirt — 27 pieces” answers how many pieces exist in total, but not the questions needed to make a sale:
- Is Blue / Medium available?
- How many Red / Large pieces are at Shop 1?
- Did Green / Small sell out?
- Does Blue / Large cost more than the other sizes?
- Which barcode belongs to the packet in the staff member's hand?
Inventory Manager therefore treats the design as one product and the nine combinations as nine SKUs.
| SKU type | Quantity |
|---|---|
| Red / S | 3 |
| Red / M | 3 |
| Red / L | 3 |
| Green / S | 3 |
| Green / M | 3 |
| Green / L | 3 |
| Blue / S | 3 |
| Blue / M | 3 |
| Blue / L | 3 |
| Total | 27 |
The main catalogue still shows one product card, so the user is not forced to scroll through nine repeated names. Opening the product shows the exact colour-size list.
Product-level information versus SKU-level information
Putting information at the correct level prevents inconsistent data.
Information normally shared by the product
- product name;
- supplier item code;
- category;
- HSN code;
- GST rate;
- brand;
- description;
- whether the product appears on My Local Shops; and
- whether its price is shown publicly.
For example, a supplier's item code 6120 may identify the complete shirt design. The HSN and GST rate also normally remain common across Red / S, Red / M and Blue / L.
Information that belongs to each SKU
- colour;
- size;
- system stock code;
- image;
- selling price;
- average landed cost;
- latest purchase cost;
- quantity in total;
- quantity at each location; and
- an optional low-stock threshold override.
Prices are SKU-level because wholesale reality does not guarantee that every size or type sells at one rate. A larger size, premium colour or differently sourced batch may need another selling price.
How system-generated SKUs work
When a new product is created, Inventory Manager generates a shared SKU base using the seller's configured prefix and a unique code. It then appends the entered colour and size.
Illustrative examples are:
MLS-4K2Q9X-RED-S
MLS-4K2Q9X-RED-M
MLS-4K2Q9X-BLUE-L
MLS-4K2Q9X-FREESIZE
The exact generated value will differ, but the principle remains the same:
Shared product base + applicable colour + applicable size = exact SKU
If colour is not relevant, only size is appended. If size is not relevant, only colour is appended. A standalone product can use the base SKU itself.
The SKU field is not manually editable. This protects four connected operations:
- an existing packet keeps the same printed barcode;
- an exact SKU search continues finding the correct product;
- a restock joins the existing stock record instead of inventing another identity; and
- Order Manager and Staff Bill continue deducting from the intended SKU.
Changing a product name or selling price does not require changing its SKU. The SKU identifies the stock type, not the latest display wording.
Preventing duplicate variants
Two rows under the same new product cannot resolve to an identical SKU. If Red / M is entered twice, Inventory Manager asks the user to combine the quantity or correct the colour-size information.
This matters because duplicate Red / M records would create several false answers:
- two barcode labels for one physical type;
- divided quantity in search results;
- an incorrect count of available SKUs;
- split average-cost history; and
- uncertainty about which record an invoice should reduce.
When the same SKU is purchased again, use Restock rather than adding another product or variant.
Images for products and variants
A grouped product uses a representative image on its catalogue card. Each underlying SKU can still retain its own full-size photo and thumbnail.
This produces a practical balance:
- the product list remains compact;
- buyers and staff can recognise the design quickly;
- opening the item reveals the correct image for each colour or type; and
- small screens download thumbnails instead of full-resolution photos for every row.
When an image is changed in Inventory Manager, the versioned image reference lets connected apps and the website request the new file. Cached older images are not treated as permanent merely because the photo URL was once loaded.
Printing barcode labels
Inventory Manager can create a label for an individual SKU from its detail page.
The preview uses the approximate proportions of the supported compact label and can include:
- product name;
- supplier item code, when the owner chooses to show it;
- colour and size;
- shop name and phone, when available and enabled;
- the Code 128 barcode; and
- the human-readable SKU below the barcode.
The owner selects how many copies to print. The default quantity follows the current stock so a newly stocked batch does not require hundreds of taps, and up to 1,000 copies can be entered for one print action.
A compatible Bluetooth label printer must first be paired. Inventory Manager sends native barcode commands to the printer instead of converting the barcode into a blurry screenshot, improving scan reliability on compact labels.
Why Code 128 is used instead of a QR code
The printed stock label represents one exact SKU string. Code 128 is suitable for that linear alphanumeric identifier and works with the app's scanner.
The camera screen may visually resemble a general code scanner, but Inventory Manager currently accepts Code 128 product labels, not arbitrary QR codes. Wi-Fi, payment and website QR codes are ignored rather than being mistaken for inventory.
Scanning a SKU
Scanning follows a short path:
- Open the scanner from Inventory Manager.
- Point the camera at the SKU barcode.
- The app checks whether the scanned text has the expected SKU shape.
- It runs an exact SKU lookup limited to the signed-in seller's products.
- It opens that SKU's Product Detail page.
If scanning was started inside one shop's catalogue, the app also checks that the product belongs to that location context. A product from another location does not silently appear as though it were available in the selected shop.
An exact lookup is both safer and cheaper than running broad searches for the same scanned value. Text search remains the better option when the user knows only part of a name or supplier item code.
Stock across two shops and one godown
One SKU has a seller-wide total and a location breakdown.
Consider Blue / Medium with 120 pieces:
| Location | Quantity before transfer |
|---|---|
| Main Godown | 80 |
| Shop 1 | 25 |
| Shop 2 | 15 |
| Total | 120 |
The owner wants to move 20 pieces from Main Godown to Shop 2.
| Location | Before | Movement | After |
|---|---|---|---|
| Main Godown | 80 | −20 | 60 |
| Shop 1 | 25 | 0 | 25 |
| Shop 2 | 15 | +20 | 35 |
| Total | 120 | 0 | 120 |
The business still owns 120 pieces, so seller-wide Total Units and Stock Worth do not change. The godown's units and stock value decrease while Shop 2's increase.
This distinction is why a location is more than a filter. It is part of every stock-changing decision.
Single-SKU and bulk transfers
Inventory Manager supports two transfer patterns.
Transfer one exact SKU
Open the SKU detail, choose the source, destination and quantity, then save. This is useful when moving only Blue / Medium.
Transfer several variants together
Open the grouped product and choose Transfer. After selecting the source location, the app shows only variants that have stock there. The owner can select several types, enter their quantities or use Select All, and move them in one operation.
For example, a shop may need:
- 5 Red / S;
- 8 Red / M;
- 6 Blue / M; and
- 4 Blue / L.
The owner can transfer all four types without opening four separate product pages.
The source and destination cannot be the same, quantities must be above zero, and no selected quantity can exceed the current stock at the source.
What happens when stock changes on another device?
The quantity shown when a transfer screen opens is not blindly trusted at save time.
Suppose the screen initially shows 10 Blue / M pieces at Shop 1:
- The owner prepares a transfer of 8 pieces.
- Before it is saved, Staff Bill sells 5 pieces from Shop 1.
- The current available quantity is now 5, not 10.
- The transfer transaction rereads the product inside Firestore.
- The request for 8 is rejected with the latest available quantity instead of saving −3 stock.
Firestore can automatically retry the transaction when another valid write happens during the operation. The same shared stock-calculation rules are used by Inventory Manager and the invoice apps, so one app does not calculate stock differently from another.
This protects against conflicting writes; it does not lock the seller to one phone. Owners and authorised staff can continue using the connected system from their permitted devices.
How invoice creation uses location-level SKU stock
Order Manager and Staff Bill first show grouped products, keeping the picker short. After the user selects a product, the invoice screen shows its individual SKUs with availability at the billing location.
If eight types are available and one is sold out:
- the product can still be selected;
- every type remains understandable in the variant list;
- the sold-out type is clearly marked;
- quantity cannot be added beyond the displayed availability; and
- final invoice saving validates stock transactionally again.
This supports the common wholesale pattern of adding several colours and sizes together while preventing an unavailable type from being sold merely because the overall product still has stock elsewhere.
Low stock and out of stock are different states
Inventory Manager uses a default seller-level low-stock threshold, which can be overridden for a complete product group or one SKU.
If the threshold is 5:
| Current quantity | Operational state |
|---|---|
| 8 | In stock, not low |
| 5 | In stock, not below the threshold |
| 4 | Low stock |
| 1 | Low stock |
| 0 | Out of stock, not shown in Low Stock |
Zero-stock products are deliberately excluded from the Low Stock section. In garment and footwear wholesale, many styles are replaced by new designs rather than restocked. Mixing every old sold-out SKU into the daily reorder list would hide the items that genuinely need attention.
The catalogue therefore defaults to In stock and offers explicit Out of stock and All filters for history or restocking.
Product availability when one or all variants sell out
Availability is calculated at both SKU and grouped-product level.
One SKU is sold out
If Red / M reaches zero but Blue / M remains available, the grouped product remains in stock. The exact Red / M type shows out-of-stock information while the other types continue to be usable.
A location sells out but another location has stock
The seller-wide product can remain in stock, but it should not appear as available at the empty location. The shop-specific catalogue and invoice picker use positive-stock location information, not the shop where the product was originally created.
Every SKU sells out
The grouped product leaves normal in-stock browse lists. It remains available in the owner's Out of stock or All view, preserving images, costs, SKU labels and the restock path.
On the public My Local Shops product detail, a published sold-out type can remain understandable to the buyer with clear availability information. Public browsing prioritises products that can currently be supplied so a wholesaler's page does not become a wall of old sold-out fashion.
How location totals remain useful
The shop or godown detail page shows current in-stock SKU count and stock worth for that location. Its product list follows the main catalogue behaviour but is locked to that shop.
Transfers change both sides of the location summary in the same transaction:
- quantity leaves the source;
- the corresponding cost value leaves the source;
- quantity enters the destination; and
- the same cost value enters the destination.
The app maintains location unit and stock-value summaries instead of downloading every SKU and recalculating them whenever the page opens. This keeps Firebase reads predictable while the number of variants grows.
Practical footwear example
A footwear wholesaler stocks one sports-shoe design in Black and White, sizes 6 through 10. That produces ten SKUs:
Black / 6 Black / 7 Black / 8 Black / 9 Black / 10
White / 6 White / 7 White / 8 White / 9 White / 10
The owner receives 20 pairs of each size in the godown, then sends different combinations to two shops according to local demand.
Shop 1 sells more Black / 8 and Black / 9. Shop 2 sells more White / 6 and White / 7. Location-level SKU quantities reveal that difference, whereas “Sports shoe — 200 pairs” cannot.
The owner can:
- print one barcode type for each size-colour SKU;
- scan a returned or counted box to open the exact stock record;
- transfer the fast-selling sizes from the godown;
- give specific sizes a higher low-stock threshold; and
- leave the grouped public product visible while clearly marking unavailable sizes.
Common mistakes to avoid
Creating a separate product card for every size
Use one product with separate SKUs. The product list remains usable and shared HSN, GST, item-code and visibility details stay consistent.
Using the supplier item code as the exact SKU
The supplier code often describes the complete design. A system-generated SKU identifies the precise colour-size stock record.
Reprinting labels after changing only the product name
The SKU remains the same when display details change. Existing labels still identify the stock unless the physical label itself needs refreshed wording.
Moving stock through manual arithmetic
Do not subtract from one location today and remember to add to another later. Use Transfer so both sides and their movement history save together.
Treating total business stock as shop availability
A seller may own 50 pieces but have zero at the billing counter. The invoice must use the selected shop's availability.
Putting sold-out items in the reorder list forever
Use Out of stock for old or seasonal styles and Low Stock for items still available but approaching their active threshold.
Frequently asked questions
Can two SKUs under one product have different prices?
Yes. Selling price and cost are stored per SKU. The grouped product displays a price range when required.
Can two SKUs use the same image?
Yes. A photo may be reused when it accurately represents both types, while another SKU can retain a different photo.
Can a Free Size product be recorded?
Yes. Colour or size can be omitted when not applicable, and values such as Free Size can form part of the generated SKU.
Can I change a generated SKU?
No. The product flows keep it protected so barcode lookup and connected stock writes remain stable.
Does scanning read a manufacturer's barcode?
Only if it exactly follows and matches a SKU stored for that seller—which normally it will not. Inventory Manager's printed labels use its own Code 128 SKU.
Does a transfer change the average cost?
No. A transfer relocates existing stock at its current cost; it does not represent a new purchase. A restock can change the weighted average cost.
Can staff transfer inventory?
Staff Bill is focused on authorised invoice creation. Inventory management, costs and transfers remain in the owner's Inventory Manager workflow.
What happens if a shop has zero stock but the godown has stock?
The product remains available to the business, but the shop-specific catalogue and invoice flow do not treat godown quantity as if it were physically at that shop. The owner can transfer the required quantity first.
Continue with the connected workflow
- Download and view Inventory Manager
- Read the complete Inventory Manager guide
- See how all four apps share the same business data
- Compare current plans and location limits
- Set up your first shop or godown
The next guide will explain how published inventory becomes a real-time digital wholesale shop, including price visibility, stock visibility, buyer inquiry and WhatsApp contact.