Best Practices - Fashion & Textile
Operational guidelines for developers building AI/RAG, e-commerce, PLM or recommendation systems in the fashion and textile sector.
---
Model the product hierarchy with at least 5 levels
Implement the structure: Brand → Season → Collection → Style/Model → Variant (colour) → SKU (size). Do not flatten the levels: losing the distinction between style and SKU causes serious problems in inventory and reporting. Each level has its own attributes (the style has a design, the variant has a colour, the SKU has stock).
---
Use immutable, unique SKU codes
The SKU is the atomic inventory code. Never change it after creation: any modification breaks the sales history and integrated systems. Use structured schemes (e.g. STYLE-COLOUR-SIZE) to enable automatic parsing and fast search. Manage obsolete SKUs with a "discontinued" status rather than physical deletion.
---
Manage sizes as data, not as constants in the code
Size systems vary by brand, country, category and season. Never hardcode sizes in the code: load them from configuration (dimension tables). Maintain international conversion tables. For applications with global users, always display sizes in the user's local system.
---
Separate sales channels at the data level
Wholesale, retail, e-commerce, outlet and duty-free have separate pricing, stock and visibility rules. Model the channel as a distinct entity in the domain, not as a flag on the product. A garment can have different prices per channel (wholesale price ≠ retail price) and separately allocated stock.
---
Implement time-to-live for the seasonal catalogue
Fashion products have a limited commercial life. Implement activation and expiry dates for each article. Use nightly batch processes to activate/deactivate articles based on current date and season. Do not physically delete expired products: archive them to maintain order and returns history.
---
Design the markdown engine with configurable rules
Markdowns (price reductions) follow precise business rules: percentage reduction by garment age, sell-through level, season. Do not hardcode these rules. Implement a pricing rule engine that applies reductions automatically while maintaining price history for each SKU.
---
Track sell-through at all levels of the hierarchy
Monitor sell-through (% sold/bought) not just in total but across the hierarchy: by season, collection, category, style, colour, size. Bottlenecks are often on specific sizes or colours. Aggregate dashboards that hide this granularity lead to wrong buy decisions.
---
Implement production overage management
Production always generates a percentage of surplus garments (3–5%) to cover defects. Systems must track: ordered quantity, produced quantity, QC-passed quantity, shipped quantity. Overage is not an error but standard industry practice; do not flag it as an anomaly in reports.
---
Validate fibre composition with regular expressions
Fibre composition must sum to 100%. Always validate: the sum of declared percentages must be exactly 100 (tolerance: ±1% for rounding). Also implement formal validation: fibres must be named according to the terminology of EU Regulation 1007/2011.
---
Use versioning systems for tech packs
Tech packs evolve during development. Implement versioning (v1, v2, draft, approved) with author and date of each modification. The "approved" version is the one in production; previous versions are the audit trail. Never overwrite the approved version: create a new version.
---
Manage lead times as probabilistic distributions
The lead time declared by the supplier is often ideal. In planning systems, use historical distributions (mean ± standard deviation) rather than fixed values. Add buffers for known events: Chinese holidays, demand peaks, seasonal logistics issues. Calculate "worst case" dates for distribution planning.
---
Implement supply chain traceability with document hashes
For compliance (CSDDD, GOTS/Oeko-Tex certifications), store supply chain documents (certificates, declarations of conformity, audit reports) with cryptographic hashes to guarantee immutability. Structure the data to enable queries such as "show me all tier-2 suppliers with an active GOTS certificate".