Shakirin Mills Gold Refining Management System

A centralized financial layer rather than calculations scattered through controllers and views. It resolves grinding revenue, refining value, services, discounts, customer net due, operational expenses, inventory cost, maintenance, payroll, manual adjustments, company collections, grinding profit, and final company net profit — so every dashboard and report is reading the same computation.

Session lifecycle covering customer, grinding machine, number of bags, gold quantity, grinding cost, refining cost, customer discount, operational expenses, inventory consumption, customer net, and session profit.

Employees, monthly salary, employment start date, derived daily salary, worked days, accrued salary, and pending or paid state. Accrual is computed rather than entered by hand.

Remittances are checked against available company profit before they are written, and are stored with the acting user, timestamp, profit before, and profit after. They are kept distinct from operational expenses.

Item catalogue, current quantities, minimum thresholds, and inventory movements. Consumption is costed into the session so profit reflects the materials actually used.

Independent maintenance costs classified by type — emergency, periodic, and repair — tracked separately from session expenses but landing in the same ledger.

A read-only record of system operations — who acted, when, from which address, and on what entity. Entries such as accounting period creation, payroll changes, inventory updates, and authentication events cannot be edited or deleted.

Role-based authorisation across General Manager, Manager, Accountant, Supervisor, and Assistant Supervisor, enforced with Laravel policies so each user reaches only the functions their role allows.

Historical price snapshots on every transaction.

When a session is created at a given bag price, gold price, or refining price, those values are captured onto the transaction itself. If management changes a price later, the older operation does not move — and neither does any report built on it. Without this, editing a single financial setting would silently rewrite months of history.

One centralized financial engine instead of per-screen calculation.

Financial logic was deliberately kept out of controllers and out of the UI. Every consumer — dashboard, administrative report, accountant workbook, ledger — calls the same services, which is the only way two screens can be guaranteed to agree on a number.

Decimal-based money and gold arithmetic.

The system computes money against gold weights, where floating-point representation accumulates rounding error across a chain of multiplications and subtractions. Decimal-based backend calculation keeps totals stable across the grinding, refining, discount, and expense chain.

Payroll accrual derived, not entered.

Accrued salary is computed as monthly salary ÷ days in month × actual worked days, which handles months of different lengths and leap years without special cases. Once a salary is paid, the accrued value is frozen historically so a later month cannot alter a settled record.

Collections validated against available profit.

A company remittance is checked against calculated available profit before it can be recorded, and is stored with profit before and after. This prevents the company from collecting more than it actually earned, and keeps collections separate from operational expenses in every report.

Deactivate rather than delete financial items in use.

A financial item can only be deleted if it was never used historically. Anything referenced by an existing transaction is deactivated instead, so historical records keep resolving their line items and reports stay reproducible.

Operations that produce no gold are first-class.

Some sessions legitimately yield no gold. Rather than forcing a placeholder quantity to satisfy the schema, the system models the no-gold case directly, so reporting is never polluted with invented weights.

Vanilla JavaScript on the client, not a frontend framework.

The interface is a set of data-dense tables, forms, and modals driven by a REST API. HTML5, CSS3, and vanilla JavaScript keep it light and dependency-free; adding a frontend framework would have introduced a build pipeline and runtime weight this product did not need.