Case study · Dewan Bandaraya Kuala Lumpur
Stock and inventory control across Kuala Lumpur City Hall stores.
Stock and inventory control
— RM 710,000, 2021 to 2023
01 · Client and system
- Dewan Bandaraya Kuala Lumpur
- SIMS — stock and inventory
- 2021 – 2023
- Delivered and handed over to the agency’s team.
02 · The problem
Stock moved between stores faster than the record of it did.
Kuala Lumpur City Hall holds stock across multiple stores, and items move between them constantly. When the movement is recorded after the fact, the stock position is always slightly wrong — and an approval carried on paper or in a message cannot be audited afterwards. The system had to make the approval itself the record, so a movement and its authorisation could never exist separately.
03 · What we built
Five things we are accountable for.
- 01 Stock master and store-level inventory control across the agency’s stores.
- 02 Movement request and approval workflow, where the approval is the record of authorisation.
- 03 Mobile approval for authorised officers, so a movement is not held up by an officer being away from a desk.
- 04 Stock position reporting for the officers who have to answer for it.
- 05 Handover to the agency’s own team, with Bahasa Malaysia documentation.
04 · Scale
The numbers this engagement is measured on.
- RM 710k
- Contract value
- 2 years
- Delivery period
- 1
- External interface
- Handed over
- Current status
- Stores on the system — to supply
- Coverage
- Stock items under control — to supply
- Volume
Two figures are held back until the agency confirms what may be published. An evaluator reads a blank field as honest; a made-up one costs the whole submission.
Architecture explorer
Six layers, in the order a stock movement passes through them.
Scroll to move through the stack. Every layer and its detail is on the page whether the highlight runs or not.
-
01
Client
The storekeeper raising a movement request, or the officer approving it.
Both actions are bound to a named user, so the movement and its authorisation carry the same audit trail.
-
02
Gateway
Authentication and store-level authorisation before the request is accepted.
An officer can only raise or approve movement for the stores they hold, and that is enforced here rather than in the interface.
-
03
Application
Stock master, movement rules, and the approval workflow itself.
A movement is never applied to the stock position until its approval is recorded — the two are a single transaction, not two steps.
-
04
Approval queue
Movements waiting on a named approver.
Pending items stay in the approver’s list until cleared. Nothing expires quietly, and nothing is auto-approved by timeout.
-
05
Database
The stock position, every movement, and every authorisation against it.
The position is derived from approved movements rather than maintained separately, so the ledger and the balance cannot disagree.
-
06
Notification
Push notification to the approver that a movement is waiting.
Approvals are actioned in the system, not in the notification. A missed push delays nothing beyond the next time the approver opens their list.
Interfaces
One interface, and it cannot change state.
Stock movement approval request.
Approvals are actioned in the system, not in the notification. Pending items stay in the approver’s list until cleared.
05 · Result
Three measured outcomes.
Time from movement request to recorded approval, before and after the system.
Stock count variance at audit, across the stores on the system.
Proportion of movements approved on mobile rather than at a desk.
This block is deliberately empty. It is the block an evaluation committee reads hardest, and it must carry numbers you can stand behind in a clarification meeting.
06 · Stack and standards
- Laravel
- Flutter
- MySQL
- RESTful API
- Firebase Cloud Messaging
- Mobile approval
Standards and compliance schedules applicable to this engagement are to be listed here — confirm which may be named publicly before this page is published.