Where the style, colour and size matrix breaks a generic ERP
The matrix is a data model question, not a naming convention. Either the system can address one style with colour and size as dimensions of it, or every combination becomes a separate record in the item master. The second option looks workable during a demonstration and becomes unmanageable in a live season, because the item master grows with every colourway a buyer asks for and nobody can maintain costing, reorder levels or minimum stock across a list that changes constantly.
Downstream everything inherits the choice. Buyers order by size ratio rather than by individual size, so an order line has to behave like a grid. Cut planning, allocation and packing all work across the matrix at once. Stock enquiries have to answer both at style level and at combination level, and the warehouse needs a barcode at the combination while planning stays at the style. A system that cannot hold both levels forces the business to keep one of them in a spreadsheet, which is where the errors start.
Selection is the moment to test this properly, using your own style list rather than the sample data supplied with the product. Enter a real order with a real ratio. Look at the stock enquiry. Run a costing and see what level it is held at. Some products handle the matrix natively, some handle it through a textile extension that is genuinely mature, and some cannot do it without an item code explosion. Finding out during selection costs a day. Finding out after go live costs a rebuild.
- Style, colour and size held as attributes of one item rather than as separate item masters
- Order lines entered as a grid with a size ratio, not as a list of individual sizes
- Barcodes issued at the combination level while planning stays at style level
- Stock, costing and reporting answerable at both style and combination level
- Selection testing done with your own styles and a real buyer order