Catalog sản phẩm với biến thể và gói: schema và mẫu UI

Tại sao biến thể và gói nhanh chóng trở nên phức tạp

Một catalog trông đơn giản khi mỗi sản phẩm là một món hàng với một giá và một số lượng tồn kho duy nhất. Thêm màu, kích thước, thời lượng gói đăng ký, hoặc đóng gói theo vùng là sự đơn giản vỡ vụn. Một bảng “Sản phẩm” duy nhất không còn trả lời được các câu hỏi cơ bản nữa: chúng ta đang bán chính xác cái gì, và làm sao theo dõi nó?

Người mua cũng kỳ vọng thông tin chính xác. Họ muốn chọn tuỳ chọn, thấy giá đúng ngay lập tức và biết lựa chọn của họ có thể giao ngay không. Nếu trang báo “Còn hàng” nhưng kích thước đã hết, sự tin tưởng giảm nhanh. Nếu giá chỉ thay đổi ở bước thanh toán, sẽ có vé hỗ trợ và trả hàng.

Gói/bộ thêm một lớp phức tạp vì chúng trông như sản phẩm nhưng hành xử như các quy tắc. Một “Starter Kit” có thể gồm một chai, một vòi và một bộ lọc. Khả dụng của nó phụ thuộc vào các phần, và chi phí cùng báo cáo của bạn vẫn phải hợp lý.

Dấu hiệu catalog bắt đầu rạn nứt:

• Bạn tạo SKU trùng lặp chỉ để biểu diễn một tuỳ chọn.
• Số liệu tồn kho có vẻ sai, đặc biệt sau khi bán gói.
• Màn hình quản trị trở thành danh sách dài các mặt hàng gần giống nhau.
• Giảm giá và thuế đúng cho mặt hàng đơn lẻ nhưng vỡ cho kit.
• Báo cáo không trả lời được “thực sự đã bán gì?”

Sửa lỗi chủ yếu là kỷ luật: một mô hình dữ liệu nhất quán và các mẫu UI khiến việc chọn tuỳ chọn và hiện trạng tồn kho rõ ràng cho khách hàng và đội ngũ.

Thuật ngữ bằng ngôn ngữ đơn giản: tuỳ chọn, biến thể, SKU, gói

Khi mọi người nói “biến thể”, họ thường lẫn vài ý khác nhau. Việc định nghĩa rõ từ sớm làm các quyết định sau (schema, UI, tồn kho) dễ dàng hơn.

Hầu hết các đội dùng các định nghĩa này:

• Tuỳ chọn: một lựa chọn người mua có thể chọn, như Kích thước hoặc Màu.
• Giá trị tuỳ chọn: một giá trị trong tuỳ chọn, như Kích thước = M hoặc Màu = Đen.
• Biến thể: một kết hợp chính xác của các giá trị tuỳ chọn, ví dụ Kích thước M + Màu Đen.
• SKU: đơn vị có thể bán và theo dõi trong vận hành và tồn kho. Một biến thể thường ánh xạ tới một SKU, nhưng không luôn luôn vậy.
• Bundle / kit / multipack: một sản phẩm làm từ các sản phẩm khác. Một bundle là nhóm marketing (các phần có thể bán riêng). Một kit là bộ phải giao cùng nhau. Một multipack là cùng một mặt hàng lặp lại (ví dụ gói 3 đôi vớ).

IDs cũng hay bị nhầm. Một ID nội bộ là thứ database dùng. Một SKU là mã vận hành (dùng trong lấy hàng, bổ sung, và báo cáo). Một barcode (UPC/EAN) là thứ máy quét đọc. Một SKU có thể có nhiều barcode (ở các vùng khác nhau), và một số mặt hàng thậm chí không có barcode.

Một quy tắc hay để quyết xem cái gì nên là biến thể có thể bán: nếu nó có thể có giá khác, tồn kho khác, trọng lượng khác hoặc quy tắc giao hàng khác — hãy coi nó là bán được. Cùng một áo phông Size M và Size XL thường cần số tồn kho riêng, nên nên là các SKU riêng.

Quyết định những gì catalog của bạn cần hỗ trợ

Trước khi chọn schema, bắt đầu bằng các câu hỏi doanh nghiệp phải trả lời hàng ngày. Khi ai đó nhìn một mặt hàng, bạn có thể tự tin nói: nó có sẵn ngay bây giờ không, giá là bao nhiêu, sẽ giao như thế nào, và quy tắc thuế áp dụng ra sao?

Một cách hữu ích là quyết định nơi mỗi “sự thật” tồn tại. Đặt các thông tin chung ở mức product, và các thông tin thay đổi ở mức variant (SKU). Nếu bạn để lẫn lộn, bạn sẽ sửa cùng một lỗi ở hai chỗ.

Các câu hỏi thường quyết định trường ở mức product hay variant:

• Nếu nó thay đổi theo kích thước/màu/vật liệu thì nó thuộc về variant.
• Nếu đúng cho mọi tổ hợp tuỳ chọn, nó thuộc product.
• Nếu bạn báo cáo theo SKU (doanh số, biên lợi nhuận, trả hàng), lưu nó theo variant.
• Nếu vận hành dùng nó để lấy/gói/gửi, lưu nơi kho làm việc: trên SKU.
• Nếu nó có thể suy ra an toàn (ví dụ tên hiển thị từ giá trị tuỳ chọn), hãy suy ra và chỉ lưu nguồn.

Giữ một nguồn chân lý. Ví dụ, đừng lưu “giá” cả ở product và variant trừ khi vai trò rõ ràng (product có MSRP, variant có giá bán thực tế).

Lập kế hoạch cho thay đổi. Bạn có thể thêm tuỳ chọn sau (ví dụ “Độ dài”), loại bỏ biến thể, hoặc gộp SKU sau khi nhà cung cấp thay đổi. Việc này trơn tru hơn khi biến thể là bản ghi loại một, chứ không chỉ là nhãn.

Nếu bạn xây dựng trong AppMaster, đặt tên thực thể rõ ràng trong Data Designer giúp dễ bảo trì khi yêu cầu thay đổi.

Một schema thực tế cho sản phẩm và biến thể

Một schema sạch giữ catalog dễ hiểu khi một sản phẩm đơn giản biến thành hàng chục tổ hợp có thể bán. Mục tiêu là mô hình hóa lựa chọn (những gì người mua chọn) riêng biệt khỏi vật phẩm có thể bán (những gì bạn thực sự lưu kho và giao).

Một tập các thực thể đáng tin cậy:

• Product: mục cha (tên, mô tả, thương hiệu, danh mục, ảnh mặc định)
• Option: loại lựa chọn (Kích thước, Màu)
• OptionValue: các giá trị cho phép (Nhỏ, Trung, Đỏ, Xanh)
• Variant: đơn vị có thể bán (một tổ hợp giá trị)
• VariantOptionValue: bảng nối kết Variant với OptionValues đã chọn

Độ duy nhất của Variant là nơi nhiều catalog sai. Cách an toàn nhất là chuẩn hoá: bắt buộc một OptionValue cho mỗi Option trên mỗi Variant, và ngăn chặn tổ hợp trùng lặp. Nếu bạn muốn nhanh hơn, lưu một “variant key” tính toán như color=red|size=m (hoặc hash của nó) trên Variant và bắt buộc duy nhất theo Product.

Giữ các trường thay đổi theo tổ hợp trên Variant, không phải Product: SKU, barcode, giá, giá so sánh, chi phí, trọng lượng, kích thước, trạng thái (active/discontinued), và ảnh (một ảnh chính hoặc bộ ảnh nhỏ).

Với thuộc tính tuỳ biến (như “vật liệu” hoặc “hướng dẫn bảo quản”), tránh thêm cột mới mãi mãi. Một trường JSONB trên Product hoặc Variant hoạt động tốt trong PostgreSQL, kết hợp với lớp xác thực nhỏ trong app của bạn.

Quy tắc SKU giữ ổn định theo thời gian

SKU là định danh cho một đơn vị bán mà bạn hứa giữ ổn định. Nó nên trả lời một câu: “Chúng ta đã bán cái gì chính xác?” Nó không nên chứa tên marketing, văn bản tuỳ chọn đầy đủ, mùa vụ, hay cả câu chuyện. Nếu bạn nhồi nhét, việc thay đổi sau này sẽ khó khăn mà phá báo cáo.

Quyết định sớm xem SKU được gán thủ công hay sinh tự động. SKU thủ công an toàn hơn khi bạn đã có ERP, barcode, hoặc SKU nhà cung cấp cần khớp. SKU sinh tự động an toàn khi bạn có nhiều biến thể và cần nhất quán, nhưng chỉ khi quy tắc đó sẽ không đổi giữa năm. Một phương án trung gian phổ biến là SKU cơ sở cố định bạn kiểm soát, + hậu tố sinh ngắn cho thuộc tính biến thể.

Quy tắc nên đọc được và tồn tại khi mở rộng:

• Giữ SKU ổn định khi đã có đơn. Không “sửa” SKU cũ bằng cách đổi tên.
• Tách ID nội bộ khỏi SKU. Dùng SKU cho con người, ID cho database.
• Dùng tiền tố ngắn cho nhóm sản phẩm (ví dụ TSH, MUG), không phải từ đầy đủ.
• Tránh nghĩa có thể đổi (như “2026” hay “SUMMER”) trừ khi doanh nghiệp bạn thực sự cần.

SKU đã ngừng không nên bị xóa. Đánh dấu inactive, giữ lịch sử giá, và cho phép chọn lại trong đơn cũ, hoàn tiền và báo cáo. Nếu thay thế SKU, lưu tham chiếu “được thay thế bởi” để hỗ trợ có thể truy dấu.

Quy tắc xác thực ngăn chặn hỏng dần: bắt buộc duy nhất SKU trên tất cả mục có thể bán, chỉ cho phép chữ, số và dấu gạch ngang, đặt độ dài tối đa rõ ràng (thường 20-32 ký tự), và dành tiền tố cho trường hợp đặc biệt (ví dụ “BND-” cho gói). Trong AppMaster, các kiểm tra này phù hợp như ràng buộc dữ liệu + Business Process chặn lưu khi rule bị vi phạm.

Logic tồn kho vượt ra ngoài còn hàng / hết hàng

Tồn kho trở nên rối khi cùng một “sản phẩm” có thể là nhiều đơn vị bán. Trước khi viết quy tắc, chọn đơn vị tồn kho: bạn theo dõi tồn ở mức product, mức variant, hay cả hai?

Nếu khách chọn kích thước hoặc màu, tồn kho theo variant thường an toàn nhất. Một áo có thể “còn hàng” tổng thể, nhưng biến thể Nhỏ-Xanh có thể đã hết. Tồn kho ở mức product phù hợp cho mặt hàng mà biến thể không thay đổi vật lưu trữ (ví dụ license số với các kế hoạch thanh toán khác nhau). Một số đội giữ cả hai: product để báo cáo, variant để bán.

Ngăn oversell không phải về một flag phép màu mà là về các trạng thái rõ ràng. Hầu hết catalog cần reservation (giữ hàng tạm thời cho giỏ hoặc đơn chưa thanh toán), backorders (cho phép bán với ngày giao rõ ràng), buffer tồn (số ẩn để bù trễ đồng bộ), và cập nhật nguyên tử (giảm tồn cùng thao tác xác nhận đơn).

Các edge case là nguồn “tồn bí ẩn”. Trả hàng chỉ nên cộng tồn sau khi kiểm tra, không phải khi tạo nhãn trả hàng. Hàng hư hỏng nên chuyển trạng thái hoặc vị trí riêng để không xuất hiện là có thể bán. Điều chỉnh tồn cần có audit trail (ai thay đổi gì và vì sao), đặc biệt khi nhiều kênh cập nhật tồn.

Gói và kit có một quy tắc chính: đừng giảm bản ghi “gói” nếu gói chỉ là nhóm. Giảm các món thành phần thay vào đó. Một gói 3 chiếc nên giảm 3 đơn vị của cùng một SKU; một kit nên giảm một mỗi thành phần.

Ví dụ: một “Starter Kit” gồm 1 chai và 2 lọc. Nếu bạn có 10 chai và 15 lọc, khả dụng của kit là 7 vì lọc là giới hạn. Toán học theo thành phần giữ báo cáo, hoàn tiền và nhập kho nhất quán.

Trong AppMaster, điều này khớp tự nhiên với bảng variant trong Data Designer và logic reservation/decrement trong Business Process Editor, nên mọi checkout đều theo cùng quy tắc.

Mô hình gói và kit mà không phá báo cáo

Gói là nơi catalog thường chệch thành các trường hợp đặc biệt. Cách đơn giản nhất là mô hình gói như mặt hàng có thể bán bình thường, rồi gắn danh sách thành phần rõ ràng.

Cấu trúc sạch là: Product (mục có thể bán) cộng thêm BundleLines. Mỗi BundleLine trỏ tới một SKU thành phần (hoặc một sản phẩm thành phần + một variant yêu cầu) và lưu số lượng. Đơn hàng vẫn hiển thị “một mục”, nhưng bạn có thể mở rộng thành phần khi cần chi phí, tồn và chi tiết hoàn thành.

Hầu hết thiết lập gói rơi vào một trong các loại:

• Fixed bundle (kit): luôn cùng các thành phần và số lượng.
• Configurable bundle: khách chọn từ các thành phần cho phép (vẫn lưu dưới dạng dòng trên đơn).
• Virtual bundle: nhóm marketing (thường không ảnh hưởng tồn kho), hữu ích để trưng bày mà không ảnh hưởng logic hoàn thành.

Giá là nơi đội thường vô tình phá báo cáo. Quyết định từ đầu những gì hiển thị trên dòng đơn, và gì đẩy báo cáo biên/lợi nhuận. Cách phổ biến là giá cố định cho gói, tổng của các phần, hoặc tổng giảm theo luật (ví dụ “chọn 3, món rẻ nhất giảm 50%”).

Tồn kho nên cũng nghiêm ngặt: một kit chỉ có khi mọi thành phần cần thiết có đủ số lượng. Để báo cáo, lưu hai góc nhìn của giao dịch:

• Mục đã bán: SKU gói (cho doanh thu, chuyển đổi, merchandising).
• Thành phần tiêu thụ: mở rộng BundleLines (cho chuyển động tồn kho, COGS, và phiếu lấy hàng).

Trong AppMaster, điều này phù hợp: một bảng Bundle + hàng BundleLine, với Business Processes mở rộng thành phần khi checkout và ghi cả bán gói lẫn tiêu thụ thành phần trong một transaction.

Mẫu UI cho chọn tuỳ chọn và biến thể

UI chọn tuỳ chọn tốt giữ người dùng tiếp tục. UI xấu khiến họ đoán, gặp lỗi và rời đi. Chìa khóa là dẫn người mua đến một biến thể thực sự có thể mua ngay từ sớm, đồng thời cho thấy rõ các thay đổi do lựa chọn gây ra.

Phía khách: ưu tiên tuỳ chọn trước, biến thể sau

Mẫu đáng tin cậy là hiển thị các tuỳ chọn (Kích thước, Màu, Vật liệu), rồi tính và chỉ hiện các lựa chọn còn hợp lệ.

Thay vì để khách chọn bất kỳ tổ hợp nào rồi báo lỗi khi thêm vào giỏ, vô hiệu hoá các tổ hợp không thể có ngay khi người dùng chọn. Ví dụ, khi chọn Màu = Đen, các kích thước không có phiên bản Đen nên bị vô hiệu hoá (không xoá) để khách hiểu chúng không có hàng.

Khi lựa chọn thay đổi, cập nhật các phần quan trọng nhất: giá (bao gồm giá khuyến mãi và mọi chiết khấu gói), ảnh chính (khớp màu hoặc kiểu), trạng thái tồn kho (tồn kho biến thể chính xác, không phải tồn kho chung sản phẩm), ước tính giao hàng (nếu thay đổi theo biến thể), và tuỳ chọn hiển thị SKU hoặc “Mã hàng” cho hỗ trợ.

Giữ giao diện bình tĩnh. Hiển thị vài nhóm tuỳ chọn một lúc, tránh dropdown lớn khi swatches hoặc nút bấm hiệu quả hơn, và làm cho lựa chọn hiện tại rõ ràng.

Phía quản trị: chỉnh sửa biến thể như bảng tính

Ở admin, người cần tốc độ chứ không cần đẹp. Lưới biến thể hoạt động tốt: mỗi hàng là một SKU, mỗi cột là một tuỳ chọn hoặc một thuộc tính (giá, barcode, trọng lượng, tồn, active/inactive). Thêm hành động hàng loạt cho các tác vụ phổ biến như cập nhật giá, bật/tắt sẵn có, hoặc gán ảnh.

Nếu bạn xây dựng trong AppMaster, một thiết lập thực tế là lưới liên kết với bảng Variant của bạn với bộ lọc (giá trị tuỳ chọn, trạng thái active, tồn thấp), cộng hành động cập nhật hàng loạt xác thực quy tắc trước khi lưu.

Các bước từng bước: chọn biến thể và kiểm tra khả dụng gói

Luồng chọn nên cảm thấy đơn giản, nhưng cần quy tắc nghiêm ngặt phía sau. Mục tiêu là luôn biết SKU chính xác mà người mua đang cấu hình, và liệu nó có thể mua ngay không.

Chọn biến thể (sản phẩm đơn)

Tải nhiều hơn tên sản phẩm và ảnh. Bạn cần toàn bộ tập giá trị tuỳ chọn (Kích thước, Màu) và danh sách các tổ hợp biến thể hợp lệ tồn tại như SKU.

Luồng đáng tin cậy:

1. Lấy product, các options của nó, và tất cả các variant tồn tại (hoặc bản đồ nén các tổ hợp hợp lệ).
2. Lưu lựa chọn hiện tại của người mua (ví dụ: Size=M, Color=Black) và cập nhật sau mỗi click.
3. Sau mỗi thay đổi, tìm variant khớp bằng cách so sánh giá trị tuỳ chọn đã chọn với danh sách variant.
4. Nếu có khớp và có thể mua được (active, giá đã đặt, không bị khoá), bật nút Thêm vào giỏ.
5. Nếu không có khớp, giữ nút Thêm vào giỏ ở chế độ tắt và hướng dẫn người mua đến lựa chọn hợp lệ.

Một chi tiết UI nhỏ nhưng ngăn thất vọng: vô hiệu hoá các giá trị tuỳ chọn không thể ngay khi các lựa chọn trước đó được chọn. Nếu Size=M chỉ tồn tại ở màu Đen, hiển thị các màu khác là không khả dụng khi M được chọn.

Khả dụng gói (kit làm từ các thành phần)

Với gói, “còn hàng” không phải một số đơn. Nó phụ thuộc vào thành phần. Quy tắc thường là:

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

Ví dụ: một “Starter Kit” cần 1 chai và 2 lọc. Nếu bạn có 10 chai và 9 lọc, khả dụng kit là min(floor(10/1)=10, floor(9/2)=4) = 4 kit.

Thông báo lỗi nên cụ thể. Ưu tiên “Chỉ còn 4 kit (lọc giới hạn gói này)” hơn là “Hết hàng.” Trong AppMaster, kiểm tra kiểu này dễ biểu đạt trong Business Process: tính variant khớp trước, rồi tính giới hạn gói, rồi trả trạng thái rõ ràng để UI hiển thị.

Sai lầm phổ biến và bẫy cần tránh

Catalog vỡ khi bạn mô hình cho “mọi thứ có thể tồn tại” thay vì “những gì bạn thực sự sẽ bán.” Cách nhanh nhất để tự rơi vào bế tắc là sinh mọi tổ hợp tuỳ chọn trước, rồi cố giữ sạch khi catalog lớn lên.

Tạo biến thể sẽ không bao giờ có tồn kho là bẫy kinh điển. Nếu bạn có 4 màu x 6 kích x 3 vật liệu thì là 72 biến thể. Nếu chỉ 10 thật sự bán được, 62 bản ghi còn lại tạo lộn xộn, mời lỗi và làm chậm báo cáo.

Giá là nguồn lỗi thầm lặng khác. Vấn đề bắt đầu khi cùng một giá xuất hiện ở nhiều nơi (product, variant, bảng giá, bảng khuyến mãi) mà không có nguồn chân lý duy nhất. Một quy tắc đơn giản: lưu giá cơ bản một lần, chỉ lưu ghi đè nơi thật sự cần (ví dụ một variant có giá khác).

Gói và kit thất bại ở tồn kho khi bạn giảm cả gói và thành phần. Nếu bạn bán “Starter Kit” gồm 1 chai và 2 lọc, trừ 1 kit và cũng trừ 1 chai + 2 lọc sẽ làm tồn giảm quá nhanh. Giữ gói là mục có thể bán, nhưng tính khả dụng và giảm tồn từ thành phần.

Công cụ admin có thể gây hại nếu cho phép dữ liệu không hợp lệ. Thêm hàng rào sớm:

• Chặn SKU trùng lặp, kể cả trên mục đã lưu kho.
• Yêu cầu mỗi variant có đầy đủ giá trị tuỳ chọn (không "thiếu kích thước").
• Ngăn hai variant chia sẻ cùng tổ hợp giá trị tuỳ chọn.
• Xác thực thành phần gói (không có số lượng bằng 0, không có SKU thiếu).

Cuối cùng, lập kế hoạch cho thay đổi. Thêm tuỳ chọn mới sau (ví dụ “Chiều rộng” cho giày) là một migration, không phải một checkbox. Quyết định điều gì xảy ra với các variant hiện có, mặc định thế nào, và đơn cũ giữ snapshot SKU và tuỳ chọn ra sao.

Kiểm tra nhanh trước khi ra mắt

Trước khi ra mắt, rà soát những thứ thực tế thường hỏng: tìm SKU, cập nhật tồn, và chặn mua hàng không thể.

Đảm bảo mọi SKU có thể bán dễ tìm. Tìm kiếm nên tìm theo tên, mã SKU, barcode/GTIN, và thuộc tính chính (như kích thước hoặc màu). Nếu bạn dùng quét trong kho, thử vài lần quét vật lý và xác nhận chúng trỏ tới đúng SKU, không chỉ product cha.

Cứng rắn về nơi xảy ra thay đổi tồn. Chọn một nguồn chân lý (logic chuyển động tồn) và đảm bảo mọi sự kiện dùng nó: đơn, huỷ, trả hàng, điều chỉnh thủ công, và lắp ráp gói. Nếu tồn có thể chỉnh ở hai màn hình hoặc hai workflow, drift là chắc chắn.

Các kiểm tra nên chạy trước khi launch:

• Chọn tuỳ chọn trong UI và xác nhận các tổ hợp không hợp lệ bị chặn sớm (trước khi thêm vào giỏ), không chỉ phát hiện ở checkout.
• Với gói, xác nhận khả dụng do thành phần hiếm nhất điều khiển và số lượng đúng (2 pin cho mỗi kit nên làm giảm khả dụng đi một nửa nếu pin là giới hạn).
• Hủy một SKU và kiểm tra nó biến mất khỏi duyệt và tìm kiếm, nhưng vẫn hiện đúng trong đơn cũ, hoá đơn và báo cáo.
• Đặt một đơn thử, huỷ nó, rồi đặt lại; tồn nên trở về và đặt lại giữ sạch.

Nếu bạn xây dựng trong AppMaster, giữ quy tắc cập nhật tồn trong một Business Process và gọi nó từ mọi đường dẫn. Thói quen đơn giản đó ngăn hầu hết lỗi tồn kho.

Kịch bản ví dụ và bước tiếp theo thực tế

Hãy tưởng tượng một cửa hàng may mặc cần cấu trúc catalog nghiêm túc.

Bạn bán một áo phông có hai tuỳ chọn: Kích thước (S, M, L) và Màu (Đen, Trắng). Mỗi tổ hợp có thể mua là một biến thể riêng với SKU, giá (nếu cần) và tồn kho riêng.

Trong schema, giữ một bản ghi Product cho “Classic T-shirt”, hai bản ghi Option (Size, Color), và các bản ghi Variant. Mỗi Variant lưu các giá trị tuỳ chọn đã chọn (ví dụ Size=M, Color=Black) và SKU (ví dụ TSH-CL-M-BLK). Tồn kho được theo dõi ở mức Variant, không phải Product.

Trên UI, thu hẹp lựa chọn và ngăn dead-ends. Mẫu gọn là: hiển thị tất cả Màu trước, rồi chỉ hiện Kích thước tồn tại cho Màu đã chọn (hoặc ngược lại). Nếu “White + L” không tồn tại, đừng cho chọn nó, hoặc hiển thị là vô hiệu kèm ghi chú rõ ràng.

Bây giờ thêm một gói: “Gift Set” gồm:

• 1x Classic T-shirt (bất kỳ biến thể)
• 1x Sticker pack (SKU đơn giản)

Khả dụng gói bị giới hạn bởi thành phần khan hiếm nhất. Nếu Sticker pack còn 5, bạn không thể bán quá 5 gói, dù áo còn nhiều. Nếu gói yêu cầu một biến thể T-shirt cụ thể (ví dụ Đen M), thì khả dụng gói = min(StickerPackStock, BlackMStock).

Các bước thực tế tiếp theo trong AppMaster:

• Xây các bảng trong Data Designer (Products, Options, OptionValues, Variants, VariantOptionValues, Inventory, Bundles, BundleComponents).
• Triển khai “tìm variant hợp lệ” và “tính khả dụng gói” trong Business Process Editor.
• Sinh giao diện web và native mobile từ cùng dự án, dùng cùng quy tắc lọc biến thể và khả dụng ở mọi nơi.

Nếu bạn muốn nguyên mẫu nhanh end-to-end, AppMaster (AppMaster (appmaster.io)) được thiết kế để xây app đầy đủ với business logic thực tế, chính xác là thứ mà chọn biến thể và quy tắc tồn kho gói phụ thuộc vào.