Q360's product master is the most abused table in your ERP.
Every AV integrator's Q360 instance has the same problem, sooner or later: the product master is a mess. Ten years of vendor pricelist imports, manual overrides, duplicate parts, inconsistent manufacturer names, end-of-life items nobody flagged, and wrong item types that break quoting.
Nobody notices until they're running a quarterly inventory count, generating a sales margin report, or trying to merge two Q360 instances after an acquisition. Then it becomes urgent, painful, and expensive.
Product masters degrade slowly. Each individual import adds "just a few" duplicates or weird entries. Over a decade that's tens of thousands of broken records — enough to quietly kill reporting accuracy and slow every quote.
What "clean" actually means.
Before you can fix a product master, you have to agree on what fixed looks like. In our practice, a clean Q360 masterno database has five properties:
Dedup. Collision-free. Normalized manufacturer names. EOL-aware. Correctly typed. That's the whole bar.
1. Deduplication.
The most common issue: the same physical part exists as multiple Q360 masternos. Usually because someone imported the same vendor pricelist twice with slightly different formatting, or two different vendors listed the same item under different numbers.
- Symbol variations — hyphens, underscores, slashes, spaces all get normalized before comparison
- Manufacturer dictionary lookups — we resolve "Crestron", "Crestron Electronics", "CRES", and "Crestron Inc" to a single canonical value before matching
- Vendor part numbers — cross-reference vendor-supplied part numbers to catch cases where different customers use different internal numbers for the same product
- UPC comparison — the gold standard when available; two rows with the same UPC are the same part, period
2. Collision prevention.
The opposite problem of duplication: two different manufacturers share an identical part number. Without intervention, the second import overwrites the first, or they collide in quoting. Our convention is a 3-letter manufacturer prefix applied to both conflicting parts — e.g. "CRE-MC-125" vs "EXT-MC-125" — so both can coexist in the master without ambiguity.
3. Manufacturer normalization.
Customer-facing documents and reports need consistent manufacturer names. We maintain a master dictionary of canonical manufacturer spellings (with customer-specific preferences where they matter — some customers want "Samsung Electronics America," others just "Samsung"). Every import is normalized against the dictionary on the way in.
4. End-of-life management.
Discontinued items shouldn't just disappear from the master — some customers still have stock on the shelf or open projects using them. We flag EOL items in a dedicated tracking field that carries:
- When the manufacturer announced EOL
- Current stock level across all warehouses
- Suggested replacement part (if the manufacturer published one)
- Date after which the item should be automatically deactivated (usually when stock hits zero)
5. Correct item typing (A / Q / K).
Q360 uses item types to distinguish serialized equipment (A-type), non-serialized stocked goods (Q-type), and kit/bundle items (K-type). Bulk imports frequently mis-type items because the vendor didn't mark them — a rackmount switch imported as Q-type instead of A-type creates problems at project delivery when the install tech needs the serial-number field that only exists on A-type items.
We use a workflow bucket concept during bulk imports: items go into a pending bucket first, get auto-classified by rules, and then get human-reviewed before committing to the master. Catches 99% of typing errors before they hit production data.
The three cleanup actions.
How we do the work.
- Data pull. We extract the current product master (usually hundreds of thousands of rows) along with the transaction history — POs, quotes, invoices — that references each item.
- Rules run. Our cleanup engine applies deduplication, collision detection, manufacturer normalization, EOL flagging, and item-type validation. Produces a report of every proposed change.
- Human review. Your Q360 admin reviews the proposed changes — usually focused on high-impact items and ambiguous cases — and approves, edits, or rejects each one.
- Staged execution. We apply approved changes against a Q360 staging copy first, validate no transactions broke, then replay against production during a quiet window.
- Post-cleanup report. You get a full log of what was merged, renamed, or retyped, with before/after counts and a list of items that couldn't be auto-resolved (need manual decisions).
Frequently asked questions.
Depends on the size of the master and the amount of historical data. A 50k-item master with moderate dupes can land in 2-3 weeks. A 500k-item master after an acquisition can take 2-3 months, mostly because of the human-review phase for edge cases.
No. Every proposed change is validated against open transactions before execution. If a merge would break an active quote, we either defer it until the quote closes or route it through a manual-review queue.
Both. Most clients start with a one-time cleanup, then switch to ongoing maintenance — we process incoming vendor pricelists through the same normalization pipeline so new imports don't re-introduce the problems we just fixed.