Series: The Complete WMS Implementation Guide | Post 3 of 17
The Unsexy Truth About WMS Implementations
Every WMS vendor will show you slick demos of real-time dashboards, directed picking, and automated putaway. What nobody wants to talk about is master data.
Here's the reality: your WMS is only as intelligent as the data you feed it. We've seen implementations at Groupe GCL where the software was configured perfectly, the hardware was ready, the team was trained, and the go-live still stumbled because the product master data was incomplete, inconsistent, or flat-out wrong.
Master data is the foundation layer. Get it right, and every downstream process (receiving, putaway, picking, shipping, cycle counts) works as designed. Get it wrong, and you spend months firefighting issues that never should have existed.
This post walks through every critical product data field you need to configure in your WMS before go-live, why each one matters operationally, and how Flowtrack Web handles each configuration. If you're preparing for a WMS implementation, treat this as your checklist.
What Is Product Master Data in a WMS Context?
In ERP terms, a product master is the central record for a SKU: description, cost, price, vendor, accounting codes. Your WMS needs all of that, plus a layer of physical and logistical attributes that your ERP typically doesn't capture.
Think of it this way: your ERP knows that SKU-2009 is "Amoxicillin 500mg, 100-count bottle" and that it costs $14.50. Your WMS needs to know that it weighs 0.34 kg, fits in a bin 30 cm wide, requires temperature-controlled storage, has a lot number and expiry date, must be picked FEFO, and lives in zone B, aisle 3, level 2.
That second layer of data is what makes directed warehouse operations possible. Without it, your WMS is just an expensive inventory list.
1. SKU Identification
Every product needs a unique, unambiguous identifier. This sounds obvious, but it's where many implementations hit their first snag.
What to configure: internal SKU code (your primary identifier), UPC/EAN barcode (for scanning at receiving and picking), vendor part number (for cross-referencing on POs), customer part number (for cross-referencing on orders, especially in 3PL environments), and alternate barcodes (inner pack, case, pallet, each with their own GTIN).
Why it matters: if your barcode strategy doesn't align with your SKU structure, your operators will hit "item not found" errors every time they scan. This is the number one complaint in the first week post go-live when master data is incomplete.
Common pitfall: companies that sell the same product in different packaging (eaches, inner packs, cases) often create separate SKUs for each. This works, but you lose visibility into total inventory across all pack sizes. A better approach is to use a single SKU with multiple units of measure.
2. Units of Measure (UoM)
This is the field most frequently misconfigured in WMS implementations. Units of measure define how you receive, store, count, and ship a product, and they need to reflect your real operational reality.
What to configure: base unit of measure (the smallest countable unit, e.g., "each"), purchase UoM (how you receive from vendors, e.g., "case of 24"), storage UoM (how it sits on the shelf), sales/pick UoM (how you ship to customers), and conversion factors between each level.
When a purchase order says "receive 10 cases" and each case contains 24 units, your WMS needs to know that receiving 10 CS means adding 240 EA to inventory. If the conversion is wrong or missing, your inventory counts will be off from day one.
More importantly, UoM drives picking logic. If an order calls for 30 eaches and your cases hold 24, a well-configured WMS will direct the picker to grab 1 case + 6 eaches (or 5 inner packs if the inner pack holds 6). That's only possible if the UoM hierarchy and conversions are correct.
Common pitfall: ignoring inner packs. Many companies configure only "each" and "case" and skip the intermediate pack level. This forces operators to break open cases for small orders when an inner pack would be faster and keep the case intact.
3. Physical Attributes
Your WMS uses physical dimensions and weight to make decisions about storage, slotting, and shipping. Without them, directed putaway and cartonization are impossible.
What to configure: weight (per base UoM and per case/pallet), dimensions (length, width, height per base UoM and per case/pallet), volume, stackability, and fragility flag.
Directed putaway uses dimensions to determine whether a product fits in a given location. If you receive a pallet of oversize items and the WMS doesn't know the dimensions, it will suggest a standard pallet slot, the pallet won't fit, and the operator will override the system and put it wherever they want. That's the start of location inaccuracy.
Common pitfall: entering dimensions for the "each" but not for the "case." Your WMS needs physical attributes at every UoM level, because putaway and picking happen at different levels.
4. Lot Control and Traceability
For industries like food, beverage, pharmaceuticals, chemicals, and cosmetics, lot traceability isn't optional. But even general distributors benefit from lot tracking for warranty management, vendor quality issues, and recall readiness.
If lot tracking is enabled, every inventory movement (receiving, putaway, picking, adjustment, transfer) must capture the lot number. This creates a complete audit trail from receipt to shipment.
For pharma and food clients, this is a regulatory requirement. But even outside regulated industries, lot tracking gives you the ability to identify exactly which customers received a specific batch if a quality issue arises. Without it, a supplier recall becomes a warehouse-wide problem instead of a targeted one.
Common pitfall: enabling lot tracking after go-live. Retroactively assigning lot numbers to existing inventory is painful and error-prone. If there's any chance you'll need lot tracking in the next 2 to 3 years, enable it from the start and enforce it during receiving.
5. Expiry Date Management
Expiry management builds on lot control but adds a time dimension that directly affects picking logic and inventory valuation.
What to configure: expiry tracking enabled per SKU, shelf life (total days from manufacture to expiry), minimum remaining shelf life for receiving (e.g., won't accept product with less than 180 days remaining), minimum remaining shelf life for shipping (e.g., won't ship product with less than 90 days remaining), and allocation rule (FEFO vs. FIFO).
FEFO picking ensures you ship the oldest-expiring stock first, minimizing waste and write-offs. But FEFO only works if the expiry date is captured at receiving and associated with the lot.
The "minimum remaining shelf life" rules are critical for both inbound and outbound. On the receiving side, they prevent you from accepting stock that's already too close to expiry. On the shipping side, they protect your customers from receiving short-dated product.
Common pitfall: setting a single shelf-life threshold instead of separate inbound and outbound minimums. Your receiving threshold should always be higher than your shipping threshold.
6. ABC Velocity Classification
Not all SKUs are created equal. ABC classification segments your products by movement velocity, and it drives storage strategy, pick location assignment, count frequency, and replenishment priority.
What to configure: velocity class (A high movers, B medium, C slow movers, D dead stock), classification method (by order lines, units picked, revenue, or a combination), and reclassification frequency.
A-class items should live in the most ergonomic, accessible pick locations (waist height, close to the packing station). C and D items can go to upper reserve or less accessible zones. This is the foundation of warehouse slotting.
It also drives cycle count frequency. A-items get counted weekly or bi-weekly. D-items might only get counted quarterly. Without the classification, you're either counting everything at the same frequency (wasteful) or counting nothing systematically (dangerous).
Common pitfall: setting ABC classification once during implementation and never updating it. Demand patterns change seasonally, with promotions, and with product lifecycle shifts. Build a process to reclassify quarterly, or at minimum, twice a year.
7. Storage Requirements and Handling Instructions
Some products need specific storage conditions. Your WMS needs to know about them to make correct putaway and allocation decisions.
What to configure: storage zone restrictions (ambient, refrigerated, frozen, hazmat, high-value, bonded), temperature range requirements, hazardous materials classification (WHMIS/TDG class, UN number), and special handling instructions (e.g., "keep upright," "do not stack," "requires 2-person lift").
If a product is flagged as refrigerated, directed putaway will only suggest locations within the refrigerated zone. Without this flag, there's no guardrail preventing an operator from putting temperature-sensitive product in a dry ambient area.
Common pitfall: relying on tribal knowledge for storage rules instead of encoding them in the system. The experienced operators know that SKU-4021 needs to stay cold. The temp worker on a Saturday shift does not.
8. Replenishment Parameters
These parameters tell your WMS when and how to refill pick locations from reserve storage.
What to configure: replenishment trigger (min/max, demand-based, or top-off), minimum quantity (trigger point), maximum quantity (how much to bring forward), replenishment UoM, and fixed pick location assignment.
Without replenishment parameters, your pick locations run dry during peak periods, and pickers waste time hunting for stock or waiting for replenishment. With proper min/max settings, the WMS generates replenishment tasks automatically, keeping pick locations stocked without overfilling them.
Common pitfall: setting min/max based on gut feeling instead of data. Analyze your average daily picks per SKU, multiply by your replenishment cycle time, and add a buffer. That's your minimum. Your maximum is constrained by the physical capacity of the pick location.
The Master Data Migration Checklist
Before go-live, every product in your WMS should have the following fields validated: SKU code and description (critical, source ERP), UPC/EAN barcode (critical), UoM hierarchy and conversions (critical, operations team and vendor specs), weight and dimensions per UoM (high priority, vendor specs or physical measurement), lot tracking flag (high priority), expiry tracking and shelf life rules (high priority if applicable), ABC velocity class (high priority), storage zone restrictions (high priority), replenishment min/max (medium priority).
Pro tip from GCL: don't try to migrate all fields for all SKUs at once. Start with your A and B items (typically 20% of SKUs covering 80% of movement). Get those fully configured and validated. Then extend to C and D items in phases. A partial but accurate master data set is infinitely better than a complete but error-filled one.
How Flowtrack Web Handles Product Master Data
Flowtrack Web organizes product configuration across several tabs within the product master screen: General (SKU identification, description, product family, status), Units of Measure (full UoM hierarchy with conversion factors and barcode assignment per level), Physical (weight, dimensions, volume, and stackability by UoM level), Traceability (lot control toggle, lot format, expiry tracking, shelf life rules, FEFO/FIFO selection), Storage (zone assignment, temperature requirements, handling instructions, hazmat flags), Velocity (ABC classification with manual override and system-calculated recommendation), and Replenishment (min/max parameters, trigger type, fixed pick location assignment).
Each tab feeds directly into the operational modules. The traceability settings drive the receiving and picking workflows. The storage settings drive putaway logic. The velocity classification feeds the analytics dashboards and slotting recommendations.
This isn't accidental. It's designed so that every configuration decision you make at the product level has a downstream effect on warehouse execution, without requiring manual intervention or workarounds.
Common Mistakes and How to Avoid Them
1. Copying ERP data without enrichment. Your ERP product master is a starting point, not a destination. It gives you SKU, description, and maybe a barcode. Everything else (UoM hierarchy, physical attributes, lot rules, velocity class, storage zones) needs to be added by your warehouse operations team before the data goes into the WMS.
2. Skipping the physical measurement step. Yes, it's tedious to weigh and measure 2,000 SKUs. Yes, it's necessary. Set up a measurement station with a calibrated scale and tape measure. Run through your top 200 items first (your A-movers). Delegate the rest to a team over 2 to 3 weeks. Vendor spec sheets can supplement, but verify a sample, because stated dimensions don't always match reality.
3. Not validating barcode uniqueness. If two different products scan to the same barcode, you have a data integrity problem that will cascade through every transaction. Run a uniqueness check on all barcodes before go-live. Flowtrack Web flags duplicates during import, but catching them earlier saves time.
4. Ignoring the "boring" SKUs. Companies obsess over configuring their top sellers and neglect the long tail. The problem is that C and D items are where most receiving and putaway errors happen, precisely because nobody bothered to set up their data properly. Give them at least the minimum: correct UoM, a valid barcode, and the right storage zone.
5. Treating master data as a one-time project. New products come in. Vendors change packaging. Customers request new formats. Master data is a living process, not a go-live task. Assign ownership (typically a warehouse coordinator or inventory analyst) and build a monthly review cadence into your operations.
What's Next
With product master data configured, the next step is location architecture: how to design your warehouse's digital blueprint with zones, location types, capacity rules, and velocity-based slotting. That's Post 4 in this series.
Together, product data and location data form the two pillars of your WMS foundation. Everything that follows (receiving, putaway, picking, shipping, analytics) depends on both being complete and accurate.
This post is part of "The Complete WMS Implementation Guide," a 17-part series by the Flowtrack Web team at Groupe GCL. Each post walks through a step of the WMS implementation lifecycle with practical guidance and real Flowtrack Web configuration examples.