Apparel and Footwear Style Matrix

Apparel and footwear businesses do not sell items. They sell styles, and a style only becomes sellable when it is broken into a grid of colours and sizes. SAP Business One models the bottom of that grid perfectly well — every colour and size permutation is a legitimate row in the item master with its own stock, cost, barcode and valuation — but it gives merchandisers no way to work at the top of it. A six-colour style on a ten-size scale is sixty item codes to create, sixty rows to key into a sales order, and sixty lines to read when a buyer asks how the size curve is selling.

The consequences are consistent across the sector. Item codes get created by hand or by a spreadsheet macro, with naming conventions that drift the moment two people are creating them. Order entry takes minutes per style instead of seconds, and a wholesale order for twelve styles becomes a data-entry exercise rather than a commercial conversation. The size curve lives in Excel. Prepacks and ratio packs are exploded manually, so the pack the customer bought is no longer visible anywhere in the document trail. Allocation of constrained stock across wholesale customers happens outside the ERP entirely, then gets typed back in. Stock is accurate in SAP Business One and effectively unreadable at the level the business actually plans.

What ECOSIRE builds

We build a style-matrix layer that sits on top of standard SAP Business One objects rather than replacing them. Every SKU generated is a real item master row. Every document the matrix writes is a real Sales Quotation, Sales Order, A/R Invoice, Purchase Order or Goods Receipt PO created through the Service Layer, so price lists, special prices, tax determination, approval procedures, serial and batch handling, and the general ledger all behave exactly as SAP Business One intends. There is no shadow document table, and no reporting that only works if you use our screens.

Style master and SKU generation

A Style user-defined object holds the merchandising record: style number, description, brand, supplier, season, colourway list, size scale, target cost, target RRP and lifecycle status. Generating a style writes the colour and size permutations into the item master through the DI API or Service Layer, stamping user-defined fields for style, colour, size, size index, size scale, season and range on every row, and applying the item group, valuation method, planning data, unit-of-measure group and default warehouses defined on the style template. Regeneration is additive and idempotent, so adding a colour in week six does not disturb the SKUs already trading.

Matrix entry on real documents

The grid is where the time is saved. A user picks a style, sees a colour-by-size matrix with available stock and open supply per cell, keys quantities, and the add-on posts the corresponding document lines. Because the write goes through the standard document object, an order raised in the matrix is indistinguishable downstream from one keyed line by line — it picks, packs, invoices and posts the same way, and appears in every standard SAP Business One report.

Size scales, packs and prepacks

Size scales are held in user-defined tables with an explicit size index, so every grid, pick list and report renders small-to-large rather than alphabetically. Pack and prepack definitions describe the ratio of sizes inside a carton; on order entry or at picking the pack explodes into its component SKUs while retaining the pack reference on the line, so customer service can still answer what was actually ordered.

Seasonal range planning

Seasons and collections are first-class records. Styles move through a lifecycle you define — concept, development, adopted, carryover, dropped — with drop dates, option counts and range-level views that let a buyer see the shape of a season without opening sixty item records. Markdowns, RRP overrides and off-range selling can be routed through the standard SAP Business One approval engine.

Allocation and stock visibility

When supply is short, the allocation workbench spreads available stock across open sales orders by size curve, customer priority and requested delivery date, then writes inventory transfer requests or reservations against those orders. A style-level stock enquiry aggregates warehouse stock into a colour-by-size grid per location, including quantities on order from open purchase orders and in transit, so the answer to how many mediums in navy takes one screen rather than ten.

Reporting

Crystal Reports layouts are deployed into the SAP Business One report tree: style sheet, size-curve sell-through, colour performance, allocation summary and open orders by style. Because the underlying data is standard document and item data plus our user-defined fields, your own reporting tools can read it too.

Who this is for

Apparel brands and wholesalers running SAP Business One who are creating SKUs by hand. Footwear distributors managing multiple size scales across regions. Uniform, workwear and PPE suppliers with colour and size variants against contract price lists. Vertically integrated retailers whose buying team plans at style level while the ERP only speaks SKU. It suits businesses that already trust SAP Business One for finance and stock and want the merchandising layer to stop living in spreadsheets.

How delivery works

This app is built to order. Nothing is downloaded and nothing is pre-installed.

1. Scoping call. We walk through your current style numbering, size scales, seasons, pack structures, price list strategy and warehouse layout, and look at a live example of how a style is created and sold today. We agree what is in scope and what is deliberately excluded. 2. Fixed quotation. You receive a written scope and a fixed price before any build work begins. If the scope changes later, the change is quoted separately — there is no open-ended time-and-materials meter. 3. Build. Typical lead time is two to four weeks from acceptance, depending on the number of size scales, whether pack explosion and allocation are in scope, and how much existing SKU data needs to be mapped back to styles. 4. Install in test. We install into your test company database first, including all user-defined field, table and object creation scripts, and load a representative sample of your own styles. Your team validates order entry, picking, invoicing and reporting against real data. 5. Install in production. Once signed off, we schedule the production install and cutover with your team, run post-install verification, and stay on the call while the first live documents are raised. 6. Support. A defect-fix window follows go-live, with an optional annual support and upgrade agreement after that.

After go-live

The add-on is delivered per tenant, licensed to your company, with source code and documentation handed over. It runs against SAP Business One 10.0 on Microsoft SQL Server or SAP HANA, on premise or cloud-hosted, and is re-validated against your environment when you apply a feature pack or upgrade. Because it writes standard objects, if you ever stop using the matrix screens your data remains complete and usable in the SAP Business One client.