PRD: Bố trí bàn & sơ đồ sàn

Module	Thương mại	PRD ID	PRD-FLR-001
Trạng thái	Sẵn sàng dev	FEAT	FLR
Epic	—	Plane	BANA-1532
Ngày	2026-06-15	Phiên bản	v1.0
Gói	@nx/commerce · @nx/sale · @nx/core	URD	FLR
Surface	Client · Chủ/QLSale · POS
Phụ trách	Phát Nguyễn

Bố trí bàn & sơ đồ sàn là gì

Một merchant phục vụ tại bàn mô hình hóa mặt bằng của mình thành một sơ đồ sàn (Layout) có tên, chứa một cây khu (Zone) lồng nhau tối đa hai cấp; mỗi khu lá sở hữu các bàn (Unit) mang sức chứa, vị trí trên canvas và kiểu dáng riêng. Chủ hoặc quản lý dựng cây này tại trang Client. Khi phục vụ mở một đơn dine-in trên Sale POS, hệ thống ghi một bản ghi chiếm dụng (Usage) gắn đơn đó với một hay nhiều bàn - bản ghi này điều khiển màu từng ô trên sơ đồ tầng và là nguồn sự thật cho khả dụng, chuyển bàn, tách và gộp. Mỗi đơn còn giữ một bản chụp (snapshot) của bàn và khách, nên phân bổ không mất dù bản ghi chiếm dụng có thay đổi sau đó.

Vì sao tách thiết kế khỏi chiếm dụng

Sau chữ "bàn" thực ra là hai công việc khác hẳn nhau. Một là thiết kế - bố trí không gian vật lý, làm tại trang Client, ít khi làm, do chủ hoặc quản lý phụ trách. Hai là chiếm dụng - đơn đang chạy đang nằm ở bàn nào, ngay lúc này, diễn ra trên Sale POS, tần suất cao, thời gian thực, do phục vụ hoặc thu ngân thao tác. Gộp cả hai vào một chỗ có thể sửa sẽ khiến sơ đồ tầng bị xáo trộn mỗi lần xếp khách; còn quản lý chiếm dụng mà thiếu một sơ đồ ổn định thì đơn hàng lại trỏ vào chỗ trống.

Thiếu bản đồ này, phục vụ không nhìn ra ngay bàn nào còn trống, bếp không có điểm neo cho đơn dine-in, còn "chuyển bàn 4 ra sân vườn" chỉ là lời dặn miệng, chẳng được ghi lại ở đâu.

Một ca phục vụ, từ thiết kế tới trả bàn

Chủ quán thiết kế "Tầng Trệt" tại trang Client thành một layout gồm hai phòng, mỗi phòng vài bàn, chỉ trong một lần lưu. Trong ca, phục vụ trên Sale POS mở đơn dine-in trên Bàn 7; ô bàn chuyển bận trên mọi máy. Một nhóm sáu khách vãng lai đến - phục vụ lọc bàn trống chứa được sáu người, xếp họ vào, rồi sau đó chuyển họ từ phòng chính ra sân vườn chỉ bằng một thao tác. Khi mỗi nhóm rời đi, hoàn thành usage của đơn sẽ trả bàn về xanh.

Chỗ dễ sai nhất

Sơ đồ sàn và chiếm dụng bàn không phải một thứ

Hai thứ này thay đổi với tần suất hoàn toàn khác nhau. Bản đồ là một chỉnh sửa hiếm hoi tại trang Client; chiếm dụng thì xáo trộn mỗi lần xếp khách trên Sale POS. Tách riêng nghĩa là sơ đồ sống không bao giờ ghi đè bản đồ, và đơn hàng luôn trỏ vào một bàn ổn định.

1. Mục tiêu & Loại trừ

Mục tiêu

• Cung cấp một màn thiết kế sơ đồ tầng tại trang Client (kéo-thả khu, bàn, đặt sức chứa, vị trí và kiểu dáng) cho chủ hoặc quản lý.
• Mô hình hóa sàn vật lý của merchant thành một cây layout → zone → unit có tên, với mỗi unit mang sức chứa, vị trí canvas và kiểu dáng.
• Lưu cả cây trong một lần lưu nguyên tử (tạo, sửa, xóa cùng lúc), kèm giới hạn độ sâu và giới hạn số lượng theo tầng/phòng/bàn/ghế, và kiểm tra mỗi zone đều thuộc đúng layout của nó.
• Chiếm dụng unit khi mở đơn dine-in trên Sale POS; hiển thị một sơ đồ tầng trực tiếp báo từng unit trống hay bận.
• Tìm bàn trống - các unit khả dụng trong một zone, và các zone con mà mọi bàn đều trống.
• Chuyển khách giữa các zone, và giữ phân bổ chính xác khi đơn bị tách hoặc gộp.
• Phát một cập nhật sàn thời gian thực mỗi khi chiếm dụng thay đổi; giữ một snapshot phân bổ trên đơn hàng.

Loại trừ

• Đặt chỗ (Reservation) - được đặc tả ở một PRD riêng, không thuộc phạm vi PRD này.
• Giá hay phí dịch vụ theo zone/bàn - giá nằm ở phần định giá; phân bổ không mang tiền.
• KDS / điều phối bếp và bản thân vòng đời đơn hàng (Sale) - phân bổ chỉ tham chiếu đơn, không sở hữu đơn.

2. Thước đo thành công

Thước đo	Mục tiêu / tín hiệu
Toàn vẹn sàn	Một bước con lỗi giữa chừng không để lại cây dựng dở - layout, zone và unit cùng được lưu hoặc cùng không lưu
An toàn độ sâu & số lượng	Không lần lưu nào ghi được cây zone sâu quá hai cấp, một zone không thuộc layout của nó, hay vượt trần tầng/phòng/bàn/ghế đã định
Sự thật chiếm dụng	Một unit báo bận đúng khi có usage reserved/active/success, và báo trống trong các trường hợp còn lại
Chính xác khả dụng	"Bàn trống" chỉ trả về unit không có usage trực tiếp; một zone chỉ được đề xuất khi mọi bàn của nó đều trống
Đồng bộ trực tiếp	Mọi lần chiếm / trả / chuyển bàn phản ánh lên mọi máy Sale POS mà không cần làm mới thủ công

3. Persona & Tình huống

Persona	Mục tiêu trong tính năng này
Chủ / Quản lý	Tại trang Client, bố trí sàn một lần - khu, bàn, ghế, vị trí - và sửa khi không gian thay đổi
Phục vụ / Thu ngân	Trên Sale POS, xem bàn nào trống, xếp khách, chuyển nhóm, và trả bàn khi khách rời
Lễ tân	Trên Sale POS, liếc một cái đọc được sàn trực tiếp và chọn bàn trống đúng kích cỡ

Kịch bản chính: chủ quán thiết kế "Tầng Trệt" tại trang Client thành một layout gồm hai phòng, mỗi phòng vài bàn, chỉ trong một lần lưu. Trong ca, phục vụ trên Sale POS mở đơn dine-in trên Bàn 7; ô bàn chuyển bận trên mọi máy. Một nhóm sáu khách vãng lai đến - phục vụ lọc bàn trống chứa được sáu người, xếp họ vào, rồi sau đó chuyển họ từ phòng chính ra sân vườn chỉ bằng một thao tác. Khi mỗi nhóm rời đi, hoàn thành usage của đơn sẽ trả bàn về xanh.

4. User Stories

#	Là một	Tôi muốn	Để
01	chủ quán	tại trang Client, thiết kế sàn thành khu và bàn trong một lần lưu	bản đồ hoàn chỉnh và nhất quán ngay khi vừa tồn tại
02	chủ quán	tại trang Client, sửa layout - thêm phòng, bỏ bàn, đặt lại vị trí ghế - trong một lần lưu	không phải dựng lại từ đầu
03	phục vụ	trên Sale POS, xem bàn trống và bận theo thời gian thực	không bao giờ xếp khách vào bàn đang có người
04	phục vụ	trên Sale POS, mở đơn trên một bàn và nó lập tức báo bận với mọi người	sàn không bao giờ bị bán trùng
05	phục vụ	trên Sale POS, chuyển một nhóm đang ngồi sang khu khác chỉ bằng một thao tác	bàn cũ trống ra còn bàn mới đầy lên
06	phục vụ	trên Sale POS, trả một bàn khi khách rời và nó trống trở lại	xếp được nhóm tiếp theo

5. Yêu cầu chức năng

#	Yêu cầu	Trạng thái	URD ref
FR-001	Một merchant mô hình hóa sàn thành một layout có tên chứa một cây zone. Zone lá sở hữu unit có sức chứa, vị trí và kiểu dáng.	✅	URD-FLR-001..003
FR-002	Một layout được tạo cùng cả cây zone lồng nhau trong một lần lưu nguyên tử.	✅	URD-FLR-004
FR-003	Một lần lưu layout áp dụng quy tắc theo id cho từng mục trong cây. • Gửi kèm chỉ id thì xóa (cascade cả nhánh con). • Gửi kèm id và chi tiết thì cập nhật. • Không gửi id thì tạo mới.	✅	URD-FLR-005
FR-004	Một zone tự nó cũng tạo/cập nhật được trong một lần lưu với zone con và unit lồng nhau. Zone có thể tạo theo lô.	✅	URD-FLR-006
FR-005	Độ sâu bị giới hạn ở hai cấp dưới gốc layout. Cây sâu hơn, hoặc một zone không thuộc layout của nó, bị từ chối trước khi lưu.	✅	URD-FLR-007
FR-006	Một lần lưu sơ đồ bị giới hạn số lượng: tối đa 100 tầng mỗi layout, 50 phòng mỗi tầng, 50 bàn mỗi phòng, 50 bàn mỗi khu. • Mỗi bàn khai sức chứa tối đa 50 ghế. • Vượt bất kỳ mức nào cũng bị từ chối kèm thông báo rõ.	🔶	URD-FLR-022 · URD-FLR-023
FR-007	Một layout đọc được với độ sâu tối đa cấu hình được - cây đầy đủ cho trang Client, cây nông cho Sale POS.	✅	URD-FLR-008
FR-008	Layout, zone và unit mang trạng thái vòng đời (Activated / Deactivated / Archived) và được xóa có thể khôi phục. Mỗi cái cũng quản lý độc lập được.	✅	URD-FLR-009..010
FR-009	Mở đơn dine-in trên một hay nhiều unit tạo một usage chiếm dụng, đánh dấu các unit đó bận.	✅	URD-FLR-011
FR-010	Một usage mang khung thời gian đặt chỗ; nếu không cho thời điểm kết thúc, áp dụng khung mặc định 90 phút.	✅	URD-FLR-012
FR-011	Chiếm dụng đi theo reserved/active → success → completed (giải phóng) hoặc cancelled. Một usage đã hoàn tất hoặc bị hủy sẽ lặng lẽ bỏ qua lệnh hoàn tất/hủy thêm - không đổi trạng thái, không báo lỗi.	✅	URD-FLR-013
FR-012	Một unit bận khi đang giữ usage reserved/active/success, trống trong các trường hợp còn lại. Sale POS truy vấn được unit trống và zone con hoàn toàn trống.	✅	URD-FLR-014..015
FR-013	Một nhóm có thể được chuyển giữa các zone - hủy usage nguồn, chiếm dụng unit của zone đích cho từng đơn, theo cách nguyên tử.	✅	URD-FLR-016
FR-014	Tách một đơn sẽ nhân bản các usage đang hoạt động sang từng đơn mới. Gộp sẽ chuyển chúng về đơn còn sống.	✅	URD-FLR-017
FR-015	Mỗi thay đổi chiếm dụng phát một cập nhật sàn thời gian thực tới mọi máy Sale POS.	✅	URD-FLR-018
FR-016	Một usage có thể ghi thông tin khách. Đơn giữ một snapshot phân bổ (unit, đường dẫn zone của nó, và thông tin khách).	✅	URD-FLR-019..020
FR-017	Mọi thao tác phân bổ chỉ gói trong merchant của chính người dùng và được gác bởi quyền phân bổ.	✅	URD-FLR-021

5.1 Tiêu chí nghiệm thu

• Lưu một layout mới kèm cây zone và unit lồng nhau trong một lần gửi → layout, zone và unit đều được tạo cùng lúc.
• Trong cùng một lần lưu, gửi một zone chỉ kèm id (không kèm chi tiết) → zone đó và toàn bộ nhánh con bị xóa.
• Gửi một zone kèm cả id và chi tiết → zone được cập nhật theo chi tiết mới; gửi một zone không kèm id → một zone mới được tạo.
• Một bước con lỗi giữa lần lưu (ví dụ một unit sai dữ liệu) → toàn bộ lần lưu rollback, không zone hay unit nào được tạo dở dang.
• Lưu một cây zone sâu quá hai cấp dưới gốc layout → bị từ chối trước khi lưu bất cứ thứ gì.
• Lưu một zone tham chiếu sai layout (không phải layout gốc của nó) → bị từ chối vì không thuộc layout.
• Thêm bàn thứ 51 vào một phòng rồi lưu → bị từ chối với thông báo rõ.
• Khai một bàn 60 ghế rồi lưu → bị từ chối.
• Đọc một layout tại trang Client → nhận về cây đầy đủ; đọc cùng layout đó từ Sale POS → nhận về cây nông theo độ sâu cấu hình cho điểm bán.
• Xóa một layout, zone hoặc unit → chuyển trạng thái Archived, khôi phục lại được, không mất dữ liệu.
• Mở một đơn dine-in trên Bàn 7 đang trống → unit chuyển bận trên mọi máy Sale POS, một usage được ghi kèm khung đặt chỗ (mặc định 90 phút nếu không khai thời điểm kết thúc).
• Hoàn thành một bàn đang có đơn đã trả (success) → usage chuyển completed, unit trống trở lại.
• Trả bàn lần thứ hai cho một lượt đã đóng → không có gì thay đổi, không báo lỗi, các bàn khác trong loạt vẫn được xử lý bình thường.
• Truy vấn bàn trống trong một zone đang có vài bàn bận → chỉ nhận về các unit không có usage reserved/active/success.
• Truy vấn zone con khả dụng của một zone cha → chỉ nhận về các zone con mà mọi bàn đều trống.
• Chuyển một nhóm đang ngồi ở phòng chính sang zone sân vườn → usage nguồn bị hủy, unit của sân vườn được chiếm cho từng đơn liên quan, cả hai đổi màu ngay trên mọi máy.
• Thử chuyển một nhóm khi zone nguồn không có usage hoạt động, hoặc zone đích không có unit → bị từ chối với lý do rõ ràng, không gì thay đổi.
• Tách một đơn đang có usage hoạt động → mỗi đơn mới nhận một bản sao usage của riêng mình; gộp hai đơn đang có usage hoạt động → toàn bộ usage chuyển về đơn còn sống.
• Mở, chuyển hoặc trả một bàn → mọi máy Sale POS khác nhận cập nhật màu ô ngay, không cần làm mới thủ công.
• Mở một đơn có ghi tên khách, số điện thoại và số khách trên một bàn → thông tin khách được lưu cùng usage.
• Tra lại một đơn sau khi usage của nó đã thay đổi → đơn vẫn giữ đúng bàn và đường dẫn zone qua snapshot phân bổ trên chính đơn đó.
• Một nhân viên không có quyền phân bổ, hoặc đang ở merchant khác, thử mở/chuyển/trả bàn → bị từ chối; chỉ thấy được sơ đồ và bàn của merchant mình.

6. Yêu cầu phi chức năng

Khía cạnh	Yêu cầu
Atomicity	Mô hình sàn (layout + zone + unit) và mỗi thao tác chiếm dụng (start, transfer, split, merge) đều là tất-cả-hoặc-không
Depth & quantity safety	Một kiểm tra chặn cây zone sâu quá hai cấp, chặn zone không thuộc layout của nó, và chặn vượt trần tầng/phòng/bàn/ghế - tất cả trước khi lưu bất cứ thứ gì
Real-time	Thay đổi chiếm dụng đẩy cập nhật thời gian thực để mọi máy Sale POS phản ánh sàn mà không cần làm mới thủ công
Tenancy & authz	Mọi thao tác gói trong merchant của chính người dùng; thiết kế sàn tại trang Client gác bởi quyền layout/zone/unit, chiếm dụng trên Sale POS gác bởi quyền usage
Performance	Truy vấn khả dụng giải hết unit của một zone trong một lượt; đọc sàn giới hạn độ sâu nên Sale POS chỉ lấy đúng phần cần hiển thị
Durability	Mỗi đơn giữ một snapshot phân bổ (unit, đường dẫn zone của nó, và thông tin khách) để phân bổ tồn tại trên đơn, độc lập với các bản ghi usage trực tiếp
i18n	Tên layout, zone và unit song ngữ (Anh / Việt)

7. UX & Luồng

Thiết kế sơ đồ tại trang Client

Chủ hoặc quản lý mở màn thiết kế sơ đồ trên trang Client, kéo-thả để dựng tầng, phòng, bàn thành một cây tối đa hai cấp, đặt sức chứa, vị trí trên canvas và kiểu dáng cho từng bàn, rồi lưu cả cây trong một lần bấm. Mọi thao tác tạo, sửa, xóa sơ đồ nằm trong màn này - Sale POS không có nút tạo hay sửa sơ đồ.

Vòng đời chiếm dụng

Completed và Cancelled là hai trạng thái cuối. Một lệnh hoàn tất hoặc hủy gửi thêm vào một usage đã ở trạng thái cuối bị bỏ qua lặng lẽ - không đổi trạng thái, không báo lỗi. Nhờ vậy, thao tác trả hàng loạt bàn cuối ngày không bị kẹt chỉ vì một bàn đã đóng từ trước.

Xếp khách, xem trực tiếp, chuyển bàn trên Sale POS

Mô hình sàn hiện ở trang Client dưới dạng màn thiết kế sơ đồ (khu, bàn, sức chứa, vị trí) cho chủ hoặc quản lý, và ở Sale POS dưới dạng sơ đồ tầng trực tiếp - tô màu từng ô theo chiếm dụng, chỉ cho xếp / tìm-trống / chuyển / trả bàn, không cho tạo hay sửa sơ đồ.

8. Dữ liệu & Miền nghiệp vụ

Thực thể	Vai trò
Sơ đồ sàn (Layout)	Bản đồ sàn có tên của một merchant; gốc của cây zone; mang style sơ đồ sàn
Zone	Một vùng trong cây (tầng / phòng / nhóm bàn); tự lồng tối đa hai cấp dưới layout
Unit (bàn)	Một đơn vị có thể ngồi (bàn); mang sức chứa, vị trí trên sơ đồ sàn và style; thuộc một zone lá
Bản ghi chiếm dụng (Usage)	Một chiếm dụng trực tiếp gắn một unit với một đơn hàng, kèm khung đặt chỗ và một trạng thái điều khiển màu sàn
Đặt chỗ (Reservation)	Đặc tả ở một PRD riêng - không thuộc phạm vi tài liệu này

Chỉ mang tính khái niệm. Quan hệ là tham chiếu mềm; toàn vẹn do quy tắc phân bổ thực thi, không phải do ràng buộc lưu trữ.

9. Phụ thuộc & Giả định

Phụ thuộc vào

#	Feature	Phụ thuộc điều gì
01	Merchant (MER, PRD-ORG-001)	mọi layout, zone, unit và usage đều scope theo một merchant.
02	Đơn hàng (Sale)	một usage chiếm unit thay cho một đơn dine-in; tách / gộp / thanh toán điều khiển vòng đời của nó.
03	Nền tảng dùng chung	các model phân bổ, trạng thái, và kênh cập nhật trực tiếp.

Giả định

#	Giả định	Sai thì sao
01	Loại hình kinh doanh của merchant là phục vụ tại bàn (F&B); merchant counter / bán lẻ không cần mô hình sàn.	Một merchant không phục vụ tại bàn nhưng vẫn cần bố trí chỗ ngồi (ví dụ quầy tự chọn có khu ngồi) không được cấp mô hình sàn, và phải quản lý bố trí đó ngoài hệ thống.
02	Trên thực tế độ sâu zone nhiều nhất là tầng → phòng → bàn; giới hạn hai cấp phản ánh đúng điều đó.	Merchant có mặt bằng cần nhiều hơn ba cấp không mô hình hóa đúng cấu trúc thật, phải gộp cấp hoặc đặt tên bù, và sơ đồ không còn khớp mặt bằng thật.

10. Kế hoạch phát hành & Tiêu chí

Khía cạnh	Kế hoạch
Phase	P2 - FLR trong URD feature catalog
Rollout	Merchant F&B / dine-in; không có công tắc triển khai
Data setup	Không - bản ghi phân bổ mới; merchant hiện hữu nhận một mô hình sàn rỗng
Launch criteria	Một layout cùng cây zone và unit lưu nguyên tử; kiểm tra độ sâu, thuộc-layout và giới hạn số lượng (tầng/phòng/bàn/ghế) giữ vững; mở đơn dine-in chiếm unit và chuyển chúng bận trực tiếp; truy vấn bàn trống loại trừ unit đang bận; chuyển bàn di chuyển một nhóm theo cách nguyên tử; trả bàn giải phóng unit và lệnh hoàn tất/hủy lặp lại trên một usage đã đóng bị bỏ qua lặng lẽ; mỗi đơn giữ snapshot phân bổ
Monitoring	Tỷ lệ lưu lỗi theo lý do (quá sâu, sai layout, vượt giới hạn số lượng hoặc sức chứa), độ trễ cập nhật chiếm dụng tới các máy Sale POS, thời gian phản hồi tra cứu bàn trống

Tham chiếu

• URD: Commerce - FLR
• PRD liên quan: Organizer & merchant · Mẫu biên lai · Loại hình bán lẻ
• Module: Commerce - URD
• Module liên quan: Sale - đơn hàng chiếm dụng unit
• Developer: @nx/commerce · @nx/sale · @nx/core

Rủi ro & Câu hỏi mở

#	Rủi ro / câu hỏi	Giảm thiểu / trạng thái
01	Một sàn dựng dở khi lưu lỗi (có zone nhưng thiếu unit)	Cả cây là một lần lưu tất-cả-hoặc-không - bất kỳ lỗi nào cũng rollback hoàn toàn
02	Một cây zone phình loạn hoặc lặp vòng	Độ sâu giới hạn hai cấp và zone không thuộc layout của nó bị từ chối trước khi lưu
03	Một tầng, phòng hoặc bàn vượt trần số lượng, hoặc một bàn khai sức chứa quá lớn	Kiểm tra giới hạn số lượng và sức chứa chặn lần lưu trước khi ghi bất cứ thứ gì
04	Hai nhóm cùng xếp vào một bàn (bán trùng)	Một unit bận khi còn bất kỳ usage reserved/active/success nào; truy vấn khả dụng loại trừ unit đang bận
05	Sơ đồ sàn lệch nhau giữa các máy	Mỗi thay đổi chiếm dụng phát một cập nhật trực tiếp mà mọi máy Sale POS đều nhận
06	Mất phân bổ nếu các bản ghi usage thay đổi	Mỗi đơn giữ một snapshot phân bổ (unit, đường dẫn zone của nó, và thông tin khách) trên bản ghi của riêng nó
07	Bàn hết khung giờ không bao giờ được trả	Một khung đặt chỗ mặc định 90 phút được ghi lại; hoàn thành giải phóng bàn một cách tường minh

Câu hỏi thường gặp

#	Câu hỏi	Trả lời
01	Vì sao bản đồ sàn và chiếm bàn lại tách riêng?	Vì chúng thay đổi với tần suất hoàn toàn khác nhau. Bản đồ là một chỉnh sửa hiếm hoi tại trang Client; chiếm dụng thì xáo trộn mỗi lần xếp khách trên Sale POS. Tách riêng nghĩa là sơ đồ sống không bao giờ ghi đè bản đồ, và đơn hàng luôn trỏ vào một unit ổn định.
02	Sàn của tôi được sâu và rộng tới đâu?	Hai cấp dưới gốc layout - thực tế là tầng → phòng → bàn - và có trần số lượng: tối đa 100 tầng mỗi layout, 50 phòng mỗi tầng, 50 bàn mỗi phòng, 50 bàn mỗi khu, mỗi bàn tối đa 50 ghế. Một lần lưu vượt bất kỳ mức nào, hoặc trỏ một zone vào sai layout, sẽ bị từ chối trước khi lưu bất cứ thứ gì.
03	Khi nào một bàn báo bận?	Khi nó giữ một usage đang reserved, active, hoặc đã trả (success). Khi usage đó hoàn tất hoặc bị hủy, bàn trống trở lại.
04	Nếu tôi trả một bàn đã trả rồi thì sao?	Không có gì xảy ra - một usage đã hoàn tất hoặc hủy sẽ lặng lẽ bỏ qua lệnh hoàn tất/hủy thêm, không báo lỗi, nên thao tác trả hàng loạt bàn cuối ngày không bị kẹt chỉ vì một bàn đã đóng từ trước.
05	Bàn cũ sẽ ra sao khi tôi chuyển một nhóm?	Việc chuyển là nguyên tử: usage nguồn bị hủy và unit của zone đích được chiếm cho từng đơn liên quan, nên bàn cũ trống ra và bàn mới đầy lên cùng lúc.
06	Tôi có mất phân bổ bàn nếu usage trực tiếp thay đổi không?	Không - mỗi đơn giữ một snapshot phân bổ gồm unit và đường dẫn zone của unit (cùng thông tin khách), nên phân bổ tồn tại ngay trên chính đơn hàng.
07	Tôi có tìm được một bàn trống đúng kích cỡ không?	Có - Sale POS truy vấn unit khả dụng trong một zone (và các zone con mà mọi bàn đều trống), bạn lọc thêm theo sức chứa.
08	Ai thiết kế được sơ đồ sàn, ai chỉ xem?	Chủ và quản lý thiết kế sơ đồ tại trang Client. Nhân viên trên Sale POS chỉ xem sơ đồ sống và thao tác xếp / tìm-trống / chuyển / trả bàn - không tạo hay sửa được sơ đồ.