title: “Order Management” description: “Manajemen order multi-channel terpusat — OrderManagement.jsx (614 baris), ProductOrder + MarketplaceOrder, batch processing, WhatsApp notification, dan timeline tracking.”
Order Management

OrderManagement.jsx — 614 baris) adalah halaman terpusat untuk mengelola semua pesanan yang masuk dari berbagai channel penjualan. Halaman ini menggabungkan data dari dua entitas order — ProductOrder (pesanan internal dari website/WhatsApp) dan MarketplaceOrder (pesanan dari Shopee, Tokopedia, dll) — ke dalam satu tampilan tabel yang bisa di-filter, di-search, dan di-batch update.
Dengan Order Management, kamu bisa melacak status setiap pesanan dari awal masuk hingga selesai dikirim ke pelanggan, tanpa perlu berpindah platform. Setiap perubahan status bisa memicu notifikasi WhatsApp otomatis ke pelanggan.
Arsitektur Komponen
Dual-Entity Order Model
Alur Order Multi-Channel
Fitur Utama
Status Order & Timeline
Cara Akses
Flow Penggunaan
Filter & Pencarian
Order dari Website
Order dari WhatsApp
Batch Processing
Metrik Order
Tips
- Cek halaman ini secara berkala sepanjang hari agar tidak ada pesanan yang terlewat atau terlambat diproses
- Manfaatkan filter channel untuk menganalisis dari mana sebagian besar pesanan berasal dan fokus pada channel paling produktif
- Gunakan batch update saat volume tinggi — centang semua order yang sudah dikemas lalu ubah status ke “Dikirim” sekaligus
- Perhatikan timeline setiap order untuk mengidentifikasi bottleneck dalam pemrosesan
- Set reminder untuk order yang sudah terlalu lama di status tertentu (> 24 jam di “Diproses” perlu investigasi)
- Monitor completion rate — jika di bawah 90%, ada masalah di pipeline fulfillment
Entity Schema — Order Management
Berikut adalah dokumentasi schema entitas yang mendasari fitur Order Management pada POS QUINNOFSPICY.Entity Relationship Diagram
Tabel Schema — CompanyPOSTransaction
Entitas utama untuk setiap transaksi POS (kasir), mencakup pesanan offline maupun online yang diproses melalui sistem POS.Tabel Schema — QuinnOrder
Entitas order dari Quinn Storefront (website publik), terhubung keCompanyPOSTransaction melalui pos_transaction_id untuk integrasi ERP dan laporan keuangan.
Sub-Schema — items[] (CompanyPOSTransaction)
Setiap elemen dalam array items pada CompanyPOSTransaction merepresentasikan satu baris produk yang dibeli.
Sub-Schema — items[] (QuinnOrder)
Setiap elemen dalam array items pada QuinnOrder merepresentasikan satu produk yang dipesan melalui storefront.
Sub-Schema — payments[] (Split Payment)
Sub-Schema — payment_proofs[] (QuinnOrder)
Sub-Schema — status_history[] (QuinnOrder)
State Machine — Order Status Lifecycle
CompanyPOSTransaction — order_status
QuinnOrder — status
QuinnOrder — fulfillment_status
QuinnOrder — payment_status
QuinnOrder — reservation_status
Sequence Diagrams
1. Pembuatan Order dari POS (Kasir)
2. Pembuatan Order dari Quinn Storefront
3. Kitchen Display — Order Masuk Dapur
4. Modifikasi Order (Update Status & Verifikasi Pembayaran)
Enum Tables
order_status (CompanyPOSTransaction)
Status pemrosesan order pada CompanyPOSTransaction. Mengontrol alur kerja dari order masuk hingga selesai.
status (CompanyPOSTransaction)
Status transaksi penuh (termasuk refund) pada CompanyPOSTransaction.
status (QuinnOrder)
Status pesanan pada QuinnOrder (lifecycle utama dari checkout hingga selesai).
payment_method (CompanyPOSTransaction)
payment_method (QuinnOrder)
payment_status (CompanyPOSTransaction)
payment_status (QuinnOrder)
fulfillment_status (QuinnOrder)
reservation_status (QuinnOrder)
source (CompanyPOSTransaction)
sales_channel (CompanyPOSTransaction & QuinnOrder)
Kanal penjualan ternormalisasi. Field source pada CompanyPOSTransaction dipertahankan untuk kompatibilitas legacy.
RBAC — Hak Akses Order Management
Berikut adalah matriks hak akses berdasarkan peran (role) terhadap operasi pada entitasCompanyPOSTransaction dan QuinnOrder.
Catatan RBAC: Semua aturan RLS (Row-Level Security) menggunakan pola
$or dengan tiga kondisi: (1) kecocokan company_id dengan active_company_id user, (2) kecocokan created_by_id dengan user.id, atau (3) role admin. Ini memastikan isolasi data multi-tenant yang ketat sambil tetap mengizinkan admin akses penuh.