What the system has to hold

A manufacturing system does five things. If a package cannot do all five, it is not a manufacturing system, whatever it is called.

  • One item master — a code that means the same thing in purchasing, on the floor, in the store and on the invoice
  • Stock movement as events, not balances — what moved, when, from where to where, so a discrepancy has a history
  • A bill of materials, so a finished unit is linked to what it consumed
  • Costing that follows actual material movement rather than a standard set once a year
  • Accounting that posts from those same movements instead of being re-entered afterwards

Want to know how this works out for your company? Send us the question as you would ask it.

Multi-warehouse is where spreadsheets stop working

One store can be run on a spreadsheet by someone diligent. Several cannot, because of transfers: the spreadsheet records the same move twice, the two entries drift, and every stock count becomes an argument about which number was right.

On the ERPNext build behind this article, six warehouses across three branches sit on one system, with more than 4,000 items on one item master. A transfer is one event, recorded once, visible from both ends.

CRM problem or operations problem

Orders lost because nobody follows up is a CRM problem. Orders accepted that the floor cannot deliver, or delivered at a margin nobody calculated, is an operations problem, and a CRM will not move it.

Why ERPNext, specifically

A footwear factory's costing is not a food producer's, and the difference is rarely a setting. ERPNext carries manufacturing, stores, purchasing and accounting in the core rather than as paid add-ons, and its source is open, so a process that does not fit can be fitted without waiting on a vendor roadmap.

Start with stores and purchasing

Stores and purchasing go first, because that is where the data quality problem is. Production and costing sit on a clean item master; put first, they inherit the mess.