The Paper Problem

Fabric receipt, batch tracking, outside processing, gate passes, and issuance all create records that have to agree. When those records live across paper registers and separate files, finding the current state becomes slow and error-prone.

The goal was not to replace every human decision. It was to create a reliable path from a physical stock movement to a searchable operational record.

Why ERPNext

I evaluated a few options. SAP and Oracle were way out of budget. Custom-built systems would take months. ERPNext hit the sweet spot:

  • Open source with no license fees
  • Python-based so I could write custom scripts
  • Built-in modules for inventory, stock, and manufacturing
  • Web-based so anyone on the factory floor could access it from a browser

What I Customized

ERPNext supplied the platform; my work was adapting it to the way this operation moves material. That distinction matters: this is an ERPNext/Frappe implementation and customization, not a claim that I wrote an ERP from scratch.

  • Stock movement aligned with receipt, transfer, and issuance events
  • Batch and LOT references that follow material through processing
  • Gate passes for controlled movement outside the facility
  • Operational reports for investigating Fabric Store movements and batches
  • Scripts and barcode-assisted steps where they reduce repeated entry

Changes were introduced incrementally so each workflow could be checked against the physical process before expanding the rollout.

The Adoption Challenge

Introducing a workflow meant showing the relevant task clearly and listening to the people using it. A control that added unnecessary friction was unlikely to survive daily use.

I handled this by walking through each role's specific workflow, reducing unnecessary decisions in the interface, and treating operator feedback as part of the implementation.

What the System Improves

The system creates a consistent operational trail between stock events, batch references, gate passes, and reports. It gives the team one structure for investigating discrepancies and reviewing Fabric Store work.

Because the system is internal, this portfolio uses an architecture diagram rather than exposing production records or employee data.

That operational scope is important: the legacy Fabric Store workflows were used, while broader ERP modules included prototypes. REVE ONE develops the wider factory application separately. Neither a matching ledger nor a passing software test proves the current physical inventory.