Accounting to ERP: Building the Supply Chain Suite
The product was expanding from accounting to ERP as an effort to go up-market. The domain I owned, inventory management, was no longer just another module. It became an upstream system for the broader suite, with decisions that impacted accounting, warehouse management, fulfillment, production, and payment.
I led two foundational projects:
- Product variant: reframing how related products are modelled
- Batch & serial number: one tracking pattern across every transaction document
Together, they laid the groundwork for the production, warehouse, and fulfillment capabilities that followed.
Product variant
Reframing the product model
Problem
Jurnal's inventory module had no concept of related products. A T-shirt in size S and a T-shirt in size M were treated as completely separate products, with no shared parent and no way to manage them as a family.
Accounting could work around the limitation. But in the supply chain suite Mekari was building, it was a foundational gap in the data model.
The initial proposed solution was scoped as a three-month build across multiple teams.
Strategy
Questioned the solution before accepting the scope. Users did not actually need variants in the traditional sense. They needed a way to group related products.
The existing product structure already handled pricing and stock at the most granular level. The missing piece was simply a parent grouping layer.
I designed a parent product-group layer on top of the existing structure, preserving granular pricing and stock while avoiding changes to the underlying product service. This reduced the cross-team dependencies that made the original proposal a three-month build.
- Internal term: product group
- User-facing term: product variant, using terminology users already understood
This preserved a simpler model internally without introducing new vocabulary for users. A usability-testing session validated the approach: 6 of 7 users completed tasks unaided, with the 7th requiring only minimal guidance.
Outcome
Reduced build time from 3 months to 2 weeks. The same user outcome shipped with a fraction of the engineering effort and cross-team dependency.
Batch & serial number
Finding the rules underneath the flows
Problem
Batch and serial tracking touched all transaction flows, from purchase and sales to fulfillment, stock adjustments, and warehouse transfers. Solving each flow independently would mean rebuilding the same underlying behavior across 10+ documents, with different logic and edge cases.
Strategy
Before designing any screen, I mapped every impacted flow and looked for what stayed constant across them.
The behavior came down to two questions: batch or serial, and whether the identifier can be created here or must already exist. That produced three picker modes:
| Identifier rule | Batch | Serial number |
|---|---|---|
| Identifier must exist | Select existing | Select existing |
| Identifier can be new | Select existing or add new | Always add new |
From that analysis, I defined three reusable primitives that held across every transaction document:
- Picker entry point: opens the picker from the document line
- Information header: sets the transaction context
- Picker: selects or adds the batch or serial, following the rule
These three compose into one pattern that holds across every document: an entry point, a context header, and a picker whose behavior follows the rule.
Batch
Purchase invoice
Serial number
Purchase invoice
Outcome
The framework I designed was reused across 16 surfaces.
It held beyond the original scope: later work on row/rack/bin, work orders, and stock reservation used the same logic, including cases I had not originally designed for.