​

title: “POS Order Queue” description: “Live fulfillment queue SNISHOP ERP — Kanban board real-time, kitchen ticket printing, browser push notification, dan multi-channel order tracking.”

​

POS Order Queue

​

Arsitektur Komponen

​

Kanban Board — 3 Kolom

​

OrderCard — Informasi per Order

​

Channel Badge Colors

​

Order Type Badges

​

Data Fetching Strategy

​

New Order Detection

• knownOrderIdsRef menyimpan Set dari order IDs yang sudah dilihat
• Setiap fetch baru, bandingkan dengan ref
• Order ID yang tidak ada di ref = order baru
• Trigger browser notification + sound
• Update ref setelah notifikasi

​

Kitchen Ticket Printing

================================
         KITCHEN TICKET
================================
Order: TRX-20261010-ABC123
Type:  Dine In
Time:  14:30:00
--------------------------------
ITEMS:
  1x Sambal Matah Premium
  2x Nasi Goreng Pedas
  1x Es Teh Manis
--------------------------------
Customer: Budi Santoso
Notes: Tidak terlalu pedas
================================

• Bluetooth thermal printer (58mm / 80mm)
• Auto-print option di settings
• Manual print dari OrderDetailModal
• isPrintingSlip state untuk prevent double-print

​

Browser Push Notification

• Title: “Pesanan Baru!”
• Body: “Order #TRX-xxx dari [Channel] - [N] items”
• Icon: App logo
• Sound: Default notification sound

• Meminta izin Notification API saat pertama kali
• User bisa disable di browser settings
• Fallback ke sound alert jika notification ditolak

​

Filter & Search

​

Filter Controls

​

Filter Behavior

• Semua filter bisa dikombinasikan
• Filter persist selama sesi halaman
• Reset filter: klik “Clear All”
• Result count ditampilkan di header

​

Order Detail Modal

• Transaction number & date
• Channel & order type badges
• Customer info (name, phone, address)
• Notes from customer

• Full item list dengan quantity dan price
• Item notes (contoh: “tidak pakai bawang”)
• Subtotal per item

• Payment method & status
• Total amount
• Split payment breakdown (jika ada)

• Start Processing / Mark Completed
• Print Kitchen Ticket
• Print Receipt
• Cancel Order
• Send WhatsApp

​

Server Functions

​

transitionPOSOrderStatus Workflow

​

Demo Mode

• DEMO_ORDERS: 6 sample orders dengan berbagai channel dan status
• DEMO_COMPANY: Dummy company context
• Auto-rotate orders untuk simulasi real-time

• Otomatis ketika isDemoMode = true
• Tidak ada data real yang dimodifikasi
• Semua aksi (process, complete) bekerja di memory saja

​

Performance Optimization

​

Cross-Module Integration

​

Best Practices

​

Untuk Kitchen Staff

1. Pantau timer — order yang sudah > 15 menit perlu prioritas
2. Print kitchen ticket untuk setiap order baru
3. Update status tepat waktu — jangan biarkan order stuck di pending
4. Cek notes — ada instruksi khusus dari customer
5. Komunikasi dengan kasir jika ada item yang habis

​

Untuk Manager

1. Monitor queue dari dashboard untuk melihat bottleneck
2. Set target time — pending < 5 menit, processing < 15 menit
3. Review completed orders untuk quality check
4. Analisis peak hours dari POS Reports
5. Adjust staffing berdasarkan order volume per jam

​

Untuk Developer

1. Selalu gunakan listPOSOrderQueue untuk fetch data (bukan direct entity filter)
2. Listen ke snishop_order_queue untuk real-time updates
3. Handle error state dengan graceful UI
4. Optimize polling — hanya ketika tab visible
5. Test demo mode untuk presentasi tanpa data real

​

Entity Relationship Diagram — Order Queue

​

Penjelasan Relasi (Bahasa Indonesia)

1. CompanyPOSTransaction → CompanyPOSProduct: Setiap transaksi POS menyimpan array items[] yang merujuk ke product_id dari CompanyPOSProduct. Ini adalah relasi many-to-many melalui embedded document.
2. CompanyPOSTransaction → CompanyPOSInventory: Setiap transaksi yang berhasil otomatis menulis log CompanyPOSInventory dengan type = 'out' untuk mengurangi stok.
3. CompanyPOSTransaction → QuinnOrder: Order dari website Quinn di-mirror ke CompanyPOSTransaction melalui field pos_transaction_id. Ini memungkinkan laporan terpadu dari semua channel.
4. CompanyPOSProduct → CompanyPOSCategory: Setiap produk POS dikelompokkan dalam satu kategori untuk filtering dan reporting.
5. QuinnOrder → CompanyPOSProduct: Item pada QuinnOrder merujuk ke SKU produk yang sama, memastikan konsistensi inventory.

​

Entity Schema Tables — Order Queue

​

CompanyPOSTransaction — Skema Field Utama

​

Enum: order_status — 8 Nilai Status Order Queue

​

Enum: payment_method — Metode Pembayaran

​

Enum: payment_status — Status Pembayaran

​

Items Sub-Schema (Embedded dalam CompanyPOSTransaction)

​

QuinnOrder — Skema Field (Channel Website)

​

State Diagram — Order Status Lifecycle (Kanban Queue)

​

Penjelasan Transisi Status (Bahasa Indonesia)

​

Sequence Diagram — Alur Order Placement → Kitchen → Fulfillment

​

Alur 1: Order dari Kasir Offline (POS)

​

Alur 2: Order dari Channel Online (QuinnOrder → CompanyPOSTransaction)

​

Alur 3: Order Cancellation & Inventory Rollback

​

RBAC — Role-Based Access Control untuk Order Status Transition

​

Catatan RBAC (Bahasa Indonesia)

1. Kasir hanya bisa mengelola order di tahap awal (pending, confirmed) dan menyelesaikan order (served → completed). Kasir tidak bisa membatalkan order yang sudah masuk dapur.
2. Kitchen Staff memiliki kendali penuh atas alur dapur: confirmed → preparing → ready. Mereka juga bisa membatalkan order jika item habis atau ada kendala masak.
3. Server / Fulfillment hanya bisa melakukan transisi ready → served. Mereka tidak bisa memulai atau membatalkan order.
4. Manager memiliki akses hampir penuh — bisa melakukan semua transisi kecuali void (kesalahan administratif).
5. Admin dan Owner memiliki akses penuh ke semua transisi, termasuk void (penghapusan administratif) yang memerlukan audit trail.
6. Void hanya bisa dilakukan oleh Admin atau Owner karena bersifat irreversible dari sisi audit — order yang di-void tidak bisa dikembalikan.

​

RLS (Row-Level Security)

{
  "$or": [
    {
      "$and": [
        { "data.company_id": "{{user.data.active_company_id}}" },
        { "data.company_id": { "$nin": [null, ""] } }
      ]
    },
    { "created_by_id": "{{user.id}}" },
    { "user_condition": { "role": "admin" } }
  ]
}

​

BroadcastChannel Sync — snishop_order_queue

​

Gambaran Umum

​

Payload Message

interface OrderQueueMessage {
  type: 'NEW_ORDER' | 'STATUS_CHANGE' | 'ORDER_REMOVED' | 'REFRESH';
  order_id: string;             // CompanyPOSTransaction._id
  transaction_number?: string;  // TRX-YYYYMMDD-XXXXXX
  new_status?: string;          // Nilai order_status baru
  previous_status?: string;     // Nilai order_status sebelumnya
  timestamp: string;            // ISO 8601 datetime
  actor?: string;               // User ID yang melakukan perubahan
  channel?: string;             // Sales channel asal order
}

​

Event Types

​

Implementasi Teknis

// 1. Inisialisasi BroadcastChannel
const bc = new BroadcastChannel('snishop_order_queue');

// 2. Kirim pesan setelah transisi status berhasil
function broadcastOrderChange(orderId, newStatus, previousStatus, actor) {
  bc.postMessage({
    type: 'STATUS_CHANGE',
    order_id: orderId,
    new_status: newStatus,
    previous_status: previousStatus,
    timestamp: new Date().toISOString(),
    actor: actor,
  });
}

// 3. Terima pesan dari tab lain
bc.onmessage = (event) => {
  const { type, order_id, new_status } = event.data;

  if (type === 'NEW_ORDER') {
    // Trigger notifikasi & sound
    showBrowserNotification(order_id);
    playSoundAlert();
    // Refetch data
    refetchOrders();
  }

  if (type === 'STATUS_CHANGE') {
    // Update order di Kanban board
    moveOrderToColumn(order_id, new_status);
  }

  if (type === 'REFRESH') {
    refetchOrders();
  }
};

​

Fallback & Lapisan Real-Time

​

Best Practices untuk Developer

1. Selalu broadcast setelah mutation — setiap kali transitionPOSOrderStatus dipanggil dan berhasil, kirim pesan ke BroadcastChannel.
2. Jangan broadcast sebelum DB confirmed — tunggu response sukses dari server sebelum broadcast, agar tab lain tidak mendapat data yang belum committed.
3. Debounce refetch — jika banyak pesan diterima dalam waktu singkat (misal 5 order masuk bersamaan), debounce refetch agar tidak terlalu banyak API call.
4. Close channel on unmount — panggil bc.close() saat komponen unmount untuk mencegah memory leak.
5. Handle stale data — jika order di tab A sudah completed tapi tab B masih menampilkan sebagai pending, WebSocket subscribe akan mengoreksi dalam < 500ms.

​

Ringkasan Arsitektur Order Queue

​

Penjelasan Arsitektur (Bahasa Indonesia)