Tour vẫn còn ghế nhưng xe đã đi qua điểm đón đầu tiên. Một khách mới chọn đúng điểm đó trên website, nhận thông báo đặt thành công rồi gọi hỏi vì sao không thấy xe. Lỗi không nằm ở tổng sức chứa; hệ thống đã dùng điều kiện còn ghế để thay cho điều kiện còn khả năng đón tại một nơi và thời điểm cụ thể.
Đặt tour theo điểm đón cần đối chiếu ba yếu tố: chỗ còn lại, điểm đón hợp lệ và hạn nhận cho điểm đó. Bài này đề xuất mô hình điều phối trên website, có tham chiếu cách tài nguyên và sức chứa được mô tả trong Odoo Appointments. Các quy tắc tuyến xe và hạn chốt là thiết kế đề xuất, không phải tính năng tour được mặc định bảo đảm bởi công cụ đặt lịch.
Đặt tour theo điểm đón: còn ghế chưa chắc còn nhận khách
Ghế biểu diễn năng lực chở khách trên chuyến. Điểm đón biểu diễn một vị trí trong phương án vận chuyển. Hạn nhận là mốc mà đội điều hành còn có thể đưa yêu cầu mới vào danh sách một cách phù hợp. Một chuyến có ghế trống vẫn có thể ngừng nhận tại một điểm do thời gian hoặc kế hoạch tuyến.
Vì vậy, danh sách điểm đón không nên chỉ là một trường văn bản đứng cạnh số người. Mỗi lựa chọn cần gắn với chuyến và điều kiện nhận. Nếu chỉ thu địa chỉ rồi xử lý sau, giao diện phải nói đây là đề nghị điểm đón cần xác nhận, chưa phải cam kết xe sẽ tới.
Tài liệu Odoo Appointments mô tả đặt lịch theo người hoặc tài nguyên và các lựa chọn sức chứa. Đây là nền để thảo luận việc dùng năng lực hữu hạn, không thay thế quy hoạch tuyến xe. Khi xây sản phẩm tour, cần thêm những ràng buộc mà công cụ lịch chung không tự hiểu.
Ví dụ giả định chuyến C9 có điểm A và B. A có mốc nhận sớm hơn B vì phương án xuất phát khác nhau. Khi A đã chốt, có thể B vẫn nhận được nếu còn ghế và điều hành cho phép. Một mốc chung duy nhất có thể làm mất cơ hội hợp lệ ở B hoặc nhận quá muộn ở A.

Mô hình chuyến trước, rồi mới mô hình điểm đón
Hãy tạo định danh cho chuyến cụ thể, không chỉ tên tour. Một tour xuất phát hằng tuần có thể dùng xe và danh sách điểm khác nhau theo ngày. Khách chọn tour nhưng hệ thống cần biết họ đang mua chỗ trên chuyến nào trước khi kiểm tra khả năng đón.
Trong chuyến, từng điểm nên có định danh ổn định, mô tả công khai đủ hiểu, khoảng đón nếu có và hạn nhận đã được điều hành chốt. Địa chỉ chi tiết hoặc ghi chú cho tài xế chỉ chia sẻ theo nhu cầu. Không đưa danh sách đầy đủ thông tin liên hệ của cả đoàn vào một file công khai để khách tìm điểm đón.
Ghế và điểm đón cần liên kết trong cùng yêu cầu đặt. Nếu khách đổi từ A sang B, số người có thể không đổi nhưng danh sách vận chuyển đổi. Nếu khách tăng số người, cần kiểm tra lại sức chứa dù điểm đón giữ nguyên. Tách hai thay đổi giúp đội điều hành biết phải đối soát phần nào.
Phần resource capacity trong Appointments là điểm đối chiếu khi kiểm tra năng lực được hiển thị trên website. Cần kiểm tra đúng phiên bản và cấu hình, không chỉ giá trị nhập ở màn hình tài nguyên. Sức chứa trong một ứng dụng lịch không tự tạo ra các quy tắc tuyến xe mà doanh nghiệp chưa thiết kế.
Kiểm tra lại tại thời điểm chốt yêu cầu
Khách có thể mở trang trước hạn và gửi đơn sau hạn. Một điểm đón vẫn hiện trên trang đã tải không có nghĩa còn nhận được. Website cần đối chiếu lại chuyến, số người và điểm ở bước xác nhận, theo nguồn thời gian được hệ thống quy định. Đồng hồ trên máy khách không nên tự quyết định quyền nhận.
Nếu điều kiện thay đổi, phản hồi nên giữ những lựa chọn còn dùng được và chỉ rõ phần cần chọn lại. Ví dụ có thể đề nghị một điểm khác còn nhận, nhưng chỉ khi doanh nghiệp đã xác nhận đó là phương án hợp lệ. Không tự đổi điểm đón của khách rồi gửi email như thể họ đã đồng ý.
Với hai khách tranh số ghế cuối, đọc số còn lại ở màn hình không đủ. Hệ thống cần cơ chế kiểm tra và giữ năng lực đã được chứng minh trong phần mềm thực tế. Nếu chưa có bảo đảm này, luồng phù hợp có thể là tiếp nhận yêu cầu rồi xác nhận thủ công. Đừng công bố đặt chắc chắn khi còn phụ thuộc người điều hành kiểm tra.
Việc đặt chỗ và phân bổ xe cũng có thể tách thành hai giai đoạn. Khách mua chỗ trên chuyến, còn điều hành gán xe sau theo phương án. Nếu vậy, tổng năng lực được chào bán phải dựa trên khả năng có thật, và thay đổi phương án xe cần được đối chiếu với các yêu cầu đã xác nhận. Không bán bằng một xe giả định chưa được bảo đảm.

Sau mốc chốt, thay đổi là yêu cầu điều hành
Một khách đổi điểm đón sau khi danh sách xe đã được gửi không chỉ sửa một dòng hiển thị. Người điều hành cần xem phương án, xác nhận khả năng đáp ứng và bảo đảm thông tin mới tới đúng người phục vụ. Nếu khách tự sửa mà tài xế vẫn dùng danh sách cũ, dữ liệu lưu đúng nhưng dịch vụ vẫn sai.
Có thể khóa thao tác tự đổi sau mốc và mở đường gửi yêu cầu có theo dõi. Đây là lựa chọn chính sách, cần nói rõ trước cho khách. Hệ thống nên phân biệt đã nhận yêu cầu với đã xác nhận thay đổi, tránh biến một thông báo tiếp nhận thành lời hứa đã đổi tuyến.
Phần cấu hình loại lịch hẹn mô tả Pre-Booking Time trong Appointments. Khoảng đặt trước của một loại lịch không mặc nhiên thay thế hạn từng điểm đón trên tuyến. Doanh nghiệp cần xác định cách ánh xạ này và kiểm thử nhánh sau mốc, thay vì coi một trường thời gian chung là đủ cho điều hành tour.
Nhật ký thay đổi nên giữ mã chuyến, yêu cầu, điểm trước sau, thời điểm và người quyết định. Thông tin khách chỉ cho người cần phục vụ, trong thời gian phù hợp. Báo cáo chất lượng có thể dùng mã giả và số thay đổi chưa được xác nhận, không cần xuất số điện thoại của cả đoàn.
Một chuyến thử với ba thời điểm
Thử gửi yêu cầu trước hạn, đúng ranh giới xử lý đã quy định và sau hạn trên một chuyến giả lập. Xác định trước kết quả được mong đợi để tránh tranh luận sau khi hệ thống phản hồi. Không cần phát sinh chuyến hay thanh toán thật để kiểm tra logic nhận điểm đón.
Tiếp theo, mở trang trước hạn nhưng gửi sau hạn, đổi điểm sau khi điều hành chốt và tăng số người khi chỉ còn ít ghế. Kiểm tra cả thông báo khách và danh sách người phục vụ nhận được. Một giao diện hiện thành công nhưng danh sách vận chuyển không cập nhật là chưa đạt yêu cầu.
Thử một yêu cầu có số người được phép trên cấu hình nhưng vượt sức chứa đã duyệt cho chuyến. Hệ thống cần dùng năng lực thật của chuyến, không chỉ giới hạn của trường nhập. Nếu điều hành đổi xe, kiểm tra các yêu cầu đã xác nhận trước khi cho nhận thêm. Không để thao tác đổi tên phương tiện làm tăng khả năng bán mà chưa có bằng chứng về xe thay thế.
Với giờ đón, kiểm tra cách hiển thị múi giờ và ngày trên email lẫn trang xác nhận. Một mốc xử lý đúng ở máy chủ vẫn có thể gây hiểu nhầm nếu khách đọc giờ không cùng ngữ cảnh. Chỉ hiển thị thông tin đã được điều hành chốt và giữ một nơi để khách xem phiên bản hiện hành.
Cuối cùng, chạy lại thao tác gửi để xác nhận không giữ thêm ghế cho cùng một yêu cầu đã được nhận diện. Kiểm tra điểm của chuyến khác không bị khóa theo ngoài ý muốn. Nghiệm thu cần chỉ rõ chuyến, mốc và năng lực được đối chiếu, không chỉ ghi rằng form đặt tour đã gửi được email.
Nếu cần Onter thiết kế luồng đặt tour theo chuyến và điểm đón, hãy Nhận tư vấn & báo giá theo cách điều hành thực tế. Giá liên hệ; chức năng tự xác nhận chỉ nên mở sau khi điều kiện chỗ và điểm đón đã được kiểm chứng.

