System Requirements Document for debet-kredit-keuangan

1. Introduction

debet-kredit-keuangan adalah aplikasi web pencatatan keuangan untuk bisnis toko yang menjual melalui Shopee. Aplikasi ini dibuat agar pemilik/pengelola keuangan toko dan staf pencatat transaksi harian dapat mencatat seluruh pergerakan uang toko secara rapi: transaksi debit dan kredit, keuangan masuk (pemasukan), keuangan keluar (pengeluaran), serta rugi/biaya iklan sebagai pos pengeluaran.

Tujuan produk yang diturunkan dari sumber: menyediakan buku kas toko yang dapat dipercaya dan mudah diisi setiap hari, sehingga pemilik toko dapat mengetahui kondisi keuangan bisnisnya — termasuk hasil penjualan dari Shopee — tanpa harus mengandalkan catatan terpisah atau ingatan.

Audiens: pemilik atau pengelola keuangan toko, dan staf yang menjalankan pencatatan transaksi harian. Ruang lingkup pencatatan adalah keuangan bisnis toko, bukan keuangan pribadi.

2. System Overview

Aplikasi berbentuk web dengan identitas milik aplikasi sendiri (pendaftaran mandiri dan login), antarmuka kustom, dan backend yang menyimpan transaksi keuangan toko secara durable.

Aktor manusia yang diterima (katalog tertutup):

• Pemilik/Pengelola Keuangan Toko — mencatat seluruh transaksi keuangan bisnis dan meninjau kondisi keuangan toko.
• Staf Pencatat Transaksi Harian — menjalankan pencatatan harian transaksi masuk dan keluar serta entri debit/kredit.

Kemampuan yang diterima saat ini:

• Mencatat transaksi debit dan kredit.
• Mencatat keuangan masuk (pemasukan) dan keuangan keluar (pengeluaran).
• Mencatat rugi/biaya iklan sebagai bagian dari pencatatan keuangan.
• Meninjau daftar transaksi yang telah dicatat.
• Konteks bisnis toko dengan penjualan melalui Shopee.

Penyingkiran sempit (narrow exclusions): aplikasi ini bukan alat keuangan pribadi, bukan integrasi otomatis ke API Shopee, bukan sistem akuntansi pajak, dan bukan alat pembayaran. Tidak ada integrasi pihak ketiga yang diminta.

2a. Product Interpretation and Delivery Boundary

Aplikasi ini dimiliki dan dijalankan sebagai produk web first-party. Seluruh halaman kerja keuangan (Transactions, Income, Expenses, Debit Credit, Advertising Costs) berada di balik login karena catatan keuangan toko harus terikat pada pemilik yang benar dan dapat dilanjutkan kembali. Halaman Landing, Login, dan Sign Up dapat diakses tanpa login karena keduanya adalah batas akses anonim: Landing menjelaskan aplikasi sebelum masuk, sedangkan Login dan Sign Up menegakkan identitas sebelum pembukuan dibuka.

Identitas dimiliki aplikasi: pengguna mendaftar sendiri (Sign Up) dan memverifikasi kembali dirinya (Login). Tidak ada batas undangan atau provisioning yang ditetapkan sumber, sehingga pendaftaran mandiri adalah jalur masuk yang benar. Identitas ini semata-mata untuk kontinuitas kepemilikan catatan keuangan; sumber tidak menetapkan perbedaan izin atau visibilitas antar peran, sehingga kedua persona memiliki akses kerja yang sama terhadap pembukuan toko.

Batas saat ini vs masa depan: semua kemampuan di atas adalah lingkup saat ini. Tidak ada kemampuan masa depan yang diterima dari sumber; usulan seperti integrasi otomatis Shopee, laporan pajak, atau multi-toko tidak termasuk lingkup saat ini dan tidak boleh dianggap komitmen.

2b. Source Content Inventory

Tidak ada direktif referensi dengan content_source pada sumber, sehingga inventaris konten tidak disertakan.

2c. Page Content and Component Coverage

Landing

• Informasi/state: penjelasan aplikasi pencatatan keuangan bisnis toko sebelum akses ke pembukuan; konteks toko yang menjual melalui Shopee; ringkasan kemampuan (debit/kredit, uang masuk, uang keluar, biaya iklan).
• Aksi utama: menuju Sign Up ("Mulai Catat Gratis"); aksi pendukung berupa tautan teks menuju Login bagi pengguna yang sudah punya akun.
• Entitas domain: tidak ada entitas keuangan yang ditampilkan sebagai data nyata; contoh baris buku kas bersifat ilustratif.
• Tanggung jawab komponen: blok hero poster dengan headline besar; kartu buku kas contoh; strip ticker total harian; blok CTA.
• State: loading tidak berlaku (konten statis); empty tidak berlaku; success = pengguna memilih CTA dan diarahkan ke Sign Up; error = tidak ada kegagalan data karena tidak ada panggilan data; recovery = pengguna tetap dapat memilih tautan Login.

Login

• Informasi/state: formulir verifikasi kembali pengguna yang mengelola catatan keuangan toko.
• Aksi utama: masuk dengan kredensial; aksi pendukung menuju Sign Up bagi yang belum punya akun.
• Entitas domain: identitas pengguna (kredensial akun).
• Tanggung jawab komponen: formulir login, pesan kesalahan, tautan ke Sign Up.
• State: loading = tombol masuk menampilkan status proses; empty = formulir kosong dengan label; success = pengguna terverifikasi dan diarahkan ke halaman kerja keuangan; error = kredensial tidak cocok, ditampilkan pesan dan formulir tetap terisi; recovery = pengguna dapat mencoba lagi atau beralih ke Sign Up.

Sign Up

• Informasi/state: formulir pendaftaran mandiri untuk pengguna baru aplikasi.
• Aksi utama: membuat akun; aksi pendukung menuju Login bagi yang sudah punya akun.
• Entitas domain: identitas pengguna baru.
• Tanggung jawab komponen: formulir pendaftaran, pesan kesalahan, tautan ke Login.
• State: loading = tombol daftar menampilkan status proses; empty = formulir kosong dengan label; success = akun dibuat dan pengguna diarahkan ke halaman kerja keuangan; error = data tidak valid atau akun sudah ada, ditampilkan pesan; recovery = pengguna memperbaiki isian atau beralih ke Login.

Transactions

• Informasi/state: daftar transaksi keuangan toko yang telah dicatat, dengan kolom debit/kredit dan penanda status IN/OUT/IKLAN; total saldo berjalan.
• Aksi utama: meninjau daftar transaksi; aksi pendukung menuju ruang kerja pencatatan (Income, Expenses, Debit Credit, Advertising Costs).
• Entitas domain: transaksi keuangan (tanggal, keterangan, nilai debit, nilai kredit, jenis/status, kategori).
• Tanggung jawab komponen: tabel baris ledger bergaris, badge status, blok stempel total saldo, navigasi rail.
• State: loading = daftar sedang dimuat; empty = belum ada transaksi, ditampilkan ajakan mencatat transaksi pertama; success = daftar transaksi tampil lengkap dengan total; error = gagal memuat data, ditampilkan pesan dan tombol coba lagi; recovery = pengguna memuat ulang daftar.

Income

• Informasi/state: ruang kerja pencatatan keuangan masuk/pemasukan toko; daftar pemasukan yang sudah dicatat pada periode berjalan.
• Aksi utama: mencatat transaksi pemasukan baru; aksi pendukung meninjau pemasukan yang sudah tercatat.
• Entitas domain: transaksi pemasukan (tanggal, keterangan, jumlah, kategori/sumber termasuk penjualan Shopee).
• Tanggung jawab komponen: formulir entri pemasukan, tabel baris pemasukan, badge IN, blok stempel total pemasukan.
• State: loading = daftar pemasukan sedang dimuat; empty = belum ada pemasukan tercatat, ditampilkan ajakan mencatat; success = entri tersimpan dan muncul di daftar dengan total diperbarui; error = penyimpanan gagal atau isian tidak valid, ditampilkan pesan dan isian dipertahankan; recovery = pengguna memperbaiki lalu menyimpan ulang.

Expenses

• Informasi/state: ruang kerja pencatatan keuangan keluar/pengeluaran toko; daftar pengeluaran yang sudah dicatat pada periode berjalan.
• Aksi utama: mencatat transaksi pengeluaran baru; aksi pendukung meninjau pengeluaran yang sudah tercatat.
• Entitas domain: transaksi pengeluaran (tanggal, keterangan, jumlah, kategori).
• Tanggung jawab komponen: formulir entri pengeluaran, tabel baris pengeluaran, badge OUT, blok stempel total pengeluaran.
• State: loading = daftar pengeluaran sedang dimuat; empty = belum ada pengeluaran tercatat, ditampilkan ajakan mencatat; success = entri tersimpan dan muncul di daftar dengan total diperbarui; error = penyimpanan gagal atau isian tidak valid, ditampilkan pesan dan isian dipertahankan; recovery = pengguna memperbaiki lalu menyimpan ulang.

Debit Credit

• Informasi/state: ruang kerja pencatatan entri debit dan kredit atas transaksi keuangan toko; daftar entri debit/kredit yang sudah dicatat.
• Aksi utama: mencatat entri debit dan kredit; aksi pendukung meninjau entri yang sudah tercatat.
• Entitas domain: entri debit/kredit (tanggal, keterangan, akun/pos, nilai debit, nilai kredit).
• Tanggung jawab komponen: formulir entri debit/kredit dengan kolom terpisah, tabel baris ledger dengan kolom debit dan kredit sejajar, blok stempel total.
• State: loading = daftar entri sedang dimuat; empty = belum ada entri, ditampilkan ajakan mencatat; success = entri tersimpan dan muncul di daftar; error = penyimpanan gagal atau isian tidak valid, ditampilkan pesan dan isian dipertahankan; recovery = pengguna memperbaiki lalu menyimpan ulang.

Advertising Costs

• Informasi/state: ruang kerja pencatatan biaya/rugi iklan sebagai pos pengeluaran pembukuan toko; daftar biaya iklan yang sudah dicatat.
• Aksi utama: mencatat biaya/rugi iklan baru; aksi pendukung meninjau biaya iklan yang sudah tercatat.
• Entitas domain: biaya iklan (tanggal, keterangan/kampanye, jumlah, status rugi/biaya).
• Tanggung jawab komponen: formulir entri biaya iklan, tabel baris dengan badge IKLAN dan ikon megafon, blok stempel total "RUGI IKLAN".
• State: loading = daftar biaya iklan sedang dimuat; empty = belum ada biaya iklan tercatat, ditampilkan ajakan mencatat; success = entri tersimpan dan muncul di daftar dengan total diperbarui; error = penyimpanan gagal atau isian tidak valid, ditampilkan pesan dan isian dipertahankan; recovery = pengguna memperbaiki lalu menyimpan ulang.

3. Functional Requirements

FR-01 — Aplikasi web pencatatan keuangan bisnis toko (explicit) As a Pemilik/Pengelola Keuangan Toko, I should dapat membuka aplikasi web pencatatan keuangan bisnis toko, sehingga seluruh catatan keuangan toko tersedia dalam satu tempat.

• Trigger/input: pengguna membuka aplikasi web.
• Hasil terlihat: aplikasi web pencatatan keuangan bisnis toko tampil dan dapat digunakan.
• Access state: halaman kerja keuangan memerlukan login; Landing dapat diakses tanpa login.
• Kegagalan/recovery: bila aplikasi tidak dapat dimuat, pengguna dapat memuat ulang.
• Kelanjutan: pengguna melanjutkan ke pencatatan atau peninjauan transaksi.

FR-02 — Mencatat transaksi debit dan kredit (explicit) As a Staf Pencatat Transaksi Harian, I should mencatat entri debit dan kredit atas transaksi keuangan toko, sehingga setiap transaksi memiliki sisi debit dan kredit yang tercatat.

• Trigger/input: pengguna mengisi tanggal, keterangan, nilai debit, dan nilai kredit pada ruang kerja Debit Credit.
• Hasil terlihat: entri debit/kredit tersimpan dan muncul pada daftar entri dengan kolom debit dan kredit sejajar.
• Access state: memerlukan login.
• Kegagalan/recovery: bila isian tidak valid atau penyimpanan gagal, pesan kesalahan tampil dan isian dipertahankan untuk diperbaiki.
• Kelanjutan: pengguna dapat menambah entri berikutnya atau meninjau daftar di Transactions.

FR-03 — Mencatat keuangan masuk (pemasukan) (explicit) As a Staf Pencatat Transaksi Harian, I should mencatat transaksi keuangan masuk/pemasukan toko, sehingga pemasukan toko tercatat pada periode yang benar.

• Trigger/input: pengguna mengisi tanggal, keterangan, jumlah, dan kategori/sumber pemasukan (termasuk penjualan Shopee) pada ruang kerja Income.
• Hasil terlihat: pemasukan tersimpan, muncul di daftar pemasukan dengan badge IN, dan total pemasukan diperbarui.
• Access state: memerlukan login.
• Kegagalan/recovery: bila penyimpanan gagal atau isian tidak valid, pesan kesalahan tampil dan isian dipertahankan.
• Kelanjutan: pengguna dapat mencatat pemasukan berikutnya atau meninjau daftar di Transactions.

FR-04 — Mencatat keuangan keluar (pengeluaran) (explicit) As a Staf Pencatat Transaksi Harian, I should mencatat transaksi keuangan keluar/pengeluaran toko, sehingga setiap pengeluaran toko tercatat pada periode yang benar.

• Trigger/input: pengguna mengisi tanggal, keterangan, jumlah, dan kategori pengeluaran pada ruang kerja Expenses.
• Hasil terlihat: pengeluaran tersimpan, muncul di daftar pengeluaran dengan badge OUT, dan total pengeluaran diperbarui.
• Access state: memerlukan login.
• Kegagalan/recovery: bila penyimpanan gagal atau isian tidak valid, pesan kesalahan tampil dan isian dipertahankan.
• Kelanjutan: pengguna dapat mencatat pengeluaran berikutnya atau meninjau daftar di Transactions.

FR-05 — Mencatat rugi/biaya iklan (explicit) As a Pemilik/Pengelola Keuangan Toko, I should mencatat rugi/biaya iklan sebagai bagian dari pencatatan keuangan toko, sehingga belanja iklan terlihat sebagai pos pengeluaran tersendiri.

• Trigger/input: pengguna mengisi tanggal, keterangan/kampanye, dan jumlah biaya iklan pada ruang kerja Advertising Costs.
• Hasil terlihat: biaya iklan tersimpan, muncul di daftar dengan badge IKLAN, dan total "RUGI IKLAN" diperbarui.
• Access state: memerlukan login.
• Kegagalan/recovery: bila penyimpanan gagal atau isian tidak valid, pesan kesalahan tampil dan isian dipertahankan.
• Kelanjutan: pengguna dapat mencatat biaya iklan berikutnya atau meninjau daftar di Transactions.

FR-06 — Meninjau daftar transaksi keuangan toko (explicit) As a Pemilik/Pengelola Keuangan Toko, I should meninjau daftar transaksi keuangan toko yang telah dicatat, sehingga saya dapat mengetahui kondisi keuangan toko.

• Trigger/input: pengguna membuka halaman Transactions.
• Hasil terlihat: daftar transaksi tampil dengan kolom debit/kredit, badge status IN/OUT/IKLAN, dan total saldo berjalan.
• Access state: memerlukan login.
• Kegagalan/recovery: bila daftar gagal dimuat, pesan kesalahan tampil dengan tombol coba lagi.
• Kelanjutan: pengguna dapat berpindah ke ruang kerja pencatatan untuk menambah transaksi.

FR-07 — Konteks bisnis toko dengan penjualan Shopee (explicit) As a Staf Pencatat Transaksi Harian, I should mencatat pemasukan hasil penjualan toko melalui Shopee sebagai bagian dari pemasukan toko, sehingga hasil penjualan Shopee masuk ke pembukuan toko.

• Trigger/input: pengguna memilih/mengisi kategori sumber pemasukan Shopee saat mencatat pemasukan.
• Hasil terlihat: pemasukan Shopee tercatat dan terhitung dalam total pemasukan toko.
• Access state: memerlukan login.
• Kegagalan/recovery: bila kategori tidak dapat disimpan, pesan kesalahan tampil dan isian dipertahankan.
• Kelanjutan: pengguna melanjutkan peninjauan di Transactions.

FR-08 — Pendaftaran mandiri (Sign Up) (required_inference) As a Pemilik/Pengelola Keuangan Toko, I should mendaftar sendiri sebelum pertama kali membuat atau mengelola pembukuan toko, sehingga catatan keuangan terikat pada akun saya.

• Trigger/input: pengguna baru mengisi formulir pendaftaran pada halaman Sign Up.
• Hasil terlihat: akun dibuat dan pengguna diarahkan ke halaman kerja keuangan.
• Access state: halaman Sign Up dapat diakses tanpa login.
• Kegagalan/recovery: bila data tidak valid atau akun sudah ada, pesan kesalahan tampil dan pengguna dapat memperbaiki isian atau beralih ke Login.
• Kelanjutan: pengguna mulai mencatat transaksi.

FR-09 — Verifikasi kembali melalui Login (required_inference) As a Staf Pencatat Transaksi Harian, I should memverifikasi kembali identitas saya melalui Login untuk melanjutkan akses ke catatan keuangan yang tersimpan, sehingga saya dapat melanjutkan pekerjaan pencatatan pada sesi berikutnya.

• Trigger/input: pengguna memasukkan kredensial pada halaman Login.
• Hasil terlihat: pengguna terverifikasi dan diarahkan ke halaman kerja keuangan dengan catatan tersimpan tersedia.
• Access state: halaman Login dapat diakses tanpa login; halaman kerja keuangan memerlukan login.
• Kegagalan/recovery: bila kredensial tidak cocok, pesan kesalahan tampil dan pengguna dapat mencoba lagi atau beralih ke Sign Up.
• Kelanjutan: pengguna melanjutkan pencatatan atau peninjauan transaksi.

FR-10 — Penyimpanan durable transaksi keuangan toko (required_inference) As a Pemilik/Pengelola Keuangan Toko, I should memiliki transaksi keuangan toko yang tersimpan secara durable di backend, sehingga catatan tetap tersedia saat saya kembali.

• Trigger/input: setiap penyimpanan transaksi dari ruang kerja pencatatan.
• Hasil terlihat: transaksi tersimpan dan dapat dimuat kembali pada sesi berikutnya.
• Access state: hanya dapat diakses setelah login.
• Kegagalan/recovery: bila penyimpanan gagal, pesan kesalahan tampil dan pengguna dapat mencoba menyimpan ulang.
• Kelanjutan: pengguna meninjau transaksi tersimpan di Transactions.

4. User Personas

Pemilik/Pengelola Keuangan Toko

• Konteks produk: pemilik atau pengelola keuangan toko yang menjual melalui Shopee dan memegang tanggung jawab atas kondisi keuangan bisnis. Ia memakai aplikasi ini sebagai buku kas utama toko, bukan sebagai alat keuangan pribadi.
• Tujuan utama: memiliki catatan keuangan bisnis yang rapi dan dapat dipakai untuk mengetahui kondisi keuangan toko, termasuk hasil penjualan dari Shopee.
• Tanggung jawab yang diterima: mencatat seluruh transaksi keuangan bisnis — pencatatan debit dan kredit, uang masuk dan uang keluar — serta mencatat biaya/rugi iklan; meninjau daftar transaksi untuk menilai kondisi keuangan.
• Input/keputusan: memutuskan kategori dan pos setiap transaksi (pemasukan, pengeluaran, debit/kredit, biaya iklan), serta menilai apakah total saldo dan total rugi iklan mencerminkan keadaan toko.
• Interaksi dengan peserta lain: bekerja pada pembukuan toko yang sama dengan Staf Pencatat Transaksi Harian; entri yang dicatat staf muncul pada daftar transaksi yang ia tinjau, dan entri yang ia catat tersedia bagi staf untuk dilanjutkan.
• Keberhasilan yang terlihat: daftar transaksi menampilkan seluruh pergerakan dengan total saldo berjalan dan total rugi iklan yang dapat dipercaya.

Staf Pencatat Transaksi Harian

• Konteks produk: staf yang menjalankan pencatatan harian transaksi masuk dan keluar serta entri debit/kredit agar pembukuan toko tetap terisi setiap hari.
• Tujuan utama: memasukkan transaksi rutin dengan cepat dan memastikan setiap pengeluaran, termasuk biaya iklan, tercatat pada periode yang benar.
• Tanggung jawab yang diterima: mencatat pemasukan harian (termasuk penjualan Shopee), mencatat pengeluaran harian, mencatat entri debit dan kredit, dan mencatat biaya iklan bila terjadi.
• Input/keputusan: tanggal transaksi, keterangan, jumlah, serta pemilihan kategori/pos yang benar untuk tiap entri.
• Interaksi dengan peserta lain: entri yang ia simpan menjadi bagian dari pembukuan yang ditinjau Pemilik/Pengelola Keuangan Toko; ia bergantung pada akun yang sama untuk melanjutkan pencatatan pada sesi berikutnya.
• Keberhasilan yang terlihat: setiap entri tersimpan tanpa kesalahan, muncul di daftar dengan badge status yang benar, dan total pada ruang kerja terkait ikut diperbarui.

5. Core User Flows

Flow A — Pemilik/Pengelola Keuangan Toko pertama kali mulai mencatat

1. Konteks awal: pemilik toko belum memiliki akun dan membuka aplikasi web untuk pertama kali.
2. Di Landing, ia membaca penjelasan aplikasi pencatatan keuangan bisnis toko dan memilih CTA "Mulai Catat Gratis".
3. Aplikasi mengarahkannya ke Sign Up. Ia mengisi formulir pendaftaran mandiri dan mengirimkannya.
4. Hasil terlihat: akun dibuat dan ia diarahkan ke halaman kerja keuangan.
5. Kegagalan/recovery: bila data tidak valid atau akun sudah ada, pesan kesalahan tampil; ia memperbaiki isian atau beralih ke Login.
6. Kelanjutan: ia melanjutkan ke Flow B untuk mencatat transaksi pertama.

Flow B — Pemilik/Pengelola Keuangan Toko mencatat pemasukan penjualan Shopee

1. Konteks awal: pemilik sudah login dan memiliki hasil penjualan Shopee yang perlu dibukukan.
2. Ia membuka Income dari rail navigasi.
3. Ia mengisi tanggal, keterangan, jumlah, dan kategori/sumber pemasukan Shopee, lalu menyimpan.
4. Hasil terlihat: pemasukan tersimpan, muncul di daftar pemasukan dengan badge IN, dan total pemasukan diperbarui.
5. Kegagalan/recovery: bila penyimpanan gagal atau isian tidak valid, pesan kesalahan tampil dan isian dipertahankan; ia memperbaiki lalu menyimpan ulang.
6. Kelanjutan: ia membuka Transactions untuk memastikan pemasukan tercatat pada daftar dan total saldo berjalan bertambah.

Flow C — Pemilik/Pengelola Keuangan Toko mencatat rugi/biaya iklan

1. Konteks awal: pemilik sudah login dan telah mengeluarkan belanja iklan untuk toko.
2. Ia membuka Advertising Costs dari rail navigasi.
3. Ia mengisi tanggal, keterangan/kampanye, dan jumlah biaya iklan, lalu menyimpan.
4. Hasil terlihat: biaya iklan tersimpan, muncul di daftar dengan badge IKLAN, dan total "RUGI IKLAN" diperbarui.
5. Kegagalan/recovery: bila penyimpanan gagal atau isian tidak valid, pesan kesalahan tampil dan isian dipertahankan; ia memperbaiki lalu menyimpan ulang.
6. Kelanjutan: ia membuka Transactions untuk melihat biaya iklan sebagai pos pengeluaran pada pembukuan toko.

Flow D — Staf Pencatat Transaksi Harian mencatat transaksi harian

1. Konteks awal: staf membuka aplikasi pada awal hari kerja pencatatan.
2. Di Login, ia memasukkan kredensial untuk memverifikasi kembali identitasnya.
3. Hasil terlihat: ia terverifikasi dan diarahkan ke halaman kerja keuangan dengan catatan tersimpan tersedia.
4. Kegagalan/recovery: bila kredensial tidak cocok, pesan kesalahan tampil; ia mencoba lagi atau beralih ke Sign Up.
5. Ia membuka Expenses dan mencatat pengeluaran harian toko (tanggal, keterangan, jumlah, kategori), lalu menyimpan.
6. Hasil terlihat: pengeluaran tersimpan, muncul di daftar dengan badge OUT, dan total pengeluaran diperbarui.
7. Ia membuka Debit Credit dan mencatat entri debit dan kredit atas transaksi keuangan toko, lalu menyimpan.
8. Hasil terlihat: entri tersimpan dan muncul pada daftar dengan kolom debit dan kredit sejajar.
9. Kegagalan/recovery: pada setiap langkah, bila penyimpanan gagal atau isian tidak valid, pesan kesalahan tampil dan isian dipertahankan untuk diperbaiki.
10. Kelanjutan: ia membuka Transactions untuk memastikan seluruh entri hari itu tercatat pada periode yang benar.

Flow E — Pemilik/Pengelola Keuangan Toko meninjau kondisi keuangan toko

1. Konteks awal: pemilik sudah login dan ingin mengetahui kondisi keuangan toko setelah beberapa hari pencatatan.
2. Ia membuka Transactions.
3. Hasil terlihat: daftar transaksi tampil dengan kolom debit/kredit, badge status IN/OUT/IKLAN, dan total saldo berjalan.
4. Kegagalan/recovery: bila daftar gagal dimuat, pesan kesalahan tampil dengan tombol coba lagi; ia memuat ulang daftar.
5. Kelanjutan: bila ia menemukan pos yang perlu ditambah atau diperbaiki, ia berpindah ke Income, Expenses, Debit Credit, atau Advertising Costs untuk mencatat transaksi berikutnya.

6. Visuals Colors and Theme

Arah kreatif bersifat otoritatif. Muse: Aaron Draplin — ledger craft yang jujur dan kokoh, seperti buku kas catatan lapangan untuk toko Shopee. Headline arah: field-notes cashbook — kerja tukang catat dengan buku bergaris, bukan dashboard fintech mengkilap.

Palet (light mode):

Tidak ada biru di mana pun; tidak ada gradien. Warna dipakai sebagai blok datar dan rule tebal, poster-style.

Tipografi:

• Heading: Alfa Slab One — slab-serif display, all-caps untuk hero dan judul seksi, tracking rapat (-0.01em), bobot berat sebagai suara stempel/badge.
• Body: Barlow pada regular dan semibold, dengan label all-caps untuk nama field dan header tabel.
• Skala 1.25 modular: display 44px mobile / 72px tablet / 112px desktop; section head 28/40/56; card title 20/24/28; body 16/17/18; label 12/12/13 all-caps dengan tracking 0.08em.
• Angka diset dalam Barlow SemiBold tabular untuk baris ledger.

Shape language: panel bergaris chunky dengan border tinta 3px, radius sudut 6px (hampir persegi — badge, bukan pill), rule horizontal tebal pemisah baris ledger, badge/stamp lingkaran untuk total, aksen torn-tape/halftone. Tombol persegi dengan hard 2px offset shadow, bukan soft float. Kartu datar dengan border terlihat, tidak pernah frosted glass.

Layout: grid asimetris poster-like — rail kiri berisi badge navigasi bertinta tebal (Dashboard, Transaksi, Pemasukan, Pengeluaran, Debit/Kredit, Biaya Iklan) dan kolom utama bergaris lebar. Baris ledger bersifat tabular dengan kolom debit/kredit sejajar dan status stamp berkode warna. Landing memakai seksi poster bertumpuk yang dipisah rule tebal, dengan blok warna full-bleed di belakang headline. Semua menempel pada grid 8px yang ketat; tidak ada yang mengambang dekoratif.

Imagery: pictogram vektor garis tebal (koin, struk, tas belanja, megafon untuk belanja iklan, kotak untuk stok) dengan stroke 3px, tekstur halftone-dot pada blok warna, badge/stamp untuk total, dan tekstur kertas bergaris. Tidak ada foto stok orang, tidak ada render 3D, tidak ada gradient blob.

7. Signature Design Concept

Hero Landing adalah halaman buku kas poster: bidang kraft-paper full-bleed dibelah satu rule tinta tebal.

• Kiri: headline slab all-caps raksasa "CATAT DUIT TOKO LO" bertumpuk tiga baris yang membentang hampir seluruh kolom, diset #1B1A17 di atas ground #F2E8D5. Kata DEBET dan KREDIT masing-masing ditempatkan di dalam blok warna solid — #1F4E3D untuk DEBET dan #E4572E untuk KREDIT — yang bleed keluar dari tepi kiri viewport.
• Kanan: kartu buku kas bertumpuk yang dirender sebagai halaman bergaris sungguhan — header band hijau tebal bertuliskan "BUKU KAS TOKO", tiga baris contoh dengan angka debit/kredit tabular, dan badge stempel oranye besar berisi saldo berjalan.
• Bawah headline: satu CTA persegi dengan hard offset shadow ("Mulai Catat Gratis") dan satu tautan teks sekunder menuju Login.
• Dasar hero: strip ticker oranye tipis yang berjalan di sepanjang tepi bawah, memuat total uang masuk, uang keluar, dan belanja iklan hari itu.

Konsep ini hanya menyusun ulang konten, state, dan kontrol yang sudah diterima (penjelasan aplikasi, CTA ke Sign Up, tautan Login, contoh baris ledger, total harian) — tidak menambah perilaku, halaman, atau tujuan baru.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: headline slab all-caps "CATAT DUIT TOKO LO" dengan blok warna DEBET/KREDIT, berdampingan dengan kartu buku kas bergaris dan badge stempel saldo.
• Input → transformation → outcome: saat halaman dimuat, angka pada kartu buku kas dan badge saldo count up sekali (satu kali, tanpa pengulangan); baris ledger baru slide in dengan snap 120ms tanpa bounce; strip ticker oranye di dasar hero berjalan terus memuat total uang masuk, uang keluar, dan belanja iklan hari itu. Hasilnya: hero terasa seperti stempel karet yang menghantam kertas — mekanis, kokoh, sekali jadi.
• Motion vocabulary: count-up sekali saat mount, snap 120ms tanpa bounce, marquee ticker, hover = colour flip instan (bukan lift), badge nav tertekan dengan pergeseran offset 1px. Tidak ada parallax, tidak ada partikel, tidak ada easing teatrikal.
• Composed first frame: bidang kraft #F2E8D5 penuh, headline tinta #1B1A17 sudah terbaca utuh, blok hijau #1F4E3D dan oranye #E4572E sudah di posisinya, kartu buku kas tampil dengan angka awal, badge saldo tampil, ticker oranye sudah terlihat di tepi bawah.
• Reduced-motion state: count-up dan snap dimatikan sehingga angka dan baris tampil langsung pada nilai akhirnya; ticker menjadi strip yang dapat digulir horizontal sehingga setiap item dapat dibawa sepenuhnya ke dalam tampilan.

9. Non-Functional Requirements

• NFR-01 — Platform web (explicit): aplikasi harus berbentuk web. Rasional: constraint keras dari sumber.
• NFR-02 — Ruang lingkup keuangan bisnis toko (explicit): pencatatan hanya untuk keuangan bisnis toko, bukan keuangan pribadi. Rasional: constraint keras dari sumber.
• NFR-03 — Penyimpanan durable (required_inference): transaksi keuangan toko harus tersimpan secara durable di backend sehingga dapat dimuat kembali pada sesi berikutnya. Rasional: diperlukan agar alur pencatatan yang diterima dapat dijalankan dan dilanjutkan.
• NFR-04 — Kontinuitas identitas (required_inference): catatan keuangan harus terikat pada akun pengguna yang benar, dengan pendaftaran mandiri dan verifikasi kembali melalui login. Rasional: diperlukan agar kepemilikan catatan tetap benar antar sesi.
• NFR-05 — Keterbacaan dan kontrol utuh di semua viewport (explicit, dari arah kreatif): headline, wordmark, label, angka, teks kartu, dan kontrol harus tetap seluruhnya di dalam viewport dan kontainernya pada 375px, 768px, dan 1280px, membungkus atau menskalakan (misalnya font-size: clamp(...) dengan ukuran mobile-nya) agar muat; tidak ada elemen lain yang menutupi bagian mana pun darinya. Konten yang bergerak/bergulir (ticker, baris yang dapat digulir) boleh melewati tepi viewport secara desain dan dinilai dari apakah ia benar-benar bergerak serta apakah setiap item menjadi terbaca penuh saat melewatinya.
• NFR-06 — Aksesibilitas gerak (explicit, dari arah kreatif): dengan prefers-reduced-motion, harus tersedia susunan statis yang dapat dipakai — item dibungkus ke baris atau dibuat dapat digulir horizontal sehingga setiap item dapat dibawa sepenuhnya ke dalam tampilan.
• NFR-07 — Kontras dan larangan palet (explicit, dari arah kreatif): ground kraft dan teks tinta harus tetap berkontras tinggi; tidak boleh ada biru/indigo (misalnya #2563EB, #4F46E5) di mana pun; template SaaS indigo/biru-di-atas-putih dilarang untuk proyek ini.

10. Tech Stack

• Frontend: React (aplikasi web).
• Backend: Python/FastAPI, menyediakan penyimpanan dan pengelolaan transaksi keuangan toko secara durable.
• Storage: basis data relasional untuk transaksi keuangan (pemasukan, pengeluaran, entri debit/kredit, biaya iklan) dan identitas pengguna.
• Kontainerisasi: Docker/docker-compose untuk menjalankan aplikasi dan basis data secara lokal.
• Kubernetes: tidak disertakan — sumber tidak menetapkan kebutuhan deployment yang mengharuskannya.

Pilihan teknologi di atas mengikuti pilihan yang ditetapkan sumber; tidak ada substitusi.

11. Assumptions and Constraints

• [Assumption — required_inference] Identitas dimiliki aplikasi dengan pendaftaran mandiri dan login, karena catatan keuangan harus terikat pada pemilik yang benar dan dapat dilanjutkan antar sesi. Tidak ada batas undangan atau provisioning yang ditetapkan sumber.
• [Assumption — required_inference] Kedua persona (Pemilik/Pengelola Keuangan Toko dan Staf Pencatat Transaksi Harian) bekerja pada pembukuan toko yang sama; sumber tidak menetapkan perbedaan izin atau visibilitas, sehingga tidak ada kontrol RBAC yang ditambahkan.
• [Constraint — explicit] Aplikasi berbentuk web.
• [Constraint — explicit] Ruang lingkup pencatatan adalah keuangan bisnis toko, bukan keuangan pribadi.
• [Constraint — explicit] Konteks bisnis toko dengan penjualan melalui Shopee; hasil penjualan Shopee dicatat sebagai pemasukan toko.
• [Constraint — explicit, dari arah kreatif] Palet, tipografi, shape language, layout, dan motion mengikuti arah kreatif Draplin; biru/indigo dan template SaaS biru-di-atas-putih dilarang.
• [Boundary] Tidak ada integrasi otomatis ke API Shopee, tidak ada pelaporan pajak, tidak ada alat pembayaran, dan tidak ada multi-toko — sumber tidak menerimanya sebagai lingkup saat ini.
• [Default — not specified by user] Nilai contoh pada kartu buku kas di Landing bersifat ilustratif dan bukan data nyata pengguna.

12. Glossary

• Debit/Kredit — pasangan entri yang mencatat dua sisi sebuah transaksi keuangan toko; dicatat pada ruang kerja Debit Credit dengan kolom debit dan kredit sejajar.
• Keuangan masuk (pemasukan) — uang yang masuk ke toko, termasuk hasil penjualan melalui Shopee; dicatat pada ruang kerja Income.
• Keuangan keluar (pengeluaran) — uang yang keluar dari toko; dicatat pada ruang kerja Expenses.
• Rugi/Biaya iklan — belanja iklan toko yang dicatat sebagai pos pengeluaran tersendiri; dicatat pada ruang kerja Advertising Costs dan ditandai badge IKLAN.
• Buku kas toko — kumpulan catatan transaksi keuangan bisnis toko yang menjadi sumber kebenaran kondisi keuangan toko.
• Badge status — penanda pada baris ledger: IN (hijau) untuk uang masuk, OUT (oranye) untuk uang keluar, IKLAN (oranye dengan ikon megafon) untuk biaya iklan.
• Stempel total — badge lingkaran dengan cincin tinta tebal dan label all-caps (misalnya "SALDO", "RUGI IKLAN") yang menampilkan total pada dashboard, transactions, dan halaman biaya iklan.
• Ticker — strip oranye tipis di bawah header yang memuat total uang masuk, uang keluar, dan belanja iklan hari itu serta transaksi terakhir.