Bersama Jaya Cup
Bringing a packaging printing company's records into one system while retaining working habits that remain useful to the team.
Bersama Jaya Cup
- Client
- Bersama Jaya Cup — food-and-beverage packaging printing, Malang
- Industry
- Packaging printing
- Our role
- Product definition, system architecture, and full development — web, server, and floor app
- Duration
- About 6 weeks of intensive development (June – August 2026)
- Year
- 2026
Scope at a glance
6
workspaces: Sales, Production, Master Data, Inventory, WhatsApp, Finance
2
physical warehouses with separately tracked stock
68
legacy spreadsheet files migrated into the system
3
real shop-floor roles: sales, planning, production
The problem
The entire operation ran on monthly spreadsheets plus one ageing point-of-sale application. The sales ledger was split by month, the print price list stood on its own, and stock for two warehouses was recorded in yet another set of files.
The starting point was documented in 68 archived spreadsheet files, which were used for migration. One included a reminder column filled in manually with notes such as "past due".
Invoices were produced separately from order records, while production schedules remained on paper. This made job information difficult to reuse for tracking and reporting.
Constraints
- Invoices and delivery notes still had to print to an ageing dot-matrix printer on three-part carbon paper, directly, with no print dialogue. That is the hardware sitting on the cashier's desk, not a technical preference we could design around.
- The company takes work where the customer supplies their own cups. A single order can be mixed: cups from the customer, lids bought here.
- One order line is often split across several operators in a day — 20,000 cups might become 3,000 + 5,000 + 5,000 + 4,000 + 3,000.
- Cost and gross-profit figures must not be visible to most employees.
Approach
The dot-matrix path was built as a second, standalone render target
A 9-pin printer renders coloured areas as dithered graphics that come out dirty and barely legible on the third carbon sheet. So the print view does not reuse the screen styling — it is built separately: pure black, no colour blocks. All of its geometry — margins, type size, element positions — is stored as database settings, so calibrating against a new batch of paper happens on a settings page rather than in a new release.
Receipt formatting deliberately mirrors the old system
Layout and number formatting on receipts follow the previous point-of-sale application. The aim was to reduce what cashiers needed to relearn while moving to the new system.
Input accepts variation in how operators write
The number of print colours drives a surcharge, and operators may write it in several ways — such as "plain", "full colour", "2", "2 colours", or "red + black". The parser accepts these variations, then normalises colour terms when saving so reports remain consistent.
Warehouse selection moved down to the order line
The initial design selected one warehouse per order. In practice, cups and lids within the same order may come from different warehouses, so warehouse selection was moved to each order line.
Negative stock is permitted, with a warning
Material can sometimes be physically available while the stock record has not yet been updated. To let work continue while the difference is reviewed, the system warns rather than immediately blocking production.
Cost figures are stripped on the server, not hidden on the screen
Cost and gross-profit data are removed from the server's response before it reaches the device, when the user's role has no right to them. Hiding them in the interface alone would mean the numbers still travel to an employee's device, visible to anyone who knows how to open the browser's developer tools.
Observed outcomes
The path from order to settled payment now runs in one track: order → deposit or full invoice → payment → delivery note, with four status tracks running side by side so the position of any job can be read without asking the person handling it.
The daily per-operator print schedule that used to live on paper now has a form a computer can read back, including partial completion — an operator who has printed 700 of 1,000 still has 300 left on that day's list.
The monthly job recap is now updated automatically when a production card reaches completion.
An honest note: we hold no before-and-after data from the client, so this page makes no claims about time or cost saved.
Other projects
Flashlight Cleanstar
2026Building a digital workflow for a motorcycle wash, including a public self-service tablet that is not given access to set prices.
Darmabox
2026Consolidating work that used to live across several disconnected apps — from costing a custom box to the accounting entry posting itself.
Ready when you are / →
Working through a similar need?
Tell us about the situation. Together, we can map the need, possible approaches, and an initial scope.
We usually reply within one business day.