Khách đặt phòng có thể trả trước qua website, đổi ngày lưu trú rồi thanh toán thêm tại quầy. Booking từ OTA lại có thể do khách trả tại khách sạn hoặc kênh thu hộ và chuyển trả sau. Nếu hệ thống chỉ đánh dấu một ô “đã thanh toán”, lễ tân khó biết còn phải thu ai và khoản nào đang chờ quyết toán.
Tự động hóa đối soát cho mô hình kinh doanh booking khách sạn cần nối đặt phòng, nghĩa vụ thanh toán và giao dịch theo từng giai đoạn. Bài viết trên hoadontudong.com.vn tập trung vào tiền trả trước, thanh toán cuối, OTA, đổi ngày và hoàn, để tiền đã nhận không bị cộng hai lần hoặc mất dấu khi lịch ở thay đổi.
Đặt phòng và thanh toán có hai vòng đời liên quan
Reservation quản lý ngày ở, phòng hoặc loại phòng, khách và trạng thái phục vụ. Hồ sơ thanh toán quản lý số phải thu, người chịu nghĩa vụ, khoản đã nhận và phần còn lại. Đã thu tiền không tự chứng minh phòng đã được giữ đúng; phòng được xác nhận cũng chưa luôn nghĩa đã thu đủ.
Giữ mã booking nội bộ ổn định cùng mã của website, PMS và kênh bán. Khách đặt nhiều phòng hoặc người khác trả hộ cần quan hệ riêng; tên khách không nên là khóa duy nhất để ghép ngân hàng. Khi booking được sửa, giữ phiên bản và lịch sử thay đổi.
Thống nhất hệ thống nào quyết định tồn phòng và hệ thống nào quyết định khoản thu. Adapter thanh toán có thể gửi kết quả, nhưng không nên tự sửa lịch ở hoặc chọn phòng khi PMS đang có trạng thái mâu thuẫn. Các quyết định phục vụ cần đi qua quy trình đặt phòng.
Tách các giai đoạn phải thu và các loại tiền
Một booking có thể có khoản trả trước, phần còn lại khi nhận/trả phòng và dịch vụ phát sinh. Giữ mỗi nghĩa vụ với thời hạn cùng số tiền. Khoản khách gửi để bảo đảm tài sản hoặc mục đích khác cần loại riêng theo chính sách, không cộng tùy tiện vào tiền phòng đã thu.
Tên “cọc” trong giao diện không tự quyết định bản chất kế toán hoặc thời điểm hóa đơn. Bộ phận chuyên môn cần xác định theo thỏa thuận và quy định áp dụng. Phần mềm giữ loại khoản, mục đích và quyết định được duyệt để không suy từ một giao dịch ngân hàng.
Đối với mỗi yêu cầu thanh toán, lưu booking, giai đoạn, số phải thu và định danh đơn. Với Pay2S, có thể dùng luồng được hỗ trợ trong Collection Link theo đơn. Một link không nên bị tái sử dụng cho mọi thay đổi của booking mà mất giá trị ban đầu.
OTA cần theo dõi ai đã thu và ai còn phải trả
Đầu tiên, xác định mô hình theo hợp đồng/kênh của booking: khách trả tại nơi lưu trú hay kênh đã thu và còn nghĩa vụ chuyển trả. Hai luồng dẫn đến đối tượng phải thu khác nhau. Không yêu cầu lễ tân thu khách lần nữa chỉ vì ngân hàng chưa có khoản OTA quyết toán.
Nếu nhận theo lô, giữ bảng kê, các dòng booking, phí và điều chỉnh được thể hiện. Giao dịch ngân hàng nối với lô, rồi lô nối từng booking. Tổng tiền chuyển trả không luôn bằng tổng giá trị đặt phòng; cần dữ liệu giải thích chênh lệch thay vì sửa giá phòng.
Khi kênh hỗ trợ phương thức trả khác, xác nhận nguồn chứng cứ và quy trình đối soát tương ứng. Không giả định mọi OTA cùng lịch thanh toán, phí hay quy tắc hủy. Adapter nên giữ loại mô hình để báo cáo không trộn tiền khách còn phải trả với tiền đối tác còn phải chuyển.
Phân bổ khoản nhận mà không cộng lặp công nợ
Booking và các khoản phải thu giữ quan hệ với payment bằng bảng phân bổ. Một khách trả gộp nhiều phòng hoặc nhiều giai đoạn cần thể hiện từng phần. Tổng phân bổ không được vượt khoản nhận, và một khoản đã dùng không được đem gạch thêm một booking khác khi xử lý lại.
Giữ tiền gốc, tiền đã phân bổ và số còn chưa rõ. Đừng vừa ghi khoản trả trước vào booking vừa cộng nó lần nữa khi tổng hợp thanh toán cuối. Màn hình lễ tân cần thấy tổng nghĩa vụ, số đã nhận và phần còn phải thu trên cùng một căn cứ.
Webhook hoặc IPN đến lại không tạo thêm tiền nhận. Bài chống xử lý thanh toán trùng hỗ trợ lớp dữ liệu. Hai khoản tiền thật cho cùng yêu cầu vẫn phải giữ để xử lý thu thừa; không loại một khoản chỉ vì booking đã đủ tiền.
Tình huống giả định: trả trước rồi thanh toán cuối
Một booking giả định có tổng tiền phòng 1.200.000 đồng, khách trả trước 500.000 đồng và còn 700.000 đồng. Khi khoản đầu đã được xác minh, hồ sơ giữ cả giao dịch cùng phân bổ vào giai đoạn trả trước. Lễ tân nhìn phần còn phải thu mà không tính lại từ ảnh chuyển khoản.
| Thông tin | Giá trị giả định |
|---|---|
| Nghĩa vụ tiền phòng | 1.200.000 đồng |
| Khoản đã nhận và phân bổ | 500.000 đồng |
| Phần còn phải thu | 700.000 đồng |
Nếu khách trả thêm 700.000 đồng, tổng đã nhận thành đủ. Nếu đồng bộ thông báo đầu lần nữa, nó vẫn là cùng khoản 500.000 đồng, không làm booking thành thu 1.700.000 đồng. Nếu có dịch vụ mới, tạo nghĩa vụ bổ sung theo quy trình thay vì sửa khoản ngân hàng đã nhận.
Khi đổi ngày làm giá trị booking thay đổi, giữ quyết định điều chỉnh rồi tính phần còn lại theo dữ liệu mới. Ví dụ chỉ minh họa logic; không trình bày các con số như kết quả triển khai hoặc chính sách của một khách sạn.
Đổi ngày và đổi phòng cần phiên bản số phải thu
PMS có thể thay ngày, số đêm, loại phòng và chính sách áp dụng. Mỗi thay đổi ảnh hưởng số phải thu cần có phiên bản, người duyệt và thời điểm. Link thanh toán đã tạo theo giá cũ phải được xử lý có chủ đích, không âm thầm đổi số tiền kỳ vọng của callback.
Nếu giá tăng, tạo phần bổ sung hoặc yêu cầu mới theo luồng đã thiết kế. Nếu giảm, xác định phần đã nhận vượt nghĩa vụ và chuyển sang xử lý phù hợp. Đừng tự hoàn hoặc bù sang booking khác chỉ vì cùng người đặt.
Giữ lịch sử giúp chăm sóc khách giải thích số dư sau thay đổi. Một booking chỉ lưu giá cuối sẽ không cho thấy vì sao khách đã trả một khoản khác. Dữ liệu nguồn thanh toán và quyết định điều chỉnh phải cùng còn để đối chiếu.
Tiền đến sau hủy hoặc sau khi phòng đã được giải phóng
Đây là trường hợp cần ngoại lệ riêng. Lưu khoản tiền và booking liên quan, nhưng kiểm tra tồn phòng cùng thỏa thuận trước khi xác nhận lại. Nếu phòng đã bán cho khách khác, callback không nên tự khôi phục booking và cấp cùng phòng.
Với Collection Link, xác minh kết quả theo hợp đồng IPN Pay2S, rồi áp rule nghiệp vụ của booking. Kết quả thanh toán hợp lệ cho biết dữ kiện tiền, không tự quyết định khả năng phục vụ tại thời điểm nhận muộn.
Phân công người liên hệ khách và người duyệt cách xử lý. Giữ trạng thái hàng/phòng, phương thức thay thế nếu khách đã trả lại và mọi khoản thu liên quan. Hồ sơ phải cho thấy vì sao booking chưa được khôi phục dù có tiền.
Hoàn tiền cần kiểm tra kênh nhận và trạng thái thực hiện
Yêu cầu hủy booking, duyệt khoản hoàn và tiền đã trả lại là các mốc khác nhau. Chính sách phụ thuộc thỏa thuận và kênh bán; phần mềm cần giữ phiên bản áp dụng. Không suy một nút Cancel thành kết quả hoàn ở ngân hàng.
Hoàn một phần phải nối tới dòng nghĩa vụ hoặc quyết định điều chỉnh, cùng khoản nhận gốc. Nếu OTA đã thu, xác nhận ai có trách nhiệm thực hiện và nguồn kiểm tra. Nếu merchant hoàn trực tiếp, cần quyền duyệt cùng cách xác minh người nhận.
Response chưa rõ cần được kiểm tra trước khi thực hiện lại. Giữ định danh yêu cầu và kết quả để hai ca lễ tân không cùng hoàn một khoản. Màn hình nên phân biệt chờ duyệt, đang xử lý và đã xác nhận hoàn theo nguồn phù hợp.
Khách quốc tế và dữ liệu hóa đơn cần hai lớp kiểm tra riêng
Nếu phục vụ du khách, xác nhận ứng dụng, ngân hàng và cấu hình QR quốc tế được merchant hỗ trợ. NAPAS công bố mở rộng mạng xuyên biên giới, nhưng phạm vi mạng không đồng nghĩa mọi ví được quét ở mọi khách sạn. Có thể tìm hiểu OneQR nội địa và quốc tế cho lớp nhận tiền.
Giữ số tiền giao dịch, đơn vị tiền, khoản thực nhận và dữ liệu quy đổi/quyết toán theo nguồn. Khi cần báo cáo, quy tắc quy đổi phải được bộ phận tài chính thống nhất. Không cộng các đồng tiền khác nhau vào một tổng nguyên tệ.
Metadata hóa đơn cần phản ánh hồ sơ người mua cùng dịch vụ đã chốt. Collection Link V2 cung cấp lớp gửi dữ liệu theo cấu hình; trạng thái thanh toán, booking và chứng từ vẫn phải riêng để xử lý lỗi đúng bước.
Chốt ngày theo booking và theo nguồn tiền
Lễ tân kiểm tra booking đến/đi, khoản còn phải thu và ngoại lệ. Người đối soát kiểm tra giao dịch, lô OTA và phân bổ. Giữ ngày ở, ngày giao dịch và thời điểm đồng bộ riêng; khoản nhập bù không tự trở thành thu phát sinh của ngày nhập.
Thử toàn bộ vòng đời gồm trả trước, trả thiếu, đổi ngày, hủy, callback muộn và hoàn một phần. Kiểm tra người dùng theo vai trò và khả năng lần về chứng cứ. Một hồ sơ tốt cho biết khách còn phải trả gì, đối tác còn nợ gì và khoản tiền nào đang chờ xử lý, ngay cả khi booking đã thay đổi nhiều lần.
Nguồn kỹ thuật: Pay2S Collection Link; Pay2S IPN; Collection Link V2; NAPAS QR xuyên biên giới cho bán lẻ và du lịch. Mô hình booking và ví dụ là đề xuất thiết kế, không phải case khách hàng.
