Katalog produk dengan varian dan bundel: skema dan pola UI

Mengapa varian dan bundel cepat menjadi berantakan

Katalog terlihat sederhana ketika setiap produk adalah satu item dengan satu harga dan satu angka stok. Tambahkan warna, ukuran, durasi langganan, atau kemasan khusus wilayah dan kesederhanaan itu runtuh. Satu tabel “Produk” tidak lagi bisa menjawab pertanyaan dasar: benda tepat apa yang kita jual, dan bagaimana kita melacaknya?

Pembeli juga mengharapkan detail yang tepat. Mereka ingin memilih opsi, melihat harga yang benar seketika, dan tahu apakah pilihan mereka dapat dikirim hari ini. Jika halaman menampilkan “Tersedia” tapi ukuran yang dipilih habis, kepercayaan cepat menurun. Jika harga berubah baru saat checkout, tiket dukungan dan pengembalian akan mengikuti.

Bundel menambahkan lapisan kompleksitas kedua karena terlihat seperti produk tetapi berperilaku seperti aturan. "Starter Kit" mungkin termasuk satu botol, satu pompa, dan satu set filter. Ketersediaannya bergantung pada bagian-bagiannya, dan biaya serta pelaporan Anda tetap harus masuk akal.

Tanda-tanda katalog mulai retak:

• Anda membuat SKU duplikat hanya untuk mewakili sebuah opsi.
• Jumlah stok terasa salah, terutama setelah penjualan bundel.
• Layar admin menjadi daftar panjang item yang hampir identik.
• Diskon dan pajak bekerja untuk item tunggal tapi rusak untuk kit.
• Pelaporan tidak bisa menjawab "apa yang sebenarnya terjual?"

Solusinya sebagian besar soal disiplin: model data yang konsisten, dan pola UI yang membuat pemilihan opsi serta ketersediaan jelas bagi pelanggan dan tim Anda.

Istilah sederhana: opsi, varian, SKU, bundel

Saat orang mengatakan "varian", mereka sering mencampur beberapa ide berbeda. Meluruskan kata-kata ini sejak awal memudahkan keputusan selanjutnya (skema, UI, inventaris).

Kebanyakan tim menggunakan definisi ini:

• Opsi: pilihan yang bisa dibuat pembeli, seperti Ukuran atau Warna.
• Nilai opsi: satu nilai di dalam opsi, seperti Ukuran = M atau Warna = Hitam.
• Varian: satu kombinasi tepat dari nilai opsi, seperti Ukuran M + Warna Hitam.
• SKU: unit yang dijual yang Anda lacak di operasi dan inventaris. Satu varian sering dipetakan ke satu SKU, tapi tidak selalu.
• Bundel / kit / multipack: produk yang dibuat dari produk lain. Sebuah bundel adalah pengelompokan pemasaran (bagian-bagiannya bisa dijual terpisah). Kit adalah set yang "harus dikirim bersama". Multipack adalah item yang sama diulang (misalnya 3-pack kaus kaki).

ID juga sering membingungkan di praktik. ID internal adalah yang dipakai database Anda. SKU adalah kode operasional Anda (dipakai di pengambilan, pengisian ulang, dan laporan). Barcode (UPC/EAN) adalah yang dibaca pemindai. Satu SKU bisa memiliki banyak barcode (berbeda wilayah), dan beberapa item tidak punya barcode sama sekali.

Aturan praktis untuk memutuskan apakah sesuatu harus menjadi varian yang bisa dijual: jika bisa memiliki harga berbeda, inventaris berbeda, berat berbeda, atau aturan pengiriman berbeda, perlakukan sebagai yang bisa dijual. Kaos yang sama dalam Ukuran M dan Ukuran XL biasanya perlu hitungan stok terpisah, jadi sebaiknya menjadi SKU terpisah.

Putuskan apa yang perlu didukung katalog Anda

Sebelum memilih skema, mulailah dengan pertanyaan yang bisnis harus jawab setiap hari. Saat seseorang melihat item, bisakah Anda dengan percaya diri mengatakan: apakah tersedia sekarang, berapa harganya, bagaimana cara pengirimannya, dan aturan pajaknya apa?

Cara berpikir yang berguna adalah memutuskan di mana setiap “fakta” disimpan. Letakkan fakta yang dibagi di level produk, dan fakta yang berubah di level varian (SKU). Jika Anda mencampurnya, Anda akan mengakhiri dengan memperbaiki bug yang sama di dua tempat.

Pertanyaan yang biasanya menentukan field di product-level vs variant-level:

• Jika berubah menurut ukuran/warna/material, itu milik varian.
• Jika benar untuk semua kombinasi opsi, itu milik produk.
• Jika Anda melaporkannya per SKU (penjualan, margin, pengembalian), simpan per varian.
• Jika operasi menggunakannya untuk pick/pack/ship, simpan di tempat gudang bekerja: pada SKU.
• Jika bisa diturunkan dengan aman (misalnya nama tampilan dari nilai opsi), turunkan dan simpan sumbernya saja.

Jaga satu sumber kebenaran. Contohnya, jangan simpan "harga" di produk dan varian kecuali perannya jelas (misalnya produk punya MSRP, varian punya harga jual aktual).

Rencanakan untuk perubahan. Anda mungkin menambahkan opsi baru nanti (seperti "Panjang"), menghentikan varian, atau menggabungkan SKU setelah pemasok berubah. Ini berjalan lebih mulus ketika varian adalah record kelas-satu, bukan sekadar label.

Jika Anda membangun di AppMaster, penamaan entitas yang jelas di Data Designer membuat ini lebih mudah dipelihara saat kebutuhan berubah.

Skema praktis untuk produk dan varian

Skema yang bersih menjaga katalog tetap dapat dimengerti ketika produk sederhana berubah menjadi puluhan kombinasi yang bisa dijual. Tujuannya adalah memodelkan pilihan (apa yang dipilih pembeli) terpisah dari item yang dijual (apa yang sebenarnya Anda stok dan kirim).

Set entitas yang dapat diandalkan:

• Product: item "induk" (nama, deskripsi, brand, kategori, gambar default)
• Option: tipe pilihan (Ukuran, Warna)
• OptionValue: nilai yang diperbolehkan (Small, Medium, Merah, Biru)
• Variant: unit yang bisa dijual (satu kombinasi nilai)
• VariantOptionValue: tabel join yang menghubungkan Variant ke OptionValue yang dipilihnya

Keunikan varian adalah tempat banyak katalog salah. Pendekatan paling aman adalah normalisasi: pastikan satu OptionValue per Option untuk setiap Variant, dan cegah kombinasi duplikat. Jika Anda juga butuh cepat, simpan "variant key" terhitung seperti color=red|size=m (atau hash dari itu) pada Variant dan tegakkan unik per Product.

Simpan field yang berubah per kombinasi di Variant, bukan Product: SKU, barcode, harga, harga banding, biaya, berat, dimensi, status (aktif/dihentikan), dan gambar (satu gambar utama atau beberapa gambar kecil).

Untuk atribut khusus (seperti "material" atau "instruksi perawatan"), hindari menambah kolom baru terus-menerus. Field JSONB pada Product atau Variant bekerja baik di PostgreSQL, dipadu dengan lapisan validasi kecil di aplikasi Anda.

Aturan SKU yang bertahan seiring waktu

SKU adalah pengenal untuk unit yang bisa dijual yang Anda janjikan akan tetap stabil. Itu harus menjawab satu pertanyaan: "Item tepat mana yang kita jual?" SKU tidak seharusnya memuat nama pemasaran, teks opsi penuh, musim, atau cerita panjang. Jika Anda membebani SKU dengan makna, akan sulit mengubah apa pun nanti tanpa merusak laporan.

Putuskan lebih awal apakah SKU ditetapkan manual atau dihasilkan. SKU manual lebih aman jika Anda sudah punya ERP, barcode, atau SKU pemasok yang harus cocok. SKU yang dihasilkan lebih aman saat Anda punya banyak varian dan butuh konsistensi, tetapi hanya jika aturannya tidak berubah di tengah tahun. Jalan tengah umum adalah SKU dasar tetap yang Anda kontrol, plus sufiks pendek yang dihasilkan untuk atribut varian.

Aturan yang tetap terbaca dan tahan pertumbuhan:

• Pertahankan SKU stabil setelah pesanan dibuat. Jangan "memperbaiki" SKU lama dengan menggantinya nama.
• Pisahkan ID internal dari SKU. Gunakan SKU untuk manusia, ID untuk database.
• Gunakan prefix pendek untuk keluarga produk (mis. TSH, MUG), bukan kata lengkap.
• Hindari makna yang bisa berubah (seperti "2026" atau "SUMMER") kecuali bisnis Anda memang bekerja begitu.

SKU yang dihentikan tidak boleh dihapus. Tandai sebagai tidak aktif, simpan riwayat harganya, dan biarkan dapat dipilih di pesanan, pengembalian, dan laporan masa lalu. Jika Anda mengganti SKU, simpan referensi "digantikan oleh" agar dukungan bisa melacaknya.

Aturan validasi mencegah kerusakan lambat-seiring-waktu: tegakkan keunikan SKU di semua item yang bisa dijual, izinkan hanya huruf, angka, dan strip, tetapkan panjang maksimum yang jelas (sering 20-32 karakter), dan cadangkan prefix untuk kasus khusus (mis. "BND-" untuk bundel). Di AppMaster, pengecekan ini cocok sebagai constraint data plus Business Process yang memblokir penyimpanan saat aturan dilanggar.

Logika inventaris di luar sekadar tersedia/tidak tersedia

Inventaris menjadi membingungkan ketika satu "produk" bisa berarti banyak unit yang bisa dijual. Sebelum menulis aturan, pilih unit inventaris Anda: apakah Anda melacak stok di level produk, varian, atau keduanya?

Jika pelanggan memilih ukuran atau warna, stok level varian biasanya paling aman. Sebuah kaos mungkin "tersedia" secara keseluruhan, tetapi varian Small-Blue bisa habis. Level produk cocok untuk item di mana varian tidak mengubah apa yang Anda simpan secara fisik (mis. lisensi digital dengan rencana penagihan berbeda). Beberapa tim menyimpan keduanya: level produk untuk pelaporan, level varian untuk penjualan.

Pencegahan overselling lebih soal status yang jelas daripada satu flag ajaib. Kebanyakan katalog membutuhkan reservasi (menahan unit sementara untuk keranjang atau pesanan belum dibayar), backorder (mengizinkan penjualan dengan tanggal kirim jelas), buffer stok (kuantitas tersembunyi untuk menutup keterlambatan sinkronisasi), dan pembaruan atomik (mengurangi stok dalam operasi yang sama saat konfirmasi pesanan).

Kasus tepi adalah sumber "stok misterius". Pengembalian harus menambah stok kembali hanya setelah inspeksi, bukan saat label pengembalian dibuat. Barang rusak harus dipindahkan ke status atau lokasi terpisah agar tidak muncul sebagai dapat dijual. Penyesuaian stok perlu jejak audit (siapa mengubah apa dan kenapa), terutama jika banyak channel memperbarui inventaris.

Bundel dan kit menambah satu aturan kunci: jangan kurangi record "bundel" jika bundel itu hanya pengelompokan. Kurangi item komponennya. 3-pack harus mengurangi tiga unit dari SKU yang sama; kit harus mengurangi satu dari setiap komponen.

Contoh: sebuah "Starter Kit" berisi 1 botol dan 2 filter. Jika Anda punya 10 botol dan 15 filter, ketersediaan kit adalah 7 karena filter yang membatasi. Perhitungan berbasis komponen menjaga pelaporan, pengembalian, dan restock konsisten.

Di AppMaster, ini terpetakan rapi ke tabel varian di Data Designer dan logika reservasi/pengurangan di Business Process Editor, sehingga setiap checkout mengikuti aturan yang sama.

Memodelkan bundel dan kit tanpa merusak pelaporan

Bundel adalah tempat katalog sering melenceng ke kasus khusus. Pendekatan paling sederhana adalah memodelkan bundel sebagai item yang bisa dijual normal, lalu lampirkan daftar komponen yang jelas.

Struktur yang bersih adalah: Product (item yang bisa dijual) plus BundleLines. Setiap BundleLine menunjuk ke SKU komponen (atau produk komponen plus varian yang dibutuhkan) dan menyimpan kuantitas. Pesanan tetap menampilkan “satu item”, tetapi Anda bisa memperluasnya menjadi bagian-bagian saat perlu detail biaya, inventaris, dan pemenuhan.

Kebanyakan setup bundel cocok salah satu dari ini:

• Bundel tetap (kit): selalu komponen dan kuantitas yang sama.
• Bundel yang dapat dikonfigurasi: pelanggan memilih dari komponen yang diperbolehkan (tetap disimpan sebagai baris di pesanan).
• Bundel virtual: pengelompokan pemasaran (sering tanpa efek inventaris), berguna untuk merchandising tanpa memaksa logika pemenuhan.

Harga adalah tempat tim secara tidak sengaja merusak pelaporan. Putuskan sejak awal apa yang muncul di baris pesanan, dan apa yang memberi makan laporan margin serta inventaris. Pendekatan umum adalah harga bundel tetap, jumlah bagian, atau jumlah yang didiskon dengan aturan per komponen (mis. "pilih 3 item, yang termurah diskon 50%").

Inventaris harus sama ketatnya: kit tersedia hanya jika setiap komponen yang dibutuhkan tersedia dalam kuantitas yang diperlukan. Untuk pelaporan, simpan dua pandangan penjualan:

• Item terjual: SKU bundel (untuk pendapatan, konversi, dan merchandising).
• Komponen yang dikonsumsi: BundleLines yang diperluas (untuk pergerakan stok, COGS, dan daftar pick).

Di AppMaster, ini cocok secara alami: tabel Bundle plus baris BundleLine, dengan Business Processes yang memperluas komponen saat checkout dan menulis penjualan bundel serta konsumsi komponen dalam satu transaksi.

Pola UI untuk memilih opsi dan varian

UI opsi yang baik membuat orang terus maju. UI yang buruk membuat mereka menebak, menemui kesalahan, dan pergi. Kuncinya adalah membimbing pembeli ke varian yang nyata dan dapat dibeli lebih awal, sambil jelas menunjukkan apa yang diubah pilihan mereka.

Untuk pelanggan: opsi dulu, varian kemudian

Pola yang andal adalah menampilkan opsi (Ukuran, Warna, Material), lalu menghitung dan menunjukkan hanya pilihan yang masih masuk akal.

Alih-alih membiarkan pelanggan memilih kombinasi apa pun dan gagal saat Tambah ke keranjang, nonaktifkan kombinasi yang tidak mungkin segera setelah pengguna membuat pilihan. Misalnya, begitu seseorang memilih Warna = Hitam, ukuran yang tidak ada dalam Hitam harus menjadi dinonaktifkan (bukan dihapus), sehingga pelanggan mengerti apa yang tidak tersedia.

Seiring pilihan berubah, perbarui bagian yang paling penting: harga (termasuk harga promo dan diskon bundel), gambar utama (cocokkan warna atau gaya yang dipilih), status stok (stok varian tepat, bukan stok produk generik), estimasi pengiriman (jika berbeda per varian), dan opsional SKU atau "kode item" untuk dukungan.

Jaga antarmuka tetap tenang. Tampilkan beberapa grup opsi sekaligus, hindari dropdown besar ketika swatch atau tombol lebih efektif, dan buat pilihan saat ini mudah terlihat.

Untuk admin: edit varian seperti spreadsheet

Di admin, orang butuh kecepatan, bukan kartu yang cantik. Grid varian bekerja baik: tiap baris adalah SKU, tiap kolom adalah opsi atau aturan (harga, barcode, berat, stok, aktif/tidak). Tambahkan aksi massal untuk tugas umum seperti pembaruan harga, toggle ketersediaan, atau penugasan gambar.

Jika Anda membangun ini di AppMaster, setup praktis adalah grid yang terikat ke tabel Variant dengan filter (nilai opsi, status aktif, stok rendah), plus aksi pembaruan massal yang memvalidasi aturan sebelum menyimpan.

Langkah demi langkah: pemilihan varian dan pengecekan ketersediaan bundel

Alur pemilihan harus terasa sederhana, tetapi memiliki aturan ketat di belakang layar. Tujuannya adalah selalu mengetahui SKU tepat yang dikonfigurasikan pembeli, dan apakah bisa dibeli sekarang.

Pemilihan varian (produk tunggal)

Muat lebih dari sekadar nama produk dan gambar. Anda butuh seluruh set nilai opsi (Ukuran, Warna) dan daftar kombinasi varian valid yang ada sebagai SKU.

Alur yang andal:

1. Ambil product, opsi-opsinya, dan semua varian yang ada (atau peta ringkas kombinasi valid).
2. Simpan pilihan saat ini dari pembeli (misal: Size=M, Color=Black) dan perbarui setiap klik.
3. Setelah tiap perubahan, temukan varian yang cocok dengan membandingkan nilai opsi yang dipilih ke daftar varian Anda.
4. Jika ada kecocokan dan dapat dibeli (aktif, harga terpasang, tidak diblokir), aktifkan Tambah ke keranjang.
5. Jika tidak ada kecocokan, biarkan Tambah ke keranjang dinonaktifkan dan pandu pembeli ke pilihan valid.

Detail UI kecil yang mencegah frustrasi: nonaktifkan nilai opsi yang tidak mungkin segera setelah pilihan sebelumnya dibuat. Jika Size=M hanya ada di Hitam, tunjukkan warna lain sebagai tidak tersedia setelah M dipilih.

Ketersediaan bundel (kit dari komponen)

Untuk bundel, "tersedia" bukan angka tunggal. Itu bergantung pada komponen. Aturan biasa adalah:

bundle_available = minimum dari komponen floor(component_stock / component_qty_per_bundle)

Contoh: "Starter Kit" membutuhkan 1 botol dan 2 filter. Jika Anda punya 10 botol dan 9 filter, ketersediaan kit adalah min(floor(10/1)=10, floor(9/2)=4) = 4 kit.

Pesan kesalahan harus konkret. Lebih baik "Hanya 4 kit tersedia (filter membatasi bundel ini)" daripada "Habis." Di AppMaster, pengecekan semacam ini mudah diungkapkan dalam Business Process: hitung varian yang cocok dulu, lalu hitung batas bundel, lalu kembalikan status yang jelas untuk UI tampilkan.

Kesalahan umum dan jebakan yang harus dihindari

Katalog rusak ketika Anda memodelkan untuk "semua yang bisa ada" daripada "apa yang benar-benar akan dijual." Cara tercepat membuat masalah adalah menghasilkan semua kombinasi opsi kemungkinan dari awal, lalu mencoba menjaga kebersihannya saat katalog tumbuh.

Membuat varian yang tidak pernah akan distok adalah jebakan klasik. Jika Anda punya 4 warna x 6 ukuran x 3 material, itu 72 varian. Jika hanya 10 yang akan dijual, 62 record lainnya membuat kekacauan, mengundang kesalahan, dan memperlambat pelaporan.

Harga adalah sumber bug lain yang sunyi. Masalah muncul saat harga sama ada di banyak tempat (produk, varian, tabel harga, tabel promo) tanpa satu sumber kebenaran. Aturan sederhana membantu: simpan harga dasar sekali, lalu simpan override hanya di tempat yang benar-benar perlu (mis. satu varian punya harga berbeda).

Bundel dan kit gagal pada inventaris ketika Anda mengurangi baik bundel maupun komponennya. Jika Anda jual "Starter Kit" yang berisi 1 botol dan 2 filter, mengurangi 1 kit dan juga mengurangi 1 botol dan 2 filter membuat stok turun dua kali lipat. Pertahankan bundel sebagai item yang bisa dijual, tapi hitung ketersediaan dan pengurangan dari komponennya.

Alat admin bisa menyebabkan kerusakan jika mengizinkan data tidak valid. Tambahkan pengaman sejak awal:

• Blokir SKU duplikat, bahkan di item yang diarsipkan.
• Wajibkan setiap varian memiliki semua nilai opsi (tidak ada "ukuran hilang").
• Cegah dua varian berbagi kombinasi opsi yang sama.
• Validasi komponen bundel (tidak boleh kuantitas nol, tidak boleh SKU yang hilang).

Akhirnya, rencanakan untuk perubahan. Menambahkan opsi baru nanti (seperti "Lebar" untuk sepatu) adalah migrasi, bukan sekadar centang. Putuskan apa yang terjadi pada varian yang ada, bagaimana default ditetapkan, dan bagaimana pesanan lama mempertahankan SKU serta snapshot opsi aslinya.

Pemeriksaan cepat sebelum Anda rilis

Sebelum meluncurkan, lakukan pengecekan pada hal-hal yang rusak di dunia nyata: menemukan SKU, memperbarui stok, dan memblokir pembelian yang tidak mungkin.

Pastikan setiap SKU yang bisa dijual mudah ditemukan. Pencarian harus menemukannya berdasarkan nama, kode SKU, barcode/GTIN, dan atribut kunci (seperti ukuran atau warna). Jika Anda memakai scanning di gudang, uji beberapa pemindaian fisik dan konfirmasi mereka mengarah ke SKU tepat, bukan hanya produk induk.

Bersikap ketat tentang di mana perubahan stok terjadi. Pilih satu sumber kebenaran (logika pergerakan inventaris Anda) dan pastikan setiap event menggunakannya: pesanan, pembatalan, pengembalian, penyesuaian manual, dan perakitan bundel. Jika stok bisa diedit di dua layar atau dua workflow, drift pasti terjadi.

Pengecekan peluncuran yang layak dijalankan:

• Pilih opsi di UI dan konfirmasi kombinasi tidak valid diblokir lebih awal (sebelum add-to-cart), bukan ditemukan saat checkout.
• Untuk bundel, konfirmasi ketersediaan digerakkan oleh komponen yang paling langka dan kuantitas yang benar (2 baterai per kit harus mengurangi ketersediaan menjadi setengahnya).
• Hentikan sebuah SKU dan verifikasi ia hilang dari browsing dan hasil pencarian, tapi masih tampil dengan benar di pesanan, faktur, dan laporan masa lalu.
• Tempatkan pesanan uji, batalkan, lalu pesan lagi; stok harus kembali dan ter-reserve ulang dengan bersih.

Jika Anda membangun di AppMaster, simpan aturan pembaruan stok di satu Business Process dan panggil dari setiap jalur. Kebiasaan tunggal itu mencegah sebagian besar bug inventaris.

Skenario contoh dan langkah praktis selanjutnya

Bayangkan sebuah toko pakaian yang masih butuh katalog serius.

Anda menjual T-shirt dengan dua opsi: Ukuran (S, M, L) dan Warna (Hitam, Putih). Setiap kombinasi yang bisa dibeli adalah varian sendiri dengan SKU, harga (jika perlu), dan inventarisnya.

Dalam skema, simpan satu record Product untuk "Classic T-shirt", dua record Option (Size, Color), dan beberapa record Variant. Masing-masing Variant menyimpan nilai opsi terpilihnya (misal: Size=M, Color=Black) dan SKU (misal: TSH-CL-M-BLK). Inventaris dilacak di level Variant, bukan Product.

Di UI, persempit pilihan dan hindari jalan buntu. Pola bersih adalah: tampilkan semua Warna dulu, lalu hanya tampilkan Ukuran yang ada untuk Warna yang dipilih (atau sebaliknya). Jika "Putih + L" tidak ada, jangan izinkan dipilih, atau tampilkan sebagai dinonaktifkan dengan catatan jelas.

Sekarang tambahkan bundel: "Gift Set" yang berisi:

• 1x Classic T-shirt (varian mana saja)
• 1x Sticker pack (SKU sederhana)

Ketersediaan bundel dibatasi oleh komponen yang paling ketat. Jika stok Sticker pack 5, Anda tidak bisa menjual lebih dari 5 bundel, meskipun T-shirt banyak stoknya. Jika bundel membutuhkan varian T-shirt tertentu (mis. Black M), maka stok bundel adalah min(StickerPackStock, BlackMStock).

Langkah praktis berikutnya di AppMaster:

• Bangun tabel di Data Designer (Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents).
• Implementasikan "find valid variants" dan "calculate bundle availability" di Business Process Editor.
• Hasilkan UI web dan native mobile dari proyek yang sama, menggunakan aturan pemfilteran varian dan ketersediaan di mana pun.

Jika Anda mau prototipe cepat ujung-ke-ujung, AppMaster (appmaster.io) dirancang untuk membangun aplikasi lengkap dengan logika bisnis nyata, yang memang bergantung pada pemilihan varian dan aturan inventaris bundel.