Lanjut ke konten
Samkarsa Logbook

v1.0.0-003 : Perbaikan State OCR & Backend Diskon/Koreksi

Memperbaiki state halusinasi OCR dan menyimpan data diskon & koreksi manual pada backend.

Blonjo2mnt baca

  • Pembersihan State Transaksi (Fix Halusinasi OCR): Transaksi yang berhasil disimpan kini akan menghapus seluruh state OCR dan Smart Note secara menyeluruh (termasuk Task ID dan source type). Pengguna tidak perlu memuat ulang (reload) halaman secara manual untuk memindai nota baru, memastikan OCR berikutnya tidak berhalusinasi dengan sisa data transaksi sebelumnya.
  • Backend - Support Diskon & Koreksi Item: Database sajen (tabel inventory_logs) kini memiliki kolom discount_value, is_percent, dan is_manual_correction sehingga item yang memiliki diskon atau merupakan hasil koreksi manual saat proses verifikasi OCR, data diskonnya tersimpan utuh di database (walau tidak dimunculkan secara terpisah di tabel rekap utama yang sudah mengandung harga net).

  • Blonjo UI: Memodifikasi Transactions.tsx dengan menambahkan handleFullReset yang menjalankan reset komprehensif pada fungsi onSuccess dari konfirmasi transaksi. Reset ini mencakup SmartNote dan status file upload di useOcrUpload (membersihkan ocrTaskId yang tertinggal).
  • Sajen API:
    • Update schema model InventoryLog di app/models/inventory.py.
    • Update logika penyimpanan log di app/services/accounting.py agar meneruskan field diskon dan koreksi manual ke dalam InventoryLog.

  • Masalah 1 (Parsing NLP): Saat pengguna memberikan input teks bebas (tanpa format baku), ada dua masalah:
    1. Total Harga: Karena teks tidak menyebutkan “Total”, AI tidak mengisi field total_amount dan juga salah dalam penjurnalan. App harus cukup pintar menghitung total secara mandiri.
    2. Tempo: Kata-kata seperti “METODE PEMBAYARAN TEMPO DENGAN JATUH TEMPO PADA TANGGAL 03/08/2026” tidak dikenali sama sekali oleh AI, sehingga jatuh tempo dan metode pembayaran gagal di-ekstrak.
  • Masalah 2 (Migrasi Database): Terjadi rentetan error saat proses deploy VPS akibat riwayat migrasi Alembic yang tidak sinkron dengan kondisi real tabel (seperti DuplicateTable pada journal_mappings dan sebagainya).
  • Analisis:
    • Sisi AI (mcp-server): Prompt sistem saat ini belum secara eksplisit meminta AI untuk bertindak sebagai kalkulator (menjumlahkan qty * harga) apabila kata “Total” absen. LLM juga butuh pengenalan konteks natural language Indonesia secara lebih spesifik terkait kata “tempo”.
    • Sisi DB (sajen-api): Migrasi lama ter-generate dalam kondisi tabel sudah ada di production, sehingga upgrade() konvensional menyebabkan transaksi DB gagal (InFailedSqlTransaction) dan DuplicateTable. Namun, penerapan inspeksi dengan Inspector tidak memadai dalam transaksi DDL PostgreSQL.
  • Rencana Eksekusi (PLAN):
    1. [Selesai] Fix Migrasi DB: Menyempurnakan semua file migrasi bermasalah dengan membuat pembungkus (wrapper) custom bernama safe_execute yang memanfaatkan SAVEPOINT PostgreSQL. Hal ini mencegah Alembic melakukan crash deploy jika entitas sudah ada di database live.
    2. Perbaikan Prompt AI (transactionParser.ts):
      • Menambahkan instruksi ketat: “Jika tidak ada nominal total di teks, KAMU WAJIB menghitung total sendiri (qty * price) dan mengisinya ke total_amount serta journal_entries.”
      • Menambahkan panduan pengenalan metode bayar: “Kenali frasa ‘PEMBAYARAN TEMPO’ dan petakan sebagai payment_method: 'tempo', lalu cari tanggal jatuh temponya untuk field due_date dalam format ISO.”
    3. Pengujian Menyeluruh: Memastikan deploy lancar dan menguji coba ulang teks input yang persis seperti kendala pengguna.

Karena migrasi Alembic menggunakan transaksi tunggal, error satu perintah DDL (seperti CREATE TABLE yang sudah ada) akan menggagalkan seluruh transaksi (masalah InFailedSqlTransaction).

Untuk mengatasinya, kami membuat pembungkus kode safe_execute di setiap file migrasi yang bermasalah.

sequenceDiagram participant Alembic participant SafeExecute as safe_execute(wrapper) participant PostgreSQL as Database (Live) Alembic->>SafeExecute: Minta buat tabel X (op.create_table) SafeExecute->>PostgreSQL: SAVEPOINT sp1 SafeExecute->>PostgreSQL: CREATE TABLE X alt Jika X belum ada (Berhasil) PostgreSQL-->>SafeExecute: Success SafeExecute->>PostgreSQL: RELEASE SAVEPOINT sp1 else Jika X sudah ada (DuplicateTable Error) PostgreSQL-->>SafeExecute: Error (Relation exists) SafeExecute->>PostgreSQL: ROLLBACK TO SAVEPOINT sp1 SafeExecute-->>Alembic: Error diabaikan (Tabel sudah aman) end

Dengan mekanisme di atas, data dan struktur live dijamin aman tanpa modifikasi paksa, dan proses deploy tidak terputus karena kesalahan duplikasi objek.