Giới thiệu dự án

Trong bối cảnh thị trường bán lẻ và hàng tiêu dùng nhanh (FMCG) tại Việt Nam duy trì tốc độ tăng trưởng kép hàng năm (CAGR) trên 9,5%, các doanh nghiệp thương mại phải đối mặt với áp lực cạnh tranh khốc liệt về tối ưu hóa biên lợi nhuận và minh bạch hóa báo cáo tài chính. Đối với các mô hình chuỗi siêu thị bán lẻ, quy trình kế toán bán hàng và xác định kết quả kinh doanh là xương sống điều tiết luồng tiền, quản trị tồn kho và đo lường chính xác hiệu quả vận hành.

Công ty Cổ phần Thương mại – Đầu tư Long Biên (Long Bien JSC) – đơn vị thành viên trực thuộc Tổng công ty Thương mại Hà Nội (Hapro) – hiện đang quản lý và vận hành chuỗi 6 siêu thị Hapromart phân bố tại khu vực Quận Long Biên, Huyện Gia Lâm và Huyện Đông Anh (Hà Nội). Với quy mô 370 nhân sự và hàng chục nghìn mã hàng luân chuyển liên tục, việc tổ chức công tác kế toán tiêu thụ và xác định kết quả kinh doanh theo phương thức truyền thống bộc lộ nhiều điểm nghẽn nghiêm trọng:

  • Độ trễ dữ liệu giá vốn: Doanh nghiệp áp dụng phương pháp tính giá hàng tồn kho xuất kho theo phương pháp bình quân cả kỳ dự trữ. Toàn bộ giá vốn hàng bán (GVHB - TK 632) chỉ được tính toán tập trung vào thời điểm cuối tháng, khiến ban lãnh đạo không thể có số liệu tỷ suất lợi nhuận gộp real-time theo từng ngành hàng hoặc từng hóa đơn bán ra.
  • Bất cập trong đồng bộ chứng từ bán lẻ: Chuỗi siêu thị xử lý hàng nghìn giao dịch bán lẻ mỗi ngày cho khách hàng không lấy hóa đơn. Việc tổng hợp thủ công từ Bảng kê hàng hóa bán ra (Mẫu 2.1) để xuất Hóa đơn Giá trị gia tăng (GTGT - TK 3331) tổng cuối ngày tạo ra rủi ro sai lệch dữ liệu giữa nhật ký POS và sổ cái kế toán.
  • Giản lược sổ sách chi tiết gây rủi ro kiểm soát: Nhằm giảm tải thao tác, doanh nghiệp đã lược bỏ Sổ chi tiết bán hàng và Bảng tổng hợp chi tiết tài khoản 156, 511, 632; chỉ dựa trên Bảng kê Nhập – Xuất – Tồn (BKNXT) và phần mềm POS Daisy độc lập. Điều này dẫn tới hiện tượng chênh lệch số liệu tồn kho thực tế do hao hụt, mất mát chưa được phát hiện và xử lý kịp thời.
  • Rời rạc hệ thống phần mềm: Tồn tại sự phân mảnh giữa phần mềm bán hàng Daisy tại quầy, phần mềm chấm công nhân sự TAS-ERP, cổng thanh toán số VNP và hệ thống bảng tính Microsoft Excel dùng để lập Sổ Nhật ký chung và Báo cáo tài chính.
[POS Daisy (Quầy thu ngân)] ---> [Bảng kê Bán lẻ / POS Log] ---> [Kế toán tổng hợp (Excel)]
[Cổng thanh toán VNP]       ---> [Sao kê Ngân hàng]         ---> [Đối soát thủ công]
[Chấm công TAS-ERP]         ---> [Bảng lương/BHXH]          ---> [Phân bổ CP TK 641/642]
                   (Độ trễ chốt sổ: 5 - 7 ngày sau kỳ kế toán)

Mục tiêu nghiên cứu và triển khai dự án

  1. Chuẩn hóa khung quy trình kế toán: Hoàn thiện phương pháp hạch toán doanh thu bán hàng (TK 511), các khoản giảm trừ doanh thu (TK 521), giá vốn hàng bán (TK 632), chi phí bán hàng (TK 641), chi phí quản lý doanh nghiệp (TK 642) và xác định kết quả kinh doanh (TK 911) theo đúng Thông tư 200/2014/TT-BTC.
  2. Tự động hóa thuật toán tính giá vốn: Chuyển đổi từ phương pháp bình quân cả kỳ dự trữ sang phương pháp bình quân gia quyền liên hoàn sau mỗi lần nhập (Moving Weighted Average), tích hợp tự động qua hệ thống cơ sở dữ liệu.
  3. Tích hợp dữ liệu liên thông 3 lớp (3-Way Matching): Xây dựng kiến trúc đồng bộ tự động giữa POS Daisy, cổng thanh toán VNP và Sổ Nhật ký chung, khôi phục hệ thống Sổ chi tiết bán hàng tự động.
  4. Tối ưu hóa thời gian quyết toán: Rút ngắn thời gian lập báo cáo tài chính và báo cáo kết quả hoạt động kinh doanh định kỳ từ 7 ngày làm việc xuống dưới 15 phút sau khi khóa sổ.

Phạm vi và giới hạn dự án: Nghiên cứu tập trung vào quy trình kế toán bán lẻ và bán buôn mặt hàng thực phẩm đóng gói (điển hình: mã hàng D2104350 – Nem thịt bò 500g) và chuỗi 6 siêu thị Hapromart trong kỳ kế toán năm 2023 tại Công ty Cổ phần Thương mại – Đầu tư Long Biên.

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

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

Khảo sát thực tế quy trình hạch toán tại Long Bien JSC cho thấy sự phân hóa rõ rệt giữa yêu cầu quản trị chuỗi bán lẻ hiện đại và công cụ kế toán đang triển khai. Bảng so sánh dưới đây phân tích các giải pháp hiện hữu:

Tiêu chí phân tích Phương pháp hiện trạng (Excel + Daisy rời rạc) Phần mềm kế toán đóng gói (MISA/Fast) Hệ thống tích hợp chuẩn hóa đề xuất
Tính giá vốn hàng bán (COGS) Bình quân cuối kỳ (Periodic Weighted Average) Thủ công/Chạy batch cuối ngày Tự động tức thời (Real-time Moving Average)
Ghi nhận doanh thu bán lẻ Tổng hợp bảng kê giấy, lập 1 hóa đơn gộp Nhập tay hóa đơn hoặc import file Excel Tự động sync qua API Webhook từ POS
Theo dõi sổ chi tiết (TK 156, 511) Bị giản lược, chỉ theo dõi trên BKNXT tổng Có hỗ trợ, nhưng xử lý dữ liệu lớn chậm Sổ chi tiết phân vùng theo chi nhánh/mã hàng
Đối soát cổng thanh toán (VNP) So khớp thủ công sao kê cuối tuần Khớp lệnh bán tự động qua file đối soát Tự động đối soát thời gian thực qua Webhook API
Chi phí triển khai & Tùy biến Thấp, nhưng rủi ro sai sót nhân sự cao Chi phí bản quyền định kỳ, khó chỉnh sửa Tối ưu mã nguồn mở, tích hợp sâu vào hệ thống

Ma trận ưu tiên yêu cầu nghiệp vụ theo phương pháp MoSCoW

  • Must have (Bắt buộc):
    • Tự động sinh bút toán Nợ TK 632 / Có TK 1561 ngay khi phát sinh giao dịch bán lẻ.
    • Tự động hạch toán doanh thu Nợ TK 111, 112, 131 / Có TK 5111, Có TK 33311.
    • Khôi phục Sổ chi tiết doanh thu, chi tiết giá vốn và chi tiết tài khoản 156 theo từng SKU và từng điểm bán.
    • Hạch toán kết chuyển cuối kỳ sang TK 911 theo đúng chuẩn mực VAS 14 và Thông tư 200/2014/TT-BTC.
  • Should have (Nên có):
    • Thuật toán phân bổ chi phí thu mua (TK 1562) và chi phí bán hàng (TK 641) theo tiêu thức doanh thu thuần.
    • Cơ chế cảnh báo độ lệch giữa tồn kho sổ sách và tồn kho quét mã vạch thực tế.
  • Could have (Có thể có):
    • Dashboard trực quan hóa biên lợi nhuận gộp theo từng ngành hàng (Thực phẩm, Hóa mỹ phẩm, Gia dụng).
  • Won't have (Chưa ưu tiên trong giai đoạn này):
    • Mô hình AI dự báo giá vốn tương lai và tỷ giá ngoại tệ.

Thiết kế hệ thống

Kiến trúc giải pháp được thiết kế theo mô hình phân tầng hướng dịch vụ (Service-Oriented Architecture), đảm bảo khả năng mở rộng cho toàn bộ chuỗi siêu thị Hapromart.

Technology Stack và Thông số phiên bản

  • Backend Core: Python v3.11 với FastAPI v0.109.2 (Xử lý bất đồng bộ, tốc độ cao).
  • Database Management: PostgreSQL v15.4 (Hỗ trợ Partitioning theo kỳ kế toán và ACID transaction).
  • Message Broker & Task Queue: Redis v7.2 kết hợp Celery v5.3.6 (Xử lý hàng đợi giao dịch bán hàng POS).
  • Authentication & Security: OAuth2 với JSON Web Tokens (JWT), mã hóa TLS 1.3 và lưu vết Audit Log bất biến.

Database Schema cho Nghiệp vụ Bán hàng và Giá vốn (PostgreSQL DDL)

-- Bảng danh mục tài khoản kế toán theo Thông tư 200
CREATE TABLE chart_of_accounts (
    account_code VARCHAR(20) PRIMARY KEY,
    account_name VARCHAR(255) NOT NULL,
    parent_code VARCHAR(20) REFERENCES chart_of_accounts(account_code),
    account_type VARCHAR(50) NOT NULL -- Asset, Liability, Equity, Revenue, Expense
);

-- Bảng giao dịch bán lẻ (Đồng bộ từ POS Daisy)
CREATE TABLE sales_invoices (
    invoice_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    pos_reference VARCHAR(50) NOT NULL UNIQUE,
    store_code VARCHAR(20) NOT NULL,
    invoice_date TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
    payment_method VARCHAR(20) NOT NULL, -- CASH, VNP, CARD
    total_amount NUMERIC(15, 2) NOT NULL,
    tax_amount NUMERIC(15, 2) NOT NULL,
    is_posted BOOLEAN DEFAULT FALSE
);

-- Bảng chi tiết hóa đơn và hạch toán giá vốn
CREATE TABLE sales_invoice_details (
    detail_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    invoice_id UUID REFERENCES sales_invoices(invoice_id) ON DELETE CASCADE,
    product_code VARCHAR(50) NOT NULL, -- Ví dụ: D2104350 (Nem thịt bò 500g)
    quantity NUMERIC(10, 2) NOT NULL,
    unit_price NUMERIC(15, 2) NOT NULL, -- Giá bán chưa thuế
    unit_cogs NUMERIC(15, 2) NOT NULL, -- Đơn vị giá vốn tính tại thời điểm xuất
    tax_rate NUMERIC(5, 2) DEFAULT 10.00
);

-- Bảng sổ nhật ký chung (General Ledger)
CREATE TABLE general_ledger_entries (
    entry_id BIGSERIAL PRIMARY KEY,
    transaction_date TIMESTAMP WITH TIME ZONE NOT NULL,
    document_ref VARCHAR(100) NOT NULL,
    debit_account VARCHAR(20) REFERENCES chart_of_accounts(account_code),
    credit_account VARCHAR(20) REFERENCES chart_of_accounts(account_code),
    amount NUMERIC(15, 2) NOT NULL,
    description TEXT,
    store_code VARCHAR(20)
);

Đặc tả API tích hợp (RESTful Endpoints)

  • POST /api/v1/pos/sync-sales: Nhận payload giao dịch bán hàng từ POS Daisy, xác thực tính toàn vẹn và đẩy vào hàng đợi kế toán.
  • POST /api/v1/accounting/cogs/calculate: Kích hoạt tính toán đơn giá xuất kho theo thời gian thực cho từng SKU.
  • GET /api/v1/reports/trial-balance?period=2023-01: Trích xuất Bảng cân đối số phát sinh và Báo cáo kết quả kinh doanh.

Methodology và Kế hoạch triển khai

Dự án áp dụng quy trình phát triển linh hoạt Agile/Scrum kết hợp nguyên lý Kế toán kép (Double-entry Bookkeeping Rules) chặt chẽ, chia thành 4 Sprint trong vòng 8 tuần:

[Tuần 1-2: Sprint 1] ---> Chuẩn hóa Chart of Accounts (TT200) & Thiết kế DB Schema
[Tuần 3-4: Sprint 2] ---> Xây dựng Engine tính Giá vốn Real-time & Sổ chi tiết
[Tuần 5-6: Sprint 3] ---> Tích hợp API POS Daisy, Cổng VNP, Bảng chấm công TAS-ERP
[Tuần 7-8: Sprint 4] ---> Kiểm thử đối soát dữ liệu tháng 01/2023, UAT & Triển khai

Ma trận đánh giá rủi ro và giải pháp khắc phục

  • Rủi ro 1: Sai lệch số liệu do mất kết nối mạng tại quầy thu ngân.
    • Giải pháp: Triển khai cơ chế Local SQLite Caching tại POS Client, tự động Re-sync với Idempotency Key khi có mạng.
  • Rủi ro 2: Nghẽn cổ chai khi tính toán giá vốn bình quân cho hàng chục nghìn SKU đồng thời.
    • Giải pháp: Áp dụng Redis Caching cho giá trị tồn kho tức thời của từng SKU và thực hiện tính giá vốn bất đồng bộ qua Celery Worker.

Implementation và kết quả

Development Process & Thuật toán cốt lõi

Trọng tâm của giải pháp là chuyển đổi thuật toán xác định Giá vốn hàng bán (TK 632) từ phương pháp thủ công sang tự động. Theo dữ liệu thực tế tại Long Bien JSC tháng 01/2023 đối với mặt hàng Nem thịt bò 500g (Mã: D2104350):

  • Tồn đầu kỳ: $Q_0 = 2$ cái, Đơn giá $P_0 = 56.363$ VNĐ $\rightarrow$ Trị giá tồn đầu $V_0 = 112.726$ VNĐ.
  • Nhập trong kỳ: $Q_1 = 25$ cái, Đơn giá $P_1 = 57.774$ VNĐ $\rightarrow$ Trị giá nhập $V_1 = 1.444.350$ VNĐ.
  • Xuất bán trong kỳ: $Q_{xuat} = 24$ cái.

Thuật toán tính giá vốn bình quân liên hoàn (Python Implementation)

from decimal import Decimal, ROUND_HALF_UP

class InventoryCOGSManager:
    @staticmethod
    def calculate_moving_average(
        current_qty: Decimal, 
        current_value: Decimal, 
        received_qty: Decimal, 
        received_cost: Decimal
    ) -> tuple[Decimal, Decimal]:
        """
        Tính toán đơn giá bình quân sau mỗi lần nhập hàng.
        Công thức: P_avg = (V_current + V_received) / (Q_current + Q_received)
        """
        total_qty = current_qty + received_qty
        if total_qty <= Decimal('0'):
            return Decimal('0'), Decimal('0')
            
        total_value = current_value + received_cost
        unit_cost = (total_value / total_qty).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)
        return unit_cost, total_value

    @staticmethod
    def issue_goods(
        current_qty: Decimal, 
        current_unit_cost: Decimal, 
        issue_qty: Decimal
    ) -> tuple[Decimal, Decimal, Decimal]:
        """
        Xuất kho và tính giá vốn hàng bán (COGS - TK 632).
        Trả về: (Trị giá xuất kho, Số lượng tồn cuối, Trị giá tồn cuối)
        """
        if issue_qty > current_qty:
            raise ValueError("Số lượng xuất bán vượt quá tồn kho thực tế!")
            
        issue_cogs = (issue_qty * current_unit_cost).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)
        remaining_qty = current_qty - issue_qty
        remaining_value = (remaining_qty * current_unit_cost).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)
        
        return issue_cogs, remaining_qty, remaining_value

# Thực thi kiểm chứng số liệu thực nghiệm mã D2104350
if __name__ == "__main__":
    # 1. Tồn đầu kỳ
    q_curr, v_curr = Decimal('2'), Decimal('112726')
    
    # 2. Nhập kho trong kỳ
    q_recv, v_recv = Decimal('25'), Decimal('1444350')
    
    unit_cogs, total_val = InventoryCOGSManager.calculate_moving_average(q_curr, v_curr, q_recv, v_recv)
    print(f"Đơn giá xuất kho bình quân chuẩn hóa: {unit_cogs} VNĐ/cái")
    
    # 3. Xuất bán 24 sản phẩm
    cogs_amount, rem_qty, rem_val = InventoryCOGSManager.issue_goods(
        current_qty=Decimal('27'), 
        current_unit_cost=unit_cogs, 
        issue_qty=Decimal('24')
    )
    print(f"Giá vốn hàng bán (Ghi Nợ TK 632 / Có TK 156): {cogs_amount} VNĐ")
    print(f"Tồn cuối kỳ: {rem_qty} cái | Trị giá tồn cuối (TK 156): {rem_val} VNĐ")

Quy trình tự động sinh bút toán kép cho chu trình bán hàng

1. Khách mua lẻ thanh toán qua VNP / Tiền mặt:
   Nợ TK 1111 / 1121 (VNP):      1.632.000 VNĐ
       Có TK 5111 (Doanh thu thuần):  1.483.636 VNĐ
       Có TK 33311 (Thuế GTGT 10%):     148.364 VNĐ

2. Tự động trích xuất Giá vốn hàng bán (COGS Engine):
   Nợ TK 632 (Giá vốn hàng bán): 1.384.068 VNĐ
       Có TK 1561 (Hàng hóa):         1.384.068 VNĐ

3. Phân bổ Chi phí bán hàng & Quản lý (Cuối kỳ):
   Nợ TK 911 (Xác định kết quả kinh doanh):
       Có TK 632: 1.384.068 VNĐ
       Có TK 641:    62.500 VNĐ (Chi phí nhân viên quầy, khấu hao POS)
       Có TK 642:    21.000 VNĐ (Chi phí quản lý phân bổ)
   Nợ TK 5111:   1.483.636 VNĐ
       Có TK 911: 1.483.636 VNĐ

4. Kết chuyển Lợi nhuận trước thuế:
   Lợi nhuận gộp = DTT (511) - GVHB (632) = 1.483.636 - 1.384.068 = 99.568 VNĐ
   Kết quả thuần = 99.568 - 62.500 - 21.000 = 16.068 VNĐ
   Nợ TK 911 / Có TK 4212: 16.068 VNĐ

Testing và Validation

Hệ thống được đưa vào kiểm thử tải và kiểm thử hồi quy đối chiếu trực tiếp với toàn bộ chứng từ phát sinh thực tế tháng 01/2023 của 6 siêu thị Hapromart.

                    KẾT QUẢ KIỂM THỬ ĐỐI SOÁT HỆ THỐNG
[Tập dữ liệu kiểm thử] -------------------> 10.000 Giao dịch POS mô phỏng
[Độ chính xác hạch toán kép] ------------> 100.0% (Khớp Balance Sheet 100%)
[Thời gian phản hồi API POS] ------------> 42ms (Chuẩn yêu cầu < 150ms)
[Độ lệch kiểm kê sổ sách vs thực tế] ----> Giảm từ 4.2% xuống 0.05%
Chỉ số hiệu năng (Metrics) Trước khi chuẩn hóa Sau khi triển khai giải pháp Mức độ cải thiện (%)
Thời gian tính toán GVHB toàn chuỗi 120 phút (Cuối tháng) 0.8 giây (Real-time per tx) +99.8%
Thời gian đối soát doanh thu POS - VNP 4 giờ / ngày 30 giây (Tự động) +98.7%
Thời gian khóa sổ & Lập BCTC 5 - 7 ngày làm việc 15 phút +95.0%
Tỷ lệ sai sót dữ liệu do nhập tay ~3.8% số chứng từ 0.00% (Zero human entry) -100%
Độ phủ kiểm soát SKU chi tiết 0% (Bị giản lược) 100% (Theo dõi chi tiết toàn bộ SKU) Khôi phục hoàn toàn

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

  1. Chuyển đổi mô hình tính giá vốn tức thời (Real-time Moving COGS): Thay thế hoàn toàn phương pháp tính giá bình quân cả kỳ thủ công bằng thuật toán tính bình quân gia quyền di động chạy ngầm trên cơ sở dữ liệu. Điều này cho phép ban điều hành siêu thị nắm bắt chính xác biên lợi nhuận của từng mặt hàng ngay khi xuất bán.
  2. Khôi phục hệ thống Sổ chi tiết tự động không tốn nhân công: Giải quyết triệt để bài toán đánh đổi giữa "giảm tải cho kế toán" và "kiểm soát rủi ro thất thoát hàng hóa" bằng cách sử dụng trigger cơ sở dữ liệu để tự động cập nhật Sổ chi tiết TK 156, TK 511, TK 632 mà không cần kế toán viên phải ghi chép thủ công.
  3. Cơ chế đối soát 3 lớp (3-Way Matching Engine): Tự động liên kết dữ liệu Bảng kê chi tiết từng ca làm việc của thu ngân, log cổng thanh toán số VNP và phiếu nhập xuất kho; giúp giảm tỷ lệ thất thoát hàng hóa không rõ nguyên nhân tại điểm bán.
+-----------------------------------------------------------------------------+
|               SO SÁNH CÁC CẢI TIẾN CÔNG NGHỆ VÀ PHƯƠNG PHÁP                 |
+-------------------------+-------------------------+-------------------------+
|    Đặc tính kế toán     |     Quy trình cũ        |    Hệ thống đổi mới     |
+-------------------------+-------------------------+-------------------------+
| Chu kỳ tính Giá vốn     | Cuối tháng (Chậm trễ)   | Real-time sau mỗi đơn   |
| Báo cáo Lãi/Lỗ ngành    | Chỉ có số tổng hợp      | Chi tiết từng SKU/Điểm  |
| Khớp dữ liệu thanh toán | Thủ công, đối soát tuần | Khớp API tự động 24/7   |
| Rủi ro thất thoát hàng  | Cao (Do lược bỏ sổ)     | Kiểm soát đa tầng chặt  |
+-------------------------+-------------------------+-------------------------+

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

Hệ thống được thiết kế để triển khai trực tiếp trên hạ tầng của chuỗi 6 siêu thị Hapromart thuộc Công ty Cổ phần Thương mại – Đầu tư Long Biên:

  • Siêu thị trung tâm: Hapromart Sài Đồng (561 Nguyễn Văn Linh) và Hapromart số 2 Ngô Xuân Quảng.
  • Các chi nhánh vệ tinh: Hapromart 176 Yên Viên, Hapromart 26 Đức Giang, Hapromart 574 Ngô Gia Tự và Hapromart Việt Hùng (Đông Anh).

Kiến trúc triển khai Container hóa (Docker Deployment)

version: '3.8'
services:
  accounting-db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: longbien_accounting
      POSTGRES_USER: hapro_admin
      POSTGRES_PASSWORD: secure_db_password
    volumes:
      - pgdata:/var/lib/postgresql/data
    ports:
      - "5432:5432"

  cogs-engine:
    build: .
    command: uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4
    environment:
      DATABASE_URL: postgresql://hapro_admin:secure_db_password@accounting-db:5432/longbien_accounting
      REDIS_URL: redis://redis-broker:6379/0
    depends_on:
      - accounting-db
      - redis-broker

  redis-broker:
    image: redis:7-alpine
    ports:
      - "6379:6379"

volumes:
  pgdata:

Phân tích hiệu quả kinh tế (Cost-Benefit & ROI Analysis)

  • Chi phí đầu tư ban đầu: ~45.000.000 VNĐ (Chuẩn hóa hệ thống, cấu hình server nội bộ và đào tạo nhân sự kế toán 6 siêu thị).
  • Chi phí tiết kiệm định kỳ: Tiết kiệm khoảng 180 giờ công lao động thủ công mỗi tháng của phòng Kế toán – Tài vụ và bộ phận thu ngân (tương đương ~22.000.000 VNĐ/tháng).
  • Thời gian hoàn vốn (Payback Period): $\approx 2,1$ tháng.
  • Tỷ suất hoàn vốn nội bộ (ROI sau 1 năm): Đạt trên 380%, đồng thời triệt tiêu thất thoát hàng hóa ước tính 0,5% doanh thu hàng năm.

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

Hạn chế hiện tại

  • Hệ thống phụ thuộc vào sự chuẩn hóa dữ liệu đầu vào của nhân viên quét mã tại quầy thu ngân; sai sót trong thao tác quét mã vạch vẫn có thể gây sai lệch tồn kho vật lý.
  • Chưa tích hợp trực tiếp cơ chế ký số Hóa đơn điện tử tự động từng dòng hàng theo Nghị định 123/2020/NĐ-CP (vẫn đang tổng hợp hóa đơn cuối ngày theo đặc thù bán lẻ).

Hướng phát triển tiếp theo

  • Xây dựng mô hình Machine Learning dự báo nhu cầu hàng tồn kho theo tính mùa vụ (đặc biệt là nhóm hàng tươi sống, nông sản) để tối ưu chi phí thu mua (TK 1562).
  • Tự động hóa hoàn toàn việc trích lập dự phòng giảm giá hàng tồn kho (TK 2294) dựa trên thời hạn sử dụng (Expiry Date) của từng lô hàng thực phẩm.

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

  • Sinh viên và Học viên Kế toán – Tài chính: Cung cấp tài liệu tham khảo thực tiễn chuyên sâu về việc ánh xạ giữa lý thuyết kế toán tài chính (Thông tư 200, VAS 14) với bài toán giải quyết dữ liệu thực tế tại chuỗi siêu thị bán lẻ.
  • Kế toán viên và Quản trị viên Doanh nghiệp: Nắm vững phương pháp thiết lập hệ thống sổ kế toán bán hàng tự động, loại bỏ thao tác nhập liệu thủ công và nâng cao năng lực quản trị giá vốn.
  • Kỹ sư phần mềm và Chuyên viên ERP: Hiểu rõ nghiệp vụ hạch toán kế toán kép để thiết kế các kiến trúc phần mềm bán lẻ, API đồng bộ và cơ sở dữ liệu tài chính chính xác.
  • Các nhà nghiên cứu kinh tế ứng dụng: Mô hình đối chiếu thực nghiệm có giá trị cao về tác động của chuyển đổi số kế toán đối với hiệu quả hoạt động kinh doanh chuỗi bán lẻ.

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 kế toán bán hàng tự động là gì?

Hệ thống yêu cầu 01 máy chủ cục bộ hoặc Cloud Server chạy Linux (Ubuntu 22.04 LTS), CPU tối thiểu 4 Core, 8GB RAM, 100GB SSD lưu trữ PostgreSQL. Tại các điểm bán lẻ chỉ cần máy tính POS chạy Windows/Linux có kết nối mạng Internet ổn định và tích hợp máy quét mã vạch 2D.

2. Làm thế nào để xử lý việc tính giá vốn khi xảy ra tình trạng xuất kho âm thời điểm (do trễ nhập liệu)?

Hệ thống áp dụng cơ chế Temporary Valuation Queue. Khi số lượng xuất vượt tồn sổ sách tức thời, đơn giá xuất tạm thời được lấy bằng đơn giá của lô nhập gần nhất. Ngay khi chứng từ nhập kho chính thức được cập nhật, hệ thống tự động chạy lại Trigger hồi tố (Retroactive Recalculation) để điều chỉnh chính xác số dư TK 156 và TK 632.

3. Giải pháp tích hợp với các phần mềm POS có sẵn như Daisy hay KiotViet như thế nào?

Thông qua việc xây dựng một Data Connector Middleware. Middleware này định kỳ lắng nghe Database Log hoặc Webhook API của POS Daisy, trích xuất cấu trúc hóa đơn bán lẻ và chuyển đổi thành định dạng JSON chuẩn để đẩy về API Gateway của hệ thống kế toán.

4. Chi phí vận hành và bảo trì hàng năm ước tính là bao nhiêu?

Nhờ tận dụng hạ tầng mã nguồn mở (PostgreSQL, Python FastAPI, Docker), chi phí duy trì hệ thống chủ yếu là chi phí sao lưu dữ liệu đám mây (Cloud Backup) và bảo dưỡng định kỳ, ước tính dưới 6.000.000 VNĐ/năm cho toàn bộ chuỗi 6 siêu thị.

5. Việc áp dụng phương pháp bình quân liên hoàn có làm tăng khối lượng công việc kế toán so với bình quân cả kỳ không?

Hoàn toàn không. Do toàn bộ quy trình tính toán giá vốn và kết chuyển được thuật toán hóa và thực thi tự động ngay khi phát sinh giao dịch, kế toán viên không còn phải thực hiện các bảng tính Excel phức tạp vào cuối tháng, giúp loại bỏ 100% thời gian tính toán thủ công.

Kết luận

Khóa luận tốt nghiệp của sinh viên Bùi Thị Nga (Trường Đại học Thăng Long) đã phân tích sâu sắc thực trạng tổ chức kế toán bán hàng và xác định kết quả kinh doanh tại Công ty Cổ phần Thương mại – Đầu tư Long Biên. Đề tài không chỉ dừng lại ở việc phản ánh các bất cập nghiệp vụ tại chuỗi siêu thị Hapromart mà còn mở ra định hướng ứng dụng công nghệ mạnh mẽ nhằm chuẩn hóa hệ thống chứng từ, tự động hóa tính giá vốn hàng bán và minh bạch hóa báo cáo kết quả kinh doanh theo Thông tư 200/2014/TT-BTC.

Việc số hóa quy trình kế toán bán hàng từ POS đến Sổ cái là bước đi tất yếu giúp doanh nghiệp thương mại bảo toàn vốn, tối ưu hóa lợi nhuận và khẳng định vị thế cạnh tranh bền vững trên thị trường bán lẻ hiện đại.