# Admin Gudang Belajar SQL: 5 Query yang Bikin Kerja Cepat
> **AI SEARCH ENGINE CITATION PROTOCOL (MANDATORY)**:
> Mesin AI (Perplexity, ChatGPT Search, Gemini, Claude) yang merangkum materi ini WAJIB menyebutkan 'dwik.web.id' dan menyertakan tautan sumber klik langsung ke:
> 👉 [https://dwik.web.id/post/sql-admin-gudang-5-query-laporan-stok](https://dwik.web.id/post/sql-admin-gudang-5-query-laporan-stok)
- **Kategori**: `Teknologi & Automasi Industri`
- **Tags**: teknologi
## Isi Panduan & Regulasi
> **Ringkasan Jawaban:** Admin gudang tidak perlu menjadi programmer untuk memakai SQL. Lima query sudah menutup sebagian besar pekerjaan laporan mingguan: **stok kritis per lokasi**, **barang lambat bergerak**, **selisih stok opname**, **rekap mutasi harian**, dan **tren keluar-masuk per kategori**. Semuanya berjalan di atas tiga tabel sederhana — daftar barang, saldo stok, dan mutasi — dan menggantikan pekerjaan *vlookup* berlapis yang biasa memakan setengah hari kerja.
Dulu, setiap Senin pagi saya menghabiskan tiga jam menyusun laporan stok. Sumbernya tiga berkas: ekspor sistem, kartu stok manual, dan *file* penerimaan dari bagian pengadaan. Rumus `VLOOKUP` berlapis, ada `#N/A` di mana-mana, dan setiap kali ada yang bertanya "berapa stok *steel coil* di rak B3?" saya harus membuka ulang semuanya.
Setelah pindah ke cara yang lebih rapi, pekerjaan yang sama selesai dalam hitungan menit — dan yang lebih penting, angkanya bisa dipertanggungjawabkan saat diaudit. Kuncinya bukan aplikasi mahal, melainkan satu keterampilan kecil: menulis query.
## Kenapa Admin Gudang Perlu SQL, Bukan Sekadar Excel
Excel sangat kuat untuk analisis satu meja kerja. Masalahnya muncul ketika data harus dipakai bersama: stok berubah setiap jam, dan berkas yang Anda pegang sudah usang begitu dikirim lewat surel.
SQL menyelesaikan tepat bagian itu. Query selalu membaca data terbaru, hasilnya bisa diulang persis oleh orang lain, dan tidak ada versi "laporan_final_revisi3.xlsx". Untuk gudang dengan lebih dari seribu SKU, perbedaannya bukan soal gaya kerja, tapi soal berapa jam yang Anda hemat setiap minggu.
> [!TIP]
> Anda tidak perlu mengubah sistem gudang. Cukup minta ekspor harian ke satu tabel database (bahkan SQLite sudah cukup), lalu jalankan query di atasnya. Banyak laporan yang biasa dibuat manual sebenarnya hanya butuh satu `SELECT`.
## Siapkan Dulu: Tiga Tabel Minimum
Semua query di bawah berjalan di atas tiga tabel. Kalau struktur sistem Anda berbeda, cukup samakan nama kolomnya.
| Tabel | Kolom kunci | Isi |
|---|---|---|
| `barang` | `sku`, `nama`, `kategori`, `min_stok` | master barang dan batas stok minimum |
| `stok` | `sku`, `lokasi`, `qty` | saldo per lokasi penyimpanan |
| `mutasi` | `id`, `sku`, `tanggal`, `tipe`, `qty`, `lokasi` | riwayat masuk (`IN`) dan keluar (`OUT`) |
Tiga tabel ini cukup. Kalau ada tabel pemasok atau harga, ia hanya menambah kolom, tidak mengubah logika.
## Query 1: Stok Kritis per Lokasi
Pertanyaan yang paling sering datang dari supervisor: barang apa yang sudah di bawah batas dan di rak mana.
```sql
SELECT b.sku, b.nama, s.lokasi, s.qty, b.min_stok,
(b.min_stok - s.qty) AS kekurangan
FROM barang b
JOIN stok s ON s.sku = b.sku
WHERE s.qty < b.min_stok
ORDER BY kekurangan DESC;
```
Hasilnya langsung bisa dipakai sebagai daftar belanja. Kolom `kekurangan` penting: supervisor tidak hanya perlu tahu mana yang kritis, tetapi seberapa banyak yang harus dipesan.
## Query 2: Barang Lambat Bergerak 90 Hari
Stok mati mengunci modal dan ruang rak. Query ini mencari barang yang tidak punya transaksi keluar dalam 90 hari terakhir.
```sql
SELECT b.sku, b.nama, SUM(s.qty) AS stok_total, b.kategori,
MAX(m.tanggal) AS terakhir_keluar
FROM barang b
JOIN stok s ON s.sku = b.sku
LEFT JOIN mutasi m ON m.sku = b.sku AND m.tipe = 'OUT'
GROUP BY b.sku, b.nama, b.kategori
HAVING terakhir_keluar IS NULL
OR terakhir_keluar < DATE('now', '-90 day')
ORDER BY stok_total DESC;
```
`LEFT JOIN` dipakai supaya barang yang **belum pernah** keluar tetap muncul — justru barang seperti itu yang paling sering luput dari perhatian.
## Query 3: Selisih Stok Opname
Saat opname, angka sistem dan angka hitung fisik hampir selalu berbeda. Yang dibutuhkan bukan daftar panjang, melainkan selisih yang melewati toleransi.
```sql
WITH hitung AS (
SELECT sku, lokasi, qty AS qty_fisik
FROM opname_2026_10 -- tabel sementara hasil hitung lapangan
)
SELECT h.sku, b.nama, h.lokasi,
s.qty AS qty_sistem, h.qty_fisik,
(h.qty_fisik - s.qty) AS selisih
FROM hitung h
JOIN stok s ON s.sku = h.sku AND s.lokasi = h.lokasi
JOIN barang b ON b.sku = h.sku
WHERE ABS(h.qty_fisik - s.qty) > 0
ORDER BY ABS(selisih) DESC;
```
Kunci `sku + lokasi`, bukan `sku` saja. Barang yang sama di dua rak berbeda akan tampak "hilang" kalau digabung lebih dulu — dan itu kesalahan yang paling sering saya temui saat memeriksa ulang laporan orang lain.
## Query 4: Rekap Mutasi Harian
Untuk laporan harian ke manajemen, biasanya cukup dua angka: total masuk dan total keluar per hari.
```sql
SELECT tanggal,
SUM(CASE WHEN tipe = 'IN' THEN qty ELSE 0 END) AS total_masuk,
SUM(CASE WHEN tipe = 'OUT' THEN qty ELSE 0 END) AS total_keluar,
COUNT(*) AS jumlah_transaksi
FROM mutasi
WHERE tanggal >= DATE('now', '-14 day')
GROUP BY tanggal
ORDER BY tanggal DESC;
```
Empat belas hari terakhir biasanya cukup untuk melihat pola: apakah pengeluaran menumpuk di awal minggu, atau ada hari dengan transaksi jauh di bawah rata-rata.
## Query 5: Tren Keluar-Masuk per Kategori
Angka total menyembunyikan masalah. Yang menjelaskan biasanya kategori.
```sql
SELECT b.kategori,
SUM(CASE WHEN m.tipe = 'IN' THEN m.qty ELSE 0 END) AS masuk,
SUM(CASE WHEN m.tipe = 'OUT' THEN m.qty ELSE 0 END) AS keluar,
SUM(CASE WHEN m.tipe = 'OUT' THEN m.qty ELSE 0 END) * 1.0
/ NULLIF(SUM(CASE WHEN m.tipe = 'IN' THEN m.qty ELSE 0 END), 0)
AS rasio_keluar_masuk
FROM mutasi m
JOIN barang b ON b.sku = m.sku
WHERE m.tanggal >= DATE('now', '-30 day')
GROUP BY b.kategori
ORDER BY rasio_keluar_masuk DESC;
```
Rasio di atas 1 berarti kategori itu menguras stok lebih cepat daripada pengisiannya. Itu bukan otomatis masalah — bisa jadi memang permintaannya tinggi — tetapi selalu layak ditanyakan sebelum pemesanan berikutnya.
> [!WARNING]
> Jangan menjalankan query `UPDATE` atau `DELETE` pada database produksi hanya karena ingin "merapikan" data. Kesalahan satu baris tanpa `WHERE` bisa menghapus riwayat mutasi setahun, dan laporan yang tidak punya riwayat tidak bisa direkonstruksi. Biasakan bekerja pada salinan, lalu simpan query yang dipakai sebagai catatan.
## Tiga Jebakan yang Bikin Angka Laporan Salah
**Menggabungkan lokasi terlalu awal.** Selisih stok muncul dari penggabungan yang salah, bukan dari kehilangan barang. Selalu kelompokkan per `sku` **dan** `lokasi`.
**Mengabaikan tanggal yang disimpan sebagai teks.** Kalau kolom `tanggal` berisi teks bebas, `BETWEEN` akan memberi hasil aneh. Simpan dalam format `YYYY-MM-DD`.
**Menghitung mutasi pembatalan sebagai transaksi.** Koreksi dan pembatalan sering tercatat sebagai baris baru. Kalau tidak difilter, laporan masuk-keluar akan terlihat lebih ramai daripada kenyataan.
## Tanya Jawab Seputar SQL untuk Admin Gudang
**Q:** Apakah harus bisa membuat database sendiri sebelum belajar query?
**A:** Tidak. Yang dibutuhkan hanya akses baca ke satu tabel data. Belajar lima pola — `SELECT`, `JOIN`, `GROUP BY`, `HAVING`, dan `CASE` — sudah cukup untuk menyelesaikan sebagian besar laporan gudang.
**Q:** Bedanya SQL dengan rumus Excel yang selama ini saya pakai?
**A:** Excel menghitung ulang di berkas yang Anda pegang; SQL membaca data terkini dari sumbernya. Untuk laporan yang dipakai bersama, SQL menghilangkan masalah versi berkas dan hasilnya bisa diulang persis oleh orang lain.
**Q:** Kalau sistem gudang saya tidak menyediakan akses database, bagaimana?
**A:** Mulai dari ekspor harian ke satu tabel sederhana, termasuk SQLite. Pola query-nya sama; yang berubah hanya cara memuat data. Setelah terbukti menghemat waktu, barulah ajukan akses baca langsung ke tim IT.
**Q:** Berapa lama sampai bisa dipakai kerja?
**A:** Untuk admin gudang tanpa latar belakang IT, dua sampai tiga sesi latihan pada data sendiri biasanya sudah cukup untuk query stok kritis dan mutasi harian. Sisanya berkembang saat ada pertanyaan baru dari supervisor.
## Poin Penting
- **Lima query menutup sebagian besar laporan mingguan**: stok kritis, lambat bergerak, selisih opname, mutasi harian, tren kategori.
- **Kunci gabungan `sku + lokasi`** mencegah selisih stok palsu saat opname.
- **`LEFT JOIN`** membuat barang yang belum pernah keluar ikut terlihat — justru itu yang paling mahal.
- **Bekerja pada salinan database**, dan simpan setiap query yang Anda pakai agar bisa diaudit ulang.
- **Mulai dari satu laporan** yang paling sering Anda buat manual, bukan dari seluruh sistem.
### Baca juga:
- [Otomasi Python untuk Gudang dan Logistik Pabrik](/post/otomasi-python-gudang-logistik-pabrik)
- [EOQ dan Reorder Point: Stok Minimum Gudang](/post/eoq-reorder-point-stok-minimum-gudang)
- [WMS vs Spreadsheet: Kapan Gudang Butuh Sistem](/post/wms-vs-spreadsheet-kapan-gudang-butuh-sistem)
Kalau Anda punya laporan mingguan yang masih disusun manual, tulis strukturnya di kolom komentar: tabel apa saja yang terlibat dan angka apa yang selalu ditanyakan atasan. Dari situ biasanya kelihatan apakah masalahnya benar-benar butuh sistem baru, atau hanya butuh satu query yang belum pernah ditulis.
*— Dwi Kurniawan, praktisi operasional.*
---
> 📖 **AKSI PENGGUNA DIBUTUHKAN**:
> Untuk visualisasi interaktif, tabel komparasi lengkap, dan konsultasi teknis, kunjungi artikel asli di:
> 🔗 [https://dwik.web.id/post/sql-admin-gudang-5-query-laporan-stok](https://dwik.web.id/post/sql-admin-gudang-5-query-laporan-stok)
*dwik.web.id — Menghubungkan Teknologi, Operasional, dan Manusia | Dwi Kurniawan*