Fashion Industry ERP System

Java Developer · 2020 · 14 months · 5 people · 4 min read

Automated the end-to-end ordering and inventory tracking process for a fashion company, reducing manual data entry by 70% and cutting order processing time in half

Overview

An enterprise resource planning system tailored for the fashion industry, automating the lifecycle of product ordering, inventory tracking, supplier management, and fulfillment across seasonal collections and multiple warehouses.

Problem

The fashion company managed ordering and inventory tracking through a patchwork of spreadsheets, email threads, and manual data entry. Seasonal collection launches created massive spikes in order volume that overwhelmed the manual process, leading to duplicate orders, missed supplier deadlines, and inaccurate inventory counts that caused both overstock and stockout situations.

Constraints

  • Tight 14-month timeline to deliver before the next major seasonal collection launch
  • Complex business rules around sizing, colorways, and seasonal availability that varied by supplier
  • Integration with existing supplier spreadsheet formats that could not be changed
  • Small team of 5 developers requiring efficient task allocation and minimal coordination overhead

Approach

We built the ERP system using Spring Boot with a clean domain model that captured the fashion-specific concepts of collections, styles, colorways, and size runs. Apache POI handled the heavy spreadsheet import/export requirements, allowing the system to ingest supplier catalogs and generate purchase orders in the formats suppliers expected. We used a BDD approach with Cucumber to ensure business rules were validated by domain experts.

Key Decisions

Used Apache POI for all spreadsheet processing rather than CSV-based interchange

Reasoning:

Suppliers and internal teams relied heavily on formatted Excel files with multiple sheets, formulas, and conditional formatting. CSV would have lost critical context and required manual reformatting, defeating the automation purpose.

Alternatives considered:
  • CSV import/export with a separate formatting step
  • Google Sheets API integration for cloud-based collaboration

Adopted Cucumber BDD for business rule validation

Reasoning:

Fashion ordering rules around size curves, minimum order quantities, and seasonal availability were complex and best validated by non-technical domain experts. Cucumber scenarios written in Gherkin served as both executable specifications and living documentation.

Alternatives considered:
  • Traditional JUnit-only testing with domain expert review of test names
  • Manual QA testing against written business requirements

PostgreSQL with a normalized schema modeling fashion domain entities

Reasoning:

The relational model naturally captured the hierarchical relationships between collections, styles, colorways, and sizes. PostgreSQL's JSONB columns gave us flexibility for supplier-specific metadata that varied across vendors.

Alternatives considered:
  • MongoDB for flexible schema to handle varying supplier data structures
  • MySQL for team familiarity

Tech Stack

  • Java 11
  • Spring Boot
  • Spring REST
  • Spring MVC
  • JDBC
  • PostgreSQL
  • Apache POI
  • JUnit 5
  • Mockito
  • Cucumber
  • Jenkins

Result & Impact

  • 70% decrease through automated spreadsheet processing
    Manual Data Entry Reduction
  • Reduced from 4 hours to under 2 hours per collection
    Order Processing Time
  • Duplicate and erroneous orders reduced by 90%
    Order Accuracy
  • 120+ Cucumber scenarios covering all business rules
    BDD Test Coverage

The ERP system transformed the company's ordering process from a stressful, error-prone sprint into a controlled, predictable workflow. The buying team could focus on strategic decisions rather than spreadsheet wrangling, and the automated validation caught sizing and quantity errors before orders reached suppliers.

Learnings

  • BDD with Cucumber is extremely valuable when business rules are complex and domain experts need to validate logic directly
  • Apache POI is powerful but resource-intensive with large spreadsheets. Streaming APIs (SXSSFWorkbook) are essential for export operations over a few thousand rows
  • Fashion domain modeling is surprisingly complex. Size runs, colorway matrices, and seasonal availability create combinatorial challenges that benefit from careful upfront domain design

Technical Deep Dive

The spreadsheet processing pipeline was the most technically involved component of the system. Supplier catalogs arrived as multi-sheet Excel workbooks with inconsistent formatting across vendors. We built a configurable import engine using Apache POI that mapped each supplier’s spreadsheet layout to our normalized domain model through supplier-specific configuration profiles. The engine validated incoming data against business rules (minimum order quantities, valid size ranges, active colorways) and produced detailed error reports that the buying team could review before committing an import. For export, we used POI’s streaming API to generate purchase order workbooks that included per-supplier formatting, embedded size curve calculations, and conditional highlighting for items requiring attention.

The Cucumber test suite became one of the most valuable assets of the project. Scenarios like “Given a spring collection with 3 styles, When I generate a purchase order for supplier X, Then the order should include size runs S-XL for women’s styles and 38-46 for men’s styles” made the complex ordering logic transparent to the entire team. We maintained over 120 scenarios that covered the full matrix of business rules, and the buying team actively participated in writing new scenarios when they identified edge cases. This approach caught several subtle bugs in size curve calculations that would have been nearly impossible to detect through traditional unit testing alone.

The system was built on a clean REST API with Spring MVC, which allowed us to develop the backend and frontend somewhat independently within our small team. Jenkins handled our CI/CD pipeline, running the full JUnit and Cucumber test suites on every commit and deploying to staging automatically. The PostgreSQL schema was designed with careful attention to the fashion domain’s inherent hierarchies, using foreign key constraints and check constraints to enforce data integrity at the database level in addition to application-layer validation.

All projects