Giới thiệu dự án

  • Context & industry statistics

    • Ngành công nghiệp thuốc lá tại Việt Nam có doanh thu trên 150 tỷ VND năm 2020, chiếm 10 % tổng doanh thu ngành FMCG.
    • Tỷ lệ nợ phải thu khách hàng trung bình 12 % doanh thu, gây áp lực thanh khoản cho doanh nghiệp.
  • Problem statement

    • Pain points:
      • Thiếu quy trình chuẩn hoá kế toán vốn bằng tiền (cash‑based accounting) và khoản phải thu khách hàng (accounts receivable).
      • Rủi ro sai sót trong phiếu thu/phiếu chi, dẫn đến chênh lệch ngân sách lên tới 3 %.
      • Khó khăn trong đánh giá khả năng thu hồi nợquản lý dòng tiền trong giai đoạn chuyển đổi số.
  • Project objectives

    1. Xây dựng công cụ kiểm kê tự động cho tiền mặt và tiền gửi.
    2. Phát triển module phân tích nợ phải thu dựa trên thuật toán K‑Means clustering.
    3. Đưa ra bảng chuẩn KPI để đo lường tính hiệu quả của quy trình kế toán.
  • Solution approach

    • Áp dụng Python 3.11, PostgreSQL 15, và FastAPI 0.110 để xây dựng hệ thống RESTful API cho việc nhập/kiểm tra chứng từ.
    • Sử dụng Pandas 2.2scikit‑learn 1.5 để thực hiện phân tích dữ liệuđịnh mức rủi ro.
    • Triển khai CI/CD với GitHub Actions, container hoá bằng Docker 24Kubernetes 1.28.
  • Expected outcomes

    • Giảm thời gian reconcile từ 3 ngày → <2 giờ.
    • Tăng độ chính xác trong ghi sổ từ 97 % → 99.8 %.
    • Nâng tỷ lệ thu hồi nợ từ 85 % → 93 % trong 6 tháng.
  • Scope & limitations

    • Scope: Áp dụng cho công ty TNHH MTV Thuốc lá Cửu Long, tập trung vào tài khoản TK 111, TK 112, TK 113, TK 131, TK 138.
    • Limitations: Không bao gồm kế toán thuế GTGTkế toán tài sản cố định (TSCĐ).

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

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

Current Solution Pros Cons
Sổ sách giấy & phần mềm Bravo (phiên bản 8.2) - Đã được triển khai trong 5 năm
- Tuân thủ Thông tư 200
- Thiếu tính năng tự động hoá
- Không hỗ trợ API, báo cáo thời gian thực
Excel‑based reconciliation - Dễ sử dụng cho nhân viên không IT - Dễ lỗi nhập liệu
- Không chuẩn hoá, không audit trail
  • Market research: Các giải pháp ERP của SAP S/4HANAOracle NetSuite cho ngành FMCG đã tích hợp cash‑based accountingAR analytics bằng AI, tuy nhiên chi phí triển khai > 500 tỷ VND.

  • User requirements (MoSCoW)

    • Must: Tự động nhập phiếu thu/chi, kiểm kê tiền mặt, báo cáo AR.
    • Should: Định mức rủi ro nợ, cảnh báo quá hạn.
    • Could: Tích hợp QR‑code cho chứng từ.
    • Won’t: Triển khai mô-đun kế toán thuế trong giai đoạn này.
  • Technical constraints

    • Hệ thống ngân hàng nội bộ chỉ hỗ trợ API qua ISO 20022.
    • Hạ tầng IT hiện tại: 2 máy chủ VMware ESXi 7, dung lượng RAM 64 GB, không có Kubernetes.
  • **Gap## Giới thiệu dự án

  • Context & industry statistics

    • Ngành công nghiệp thuốc lá tại Việt Nam có doanh thu trên 150 tỷ VND năm 2020, chiếm 10 % tổng doanh thu ngành FMCG.
    • Tỷ lệ nợ phải thu khách hàng trung bình 12 % doanh thu, gây áp lực thanh khoản cho doanh nghiệp.
  • Problem statement

    • Pain points:
      • Thiếu quy trình chuẩn hoá kế toán vốn bằng tiền (cash‑based accounting) và khoản phải thu khách hàng (accounts receivable).
      • Rủi ro sai sót trong phiếu thu/phiếu chi, dẫn đến chênh lệch ngân sách lên tới 3 %.
      • Khó khăn trong đánh giá khả năng thu hồi nợquản lý dòng tiền trong giai đoạn chuyển đổi số.
  • Project objectives

    1. Xây dựng công cụ kiểm kê tự động cho tiền mặt và tiền gửi.
    2. Phát triển module phân tích nợ phải thu dựa trên thuật toán K‑Means clustering.
    3. Đưa ra bảng chuẩn KPI để đo lường tính hiệu quả của quy trình kế toán.
  • Solution approach

    • Áp dụng Python 3.11, PostgreSQL 15, và FastAPI 0.110 để xây dựng hệ thống RESTful API cho việc nhập/kiểm tra chứng từ.
    • Sử dụng Pandas 2.2scikit‑learn 1.5 để thực hiện phân tích dữ liệuđịnh mức rủi ro.
    • Triển khai CI/CD với GitHub Actions, container hoá bằng Docker 24Kubernetes 1.28.
  • Expected outcomes

    • Giảm thời gian reconcile từ 3 ngày → <2 giờ.
    • Tăng độ chính xác trong ghi sổ từ 97 % → 99.8 %.
    • Nâng tỷ lệ thu hồi nợ từ 85 % → 93 % trong 6 tháng.
  • Scope & limitations

    • Scope: Áp dụng cho công ty TNHH MTV Thuốc lá Cửu Long, tập trung vào tài khoản TK 111, TK 112, TK 113, TK 131, TK 138.
    • Limitations: Không bao gồm kế toán thuế GTGTkế toán tài sản cố định (TSCĐ).

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

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

Current Solution Pros Cons
Sổ sách giấy & phần mềm Bravo (phiên bản 8.2) - Đã được triển khai trong 5 năm
- Tuân thủ Thông tư 200
- Thiếu tính năng tự động hoá
- Không hỗ trợ API, báo cáo thời gian thực
Excel‑based reconciliation - Dễ sử dụng cho nhân viên không IT - Dễ lỗi nhập liệu
- Không chuẩn hoá, không audit trail
  • Market research: Các giải pháp ERP của SAP S/4HANAOracle NetSuite cho ngành FMCG đã tích hợp cash‑based accountingAR analytics bằng AI, tuy nhiên chi phí triển khai > 500 tỷ VND.

  • User requirements (MoSCoW)

    • Must: Tự động nhập phiếu thu/chi, kiểm kê tiền mặt, báo cáo AR.
    • Should: Định mức rủi ro nợ, cảnh báo quá hạn.
    • Could: Tích hợp QR‑code cho chứng từ.
    • Won’t: Triển khai mô-đun kế toán thuế trong giai đoạn này.
  • Technical constraints

    • Hệ thống ngân hàng nội bộ chỉ hỗ trợ API qua ISO 20022.
    • Hạ tầng IT hiện tại: 2 máy chủ VMware ESXi 7, dung lượng RAM 64 GB, không có Kubernetes.
  • Gap analysis

    • Opportunity: Áp dụng microservice cho từng chức năng (cash, bank, AR) giúp scale độc lập.

Thiết kế hệ thống

  • Architecture diagram

  • Technology stack

Layer Technology Version
Backend FastAPI 0.110
Database PostgreSQL 15
Data processing Pandas 2.2
Machine learning scikit‑learn 1.5
Container Docker 24
Orchestration Kubernetes 1.28
CI/CD GitHub Actions latest
Frontend React 18
Authentication OAuth2 (JWT) 2.0
  • Database design (simplified)

    -- accounts table (cash, bank, AR)
    CREATE TABLE accounts (
        account_id   SERIAL PRIMARY KEY,
        account_code VARCHAR(10) NOT NULL,
        account_name VARCHAR(100) NOT NULL,
        account_type VARCHAR(20) CHECK (account_type IN ('cash','bank','ar'))
    );
    
    -- vouchers (phiếu thu/chi)
    CREATE TABLE vouchers (
        voucher_id   SERIAL PRIMARY KEY,
        voucher_no   VARCHAR(20) UNIQUE NOT NULL,
        date_issued  DATE NOT NULL,
        debit_acc_id INT REFERENCES accounts(account_id),
        credit_acc_id INT REFERENCES accounts(account_id),
        amount       NUMERIC(15,2) NOT NULL,
        description  TEXT,
        created_at   TIMESTAMP DEFAULT NOW()
    );
    
    -- receivables
    CREATE TABLE receivables (
        ar_id        SERIAL PRIMARY KEY,
        customer_id  INT NOT NULL,
        invoice_no   VARCHAR(30) NOT NULL,
        due_date     DATE NOT NULL,
        amount       NUMERIC(15,2) NOT NULL,
        status       VARCHAR(20) CHECK (status IN ('open','paid','overdue')),
        created_at   TIMESTAMP DEFAULT NOW()
    );
    
  • API endpoints (example)

    POST /api/v1/vouchers          # tạo phiếu thu/chi
    GET  /api/v1/vouchers/{id}     # chi tiết voucher
    POST /api/v1/ar/collect        # ghi nhận thu hồi nợ
    GET  /api/v1/ar/summary        # báo cáo AR tổng hợp
    POST /api/v1/analytics/risk    # tính risk score cho khách hàng
    
  • Security considerations

    • HTTPS/TLS 1.3 cho mọi giao tiếp.
    • JWT access token (expires 15 min) + refresh token (7 days).
    • Role‑based access: Kế toán (full CRUD), Quản lý (read‑only).
  • Performance requirements

    • Thời gian phản hồi API ≤ 200 ms cho truy vấn voucher.
    • Batch processing ≤ 5 min cho 100 k bản ghi AR.

Methodology

  • Development methodology: Scrum – 2‑week sprints, Sprint Review với bộ phận Kế toán.

  • Project timeline

    Milestone Target date Deliverable
    Sprint 0 – Setup môi trường 2024‑12‑01 Docker Compose, CI pipeline
    Sprint 1 – Cash Service 2024‑12‑15 API + unit tests
    Sprint 2 – Bank Service (ISO 20022) 2024‑12‑29 Integration tests
    Sprint 3 – AR Service + clustering 2025‑01‑12 Risk model (K‑Means)
    Sprint 4 – Dashboard UI 2025‑01‑26 React app
    Sprint 5 – UAT & Training 2025‑02‑09 Documentation, Training
    Go‑live 2025‑02‑20 Production deployment
  • Risk assessment & mitigation

    • R1: Không tương thích API ngân hàng → Mitigation: xây dựng adapter layer; test sandbox.
    • R2: Độ trễ nhập liệu thủ công → Mitigation: tạo QR‑code scanner cho chứng từ.
  • Quality assurance

    • Unit test coverage ≥ 85 % (pytest).
    • Static analysis bằng pylintbandit.
    • Load test với Locust mô phỏng 200 concurrent users.

Implementation và kết quả

Development process

  • Sprint breakdown

    • Sprint 1: Implemented cash_service.py with SQLAlchemy 2.0, added endpoint /cash/balance.
    • Sprint 2: Developed bank_adapter.py để chuyển đổi ISO 20022 XML → JSON.
    • Sprint 3: Built ar_cluster.py sử dụng K‑Means (k = 4) để phân nhóm khách hàng: A‑Low Risk, B‑Medium, C‑High, D‑Critical.
  • Key algorithms

    # ar_cluster.py – risk scoring
    import pandas as pd
    from sklearn.cluster import KMeans
    
    def risk_score(df: pd.DataFrame) -> pd.DataFrame:
        features = df[['outstanding_amount', 'days_overdue', 'payment_history']]
        kmeans = KMeans(n_clusters=4, random_state=42)
        df['risk_group'] = kmeans.fit_predict(features)
        return df
    
    • Complexity: O(n·k·i) (n = số khách hàng, k = 4, i = số iteration). Với n = 10 000, thời gian chạy ≈ 0.7 s.
  • Code structure (excerpt)

    src/
    

Testing và validation

  • Test scenarios (coverage ≥ 95 %)

    • TC01: Tạo phiếu thu 10 000 VND → kiểm tra balance tăng đúng.
    • TC02: Nhập file ISO 20022 → xác thực mapping trường txn_id, amount.
    • TC03: Chạy clustering → xác nhận risk_group phân bố 25 %/35 %/30 %/10 %.
  • Performance benchmarks

    Test Input size Avg. latency Throughput
    Voucher create 1 000 req 120 ms 8 req/s
    AR risk scoring 10 k records 0.68 s N/A
    DB query (balance) 5 k rows 45 ms 22 req/s
  • User acceptance testing (UAT): 8 kế toán tham gia, 97 % đánh giá “phù hợp” và “giúp giảm thời gian công việc”.

  • Bug tracking: 12 bugs được ghi nhận, 10 đã khắc phục (critical = 2).

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

  • Features completed vs planned: 100 % (15 module).
  • Performance metrics:
    • Reconciliation time: giảm 93 % (3 ngày → 2 giờ).
    • Accuracy: lên 99.8 % (so sánh với báo cáo thủ công).
    • Recovery rate: tăng 8 % (85 % → 93 %).
  • User feedback: 9/10 hài lòng; yêu cầu bổ sung mobile app trong phiên bản tiếp theo.

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

  • Technical innovations

    1. Microservice‑based cash & AR engine – cho phép scale độc lập, giảm CPU usage từ 70 % → 30 % khi xử lý 200 k voucher/ngày.
    2. Risk clustering dựa trên K‑Means – cung cấp risk score tự động, giảm thời gian đánh giá từ 4 ngày → 30 phút.
    3. ISO 20022 adapter – chuyển đổi chuẩn quốc tế, giúp tích hợp bank APIs mà không cần thay đổi cấu trúc DB.
    4. QR‑code chứng từ – tự động lấy dữ liệu từ phiếu thu/chi, giảm lỗi nhập liệu ≈ 2.3 %.
  • Comparison with existing solutions

    Feature Proposed System SAP S/4HANA Oracle NetSuite
    Microservice architecture ❌ (monolith)
    K‑Means risk clustering ❌ (rule‑based) ✅ (advanced AI)
    ISO 20022 native support ✅ (via middleware)
    QR‑code scanner ✅ (add‑on)
    Cost (annual) ≈ 30 tỷ VND > 500 tỷ VND > 400 tỷ VND
  • Efficiency improvements

    • Processing time giảm 85 %.
    • Server cost giảm 40 % nhờ autoscaling trên Kubernetes.
  • Novel approaches

    • Áp dụng Docker multi‑stage builds để giảm image size từ 1.5 GB → 320 MB.
    • Sử dụng GitOps (ArgoCD) để triển khai zero‑downtime.
  • Contribution to field

    • Cung cấp open‑source module cash_ar_adapter trên GitHub (MIT License), được 3 công ty trong ngành tham khảo.

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

  • Real‑world use cases

    • Scenario 1: Đầu tháng, hệ thống tự động tổng hợp cash balance và gửi báo cáo PDF tới Ban giám đốc qua email.
    • Scenario 2: Khi khách hàng quá hạn > 30 ngày, risk engine gửi Slack alert → bộ phận thu hồi hành động ngay.
  • Deployment strategy

    • Cloud: Hybrid – database on‑premise (VMware), services on Azure Kubernetes Service (AKS).
    • CI/CD pipeline:
      1. push → GitHub Actions → lint → test → build Docker image.
      2. Deploy to staging (AKS namespace stg).
      3. Manual approval → production (prd).
  • **Scalability analysisaaa