Gold Store Management

Masalah

Stok sebuah toko emas adalah modalnya, dan perputarannya cepat. Penjualan dibagi ke beberapa staff (satu invoice bisa ditanggung sampai tiga orang), jadi bonus harus mengikuti pembagian itu, bukan mengikuti kasirnya. Target ditetapkan per orang per bulan, dan di akhir bulan ada yang harus menyusun laporan laba rugi dari pendapatan, biaya operasional, biaya produksi, gaji, dan bonus. Kalau dikerjakan di spreadsheet, justru di situ kesalahannya muncul.

Sistemnya sudah ada saat pekerjaannya dimulai, dan ternyata sebagian besar dari pekerjaan itu adalah membuatnya aman, bukan menambah fiturnya: sekitar seperempat commit-nya berisi perbaikan, refactor, atau penyesuaian. Otorisasi di keempat perannya adalah yang pertama tumbang: menu mengarah ke halaman yang tidak bisa dibuka peran itu, aturan akses duduk di konstruktor controller sehingga memblokir orang yang justru seharusnya boleh lewat alih-alih yang seharusnya dicegah, dan sidebar menampilkan modul untuk staff yang sama sekali tidak berhak melihatnya. Transaksi pengeluaran menyusul: total harga yang berubah jadi NaN begitu field quantity diisi apa pun yang bukan angka, validasi form yang terlalu tipis sehingga nilainya tetap sampai ke backend, dan modal edit yang gagal memuat transaksi yang seharusnya diedit.

Stok adalah yang paling serius. Satu nomor order bisa dipakai beberapa pengguna dan dibagi rata di antara mereka, sementara fungsi update yang awal mengembalikan stok dengan selalu menambahkan quantity lama alih-alih selisihnya, jadi hitungannya melenceng ke arah mana pun yang kebetulan disukai aritmetikanya, pada angka yang merupakan modal tokonya. Dua pengguna yang menyesuaikan produk yang sama di saat bersamaan juga bisa saling mendahului. Pelaporannya punya versi masalah yang sama: target penjualan difilter dengan bulan yang ditulis di dalam kode, laporan bulanan dan tahunan belum ada, dan chart dashboard belum bisa memisahkan angka satu pengguna dari pengguna lain, semuanya kemudian bertemu perubahan kebutuhan, ketika data per cabang dan format mata uang datang dan harus diterapkan ke hampir seluruh template laporan sekaligus.

Solusi

Tidak ada halaman publik: setiap halaman butuh login, dan empat peran (admin, manajer, akuntan, staff) menentukan halaman mana yang ada untukmu. Aturan itu berawal berpencar dan berakhir di satu tempat: pemetaan menu per peran yang eksplisit, pembatasannya ditulis di samping route yang dilindunginya alih-alih di dalam controller, dan modul pengguna disembunyikan dari staff alih-alih ditampilkan dalam versi tersaring. Penjualan dicatat sebagai nomor invoice yang bisa dibagi ke maksimal tiga staff, masing-masing dapat sub-nomor sendiri, sehingga bonusnya mengikuti pekerjaannya; stok kini diperbarui berdasarkan selisih antara nilai lama dan baru, dengan transaksi pemilik tunggal dan transaksi bersama ditangani sebagai dua jalur yang eksplisit. Seluruh update-nya berjalan di dalam transaksi database yang mengunci baris yang disentuhnya dan melempar exception saat stok tidak cukup untuk menutup perubahannya: exception, bukan redirect, sehingga update yang gagal tidak mungkin meninggalkan separuh dirinya. Form-nya tetap mengecek stok lewat endpoint sebelum dikirim, yang membuat kegagalan itu jarang, tapi sekarang invariannya juga dipegang server terlepas dari apa yang dikirim klien: field quantity yang penuh huruf tidak lagi mengubah totalnya jadi NaN.

Pelaporannya tumbuh dari bulan yang di-hardcode menjadi sebuah lapisan: pencapaian target dihitung dari transaksinya alih-alih diketik, export bulanan dan tahunan ke PDF maupun Excel, laporan dipecah per pengguna dan per peran staff, informasi cabang di heading dengan cabang nonaktif disaring keluar, dan format mata uang diterapkan menyeluruh. Penghapusan menjadi satu pola alih-alih kebiasaan: satu flag di setiap tabel, query yang menghormatinya, dan aksi restore yang eksplisit, sehingga data bisa dikeluarkan dari peredaran tanpa harus hilang. Kode produk di-generate, bukan diketik, supaya katalognya tetap konsisten secepat apa pun data dimasukkan.

Laporan laba rugi dihitung dari catatan penjualan, biaya, dan gaji yang sama dengan yang ditulis bagian lain aplikasi, jadi angkanya cocok secara konstruksi, bukan karena kehati-hatian. Setiap peran mendapat dashboard yang membandingkan transaksi terhadap target, dan itu satu-satunya tampilan yang dibutuhkan sebagian besar staff. Refactor yang berjalan bersamanya belum tuntas: satu migrasi foreign key masih bertanggal bertahun-tahun di masa depan, dan satu relasi masih menamai tabelnya dengan tanda hubung padahal schema-nya memakai garis bawah. Keduanya sisa yang seharusnya dicegah framework: validasi tempatnya di form request, dan penghapusan tempatnya di trait bawaan, bukan di kolom yang dipelihara manual.