# LSM Web Portal - Flow Aplikasi & Relasi Database

## 📋 Daftar Isi
1. [Gambaran Umum Aplikasi](#gambaran-umum-aplikasi)
2. [Flow Proses Bisnis Utama](#flow-proses-bisnis-utama)
3. [Struktur Database & Relasi Tabel](#struktur-database--relasi-tabel)
4. [Dampak Relasi Terhadap Transaksi](#dampak-relasi-terhadap-transaksi)
5. [Integrasi dengan Sistem ERP (QAD)](#integrasi-dengan-sistem-erp-qad)

---

## 🎯 Gambaran Umum Aplikasi

### Tujuan Aplikasi
LSM (Laporan Stok Malam) Web Portal adalah sistem manajemen inventori restoran yang mengotomatisasi:
- Pencatatan stok harian (menggantikan proses manual Excel)
- Perhitungan kebutuhan pemesanan barang (SPB - Surat Permintaan Barang)
- Pembuatan Delivery Order (DO) untuk integrasi dengan ERP
- Pelaporan dan monitoring stok real-time

### Pengguna Sistem
1. **Staff Store**: Input stok harian, kelola SPB
2. **Store Manager (SM)**: Approve dan monitor transaksi store
3. **Senior Store Manager (SSM)**: Review forecast, monitor multi-store
4. **SDP/HO (Head Office)**: Maintain master data, upload forecast
5. **PPIC**: Validasi order, monitor pengiriman
6. **Management**: Lihat laporan dan analitik

---

## 🔄 Flow Proses Bisnis Utama

### 1. Setup Master Data (Dilakukan oleh SDP/HO)
```
┌─────────────────────────────────────────────────────────┐
│ MASTER DATA SETUP                                       │
├─────────────────────────────────────────────────────────┤
│ 1. Sync dari ERP (QAD):                                │
│    • Stores (Cabang Restoran)                          │
│    • Menus (Menu Restoran)                             │
│    • Raw Materials/Items (Bahan Baku)                  │
│    • Item Conversions (Konversi Satuan)               │
│                                                         │
│ 2. Setup Manual:                                        │
│    • Range DOI (Days of Inventory)                     │
│    • FSTR (Formula/Resep Masakan)                      │
│    • Reason Adjustments (Alasan Penyesuaian)          │
│    • Shipment Deliveries (Jadwal Pengiriman)          │
│    • Holidays (Hari Libur)                             │
│    • Sales Types (Jenis Penjualan)                     │
│    • Armada Types (Jenis Kendaraan)                    │
│    • Periods (Periode Pelaporan)                       │
└─────────────────────────────────────────────────────────┘
```

### 2. Upload & Review Forecast (Bulanan)
```
┌─────────────────────────────────────────────────────────┐
│ FORECAST MANAGEMENT                                     │
├─────────────────────────────────────────────────────────┤
│ Step 1: SDP/HO Upload Forecast                         │
│    • Upload file Excel berisi forecast penjualan       │
│    • Data forecast per store, per item, per hari       │
│         ↓                                               │
│ Step 2: SSM Review & Adjust                            │
│    • Review forecast yang di-upload                    │
│    • Sesuaikan dengan kondisi aktual                   │
│         ↓                                               │
│ Step 3: SM Set Target Sisa Malam (TSM)                │
│    • Tentukan target stok yang harus tersisa           │
│    • TSM = buffer stock untuk operasional              │
└─────────────────────────────────────────────────────────┘
```


### 3. Proses Harian - Stock Opname (SO/LSM)
```
┌─────────────────────────────────────────────────────────┐
│ DAILY STOCK OPNAME (Setiap Malam)                      │
├─────────────────────────────────────────────────────────┤
│ Waktu: Setiap malam setelah tutup operasional          │
│ PIC: Staff Store                                        │
│                                                         │
│ Step 1: Buat Stock Opname Baru                         │
│    • Pilih tanggal SO (hari H)                         │
│    • Sistem auto-load semua item untuk store           │
│         ↓                                               │
│ Step 2: Input Stok Fisik                               │
│    • Input Qty Utuh (kemasan utuh)                     │
│    • Input Qty Pakai (kemasan terbuka/terpakai)       │
│    • Sistem auto-convert ke satuan standar             │
│         ↓                                               │
│ Step 3: Sistem Hitung Ending Stock                     │
│    Formula:                                             │
│    Ending Stock = (Qty Utuh × Conversion) + Qty Pakai │
│         ↓                                               │
│ Step 4: Adjustment (jika perlu)                        │
│    • Tambah/kurangi qty dengan alasan tertentu         │
│    • Contoh: Big Order, GM Day, Forecast Issue         │
│         ↓                                               │
│ Step 5: Save & Submit                                  │
│    • Save: Simpan sebagai Draft (bisa edit)            │
│    • Submit: Lock data, siap generate SPB              │
│                                                         │
│ ⚠️ ATURAN PENTING:                                      │
│    • Input hanya boleh hari H (tidak boleh backdate)   │
│    • Edit window: sampai jam 11:00 H+1                 │
│    • Setelah submit, data tidak bisa diubah            │
└─────────────────────────────────────────────────────────┘
```

### 4. Generate SPB (Surat Permintaan Barang)
```
┌─────────────────────────────────────────────────────────┐
│ SPB GENERATION (Otomatis dari SO)                      │
├─────────────────────────────────────────────────────────┤
│ Trigger: Setelah SO di-submit                          │
│ PIC: Staff Store / Store Manager                       │
│                                                         │
│ Step 1: Sistem Hitung Kebutuhan                        │
│    Formula SPB:                                         │
│    Suggested Qty = (Forecast - Ending Stock) + TSM     │
│                                                         │
│    Dimana:                                              │
│    • Forecast = Proyeksi penjualan dari forecast       │
│    • Ending Stock = Hasil SO malam sebelumnya          │
│    • TSM = Target Sisa Malam (buffer stock)            │
│         ↓                                               │
│ Step 2: Review & Adjustment                            │
│    • Review suggested qty dari sistem                  │
│    • Adjust qty jika perlu (dengan alasan)             │
│    • Sistem tampilkan alert:                           │
│      - Forecast Alert (variance vs forecast)           │
│      - DOI Status (Critical/Normal/Safe)               │
│         ↓                                               │
│ Step 3: Finalisasi SPB                                 │
│    • Final Qty = Suggested Qty + Adjusted Qty          │
│    • Generate SPB Number (auto)                        │
│    • Status: Draft → Submitted → Approved              │
│                                                         │
│ 📊 JENIS SPB:                                           │
│    • SPB Regular: Pemesanan rutin harian               │
│    • SPB Tambahan: Pemesanan di luar regular           │
│    • SPB Batalan: Pembatalan/perubahan SPB             │
└─────────────────────────────────────────────────────────┘
```

### 5. Generate Delivery Order (DO)
```
┌─────────────────────────────────────────────────────────┐
│ DELIVERY ORDER GENERATION                               │
├─────────────────────────────────────────────────────────┤
│ Trigger: Setelah SPB Approved                          │
│ PIC: PPIC / Store Manager                              │
│                                                         │
│ Step 1: Generate DO dari SPB                           │
│    • Pilih SPB yang sudah approved                     │
│    • Sistem create DO dengan detail items             │
│         ↓                                               │
│ Step 2: Generate CSV File                              │
│    • Sistem export DO ke format CSV                    │
│    • Format sesuai requirement ERP (QAD)               │
│         ↓                                               │
│ Step 3: Kirim ke ERP                                   │
│    • Upload CSV ke sistem QAD                          │
│    • QAD proses untuk pengiriman barang                │
│         ↓                                               │
│ Step 4: Mark as Sent                                   │
│    • Update status DO: Generated → Sent                │
│    • Tracking untuk monitoring pengiriman              │
└─────────────────────────────────────────────────────────┘
```


### 6. Flow Diagram Lengkap
```
┌──────────────┐
│ MASTER DATA  │ ← Sync dari ERP (Stores, Menus, Items)
│   SETUP      │ ← Setup Manual (DOI, FSTR, Schedules)
└──────┬───────┘
       │
       ↓
┌──────────────┐
│   FORECAST   │ ← Upload Excel (SDP/HO)
│  MANAGEMENT  │ ← Review & Adjust (SSM)
│              │ ← Set TSM (SM)
└──────┬───────┘
       │
       ↓
┌──────────────┐
│ STOCK OPNAME │ ← Input Qty Utuh & Pakai (Staff Store)
│   (MALAM)    │ ← Auto Convert & Calculate
│              │ ← Submit (Lock Data)
└──────┬───────┘
       │
       ↓
┌──────────────┐
│ GENERATE SPB │ ← Auto Calculate: (Forecast - SO) + TSM
│              │ ← Review & Adjust (SM)
│              │ ← Submit & Approve
└──────┬───────┘
       │
       ↓
┌──────────────┐
│ GENERATE DO  │ ← Create DO dari SPB
│              │ ← Export CSV untuk ERP
│              │ ← Send to QAD
└──────┬───────┘
       │
       ↓
┌──────────────┐
│   LAPORAN    │ ← LSM Report
│              │ ← DOI Report
│              │ ← Compliance Report
│              │ ← Adjusted Item Report
└──────────────┘
```

---

## 🗄️ Struktur Database & Relasi Tabel

### Kategori Tabel

#### 1. Master Data Tables
```
m_stores                    → Data cabang restoran
m_menus                     → Data menu restoran
m_raw_materials             → Data bahan baku/item
m_item_conversions          → Konversi satuan item
m_range_dois                → Range Days of Inventory
m_fstrs                     → Formula/resep masakan
m_fstr_details              → Detail bahan dalam resep
m_reason_adjustments        → Alasan penyesuaian
m_shipment_schedules        → Jadwal pengiriman (DCKP/DSLK)
m_shipment_suppliers        → Jadwal supplier
m_holidays                  → Data hari libur
m_sales_types               → Jenis penjualan
m_armada_types              → Jenis kendaraan pengiriman
m_periods                   → Periode pelaporan
m_numbering_formats         → Format penomoran SPB
m_target_sisa_malam         → Target sisa malam per item
```

#### 2. Transaction Tables
```
t_forecasts                 → Header forecast
t_forecast_details          → Detail forecast per item
t_stock_opnames             → Header stock opname (LSM)
t_stock_opname_details      → Detail SO per item
t_stock_opname_change_logs  → Log perubahan SO
t_item_requests             → Header SPB
t_item_request_details      → Detail SPB per item
t_item_request_cancellations → Pembatalan SPB
t_delivery_orders           → Header Delivery Order
t_delivery_order_details    → Detail DO per item
t_stock_movements           → Pergerakan stok
t_current_stocks            → Stok terkini per store
```

#### 3. System Tables
```
users                       → Data pengguna
roles                       → Role/jabatan
permissions                 → Hak akses
role_has_permissions        → Mapping role-permission
model_has_roles             → Mapping user-role
user_stores                 → Mapping user-store
qad_sync_logs               → Log sinkronisasi QAD
```


### Relasi Antar Tabel Utama

#### Relasi 1: Stock Opname Flow
```
┌─────────────────┐
│  m_stores       │
│  (Cabang)       │
└────────┬────────┘
         │ 1
         │
         │ N
┌────────▼────────────┐
│ t_stock_opnames     │ ← Header SO
│ - so_number         │
│ - store_id          │
│ - so_date           │
│ - status            │
└────────┬────────────┘
         │ 1
         │
         │ N
┌────────▼─────────────────┐         ┌──────────────────┐
│ t_stock_opname_details   │ N ────→ │ m_raw_materials  │
│ - stock_opname_id        │         │ (Bahan Baku)     │
│ - raw_material_id        │         └──────────────────┘
│ - qty_utuh               │
│ - qty_pakai              │
│ - qty_converted          │
│ - qty_total (ending)     │
└──────────────────────────┘
```

**Dampak Relasi:**
- Satu Store bisa punya banyak Stock Opname (history harian)
- Satu SO punya banyak detail items
- Setiap detail SO terhubung ke master raw material
- Jika raw material dihapus/diubah, akan affect semua SO history
- Ending stock dari SO digunakan untuk calculate SPB

#### Relasi 2: Forecast Flow
```
┌─────────────────┐
│  m_stores       │
└────────┬────────┘
         │ 1
         │
         │ N
┌────────▼────────────┐
│ t_forecasts         │ ← Header Forecast
│ - store_id          │
│ - period_start      │
│ - period_end        │
│ - status            │
└────────┬────────────┘
         │ 1
         │
         │ N
┌────────▼─────────────────┐         ┌──────────────────┐
│ t_forecast_details       │ N ────→ │ m_raw_materials  │
│ - forecast_id            │         └──────────────────┘
│ - raw_material_id        │
│ - forecast_date          │         ┌──────────────────┐
│ - forecast_qty           │ N ────→ │ m_menus          │
│ - menu_id (optional)     │         └──────────────────┘
└──────────────────────────┘
```

**Dampak Relasi:**
- Forecast per store, per periode
- Detail forecast per item, per hari
- Bisa dikaitkan dengan menu tertentu
- Data forecast digunakan dalam perhitungan SPB
- Jika forecast tidak ada, SPB tetap bisa dibuat tapi dengan warning

#### Relasi 3: SPB (Item Request) Flow
```
┌─────────────────┐
│ t_stock_opnames │ ← SO sebelumnya
└────────┬────────┘
         │ 1
         │
         │ 1
┌────────▼────────────┐         ┌──────────────────────┐
│ t_item_requests     │ 1 ────→ │ m_stores             │
│ - spb_number        │         └──────────────────────┘
│ - store_id          │
│ - stock_opname_id   │         ┌──────────────────────┐
│ - request_type      │ 1 ────→ │ m_shipment_schedules │
│ - shipment_id       │         │ (Jadwal Kirim)       │
│ - status            │         └──────────────────────┘
└────────┬────────────┘
         │ 1
         │
         │ N
┌────────▼─────────────────┐         ┌──────────────────┐
│ t_item_request_details   │ N ────→ │ m_raw_materials  │
│ - item_request_id        │         └──────────────────┘
│ - raw_material_id        │
│ - forecast_qty           │ ← Dari forecast
│ - so_qty                 │ ← Dari SO (ending stock)
│ - tsm_qty                │ ← Target Sisa Malam
│ - suggested_qty          │ ← (Forecast - SO) + TSM
│ - adjusted_qty           │ ← Manual adjustment
│ - final_qty              │ ← Suggested + Adjusted
│ - alert_status           │ ← DOI status
└──────────────────────────┘
```

**Dampak Relasi:**
- SPB terhubung ke SO sebelumnya (untuk ambil ending stock)
- SPB terhubung ke shipment schedule (untuk jadwal kirim)
- Detail SPB calculate otomatis dari: Forecast, SO, dan TSM
- Jika SO tidak ada, SPB tidak bisa di-generate
- Jika forecast tidak ada, suggested qty = 0 + adjustment
- Final qty adalah yang akan dikirim ke warehouse


#### Relasi 4: Delivery Order Flow
```
┌─────────────────┐
│ t_item_requests │ ← SPB yang approved
└────────┬────────┘
         │ 1
         │
         │ N
┌────────▼────────────┐         ┌──────────────────┐
│ t_delivery_orders   │ 1 ────→ │ m_stores         │
│ - do_number         │         └──────────────────┘
│ - item_request_id   │
│ - store_id          │
│ - do_date           │
│ - csv_file_path     │ ← File untuk ERP
│ - status            │
└────────┬────────────┘
         │ 1
         │
         │ N
┌────────▼─────────────────┐         ┌──────────────────┐
│ t_delivery_order_details │ N ────→ │ m_raw_materials  │
│ - delivery_order_id      │         └──────────────────┘
│ - raw_material_id        │
│ - qty_ordered            │ ← Dari SPB final_qty
│ - uom                    │
└──────────────────────────┘
```

**Dampak Relasi:**
- DO dibuat dari SPB yang sudah approved
- Satu SPB bisa generate satu atau lebih DO
- DO generate CSV file untuk dikirim ke ERP (QAD)
- Jika SPB diubah setelah DO dibuat, DO tidak ter-update otomatis
- DO adalah final document untuk warehouse

#### Relasi 5: Item Conversion & Calculation
```
┌──────────────────┐
│ m_raw_materials  │
│ - code           │
│ - name           │
│ - uom            │ ← Unit of Measure (KG, PCS, dll)
└────────┬─────────┘
         │ 1
         │
         │ 1
┌────────▼─────────────────┐
│ m_item_conversions       │
│ - raw_material_id        │
│ - conversion_factor      │ ← Faktor konversi
│ - from_uom               │ ← Satuan asal (PCS)
│ - to_uom                 │ ← Satuan tujuan (KG)
└──────────────────────────┘

Contoh Penggunaan:
- Item: Tepung Terigu
- UOM: KG
- Conversion: 1 Karton (PCS) = 10 KG
- 
- Input SO:
  Qty Utuh: 5 karton
  Qty Pakai: 3 kg
  
- Calculation:
  Qty Converted = 5 × 10 = 50 kg
  Ending Stock = 50 + 3 = 53 kg
```

**Dampak Relasi:**
- Conversion factor sangat critical untuk akurasi perhitungan
- Jika conversion salah, semua perhitungan SO dan SPB akan salah
- Perubahan conversion factor tidak affect data history
- Setiap item harus punya conversion yang benar

#### Relasi 6: Target Sisa Malam (TSM)
```
┌──────────────────┐
│ m_stores         │
└────────┬─────────┘
         │ 1
         │
         │ N
┌────────▼─────────────────┐         ┌──────────────────┐
│ m_target_sisa_malam      │ N ────→ │ m_raw_materials  │
│ - store_id               │         └──────────────────┘
│ - raw_material_id        │
│ - target_qty             │ ← Buffer stock yang diinginkan
│ - is_active              │
└──────────────────────────┘

Penggunaan dalam SPB:
Suggested Qty = (Forecast - Ending Stock) + TSM

Contoh:
- Forecast: 100 kg
- Ending Stock (dari SO): 20 kg
- TSM: 15 kg
- Suggested Qty = (100 - 20) + 15 = 95 kg
```

**Dampak Relasi:**
- TSM per store, per item
- TSM mempengaruhi suggested qty di SPB
- Jika TSM tidak diset, default = 0
- TSM bisa diubah sewaktu-waktu oleh SM
- Perubahan TSM langsung affect SPB berikutnya


---

## ⚠️ Dampak Relasi Terhadap Transaksi

### 1. Dampak Perubahan Master Data

#### A. Perubahan Raw Material
```
Skenario: Raw Material "Tepung Terigu" diubah/dihapus

Dampak:
✗ SO yang sudah ada: Tetap tampil (data history)
✗ SPB yang sudah ada: Tetap tampil (data history)
✗ DO yang sudah ada: Tetap tampil (data history)
✓ SO baru: Tidak bisa input item tersebut
✓ SPB baru: Tidak bisa order item tersebut

Solusi:
- Jangan hapus raw material yang sudah pernah digunakan
- Gunakan flag is_active = false untuk non-aktifkan
- Soft delete dengan delete_flag = 1
```

#### B. Perubahan Conversion Factor
```
Skenario: Conversion factor diubah dari 10 ke 12

Dampak:
✗ SO lama: Tetap pakai conversion lama (53 kg)
✓ SO baru: Pakai conversion baru
  Qty Utuh: 5 karton
  Qty Converted = 5 × 12 = 60 kg (bukan 50 kg)
  Ending Stock = 60 + 3 = 63 kg

⚠️ PERHATIAN:
- Perubahan conversion affect akurasi perhitungan
- Bisa menyebabkan over/under stock
- Harus dikomunikasikan ke semua store
```

#### C. Perubahan Store
```
Skenario: Store "Cabang A" di-nonaktifkan

Dampak:
✗ Data history: Tetap ada (SO, SPB, DO lama)
✓ Transaksi baru: Tidak bisa create SO/SPB
✓ User access: User tidak bisa akses store tersebut
✓ Forecast: Tidak bisa upload forecast untuk store ini

Solusi:
- Gunakan is_active flag, jangan hapus store
- Archive data lama untuk reporting
```

### 2. Dampak Perubahan Transaksi

#### A. Edit Stock Opname
```
Skenario: SO sudah submit, mau edit qty

Aturan:
✓ Status Draft: Bisa edit kapan saja
✗ Status Submitted: Tidak bisa edit
✗ Sudah generate SPB: Tidak bisa edit SO

Dampak jika bisa edit:
- SPB yang sudah dibuat jadi tidak valid
- Ending stock berubah
- Suggested qty SPB harus di-recalculate
- DO yang sudah dibuat jadi salah

Solusi:
- Lock SO setelah submit
- Jika perlu koreksi, buat adjustment di SPB
```

#### B. Edit SPB
```
Skenario: SPB sudah approved, mau ubah qty

Aturan:
✓ Status Draft: Bisa edit
✓ Status Submitted: Bisa edit (sebelum approved)
✗ Status Approved: Tidak bisa edit
✗ Sudah generate DO: Tidak bisa edit

Dampak jika bisa edit:
- DO yang sudah dibuat jadi tidak match
- CSV yang sudah dikirim ke ERP jadi salah
- Warehouse sudah prepare barang

Solusi:
- Gunakan SPB Batalan untuk koreksi
- Create SPB Tambahan untuk order lebih
```

#### C. Hapus Forecast
```
Skenario: Forecast bulan ini dihapus

Dampak:
✗ SPB yang sudah dibuat: Tetap ada (pakai forecast lama)
✓ SPB baru: Suggested qty = 0 (no forecast)
✓ System alert: "No Forecast Available"

Solusi:
- Jangan hapus forecast yang sudah digunakan
- Upload forecast baru untuk replace
- Pastikan forecast selalu ada sebelum periode dimulai
```

### 3. Dampak Integritas Data

#### A. Orphan Records
```
Problem: Data detail tanpa header

Contoh:
- SO Detail tanpa SO Header
- SPB Detail tanpa SPB Header
- DO Detail tanpa DO Header

Penyebab:
- Delete cascade tidak jalan
- Manual delete di database
- Error saat save transaction

Dampak:
- Data tidak konsisten
- Report jadi salah
- Tidak bisa trace history

Pencegahan:
- Gunakan soft delete (delete_flag)
- Implement proper cascade delete
- Transaction rollback jika error
```

#### B. Duplicate Data
```
Problem: Data kembar

Contoh:
- SO dengan tanggal sama untuk store sama
- SPB Number duplicate
- DO Number duplicate

Penyebab:
- Concurrent insert
- Auto-numbering error
- Manual input

Dampak:
- Confusion dalam tracking
- Report double count
- ERP integration error

Pencegahan:
- Unique constraint di database
- Proper locking mechanism
- Validation sebelum save
```


---

## 🔗 Integrasi dengan Sistem ERP (QAD)

### 1. Data yang Di-Sync dari QAD ke LSM

#### A. Master Stores (Cabang)
```
Frekuensi: On-demand / Manual trigger
Method: API Call / CSV Import

Data yang di-sync:
- Store Code (QAD Code)
- Store Name
- Store Address
- Store Type
- Status (Active/Inactive)

Flow:
QAD → API → LSM Controller → Database
     ↓
  Sync Log (Success/Failed)
```

#### B. Master Menus
```
Frekuensi: On-demand / Manual trigger
Method: API Call

Data yang di-sync:
- Menu Code (PLU Code)
- Menu Name
- Menu Category
- Price
- Status

Penggunaan di LSM:
- Reference untuk forecast
- Tidak affect langsung ke SO/SPB
```

#### C. Master Raw Materials (Items)
```
Frekuensi: Daily / On-demand
Method: API Call

Data yang di-sync:
- Item Code (QAD Item Code)
- Item Name
- UOM (Unit of Measure)
- Category
- Status

⚠️ CRITICAL:
- Item ini yang digunakan di SO dan SPB
- Jika item tidak sync, tidak bisa order
- Conversion factor harus di-maintain manual di LSM
```

#### D. Item Conversions
```
Frekuensi: On-demand
Method: API Call / Manual Setup

Data yang di-sync:
- Item Code
- Conversion Factor
- From UOM
- To UOM

Contoh:
QAD: 1 Karton = 10 KG
LSM: Simpan conversion 1:10
```

### 2. Data yang Dikirim dari LSM ke QAD

#### A. Delivery Order (DO)
```
Frekuensi: Setelah SPB Approved
Method: CSV File Upload

Format CSV:
DO_Number, Store_Code, Item_Code, Qty, UOM, Delivery_Date

Contoh:
DO-2024-001, ST001, RM001, 100, KG, 2024-01-15
DO-2024-001, ST001, RM002, 50, PCS, 2024-01-15

Flow:
LSM Generate DO → Export CSV → Upload ke QAD
                              ↓
                    QAD Process untuk Warehouse
                              ↓
                    Warehouse Prepare & Ship
```

#### B. Status Update (Optional)
```
Jika ada integrasi real-time:

LSM → QAD:
- DO Created
- DO Sent
- DO Confirmed

QAD → LSM:
- DO Received by Warehouse
- DO Shipped
- DO Delivered
```

### 3. Sync Process & Error Handling

#### A. Sync Stores
```
Process:
1. User klik "Sync Stores" di LSM
2. LSM call QAD API
3. QAD return list of stores
4. LSM process each store:
   - If exists: Update
   - If new: Insert
5. Log result to qad_sync_logs

Error Handling:
- Connection timeout: Retry 3x
- Invalid data: Skip & log error
- Duplicate: Update existing
- API error: Log & notify admin

Success Rate:
- Target: 100% success
- Acceptable: 95% success
- Alert if < 90%
```

#### B. Sync Items
```
Process:
1. Scheduled job (daily 02:00 AM)
2. LSM call QAD API for new/updated items
3. Process in batch (100 items per batch)
4. Update LSM database
5. Send notification if error

Critical Items:
- Items yang sering digunakan
- Items dengan stock critical
- New items yang baru ditambahkan

Monitoring:
- Last sync time
- Success count
- Error count
- Failed items list
```

### 4. Data Consistency & Validation

#### A. Master Data Validation
```
Sebelum Sync:
✓ Check QAD connection
✓ Validate data format
✓ Check for duplicates
✓ Verify required fields

Setelah Sync:
✓ Compare record count
✓ Validate key fields
✓ Check for orphan records
✓ Generate sync report
```

#### B. Transaction Data Validation
```
Sebelum Send DO:
✓ Validate DO format
✓ Check item codes exist in QAD
✓ Verify store codes
✓ Validate quantities
✓ Check delivery dates

Setelah Send:
✓ Confirm receipt by QAD
✓ Validate processing status
✓ Check for errors
✓ Update LSM status
```

### 5. Sync Logs & Monitoring

#### Table: qad_sync_logs
```sql
Columns:
- id
- sync_type (stores, menus, items, conversions)
- sync_direction (qad_to_lsm, lsm_to_qad)
- status (success, failed, partial)
- records_processed
- records_success
- records_failed
- error_details (JSON)
- request_details (JSON)
- response_details (JSON)
- duration_seconds
- created_at

Monitoring Dashboard:
- Last sync time per type
- Success rate (%)
- Average duration
- Error trends
- Failed records list
```


---

## 📊 Contoh Kasus Lengkap

### Kasus: Proses Harian Store "Cabang Senayan"

#### Hari 1 (Senin) - Setup & Forecast
```
08:00 - SDP Upload Forecast
- Upload Excel forecast untuk minggu ini
- Forecast untuk Cabang Senayan:
  * Tepung Terigu: 100 kg/hari
  * Minyak Goreng: 50 liter/hari
  * Telur: 200 butir/hari

10:00 - SSM Review Forecast
- Review forecast yang di-upload
- Adjust berdasarkan event:
  * Ada promo hari Rabu → increase 20%
  * Tepung Terigu: 120 kg (Rabu)

14:00 - SM Set Target Sisa Malam
- Set TSM untuk setiap item:
  * Tepung Terigu: 15 kg (buffer 1 hari)
  * Minyak Goreng: 10 liter
  * Telur: 50 butir
```

#### Hari 1 (Senin) - Malam (Stock Opname)
```
22:00 - Staff Store Input SO
Store: Cabang Senayan
Tanggal: 2024-01-15

Item 1: Tepung Terigu
- Qty Utuh: 2 karton (1 karton = 10 kg)
- Qty Pakai: 5 kg
- Conversion: 2 × 10 = 20 kg
- Ending Stock: 20 + 5 = 25 kg

Item 2: Minyak Goreng
- Qty Utuh: 3 jerigen (1 jerigen = 5 liter)
- Qty Pakai: 2 liter
- Conversion: 3 × 5 = 15 liter
- Ending Stock: 15 + 2 = 17 liter

Item 3: Telur
- Qty Utuh: 5 tray (1 tray = 30 butir)
- Qty Pakai: 10 butir
- Conversion: 5 × 30 = 150 butir
- Ending Stock: 150 + 10 = 160 butir

22:30 - Submit SO
- Status: Draft → Submitted
- SO Number: SO-SEN-20240115-001
- Data locked, tidak bisa edit
```

#### Hari 2 (Selasa) - Pagi (Generate SPB)
```
07:00 - SM Generate SPB dari SO
Store: Cabang Senayan
Tanggal: 2024-01-16
Referensi SO: SO-SEN-20240115-001

Perhitungan Otomatis:

Item 1: Tepung Terigu
- Forecast (Selasa): 100 kg
- Ending Stock (dari SO): 25 kg
- TSM: 15 kg
- Suggested Qty = (100 - 25) + 15 = 90 kg
- Adjustment: +10 kg (ada catering order)
- Final Qty: 100 kg

Item 2: Minyak Goreng
- Forecast: 50 liter
- Ending Stock: 17 liter
- TSM: 10 liter
- Suggested Qty = (50 - 17) + 10 = 43 liter
- Adjustment: 0
- Final Qty: 43 liter

Item 3: Telur
- Forecast: 200 butir
- Ending Stock: 160 butir
- TSM: 50 butir
- Suggested Qty = (200 - 160) + 50 = 90 butir
- Adjustment: 0
- Final Qty: 90 butir

08:00 - Review & Submit SPB
- SPB Number: SPB-SEN-20240116-001
- Status: Draft → Submitted
- Menunggu approval

10:00 - Manager Approve SPB
- Status: Submitted → Approved
- Siap generate DO
```

#### Hari 2 (Selasa) - Siang (Generate DO)
```
11:00 - PPIC Generate DO
DO Number: DO-20240116-001
Store: Cabang Senayan
Delivery Date: 2024-01-17 (H+1)

Items:
1. Tepung Terigu: 100 kg
2. Minyak Goreng: 43 liter
3. Telur: 90 butir

11:30 - Export CSV
File: DO-20240116-001.csv
Content:
DO-20240116-001,SEN,RM001,100,KG,2024-01-17
DO-20240116-001,SEN,RM002,43,LITER,2024-01-17
DO-20240116-001,SEN,RM003,90,PCS,2024-01-17

12:00 - Upload ke QAD
- Upload CSV ke sistem QAD
- QAD process untuk warehouse
- Status: Generated → Sent

14:00 - Warehouse Process
- Warehouse terima DO dari QAD
- Prepare barang sesuai DO
- Schedule pengiriman besok pagi
```

#### Hari 3 (Rabu) - Pagi (Terima Barang)
```
08:00 - Barang Sampai di Store
- Driver deliver barang
- Staff store terima & cek fisik
- Cocokkan dengan DO

Items Diterima:
✓ Tepung Terigu: 100 kg (sesuai)
✓ Minyak Goreng: 43 liter (sesuai)
✓ Telur: 90 butir (sesuai)

08:30 - Update Stock
- Input penerimaan barang
- Update current stock
- Siap untuk operasional hari ini

New Stock:
- Tepung Terigu: 25 (sisa kemarin) + 100 (baru) = 125 kg
- Minyak Goreng: 17 + 43 = 60 liter
- Telur: 160 + 90 = 250 butir
```

#### Hari 3 (Rabu) - Malam (SO Lagi)
```
22:00 - Stock Opname Hari Rabu
(Proses berulang seperti hari Senin)

Ending Stock setelah operasional:
- Tepung Terigu: 30 kg (pakai 95 kg)
- Minyak Goreng: 15 liter (pakai 45 liter)
- Telur: 80 butir (pakai 170 butir)

Note: Pemakaian lebih tinggi karena ada promo
```

### Analisis Kasus

#### 1. Akurasi Forecast
```
Item: Tepung Terigu (Rabu)
- Forecast: 120 kg (sudah di-adjust untuk promo)
- Actual Usage: 95 kg
- Variance: -25 kg (-20.8%)
- Status: ✓ Under forecast (aman)

Item: Telur (Rabu)
- Forecast: 200 butir
- Actual Usage: 170 butir
- Variance: -30 butir (-15%)
- Status: ✓ Under forecast (aman)
```

#### 2. Efektivitas TSM
```
Item: Tepung Terigu
- TSM Setting: 15 kg
- Actual Ending: 30 kg
- Status: ✓ Above TSM (aman)

Item: Minyak Goreng
- TSM Setting: 10 liter
- Actual Ending: 15 liter
- Status: ✓ Above TSM (aman)

Item: Telur
- TSM Setting: 50 butir
- Actual Ending: 80 butir
- Status: ✓ Above TSM (aman)

Kesimpulan: TSM setting sudah tepat
```

#### 3. Efisiensi Proses
```
Timeline:
- SO Input: 22:00 (30 menit)
- SPB Generate: 07:00 (1 jam)
- DO Generate: 11:00 (30 menit)
- Upload QAD: 12:00 (instant)
- Barang Sampai: 08:00 H+1

Total Lead Time: 34 jam (dari SO sampai terima barang)
Target: < 36 jam
Status: ✓ Sesuai target
```

---

## 🎓 Kesimpulan

### Keunggulan Sistem LSM Web Portal

1. **Otomasi Perhitungan**
   - Auto-calculate ending stock dari qty utuh & pakai
   - Auto-suggest SPB qty berdasarkan forecast & TSM
   - Mengurangi human error dalam perhitungan

2. **Real-time Monitoring**
   - Dashboard untuk monitor stok semua store
   - Alert untuk item critical (DOI status)
   - Tracking DO dari create sampai delivery

3. **Integrasi ERP**
   - Sync master data dari QAD
   - Export DO ke QAD dalam format CSV
   - Single source of truth untuk data

4. **Audit Trail**
   - Log semua perubahan data
   - Track siapa, kapan, apa yang diubah
   - History lengkap untuk compliance

5. **Flexible & Scalable**
   - Support multi-store
   - Support berbagai jenis SPB (Regular, Tambahan, Batalan)
   - Mudah add store/item baru

### Rekomendasi Implementasi

1. **Phase 1: Pilot (1-2 Store)**
   - Test semua flow end-to-end
   - Training user
   - Fix bugs & improve UX

2. **Phase 2: Rollout (5-10 Store)**
   - Deploy ke store lain
   - Monitor performance
   - Collect feedback

3. **Phase 3: Full Deployment**
   - Deploy ke semua store
   - Continuous improvement
   - Regular training

4. **Maintenance**
   - Daily: Monitor sync logs
   - Weekly: Review error reports
   - Monthly: Performance review
   - Quarterly: User feedback session

---

**Dokumen ini dibuat untuk membantu presentasi kepada atasan mengenai flow aplikasi LSM Web Portal, relasi database, dan dampaknya terhadap transaksi bisnis.**

*Last Updated: 2026-01-08*
