Nhà hàng còn tám ghế không có nghĩa là nhận được một đoàn tám người. Bốn ghế ở tầng trên, bốn ghế ngoài sân có thể đều trống, nhưng khách muốn ngồi chung và hai khu vực không thể ghép. Website đặt bàn cần trả lời được câu hỏi về một nhóm khách cụ thể, trong một khoảng thời gian cụ thể, trên những bàn thực sự có thể sử dụng cùng nhau.
Bài viết phân tích cách thiết kế website đặt bàn ghép bàn ở mức nghiệp vụ và kiểm thử. Các con số bên dưới là ví dụ giả định để làm rõ quy tắc, không phải dữ liệu vận hành của một nhà hàng hoặc cam kết tính năng của mọi phần mềm.
Đặt cả nhóm khách lên sơ đồ bàn trước khi cộng ghế
Hãy xét một mặt bằng có bàn A bốn chỗ, bàn B bốn chỗ và bàn C sáu chỗ. A nằm cạnh B và được phép ghép; C ở phòng riêng. Đoàn sáu người có thể dùng C hoặc tổ hợp A cộng B nếu hai bàn cùng rảnh trong toàn bộ thời gian phục vụ. Nếu C đã có khách, A rảnh nhưng B bận, hệ thống không được lấy bốn chỗ của A cộng hai ghế trống ở một bàn khác đang phục vụ để xác nhận đoàn sáu người.
Khái niệm cần lưu là sức chứa của một phương án bố trí, không chỉ tổng ghế còn lại. Phương án gồm danh sách bàn, sức chứa thực tế sau ghép, khu vực và các giới hạn phục vụ. Hai bàn bốn chỗ không nhất thiết tạo thành bàn tám chỗ nếu lối đi hoặc cách kê bàn chỉ cho phép sáu khách. Quy tắc này do người vận hành xác nhận; lập trình viên không nên suy ra từ phép cộng.
Trong tài liệu nhà hàng Odoo 19, bàn có thể được mô hình hóa thành tài nguyên đặt chỗ và liên kết để phục vụ nhóm lớn hơn. Đây là ví dụ về cách sản phẩm hỗ trợ quan hệ giữa các bàn. Khi chọn giải pháp khác, vẫn cần kiểm tra riêng khả năng ghép, phiên bản và hành vi đặt đồng thời.
Ba loại dữ liệu thường bị gom vào một con số
Sức chứa mô tả số người phục vụ được. Khả dụng mô tả bàn có rảnh trong khoảng giờ hay không. Điều kiện ghép mô tả những tài nguyên được phép dùng cùng nhau. Khi ba khái niệm nằm chung trong trường “số chỗ còn”, nhân viên rất khó biết hệ thống từ chối vì hết ghế, thiếu thời gian hay không tồn tại cách ghép phù hợp.
Mỗi bàn nên có mã ổn định để việc đổi tên hiển thị không phá lịch đã đặt. Bàn “Cửa sổ 1” có thể đổi thành “Bàn 12”, nhưng các đơn cũ vẫn phải trỏ đến cùng tài nguyên. Với tổ hợp A cộng B, website cũng cần nhớ cả A lẫn B đã được giữ, thay vì chỉ ghi một mã nhóm không liên hệ với từng bàn thành viên.
Quan hệ ghép nên được quản lý như danh sách các tổ hợp đã duyệt. Nếu A ghép được với B và B ghép được với C, không tự động kết luận A, B, C ghép được thành một dãy. Có thể có cột chắn, cửa thoát hiểm hoặc giới hạn số bàn được di chuyển. Một sơ đồ đơn giản nhưng đúng thực tế hữu ích hơn một thuật toán tìm đủ số ghế trong mọi góc phòng.
Khách đặt lúc 19 giờ đang giữ khoảng nào?
Thời điểm đến chỉ là đầu khoảng chiếm dụng. Giả sử một lượt ăn dự kiến hai giờ và cần thêm mười lăm phút thu dọn, bàn được dùng từ 19 giờ đến 21 giờ 15 theo chính sách minh họa. Đặt lượt sau lúc 21 giờ có thể tạo xung đột dù hai bản ghi có giờ bắt đầu khác nhau. Nhà hàng phải xác định rõ thời lượng theo loại dịch vụ, quy mô đoàn hoặc khung giờ.
Đối với bàn ghép, khoảng cần kiểm tra phải áp dụng cho mọi bàn thành viên. Bàn A rảnh đến 21 giờ còn B rảnh đến 22 giờ không tạo được tổ hợp phục vụ đến 21 giờ 15. Có thể đưa ra giờ khác hoặc xin nhân viên xác nhận, nhưng không âm thầm rút ngắn thời lượng của khách để làm lịch trông còn chỗ.
WooCommerce Bookings phân biệt kiểm tra toàn bộ các khối thời gian và chỉ khối bắt đầu, đồng thời có cấu hình khoảng đệm. Điều quan trọng khi nghiệm thu là kiểm tra cấu hình thực tế của website, thay vì mặc định lịch có ô xanh đã kiểm tra cả bữa ăn.
Giữ đồng thời các bàn để tránh bán hai lần
Tình huống khó xuất hiện khi hai khách cùng nhìn thấy A cộng B còn trống. Khách thứ nhất đặt đoàn sáu người, khách thứ hai đặt riêng bàn B. Nếu hệ thống chỉ kiểm tra rồi ghi từng bàn lần lượt, cả hai yêu cầu có thể vượt qua bước đọc và cùng được xác nhận. Việc kiểm tra lại và ghi nhận giữ chỗ phải là một thao tác có bảo vệ xung đột trên các tài nguyên liên quan.
Đây là yêu cầu thiết kế cho đội tích hợp, không phải hướng dẫn khách hàng sửa cơ sở dữ liệu đang chạy. Phương án có thể khác nhau tùy nền tảng, nhưng kết quả cần kiểm chứng giống nhau: chỉ một giao dịch nhận được B trong khoảng trùng; giao dịch còn lại nhận phản hồi rõ và những lựa chọn còn hợp lệ. Không được để cả hai nhận email thành công rồi gọi điện hủy một bên.
Nếu có bước thanh toán hoặc xác nhận qua điện thoại, nhà hàng cần quy định thời hạn giữ tạm. Giữ tạm hết hạn phải trả lại mọi bàn trong tổ hợp. Callback đến muộn hoặc khách bấm gửi lại không được tạo thêm một lượt giữ mới. Mã yêu cầu và lịch sử chuyển trạng thái giúp phân biệt gửi lại cùng đơn với một yêu cầu đặt khác.
Không phải mô hình tài nguyên nào cũng ghép được nhiều bàn
Danh sách tài nguyên trong trang quản trị chưa đủ để kết luận hệ thống phân bổ đồng thời nhiều tài nguyên. Tài liệu Resources in Bookings nêu rằng mặc định mỗi booking chỉ được gán một tài nguyên. Vì vậy, đưa A và B vào danh sách lựa chọn có thể chỉ tạo quan hệ chọn một trong hai, không tạo tổ hợp A cộng B.
Đội triển khai nên yêu cầu bản trình diễn với chính tình huống bàn ghép của nhà hàng. Nếu phần mềm chỉ chọn một tài nguyên, có thể quản lý bằng tài nguyên tổ hợp, lớp điều phối riêng hoặc quy trình yêu cầu xác nhận. Mỗi lựa chọn cần chứng minh không bán chồng bàn thành viên. Tài nguyên tổ hợp độc lập mà không khóa A và B riêng vẫn có thể tạo lỗi.
Đừng hứa “tự động ghép mọi bàn” chỉ vì giao diện có nút kéo bàn trên sơ đồ POS. Thao tác ghép đơn hàng tại quầy và phân bổ bàn cho khách đặt trước giải quyết hai thời điểm khác nhau. Cần chứng minh dữ liệu đi từ website sang lịch phục vụ đúng cách, kể cả khi nhân viên thay bàn sau khi khách đến.
Bộ tình huống nghiệm thu có ý nghĩa cho nhà hàng
Bắt đầu với đoàn vừa đúng sức chứa của một bàn, sau đó là đoàn chỉ vừa khi ghép. Thử cùng đoàn vào giờ mà một bàn thành viên đã bận. Kiểm tra một yêu cầu đi qua giờ đóng cửa hoặc khoảng bàn cần thu dọn. Những ca này kiểm tra ranh giới nghiệp vụ tốt hơn việc chỉ gửi một đơn nhỏ vào buổi sáng trống lịch.
Tiếp theo, gửi hai yêu cầu cùng lúc cho tổ hợp và một bàn thành viên, thử gửi lại cùng mã yêu cầu, rồi hủy đơn giữ tạm. Kết quả phải trả lại đúng tài nguyên, không làm trống nhầm bàn đang thuộc đơn khác. Nếu nhân viên chuyển đoàn sang bàn C, A và B chỉ được trả lại sau khi phương án mới đã được xác nhận thành công.
Cuối cùng, đọc thông báo như một khách đặt bàn. “Không còn bàn phù hợp cho nhóm sáu người lúc 19 giờ” chính xác hơn “nhà hàng hết chỗ” khi vẫn nhận được hai nhóm nhỏ. Website nên đề xuất giờ hoặc khu vực thực sự có thể phục vụ, đồng thời cho phép gửi nhu cầu cần nhân viên xem xét. Yêu cầu đang chờ không được trình bày như lịch đã chắc chắn.
Chốt quy tắc trước khi chọn giao diện đặt bàn
Nhà hàng có thể chuẩn bị một sơ đồ đánh dấu bàn, danh sách tổ hợp được ghép, thời lượng phục vụ, khoảng đệm và người có quyền đổi phương án. Chỉ cần một ca đông khách giả định cũng đủ lộ ra nhiều câu hỏi chưa được thống nhất. Tài liệu này trở thành đầu vào nghiệm thu, giúp tránh tranh luận sau khi website đã có đơn thật.
Nếu cần kết nối giao diện đặt bàn với hệ thống vận hành, bạn có thể tham khảo dịch vụ thiết kế website của Onter và mô tả quy tắc ghép đang dùng. Giá: Liên hệ. Nhận tư vấn & báo giá theo phạm vi đã đối chiếu, đặc biệt với yêu cầu giữ nhiều bàn cùng lúc.
