1. Fulfillment Architecture — Outbound

1.1 Flow Lengkap

STEP 1: FULFILLMENT ORDER (Kepala Packing)
│  Pilih order yang mau dikirim → pilih gudang
│  System auto-generate: Pick List (group by Area + SKU)
│  Status: pick_requested
│
STEP 2: APPROVAL (Kepala Gudang)
│  Review Pick List → Approve pengeluaran barang
│  TTD digital sebagai bukti otoritas
│  Status: approved
│  → Print Pick List untuk dibawa ke area
│
STEP 3: PICKING (Picker/Staff Gudang)
│  Ambil barang per Area sesuai Pick List
│  Confirm qty yang diambil (actual vs requested)
│  Catat discrepancy jika ada
│  Status: picked
│
STEP 4: PACKING (Packer — PIC Assigned)
│  Scan order → verify items cocok
│  Tempel resi → pack
│  SETIAP RESI DI-TRACK SIAPA YANG PACK
│  → Kalau salah packing = penalty ke packer
│  Status: packed
│
STEP 5: SORT BY EKSPEDISI
│  Group paket by kurir (JNE, J&T, SiCepat, dll)
│  BUKAN by platform (Shopee/TikTok/Mengantar)
│  → Driver kurir datang, ambil 1 pile saja
│
STEP 6: COURIER HANDOVER (Anti-Fraud)
│  Manifest serah terima per kurir
│  TTD staff gudang + TTD driver kurir
│  → Sebelum handover = tanggung jawab gudang
│  → Sesudah handover = tanggung jawab kurir
│  Status: handed_over
│
STEP 7: SIDE EFFECTS (System)
│  → Stock deduction (FEFO lot consumption)
│  → Journal generation (penjualan + HPP)
│  → Audit trail
│  → Order status: dikirim

1.2 Stock Reservation

TANPA RESERVATION:
  09:00 — Stok Ayam: 50
  09:01 — 30 order masuk (butuh 30)
  09:02 — 25 order lagi masuk (butuh 25)
  09:03 — Total butuh 55, stok cuma 50 → 5 order gagal

DENGAN RESERVATION:
  09:00 — Stok Ayam: 50 (available: 50)
  09:01 — 30 order → reserve 30 (available: 20)
  09:02 — 25 order → reserve 20, TOLAK 5 (sold out)
  → Gak ada false promise ke customer

1.3 Partial Fulfillment

Order 3 item, item C habis:
  → Opsi 1: Ship item A+B (partial), item C jadi backorder
  → Opsi 2: Hold semua sampai item C tersedia
  → Owner/admin decide (bukan auto)

Entity: FulfillmentOrderItem.qty_fulfilled bisa < qty_requested

2. Fulfillment Architecture — Inbound (Supplier)

2.1 Flow Lengkap

STEP 1: PO Created (sudah ada)
│
STEP 2: Supplier Deliver ke Gudang
│  Bisa via: sopir pabrik ATAU kurir pihak ketiga
│
STEP 3: RECEIVE & INSPECT (Goods Receipt Note)
│  ┌──────────────────────────────────────────┐
│  │ GOODS RECEIPT NOTE (GRN)                 │
│  │ GRN-260331-001                           │
│  │                                           │
│  │ Supplier: PT Frozen Food Indo             │
│  │ PO Ref: PO2603-00005                     │
│  │ Driver: Pak Joko (sopir pabrik)           │
│  │                                           │
│  │ Item              PO    Diterima  Selisih │
│  │ Forbest Ayam 1kg  500   498       -2     │
│  │ Nugget Original   200   200        0     │
│  │                                           │
│  │ Catatan: 2 pcs kemasan bocor             │
│  │                                           │
│  │ [TTD Staff Gudang]  [TTD Sopir/Kurir]    │
│  │                                           │
│  │ Copy 1: Gudang simpan                    │
│  │ Copy 2: Sopir bawa balik ke pabrik       │
│  └──────────────────────────────────────────┘
│
STEP 4: Stock In
│  → Lot created (FEFO: cost + expiry date)
│  → product.stok += qty_received
│  → stock_transaction: inbound
│  → Journal: Dr. Persediaan / Cr. Hutang (atau Kas)
│
STEP 5: Shelve ke Area
   → Staff taruh barang di Area yang ditentukan

2.2 Dua Jenis Delivery

3. Return Flows

3.1 Customer Return (RTS — Return to Sender)

Notification masuk → Paket tiba di gudang → Inspect kondisi

BAIK (bisa dijual lagi):
  → Stok masuk + lot restore
  → Reverse piutang + reverse fee
  → Dr. Retur Penjualan / Cr. Piutang + Cr. Fee

RUSAK (gak bisa dijual):
  → Stok masuk ke area "rusak"
  → Jurnal kerugian
  → Dr. Kerugian Barang Rusak / Cr. Persediaan

HILANG (paket gak sampai):
  → Gak ada stok masuk
  → Klaim ke kurir
  → Dr. Piutang Klaim Kurir / Cr. Persediaan

3.2 Supplier Return

Alasan: Cacat, expired, salah kirim, kelebihan

KALAU PO = UTANG (belum bayar):
  → Potong hutang
  → Dr. Hutang Usaha / Cr. Persediaan

KALAU PO = CASH (sudah bayar):
  Opsi 1 — Refund uang:
    → Dr. Kas / Cr. Persediaan
  Opsi 2 — Ganti barang:
    → Supplier kirim replacement → receive sebagai inbound baru

3.3 Customer Refund / Replacement

4. Entity Model — Complete

4.1 Outbound Entities

Fulfillment Order

"Surat Perintah Pengeluaran Barang" — batch of orders to fulfill

Fulfillment Order Item

Pick List

"Bon Pengeluaran Gudang" — aggregate per SKU per Area

Pick List Item

Shipment

1 resi = 1 shipment. Track packer PIC.

Courier Handover

Manifest serah terima — anti-fraud document

Packing Incident

4.2 Inbound Entity

Goods Receipt Note (GRN)

GRN Item

4.3 Entity Relationship Diagram

                OUTBOUND
Sales Order ──→ Fulfillment Order ──→ Pick List ──→ Shipment ──→ Courier Handover
                     │                   │            │
                     └── FO Items        └── PL Items  ├── packed_by (PIC)
                     (per order item)    (per SKU/Area) ├── no_resi
                                                       └── Packing Incident

                INBOUND
Purchase Order ──→ Goods Receipt Note ──→ Stock In ──→ Lot Created (FEFO)
                        │
                        └── GRN Items (qty_ordered vs qty_received vs qty_rejected)

                RETURNS
Return Record ──→ Inspect ──→ Baik (stock in + reverse) / Rusak (loss) / Hilang (claim)
Supplier Return ──→ Stock Out ──→ Potong hutang / Refund / Replacement

5. Accountability & Anti-Fraud

5.1 Chain of Custody

5.2 Inbound Anti-Fraud (GRN)

6. Inventory Intelligence — Overview

6.1 Data Input → Analytics Output

6.2 Key Metrics

6.3 Multi-Warehouse Allocation

Per SKU per gudang, track:
  • Demand rate (berapa terjual per hari di gudang ini)
  • Current stock
  • Days remaining

Rekomendasi:
  • Next PO alokasi proporsional:
    Gudang A demand 60% → alokasi 60% dari PO
    Gudang B demand 40% → alokasi 40%
  • Transfer inter-gudang kalau 1 gudang kritis, yang lain surplus

7. Forecasting Deep Dive — Methods & References

7.1 Exponential Smoothing (Holt-Winters)

7.2 Croston's Method

7.3 Demand Sensing

7.4 Promotional Uplift Modeling

7.5 Safety Stock — Static vs Dynamic

8. Demand Classification — ABC-XYZ Framework

8.1 Dua Dimensi

ABC (Value contribution — Pareto 80/20):

XYZ (Demand predictability — Coefficient of Variation):

8.2 Combined Matrix (9 Cells)

8.3 Service Level per Class

9. Campaign-Driven Demand Management

9.1 Dua Jenis Demand Event

9.2 Planned Campaign — Flow

SEBELUM CAMPAIGN:
  1. Pilih produk + set harga campaign
  2. System cek historical campaign serupa:
     "Live terakhir harga 39rb → sold 250 pcs"
  3. System suggest stock preparation:
     "Butuh 330 pcs, available 150, PO 200 pcs"
     "Supplier lead time 5 hari → PO paling lambat [tanggal]"
  4. Auto-create PO suggestion

SAAT CAMPAIGN:
  5. Monitor actual vs estimated real-time
  6. Alert kalau actual >> estimated (butuh emergency PO?)

SETELAH CAMPAIGN:
  7. Record actual volume, duration, platform
  8. Calculate accuracy (actual/estimated)
  9. Feed back ke future campaign estimates

9.3 Unplanned Spike — Detection & Response

DETECT (Realtime):
  current_demand = orders hari ini untuk SKU X
  expected_demand = moving average 14 hari
  IF current_demand > expected_demand × 2:
    → SPIKE DETECTED → Alert

ANALYZE (System bantu):
  Platform breakdown: "TikTok +407%, Shopee +87%"
  Cek campaign calendar: "Gak ada campaign hari ini"
  → Kesimpulan: UNPLANNED spike

DECIDE (Owner — BUKAN auto):
  Scenario planner:
  • Beli 300 pcs → Rp 13.5jt → cover 1.5 hari
  • Beli 700 pcs → Rp 31.5jt → cover 4 hari
  • Monitor besok → zero cost → risk stockout

  FROZEN FOOD CONSTRAINT:
  Overstock = expire = RUGI
  → System harus kasih warning shelf life

LEARN (Setelah spike selesai):
  Record: duration, peak, total volume, source
  → Improve scenario planner untuk spike berikutnya

9.4 Produk Baru — Sinyal Organik

STAGED APPROACH:

Batch 1 (Test): 100 pcs
  Monitor sell-through rate vs benchmark produk baru
  Benchmark: produk baru rata-rata jual 8% stock in 3 hari

  IF actual > benchmark × 3:
    → HOT SIGNAL → Alert: "Produk ini 7.7× di atas rata-rata"
    → Suggest immediate reorder

  IF actual < benchmark × 0.5:
    → SLOW SIGNAL → "Pertimbangkan stop restock"

Batch 2 (Scale — kalau hot):
  Qty = actual run rate × 14-30 hari

Batch 3 (Sustain):
  Sudah ada cukup data → switch ke standard forecast

9.5 Database Entities

campaign_plans:
  id, org_id, product_id
  campaign_type: "tiktok_live" | "flash_sale" | "ads_push" | "price_cut" | "bundle"
  campaign_date, duration_days
  campaign_price, normal_price
  estimated_volume (auto-suggest dari historical)
  actual_volume (post-campaign)
  po_id (PO yang dibuat untuk campaign)
  status: planning → stock_ready → active → completed
  accuracy_pct (actual/estimated × 100)

demand_snapshots (daily, per SKU per warehouse):
  product_id, warehouse_id, date
  qty_ordered, qty_shipped
  source_breakdown: jsonb {tiktok: N, shopee: N, mengantar: N}
  is_spike: boolean
  spike_event_id: FK

spike_events:
  product_id
  detected_at, started_at, ended_at
  peak_demand, total_volume, duration_days
  source: "planned_campaign" | "organic_surge" | "unknown"
  campaign_id: FK (kalau planned)
  response: "po_created" | "monitored" | "dismissed"
  po_id: FK
  outcome_notes

new_product_tracking:
  product_id
  first_po_date, initial_stock
  benchmark_sell_through
  actual_sell_through
  signal: "hot" | "normal" | "slow"
  signal_detected_at

10. New Product Introduction (NPI) Forecasting

10.1 Methods

10.2 Implementasi LabaBersih

Saat seller tambah produk baru:
  1. Prompt: "Produk ini mirip dengan produk mana?" → dropdown existing products
  2. Show reference product's daily demand
  3. Seller input adjustment: "Lebih laku / Sama / Kurang laku"
  4. System suggest: initial batch = reference demand × adjustment × 14 hari
  5. After 2-4 minggu real data → switch ke actual demand-based forecast
  6. Hot signal detection active dari hari pertama

11. Industry Reference — Who Uses What

11.1 Pattern Validation

Setiap pattern dalam dokumen ini di-cross-reference dengan SaaS/tools yang sudah proven:

11.2 Tool Comparison

11.3 Forecasting Method per Tool

12. Implementation Priority

12.1 Fulfillment

12.2 Inventory Intelligence

12.3 Frozen Food Differentiator

LabaBersih v2 — Fulfillment & Inventory Intelligence Architecture
Document version 1.0 | 31 Maret 2026
Industry references: ShipBob, ShipHero, ShipStation, Cin7, Lokad, Blue Yonder, Inventory Planner, Amazon, Walmart, SAP IBP, o9 Solutions
Forecasting references: Holt-Winters (1960), Croston (1972), ABC-XYZ Analysis, Demand Sensing (2010s)