Changelog

Fix BUG-008 (Feedback lần 2) đã tách đúng 3 diễn giải riêng cho cột E dien_giai_ht, nhưng đồng thời cũng gán 3 giá trị khác nhau cho cột D dien_giai (dg1/dg2/dg3). Cột D đáng lẽ phải dùng chung 1 nội dung cho cả 3 dòng cùng ngày, cột E mới tách chi tiết.

Trên MISA, kế toán lọc sổ nhật ký theo cột Diễn giải (D) bằng cụm từ "Shopeefood" hoặc "Grabfood". Nếu 3 dòng cùng ngày ghi khác nhau (hoa hồng / GTGT / TNCN), kết quả lọc chỉ trả về 1/3 dòng — đối chiếu công nợ TK 131 không đầy đủ, sai tổng phát sinh.

Tách thành 2 biến riêng: dg_common = "Hạch toán chi phí đơn hàng {p}" dùng cho tất cả 3 rows ở dien_giai (cột D); dg1/dg2/dg3 giữ nguyên, chỉ gán vào dien_giai_ht (cột E) để phân biệt loại hạch toán.

Hàm dateKeyToDate() tạo Date object bằng new Date(yyyy, mm-1, dd, 0, 0, 0, 0) — là midnight theo local timezone của Node.js process. Trên VPS chạy UTC, midnight ngày 01/03 theo giờ Việt Nam (UTC+7) = 2026-02-28T17:00:00Z. ExcelJS chuyển Date sang Excel serial number dùng UTC epoch → Excel thấy ngày 28/02 → hiển thị sai 1 ngày.

Cột Ngày trong FILE DỮ LIỆU hiển thị sớm hơn 1 ngày so với email SF/GF. Nếu kế toán đối chiếu theo ngày (đặc biệt cuối tháng), dữ liệu sẽ rơi sai kỳ hạch toán — ví dụ đơn hàng 31/03 ghi thành 30/03, sai tháng.

Đổi sang new Date(Date.UTC(yyyy, mm-1, dd)) — date luôn là midnight UTC bất kể timezone server, ExcelJS serialize đúng ở mọi môi trường. Áp dụng cho cả SF (shopeefood.ts) và GF (grabfood.ts).

Parser SF chỉ đọc 6 trong 12 cột của CSV (cột 3, 4, 5, 9, 10, 11). Cột 6 "Khuyến mại từ quán" không được đọc trực tiếp. Writer tính ngược bằng công thức: giam_gia = gia_tri_don − tien_ck − thue − thuc_nhan. Công thức này sai khi có cột 8 "Phí vận chuyển trả cho quán" ≠ 0 vì phí vận chuyển cộng thêm vào thuc_nhan khiến phép trừ cho kết quả nhỏ hơn giá trị thật.

Cột GIẢM GIÁ THÊM dùng để đối chiếu với email SF ("Tổng khuyến mại lợi quán") và tính Doanh thu xuất hoá đơn = Giá trị đơn − Giảm giá thêm. Nếu sai, kế toán không đối chiếu được với email, doanh thu xuất HĐ cũng sai → sai hoá đơn thuế.

Thêm COL_KHUYEN_MAI = 6, đọc trực tiếp vào trường giam_gia_them trong ParsedDayData. Writer ưu tiên dùng row.giam_gia_them nếu có, chỉ fallback về công thức tính ngược cho GF (không có khái niệm này).

converter.ts cấp 2 NVK mỗi ngày: ct1 = NVK_n (Row hoa hồng) và ct2 = NVK_(n+1) (Row thuế GTGT + TNCN). Counter tăng 2 mỗi ngày, khiến 3 dòng ASP của cùng 1 ngày mang 2 số chứng từ khác nhau. Nhận định sai từ ban đầu dựa trên tham chiếu file cũ.

Trong MISA, 1 số chứng từ NVK = 1 bút toán kế toán. Nếu 3 dòng của cùng 1 ngày dùng 2 NVK khác nhau, MISA hiểu là 2 giao dịch riêng lẻ → bút toán không cân → đối chiếu công nợ TK 131 bị sai → báo cáo sai. Đây là lỗi nghiêm trọng nhất trong nhóm feedback này.

Dùng 1 NVK duy nhất cho cả 3 dòng của cùng 1 ngày+kênh. Counter tăng 1 mỗi ngày thay vì 2. Code mới: const ct = formatChungTu(counter++) — cả 3 rows đều dùng ct.

Cột "Diễn giải HT" hiển thị trên sổ sách MISA. Kế toán muốn lọc tất cả bút toán Shopeefood bằng 1 cụm từ duy nhất. Nếu 3 dòng ghi khác nhau, lọc theo diễn giải trả về không đủ — chỉ ra 1/3 dòng → đối chiếu không chính xác.

Tất cả 3 dòng dùng cùng nội dung: "Hạch toán chi phí đơn hàng Shopeefood" / "Hạch toán chi phí đơn hàng Grabfood". Channel name được capitalize từ dien_giai_prefix trong DB, không cần thay đổi cấu trúc DB.

converter.ts không có guard check gia_tri_don === 0. GF PDF những ngày không có đơn hàng vẫn có thể tồn tại với tổng = 0 (đặc biệt khi hệ thống GrabFood gửi PDF báo cáo ngày với 0 đơn). Parser parse thành công → converter tạo 3 dòng ASP với so_tien = 0.

Dòng ASP tiền = 0 là bút toán trống, vô nghĩa trong MISA. Import vào sẽ tạo bút toán dư 0 trên TK 131 → khi đối chiếu công nợ xuất hiện những dòng rỗng gây khó đọc và nhầm lẫn khi kiểm tra sổ.

Thêm if (row.gia_tri_don === 0) continue trước khi allocate NVK. Những ngày không có doanh thu sẽ không tạo bút toán nào.

Parser v1.0 dùng hardcoded index để lấy số liệu từ dòng tổng PDF (ví dụ: row[16] = THUC_NHAN). GrabFood thỉnh thoảng xuất PDF với dòng tổng 16 cột thay vì 19 cột (những ngày không có đơn hoặc định dạng template thay đổi) → row[16] không tồn tại → IndexError: list index out of range.

Toàn bộ email GF của ngày đó bị skip không xử lý được. Nếu không phát hiện kịp thời, dữ liệu ngày đó bị thiếu khỏi FILE ASP → sai tổng hạch toán tháng.

Viết lại parse-gf-pdf.py v2.0 với chiến lược 3 tầng: (1) String match header → map cột động theo tên thay vì index cứng; (2) AI fallback (Gemini) nếu tên cột không khớp pattern; (3) Error + Telegram alert nếu cả 2 tầng đều thất bại. Kèm sanity check zero-tolerance: thuc_nhan == gia_tri_don − tong_ck − thue_gtgt − thue_tncn.

Service Account Google là tài khoản robot — không có Google Drive quota riêng. Không thể tạo file trong Personal Drive của user bằng SA. Giải pháp đúng: dùng OAuth2 user credentials (refresh token của Gmail đã kết nối) để upload — tài khoản người dùng có quota Drive thật.

File XLSX không được upload lên Drive → kế toán không nhận được file qua Drive link → phải download thủ công từng file một, mất tính tự động.

Thêm scope drive.file vào Gmail OAuth flow.drive.ts ưu tiên dùng user refresh token (từ GmailToken table) thay vì Service Account khi upload. SA vẫn giữ làm fallback. Yêu cầu user kết nối lại Gmail trên /setup để lấy token mới có scope drive.file.

File .env trên VPS chứa key ID cũ của Service Account (011350392c...) đã bị xóa khỏi Google Cloud Console. Key active hiện tại là 432467bef4... trong file che-lien-agents-432467bef4ab.json. JWT được ký bằng private key không còn tồn tại → Google từ chối xác thực.

Tìm file JSON đúng (432467bef4), copy lên VPS, cập nhật GOOGLE_SERVICE_ACCOUNT_JSON trong .env. Tuy nhiên sau đó phát hiện BUG-003 (SA không có quota) → chuyển hẳn sang OAuth user credentials.

Code cũ dùng Promise.all(messages.map(id => gmail.modify(...))) — gửi 50 request đồng thời lên Gmail API. Gmail API có rate limit ~10 req/s per user → 50 concurrent calls bị reject 429. HP (ít email hơn) không bị, DBP (nhiều email hơn) bị lỗi.

Label SFGF_Processed không được gỡ → lần scan tiếp theo bỏ qua toàn bộ email đã từng scan → mất dữ liệu mới nếu user nhấn Reset rồi scan lại mà không xử lý lỗi này.

Thay bằng gmail.users.messages.batchModify() — 1 API call duy nhất xử lý tối đa 1000 message IDs → không còn concurrent calls, không bị rate limit.