Apparel Matrix Item & Size-Colour Manager

The problem

Apparel businesses do not sell items. They sell styles, and every style explodes into a grid of sizes and colours that NetSuite stores as a flat list of matrix child items. A single style in six colours and eight sizes becomes forty-eight inventory items. Merchandisers who think in grids are forced into a record-by-record interface: adding a new colourway means creating child items one at a time, entering a sales order for a size run means adding forty-eight lines, and answering "how much of style AW-4471 do I have across all sizes?" means running a saved search and pivoting the results by hand.

The consequences compound through the season. Pre-packs and assortments — a carton containing 2 smalls, 3 mediums, 3 larges and 2 extra-larges — have no native representation, so they get keyed as separate lines and the pack ratio drifts. Season and drop are tracked in a text field somewhere, or in a spreadsheet, so "show me all Spring/Summer 26 styles still open on purchase orders" is not a question NetSuite can answer without custom work. Size curves live in the buyer's head. Open-to-buy is reconciled outside the system. And in a OneWorld account with multiple subsidiaries and channels, the same style gets set up slightly differently in each one.

None of this is a defect in NetSuite. Matrix items work exactly as designed; they simply present a two-dimensional merchandising problem through a one-dimensional record interface. Closing that gap is what every serious fashion implementation ends up building.

What ECOSIRE builds

This is a build-to-order NetSuite customization. Nothing is pre-packaged and nothing downloads instantly — we scope your assortment structure, agree a fixed price, then build the application against your account and install it.

Style and grid management

A custom record for Style sits above the matrix parent item and carries the merchandising attributes NetSuite has no home for: season, drop, delivery window, brand, department, class, silhouette, fabric, country of origin and cost band. A Suitelet-based grid editor renders the size-by-colour matrix as an actual grid. Entering a new colourway is one row; the script generates the matrix child items through the record API with your naming convention, item pricing, UPC/GTIN assignment, inventory preferences, units of measure and subsidiary restrictions applied consistently — instead of forty-eight manual creations.

Matrix option lists are managed as custom lists or custom segments (your choice at scoping — custom segments let the grid attributes flow through to GL impact and reporting; custom lists are lighter). Size scales are defined once (Numeric 28–44, Alpha XS–XXL, Kids 2–14, EU shoe 36–46) and reused, so a style is assigned a scale rather than having its sizes typed in.

Pre-packs and assortments

A custom record defines a Pre-Pack — a named ratio of sizes within a colour, or across colours — and a User Event script on the transaction expands it at line level. The buyer enters "12 packs of AW-4471 Navy, ratio B" and the sales order, purchase order or transfer order is written with the correct per-size quantities. The pack identity is retained on a custom line column so the document can be printed, picked and reported at pack level even though inventory moves at SKU level. Where you assemble packs physically, the build can instead drive assembly/kit items so the pack is a stocked entity.

Season and assortment planning

A planning Suitelet works from the size-curve records: enter a total buy quantity for a style, apply a curve (historic, or manually set), and the system distributes across sizes and colours, then writes the result to purchase orders or to a plan record for review. Saved searches and a SuiteAnalytics dataset roll inventory, on-order, sold and returned quantities up from child item to style, colour and size so the grid view answers stock questions without a manual pivot.

Integration points

A Map/Reduce script handles bulk operations — mass price changes across a season, bulk item creation from a supplier's line sheet, end-of-season markdown application — without hitting governance limits. RESTlets expose style, grid and pre-pack data so your PLM, 3PL, EDI translator or e-commerce platform can read the assortment structure in grid form rather than reconstructing it from item names. SuiteFlow drives the style lifecycle: Development → Approved → Active → Markdown → Discontinued, with the approvals and field locking your process requires.

Who this is for

Apparel, footwear and accessories brands running NetSuite as their system of record, particularly those with multi-channel distribution (wholesale, retail, DTC) or a OneWorld structure where the same style is sold from several subsidiaries. It suits businesses with at least a few hundred active styles, where manual matrix maintenance has become a named person's full-time job. It is equally relevant to a first NetSuite implementation, where getting the item architecture right at the start avoids a painful re-platform later.

How delivery works

1. Scoping call. We walk through your item architecture as it exists today — matrix parents, naming conventions, size scales, how pre-packs are handled now, which subsidiaries and channels are involved, and what your PLM or line-sheet source looks like. We agree what the grid editor must do and what stays native.

2. Fixed quote. You receive a written scope and a fixed price before anything is built. Changes after that point are quoted separately, not absorbed silently.

3. Build. Development happens as an SDF project using SuiteScript 2.1 — Suitelets for the grid and planning screens, User Event and Client scripts for transaction behaviour, Map/Reduce for bulk work, custom records and custom segments for the data model. Source is version-controlled and delivered to you.

4. Install in sandbox. The bundle is deployed to your sandbox or a Release Preview account first. You test against your own data — real styles, real size scales, real purchase orders — and we iterate on what surfaces.

5. Install in production. Once you sign off in sandbox, we deploy to production during an agreed window, configure roles and permissions, and verify with you live.

6. Support window. A defect-fix support period follows go-live. You own the SDF project and the unmanaged bundle outright — there is no runtime licence and no dependency on us to keep it working.

Typical lead time is two to four weeks from signed quote to production install, depending on scope and on how quickly sandbox feedback comes back.