URD: Sản phẩm

Module	Phiên bản	Cập nhật
CORE-05	v1.1	2026-07-15

Module Sản phẩm làm gì

Xác định các yêu cầu hướng người dùng cho quản lý danh mục sản phẩm: cách chủ merchant tạo và duy trì sản phẩm, các biến thể họ thực sự bán, giá (fares) mà các biến thể đó mang, nhóm hàng tổ chức chúng, và định danh dùng để tra cứu. Danh mục là nền tảng mà mọi kênh bán đọc từ đó.

Bảy ý cần hiểu trước

Đây là phần quan trọng nhất của tài liệu. Hiểu bảy ý dưới đây là hiểu 80% module.

1. Sản phẩm là ý niệm, biến thể mới là thứ bán được

"Áo thun" không phải một thứ khách mua được - nó chỉ là cái tên, mô tả, và nhóm hàng mà chủ quán dùng để gom mọi phiên bản của cùng một món lại với nhau. Cái khách thật sự cầm ra quầy trả tiền là "áo thun đỏ size M" - một biến thể. Mỗi sản phẩm phải có ít nhất một biến thể ngay từ lúc tạo, và đúng một biến thể trong số đó được đánh dấu mặc định.

Ranh giới này rất dễ nhầm vì hai thứ trông giống nhau trên màn hình, nhưng dữ liệu đứng sau lại tách hẳn: giá bán, mã vạch, và số lượng tồn kho đều gắn vào biến thể, không gắn vào sản phẩm.

Thuộc tính	Gắn vào Sản phẩm	Gắn vào Biến thể
Tên, mô tả, nhóm hàng, hình ảnh	Có	-
Kênh bán (hiển thị ở đâu)	Có	-
Giá bán (fare)	-	Có
Mã vạch, mã hàng (SKU), mã QR	-	Có
Tồn kho, đơn vị tính	-	Có
Loại hàng (lưu kho, dịch vụ, combo...)	-	Có

Ngay cả một món chỉ bán một kiểu duy nhất, không có size hay màu để chọn - ví dụ "Nước suối 500ml" - bên dưới vẫn luôn có đúng một biến thể đại diện cho chính món đó. Sản phẩm không bao giờ được bán trực tiếp; nó luôn bán qua biến thể của mình, kể cả khi chỉ có một biến thể.

2. Biến thể được nhận diện bằng tổ hợp lựa chọn, và chỉ những cái được khai mới được sinh ra

Một sản phẩm biến đổi theo các trục - Size, Mức đá, Màu sắc. Mỗi trục mang một danh sách giá trị có thứ tự (S/M/L, hay 100%/50%/0% đá). Một biến thể chọn đúng một giá trị trên mỗi trục nó dùng, và tổ hợp các lựa chọn đó chính là danh tính của biến thể trong sản phẩm - không hai biến thể nào của cùng một sản phẩm được phép trùng tổ hợp.

Điều dễ nhầm ở đây: hệ thống không tự bung hết mọi tổ hợp có thể có. Chủ quán khai trục và giá trị, rồi khai đúng những biến thể mình thực sự bán; hệ thống chỉ sinh đúng bấy nhiêu.

Cho trước	Số tổ hợp lý thuyết	Số biến thể được khai	Số biến thể được sinh
Ly trà sữa có Size (S/M/L) và Mức đá (100/50/0)	3 × 3 = 9	5 (chủ chỉ bán 5 kiểu thực tế, ví dụ không bán size S 100% đá)	5

Đúng một biến thể trong lần khai đó phải là mặc định - cái nào được đánh dấu tường minh thì lấy cái đó, không đánh dấu gì thì biến thể khai báo đầu tiên tự nhiên thành mặc định. Khai hai cái cùng làm mặc định thì cả lô bị từ chối, không riêng biến thể đó.

3. Catalog sở hữu định danh sản phẩm, kho chỉ giữ định danh đơn vị vật lý

Đây là ranh giới hay bị nhầm nhất giữa hai module. Có hai loại "mã" hoàn toàn khác bản chất, và chúng gán ở hai thời điểm khác nhau, hai màn hình khác nhau:

• Định danh catalog - mã hệ thống, slug, mã hàng (SKU), mã vạch, mã QR. Những mã này đại diện cho một kiểu hàng, không phải một món cụ thể nằm trên kệ. Gán lúc chủ quán tạo hoặc sửa biến thể ở màn sản phẩm. Ví dụ: "áo thun đỏ size M" mang mã vạch 8934567890123 - mọi chiếc áo thun đỏ size M trong kho, dù nhập đợt nào, đều dùng chung một mã vạch đó.
• Định danh kho - IMEI, số serial. Những mã này đại diện cho một đơn vị vật lý riêng lẻ, không phải một kiểu hàng. Gán lúc nhập kho, do nhân viên kho nhập hoặc quét lúc nhận hàng. Ví dụ: nhập 10 chiếc điện thoại cùng một mẫu (cùng một biến thể, cùng một mã vạch catalog), nhưng mỗi chiếc mang một IMEI khác nhau - 10 IMEI cho 10 chiếc, dù cả 10 đều là "cùng một sản phẩm" theo catalog.

Nói gọn: catalog trả lời "đây là hàng gì", kho trả lời "đây là chiếc/lô nào". Một biến thể có bật theo dõi lô hay theo dõi serial hay không cũng là một cờ khai ở catalog lúc tạo biến thể - nhưng bản thân mã lô, mã serial thì chỉ sinh ra lúc hàng thật sự về kho.

4. Định danh duy nhất theo từng merchant, không phải toàn hệ thống

Một mã vạch không phải của riêng một merchant - nó thường là mã do nhà sản xuất in sẵn trên bao bì (mã GS1), và hai merchant khác nhau hoàn toàn có thể cùng bán một sản phẩm mang cùng một mã vạch đó. Vì vậy tính duy nhất của một định danh chỉ có ý nghĩa trong phạm vi một merchant - merchant A gán mã vạch 8934567890123 cho "lon nước ngọt X" của mình, merchant B cũng gán đúng mã đó cho "lon nước ngọt X" của họ, và hai việc gán này không đụng nhau, không merchant nào bị từ chối vì "mã đã được dùng" ở nơi khác.

Điều này khác với suy nghĩ tự nhiên rằng "mã vạch là duy nhất trên toàn thế giới nên hệ thống cũng phải chặn trùng toàn hệ thống" - sai, vì đó là mã của nhà sản xuất, không phải mã do một merchant tự sinh ra để quản lý riêng mình.

5. Ba cơ chế nổ thành phần khác nhau: KIT, COMBO, MANUFACTURED

Ba loại hàng này đều "được ghép từ nhiều thứ khác" khi nhìn thoáng qua, nhưng đứng sau là ba cơ chế hoàn toàn khác nhau về tồn kho và thời điểm trừ. Nhầm ba cái này với nhau là nhầm lẫn phổ biến nhất khi mới vào module.

Cơ chế	Bán 1 cái thì trừ gì	Có tồn riêng của chính nó không	Nổ lúc nào	Ví dụ
KIT	Trừ thẳng từng nguyên liệu thô theo công thức	Không - không có mã tồn kho của riêng nó	Ngay lúc bán, tại quầy	Ly trà sữa: bán 1 ly là trừ ngay sữa, trà, trân châu theo định lượng công thức
COMBO	Trừ tồn của từng biến thể thành phần (mỗi thành phần vẫn có tồn riêng của chính nó)	Không - tồn của combo được suy ra từ tồn nhỏ nhất trong các thành phần	Ngay lúc thêm vào giỏ, tại quầy	Combo 2 gà + khoai: bán 1 combo là trừ tồn của biến thể "2 miếng gà" và biến thể "khoai chiên" riêng biệt
MANUFACTURED	Không trừ gì thêm lúc bán - chỉ trừ đúng tồn có sẵn của chính món đó	Có - mang mã tồn kho của riêng nó	Lúc sản xuất (một lệnh sản xuất riêng, tách hẳn khỏi lúc bán)	Mẻ bánh mì nướng sẵn: nướng một mẻ là một lần trừ bột, men, trứng qua lệnh sản xuất; bán từng ổ bánh sau đó chỉ trừ tồn bánh đã nướng, không đụng lại nguyên liệu

Cách phân biệt nhanh: KIT là "pha/làm ngay khi khách gọi", COMBO là "gói nhiều món đã có sẵn tồn riêng lại bán chung một giá", MANUFACTURED là "làm trước, để dành, bán sau". Chỉ MANUFACTURED có tồn kho riêng để merchant nhìn thấy trên bảng tồn; KIT và COMBO đều không có dòng tồn kho của chính món ghép đó.

6. Thứ tự nhận diện mã vạch tại quầy: mã vạch, rồi mã hàng, rồi mã QR, rồi slug, rồi mã hệ thống

Vì mỗi loại mã chỉ duy nhất trong chính loại của nó, không duy nhất chéo giữa các loại, nên hoàn toàn có thể xảy ra chuyện một chuỗi ký tự vừa là mã vạch của biến thể này, vừa tình cờ là mã hàng (SKU) của một biến thể khác trong cùng merchant. Khi thu ngân quét hoặc gõ một chuỗi tại quầy, hệ thống phải luôn ra đúng một kết quả, không phải một danh sách để chọn - nên cần một thứ tự ưu tiên cố định để phân xử.

Thứ tự đó là: mã vạch → mã hàng (SKU) → mã QR → slug → mã hệ thống. Mã vạch và mã hàng đứng đầu vì đây là hai loại mã thu ngân thật sự quét hoặc gõ tại quầy hằng ngày; slug và mã hệ thống đứng cuối vì chúng phục vụ tra cứu nội bộ, không phải để nhập tay ở quầy.

Ví dụ: chuỗi ABC123 là mã vạch của "áo thun đỏ size M", đồng thời cũng (tình cờ) là mã hàng của "áo thun xanh size L". Quét ABC123 tại quầy luôn ra "áo thun đỏ size M" - vì mã vạch thắng mã hàng theo đúng thứ tự trên, không bao giờ ra cả hai, không bao giờ báo lỗi mập mờ.

7. Loại biến thể quyết định cách trừ kho, không có một "chế độ tồn kho" tách riêng

Mỗi biến thể mang đúng một loại trong bảy loại hàng: hàng lưu kho, hàng tiêu hao, dịch vụ, KIT, combo, hàng sản xuất trước, và quyền sử dụng (một biến thể ảo cấp quyền dùng một dịch vụ hoặc tài nguyên, không gắn hàng hóa vật lý nào). Loại này, cộng với một cờ "có theo dõi tồn kho hay không" khai ngay trên chính biến thể đó, là toàn bộ những gì cần để quyết định việc trừ kho hoạt động ra sao - không có thêm một trường "chế độ tồn kho" nào khác đứng cạnh loại biến thể.

Loại biến thể	Theo dõi tồn kho riêng khi nào	Ví dụ
Hàng lưu kho, Hàng sản xuất trước	Có, khi cờ theo dõi tồn được bật trên biến thể	Áo thun đỏ size M; mẻ bánh mì đã nướng
Combo	Không bao giờ - luôn suy ra từ thành phần, bất kể cờ	Combo 2 gà + khoai
Hàng tiêu hao, Dịch vụ, KIT, Quyền sử dụng	Không - luôn tạo không theo dõi tồn riêng, dù cờ có bật hay không	Đá viên (tiêu hao); phí giữ xe (dịch vụ); ly trà sữa (KIT); một suất học thử (quyền sử dụng)

Combo là trường hợp đặc biệt nhất: dù merchant có bật cờ theo dõi tồn cho một biến thể combo, hệ thống vẫn không tạo tồn kho riêng cho nó - vì bản chất combo không phải một mã hàng vật lý độc lập, nó chỉ là một cách gói các biến thể đã có tồn riêng lại bán chung một giá.

Module có những gì

Mười tính năng. Bấm vào mã AREA để sang tab Chi tiết đọc yêu cầu của nhóm đó.

AREA	Tên	Phase	Trạng thái
PRD	Danh mục Sản phẩm	P1	Một phần
CAT	Nhóm hàng	P1	Đã dựng
VAR	Biến thể	P2	Một phần
BND	Combo & Gói bán kèm	P2	Đã dựng
OPT	Tùy chọn Sản phẩm	P2	Một phần
FAR	Fares / Định giá	P2	Đã dựng
PID	Định danh	P1	Một phần
CMP	Khuyến mãi	P3	Một phần
ACC	Kiểm soát Truy cập	P1	Đã dựng
SCH	Kênh bán hàng	P2	Đã dựng

1. Định nghĩa

Thuật ngữ	Định nghĩa
Sản phẩm (Product)	Một mục cơ sở trong danh mục của merchant.
Biến thể (Variant)	Một đơn vị bán được của sản phẩm (ví dụ kích cỡ hoặc hương vị). Thứ thực sự được bán và định giá.
Loại biến thể (Variant type)	Phân loại điều khiển việc quản lý tồn & bundle: STORABLE, CONSUMABLE, SERVICE, KIT, COMBO, MANUFACTURED, ENTITLEMENT (biến thể ảo, cấp quyền dùng dịch vụ/tài nguyên).
Tùy chọn (Option)	Một cách một sản phẩm biến đổi (Size, Mức đá…), thuộc về một sản phẩm; mỗi biến thể chọn một trong các giá trị của nó.
Giá trị tùy chọn (Option value)	Một lựa chọn trên một tùy chọn (S / M / L); duy nhất trong tùy chọn của nó.
Tổ hợp (Combination)	Tập giá trị một biến thể chọn - danh tính của nó trong sản phẩm.
Bộ fare (Fare set)	Container định giá liên kết 1-1 với một biến thể.
Fare	Một mục giá bên trong bộ fare; có thể là giá cơ bản, override, hoặc bậc theo số lượng/thời gian/kênh.
Nhóm hàng (Category)	Một nhóm sản phẩm trong một merchant; mang một loại phân biệt Sản phẩm hoặc Nguyên liệu.
Định danh (Identifier)	Một mã theo lược đồ (SYSTEM, SLUG, SKU, BARCODE, QRCODE) dùng để tra cứu.
Bundle (Gói)	Quan hệ combo, add-on, hoặc thường-mua-cùng giữa các biến thể.
Sản phẩm theo kênh bán (Sale-channel product)	Một ánh xạ kiểm soát sản phẩm nào hiển thị ở kênh nào.

2. Mô hình Khái niệm

Chỉ là khái niệm - schema đầy đủ nằm trong mô hình miền commerce và fares của pricing.

3. Feature

PRD - Danh mục Sản phẩm Một phần

Đặc tả: chưa có PRD riêng · 17 yêu cầu · 1 kịch bản nghiệm thu

Chủ tạo sản phẩm trong một merchant - mỗi sản phẩm có tên/mô tả đa ngôn ngữ, một định danh hệ thống và slug, một biến thể mặc định, hình ảnh, gán kênh bán, và vòng đời đầy đủ (vô hiệu hóa / kích hoạt lại / lưu trữ). Sản phẩm có thể tìm kiếm và liệt kê, lọc theo vai trò.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-PRD-001	Bắt buộc	Chủ có thể tạo một sản phẩm trong một merchant.	Đã dựng
URD-PRD-002	Bắt buộc	Mỗi sản phẩm nhận một định danh do hệ thống sinh và slug.	Đã dựng
URD-PRD-003	Bắt buộc	Tên & mô tả sản phẩm hỗ trợ nhiều ngôn ngữ.	Đã dựng
URD-PRD-004	Bắt buộc	Một biến thể mặc định được tạo cùng mỗi sản phẩm mới.	Đã dựng
URD-PRD-005	Bắt buộc	Chủ có thể cập nhật thông tin sản phẩm.	Đã dựng
URD-PRD-006	Bắt buộc	Chủ có thể vô hiệu hóa / kích hoạt lại / lưu trữ một sản phẩm.	Đã dựng
URD-PRD-007	Bắt buộc	Slug sản phẩm là duy nhất trong cùng một merchant.	Đã dựng
URD-PRD-008	Bắt buộc	Người dùng có thể tìm sản phẩm theo ID hoặc slug.	Đã dựng
URD-PRD-009	Bắt buộc	Người dùng có thể xem danh sách sản phẩm (lọc theo vai trò).	Đã dựng
URD-PRD-010	Nên có	Chủ có thể đính kèm hình ảnh / media cho sản phẩm.	Đã dựng
URD-PRD-011	Nên có	Chủ có thể gán sản phẩm cho các kênh bán cụ thể.	Đã dựng
URD-PRD-012	Nên có	Sản phẩm đã lưu trữ là chỉ đọc; có thể kích hoạt lại để khôi phục trạng thái Kích hoạt.	Đã dựng
URD-PRD-013	Nên có	Sản phẩm hỗ trợ phân cấp cha-con.	Đã dựng
URD-PRD-014	Nên có	Người dùng có thể tìm sản phẩm theo tên (một phần, nhận biết i18n).	Đã dựng
URD-PRD-015	Nên có	Người dùng có thể lọc danh sách sản phẩm theo nhóm hàng.	Đã dựng
URD-PRD-016	Có thể	Chủ có thể nhập danh mục từ CSV / bảng tính.	Chưa dựng
URD-PRD-017	Bắt buộc	Danh mục sản phẩm đồng bộ từ merchant trụ sở chính xuống các merchant con (đồng bộ nền qua hàng đợi).	Đã dựng

AC-PRD-01: Tạo sản phẩm

Cho trước	Khi	Thì
Chủ với một merchant đang hoạt động	Tạo một sản phẩm với tên + nhóm hàng	Sản phẩm được tạo với định danh đã sinh; biến thể mặc định được tạo; sản phẩm liên kết với merchant
Slug sẽ trùng		Hệ thống đảm bảo một slug duy nhất trong merchant

CAT - Nhóm hàng Đã dựng

Đặc tả: PRD-CAT-001 (nguồn dùng chung, thuộc module Kinh doanh) · 8 yêu cầu · 2 kịch bản nghiệm thu

Nhóm hàng (Category) là một phân loại dùng chung: discriminationType xác định nhóm phục vụ Sản phẩm (catalog, module này) hay Nguyên liệu (module Kho); các màn quản lý theo từng domain (màn danh mục sản phẩm ở trang Client, màn danh mục nguyên liệu ở Kho sau này) đều trỏ về định nghĩa chung này. Chủ gom sản phẩm/nguyên liệu vào nhóm hàng với tên đa ngôn ngữ và mô tả, icon + màu hiển thị, phân cấp cha-con tối đa 8 tầng, và chính sách xóa theo merchant.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-CAT-001	Bắt buộc	Nhóm/danh mục được tạo và quản lý (danh sách/tạo/sửa) trong một merchant.	Đã dựng
URD-CAT-002	Bắt buộc	Đổi tên nhóm không ảnh hưởng sản phẩm/nguyên liệu trong nhóm.	Đã dựng
URD-CAT-003	Bắt buộc	Xóa nhóm là soft-delete theo chính sách xóa của merchant. • Strict bật: chặn xóa nhóm còn con. • Strict tắt: con gắn lên cha của node bị xóa. • Nhóm còn sản phẩm/nguyên liệu liên kết luôn bị chặn.	Đã dựng
URD-CAT-004	Bắt buộc	Nhóm mang tên + mô tả đa ngôn ngữ, kèm icon + màu hiển thị.	Đã dựng
URD-CAT-005	Bắt buộc	Nhóm lập phân cấp cha-con trong merchant, tối đa 8 cấp; tự-làm-cha và vòng lặp bị chặn.	Đã dựng
URD-CAT-006	Nên có	Nhóm hệ thống dùng chung (không thuộc merchant) là chỉ-đọc với merchant, không xóa được.	Đã dựng
URD-CAT-007	Nên có	Mẫu nhóm theo ngành được tạo sẵn lúc onboarding (xem URD-ORG-017 ở module Kinh doanh).	Đã dựng
URD-CAT-008	Nên có	Mỗi nhóm mang một loại phân biệt (discriminationType): nhóm Sản phẩm phục vụ catalog, nhóm Nguyên liệu phục vụ module Kho.	Đã dựng

AC-CAT-01: Quản lý nhóm & vòng đời

Cho trước	Khi	Thì
Chủ với một merchant đang hoạt động	Tạo một nhóm với tên đa ngôn ngữ	Nhóm được tạo và giới hạn theo merchant
Một nhóm có sản phẩm/nguyên liệu liên kết	Đổi tên	Đổi tên thành công; sản phẩm/nguyên liệu không bị ảnh hưởng
Một nhóm có sản phẩm/nguyên liệu liên kết	Xóa (bất kể chính sách)	Bị chặn
strict bật; nhóm có nhóm con	Xóa	Bị chặn
strict tắt; nhóm có nhóm con	Xóa	Các con được gắn lên cha của node bị xóa; node bị soft-delete

AC-CAT-02: Phân cấp & loại phân biệt

Cho trước	Khi	Thì
Một nhóm lồng ở tầng thứ 8	Chọn thêm một nhóm con	Bị chặn - vượt giới hạn 8 tầng
Chọn cha tạo thành vòng lặp	Lưu	Bị chặn
Một nhóm hệ thống dùng chung	Merchant thử sửa hoặc xóa	Bị từ chối
Một nhóm được tạo cho nguyên liệu	Lưu	discriminationType được lưu là Nguyên liệu, phục vụ module Kho

VAR - Biến thể Một phần

Đặc tả: chưa có PRD riêng · 13 yêu cầu · 1 kịch bản nghiệm thu

Chủ thêm nhiều biến thể bán được cho mỗi sản phẩm, mỗi biến thể có loại (STORABLE/CONSUMABLE/SERVICE/KIT/COMBO/MANUFACTURED/ENTITLEMENT), đơn vị đo lường, định danh, khoảng thời gian hiệu lực, và quan hệ bundle - được tạo hoặc cập nhật trong một thao tác liền mạch cùng với thông tin, bộ fare, fares, và định danh.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-VAR-001	Bắt buộc	Mỗi sản phẩm có ít nhất một biến thể; trạng thái có thể thay đổi.	Đã dựng
URD-VAR-002	Bắt buộc	Chủ có thể tạo thêm biến thể.	Đã dựng
URD-VAR-003	Bắt buộc	Tạo aggregate: biến thể + thông tin + bộ fare + fares + định danh trong một thao tác liền mạch.	Đã dựng
URD-VAR-004	Bắt buộc	Cập nhật aggregate: cập nhật một biến thể cùng mọi dữ liệu liên quan trong một thao tác liền mạch.	Đã dựng
URD-VAR-005	Bắt buộc	Mỗi biến thể có một định danh do hệ thống sinh.	Đã dựng
URD-VAR-006	Bắt buộc	Loại biến thể (STORABLE / CONSUMABLE / SERVICE / KIT / COMBO / MANUFACTURED / ENTITLEMENT) có thể chọn.	Đã dựng
URD-VAR-007	Nên có	Biến thể có thể có khoảng thời gian hiệu lực.	Một phần
URD-VAR-008	Nên có	Chủ có thể gán định danh SKU / BARCODE / QRCODE.	Một phần
URD-VAR-009	Nên có	Biến thể lưu đơn vị đo lường cơ sở / mua / bán.	Đã dựng
URD-VAR-010	Nên có	Bundle liên hệ các biến thể như combo / add-on / thường-mua-cùng.	Đã dựng
URD-VAR-011	Có thể	Giá đã giải quyết của một biến thể có thể đọc qua một endpoint chuyên biệt.	Chưa dựng
URD-VAR-012	Có thể	Quy đổi đơn vị giữa đơn vị mua và đơn vị bán.	Chưa dựng
URD-VAR-013	Nên có	Biến thể của một sản phẩm đã lưu trữ không còn bán được ở bất kỳ kênh nào.	Chưa dựng

AC-VAR-01: Biến thể aggregate

Cho trước	Khi	Thì
Một sản phẩm có sẵn	Chủ tạo một biến thể với thông tin, fares, và định danh trong một bước	Biến thể + thông tin + bộ fare + fares + định danh được tạo trong một thao tác liền mạch
Bất kỳ bước con nào thất bại		Toàn bộ thao tác rollback; không có gì được lưu

BND - Combo & Gói bán kèm Đã dựng

Đặc tả: PRD-BND-001 · 16 yêu cầu · 5 kịch bản nghiệm thu

Chủ liên kết hai biến thể bằng một gói có kiểu - một combo (định giá một lần, cấu thành từ các biến thể thành phần), một add-on (một biến thể liên quan miễn phí gắn vào một dòng chủ), hoặc một gợi ý mua-kèm-thường-xuyên (có hướng, với giá ghi-đè tùy chọn riêng). Tại điểm bán một combo được bung phía máy chủ thành một dòng dẫn có giá cùng các dòng thành phần giá-không, số lượng thành phần nhân theo số lượng combo, và add-on / FBT gắn vào một dòng dẫn cấp-cao nhất hiện có. Việc bung được rào chắn khỏi độ sâu vượt mức, chu trình và combo rỗng, và toàn bộ đồ thị gói được tạo liền mạch cùng biến thể. Đây là chi tiết tính năng đằng sau đề cập gói ở URD-VAR-010.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-BND-001	Bắt buộc	Một gói liên kết một biến thể dẫn với một biến thể liên quan theo một trong ba kiểu: COMBO, ADDON, FBT.	Đã dựng
URD-BND-002	Bắt buộc	Một combo cấu thành từ các biến thể thành phần mỗi cái có số lượng riêng; combo được định giá, thành phần về không.	Đã dựng
URD-BND-003	Bắt buộc	Một add-on liên kết một biến thể liên quan luôn-miễn-phí với một biến thể chủ.	Đã dựng
URD-BND-004	Nên có	Một mục FBT gợi ý một biến thể liên quan, có hướng, và có thể mang giá ghi-đè riêng (cố định / phần trăm / theo-đơn-vị / bậc thang) hoặc lùi về fare của biến thể được gợi ý.	Đã dựng
URD-BND-005	Bắt buộc	Cùng một quan hệ (kiểu, dẫn, liên quan) không thể trùng lặp.	Đã dựng
URD-BND-006	Nên có	Các gói của một biến thể dẫn và một kiểu mang thứ tự hiển thị.	Đã dựng
URD-BND-007	Bắt buộc	Các gói được tạo liền mạch cùng biến thể; mọi lỗi quay lui toàn bộ thao tác tạo.	Đã dựng
URD-BND-008	Bắt buộc	Thêm một combo vào giỏ bung nó phía máy chủ thành một dòng dẫn có giá cùng các dòng con thành phần giá-không liên kết với dòng dẫn.	Đã dựng
URD-BND-009	Bắt buộc	Số lượng mỗi thành phần là số-lượng-mỗi-combo × số lượng combo; một thành phần đến từ nhiều nhánh được gộp vào một dòng với số lượng cộng dồn.	Đã dựng
URD-BND-010	Nên có	Combo có thể lồng nhau; việc bung đệ quy đến tối đa năm cấp độ sâu.	Đã dựng
URD-BND-011	Bắt buộc	Một combo vượt giới hạn độ sâu, tạo chu trình, hoặc không có thành phần bị từ chối kèm lý do cụ thể.	Đã dựng
URD-BND-012	Bắt buộc	Dòng thành phần combo không thể sửa trực tiếp; chủ sửa dòng dẫn combo và các con tự nhân theo.	Đã dựng
URD-BND-013	Bắt buộc	Một biến thể sản phẩm combo phải khai báo ít nhất một thành phần combo khi tạo.	Đã dựng
URD-BND-014	Nên có	Một mục add-on hoặc FBT gắn tại điểm bán vào một dòng dẫn cấp-cao nhất hiện có, được kiểm khớp với quan hệ đã cấu hình; combo không thể gắn theo cách này.	Đã dựng
URD-BND-015	Nên có	Một add-on vẫn giữ chỗ tồn cho thành phần của nó dù miễn phí.	Đã dựng
URD-BND-016	Nên có	Mỗi dòng dẫn combo và dòng thành phần ghi lại combo cùng các dòng gói đã sinh ra nó cho bếp / hoàn tiền / kiểm toán về sau.	Đã dựng

AC-BND-01: Combo bung khi thêm vào giỏ

Cho trước	Khi	Thì
Một combo định giá một lần, gồm 1 burger + 1 khoai + 1 nước	Thu ngân thêm combo vào giỏ	Một dòng dẫn có giá cùng ba dòng thành phần giá-không liên kết với dòng dẫn được tạo
Cùng combo đó, số lượng hai	Thu ngân thêm vào	Mỗi dòng thành phần được nhân lên gấp đôi số-lượng-mỗi-combo

AC-BND-02: Rào chắn bung combo

Cho trước	Khi	Thì
Một combo lồng quá năm cấp	Thu ngân thêm vào	Từ chối - combo lồng quá sâu
Một combo gián tiếp tham chiếu chính nó	Thu ngân thêm vào	Từ chối - phát hiện chu trình combo
Một biến thể combo không có thành phần	Thu ngân thêm vào	Từ chối - combo không có thành phần

AC-BND-03: Gắn add-on / FBT

Cho trước	Khi	Thì
Một dòng dẫn cấp-cao nhất và một quan hệ add-on đã cấu hình	Thu ngân gắn add-on	Một dòng add-on miễn phí được tạo dưới dòng dẫn và tồn của nó được giữ chỗ
Một quan hệ FBT đã cấu hình	Thu ngân gắn mục FBT	Một dòng mang giá riêng (có thể ghi-đè) được tạo dưới dòng dẫn
Một quan hệ combo	Thu ngân thử gắn	Từ chối - combo được máy chủ bung, không gắn được
Mục không khớp biến thể dẫn / liên quan đã cấu hình của gói	Thu ngân gắn	Từ chối - quan hệ gói không khớp

AC-BND-04: Dòng combo giữ nhất quán

Cho trước	Khi	Thì
Một combo trên đơn	Chủ thử sửa trực tiếp một dòng thành phần	Từ chối - thành phần không sửa trực tiếp được
Cùng combo đó	Chủ sửa số lượng dòng dẫn combo	Mọi dòng thành phần tự nhân theo

AC-BND-05: Tạo gói

Cho trước	Khi	Thì
Một biến thể sản phẩm combo khai báo không có thành phần combo	Chủ tạo nó	Từ chối - một biến thể combo phải khai báo ít nhất một thành phần
Một biến thể có gói combo / add-on / FBT	Chủ tạo nó; bất kỳ bước con nào thất bại	Toàn bộ thao tác tạo biến thể quay lui; không dòng gói nào được lưu

OPT - Tùy chọn Sản phẩm Một phần

Đặc tả: PRD-OPT-001 · PRD-OPT-002 · 20 yêu cầu · 10 kịch bản nghiệm thu

Chủ định nghĩa các tùy chọn mà sản phẩm biến đổi theo (Size, Mức đá, Màu sắc…) với giá trị có thứ tự, và mỗi biến thể chọn một giá trị mỗi tùy chọn - nhờ đó mỗi biến thể được nhận diện duy nhất bằng tổ hợp lựa chọn của nó. Khi tạo sản phẩm, chủ khai báo các trục tùy chọn cùng với đúng những biến thể cần sinh, và hệ thống tạo toàn bộ sản phẩm - tùy chọn, giá trị, biến thể, liên kết, định danh và thuộc tính kho - một cách liền mạch, giải quyết một biến thể mặc định, và làm mỗi biến thể tra được theo tùy chọn của nó trong tìm kiếm.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-OPT-001	Bắt buộc	Chủ định nghĩa các tùy chọn của sản phẩm, mỗi tùy chọn có một tên và một thứ tự hiển thị.	Đã dựng
URD-OPT-002	Bắt buộc	Mỗi tùy chọn mang một danh sách giá trị được sắp thứ tự.	Đã dựng
URD-OPT-003	Bắt buộc	Một tùy chọn và các giá trị của nó được tạo hoặc đổi cùng nhau trong một bước.	Đã dựng
URD-OPT-004	Bắt buộc	Biến thể khai báo giá trị của nó trên mỗi tùy chọn nó dùng; tùy chọn hoặc giá trị lạ bị từ chối.	Đã dựng
URD-OPT-005	Bắt buộc	Một biến thể chọn tối đa một giá trị mỗi tùy chọn.	Đã dựng
URD-OPT-006	Bắt buộc	Mọi giá trị một biến thể dùng phải thuộc về sản phẩm và về tùy chọn của nó.	Đã dựng
URD-OPT-007	Bắt buộc	Không có hai biến thể nào của một sản phẩm dùng chung một tổ hợp; biến thể không tùy chọn được miễn.	Đã dựng
URD-OPT-008	Bắt buộc	Một cài đặt merchant có thể buộc mọi biến thể dùng tùy chọn, từ chối biến thể không tùy chọn.	Đã dựng
URD-OPT-009	Nên có	Chủ có thể đổi các tùy chọn mà một biến thể dùng.	Đã dựng
URD-OPT-010	Nên có	Một tùy chọn không có giá trị nào, hoặc một lựa chọn trùng, bị từ chối.	Đã dựng
URD-OPT-011	Bắt buộc	Khi tạo sản phẩm, chủ cung cấp cả các trục tùy chọn và đúng những biến thể cần sinh, mỗi biến thể khai báo lựa chọn của nó trên từng trục.	Đã dựng
URD-OPT-012	Bắt buộc	Chỉ những biến thể đã khai báo được sinh - hệ thống không bao giờ tự bung trọn ma trận tùy chọn.	Đã dựng
URD-OPT-013	Bắt buộc	Trục tùy chọn, giá trị của chúng, và mọi biến thể đã khai báo được sinh cùng sản phẩm trong một thao tác liền mạch.	Đã dựng
URD-OPT-014	Bắt buộc	Đúng một biến thể được sinh là mặc định: cái được đánh dấu tường minh, nếu không thì cái khai báo đầu tiên được nâng.	Đã dựng
URD-OPT-015	Bắt buộc	Khai báo nhiều hơn một mặc định tường minh trong cùng yêu cầu tạo bị từ chối.	Đã dựng
URD-OPT-016	Nên có	Chủ có thể đổi biến thể nào là mặc định sau khi tạo.	Đã dựng
URD-OPT-017	Nên có	Mỗi biến thể được sinh có thể mang SKU / barcode riêng; một barcode lặp trong-yêu-cầu hoặc đã dùng trong merchant bị từ chối.	Đã dựng
URD-OPT-018	Nên có	Thuộc tính quản lý tồn chỉ sinh cho loại biến thể quản lý tồn; combo và loại không quản lý tồn được tạo không theo dõi.	Đã dựng
URD-OPT-019	Nên có	Biến thể được sinh và lựa chọn tùy chọn của chúng được phản chiếu vào tìm kiếm, giữ tươi mới khi trục, giá trị, hoặc liên kết đổi.	Đã dựng
URD-OPT-020	Nên có	Trục và giá trị tùy chọn được chuẩn hóa (không phân biệt hoa thường) để các lựa chọn tương đương gộp về một.	Một phần

AC-OPT-01: Định nghĩa tùy chọn và khai báo biến thể

Cho trước	Khi	Thì
Sản phẩm có tùy chọn Size (S/M/L) và Mức đá (100/50/0)	Chủ khai báo một biến thể cho Lớn, 50% đá	Biến thể được lưu với hai giá trị đã chọn
Cùng sản phẩm đó	Chủ khai báo một biến thể dùng một size không tồn tại	Bị từ chối - giá trị không thuộc sản phẩm

AC-OPT-02: Tổ hợp trùng bị từ chối

Cho trước	Khi	Thì
Một biến thể cho Lớn, 50% đá đã tồn tại	Chủ khai báo một biến thể khác cho cùng Lớn, 50% đá	Bị từ chối - tổ hợp là như nhau bất kể thứ tự chọn

AC-OPT-03: Cài đặt bắt buộc tùy chọn

Cho trước	Khi	Thì
Cài đặt bắt buộc tùy chọn đang bật	Chủ tạo một biến thể không dùng tùy chọn nào	Bị từ chối - mọi biến thể phải dùng tùy chọn
Cài đặt tắt	Cùng yêu cầu đó	Biến thể được lưu; biến thể không tùy chọn có thể cùng tồn tại

AC-OPT-04: Lựa chọn nằm trong sản phẩm

Cho trước	Khi	Thì
Một tùy chọn thuộc sản phẩm A	Một biến thể của sản phẩm B thử dùng nó	Bị từ chối - tùy chọn không thuộc sản phẩm đó
Một giá trị thuộc tùy chọn Size	Một biến thể ghép nó với tùy chọn Mức đá	Bị từ chối - giá trị không thuộc tùy chọn đó

AC-OPT-05: Sinh biến thể tường minh

Cho trước	Khi	Thì
Một sản phẩm có trục Size (S/M/L) và Đá (100/50/0)	Chủ tạo nó khai báo năm biến thể cụ thể	Đúng năm biến thể đó được sinh - không bao giờ là ma trận chín ô đầy đủ
Cùng thao tác tạo đó	Bất kỳ bước con nào thất bại (tùy chọn sai, barcode trùng, hai mặc định)	Toàn bộ đồ thị sản phẩm rollback; không lưu gì

AC-OPT-06: Biến thể mặc định khi sinh

Cho trước	Khi	Thì
Nhiều biến thể khai báo, một cái đánh dấu mặc định	Sản phẩm được tạo	Biến thể được đánh dấu là mặc định
Nhiều biến thể khai báo, không cái nào đánh dấu	Sản phẩm được tạo	Biến thể khai báo đầu tiên được nâng thành mặc định
Hai biến thể khai báo đánh dấu mặc định	Sản phẩm được tạo	Bị từ chối - chỉ cho phép một mặc định

AC-OPT-07: Đổi mặc định sau khi tạo

Cho trước	Khi	Thì
Một sản phẩm có mặc định là biến thể A	Chủ nâng biến thể B thành mặc định	B trở thành mặc định và A không còn là mặc định

AC-OPT-08: Tính duy nhất barcode theo từng biến thể

Cho trước	Khi	Thì
Hai biến thể khai báo mang cùng một barcode	Sản phẩm được tạo	Bị từ chối - barcode trùng trong yêu cầu
Barcode của một biến thể khai báo đã tồn tại trong merchant	Sản phẩm được tạo	Bị từ chối - barcode đã được dùng

AC-OPT-09: Thuộc tính kho theo loại biến thể

Cho trước	Khi	Thì
Một loại biến thể quản lý tồn	Biến thể được sinh	Thuộc tính quản lý tồn được sinh cho mỗi biến thể
Một loại combo hoặc không quản lý tồn	Biến thể được sinh	Biến thể được tạo không theo dõi

AC-OPT-10: Biến thể tra được theo tùy chọn

Cho trước	Khi	Thì
Một biến thể được sinh liên kết Size=M, Đá=50	Tìm kiếm được truy vấn/lọc theo giá trị tùy chọn của nó	Biến thể được trả về và lọc được theo size và ice
Trục, giá trị, hoặc liên kết của nó đổi sau đó	Thay đổi được áp dụng	Facet tùy chọn của biến thể trong tìm kiếm được làm tươi tương ứng

FAR - Fares / Định giá Đã dựng

Đặc tả: PRD-FAR-001 · engine chính thuộc module Định giá

Định nghĩa engine fare/định giá (chọn giá thắng, fare cha-con, thuế, snapshot) là nguồn chính ở module Định giá. Khu này chỉ là phần UI chủ sửa giá bán ngay trong màn sản phẩm (PRD-FAR-001); chi tiết engine xem module Định giá.

PID - Định danh Một phần

Đặc tả: PRD-PID-001 · 10 yêu cầu · 1 kịch bản nghiệm thu

Sản phẩm và biến thể được tra cứu bằng mã theo lược đồ - SYSTEM và SLUG được tự sinh, trong khi chủ có thể gắn định danh SKU, BARCODE, và QRCODE, mỗi mã duy nhất theo từng lược đồ trong một merchant.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-PID-001	Bắt buộc	Mỗi định danh là duy nhất theo từng lược đồ trong một merchant.	Đã dựng
URD-PID-002	Bắt buộc	Một sản phẩm / biến thể có thể giữ nhiều định danh trên các lược đồ.	Đã dựng
URD-PID-003	Bắt buộc	Định danh SYSTEM và SLUG được tự sinh khi tạo.	Đã dựng
URD-PID-004	Nên có	Chủ có thể gán định danh SKU, BARCODE, QRCODE.	Một phần
URD-PID-005	Bắt buộc	Một barcode được nhập/quét tại quầy luôn ra đúng một biến thể, sẵn sàng thêm vào giỏ.	Một phần
URD-PID-006	Bắt buộc	Một barcode không khớp gì trả về kết quả "không tìm thấy" rõ ràng, kèm lối rẽ tìm theo tên/SKU.	Chưa dựng
URD-PID-007	Bắt buộc	Khi một chuỗi khớp nhiều hơn một lược đồ định danh, việc phân giải theo một thứ tự lược đồ cố định, xác định.	Chưa dựng
URD-PID-008	Nên có	Máy quét phần cứng và gõ tay đi qua cùng một tra cứu, cho cùng kết quả.	Chưa dựng
URD-PID-009	Nên có	Biến thể tìm ra mang đúng giá và tình trạng còn hàng theo kênh, như khi chọn thủ công.	Chưa dựng
URD-PID-010	Có thể	Barcode cân ký được đọc theo đoạn mã hàng, còn đoạn trọng lượng/giá nhúng trong mã được hiểu là số lượng/giá.	Chưa dựng

SKU, BARCODE, và QRCODE là định danh catalog (thuộc module Sản phẩm), gán lúc tạo/sửa biến thể ở màn sản phẩm. Định danh đơn vị vật lý ở kho (IMEI, số serial) thuộc module Kho, gán lúc nhập kho.

AC-PID-01: Tra cứu định danh

Cho trước	Khi	Thì
Một sản phẩm được tạo	Khi tạo	Định danh SYSTEM và SLUG được tự sinh
Chủ gán một SKU/BARCODE/QRCODE	Lưu	Định danh duy nhất theo từng lược đồ trong merchant

CMP - Khuyến mãi Một phần

Đặc tả: chưa có PRD riêng · 3 yêu cầu · 1 kịch bản nghiệm thu

Chủ tạo và quản lý các chiến dịch khuyến mãi giới hạn theo merchant với khoảng ngày và giới hạn sử dụng; việc áp dụng chiết khấu tự động tại thời điểm định giá chưa được bật.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-CMP-001	Nên có	Chủ có thể tạo và quản lý chiến dịch khuyến mãi (với khoảng ngày, giới hạn sử dụng).	Một phần
URD-CMP-002	Nên có	Khuyến mãi được giới hạn theo một merchant.	Một phần
URD-CMP-003	Có thể	Chiết khấu khuyến mãi được áp dụng tự động tại thời điểm định giá.	Chưa dựng

CRUD khuyến mãi đã hoạt động; engine tính chiết khấu đang bị tắt, nên chiết khấu chưa được áp dụng tự động. Xem khuyến mãi của pricing.

AC-CMP-01: Chiến dịch khuyến mãi

Cho trước	Khi	Thì
Chủ với một merchant đang hoạt động	Tạo một chiến dịch khuyến mãi với khoảng ngày và giới hạn sử dụng	Chiến dịch được tạo và giới hạn theo merchant

ACC - Kiểm soát Truy cập Đã dựng

Đặc tả: chưa có PRD riêng · 4 yêu cầu · 1 kịch bản nghiệm thu

Mọi thao tác sản phẩm được lọc theo vai trò của người dùng yêu cầu - chủ và nhân viên chỉ thấy sản phẩm trong các merchant của mình/được phân công, trong khi admin bỏ qua lọc theo vai trò.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-ACC-001	Bắt buộc	Mọi thao tác sản phẩm được lọc theo vai trò của người dùng yêu cầu.	Đã dựng
URD-ACC-002	Bắt buộc	Chủ chỉ thấy sản phẩm dưới các merchant của mình.	Đã dựng
URD-ACC-003	Bắt buộc	Nhân viên chỉ thấy sản phẩm trong các merchant được phân công.	Đã dựng
URD-ACC-004	Bắt buộc	Admin / Super Admin bỏ qua lọc theo vai trò.	Đã dựng

AC-ACC-01: Truy cập theo vai trò

Cho trước	Khi	Thì
Chủ với merchant X, Y	Xem sản phẩm	Chỉ sản phẩm dưới X và Y được trả về
Nhân viên phân công cho X	Xem sản phẩm	Chỉ sản phẩm dưới X được trả về
Admin	Xem sản phẩm	Mọi sản phẩm được trả về; bỏ qua lọc

SCH - Kênh bán hàng Đã dựng

Đặc tả: PRD-SCH-001 · 13 yêu cầu · 6 kịch bản nghiệm thu

Chủ tổ chức những gì mình bán thành các kênh bán hàng - bề mặt thực đơn có tên, đa ngôn ngữ, phân cấp (tại quầy, mang đi, giao hàng, ki-ốt). Một sản phẩm chỉ hiển thị trong một kênh khi được gán vào đó, nên hiển thị là một công tắc duy nhất bật khi tạo sản phẩm. Mỗi kênh mang một chuỗi vị trí kho theo thứ tự ưu tiên (ưu tiên thấp nhất là nguồn kho mặc định tự chọn), có trạng thái vòng đời (kích hoạt / ngừng / lưu trữ), và không thể bị ngừng khi vẫn còn đơn đang hoạt động. Mọi danh sách kênh và sản phẩm được phục vụ đã lọc theo quyền của người gọi - một chủ chỉ thấy kênh của các merchant của mình, admin thấy tất cả - nên thực đơn một thiết bị nhận được luôn được giới hạn theo người đang hỏi. Đây là tính năng chi tiết đằng sau nhắc đến kênh bán hàng tại URD-PRD-011.

Mã	Ưu tiên	Yêu cầu	Trạng thái
URD-SCH-001	Bắt buộc	Chủ có thể tạo kênh bán hàng trong một merchant, mỗi kênh có tên/mô tả đa ngôn ngữ và một định danh hệ thống tự sinh.	Đã dựng
URD-SCH-002	Bắt buộc	Slug kênh là duy nhất giữa các kênh chưa xóa (mọi trạng thái) trong cùng một merchant.	Đã dựng
URD-SCH-003	Bắt buộc	Một kênh có trạng thái vòng đời: kích hoạt, ngừng, lưu trữ.	Đã dựng
URD-SCH-004	Bắt buộc	Chủ có thể cập nhật một kênh; một cập nhật không có trường nào bị từ chối.	Đã dựng
URD-SCH-005	Bắt buộc	Việc ngừng một kênh bị từ chối khi nó còn đơn bán đang hoạt động.	Đã dựng
URD-SCH-006	Nên có	Kênh hỗ trợ phân cấp cha-con.	Đã dựng
URD-SCH-007	Bắt buộc	Một sản phẩm được gán vào một hoặc nhiều kênh; việc gán quyết định sản phẩm có hiển thị trong kênh đó không.	Đã dựng
URD-SCH-008	Bắt buộc	Các gán sản phẩm-vào-kênh được ghi như một phần của bước tạo sản phẩm toàn vẹn.	Đã dựng
URD-SCH-009	Nên có	Một kênh mang một chuỗi vị trí kho theo thứ tự ưu tiên; vị trí ưu tiên thấp nhất là mặc định tự chọn; chuỗi được diff-sync khi cập nhật.	Đã dựng
URD-SCH-010	Bắt buộc	Xóa một kênh sẽ bỏ gán các sản phẩm của nó và soft-delete kênh.	Đã dựng
URD-SCH-011	Bắt buộc	Danh sách/đếm kênh và sản phẩm được phục vụ đã lọc theo quyền của người gọi; admin bỏ qua bộ lọc.	Đã dựng
URD-SCH-012	Nên có	Kênh và sản phẩm có thể tìm kiếm, giới hạn theo các merchant của người gọi.	Đã dựng
URD-SCH-013	Nên có	Tạo kênh đầu tiên của một merchant hoàn tất bước onboarding kênh của merchant.	Đã dựng

AC-SCH-01: Tạo một kênh

Cho trước	Khi	Thì
Chủ với một merchant đang hoạt động	Tạo một kênh với tên đa ngôn ngữ và một slug	Kênh được tạo, giới hạn theo merchant, với một định danh hệ thống tự sinh
Một kênh đang hoạt động trong merchant đã dùng slug đó	Chủ tạo kênh khác cùng slug	Bị từ chối - slug đã được dùng trong merchant này

AC-SCH-02: Hiển thị theo kênh qua gán sản phẩm

Cho trước	Khi	Thì
Một kênh Tại quầy và một kênh Giao hàng	Chủ tạo một sản phẩm chỉ gán cho Tại quầy	Sản phẩm hiển thị trong Tại quầy và không trong Giao hàng
Cùng sản phẩm đó	Chủ gán thêm vào Giao hàng	Sản phẩm giờ hiển thị trong cả hai kênh

AC-SCH-03: Chốt chặn khi ngừng

Cho trước	Khi	Thì
Một kênh còn đơn (đang hoạt động) đang mở	Chủ ngừng kênh	Bị từ chối - kênh còn đơn đang hoạt động
Cùng kênh sau khi đơn được đóng / hủy	Chủ ngừng nó	Kênh được ngừng

AC-SCH-04: Chuỗi vị trí kho

Cho trước	Khi	Thì
Một kênh tạo với các vị trí [A, B, C]	Kênh được lưu	Vị trí A (ưu tiên thấp nhất) là nguồn kho mặc định tự chọn
Chuỗi được cập nhật thành [B, A]	Cập nhật được áp dụng	B trở thành mặc định; vị trí bị loại được bỏ gán; vị trí còn lại giữ hàng của nó
Đầu vào liệt kê một vị trí hai lần	Kênh được lưu	Bản trùng gộp về lần xuất hiện đầu

AC-SCH-05: Phục vụ đã giới hạn theo quyền

Cho trước	Khi	Thì
Chủ được grant merchant X và Y	Liệt kê kênh / sản phẩm	Chỉ kênh / sản phẩm của X và Y được trả về
Nhân viên phân công cho X	Liệt kê kênh / sản phẩm	Chỉ của X được trả về
Admin / Super Admin	Liệt kê kênh / sản phẩm	Tất cả được trả về; bỏ qua lọc

AC-SCH-06: Xóa bỏ gán sản phẩm

Cho trước	Khi	Thì
Một kênh có sản phẩm được gán	Chủ xóa kênh	Các gán sản phẩm của kênh được bỏ gán và kênh được soft-delete

4. Ràng buộc

Mã	Ràng buộc
C-01	Một sản phẩm thuộc đúng một merchant.
C-02	Slug sản phẩm là duy nhất trong cùng một merchant.
C-03	Mỗi sản phẩm có ít nhất một biến thể.
C-04	Mỗi biến thể có đúng một bộ fare với ít nhất một fare.
C-05	Thao tác tạo / cập nhật aggregate là toàn vẹn: hoặc thành công trọn vẹn, hoặc không lưu gì cả.
C-06	Mọi bản ghi dùng soft-delete; không có gì bị xóa vật lý.
C-07	Lọc theo vai trò áp dụng cho mọi thao tác liệt kê và đếm.

5. Loại trừ

Sản phẩm cố ý không làm những việc sau.

Mã	Việc không làm
N-01	Định mức nguyên vật liệu & công thức sản xuất - thuộc Kho.
N-02	Mức tồn theo địa điểm - thuộc Kho.
N-03	Xử lý đơn hàng & thanh toán - thuộc Đơn hàng.
N-04	Tính chiết khấu khuyến mãi tại thời điểm định giá - engine đang triển khai, xem CMP.
N-05	Engine quy đổi đơn vị - dự kiến.
N-06	Nhập danh mục hàng loạt / CSV / bảng tính - dự kiến.
N-07	Đặc tả API kỹ thuật - thuộc tài liệu lập trình viên.
N-08	Engine fare/định giá (chọn fare thắng, thuế, snapshot) - thuộc Định giá.

Lịch sử phiên bản

Ngày	Người	Thay đổi	Phiên bản
2026-02-26	P. Do - Product Owner	User story & yêu cầu ban đầu.	v0.1
2026-04-16	P. Do - Product Owner	Mở rộng yêu cầu biến thể & fare.	v0.3
2026-05-29	Di chuyển tài liệu	Tái cấu trúc theo quy ước module-docs; trung thực trạng thái Built/In-progress/Planned theo tài liệu dev; tách khuyến mãi khỏi kho (chuyển sang module Kho).	v0.4
2026-06-04	Claude (AI pair)	Tổ chức lại theo tính năng (Feature Spine); mỗi tính năng mang yêu cầu + tiêu chí chấp nhận riêng.	v0.5
2026-06-15	Phát Nguyễn	Thêm tính năng BND Combo & Gói bán kèm (URD-BND-001..016) kèm tiêu chí chấp nhận; liên kết PRD-BND-001.	v0.6
2026-06-15	Phát Nguyễn	Thêm tính năng SCH Kênh bán hàng (tổ chức thực đơn & hiển thị theo kênh) (URD-SCH-001..013) kèm tiêu chí chấp nhận; liên kết PRD-SCH-001.	v0.7
2026-07-08	P. Nguyen	Chuẩn hóa hình thức (cột ưu tiên chữ đầy đủ, backtick, bỏ em-dash); thêm ENTITLEMENT (loại biến thể thứ 7); thêm loại phân biệt nhóm hàng (Product/Material); bỏ cờ add-on nhóm hàng; sửa footnote fare (SALE/OVERRIDE); làm rõ archived có thể khôi phục; làm rõ hành vi biến thể khi sản phẩm lưu trữ (URD-VAR-013); ranh giới định danh catalog (SKU/barcode/QR) vs kho (IMEI/serial).	v0.8
2026-07-09	P. Nguyen	Gộp Category thành nguồn dùng chung ở Products (dồn yêu cầu từ commerce + discriminationType); khu CAT commerce trỏ về đây.	v0.9
2026-07-09	P. Nguyen	Gộp engine fare về module Định giá; khu FAR products chỉ còn UI sửa giá + trỏ.	v1.0
2026-07-15	Claude (AI pair)	Chuyển sang chuẩn trình bày Kho: <DocTabs> 3 tab (overview/details/history), yêu cầu ra bảng 4 cột với Badge trạng thái, gộp "Phạm vi" + "Không-mục-tiêu" thành một mục Loại trừ duy nhất. Chỉ đổi hình thức - không đổi mã, không đổi quyết định, không thêm/bớt yêu cầu.	v1.1