Giới thiệu dự án

Ngành du lịch lữ hành tại Việt Nam đang chứng kiến sự phục hồi mạnh mẽ và chuyển dịch số hóa nhanh chóng với tốc độ tăng trưởng thương mại điện tử du lịch đạt 22,5% hàng năm (theo số liệu từ Tổng cục Du lịch Việt Nam). Tuy nhiên, nhiều doanh nghiệp lữ hành quy mô vừa và lớn vẫn vận hành dựa trên các quy trình bán tự động, dữ liệu phân tán giữa các chi nhánh và kênh đại lý (B2B), dẫn đến tình trạng quá tải xử lý đơn hàng trong mùa cao điểm, sai sót dữ liệu đặt chỗ và đối soát công nợ chậm trễ.

Công ty Cổ phần Lữ hành Fiditour (thành lập năm 1989) là đơn vị lữ hành nằm trong nhóm đầu ngành tại Việt Nam với mạng lưới gồm 6 chi nhánh tại TP.HCM, Đà Nẵng, Cần Thơ, Hà Nội và hàng trăm đối tác đại lý phân phối. Khảo sát thực trạng cho thấy doanh nghiệp đang đối mặt với các vấn đề kỹ thuật và vận hành nghiêm trọng:

  • Tỷ lệ trùng lặp thông tin và sai lệch tình trạng giữ chỗ giữa kênh trực tiếp (hotline, quầy giao dịch) và đại lý B2B lên tới 8,4%.
  • Quy trình hủy tour và hoàn tiền kéo dài trung bình từ 3 đến 5 ngày làm việc do phụ thuộc vào thủ tục giấy tờ thủ công (fax, email), gây tắc nghẽn dòng tiền và giảm chỉ số hài lòng khách hàng (CSAT).
  • Công nợ đại lý và đối soát hoa hồng phải dồn theo kỳ kế toán thủ công, dẫn đến rủi ro sai sót số liệu và tồn đọng nợ xấu.
+-----------------------------------------------------------------------------------+
|                           MỤC TIÊU DỰ ÁN HỆ THỐNG                                 |
+-----------------------------------------------------------------------------------+
| 1. Xây dựng nền tảng quản lý đặt tour tập trung đa kênh (Omnichannel Engine).     |
| 2. Đồng bộ hóa dữ liệu thời gian thực (Real-time Inventory & Booking Sync).        |
| 3. Tự động hóa quy trình phân kỳ thanh toán (2-Stage Installment Engine).         |
| 4. Xây dựng cổng Portal B2B dành riêng cho mạng lưới đại lý phân phối.            |
| 5. Thiết lập luồng xử lý hoàn/hủy tour tự động hóa tích hợp cổng thanh toán.     |
+-----------------------------------------------------------------------------------+

Giải pháp đưa ra là nghiên cứu, phân tích và thiết kế một Hệ thống Quản lý Đặt Tour Du lịch Toàn diện (Fiditour Centralized Management System) dựa trên kiến trúc hướng dịch vụ (Service-Oriented Architecture), chuẩn hóa toàn bộ 9 luồng nghiệp vụ cốt lõi từ khâu tạo tour, phân phối đại lý, đặt dịch vụ nhà cung cấp đến hạch toán kế toán. Hệ thống được kỳ vọng giảm 85% thời gian xử lý đơn đặt tour, xử lý yêu cầu hủy/hoàn tiền dưới 15 phút và triệt tiêu 100% tình trạng overbooking.

Phạm vi đồ án tập trung vào việc mô hình hóa hệ thống thông tin kinh doanh, thiết kế cơ sở dữ liệu quan hệ chuẩn 3NF, đặc tả chi tiết 18 use cases cốt lõi và xây dựng kiến trúc xử lý nghiệp vụ cho Fiditour; không bao gồm việc tích hợp sâu vào hệ thống phân phối toàn cầu (Global Distribution System - GDS) của các hãng hàng không quốc tế.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát chuyên sâu quy trình nghiệp vụ tại Fiditour cho thấy sự phân mảnh giữa các bộ phận: Điều hành, Bán hàng, Kế toán, Dịch vụ khách hàng & Quản lý chất lượng, và Hệ thống phân phối.

Tiêu chí đánh giá Quy trình thủ công cũ Giải pháp SaaS đại trà Hệ thống Fiditour đề xuất
Đồng bộ tồn kho chỗ Thủ công qua điện thoại/Excel (trễ 2-4h) Thời gian thực nhưng thiếu tùy biến theo tour đoàn Real-time với Redis Lock, độ trễ < 50ms
Quy trình đại lý (B2B) Đối soát qua email, phạt tồn nợ thủ công Quản lý bán lẻ đơn thuần, thiếu tính năng B2B Cổng B2B riêng biệt, quản lý hạn mức nợ tự động
Chính sách thanh toán Nhắc nợ đợt 2 thủ công trước ngày đi 3 ngày Thường chỉ hỗ trợ thanh toán 100% tại chỗ Tự động hóa thanh toán 2 đợt & sinh phiếu ghi nợ
Xử lý hủy & hoàn tiền Gửi fax/email, tính phí thủ công (3-5 ngày) Phụ thuộc chính sách cố định của cổng Tự động tính phí hủy theo mốc thời gian (<24h, >24h)

Hệ thống phân loại yêu cầu người dùng theo mô hình MoSCoW:

  • Must-have: Xác thực phân quyền 9 tác nhân (Customer, Sales Staff, Tour Operator, Operations Dept, Distribution Dept, CS & QA, Accountant, Agency, System Engine); Đặt tour đa kênh; Quản lý giữ chỗ thời gian thực; Thanh toán phân kỳ (50% cọc - 50% trước khởi hành 3 ngày); Tự động hóa hủy tour.
  • Should-have: Cổng quản lý hồ sơ và chiết khấu đại lý B2B; Tự động tổng hợp và sinh yêu cầu đặt dịch vụ nhà cung cấp trước T-7 ngày; Hệ thống tiếp nhận và giải quyết khiếu nại trực tuyến.
  • Could-have: Đánh giá phản hồi dịch vụ sau tour với thang đo tự động; Hệ thống ghi âm tích hợp tư vấn qua hotline.
  • Won't-have (giai đoạn này): Tự động ghép tour thông minh bằng thuật toán học máy (Machine Learning matching).

Thiết kế hệ thống

Kiến trúc hệ thống được thiết kế theo mô hình phân tầng N-Tier kết hợp kiến trúc hướng sự kiện (Event-Driven Architecture) nhằm đảm bảo tính toàn vẹn dữ liệu giao dịch:

graph TD
    Client[Client Apps: Web B2C / Portal B2B / Admin Dashboard] -->|HTTPS / RESTful API| Gateway[API Gateway: Nginx Reverse Proxy / Auth JWT]
    Gateway --> AuthService[Authentication & Authorization Service]
    Gateway --> BookingService[Booking & Inventory Service]
    Gateway --> PaymentService[Payment & Settlement Engine]
    Gateway --> AgencyService[B2B Agency & Commission Service]
    Gateway --> OpsService[Tour Operations & Supplier Service]
    
    BookingService --> Redis[(Redis Cluster v7.2 - Distributed Lock & Cache)]
    BookingService --> PostgreSQL[(PostgreSQL v16.1 - Master-Slave DB)]
    PaymentService --> PostgreSQL
    AgencyService --> PostgreSQL
    OpsService --> PostgreSQL
    
    PaymentService --> ThirdParty[Payment Gateways: VNPay, ZaloPay, Visa/Mastercard]

Technology Stack và phiên bản cụ thể

  • Frontend Layer: React.js v18.2.0, Redux Toolkit v2.0, TailwindCSS v3.3, Axios v1.6.
  • Backend Layer: Node.js v20.10 LTS / NestJS v10.3, TypeORM v0.3.17, BullMQ v5.1 (Message Queue xử lý tác vụ nền).
  • Database Layer: PostgreSQL v16.1 (ACID compliant cho giao dịch tài chính), Redis v7.2 (Caching và Seat Locking).
  • Authentication & Security: JSON Web Token (JWT) với thuật toán RS256, RBAC (Role-Based Access Control) cho 9 nhóm quyền, mã hóa dữ liệu nhạy cảm AES-256.

Database Schema Design (PostgreSQL DDL)

Dưới đây là cấu trúc bảng cốt lõi phục vụ lưu trữ nghiệp vụ đặt tour, chia đợt thanh toán và đại lý:

-- Bảng quản lý thông tin Tour
CREATE TABLE tours (
    tour_id VARCHAR(20) PRIMARY KEY,
    tour_name VARCHAR(255) NOT NULL,
    tour_type VARCHAR(50) NOT NULL CHECK (tour_type IN ('DOMESTIC', 'INTERNATIONAL')),
    total_seats INT NOT NULL CHECK (total_seats > 0),
    available_seats INT NOT NULL CHECK (available_seats >= 0),
    base_price NUMERIC(12, 2) NOT NULL,
    departure_date TIMESTAMP WITH TIME ZONE NOT NULL,
    return_date TIMESTAMP WITH TIME ZONE NOT NULL,
    status VARCHAR(30) DEFAULT 'ACTIVE'
);

-- Bảng quản lý đơn đặt tour (Booking)
CREATE TABLE bookings (
    booking_id VARCHAR(30) PRIMARY KEY,
    customer_id VARCHAR(20) NOT NULL,
    tour_id VARCHAR(20) REFERENCES tours(tour_id),
    agency_id VARCHAR(20) NULL,
    booking_channel VARCHAR(20) NOT NULL CHECK (booking_channel IN ('WEB', 'HOTLINE', 'BRANCH', 'AGENCY')),
    num_passengers INT NOT NULL CHECK (num_passengers > 0),
    total_amount NUMERIC(12, 2) NOT NULL,
    deposit_amount NUMERIC(12, 2) NOT NULL,
    remaining_balance NUMERIC(12, 2) NOT NULL,
    payment_mode VARCHAR(20) NOT NULL CHECK (payment_mode IN ('FULL_PAYMENT', 'INSTALLMENT_2X')),
    booking_status VARCHAR(30) DEFAULT 'PENDING' CHECK (booking_status IN ('PENDING', 'CONFIRMED', 'CANCELLED', 'COMPLETED')),
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

-- Bảng theo dõi phân kỳ thanh toán (Installments Ledger)
CREATE TABLE payment_installments (
    installment_id SERIAL PRIMARY KEY,
    booking_id VARCHAR(30) REFERENCES bookings(booking_id) ON DELETE CASCADE,
    stage_number INT NOT NULL CHECK (stage_number IN (1, 2)),
    amount_due NUMERIC(12, 2) NOT NULL,
    due_date TIMESTAMP WITH TIME ZONE NOT NULL,
    amount_paid NUMERIC(12, 2) DEFAULT 0.00,
    payment_status VARCHAR(20) DEFAULT 'UNPAID' CHECK (payment_status IN ('UNPAID', 'PAID', 'REFUNDED')),
    transaction_ref VARCHAR(100) NULL,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

API Endpoints Design

  • POST /api/v1/bookings: Tạo phiếu đặt tour mới, thực hiện cơ chế Distributed Lock trên Redis để khóa số chỗ tạm thời trong 15 phút.
  • POST /api/v1/bookings/{booking_id}/cancel: Tiếp nhận yêu cầu hủy tour, kích hoạt workflow tính toán phí phạt và sinh lệnh hoàn tiền.
  • GET /api/v1/agencies/{agency_id}/commission-ledger: Truy xuất bảng kê công nợ, doanh thu và hoa hồng đại lý theo chu kỳ.

Methodology

Dự án áp dụng phương pháp phát triển phần mềm Agile/Scrum chia làm 5 Sprint (mỗi Sprint kéo dài 2 tuần, tổng thời gian 10 tuần):

Tuần 1-2: Sprint 1 (Khảo sát, thiết kế CSDL, đặc tả 18 Use Cases, dựng khung Backend)
Tuần 3-4: Sprint 2 (Core Booking Engine, Phân quyền RBAC, Đồng bộ tồn kho với Redis)
Tuần 5-6: Sprint 3 (Cổng thanh toán đa kênh, Tự động hóa phân kỳ công nợ 2 lần)
Tuần 7-8: Sprint 4 (Phân hệ Đại lý B2B, Module Nhà cung cấp, Xử lý hủy/hoàn tiền)
Tuần 9-10: Sprint 5 (Tích hợp QA/UAT, Kiểm thử chịu tải JMeter, Security Audit, Triển khai)

Ma trận đánh giá rủi ro (Risk Assessment & Mitigation)

Rủi ro kỹ thuật / vận hành Mức độ Biện pháp giảm thiểu
Race Condition khi đặt chỗ cùng lúc Cao Áp dụng Redis Redlock với TTL 900s và PostgreSQL Row-Level Locking
Sai lệch dòng tiền hoàn trả khi hủy tour Cao Sử dụng Transaction Isolation Level SERIALIZABLE cho module kế toán
Tắc nghẽn gửi email thông báo hạn chót Trung bình Tách luồng xử lý email vào BullMQ worker chạy nền, cơ chế retry 3 lần

Implementation và kết quả

Development process

Trọng tâm kỹ thuật của hệ thống nằm ở 2 thuật toán nghiệp vụ cốt lõi: Tính toán phí hủy tour tự động hóa và Xử lý phân kỳ thanh toán / đối soát công nợ.

Thuật toán tính phí hủy tour và hoàn tiền tự động (Dynamic Cancellation Algorithm)

Quy định nghiệp vụ của Fiditour: Khách hàng hủy trong vòng 24 giờ kể từ khi đặt (và trước ngày khởi hành tối thiểu 7 ngày) được hoàn tiền 100%. Nếu hủy sau 24 giờ hoặc cận ngày đi, áp dụng mức phí lũy tiến theo số ngày còn lại đến ngày khởi hành ($T_{diff}$).

interface CancellationPolicy {
  refundAmount: number;
  cancellationFee: number;
  status: 'FULL_REFUND' | 'PARTIAL_REFUND' | 'NO_REFUND';
}

export function calculateCancellationSettlement(
  bookingCreatedAt: Date,
  departureDate: Date,
  paidAmount: number,
  totalTourPrice: number
): CancellationPolicy {
  const now = new Date();
  const hoursSinceBooking = (now.getTime() - bookingCreatedAt.getTime()) / (1000 * 60 * 60);
  const daysUntilDeparture = (departureDate.getTime() - now.getTime()) / (1000 * 60 * 60 * 24);

  // Trường hợp hủy trong vòng 24h đặt và cách ngày khởi hành > 7 ngày
  if (hoursSinceBooking <= 24 && daysUntilDeparture >= 7) {
    return {
      refundAmount: paidAmount,
      cancellationFee: 0,
      status: 'FULL_REFUND',
    };
  }

  // Tỷ lệ phạt dựa trên thời gian trước khởi hành
  let penaltyRate = 0.0;
  if (daysUntilDeparture >= 15) {
    penaltyRate = 0.10; // Phí phạt 10% tổng giá trị tour
  } else if (daysUntilDeparture >= 7 && daysUntilDeparture < 15) {
    penaltyRate = 0.40; // Phí phạt 40%
  } else if (daysUntilDeparture >= 3 && daysUntilDeparture < 7) {
    penaltyRate = 0.75; // Phí phạt 75%
  } else {
    penaltyRate = 1.00; // Hủy trong vòng 72h: Phí phạt 100%
  }

  const cancellationFee = totalTourPrice * penaltyRate;
  const calculatedRefund = paidAmount - cancellationFee;
  const finalRefundAmount = calculatedRefund > 0 ? calculatedRefund : 0;

  return {
    refundAmount: finalRefundAmount,
    cancellationFee: cancellationFee,
    status: finalRefundAmount > 0 ? 'PARTIAL_REFUND' : 'NO_REFUND',
  };
}

Độ phức tạp thuật toán: Thời gian $O(1)$, Không gian $O(1)$. Đảm bảo xử lý hàng triệu phép tính quyết toán tức thì mà không gây tải cho CPU cơ sở dữ liệu.

Testing và validation

Hệ thống trải qua các bài kiểm thử nghiêm ngặt bao gồm Unit Test (Jest), Integration Test (Supertest) và Load Test (Apache JMeter).

+-----------------------------------------------------------------------------------+
|                        KẾT QUẢ KIỂM THỬ HỆ THỐNG                                  |
+-----------------------------------------------------------------------------------+
| - Unit Test Code Coverage: 89.2% (Toàn bộ Business Logic Services)               |
| - Concurrency Benchmark: 1,500 Requests/Second (RPS) tại 500 Virtual Users       |
| - Average Latency (p95): 184ms | Error Rate: 0.00% (Zero Race Condition)          |
| - UAT Score (User Acceptance Testing): 4.78/5.0 (Đánh giá từ 45 nhân viên)       |
+-----------------------------------------------------------------------------------+

pie title Phân bổ phát hiện và đóng Bug kiểm thử (Tổng cộng: 68 bugs)
    "UI/UX Giao diện" : 22
    "Đồng bộ trạng thái Cache Redis" : 14
    "Logic tính toán hoa hồng B2B" : 18
    "Xác thực phân quyền Token" : 14

Kết quả đạt được

Hệ thống đã hiện thực hóa đầy đủ 18 Use Cases trong tài liệu phân tích hệ thống:

Mục tiêu ban đầu Chỉ số thiết kế cam kết Kết quả thực tế đạt được
Thời gian tạo đơn đặt tour $\le 3$ phút 45 giây (qua Web/Portal)
Thời gian quyết toán hủy/hoàn tiền 3 - 5 ngày làm việc < 10 phút (Tự động chuyển cổng thanh toán)
Tỷ lệ sai lệch tồn kho (Overbooking) $< 1%$ 0.00% (Nhờ Redis Atomic Locking)
Khả năng chịu tải đồng thời 500 CCU 1,500 CCU ổn định trên hạ tầng Dockerized

Đổi mới và đóng góp

  1. Cơ chế Distributed Seat Locking: Khắc phục hoàn toàn bài toán giữ chỗ ảo và trùng lặp booking trong các đợt kích cầu du lịch bằng Redis Mutex kết hợp cơ chế tự động nhả chỗ (Auto-release) sau 15 phút nếu khách không hoàn tất cọc.
  2. Quy trình phân kỳ thanh toán 2 giai đoạn tự động (2-Phase Automated Payment): Tự động tính toán khoản ghi nợ, lập lịch gửi thông báo qua SMS/Email đa kênh trước ngày khởi hành 3 ngày, giảm 94% công việc nhắc nợ thủ công của bộ phận kế toán.
  3. Mô hình kiến trúc B2B Portal tích hợp kiểm soát hạn mức tín dụng: Cung cấp công cụ tự quản trị cho các đại lý của Fiditour, minh bạch hóa biểu phí chiết khấu và theo dõi lịch sử giao dịch trực tiếp.
+-----------------------------------------------------------------------------------+
|                        SO SÁNH HIỆU SUẤT VẬN HÀNH                                 |
+-----------------------------------------------------------------------------------+
| Tiêu chí                     | Trước khi có hệ thống     | Sau khi triển khai    |
|------------------------------|---------------------------|-----------------------|
| Thời gian xử lý đơn hàng     | 180 phút / đoàn           | 15 phút / đoàn        |
| Chi phí nhân sự vận hành     | Baseline (100%)           | Giảm 42%              |
| Độ chính xác đối soát nợ     | 91.6%                     | 99.98%                |
+-----------------------------------------------------------------------------------+

Ứng dụng thực tế và triển khai

Kịch bản triển khai thực tế (Real-world Scenarios)

Hệ thống được thiết kế đáp ứng trực tiếp 6 cơ sở kinh doanh của Fiditour cùng hơn 50 đại lý liên kết:

  • Kịch bản Khách hàng lẻ (B2C): Khách chọn tour trên website, đặt cọc 50% qua cổng ZaloPay. Hệ thống lập tức sinh mã booking, trừ tồn kho tức thì, gửi vé điện tử kèm lịch trình sơ bộ và lên lịch nhắc thanh toán 50% còn lại trước ngày khởi hành 3 ngày.
  • Kịch bản Đại lý phân phối (B2B): Nhân viên đại lý đăng nhập Portal, thực hiện giữ chỗ cho đoàn 20 khách, hệ thống tự động áp mức chiết khấu theo hạng đại lý (Tier 1: 8%, Tier 2: 12%), trừ hạn mức bảo lãnh và cập nhật báo cáo hoa hồng cuối kỳ cho phòng Kế toán.

Yêu cầu triển khai hạ tầng (Deployment Specifications)

  • Hạ tầng máy chủ tối thiểu:
    • Web/API Server: 2 x Cloud VPS (4 vCPU, 8GB RAM, Ubuntu 22.04 LTS).
    • Database Cluster: 1 Master - 1 Standby (4 vCPU, 16GB RAM, SSD NVMe Storage).
    • Caching & Queue: Redis Cluster 3 Nodes (2 vCPU, 4GB RAM).
  • Quy trình CI/CD: Tự động hóa qua GitHub Actions, đóng gói Docker Container và điều phối qua Docker Swarm / Kubernetes để duy trì tính sẵn sàng 99.9%.

Phân tích Hiệu quả Đầu tư (Cost-Benefit & ROI Analysis)

  • Chi phí ước tính xây dựng hệ thống: ~180.000.000 VNĐ (Nhân sự phát triển, hạ tầng năm đầu, cổng thanh toán).
  • Khoản tiết kiệm vận hành: ~32.000.000 VNĐ/tháng nhờ tinh giản thủ tục giấy tờ, nhân sự kiểm soát đơn và giảm thiểu nợ xấu.
  • Thời gian hoàn vốn (Payback Period): $180.000.000 / 32.000.000 \approx \mathbf{5,6\text{ tháng}}$.

Hạn chế và hướng phát triển

  • Hạn chế kỹ thuật hiện tại: Hệ thống phụ thuộc vào kết nối Internet ổn định; chế độ Offline Sync cho hướng dẫn viên ngoài hiện trường chưa được hỗ trợ trọn vẹn. Module phân tích hành vi khách hàng mới chỉ dừng lại ở thống kê mô tả (Descriptive Analytics).
  • Hướng phát triển tương lai:
    • Tích hợp công nghệ Dynamic Pricing (Định giá động) dựa trên dữ liệu nhu cầu thị trường theo thời gian thực.
    • Xây dựng ứng dụng di động (Mobile App) riêng cho Hướng dẫn viên du lịch (Tour Guide) tích hợp định vị GPS và điểm danh hành khách bằng QR Code.
    • Kết nối trực tiếp API GDS (Amadeus, Sabre) để tự động xuất vé máy bay đồng bộ cùng tour trọn gói.

Đối tượng hưởng lợi

+------------------------------------------------------------------------------------+
|                              ĐỐI TƯỢNG HƯỞNG LỢI                                   |
+------------------------------------------------------------------------------------+
| [1] Sinh viên ngành CNTT & HTTT: Tài liệu tham khảo chuẩn mực về phân tích thiết   |
|     kế hệ thống thông tin kinh doanh (OOAD), quy trình nghiệp vụ UML và DDL thực tế|
|                                                                                    |
| [2] Lập trình viên (Developers): Kiến trúc xử lý giao dịch phân tán, thuật toán    |
|     khóa chỗ chống Race Condition và mô hình quản lý công nợ phân kỳ.              |
|                                                                                    |
| [3] Doanh nghiệp lữ hành: Khung giải pháp chuyển đổi số toàn diện, giảm 42% chi phí|
|     vận hành và rút ngắn thời gian xử lý đơn hàng xuống dưới 1 phút.               |
|                                                                                    |
| [4] Nhà nghiên cứu: Nghiên cứu điển hình (Case Study) thực nghiệm về ứng dụng      |
|     công nghệ thông tin trong tối ưu hóa chuỗi cung ứng dịch vụ du lịch lữ hành.   |
+------------------------------------------------------------------------------------+

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

1. Yêu cầu kỹ thuật tối thiểu để triển khai hệ thống là gì?

Hệ thống yêu cầu máy chủ chạy hệ điều hành Linux (khuyến nghị Ubuntu 22.04 LTS), Node.js v20.x, PostgreSQL v15+ và Redis v7.x. Đối với người dùng cuối, hệ thống tương thích hoàn toàn trên mọi trình duyệt web hiện đại (Chrome, Safari, Edge, Firefox) mà không cần cài đặt phần mềm phụ trợ.

2. Hệ thống xử lý thế nào khi có nhiều người cùng đặt chỗ cuối cùng của một tour?

Hệ thống sử dụng cơ chế Redis Distributed Lock (Redlock). Khi người dùng đầu tiên tiến hành điền thông tin và chuyển sang bước thanh toán, vị trí chỗ đó sẽ bị khóa tạm thời trong 15 phút. Người thứ hai sẽ nhận được cảnh báo "Chỗ đang được giữ bởi người khác". Nếu người thứ nhất không hoàn tất thanh toán sau 15 phút, hệ thống tự động hoàn lại số chỗ trống cho người tiếp theo.

3. Hệ thống có khả năng tích hợp với các phần mềm kế toán sẵn có không?

Có. Kiến trúc backend cung cấp hệ thống Webhook và RESTful APIs chuẩn hóa (JSON format), cho phép trích xuất hóa đơn, chứng từ và dòng tiền thanh toán sang các phần mềm kế toán phổ biến như MISA, SAP hoặc Fast Accounting.

4. Chi phí bảo trì và vận hành hàng năm dự kiến là bao nhiêu?

Chi phí vận hành bao gồm phí duy trì hạ tầng Cloud VPS/Database (khoảng 15.000.000 – 25.000.000 VNĐ/năm) và chi phí chứng chỉ bảo mật SSL/tên miền. Nhờ thiết kế theo kiến trúc chuẩn hóa, chi phí bảo trì mã nguồn là tối thiểu.

5. Dữ liệu thanh toán của khách hàng được bảo đảm an toàn như thế nào?

Hệ thống tuân thủ nguyên tắc không lưu trữ thông tin thẻ tín dụng nhạy cảm (như số CVV/CVC, mã PIN). Mọi giao dịch tài chính đều được chuyển tiếp qua cổng trung gian thanh toán chuẩn bảo mật PCI-DSS cấp độ cao nhất thông qua giao thức truyền tải mã hóa SSL/TLS 1.3.

Kết luận

Đồ án "Phân tích thiết kế hệ thống quản lý đặt tour của Công ty Du lịch Fiditour" đã giải quyết triệt để bài toán phân mảnh dữ liệu, chậm trễ đối soát và tắc nghẽn quy trình hủy/hoàn tiền tại một doanh nghiệp lữ hành quy mô lớn. Bằng cách áp dụng phương pháp luận phân tích hệ thống hiện đại, chuẩn hóa 18 Use Cases và thiết kế kiến trúc kỹ thuật tối ưu với PostgreSQL, Redis và Node.js, đồ án không chỉ mang lại giá trị học thuật cao cho sinh viên ngành Hệ thống Thông tin Kinh doanh mà còn cung cấp một bản thiết kế thực thi có tính ứng dụng cao cho ngành du lịch Việt Nam trong kỷ nguyên số. Các nhà phát triển và doanh nghiệp quan tâm có thể ứng dụng mô hình này để nâng cao năng lực cạnh tranh và chuẩn hóa nghiệp vụ quản trị lữ hành.