Varyantlar ve paketli ürünlerle ürün kataloğu: şema ve UI kalıpları

Neden varyantlar ve paketler çabucak karışır

Bir katalog, her ürün tek bir öğe, tek bir fiyat ve tek bir stok sayısı olduğunda basit görünür. Renk, beden, abonelik süresi veya bölgeye özel ambalaj ekleyin, o basitlik bozulur. Tek bir “Ürünler” tablosu artık temel soruları cevaplayamaz: aslında hangi öğeyi satıyoruz ve bunu nasıl izliyoruz?

Alışveriş yapanlar ayrıca detayların doğru olmasını bekler. Seçenekleri seçmek, doğru fiyatı hemen görmek ve seçtiklerinin bugün gönderilip gönderilemeyeceğini bilmek isterler. Sayfada “Stokta” yazıyor ama seçilen beden yoksa güven hızla düşer. Fiyat sadece ödeme sırasında değişiyorsa, destek talepleri ve iadeler peşinden gelir.

Paketler ikinci bir karmaşıklık katmanı ekler çünkü ürün gibi görünürler ama kurallar gibi davranırlar. Bir “Başlangıç Kiti” bir şişe, bir pompa ve bir dizi filtre içerebilir. Kullanılabilirliği parçalara bağlıdır ve maliyetlerinizle raporlamanızın anlamlı olması gerekir.

Katalogunuz çatlamaya başladığında görünen işaretler:

• Bir seçeneği temsil etmek için çoğaltılmış SKU'lar oluşturuyorsunuz.
• Paket satışlarından sonra stok sayıları yanlış hissediliyor.
• Yönetici ekranları neredeyse aynı öğelerden oluşan uzun listeler haline geliyor.
• İndirimler ve vergiler tek tek öğelerde çalışıyor ama kitlerde bozuluyor.
• Raporlama “gerçekte ne satıldı?” sorusuna cevap veremiyor.

Çözüm büyük oranda disiplin: tutarlı kalan bir veri modeli ve müşterileriniz ile ekibiniz için seçenek seçimini ve kullanılabilirliği açık hale getiren UI kalıpları.

Düz dilde terimler: seçenekler, varyantlar, SKU'lar, paketler

İnsanlar “varyantlar” dediğinde genellikle birkaç farklı fikri karıştırırlar. Terimleri baştan doğru koymak (şema, UI, envanter kararları) sonradan işleri çok kolaylaştırır.

Çoğu ekip bu tanımları kullanır:

• Seçenek (Option): alıcının yapabileceği bir tercih, örneğin Beden veya Renk.
• Seçenek değeri (Option value): bir seçeneğin içindeki bir değer, örneğin Beden = M veya Renk = Siyah.
• Varyant (Variant): seçenek değerlerinin tek bir kesin kombinasyonu, örneğin Beden M + Renk Siyah.
• SKU: operasyon ve envanterde izlediğiniz satılabilir birim. Bir varyant genellikle tek bir SKU'ya eşler, ama her zaman değil.
• Paket / kit / multipack: diğer ürünlerden oluşan bir ürün. Paket (bundle) pazarlama amaçlı gruplanmış olabilir (parçalar ayrı satılabilir). Kit birlikte gönderilmesi gereken settir. Multipack aynı öğenin tekrarıdır (örneğin 3'lü çorap paketi).

ID'ler de pratikte karışır. İç ID veritabanınızın kullandığı değerdir. SKU operasyonel kodunuzdur (toplama, yeniden stoklama ve raporlarda kullanılır). Barkod (UPC/EAN) tarayıcıların okuduğudur. Bir SKU'nun farklı bölgeler için birden fazla barkodu olabilir ve bazı öğelerin hiç barkodu olmayabilir.

Bir şeyin satılabilir varyant olup olmadığını belirlemek için iyi bir kural: fiyatı, envanteri, ağırlığı veya gönderim kurallarını değiştirebiliyorsa, onu satılabilir olarak ele alın. Aynı tişörtün M ve XL bedenleri genellikle ayrı stok sayımları gerektirir, bu nedenle ayrı SKU olmalıdır.

Kataloğunuzun hangi ihtiyaçları desteklemesi gerektiğini belirleyin

Bir şemayı seçmeden önce, işin her gün cevaplaması gereken sorularla başlayın. Bir öğeye bakıldığında şu sorulara güvenle cevap verebiliyor musunuz: şu an mevcut mu, maliyeti ne, nasıl gönderilecek ve hangi vergi kuralları uygulanıyor?

Bunu düşünmenin faydalı yollarından biri her “gerçeğin” nerede tutulacağına karar vermektir. Paylaşılan gerçekleri üründe, değişen gerçekleri varyantta (SKU) tutun. Karıştırırsanız aynı hatayı iki yerde düzeltmek zorunda kalırsınız.

Ürün düzeyi vs varyant düzeyi alanları genellikle şu sorular belirler:

• Beden/renk/malzeme ile değişiyorsa, varyanta ait olmalı.
• Tüm seçenek kombinasyonları için geçerliyse, ürün düzeyinde olmalı.
• Raporlar SKU başına yapılıyorsa (satış, marj, iadeler), varyant başına saklayın.
• Operasyonlar bunu seçme/paketleme/gönderme için kullanıyorsa, depo nerede çalışıyorsa oraya (SKU) saklayın.
• Güvenle türetilebiliyorsa (örnek: gösterim adı seçenek değerlerinden türetilmişse), kaynağı saklayın ve gösterimi türetin.

Bir kaynak tekliği (single source of truth) tutun. Örneğin “fiyat”ı hem ürün hem varyant üzerinde saklamayın, rolü belirgin değilse çakışma olur (örneğin ürün MSRP, varyant satılacak gerçek fiyat).

Değişime hazırlıklı olun. Sonradan yeni bir seçenek ekleyebilir (örneğin “Uzunluk”), bir varyantı emekliye ayırabilir veya tedarikçi değişince SKU'ları birleştirebilirsiniz. Varyantlar birinci sınıf kayıtlarsa bu daha sorunsuz ilerler.

AppMaster içinde inşa ediyorsanız, Data Designer'da net varlık isimlendirmesi gereksinimler değiştikçe bakımını kolaylaştırır.

Ürünler ve varyantlar için pratik bir şema

Temiz bir şema, basit bir ürünün onlarca satılabilir kombinasyona dönüştüğünde katalogu anlaşılır tutar. Amaç, alışveriş yapanların seçtiklerini (ne seçtikleri) stokta olan satılabilir öğelerden (neyi gerçekten gönderdiğiniz) ayrı modellendirir.

Güvenilir bir varlık seti:

• Product: üst ürün (isim, açıklama, marka, kategori, varsayılan görseller)
• Option: bir tercih türü (Beden, Renk)
• OptionValue: izin verilen değerler (Small, Medium, Red, Blue)
• Variant: satılabilir birim (tek bir değer kombinasyonu)
• VariantOptionValue: Variant ile seçilmiş OptionValue'leri bağlayan join tablosu

Varyant benzersizliği birçok kataloğun yanlış yaptığı yerdir. En güvenli yaklaşım normalleştirilmişdir: her Variant için her Option'a bir OptionValue atanmasını zorunlu kılın ve kopya kombinasyonları engelleyin. Hız gerekiyorsa, Variant üzerinde hesaplanmış bir “variant key” saklayın örn. color=red|size=m (veya bunun hash'i) ve Product başına benzersiz olmasını zorlayın.

Üründe değil, kombinasyon başına değişen alanları Variant üzerinde tutun: SKU, barkod, fiyat, karşılaştırma fiyatı, maliyet, ağırlık, boyutlar, durum (aktif/üretimden-kaldırılmış) ve görseller (ana görsel veya küçük bir görsel seti).

Özel nitelikler (örneğin “malzeme” veya “bakım talimatları”) için sonsuza dek yeni sütunlar eklemekten kaçının. PostgreSQL'de Product veya Variant üzerinde bir JSONB alanı ve uygulamada küçük bir doğrulama katmanı iyi çalışır.

Zaman içinde tutarlı kalan SKU kuralları

SKU, sattığınız belirli bir birimi tanımlayan ve sabit kalması gereken bir tanımlayıcıdır. Bir soruyu cevaplamalı: “Hangi kesin ürünü sattık?” Pazarlama adı, tüm seçenek metni, sezon veya uzun hikâye taşımaya çalışmamalıdır. Aksi halde raporları bozmadan bir şeyi değiştirmek zorlaşır.

SKU'ların elle atanıp atanmayacağı ya da otomatik oluşturulacağına erken karar verin. Manuel SKU'lar, zaten eşleşmesi gereken bir ERP'niz, barkodlarınız veya tedarikçi SKU'larınız varsa daha güvenlidir. Üretilen SKU'lar, çok fazla varyantınız varsa ve tutarlılık gerekiyorsa daha iyidir ama kurallar yıl ortasında değişmeyecekse.

Orta yol genellikle kontrol ettiğiniz sabit bir temel SKU artı varyant öznitelikleri için kısa bir üretilmiş ek olur.

Okunabilir ve büyümeyi dayanıklı tutan kurallar:

• Bir sipariş verildikten sonra SKU'ları sabit tutun. Eski SKU'ları yeniden adlandırarak “düzeltmeyin.”
• İç ID'yi SKU'dan ayırın. İnsanlar için SKU, veritabanı için ID kullanın.
• Ürün aileleri için kısa önekler kullanın (ör. TSH, MUG), tam kelimeler değil.
• Değişebilecek anlamlardan kaçının (ör. “2026” veya “SUMMER”), işiniz gerçekten bu şekilde işlemiyorsa.

Üretimi durdurulmuş SKU'lar silinmemelidir. Bunları pasif olarak işaretleyin, fiyat geçmişini ve geçmiş siparişlerde, iadelerde ve raporlarda seçilebilir kalmasını sağlayın. Bir SKU'yu değiştirirseniz, neyle değiştirildiğini izlemek için “yerine konuldu” referansı saklayın.

Doğrulama kuralları zaman içinde yavaş hasarı önler: satılabilir tüm öğelerde SKU benzersizliğini zorunlu kılın, yalnızca harf, sayı ve kısa çizgiye izin verin, net bir maksimum uzunluk belirleyin (genellikle 20-32 karakter) ve özel durumlar için önekleri ayırın (örneğin paketler için “BND-”). AppMaster içinde bu kontroller veri kısıtları ve bir İş Süreciyle (Business Process) kaydetmeyi engelleyen bir doğrulama olarak kolayca uygulanır.

Basit stok durumunun ötesinde envanter mantığı

Aynı “ürün” birçok farklı satılabilir birimi ifade ettiğinde envanter kafa karıştırır. Kuralları yazmadan önce envanter birimini seçin: stoğu ürün düzeyinde mi, varyant düzeyinde mi yoksa her ikisinde mi takip ediyorsunuz?

Müşteriler beden veya renk seçiyorsa, varyant düzeyinde stok genellikle en güvenli olandır. Bir tişört genel olarak “stokta” olabilir ama Small-Blue varyantı tükenmiş olabilir. Ürün düzeyi stoku, varyantların fiziksel olarak ne sakladığınızı değiştirmediği durumlar için işe yarar (örneğin farklı faturalama planları olan dijital lisanslar). Bazı ekipler her ikisini de tutar: raporlama için ürün düzeyi, satış için varyant düzeyi.

Fazla satışın (overselling) önlenmesi tek bir sihirli bayraktan çok net durumlarla ilgilidir. Çoğu katalogda rezervasyonlar (sepet veya ödenmemiş siparişler için birimlerin kısa süreli tutulması), backorder (satışa izin verip net gönderim tarihini bildirme), stok tamponları (senkronizasyon gecikmelerini kapatacak gizli miktar) ve atomik güncellemeler (siparişi onaylayan aynı işlemde stoğu azaltma) gerekir.

Köşe durumlar “gizemli stok”un kaynağıdır. İadeler sadece muayeneden sonra stoğa eklenmelidir, iade etiketi oluşturulduğunda değil. Hasarlı öğeler ayrı bir durum veya konuma taşınmalı ki satılabilir görünmesin. Stok ayarlamaları bir denetim izi tutmalı (kim neyi neden değiştirdi), özellikle birden fazla kanal envanteri güncelliyorsa.

Paketler ve kitler için bir temel kural: paket sadece bir gruplayıcı ise onun kaydını düşürmeyin. Bileşen öğeleri azaltın. 3'lü paket aynı SKU'dan üç birim azaltmalı; bir kitse her bileşenden birer adet azaltmalıdır.

Örnek: “Başlangıç Kiti” 1 şişe ve 2 filtre içeriyorsa. Elinizde 10 şişe ve 15 filtre varsa kit kullanılabilirliği filtrelerin kısıtlayıcılığı nedeniyle 7'dir. Bileşen tabanlı matematik raporlama, iade ve yeniden stoklama açısından tutarlılığı korur.

AppMaster içinde bu, Data Designer'daki varyant tablolarına ve İş Süreci Editörü'ndeki rezervasyon/azaltma mantığına net bir şekilde eşlenir; böylece her ödeme işlemi aynı kuralları takip eder.

Raporlamayı bozmayacak şekilde paketleri ve kitleri modelleme

Paketler, katalogların sıkça özel durumlara kaydığı yerdir. En basit yaklaşım paketleri normal satılabilir öğeler olarak modelleyip, ardından bileşenlerin net bir listesini iliştirmektir.

Temiz bir yapı: Product (satılabilir öğe) artı BundleLines. Her BundleLine bir bileşen SKU'suna (veya bir bileşen ürüne ve gerekli varyanta) işaret eder ve bir miktar saklar. Siparişler “bir öğe” gösterir ama gerektiğinde maliyet, envanter ve karşılama detayına açılabilir.

Çoğu paket kurulumundan biri uygundur:

• Sabit paket (kit): her zaman aynı bileşenler ve miktarlar.
• Yapılandırılabilir paket: müşteri izin verilen bileşenlerden seçim yapar (yine de siparişte satır olarak kaydedilir).
• Sanal paket: pazarlama gruplaması (çoğunlukla envanter etkisi yok), merchandising için faydalı.

Fiyatlandırma takımların raporlamayı kazara bozduğu yerdir. Sipariş satırında ne görünür ve ne marj/raporlama besler ona önceden karar verin. Yaygın yaklaşımlar sabit paket fiyatı, parçaların toplamı veya bileşen başına kurallı indirimli toplamdır (ör. “herhangi 3 ürünü seç, en ucuzu %50 indirimli”).

Envanter aynı derecede sıkı olmalı: bir kit, her gerekli bileşenin gereken miktarda mevcut olması durumunda kullanılabilir olmalıdır. Raporlama için satışı iki şekilde saklayın:

• Satılan öğe: paket SKU'sı (gelir, dönüşüm ve merchandising için).
• Tüketilen bileşenler: genişletilmiş BundleLines (stok hareketi, COGS, toplama listeleri için).

AppMaster içinde bu doğal olarak uyar: bir Bundle tablosu ve BundleLine satırları, ödeme sırasında bileşenleri genişleten ve paket satışını ile bileşen tüketimini tek bir işlemde yazan İş Süreçleri ile.

Seçenekleri ve varyantları seçmek için UI kalıpları

İyi seçenek UI'sı insanları hareket halinde tutar. Kötü seçenek UI'sı onları tahmin etmeye, hatalarla karşılaşmaya ve ayrılmaya zorlar. Anahtar, müşteriyi erken aşamada gerçek, satın alınabilir bir varyanta yönlendirmek ve seçimlerinin neyi değiştirdiğini açıkça göstermektir.

Müşteri tarafı: önce seçenekler, sonra varyantlar

Güvenilir bir kalıp seçenekleri (Beden, Renk, Malzeme) sunmak, sonra yalnızca mantıklı kalan seçimleri hesaplayıp göstermek yönündedir.

Müşterinin herhangi bir kombinasyonu seçmesine izin verip Add to cart'da hata vermek yerine, kullanıcı bir seçim yaptığında imkansız kombinasyonları hemen devre dışı bırakın. Örneğin biri Renk = Siyah seçtiğinde, Siyah'ta olmayan bedenler devre dışı olmalı (kaldırılmamalı), böylece müşteri neyin mevcut olmadığını anlar.

Seçim değiştikçe en çok önem taşıyan parçaları güncelleyin: fiyat (kampanya fiyatı ve varsa paket indirimi dahil), ana görseller (seçilen renk veya stile uyan), stok durumu (kesin varyant stoğu, ürün genel stoğu değil), teslimat tahmini (varyant bazlıysa) ve isteğe bağlı olarak SKU veya “Ürün kodu” destek için.

Arayüzü sakin tutun. Birkaç seçenek grubunu aynı anda gösterin, büyük açılır menülerden kaçının; renk örnekleri veya butonlar daha iyidir ve mevcut seçimi belirgin kılın.

Yönetici tarafı: varyantları elektronik tablo gibi düzenleyin

Yönetimde hız, görsel şıklıktan daha önemlidir. Her satır bir SKU, her sütun bir seçenek veya kural (fiyat, barkod, ağırlık, stok, aktif/pasif) olan bir varyant ızgarası iyi çalışır. Fiyat güncellemeleri, kullanılabilirliği açma/kapatma veya görsel atama gibi toplu işlemler ekleyin.

AppMaster ile bunu kurarken pratik bir düzen: Variant tablonuza bağlı bir ızgara, filtreler (seçenek değeri, aktif durum, düşük stok) ve kaydetmeden önce kuralları doğrulayan bir toplu güncelleme eylemi.

Adım adım: varyant seçimi ve paket kullanılabilirlik kontrolleri

Bir seçim akışı basit hissettirmeli ama altında katı kurallar olmalı. Amaç, alışveriş yapanın yapılandırdığı kesin SKU'yu ve şu anda satın alınıp alınamayacağını her zaman bilmektir.

Varyant seçimi (tek ürün)

Ürün adından ve görsellerden daha fazlasını yükleyin. Tüm seçenek değerleri (Beden, Renk) ve SKU olarak mevcut olan geçerli varyant kombinasyonları listesine ihtiyacınız vardır.

Güvenilir bir akış:

1. Ürünü, seçeneklerini ve tüm mevcut varyantları (veya geçerli kombinasyonların kompakt bir haritasını) alın.
2. Alışveriş yapanın mevcut seçimlerini saklayın (ör. Size=M, Color=Black) ve her tıklamada güncelleyin.
3. Her değişiklikten sonra seçili seçenek değerlerini varyant listenizle karşılaştırarak eşleşen varyantı bulun.
4. Eşleşme varsa ve satın alınabilir durumdaysa (aktif, fiyat setli, engellenmemiş), Add to cart'ı etkinleştirin.
5. Eşleşme yoksa, Add to cart devre dışı kalsın ve alışveriş yapanı geçerli bir seçime yönlendirin.

Küçük bir UI detayı, hayal kırıklığını önler: önce yapılan seçimler yapıldığında imkansız seçenek değerlerini hemen devre dışı bırakın. Eğer Size=M yalnızca Siyah ile varsa, M seçildiğinde diğer renkleri kullanılamaz olarak gösterin.

Paket kullanılabilirliği (bileşenlerden oluşan kit)

Paketler için “stokta” tek bir sayı değildir. Durum bileşenlere bağlıdır. Yaygın kural:

bundle_available = minimum over components of floor(component_stock / component_qty_per_bundle)

Örnek: “Başlangıç Kiti” 1 şişe ve 2 filtre gerektiriyorsa. 10 şişe ve 9 filtre varsa kullanılabilirlik min(floor(10/1)=10, floor(9/2)=4) = 4 kittir.

Hata mesajları somut olmalı. “Stokta yok” yerine “Sadece 4 kit mevcut (bu paketi filtreler sınırlıyor)” gibi ifadeler tercih edin. AppMaster'da bu tip kontrol Business Process içinde açıkça ifade edilebilir: önce eşleşen varyantı hesaplayın, sonra paket limitlerini hesaplayın ve UI'nin göstereceği net bir durum döndürün.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Kataloglar, “var olabilecek her şeyi” modellediğinizde kırılır; bunun yerine “gerçekte ne satacaksınız” üzerine model kurun. En hızlı şekilde kendinizi köşeye sıkıştırmanın yolu, tüm olası kombinasyonları baştan üretip katalog büyüdükçe temizlemeye çalışmaktır.

Asla stoklanmayacak varyantlar yaratmak klasik tuzaktır. 4 renk x 6 beden x 3 malzeme = 72 varyanttır; eğer sadece 10'u satılacaksa kalan 62 kayıt karmaşa yaratır, hatalara davetiye çıkarır ve raporlamayı yavaşlatır.

Fiyatlandırma sessiz bir hata kaynağıdır. Aynı fiyatın birden fazla yerde (ürün, varyant, fiyat tablosu, promosyon tablosu) saklanması sorunu başlatır. Basit bir kural yardımcı olur: temel fiyatı bir yerde saklayın, sonra yalnızca gerçekten gerekliyse (örneğin bir varyant farklı bir fiyata sahipse) geçersiz kılın.

Paketler ve kitler envanterde paket kaydını ve bileşenleri birlikte azaltırsanız başarısız olur. “Başlangıç Kiti” satıldığında 1 kit ve ayrıca 1 şişe + 2 filtre azaltmak stokun gereğinden erken tükenmesine neden olur. Paketi satılabilir tutun ama kullanılabilirlik ve azaltmaları bileşenlerden hesaplayın.

Yönetici araçları geçersiz veri girilmesine izin veriyorsa zarar verir. Erken korumalar ekleyin:

• Çift SKU'ları engelleyin, arşivlenmiş öğeler dahil.
• Her varyantın tüm seçenek değerlerine sahip olmasını zorunlu kılın (örn. “beden eksik” olmasın).
• İki varyantın aynı seçenek kombinasyonunu paylaşmasını önleyin.
• Paket bileşenlerini doğrulayın (sıfır miktar yok, eksik SKU yok).

Son olarak değişime hazırlıklı olun. Sonradan yeni bir seçenek eklemek (örneğin ayakkabılar için “Genişlik”) bir geçiştir, bir onay kutusu değil. Mevcut varyantlara ne olacağına, varsayılanların nasıl belirleneceğine ve eski siparişlerin orijinal SKU ve seçenek anlık görüntüsünü nasıl koruyacağına karar verin.

Gönderim öncesi hızlı kontroller

Lansman öncesi gerçek hayatta bozulan şeylere bakın: SKU bulma, stok güncelleme ve imkansız satın almaları engelleme.

Her satılabilir SKU'nun kolay bulunabildiğinden emin olun. Arama ad, SKU kodu, barkod/GTIN ve anahtar nitelikler (beden veya renk gibi) ile bulmalı. Depoda tarama kullanıyorsanız birkaç fiziksel taramayı test edin ve doğru SKU'ya mi yoksa sadece ana ürüne mi denk geldiğini doğrulayın.

Stoğun nerede değiştiği konusunda katı olun. Bir kaynak tekliği seçin (envanter hareket mantığınız) ve her olayın ondan faydalandığından emin olun: siparişler, iptaller, iadeler, manuel düzeltmeler ve paket montajı. Stok iki ekran veya iki iş akışında düzenlenebiliyorsa sapma kaçınılmazdır.

Çalıştırmaya değer kontroller:

• UI'da seçenekleri seçin ve geçersiz kombinasyonların Add-to-cart öncesinde engellendiğini doğrulayın, checkout'ta keşfedilmesin.
• Paketler için kullanılabilirliğin en az bulunan bileşen tarafından ve doğru miktarla yönlendirildiğini doğrulayın (ör. bir kit için 2 pil gerekiyorsa kullanılabilirlik yarıya iner).
• Bir SKU'yu emekli edin ve taramadan ve arama sonuçlarından kaybolduğunu ama geçmiş siparişlerde, faturalar ve raporlarda doğru göründüğünü doğrulayın.
• Test siparişi verin, iptal edin, sonra tekrar verin; stok geri dönmeli ve temiz şekilde yeniden rezerve edilmelidir.

AppMaster ile inşa ediyorsanız, stok güncelleme kurallarını tek bir İş Sürecinde tutun ve her yol bunu çağırsın. Bu tek alışkanlık çoğu envanter hatasını önler.

Örnek senaryo ve pratik sonraki adımlar

Ciddi bir kataloğa ihtiyaç duyan bir giyim mağazasını hayal edin.

İki seçenekli bir tişört satıyorsunuz: Beden (S, M, L) ve Renk (Siyah, Beyaz). Her satın alınabilir kombinasyon kendi varyantı, kendi SKU'su, gerekirse fiyatı ve stoğu ile ayrı tutulur.

Şemada “Classic T-shirt” için bir Product kaydı, iki Option kaydı (Beden, Renk) ve birkaç Variant kaydınız olur. Her Variant seçilmiş seçenek değerlerini saklar (ör. Size=M, Color=Black) ve SKU'yu içerir (örnek: TSH-CL-M-BLK). Envanter Variant düzeyinde izlenir, Product seviyesinde değil.

UI'da seçimleri daraltın ve ölü uçları önleyin. Temiz bir kalıp: önce tüm Renkleri gösterin, sonra seçilen Renge göre mevcut Bedenleri gösterin (veya tersini yapın). Eğer “White + L” yoksa, seçilmeye izin vermeyin veya devre dışı olarak açık bir notla gösterin.

Şimdi bir paket ekleyin: “Hediye Seti” içeriği:

• 1x Classic T-shirt (herhangi bir varyant)
• 1x Sticker pack (basit bir SKU)

Paket kullanılabilirliği en kısıtlayıcı bileşen tarafından sınırlanır. Eğer Sticker pack stoğu 5 ise, tişörtlere bol stok olsa bile 5'ten fazla paket satamazsınız. Paket belirli bir tişört varyantı gerektiriyorsa (ör. Siyah M), paket stoğu min(StickerPackStock, BlackMStock) olur.

AppMaster'da pratik sonraki adımlar:

• Data Designer'da tabloları oluşturun (Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents).
• Business Process Editor'da “geçerli varyantı bul” ve “paket kullanılabilirliğini hesapla” iş akışlarını uygulayın.
• Aynı projeden web ve yerel mobil arayüzler üretin, her yerde aynı varyant filtreleme ve kullanılabilirlik kurallarını kullanın.

Uçtan uca hızlı bir prototip istiyorsanız, AppMaster (appmaster.io) gerçek iş mantığı olan tam uygulamalar oluşturmak üzere tasarlanmıştır — varyant seçimi ve paket envanter kurallarının bağlı olduğu tam olarak budur.