Diễn giải hệ thống và các module

Summary feature, độ phức tạp và estimate sơ bộ

Estimate dưới đây là ước lượng sơ bộ theo man-day cho 1 dev và 1 tester, dùng để hình dung effort ở mức story/high-level. Chưa bao gồm UAT, PM, DevOps, triển khai production, migration dữ liệu thực tế và thời gian chờ khách hàng xác nhận.

Background

• Hai pháp nhân Công ty Cổ Phần Đầu Tư Phát Triển Núi Hồng và Công Ty TNHH Thương Mại và Dịch Vụ Tổng Hợp Lâm Giang cùng vận hành mảng xăng dầu và vận tải.
• Hai công ty dùng chung một nền tảng phần mềm, nhưng dữ liệu, tài sản, nhân sự, báo cáo và vận hành phải tách riêng theo từng công ty.
• Trong nghiệp vụ xăng dầu, công ty có thể bán xăng dầu cho cửa hàng/điểm bán trực thuộc hoặc khách hàng bên ngoài.
• Cửa hàng xăng dầu được xem như một đối tượng mua hàng từ công ty để bán lẻ, không dùng mô hình phân cấp pháp nhân để tránh hiểu nhầm về quan hệ giữa 2 công ty.

Quản trị 2 công ty và phạm vi dữ liệu

• Hệ thống phục vụ cho 2 doanh nghiệp:
  • Công ty Cổ Phần Đầu Tư Phát Triển Núi Hồng.
  • Công Ty TNHH Thương Mại và Dịch Vụ Tổng Hợp Lâm Giang.
• Cả 2 doanh nghiệp đều vận hành mảng xăng dầu và vận tải.
• Hệ thống dùng chung một nền tảng, nhưng dữ liệu phải tách riêng theo từng công ty:
  • Nhân sự.
  • Tài sản.
  • Xe.
  • Tài xế.
  • Kho.
  • Cửa hàng.
  • Phiếu mua/bán/nhập/xuất.
  • Chuyến xe.
  • Công nợ.
  • Doanh thu, chi phí, lợi nhuận.
  • Báo cáo.
• Nhân viên thuộc công ty nào thì chỉ thao tác và xem dữ liệu của công ty đó.
• Một số user quyền cao có thể xem dữ liệu cả 2 công ty.
• Với user có quyền xem nhiều công ty, hệ thống cần có bộ chọn công ty để xem riêng từng công ty.
• BOD/Giám đốc cần xem báo cáo tách riêng theo từng công ty, không mặc định gộp số liệu của 2 công ty.
• Nếu sau này cần xem hợp nhất 2 công ty, đó nên là một lựa chọn riêng, không phải mặc định.

Cách đọc story này

• Các nội dung nghiệp vụ chính bên dưới được diễn giải từ 2 tài liệu EasyNote đã ghi nhận với khách hàng.
• Một số phần là chuẩn hóa/suy luận triển khai để story dễ hiểu hơn, ví dụ: bảng vai trò, trạng thái chứng từ, lịch sử thao tác, quy tắc đối soát, cảnh báo vận hành.
• Các phần có nhãn Cần xác nhận là điểm cần hỏi lại khách hàng trước khi chốt scope hoặc thiết kế chi tiết.

Vai trò người dùng cơ bản

Bảng dưới đây là chuẩn hóa vai trò đề xuất từ nghiệp vụ EasyNote, chưa phải ma trận phân quyền chi tiết đã được khách hàng chốt.

BOD / Dashboard tổng quan

BOD/Giám đốc cần một màn hình tổng quan để xem tình hình vận hành và tài chính của từng công ty.

• Dashboard mặc định xem theo từng công ty.
• User có quyền cao có thể đổi công ty bằng bộ chọn công ty.
• Dashboard cần có bộ lọc:
  • Theo ngày.
  • Theo tháng.
  • Theo khoảng ngày.
  • Theo công ty.

Nhóm chỉ số tài chính

• Tổng doanh thu.
• Tổng chi phí.
• Lợi nhuận gộp.
• Lợi nhuận thực.
• Tổng tiền thực trong các tài khoản ngân hàng.
• Công nợ phải thu.
• Công nợ phải trả.
• Tiền đang kẹt ở:
  • Tồn kho.
  • Khách hàng/cửa hàng chưa thanh toán.
  • Hàng đã bán nhưng chưa xuất.
  • Khoản phải trả nhà cung cấp sắp đến hạn.

Nhóm chỉ số xăng dầu

• Tổng lượng mua vào.
• Tổng lượng bán ra.
• Tồn kho vật lý.
• Tồn kho khả dụng.
• Hàng đã bán nhưng chưa xuất.
• Giá trị tồn kho.
• Doanh thu xăng dầu.
• Lợi nhuận xăng dầu.

Nhóm chỉ số cửa hàng

• Doanh thu cửa hàng.
• Lượng xăng bán ra theo cửa hàng.
• Tồn kho từng cửa hàng.
• Tiền cửa hàng đã chuyển về.
• Tiền cửa hàng còn thiếu/chuyển dư.
• Lợi nhuận cửa hàng.
• Chi phí cửa hàng.

Nhóm chỉ số vận tải

• Tổng số chuyến xe.
• Doanh thu vận tải.
• Chi phí vận tải.
• Lợi nhuận vận tải.
• Doanh thu/chi phí theo xe.
• Doanh thu/chi phí theo tài xế.
• Công nợ khách hàng vận tải.
• Công nợ garage.
• Xe sắp đến hạn bảo dưỡng.

Cảnh báo đề xuất / điểm cần chú ý

Các cảnh báo dưới đây là đề xuất vận hành dựa trên nghiệp vụ đã mô tả, không phải toàn bộ đều được EasyNote ghi trực tiếp:

• Công nợ quá hạn.
• Phiếu mua/bán chờ duyệt.
• Chi phí chờ duyệt.
• Cửa hàng chưa gửi báo cáo ngày.
• Cửa hàng chuyển thiếu tiền.
• Tồn kho thấp.
• Hàng đã bán nhưng chưa xuất lâu ngày.
• Xe sắp đến hạn bảo dưỡng.

Quản lý xăng dầu

• Bao gồm 4 phần cơ bản: Mua -> Nhập, Bán -> Xuất:
  • Công ty mua từ nhà cung cấp như Petrolimex => Tạo phiếu mua. Nếu phiếu mua này chưa được bộ phận kế toán chuyển qua: Đã thanh toán thì số tiền mua hàng sẽ được tính vào Công Nợ Phải Trả cho Nhà Cung Cấp.
  • Sau khi phiếu mua được duyệt, công ty sẽ tạo phiếu nhập kho để ghi nhận hàng thực nhập. Sau khi Nhập Kho, các thông tin như: Tồn Kho, Số tiền tồn kho, Công nợ sẽ được tính - Kho vẫn được nhập khi chưa thanh toán.
  • Công ty bán cho cửa hàng xăng dầu hoặc khách hàng bên ngoài => Tạo phiếu bán.
  • Sau khi phiếu bán được duyệt, công ty sẽ tạo phiếu xuất kho để ghi nhận hàng thực xuất cho khách hàng/cửa hàng.
• Trước khi Mua/Bán đều phải đi qua quy trình duyệt thì mới được Nhập/Xuất.

Lô hàng, giá vốn và chiết khấu khi bán xăng dầu

• Mỗi phiếu mua xăng dầu sẽ tạo ra 1 Lô hàng.
• Mỗi Lô hàng có các thông tin chính:
  • Nhà cung cấp
  • Kho lưu trữ
  • Số lượng nhập
  • Giá vốn/giá gốc mua vào
  • Số lượng còn tồn của lô
• Khi tạo phiếu bán, người dùng bắt buộc phải chọn thủ công bán từ Lô hàng nào.
• Một phiếu bán có thể lấy hàng từ nhiều lô khác nhau.
• Người dùng nhập số lượng lấy từ từng lô để hệ thống tính ra giá vốn bình quân của phiếu bán.
• Thay vì nhập trực tiếp Giá bán, người dùng nhập Chiết khấu theo đồng/lít.
• Hệ thống lấy Giá xăng dầu hiện tại trừ đi Chiết khấu để tính ra giá bán thực tế.
• Lợi nhuận gộp của phiếu bán được tính dựa trên:
  • Giá bán thực tế
  • Giá vốn bình quân
  • Số lượng bán

Ví dụ:

• Giá xăng dầu hiện tại: 16.500đ/lít
• Khách hàng được chiết khấu: 1.000đ/lít
• Giá bán thực tế: 16.500đ - 1.000đ = 15.500đ/lít
• Phiếu bán lấy hàng từ 2 lô:
  • Lô 1: 60.000 lít, giá vốn 14.400đ/lít
  • Lô 2: 60.000 lít, giá vốn 14.600đ/lít
• Giá vốn bình quân:
  • (60.000 * 14.400 + 60.000 * 14.600) / 120.000 = 14.500đ/lít
• Lợi nhuận gộp trên mỗi lít:
  • 15.500đ - 14.500đ = 1.000đ/lít
• Tổng lợi nhuận gộp của phiếu bán:
  • 1.000đ * 120.000 lít = 120.000.000đ

Cập nhật giá xăng dầu

• Hệ thống cần có phân hệ cập nhật Giá xăng dầu hiện tại theo ngày hoặc theo thời điểm thay đổi giá.
• Giá xăng dầu hiện tại là giá niêm yết/cơ sở dùng để tính giá bán cho khách hàng.
• Giá xăng dầu hiện tại khác với Giá vốn của lô hàng:
  • Giá vốn là giá công ty mua vào, được lưu cố định theo từng Lô hàng.
  • Giá xăng dầu hiện tại là giá bán cơ sở tại thời điểm tạo/duyệt phiếu bán.
• Khi tạo phiếu bán:
  • Người dùng chọn thủ công các Lô hàng sẽ bán.
  • Hệ thống lấy giá vốn từ các lô đã chọn để tính Giá vốn bình quân.
  • Hệ thống lấy Giá xăng dầu hiện tại.
  • Người dùng nhập Chiết khấu theo đồng/lít.
  • Hệ thống tính Giá bán thực tế = Giá xăng dầu hiện tại - Chiết khấu.
• Giá xăng dầu dùng trên phiếu bán phải được chốt lại tại thời điểm tạo/duyệt phiếu.
• Nếu bảng giá thay đổi sau đó, các phiếu bán cũ không được tự thay đổi giá bán, doanh thu hoặc lợi nhuận.
• Cần xác nhận: EasyNote đã nói có bảng giá xăng dầu theo ngày và giá bán tính từ chiết khấu, nhưng chưa nói rõ thời điểm chốt giá là lúc tạo phiếu, gửi duyệt hay duyệt phiếu.
• Cần xác nhận: EasyNote phần 2 ghi "Giá trị tồn kho" theo cách diễn đạt dễ gây nhầm lẫn. Cần hỏi lại khách hàng giá trị tồn kho phải tính theo giá vốn/gốc nhập của từng lô hay theo một công thức khác.

Ví dụ:

• Ngày 20/05/2026, giá xăng dầu hiện tại là 16.500đ/lít.
• Nhân viên tạo phiếu bán cho khách hàng A:
  • Chọn Lô 1: 60.000 lít, giá vốn 14.400đ/lít
  • Chọn Lô 2: 60.000 lít, giá vốn 14.600đ/lít
  • Nhập chiết khấu: 1.000đ/lít
• Hệ thống chốt trên phiếu bán:
  • Giá xăng dầu tại thời điểm bán: 16.500đ/lít
  • Giá bán thực tế: 16.500đ - 1.000đ = 15.500đ/lít
  • Giá vốn bình quân: 14.500đ/lít
  • Lợi nhuận gộp trên mỗi lít: 1.000đ/lít
• Ngày 21/05/2026, giá xăng dầu tăng lên 16.800đ/lít.
• Phiếu bán ngày 20/05/2026 vẫn giữ giá 16.500đ/lít, không tính lại theo giá mới.

Tóm tắt luồng giá:

• Cập nhật bảng giá xăng dầu.
• Tạo phiếu mua để sinh lô hàng và lưu giá vốn từng lô.
• Khi tạo phiếu bán, người dùng chọn lô thủ công, nhập chiết khấu, hệ thống tính giá bán thực tế.
• Giá bán trên phiếu phải được chốt lại để bảng giá mới không làm thay đổi phiếu cũ.

flowchart TD
    A[Cập nhật bảng giá xăng dầu] --> B[Giá xăng dầu hiện tại]

    C[Tạo phiếu mua] --> D[Tạo lô hàng]
    D --> E[Lưu giá vốn của từng lô]
    E --> F[Chọn lô thủ công khi tạo phiếu bán]

    B --> G[Tạo phiếu bán]
    F --> G
    G --> H[Nhập chiết khấu theo đồng/lít]
    G --> I[Tính giá vốn bình quân từ các lô đã chọn]
    H --> J[Tính giá bán thực tế]
    B --> J

    J --> K[Chốt giá bán trên phiếu bán]
    I --> L[Tính lợi nhuận gộp]
    K --> L

    M[Bảng giá thay đổi sau đó] --> N[Không cập nhật lại phiếu bán cũ]
    K --> N

Quy trình duyệt phiếu mua và phiếu bán

• Phiếu mua và phiếu bán đều phải đi qua quy trình duyệt trước khi được nhập/xuất kho.
• Quy trình phiếu mua:
  • Nhân viên tạo phiếu mua.
  • Gửi duyệt.
  • Sau khi được duyệt, bộ phận kho mới được tạo phiếu nhập kho.
  • Khi nhập kho, hệ thống mới cập nhật tồn kho, giá trị tồn kho và công nợ phải trả.
• Quy trình phiếu bán:
  • Nhân viên tạo phiếu bán.
  • Chọn khách hàng, kho, lô hàng, số lượng từng lô và chiết khấu.
  • Gửi duyệt.
  • Sau khi được duyệt, bộ phận kho mới được tạo phiếu xuất kho.
  • Khi xuất kho, hệ thống mới cập nhật tồn kho, giá vốn, doanh thu và công nợ phải thu.
• Duyệt phiếu không đồng nghĩa với đã nhập kho/xuất kho.
• Thanh toán/thu tiền là bước riêng do kế toán cập nhật.
• Hệ thống cần lưu lịch sử: người tạo, người gửi duyệt, người duyệt/từ chối, thời gian xử lý và lý do từ chối nếu có.

Trạng thái chứng từ

Các trạng thái dưới đây là chuẩn hóa đề xuất từ luồng EasyNote, chưa phải taxonomy trạng thái đã được khách hàng chốt.

• Phiếu mua: Nháp -> Chờ duyệt -> Đã duyệt -> Đã nhập một phần/Đã nhập đủ -> Thanh toán một phần/Đã thanh toán.
• Phiếu bán: Nháp -> Chờ duyệt -> Đã duyệt -> Đã xuất một phần/Đã xuất đủ -> Thu tiền một phần/Đã thu tiền.
• Phiếu mua/bán có thể chuyển sang Đã hủy; khi hủy không xóa dữ liệu mà rollback các phát sinh tồn kho, doanh thu và công nợ liên quan.
• Cần xác nhận: với phiếu bán, thời điểm bắt đầu giữ hàng cho khách là khi tạo phiếu, gửi duyệt hay sau khi phiếu được duyệt.

Đối soát nhập/xuất nhiều lần

• Một phiếu mua có thể được nhập kho nhiều lần bằng nhiều phiếu nhập kho.
• Một phiếu bán có thể được xuất kho nhiều lần bằng nhiều phiếu xuất kho.
• Hệ thống cần đối soát số lượng theo từng chứng từ gốc:
  • Tổng số lượng trên phiếu mua/phiếu bán.
  • Đã nhập kho hoặc đã xuất kho bao nhiêu.
  • Còn lại bao nhiêu chưa nhập/chưa xuất.
  • Danh sách từng lần nhập/xuất: ngày thực hiện, người thực hiện, kho, lô hàng, số lượng.
• Không được nhập kho vượt quá số lượng còn lại trên phiếu mua.
• Không được xuất kho vượt quá số lượng còn lại trên phiếu bán hoặc số lượng còn tồn của lô đã chọn.
• Trạng thái chứng từ sẽ được cập nhật dựa trên kết quả đối soát:
  • Phiếu mua: chưa nhập, nhập một phần, nhập đủ.
  • Phiếu bán: chưa xuất, xuất một phần, xuất đủ.

Ví dụ:

• Phiếu mua PM001 có tổng số lượng 100.000 lít.
  • Nhập lần 1: 40.000 lít
  • Nhập lần 2: 60.000 lít
  • Tổng đã nhập: 100.000 lít
  • Còn lại chưa nhập: 0 lít
• Phiếu bán PB001 có tổng số lượng 100.000 lít.
  • Xuất lần 1: 40.000 lít
  • Xuất lần 2: 60.000 lít
  • Tổng đã xuất: 100.000 lít
  • Còn lại chưa xuất: 0 lít

Quản lý danh mục nền cho xăng dầu

Các danh mục nền là dữ liệu dùng chung để tạo phiếu mua, phiếu bán, phiếu nhập kho, phiếu xuất kho và báo cáo tồn kho.

• Nhà cung cấp
  • Dùng khi tạo phiếu mua xăng dầu.
  • Lưu thông tin tên nhà cung cấp, thông tin liên hệ, mã số thuế nếu có.
  • Ví dụ: Petrolimex.
• Khách hàng
  • Dùng khi tạo phiếu bán xăng dầu.
  • Bao gồm khách hàng ngoài công ty và các cửa hàng/điểm bán mua hàng từ công ty.
  • Lưu thông tin tên khách hàng, thông tin liên hệ, mã số thuế nếu có.
• Kho
  • Dùng khi nhập kho, xuất kho và xem tồn kho.
  • Một công ty có thể có nhiều kho.
  • Kho có thể là kho tổng hoặc kho/cửa hàng xăng dầu.
• Sản phẩm xăng dầu
  • Danh mục các loại xăng dầu đang mua bán.
  • Ví dụ: RON95, E5 RON92, Dầu DO.
  • Mỗi sản phẩm có đơn vị tính chính, ví dụ lít hoặc khối.
• Đơn vị tính
  • Dùng để thống nhất số lượng trên phiếu mua/bán/nhập/xuất.
  • Ví dụ: lít, khối.
  • Nếu dùng nhiều đơn vị tính, hệ thống cần có tỷ lệ quy đổi rõ ràng.
• Tài khoản ngân hàng
  • Công ty, khách hàng và nhà cung cấp có thể có nhiều tài khoản ngân hàng.
  • Dữ liệu này phục vụ phần tài chính, thanh toán và đối soát sao kê.
• Tên trong nội dung chuyển khoản
  • Mỗi khách hàng/nhà cung cấp có thể có tên nhận diện trong nội dung chuyển khoản.
  • Dùng để hệ thống nhận diện giao dịch khi import sao kê ngân hàng.

Quản lý hàng đã bán nhưng chưa xuất hết

• Trong nghiệp vụ xăng dầu, có trường hợp công ty đã bán hàng cho khách nhưng khách chưa lấy hết hàng ngay.
• Phần hàng này vẫn còn nằm trong kho vật lý của công ty, nhưng đã thuộc về khách hàng trên phiếu bán.
• Sau khi phiếu bán được duyệt, lượng hàng trên phiếu cần được giữ lại cho khách, không được bán tiếp cho khách khác.
• Hệ thống cần biết khách hàng nào đang còn hàng gửi tại kho, thuộc phiếu bán nào và lô hàng nào.
• Cần tách rõ các khái niệm:
  • Tồn kho vật lý: tổng lượng xăng thực tế còn trong kho.
  • Hàng đã bán chưa xuất: lượng xăng đã giữ cho khách nhưng chưa xuất khỏi kho.
  • Tồn kho khả dụng: lượng xăng còn có thể bán cho khách khác.
• Công thức:
  • Tồn kho khả dụng = Tồn kho vật lý - Hàng đã bán chưa xuất
• Theo ghi nhận hiện tại, công ty không tính phí lưu kho cho hàng khách đã mua nhưng chưa lấy hết.
• Khi xuất kho từng phần:
  • Mỗi lần xuất kho sẽ giảm Hàng đã bán chưa xuất.
  • Đồng thời giảm Tồn kho vật lý.
  • Nếu xuất đủ số lượng trên phiếu bán thì phiếu bán chuyển sang trạng thái đã xuất đủ.

Ví dụ:

• Phiếu bán PB001 cho khách hàng A:
  • Tổng bán: 100.000 lít
  • Đã xuất kho: 0 lít
  • Hàng khách A còn gửi tại kho: 100.000 lít
• Xuất kho lần 1:
  • Xuất: 40.000 lít
  • Đã xuất kho: 40.000 lít
  • Hàng khách A còn gửi tại kho: 60.000 lít
• Xuất kho lần 2:
  • Xuất: 60.000 lít
  • Đã xuất kho: 100.000 lít
  • Hàng khách A còn gửi tại kho: 0 lít
  • Phiếu bán chuyển sang trạng thái đã xuất đủ.

Tóm tắt luồng hàng đã bán nhưng chưa xuất:

• Phiếu bán được duyệt và giữ hàng cho khách.
• Phần hàng đã giữ làm giảm tồn kho khả dụng nhưng chưa giảm tồn kho vật lý.
• Khi khách lấy hàng từng phần, mỗi lần xuất kho giảm đồng thời hàng đã bán chưa xuất và tồn kho vật lý.
• Khi xuất đủ số lượng trên phiếu, phiếu bán chuyển sang trạng thái đã xuất đủ.

flowchart TD
    A[Tạo phiếu bán cho khách hàng] --> B[Chọn lô hàng và số lượng bán]
    B --> C[Gửi duyệt phiếu bán]
    C --> D[Phiếu bán được duyệt]

    D --> E[Giữ hàng cho khách]
    E --> F[Tăng hàng đã bán chưa xuất]
    E --> G[Giảm tồn kho khả dụng]
    E --> H[Tồn kho vật lý chưa đổi]

    F --> I[Khách lấy hàng từng phần]
    I --> J[Tạo phiếu xuất kho]
    J --> K[Giảm hàng đã bán chưa xuất]
    J --> L[Giảm tồn kho vật lý]

    K --> M{Đã xuất đủ?}
    M -->|Chưa| I
    M -->|Rồi| N[Phiếu bán đã xuất đủ]

Hủy phiếu và rollback

• Phiếu mua/phiếu bán không nên bị xóa khỏi hệ thống, mà chuyển sang trạng thái Đã hủy.
• Khi hủy phiếu, người dùng cần nhập:
  • Lý do hủy
  • Chứng từ/hình ảnh đính kèm nếu có
• Hệ thống cần lưu lịch sử:
  • Người hủy
  • Thời gian hủy
  • Trạng thái phiếu trước khi hủy
  • Các dữ liệu đã rollback
• Hủy phiếu mua:
  • Nếu phiếu mua chưa nhập kho: chỉ chuyển trạng thái sang Đã hủy.
  • Nếu phiếu mua đã nhập kho: hệ thống cần rollback tồn kho, giá trị tồn kho và công nợ phải trả đã phát sinh.
  • Nếu phiếu mua đã thanh toán: không xóa giao dịch thanh toán, mà ghi nhận khoản cần hoàn tiền/cấn trừ/công nợ âm với nhà cung cấp.
• Hủy phiếu bán:
  • Nếu phiếu bán chưa xuất kho: trả lại phần hàng đã giữ cho khách về tồn kho khả dụng.
  • Nếu phiếu bán đã xuất kho: hệ thống cần rollback tồn kho, giá vốn, doanh thu và công nợ phải thu.
  • Nếu phiếu bán đã thu tiền: không xóa giao dịch thu tiền, mà ghi nhận khoản cần hoàn tiền/cấn trừ/công nợ âm với khách hàng.
  • Nếu phiếu bán mới xuất một phần: phần chưa xuất được trả về tồn khả dụng, phần đã xuất cần được xử lý như hàng trả lại hoặc nghiệp vụ điều chỉnh.
• Sau khi phiếu đã hủy:
  • Không được nhập kho/xuất kho tiếp.
  • Không được cập nhật thanh toán/thu tiền trực tiếp trên phiếu đã hủy.
  • Chỉ được xử lý các khoản tiền liên quan thông qua nghiệp vụ điều chỉnh/cấn trừ/hoàn tiền.

flowchart TD
    A[Người dùng bấm hủy phiếu] --> B[Nhập lý do hủy và chứng từ đính kèm]
    B --> C{Loại phiếu?}

    C -->|Phiếu mua| D{Đã nhập kho chưa?}
    D -->|Chưa| E[Chuyển phiếu mua sang Đã hủy]
    D -->|Rồi| F[Rollback phiếu mua]
    F --> F1[Giảm tồn kho đã nhập]
    F --> F2[Giảm giá trị tồn kho]
    F --> F3[Đảo công nợ phải trả]

    F --> G{Đã thanh toán NCC chưa?}
    G -->|Chưa| H[Hoàn tất hủy phiếu mua]
    G -->|Rồi| I[Ghi nhận hoàn tiền, cấn trừ hoặc công nợ âm với NCC]
    I --> H
    E --> H

    C -->|Phiếu bán| J{Đã xuất kho chưa?}
    J -->|Chưa| K[Trả hàng đã giữ cho khách về tồn kho khả dụng]
    K --> L[Chuyển phiếu bán sang Đã hủy]

    J -->|Rồi| M[Rollback phiếu bán]
    M --> M1[Tăng lại tồn kho vật lý hoặc ghi nhận hàng trả về]
    M --> M2[Đảo giá vốn]
    M --> M3[Đảo doanh thu]
    M --> M4[Đảo công nợ phải thu]

    M --> N{Đã thu tiền khách chưa?}
    N -->|Chưa| O[Hoàn tất hủy phiếu bán]
    N -->|Rồi| P[Ghi nhận hoàn tiền, cấn trừ hoặc công nợ âm với khách hàng]
    P --> O
    L --> O

    H --> Q[Lưu lịch sử hủy và dữ liệu rollback]
    O --> Q
    Q --> R[Khóa phiếu đã hủy, không cho nhập/xuất/thu/chi tiếp]

Note: Công ty quản lý toàn bộ quá trình nhập/xuất kho. Cửa hàng xăng dầu chỉ upload báo cáo bán hàng và xem tồn kho cửa hàng của mình (xem tiếp ở phần quản lý cửa hàng).

Quản lý cửa hàng

• Mỗi cửa hàng xăng dầu sẽ được cấp 1 account trên phần mềm.
• User bình thường thuộc cửa hàng chỉ thấy được các chức năng đơn giản:
  • Upload báo cáo bán hàng hằng ngày.
  • Xem tồn kho cửa hàng của mình.
• Các thông tin tổng hợp như doanh thu, lợi nhuận, chi phí, tiền chuyển về, lãi/lỗ chỉ dành cho CEO/Giám đốc/BOD hoặc user có quyền cao hơn.
• Cửa hàng không tự tạo phiếu mua/bán, không quản lý lô thủ công; các nghiệp vụ đó do công ty quản lý.

Luồng sử dụng của cửa hàng

• Cửa hàng đăng nhập vào hệ thống.
• Chọn file báo cáo bán hàng từ phần mềm hiện tại của cửa hàng.
• Bấm gửi báo cáo.
• Hệ thống xử lý file để lấy:
  • Số lượng xăng bán ra.
  • Giá bán.
  • Doanh thu.
  • Số tiền cửa hàng đã chuyển về.
• Hệ thống tự động cập nhật tồn kho cửa hàng.
• User cửa hàng có thể xem tồn kho hiện tại của cửa hàng mình.

Upload báo cáo bán hàng hằng ngày

• Có 4 cửa hàng xăng dầu đang sử dụng 3 phần mềm khác nhau.
• Hệ thống cần cho phép upload file báo cáo từ các phần mềm này.
• File báo cáo dùng để cập nhật dữ liệu bán hàng hằng ngày.
• Nếu file có nhiều mức giá bán trong ngày, hệ thống cần ghi nhận rõ từng mức giá.

Tồn kho cửa hàng

• Khi cửa hàng nhập hàng từ công ty, tồn kho cửa hàng tăng.
• Khi cửa hàng gửi báo cáo bán hàng hằng ngày, tồn kho cửa hàng giảm.
• Hệ thống tự tính:
  • Số lượng tồn kho.
  • Giá trị tồn kho.
  • Giá nhập của hàng tồn.
• User cửa hàng chỉ được xem tồn kho của cửa hàng mình.

Báo cáo doanh thu, lợi nhuận và chi phí cửa hàng

• Phần này dành cho CEO/Giám đốc/BOD hoặc user có quyền cao hơn.
• Hệ thống cần tổng hợp:
  • Doanh thu theo ngày/tháng.
  • Số lượng bán ra.
  • Giá bán.
  • Giá nhập.
  • Lợi nhuận gộp.
  • Chi phí cửa hàng.
  • Lợi nhuận thực.
• Chi phí cửa hàng bao gồm:
  • Mặt bằng.
  • Điện nước.
  • Bảo trì sửa chữa.
  • Lương.
• Nếu trong ngày có nhiều mức giá bán khác nhau, báo cáo cần thể hiện rõ để tính doanh thu/lợi nhuận đúng.

Đối soát tiền cửa hàng chuyển về

• Phần này dành cho CEO/Giám đốc/BOD hoặc user có quyền cao hơn.
• Báo cáo cửa hàng có số tiền phải chuyển về trong ngày.
• Kế toán/tài chính ghi nhận số tiền thực nhận.
• Hệ thống tính chênh lệch:
  • Đã chuyển đủ.
  • Còn thiếu.
  • Chuyển dư.

Quản lý vận tải

• Doanh nghiệp đang vận hành vận tải và có hơn 20 đầu xe, chạy tuyến Bắc - Nam.
• Phân hệ vận tải chỉ quản trị chung về chuyến xe, không cần quản lý chi tiết mặt hàng, khối lượng hoặc trọng lượng hàng vận chuyển.

Quản lý tài xế

• Quản lý danh sách tài xế và thông tin tài xế.
• Mỗi tài xế cần có các thông tin:
  • Họ tên.
  • CCCD.
  • GPLX.
  • Ngày sinh.
  • Ngày bắt đầu làm việc.
  • Ngày kết thúc làm việc nếu có.
  • Trạng thái: đang làm, tạm dừng, đã nghỉ.
• Tài xế có thể vào hệ thống để xem:
  • Chuyến xe sắp chạy.
  • Chuyến xe đang chạy.
  • Chuyến xe đã hoàn thành.
• Tính năng đang được ghi nhận từ EasyNote: tài xế bấm Start khi bắt đầu chuyến và bấm Dừng khi kết thúc chuyến.
  • Cần xác nhận: đây là ghi chú nội bộ vì flow này có thể quá thủ công, cần hỏi lại khách hàng có thật sự muốn tài xế thao tác trực tiếp trên app hay để điều phối cập nhật thời gian thực tế.
  • Nếu giữ tính năng này, hệ thống sẽ dùng thời gian start/dừng để thống kê chuyến xe mất bao lâu và so sánh với các chuyến tương tự.
• Nếu một chuyến xe có 2 tài xế thì mặc định lương tài xế được chia 2.
• Hệ thống cần hiển thị được doanh thu của tài xế theo tháng và theo chuyến.

Quản lý xe

• Quản lý danh sách xe và biển số xe.
• Mỗi xe có thể được gán mặc định với một tài xế.
• Mỗi xe cần có các thông tin:
  • Biển số.
  • Tài xế mặc định.
  • Thời gian kiểm định xe.
  • Giấy phép đi đường.
  • Odo hiện tại.
  • Tổng số chuyến.
  • Tổng doanh thu.
  • Tổng chi phí.
• Hệ thống cần theo dõi các mốc gần nhất của xe:
  • Lần bảo dưỡng gần nhất.
  • Lần thay nhớt gần nhất.
  • Lần bơm dầu gần nhất.
  • Lần thay lốp gần nhất.

Định mức chuyến

• Các chuyến/tuyến cố định có thể được cài đặt trước.
• Ví dụ: TP.HCM đi Hà Nội.
• Mỗi định mức chuyến cần có:
  • Điểm đi.
  • Điểm đến.
  • Số KM.
  • Lương tài xế dự kiến.
  • Chi phí xăng dầu dự kiến.
  • Phí VETC dự kiến.
  • Doanh thu dự kiến.
• Định mức chuyến có thể được cập nhật bởi Admin.
• Khi tạo chuyến xe thực tế, hệ thống có thể lấy dữ liệu từ định mức chuyến để giảm thao tác nhập liệu và làm cơ sở so sánh sau chuyến.

Tạo và điều phối chuyến xe

• Bộ phận kinh doanh tạo chuyến xe.
• Khi tạo chuyến, người dùng nhập/chọn:
  • Điểm đi.
  • Điểm đến.
  • Các điểm dừng giữa chặng nếu có.
  • Ngày và giờ xuất phát.
  • Xe.
  • Tài xế chính.
  • Tài xế phụ nếu có.
  • Khách hàng vận tải nếu có.
  • Doanh thu dự kiến nếu có.
• Chuyến xe sau khi tạo sẽ gửi tới bộ phận điều phối.
• Điều phối giao chuyến cho tài xế và báo xe thủ công.
• Chuyến xe có thể có nhiều điểm dừng để bỏ hàng hoặc lên hàng, nhưng hệ thống không cần quản lý chi tiết mặt hàng/khối lượng/trọng lượng.

Kết thúc chuyến và cập nhật thực tế

• Sau khi chuyến xe kết thúc, điều phối cần cập nhật dữ liệu thực tế.
• Các thông tin cần cập nhật:
  • Thời gian kết thúc chuyến.
  • Doanh thu thực tế nếu khác doanh thu dự kiến.
  • Các điểm dừng phát sinh nếu có.
  • Ghi chú phát sinh trong chuyến.
• Nếu chuyến xe chạy thêm điểm dừng và phát sinh thêm doanh thu, điều phối cần cập nhật doanh thu thực tế.
• Dữ liệu thực tế được dùng để:
  • So sánh với định mức chuyến.
  • Tính doanh thu chuyến.
  • Tính chi phí chuyến.
  • Tính lợi nhuận thực của chuyến.

Chi phí vận tải

• Chi phí vận tải có thể phát sinh trong hoặc sau chuyến xe.
• Khi tạo chi phí vận tải, người dùng cần chọn chuyến xe liên quan nếu có.
• Các loại chi phí vận tải gồm:
  • Lương tài xế.
  • Phí VETC.
  • Xăng dầu.
  • Rửa xe.
  • Ăn uống.
  • Vá xe.
  • Chi phí ngoài khác.
• Chi phí cần đi qua quy trình duyệt tương tự phần chi phí chung của hệ thống:
  • Tạo chi phí.
  • Đính kèm hóa đơn/chứng từ nếu có.
  • Nộp duyệt.
  • Sau khi được duyệt, chi phí mới được tính vào tổng chi phí và lợi nhuận thực.
• VETC có thể được nhập thủ công trước, sau này có thể tích hợp để tự động lấy dữ liệu từ hệ thống VETC mỗi ngày hoặc sau mỗi chuyến.
• Một số chi phí có loại Phải thu, nghĩa là công ty đã chi trước nhưng cần thu lại từ tài xế.
  • Ví dụ: ứng lương, phạt chuyến, khoản tài xế phải hoàn lại.
  • Các khoản này sẽ được ghi nhận để trừ/cấn trừ với tài xế.

Bảo dưỡng xe

• Quản lý danh sách garage bảo dưỡng/sửa chữa.
• Khi tạo bảo dưỡng, người dùng cần nhập:
  • Xe.
  • Garage.
  • Hạng mục bảo dưỡng/sửa chữa.
  • Số tiền.
  • Ngày bảo dưỡng.
  • Chứng từ/hình ảnh đính kèm nếu có.
• Hệ thống cần nhắc lịch bảo dưỡng theo KM:
  • > 5.000 KM - cần bơm dầu.
  • > 20.000 KM - cần thay nhớt.
  • > 40.000 KM - cần thay lọc nhớt.
• Có thể dựa vào số chuyến xe đã đi để cộng dồn số KM và nhắc lịch bảo dưỡng.
• Cho phép sai số thực tế khoảng 50-100 KM.
• Odo của xe được cập nhật thủ công định kỳ khoảng 2-3 ngày/lần.
• Chi phí bảo dưỡng/sửa chữa sẽ liên kết về tài chính để tính tổng chi phí và công nợ garage nếu chưa thanh toán.

Công nợ, doanh thu và báo cáo vận tải

• Hệ thống cần theo dõi:
  • Doanh thu từng chuyến xe.
  • Chi phí từng chuyến xe.
  • Lợi nhuận thực từng chuyến xe.
  • Công nợ khách hàng vận tải.
  • Công nợ garage bảo dưỡng/sửa chữa.
  • Khoản phải thu từ tài xế nếu có chi phí loại Phải thu.
• Báo cáo vận tải cần xem được theo:
  • Ngày.
  • Tháng.
  • Khoảng ngày.
  • Xe.
  • Tài xế.
  • Khách hàng.
• Chủ doanh nghiệp có thể xem:
  • Xe nào chạy bao nhiêu chuyến.
  • Doanh thu và chi phí từng xe.
  • Tài xế nào chạy bao nhiêu chuyến.
  • Doanh thu của tài xế theo tháng hoặc theo chuyến.
  • Chuyến nào lời/lỗ.

Quản lý tài chính

Chủ yếu quản lý các phần sau:

• Công nợ phải thu
  • Theo dõi khách hàng/cửa hàng còn nợ bao nhiêu.
  • Công nợ phát sinh từ phiếu bán/phiếu xuất kho.
  • Ghi nhận thu tiền một phần hoặc toàn bộ.
  • Theo dõi công nợ quá hạn.
• Công nợ phải trả
  • Theo dõi công ty đang nợ nhà cung cấp bao nhiêu.
  • Công nợ phát sinh từ phiếu mua/phiếu nhập kho.
  • Ghi nhận thanh toán một phần hoặc toàn bộ.
  • Theo dõi khoản phải trả đến hạn/quá hạn.
• Thu/chi tiền
  • Ghi nhận tiền khách hàng/cửa hàng chuyển về.
  • Ghi nhận tiền công ty thanh toán cho nhà cung cấp.
  • Ghi nhận các khoản chi khác như vận tải, bảo dưỡng, lương tài xế, phí cầu đường.
  • Đối soát số tiền phải thu với số tiền thực nhận.
• Giá trị tồn kho và giá vốn
  • Theo dõi số lượng tồn kho và giá trị tồn kho.
  • Khi nhập kho, cập nhật giá trị hàng tồn.
  • Khi xuất kho, giảm tồn kho và ghi nhận giá vốn.
  • Làm cơ sở tính lãi/lỗ theo từng đợt bán, cửa hàng hoặc khách hàng.
• Dòng tiền mua - nhập - bán - xuất - thu
  • Nên có một luồng tài chính xuyên suốt:
    • Mua hàng → phát sinh dự kiến phải trả.
    • Nhập kho → xác nhận giá trị hàng tồn và công nợ phải trả.
    • Bán hàng → phát sinh dự kiến phải thu.
    • Xuất kho → xác nhận doanh thu/công nợ phải thu và giảm tồn kho.
    • Thu tiền → giảm phải thu, tăng tiền.
    • Thanh toán nhà cung cấp → giảm phải trả, giảm tiền.
  • Đây là xương sống để xem công ty đang kẹt tiền ở đâu: tồn kho, khách nợ, cửa hàng chưa nộp, hay nhà cung cấp đến hạn trả.

Nguồn phát sinh tài chính

Phân hệ tài chính không nhập lại toàn bộ dữ liệu nghiệp vụ từ đầu, mà nhận các phát sinh từ các module khác trong hệ thống.

• Từ Quản lý xăng dầu:
  • Phiếu mua phát sinh khoản phải trả dự kiến cho nhà cung cấp.
  • Phiếu nhập kho xác nhận giá trị hàng tồn kho và công nợ phải trả.
  • Phiếu bán phát sinh khoản phải thu dự kiến từ khách hàng/cửa hàng.
  • Phiếu xuất kho xác nhận doanh thu, giá vốn và công nợ phải thu.
  • Hủy phiếu/rollback sẽ tạo các phát sinh điều chỉnh tương ứng.
• Từ Quản lý cửa hàng:
  • Báo cáo bán hàng hằng ngày phát sinh doanh thu cửa hàng.
  • Số tiền cửa hàng chuyển về dùng để đối soát với doanh thu phải nộp.
  • Chi phí cửa hàng được dùng để tính lợi nhuận thực của cửa hàng.
  • Tồn kho cửa hàng được dùng để tính giá trị hàng tồn.
• Từ Quản lý vận tải:
  • Doanh thu chuyến xe.
  • Chi phí chuyến xe.
  • Chi phí bảo dưỡng/sửa chữa.
  • Công nợ khách hàng vận tải.
  • Công nợ garage, tài xế hoặc các bên liên quan nếu có.
• Từ import sao kê ngân hàng:
  • Giao dịch tiền vào.
  • Giao dịch tiền ra.
  • Số dư theo từng tài khoản ngân hàng.
  • Dữ liệu dùng để đối soát thanh toán/thu tiền với phiếu mua, phiếu bán, chi phí và công nợ.

Import sao kê ngân hàng và đối soát giao dịch

Phần này dùng để đưa dòng tiền thực tế từ ngân hàng vào hệ thống, sau đó kế toán đối soát các giao dịch đó với phiếu mua, phiếu bán, chi phí hoặc công nợ liên quan.

Mục tiêu là hệ thống biết được:

• Tiền thật đã vào/ra tài khoản nào.
• Khoản tiền đó thuộc khách hàng, cửa hàng, nhà cung cấp hoặc khoản chi phí nào.
• Khoản tiền đó đang thanh toán cho chứng từ nào.
• Sau đối soát, công nợ và trạng thái thanh toán được cập nhật đúng.

Quy trình tổng quát

• Kế toán chọn tài khoản ngân hàng của công ty.
• Kế toán upload file sao kê ngân hàng.
• Hệ thống đọc từng dòng giao dịch trong file.
• Mỗi dòng giao dịch được lưu thành một Payment Transaction.
• Hệ thống phân loại giao dịch:
  • Tiền vào.
  • Tiền ra.
• Hệ thống thử nhận diện đối tượng liên quan dựa trên:
  • Số tài khoản ngân hàng.
  • Nội dung chuyển khoản.
  • Tên nhận diện chuyển khoản đã cấu hình cho khách hàng/nhà cung cấp.
• Kế toán kiểm tra lại gợi ý của hệ thống.
• Kế toán chọn chứng từ cần đối soát.
• Hệ thống cập nhật công nợ, trạng thái thanh toán và số dư ngân hàng.

Payment Transaction

Mỗi dòng sao kê sau khi import cần được lưu thành một giao dịch riêng, bao gồm:

• Tài khoản ngân hàng của công ty.
• Ngày giao dịch.
• Mã giao dịch nếu có.
• Loại giao dịch:
  • Tiền vào.
  • Tiền ra.
• Số tiền giao dịch.
• Tài khoản nguồn hoặc tài khoản nhận.
• Tên người chuyển/người nhận nếu file sao kê có.
• Nội dung chuyển khoản.
• Số dư sau giao dịch nếu file sao kê có.
• Trạng thái đối soát:
  • Chưa đối soát
  • Đã gợi ý đối tượng
  • Đã đối soát một phần
  • Đã đối soát đủ
  • Không xác định

Đối soát tiền vào

Áp dụng khi khách hàng/cửa hàng chuyển tiền về công ty.

• Hệ thống nhận diện giao dịch tiền vào.
• Hệ thống gợi ý khách hàng/cửa hàng liên quan.
• Kế toán mở giao dịch đó và thấy danh sách khoản phải thu:
  • Phiếu bán chưa thu tiền.
  • Phiếu bán thu tiền một phần.
  • Khoản tiền cửa hàng phải chuyển về theo báo cáo hằng ngày.
• Kế toán tick một hoặc nhiều chứng từ để đối soát.
• Sau khi xác nhận:
  • Giao dịch được gắn với chứng từ.
  • Công nợ phải thu giảm.
  • Phiếu bán chuyển sang Thu tiền một phần hoặc Đã thu tiền.
  • Nếu khách chuyển dư, công nợ có thể thành số âm để cấn trừ sau.

Ví dụ:

• Khách A đang nợ:
  • Phiếu bán PB001: 300.000.000đ
  • Phiếu bán PB002: 200.000.000đ
• Khách A chuyển khoản: 500.000.000đ
• Kế toán import sao kê.
• Hệ thống gợi ý giao dịch này thuộc khách A.
• Kế toán tick PB001 và PB002.
• Sau đối soát:
  • PB001: Đã thu tiền
  • PB002: Đã thu tiền
  • Công nợ khách A giảm 500.000.000đ
  • Số dư tài khoản ngân hàng tăng 500.000.000đ

Đối soát tiền ra

Áp dụng khi công ty thanh toán cho nhà cung cấp hoặc chi trả chi phí.

• Hệ thống nhận diện giao dịch tiền ra.
• Hệ thống gợi ý nhà cung cấp hoặc loại chi phí liên quan.
• Kế toán mở giao dịch đó và thấy danh sách khoản phải trả:
  • Phiếu mua chưa thanh toán.
  • Phiếu mua thanh toán một phần.
  • Chi phí đã duyệt nhưng chưa chi.
• Kế toán tick một hoặc nhiều chứng từ để đối soát.
• Sau khi xác nhận:
  • Giao dịch được gắn với chứng từ.
  • Công nợ phải trả giảm.
  • Phiếu mua chuyển sang Thanh toán một phần hoặc Đã thanh toán.
  • Nếu là chi phí, khoản chi phí được ghi nhận đã chi.
  • Nếu công ty chuyển dư, công nợ nhà cung cấp có thể thành số âm để cấn trừ sau.

Ví dụ:

• Công ty đang nợ Petrolimex:
  • Phiếu mua PM001: 800.000.000đ
• Công ty chuyển khoản cho Petrolimex: 500.000.000đ
• Kế toán import sao kê.
• Hệ thống gợi ý giao dịch này thuộc Petrolimex.
• Kế toán tick PM001.
• Sau đối soát:
  • PM001: Thanh toán một phần
  • Công nợ phải trả Petrolimex còn 300.000.000đ
  • Số dư tài khoản ngân hàng giảm 500.000.000đ

Các trường hợp đặc biệt

Các trường hợp dưới đây là quy tắc triển khai đề xuất để đảm bảo đối soát an toàn, EasyNote chưa mô tả chi tiết từng case.

• Một giao dịch thanh toán cho nhiều phiếu.
  • Ví dụ khách chuyển 500.000.000đ để thanh toán 2-3 phiếu bán.
• Một phiếu được thanh toán bằng nhiều giao dịch.
  • Ví dụ khách chuyển trước 200.000.000đ, hôm sau chuyển thêm 300.000.000đ.
• Giao dịch chuyển dư.
  • Hệ thống ghi nhận công nợ âm.
  • Khoản âm dùng để cấn trừ phiếu sau hoặc xử lý hoàn tiền.
• Giao dịch không nhận diện được.
  • Kế toán chọn thủ công khách hàng/nhà cung cấp/loại chi phí.
• Giao dịch import trùng.
  • Hệ thống cần cảnh báo và không import trùng nếu trùng mã giao dịch/ngày/số tiền/tài khoản/nội dung.
• Giao dịch đối soát sai.
  • Cho phép hủy đối soát.
  • Khi hủy đối soát, công nợ và trạng thái chứng từ quay về trạng thái trước đó.
  • Hệ thống lưu lịch sử thao tác hủy đối soát.

Kết quả sau đối soát

• Cập nhật số dư tài khoản ngân hàng.
• Cập nhật công nợ phải thu/phải trả.
• Cập nhật trạng thái phiếu mua/phiếu bán/chi phí.
• Lưu lịch sử đối soát:
  • Ai import sao kê.
  • Ai đối soát.
  • Thời gian đối soát.
  • Giao dịch ngân hàng nào.
  • Gắn với chứng từ nào.
  • Số tiền đối soát bao nhiêu.

Tóm tắt luồng đối soát:

• Kế toán import sao kê theo tài khoản ngân hàng của công ty.
• Mỗi dòng sao kê được lưu thành một Payment Transaction.
• Hệ thống gợi ý khách hàng, cửa hàng, nhà cung cấp hoặc chi phí liên quan dựa trên số tài khoản/nội dung chuyển khoản/tên nhận diện.
• Kế toán kiểm tra và tick phiếu mua, phiếu bán hoặc khoản chi phí cần đối soát.
• Sau khi xác nhận, hệ thống cập nhật trạng thái thanh toán, công nợ và số dư tài khoản.

flowchart TD
    A[Kế toán chọn tài khoản ngân hàng] --> B[Upload file sao kê]
    B --> C[Hệ thống đọc từng dòng giao dịch]
    C --> D[Tạo Payment Transaction]
    D --> E{Tiền vào hay tiền ra?}

    E -->|Tiền vào| F[Thử nhận diện khách hàng/cửa hàng]
    E -->|Tiền ra| G[Thử nhận diện nhà cung cấp/chi phí]

    F --> H{Nhận diện được?}
    G --> I{Nhận diện được?}

    H -->|Có| J[Gợi ý khách hàng/cửa hàng]
    H -->|Không| K[Kế toán chọn thủ công]
    I -->|Có| L[Gợi ý nhà cung cấp/chi phí]
    I -->|Không| K

    J --> M[Hiển thị phiếu bán/khoản phải thu]
    L --> N[Hiển thị phiếu mua/khoản chi phí]
    K --> K1{Chọn loại đối soát thủ công}
    K1 -->|Khoản phải thu| M
    K1 -->|Khoản phải trả/chi phí| N

    M --> O[Kế toán tick chứng từ cần thu]
    N --> P[Kế toán tick chứng từ cần chi]

    O --> Q{Số tiền giao dịch so với chứng từ?}
    P --> R{Số tiền giao dịch so với chứng từ?}

    Q -->|Đủ| S[Cập nhật Đã thu tiền]
    Q -->|Thiếu| T[Cập nhật Thu tiền một phần]
    Q -->|Dư| U[Ghi nhận công nợ âm/cấn trừ sau]

    R -->|Đủ| V[Cập nhật Đã thanh toán]
    R -->|Thiếu| W[Cập nhật Thanh toán một phần]
    R -->|Dư| X[Ghi nhận trả trước/công nợ âm với NCC]

    S --> Y[Cập nhật công nợ và số dư ngân hàng]
    T --> Y
    U --> Y
    V --> Y
    W --> Y
    X --> Y

    Y --> Z[Lưu lịch sử đối soát]

Công nợ âm/dương

Hệ thống cần cho phép công nợ có thể là số dương, bằng 0 hoặc số âm.

• Công nợ dương:
  • Khách hàng/cửa hàng còn nợ công ty.
  • Hoặc công ty còn nợ nhà cung cấp.
• Công nợ bằng 0:
  • Hai bên đã thanh toán đủ.
• Công nợ âm:
  • Khách hàng/cửa hàng chuyển dư tiền cho công ty.
  • Hoặc công ty chuyển dư tiền cho nhà cung cấp.
  • Khoản âm này có thể được cấn trừ vào chứng từ phát sinh sau hoặc xử lý hoàn tiền.

Ví dụ:

• Khách hàng A đang nợ công ty 400.000.000đ.
• Khách hàng A chuyển khoản 500.000.000đ.
• Sau khi đối soát:
  • Công nợ khách hàng A = -100.000.000đ.
  • Nghĩa là khách hàng A đang chuyển dư 100.000.000đ.
  • Khoản dư này có thể cấn trừ cho phiếu bán tiếp theo hoặc hoàn tiền cho khách.

Quản lý chi phí và duyệt chi phí

Phân hệ tài chính cần quản lý các khoản chi phí phát sinh trong quá trình vận hành công ty, cửa hàng và vận tải.

• Người dùng tạo khoản chi phí với các thông tin:
  • Loại chi phí.
  • Số tiền.
  • Ngày phát sinh.
  • Đối tượng liên quan nếu có: cửa hàng, chuyến xe, xe, tài xế, garage, nhà cung cấp.
  • Hóa đơn nếu có.
  • Chứng từ/hình ảnh đính kèm nếu có.
  • Ghi chú.
• Chi phí cần đi qua quy trình duyệt:
  • Tạo chi phí.
  • Nộp duyệt.
  • CEO/Giám đốc duyệt.
  • Sau khi được duyệt, chi phí mới được tính vào tổng chi phí và lợi nhuận thực.
• Hệ thống cần phân biệt:
  • Chi phí có hóa đơn.
  • Chi phí không có hóa đơn.
• Chi phí có thể đến từ:
  • Chi phí công ty chung.
  • Chi phí cửa hàng: mặt bằng, điện nước, bảo trì sửa chữa, lương.
  • Chi phí vận tải: lương tài xế, VETC, nhiên liệu, rửa xe, ăn uống, vá xe.
  • Chi phí bảo dưỡng/sửa chữa xe.

Lợi nhuận thực

Phân hệ tài chính cần tính được lợi nhuận thực, không chỉ dừng ở doanh thu hoặc lợi nhuận gộp.

• Doanh thu:
  • Doanh thu xăng dầu.
  • Doanh thu cửa hàng.
  • Doanh thu vận tải.
• Giá vốn:
  • Giá vốn xăng dầu theo lô hàng.
  • Giá vốn hàng bán của cửa hàng.
  • Chi phí trực tiếp của chuyến xe nếu có.
• Chi phí:
  • Chi phí công ty.
  • Chi phí cửa hàng.
  • Chi phí vận tải.
  • Chi phí bảo dưỡng/sửa chữa.
• Công thức cơ bản:
  • Lợi nhuận gộp = Doanh thu - Giá vốn
  • Lợi nhuận thực = Doanh thu - Giá vốn - Chi phí
• Hệ thống cần xem được lợi nhuận theo:
  • Ngày.
  • Tháng.
  • Khoảng ngày.
  • Công ty.
  • Cửa hàng.
  • Khách hàng.
  • Chuyến xe nếu áp dụng cho vận tải.

Số dư tài khoản ngân hàng và bộ lọc báo cáo

Hệ thống cần theo dõi số tiền thực tế đang có trong từng tài khoản ngân hàng của công ty. Đây là tiền thật trong ngân hàng, khác với công nợ và khác với lợi nhuận.

• Công ty có thể có nhiều tài khoản ngân hàng.
• Mỗi tài khoản ngân hàng cần theo dõi:
  • Tên ngân hàng.
  • Số tài khoản.
  • Chủ tài khoản.
  • Số dư hiện tại.
  • Danh sách giao dịch tiền vào/tiền ra.
• Mỗi lần import sao kê, hệ thống cập nhật:
  • Giao dịch tiền vào.
  • Giao dịch tiền ra.
  • Số dư sau giao dịch nếu file sao kê có.
• Người dùng có quyền cao có thể xem:
  • Tổng số dư tất cả tài khoản ngân hàng.
  • Số dư từng tài khoản.
  • Chi tiết giao dịch của từng tài khoản.

Ví dụ:

• Tài khoản VPBank còn 2.000.000.000đ.
• Tài khoản ACB còn 500.000.000đ.
• Tài khoản Vietcombank còn 1.000.000.000đ.
• Tổng tiền thật trong ngân hàng là 3.500.000.000đ.
• Tuy nhiên công ty vẫn có thể đang phải trả nhà cung cấp 2.000.000.000đ và khách hàng còn nợ công ty 1.000.000.000đ.

Báo cáo tài chính cần có bộ lọc:

• Theo ngày.
• Theo tháng.
• Theo khoảng ngày.
• Theo công ty.
• Theo cửa hàng nếu dữ liệu liên quan đến cửa hàng.
• Theo khách hàng/nhà cung cấp nếu xem công nợ.
• Theo tài khoản ngân hàng nếu xem dòng tiền thực tế.

Luồng dữ liệu giữa Quản lý xăng dầu và Quản lý tài chính

Tóm tắt luồng dữ liệu:

• Phiếu mua/nhập kho làm tăng tồn kho, giá trị tồn kho và công nợ phải trả nếu chưa thanh toán.
• Phiếu bán/xuất kho làm giảm tồn kho, ghi nhận giá vốn, doanh thu và công nợ phải thu nếu chưa thu tiền.
• Thu tiền hoặc thanh toán nhà cung cấp cập nhật công nợ và số dư tài khoản ngân hàng.
• Hủy phiếu/rollback tạo phát sinh điều chỉnh tương ứng, không xóa dữ liệu gốc.

flowchart TD
    A[Quản lý xăng dầu] --> B[Tạo phiếu mua]
    B --> C[Duyệt phiếu mua]
    C --> D[Tạo phiếu nhập kho]

    D --> E[Nhập xăng vào kho]
    E --> F[Cập nhật số lượng tồn kho]
    E --> G[Cập nhật giá trị tồn kho]
    E --> H[Phát sinh công nợ phải trả nhà cung cấp]

    H --> I[Quản lý tài chính]
    G --> I
    F --> A

    I --> J[Thanh toán nhà cung cấp]
    J --> K[Giảm công nợ phải trả]
    J --> L[Giảm tiền công ty]

    A --> M[Tạo phiếu bán]
    M --> N[Duyệt phiếu bán]
    N --> O[Tạo phiếu xuất kho]

    O --> P[Xuất xăng khỏi kho]
    P --> Q[Giảm số lượng tồn kho]
    P --> R[Ghi nhận giá vốn]
    P --> S[Ghi nhận doanh thu]
    P --> T[Phát sinh công nợ phải thu khách hàng/cửa hàng]

    Q --> A
    R --> I
    S --> I
    T --> I

    I --> U[Thu tiền khách hàng/cửa hàng]
    U --> V[Giảm công nợ phải thu]
    U --> W[Tăng tiền công ty]

    I --> X[Báo cáo dòng tiền]
    X --> Y[Tiền kẹt ở tồn kho]
    X --> Z[Tiền kẹt ở khách nợ/cửa hàng chưa nộp]
    X --> AA[Khoản phải trả nhà cung cấp đến hạn]

Trung tâm duyệt

EasyNote đã ghi nhận nhu cầu duyệt phiếu mua, phiếu bán, chi phí và có thao tác tick nhiều item/duyệt tất cả. Trung tâm duyệt dưới đây là chuẩn hóa đề xuất để gom các việc chờ duyệt vào một nơi.

• Các loại chứng từ cần đưa vào trung tâm duyệt:
  • Phiếu mua hàng.
  • Phiếu bán hàng.
  • Chi phí công ty.
  • Chi phí cửa hàng.
  • Chi phí vận tải.
  • Chi phí bảo dưỡng/sửa chữa.
• Người duyệt có thể:
  • Xem danh sách chứng từ đang chờ duyệt.
  • Lọc theo công ty, loại chứng từ, ngày tạo, người tạo.
  • Xem chi tiết chứng từ trước khi duyệt.
  • Duyệt từng chứng từ.
  • Từ chối và nhập lý do từ chối.
  • Tick nhiều chứng từ để duyệt hàng loạt.
• Khi duyệt hàng loạt:
  • Hệ thống vẫn phải lưu lịch sử duyệt riêng cho từng chứng từ.
  • Nếu một chứng từ không hợp lệ, hệ thống cần báo rõ chứng từ nào lỗi và lý do.
  • Không được duyệt hàng loạt các chứng từ mà người dùng không có quyền xử lý.
• Hệ thống cần lưu lịch sử:
  • Người gửi duyệt.
  • Người duyệt/từ chối.
  • Thời gian xử lý.
  • Lý do từ chối nếu có.
  • Trạng thái trước và sau khi xử lý.

Import dữ liệu ban đầu 2026

Khách hàng có nhu cầu import dữ liệu năm 2026 vào hệ thống để bắt đầu vận hành trên nền dữ liệu hiện có.

• Danh sách ứng viên cần chốt với khách hàng trước khi triển khai import:
  • Danh sách công ty.
  • Danh sách người dùng/nhân sự.
  • Danh sách khách hàng.
  • Danh sách nhà cung cấp.
  • Danh sách kho.
  • Danh sách cửa hàng.
  • Danh sách sản phẩm xăng dầu.
  • Danh sách xe.
  • Danh sách tài xế.
  • Danh sách garage.
  • Tồn kho đầu kỳ.
  • Hàng đã bán nhưng chưa xuất nếu có.
  • Công nợ phải thu đầu kỳ.
  • Công nợ phải trả đầu kỳ.
  • Số dư tài khoản ngân hàng đầu kỳ.
  • Phiếu mua/bán/chuyến xe/chi phí lịch sử nếu cần.
• Khi import, hệ thống cần:
  • Có template dữ liệu để người dùng điền.
  • Kiểm tra lỗi dữ liệu trước khi import chính thức.
  • Báo rõ dòng nào lỗi, lỗi gì.
  • Không import trùng dữ liệu đã có.
  • Lưu lịch sử import: ai import, thời gian, file nào, kết quả bao nhiêu dòng thành công/thất bại.
• Dữ liệu import phải được gắn đúng công ty để đảm bảo dữ liệu của 2 công ty tách riêng.
• Các số liệu đầu kỳ như tồn kho, công nợ và số dư ngân hàng là cơ sở để hệ thống tính tiếp các phát sinh sau này.

Thông báo / nhắc việc

EasyNote đã ghi nhận trực tiếp một số nhu cầu thông báo/nhắc việc như nhắc bảo dưỡng theo KM và thông báo tới bộ phận kho sau khi phiếu bán được duyệt/xuất kho. Các nhắc việc khác bên dưới là đề xuất vận hành để người dùng biết việc cần xử lý, không chỉ xem báo cáo sau khi sự việc đã xảy ra.

• Nhắc việc duyệt:
  • Phiếu mua chờ duyệt.
  • Phiếu bán chờ duyệt.
  • Chi phí chờ duyệt.
• Nhắc việc cửa hàng:
  • Cửa hàng chưa gửi báo cáo bán hàng trong ngày.
  • Cửa hàng chuyển thiếu tiền so với báo cáo.
  • Cửa hàng có chênh lệch tồn kho bất thường nếu phát hiện được.
• Nhắc việc tài chính:
  • Công nợ phải thu quá hạn.
  • Công nợ phải trả sắp đến hạn.
  • Giao dịch sao kê chưa đối soát.
  • Giao dịch import bị lỗi hoặc nghi ngờ trùng.
• Nhắc việc kho/xăng dầu:
  • Tồn kho thấp.
  • Hàng đã bán nhưng chưa xuất lâu ngày.
  • Phiếu nhập/xuất chưa hoàn tất.
• Nhắc việc vận tải:
  • Xe sắp đến hạn bảo dưỡng.
  • Xe quá hạn bảo dưỡng.
  • Chuyến xe chưa cập nhật kết thúc.
  • Chi phí chuyến chưa nộp duyệt hoặc chưa được duyệt.
• Mỗi thông báo cần có:
  • Loại thông báo.
  • Công ty liên quan.
  • Đối tượng liên quan: phiếu, cửa hàng, xe, chuyến, khách hàng, nhà cung cấp.
  • Mức độ ưu tiên nếu cần.
  • Trạng thái: chưa đọc, đã đọc, đã xử lý.
  • Link/đường dẫn tới màn hình xử lý tương ứng.

AI CHATBOT

• Chatbot dùng để hỗ trợ chủ doanh nghiệp và người quản lý truy vấn nhanh dữ liệu trong hệ thống.
• Chatbot có thể trả lời các câu hỏi thống kê dựa trên dữ liệu đã có trong hệ thống.
• Chatbot chỉ trả lời dựa trên dữ liệu người dùng có quyền xem. Đây là nguyên tắc an toàn hệ thống được bổ sung khi diễn giải, không phải câu chữ EasyNote ghi trực tiếp.
• Chatbot không tự ý sửa dữ liệu nghiệp vụ như:
  • Tạo phiếu.
  • Duyệt phiếu.
  • Hủy phiếu.
  • Cập nhật công nợ.
  • Cập nhật thanh toán.
  • Tạo chi phí.
• Nếu câu hỏi thiếu thời gian hoặc phạm vi dữ liệu, chatbot cần hỏi lại hoặc dùng bộ lọc mặc định rõ ràng.

Ví dụ câu hỏi chatbot cần trả lời được:

• Xe biển số xx tháng vừa rồi chạy bao nhiêu chuyến?
• Xe biển số xx tháng vừa rồi doanh thu bao nhiêu, chi phí bao nhiêu, lời/lỗ bao nhiêu?
• Tài xế xx tháng vừa rồi chạy bao nhiêu chuyến?
• Cửa hàng xx tháng vừa rồi bán bao nhiêu lít xăng?
• Cửa hàng xx tháng vừa rồi lời hay lỗ?
• Cửa hàng xx hiện còn tồn kho bao nhiêu?
• Khách hàng xx hiện còn nợ bao nhiêu?
• Nhà cung cấp xx hiện công ty còn nợ bao nhiêu?
• Công ty xx tháng này doanh thu, chi phí, lợi nhuận thực là bao nhiêu?
• Hiện tiền đang kẹt nhiều nhất ở đâu: tồn kho, khách nợ, cửa hàng chưa chuyển tiền hay khoản phải trả?