Chín Miền Dữ Liệu Doanh Nghiệp

Sổ tay triển khai cho engineer: mỗi miền dữ liệu của một doanh nghiệp Việt Nam — nguồn nào, lấy bằng cách nào, luật nào ràng buộc, bẫy nào làm hỏng pipeline. Toàn bộ số liệu pháp lý đối chiếu văn bản còn hiệu lực tại 23/08/2026.

3 miền Nền tảng 3 miền Vận hành 3 miền Tăng trưởng 30 câu quiz có nút nộp bài

00 Đọc trước

Tài liệu này dành cho ai

Engineer chuẩn bị build data pipeline / data platform cho doanh nghiệp Việt Nam. Giả định bạn biết SQL, API, ETL — không giả định bạn biết Thông tư nào quy định thời hạn lưu chứng từ, hay vì sao số liệu quảng cáo hôm qua hôm nay lại khác nhau.

Mỗi miền dữ liệu được viết theo cùng một khuôn 6 phần: Dữ liệu gốc → Đặc thù Việt Nam → Cách lấy → Bẫy kỹ thuật → Công nghệ bổ trợ → Chỉ số đầu ra. Đọc ngang theo khuôn này để so sánh các miền với nhau.

Quy ước ký hiệu

NĐ 254/2026	Văn bản pháp lý đang có hiệu lực — số hiệu tra cứu được
TT 200/2014	Văn bản đã hết hiệu lực — chỉ nêu để đối chiếu
XÁC MINH	Đối chiếu tài liệu chính chủ / văn bản gốc
CHƯA XÁC MINH	Nguồn thứ cấp — phải tự kiểm trước khi đưa vào production

Nguyên tắc viết tài liệu này

Không bịa số. Mọi con số pháp lý đều kèm số hiệu văn bản. Chỗ nào tra không ra thì ghi thẳng là chưa xác minh, không đoán.
Không hard-code từ tài liệu này. Rate limit, endpoint, TTL token đều đổi. Dùng đây làm bản đồ, không phải làm spec.
Có so sánh quốc tế ở những chỗ giúp bạn nhìn ra đâu là đặc thù Việt Nam, đâu là chuẩn chung.

01 Văn bản pháp lý đã thay đổi — đọc trước khi tin tài liệu cũ

Trong 8 tháng gần đây có 4 khung pháp lý lớn bị thay thế. Bất kỳ tài liệu tuân thủ nào viết trước 2026 và còn trích Thông tư 200, Nghị định 123/2020, Nghị định 13/2023 hay Nghị định 53/2022 đều đã lỗi thời.

Nếu bạn đang cầm một spec kế toán ghi "theo Thông tư 200" — spec đó viết cho chế độ kế toán đã hết hiệu lực từ 01/01/2026. Hệ thống tài khoản vẫn giữ cấu trúc Loại 1–9 và phần lớn số hiệu TK, nhưng có tài khoản bị bỏ, có tài khoản đổi tên, và tên báo cáo tài chính đã đổi.

Lĩnh vực	Văn bản cũ (hết hiệu lực)	Văn bản hiện hành	Hiệu lực từ
Chế độ kế toán DN	TT 200/2014/TT-BTC	TT 99/2025/TT-BTC	01/01/2026
Hoá đơn điện tử	NĐ 123/2020 NĐ 70/2025 TT 78/2021	NĐ 254/2026/NĐ-CP TT 91/2026/TT-BTC	01/07/2026
Bảo vệ dữ liệu cá nhân	NĐ 13/2023/NĐ-CP	Luật 91/2025/QH15 NĐ 356/2025/NĐ-CP	01/01/2026
An ninh mạng	Luật ANM 2018 NĐ 53/2022	Luật 116/2025/QH15 NĐ 333/2026/NĐ-CP	01/07 & 19/08/2026
Thuế TNCN	Luật TNCN 2007 — 7 bậc	Luật 109/2025/QH15 — 5 bậc	kỳ tính thuế 2026
BHXH	Luật BHXH 2014	Luật 41/2024/QH15	01/07/2025

Bốn con số hay bị ghi sai nhất trong hệ thống payroll đang chạy

Tham số	Giá trị cũ (sai)	Giá trị hiện hành	Căn cứ
Giảm trừ gia cảnh bản thân	11.000.000 đ	15.500.000 đ	NQ 110/2025/UBTVQH15
Giảm trừ người phụ thuộc	4.400.000 đ	6.200.000 đ	NQ 110/2025/UBTVQH15
Cơ sở tính trần BHXH	"lương cơ sở"	"mức tham chiếu" 2.530.000 đ	Luật 41/2024 NĐ 161/2026
Trần miễn thuế tiền ăn ca	730.000 đ	1.200.000 đ	NĐ 253/2026/NĐ-CP

Cả 4 tham số này đều là hằng số cấu hình trong mọi hệ thống payroll. Nếu chúng nằm hard-code trong code thay vì trong bảng tham số có hiệu lực theo thời gian (effective_from / effective_to), mỗi lần luật đổi là một lần phải deploy. Thiết kế đúng: bảng tham số theo kỳ, tính lương tra theo ngày của kỳ lương.

02 Kiến trúc 3 lớp · 9 miền

Ba lớp không phải là cách chia phòng ban — mà là cách chia theo tính chất dữ liệu: lớp nào bị luật ràng buộc chặt nhất, lớp nào biến động nhanh nhất, lớp nào nhiễu nhất.

Lớp 3 · Tăng trưởng & Trí tuệDữ liệu nhiễu, không immutable

7 · CSKH & Trải nghiệm 8 · Performance Marketing 9 · Sản phẩm & R&D

Lớp 2 · Vận hành & Động cơDữ liệu giao dịch, tốc độ cao

4 · Tồn kho & Chuỗi cung ứng 5 · Mua hàng & Nhà cung cấp 6 · Bán hàng & Đơn hàng

Lớp 1 · Nền tảng & Kiểm soátDữ liệu pháp định, bất biến, lưu 10 năm

1 · Kế toán & Tài chính 2 · Pháp lý & Tuân thủ 3 · Nhân sự & Lương

Lớp 1 — vì sao làm trước

Đây là sự thật pháp lý: con số đã lên báo cáo tài chính, đã lên hoá đơn có mã cơ quan thuế, đã lên bảng lương. Chúng không được sửa tuỳ tiện, phải lưu tối thiểu 10 năm, và là chuẩn để đối soát mọi lớp trên. Sai ở đây là sai có hậu quả pháp lý, không chỉ sai số liệu.

Lớp 2 — nơi khối lượng nằm

99% số dòng dữ liệu nằm ở đây: từng đơn hàng, từng phiếu nhập xuất, từng giao dịch thanh toán. Tốc độ ghi cao, nhiều nguồn rời rạc (POS + sàn + web + kho), và là nơi phát sinh bài toán khớp định danh khó nhất.

Lớp 3 — nơi dữ liệu không đứng yên

Đặc trưng riêng: số liệu bị viết lại về quá khứ. Conversion hôm nay được cộng ngược vào ngày click tuần trước. Chat log có cửa sổ truy cập giới hạn. Đây là lớp duy nhất mà pattern append-only chắc chắn cho ra số sai.

Thứ tự phụ thuộc, không phải thứ tự quan trọng. Lớp 2 cần Lớp 1 để đối soát (đơn hàng phải khớp doanh thu kế toán). Lớp 3 cần Lớp 2 để đo thật (conversion quảng cáo phải đối chiếu đơn hàng thật). Xây Lớp 3 trước khi có Lớp 1 thì bạn có dashboard đẹp trên nền số không kiểm chứng được — đúng thứ mà mọi bên đều muốn tránh.

Lớp 1 / 3

Nền tảng & Kiểm soát

Ba miền dữ liệu bị pháp luật ràng buộc trực tiếp: có mẫu biểu bắt buộc, có thời hạn lưu trữ bắt buộc, có chế tài khi sai. Đây cũng là ba miền mà một thay đổi luật có thể buộc bạn sửa schema.

Kế toán & Tài chính

Accounting & Finance Nền tảng

Dữ liệu gốc

Sổ cái & sổ chi tiết — bút toán theo hệ thống tài khoản Loại 0–9
Chứng từ — phiếu thu/chi, phiếu nhập/xuất kho, uỷ nhiệm chi
Hoá đơn điện tử — file XML có chữ ký số, đây mới là bản gốc pháp lý

Công nợ — TK 131 phải thu khách hàng, TK 331 phải trả người bán
Báo cáo tài chính — B01 đến B09 theo mẫu bắt buộc
Tờ khai thuế — GTGT, TNDN, TNCN theo kỳ

Đặc thù Việt Nam

Ba chế độ kế toán chạy song song — đây là điều engineer nước ngoài hay hiểu sai:

Chế độ	Văn bản	Đối tượng	Hiệu lực
Doanh nghiệp nói chung	TT 99/2025/TT-BTC	Mọi thành phần kinh tế	01/01/2026
Doanh nghiệp nhỏ và vừa	TT 133/2016/TT-BTC	SME — vẫn còn hiệu lực, được chọn	01/01/2017
Doanh nghiệp siêu nhỏ	TT 58/2026/TT-BTC	DN siêu nhỏ bắt buộc	01/07/2026

TT 99/2025 KHÔNG thay thế TT 133/2016. SME được quyền chọn, nhưng phải nhất quán trong cả năm tài chính. Nghĩa là schema của bạn phải mang thuộc tính "đơn vị này đang áp chế độ nào", không giả định một chuẩn duy nhất.

Thay đổi hệ thống tài khoản so với TT 200: giữ nguyên cấu trúc Loại 0–9 và phần lớn số hiệu (TK 111 tiền mặt, TK 131, TK 156, TK 511, TK 632, TK 911…). Nhưng: bỏ TK 161, 417, 441, 461, 466, 611, 631; thêm TK 215 tài sản sinh học, TK 332, TK 82112 thuế tối thiểu toàn cầu; đổi tên TK 112 từ "Tiền gửi Ngân hàng" thành "Tiền gửi không kỳ hạn".

Báo cáo đổi tên: "Bảng cân đối kế toán" nay là "Báo cáo tình hình tài chính" (mẫu B 01 – DN). Nếu hệ thống của bạn sinh báo cáo theo tên cũ, tên đó đã sai chuẩn.

Thuế suất TNDN nay phân tầng theo doanh thu — lần đầu tiên tại Việt Nam Luật 67/2025/QH15: 15% nếu doanh thu năm ≤ 3 tỷ; 17% nếu trên 3 đến ≤ 50 tỷ; 20% phổ thông. Thêm nữa NĐ 141/2026/NĐ-CP miễn thuế TNDN cho DN doanh thu ≤ 1 tỷ/năm.

Thuế GTGT đang giảm 10% → 8% theo NQ 204/2025/QH15, hiệu lực đến hết 31/12/2026. Không áp cho hàng thuế suất 5%, và loại trừ viễn thông, tài chính–ngân hàng, chứng khoán, bảo hiểm, bất động sản, kim loại, khai khoáng (trừ than), hàng chịu thuế tiêu thụ đặc biệt (trừ xăng).

Chuẩn bị cho 01/01/2027. Mức 8% hết hạn 31/12/2026 và chưa có văn bản gia hạn. Hệ thống tính thuế phải để thuế suất là dữ liệu tra theo ngày, không phải hằng số — nếu không, đêm giao thừa 2027 sẽ là một đêm deploy khẩn.

Cách lấy dữ liệu

Hệ thống	Đường vào	Ghi chú kỹ thuật
MISA AMIS Kế toán	Open API REST	Base `https://actapp.misa.vn`, auth `POST /api/oauth/actopen/connect` với `app_id` + `access_code`. Token 12 giờ, header `X-MISA-AccessToken`. Phân trang `skip`/`take`, take tối đa 100. Không phải OAuth2 chuẩn — không có client_secret.
MISA SME.NET	Không có API DB trực tiếp	Chạy trên Microsoft SQL Server (2019 hoặc 2014 tuỳ OS). Backup dạng `.mbk`/`.mbz` độc quyền, không phải `.bak`. Schema không có tài liệu công khai → đọc DB được về kỹ thuật nhưng không có hợp đồng schema, nâng cấp phiên bản có thể phá pipeline.
BRAVO	Linked Server / Web Service	Nhà cung cấp thừa nhận công khai đường View / Link Server / Web Services / API — hiếm và rất đáng giá, vì tích hợp ở tầng DB được hỗ trợ chính thức thay vì làm lén.
FAST	Chưa xác minh	Có sản phẩm Fast iConnect nhưng không tìm thấy tài liệu API công khai. Giả định an toàn: file-based hoặc DB-level, phải làm việc với đối tác triển khai.
Odoo	XML-RPC	`/xmlrpc/2/common` để authenticate, `/xmlrpc/2/object` để gọi model qua `execute_kw`. `fields_get()` cho introspection — tự sinh schema thay vì hard-code. Self-hosted chạy PostgreSQL nên CDC logical replication khả thi.
Hoá đơn điện tử	Lấy XML từ nhà cung cấp HĐĐT	Cổng thuế `hoadondientu.gdt.gov.vn` cho tra cứu và xuất XML thủ công, không có API công khai cho người nộp thuế. Kênh lập trình chính thức là Web Service/SOAP dành cho tổ chức cung cấp dịch vụ — đó là kênh nộp, không phải kênh tra cứu.

Các "API" bên thứ ba rao bán để truy vấn cổng hoadondientu.gdt.gov.vn là reverse-engineering endpoint nội bộ, không được công bố hay hỗ trợ chính thức. Rủi ro cả pháp lý lẫn kỹ thuật — endpoint có thể đổi bất kỳ lúc nào mà không báo trước.

Bẫy kỹ thuật

PDF không phải hoá đơn. Bản gốc pháp lý của hoá đơn điện tử là file XML kèm chữ ký số. Bản in ra giấy hay PDF chỉ là bản thể hiện. Nếu kho lưu trữ của bạn chỉ có PDF, về mặt pháp lý bạn chưa lưu hoá đơn.
Trách nhiệm lưu trữ thuộc về người nộp thuế, không phải nhà cung cấp. Thuê MISA/Viettel/VNPT làm HĐĐT không chuyển giao nghĩa vụ pháp lý. Phải giữ bản sao XML gốc (chữ ký số còn verify được) trong kho do mình kiểm soát, đủ 10 năm, kể cả khi đổi nhà cung cấp. Điều khoản data-export phải nằm trong hợp đồng dịch vụ.
Số hoá đơn reset về 1 mỗi ngày 01/01. Tối đa 8 chữ số. Nghĩa là số hoá đơn không unique toàn cục — khoá thật là tổ hợp (ký hiệu, số, năm). Dùng số hoá đơn làm primary key là lỗi kinh điển.
Ký hiệu hoá đơn 6 ký tự mã hoá cả loại hoá đơn, có/không có mã cơ quan thuế, và năm lập — phải parse chứ không lưu như chuỗi mờ.
Người mua có thể không có mã số thuế. Khi đó hoá đơn ghi "Bán cho người tiêu dùng". Schema phải cho phép MST nullable, và join theo MST sẽ mất nhóm bán lẻ này.
Kỳ kế toán không phải kỳ dương lịch của bạn. Bút toán điều chỉnh cuối kỳ có thể ghi ngày thuộc kỳ trước sau khi kỳ đó đã "đóng" trong hệ thống nguồn. Pipeline chỉ đọc WHERE created_at > watermark sẽ bỏ sót — phải theo dõi cả updated_at và cho phép re-sync kỳ đã đóng.

Công nghệ bổ trợ

Debezium SQL Server CDC SQL Server 2016 SP1+ Std/Ent lxml / xmlschema (parse XML HĐĐT) xmlsec (verify chữ ký số) dbt (mô hình hoá sổ cái) Great Expectations (kiểm tra cân đối) MinIO / S3 Object Lock (WORM 10 năm)

Kiểm thử bắt buộc cho miền này: tổng Nợ = tổng Có ở mọi kỳ; tổng doanh thu sổ cái = tổng doanh thu hoá đơn đã phát hành; số dòng trước và sau mỗi bước transform phải khớp. Ba assertion này bắt được đa số lỗi pipeline kế toán.

Chỉ số đầu ra

Doanh thu thuần theo kỳGiá vốn & biên lợi nhuận gộpDòng tiền thuần Tuổi nợ phải thu (AR aging)Tuổi nợ phải trả (AP aging)Vòng quay vốn lưu động Thuế GTGT phải nộp / được khấu trừ

Pháp lý, Rủi ro & Tuân thủ

Legal, Risk & Compliance Nền tảng

Dữ liệu gốc

Hợp đồng — bản ký số, phụ lục, ngày hiệu lực, ngày hết hạn, điều khoản gia hạn
Giấy phép & chứng nhận — ĐKKD, giấy phép con, chứng chỉ ngành
Hồ sơ tuân thủ dữ liệu — DPIA, TIA, bằng chứng đồng ý

Nhật ký truy cập — ai xem dữ liệu gì, khi nào (yêu cầu pháp lý, không phải tuỳ chọn)
Sự cố & vi phạm — thời điểm phát hiện, phạm vi ảnh hưởng, thời điểm báo cáo
Chính sách nội bộ — phiên bản, ngày ban hành, ai đã xác nhận đọc

Đặc thù Việt Nam

Việt Nam đã có Luật Bảo vệ dữ liệu cá nhân đầy đủ — Luật 91/2025/QH15 hiệu lực 01/01/2026, chi tiết tại NĐ 356/2025/NĐ-CP. Đây là nâng cấp từ nghị định lên luật, và có hiệu lực ngoài lãnh thổ: tổ chức nước ngoài xử lý dữ liệu công dân Việt Nam cũng thuộc phạm vi.

Hai thay đổi phân loại dữ liệu ảnh hưởng trực tiếp đến schema:

Chuyển từ cơ bản sang NHẠY CẢM: dữ liệu về hoạt động và lịch sử hoạt động trên không gian mạng. Nghĩa là clickstream, product telemetry, behavioural analytics của người dùng Việt Nam giờ là dữ liệu nhạy cảm — kéo theo yêu cầu đồng ý chặt hơn, access control, và mã hoá khi chuyển ra nước ngoài.
Bỏ khỏi nhóm cơ bản: số CMND, mã số thuế, số BHXH — thay bằng số định danh cá nhân/căn cước.

Không có cơ sở "lợi ích hợp pháp" kiểu GDPR. Ngoài đồng ý, chỉ có danh sách đóng 6 nhóm ngoại lệ (cấp bách bảo vệ tính mạng, bảo vệ quyền lợi trước xâm phạm, tình trạng khẩn cấp/an ninh quốc gia, hoạt động cơ quan nhà nước, thực hiện thoả thuận với chủ thể, luật khác quy định). Marketing, analytics, personalisation ở Việt Nam gần như luôn cần consent.

Nghĩa vụ nộp hồ sơ — đây là khác biệt lớn nhất so với GDPR:

Hồ sơ	Nộp cho ai	Thời hạn	Duy trì
DPIA — đánh giá tác động xử lý DLCN	A05, Bộ Công an	60 ngày kể từ ngày xử lý đầu tiên	Cập nhật 6 tháng/lần
TIA — đánh giá tác động chuyển DLCN ra nước ngoài	A05, Bộ Công an	60 ngày kể từ lần chuyển đầu tiên	Thẩm định 15 ngày, kiểm tra hằng năm
Thông báo vi phạm dữ liệu	A05	72 giờ kể từ khi phát hiện	TMĐT: 24 giờ

Việt Nam KHÔNG có adequacy decision, KHÔNG có SCC, KHÔNG có BCR. Không có "danh sách nước an toàn". Mọi luồng dữ liệu ra nước ngoài — kể cả dùng cloud region nước ngoài, CRM/ERP/HRIS SaaS quốc tế — đều đi qua thủ tục nộp hồ sơ và hậu kiểm.

So sánh quốc tế · Việt Nam vs EU GDPR

Trục	Việt Nam Luật 91/2025	EU GDPR
Cơ sở xử lý	Consent là chủ đạo + 6 ngoại lệ đóng. Không có legitimate interests thương mại.	6 cơ sở ngang hàng (Điều 6): consent, hợp đồng, nghĩa vụ pháp lý, lợi ích sống còn, nhiệm vụ công, lợi ích hợp pháp.
DPIA	BẮT BUỘC NỘP cho công an trong 60 ngày, cập nhật 6 tháng/lần, kiểm tra hằng năm.	KHÔNG phải nộp. Tài liệu nội bộ. Chỉ tham vấn trước khi rủi ro vẫn cao sau biện pháp giảm thiểu (Điều 36).
Chuyển xuyên biên giới	Nộp TIA + hậu kiểm. Không có cơ chế "khoá một lần".	Adequacy / SCC / BCR — dùng SCC không cần xin phép trước.
Trần phạt	Mua bán DLCN: 10× khoản thu bất hợp pháp, sàn 3 tỷ. Chuyển trái phép: 5% doanh thu năm trước. Khác: tối đa 3 tỷ đồng.	Tối đa 20 triệu EUR hoặc 4% doanh thu toàn cầu — tuỳ mức cao hơn (Điều 83(5)).

Ba khác biệt quyết định thiết kế hệ thống: (1) Việt Nam là chế độ đăng ký, GDPR là chế độ trách nhiệm giải trình — DPIA ở Việt Nam là quy trình vận hành có deadline pháp lý, cần chủ sở hữu và lịch nhắc, không phải tài liệu để tủ. (2) Không có SCC nghĩa là mỗi thay đổi kiến trúc (đổi cloud region, thêm SaaS vendor) đều có thể kích hoạt nghĩa vụ cập nhật hồ sơ. (3) Trần theo % của Việt Nam (5%) cao hơn GDPR (4%), dù trần tuyệt đối thấp hơn nhiều.

Chữ ký số & hợp đồng điện tử

Luật GDĐT 20/2023/QH15 hiệu lực 01/07/2024 + NĐ 23/2025/NĐ-CP. Ba loại chữ ký (danh sách đóng): chữ ký điện tử chuyên dùng, chữ ký số công cộng (VNPT-CA, Viettel-CA, FPT-CA…), chữ ký số chuyên dùng công vụ.

Chữ ký scan KHÔNG phải chữ ký điện tử. Uỷ ban Thường vụ Quốc hội khẳng định rõ khi trình Luật GDĐT 2023: chữ ký scan, chữ ký hình ảnh, mật khẩu OTP, tin nhắn SMS không đáp ứng định nghĩa chữ ký điện tử. Hợp đồng ký scan có thể vẫn có hiệu lực nếu hai bên tự nguyện thực hiện, nhưng không đạt mức "tương đương chữ ký tay" và rất khó chứng minh khi tranh chấp.

Hợp đồng lao động điện tử là hợp lệ — BLLĐ 45/2019 Điều 14 khoản 1 nói rõ HĐLĐ giao kết qua phương tiện điện tử dưới hình thức thông điệp dữ liệu có giá trị như HĐLĐ bằng văn bản. Nhưng vẫn phải "làm thành 02 bản" — tức nền tảng phải cho phép người lao động tải và giữ bản độc lập, không chỉ xem trên portal.

Bẫy kỹ thuật

Retention là thuộc tính nghiệp vụ, không suy ra được từ định dạng file. Ranh giới 5 năm vs 10 năm phụ thuộc "chứng từ này có dùng trực tiếp để ghi sổ và lập BCTC hay không" — phải gắn ở tầng metadata ngay khi tạo chứng từ, không thể phân loại lại sau bằng script.
Ngày bắt đầu tính retention khác nhau theo loại tài liệu. Đa số tính từ ngày kết thúc kỳ kế toán năm; nhưng tài liệu thanh lý TSCĐ, chia tách/giải thể, hồ sơ kiểm toán tính từ ngày sự kiện hoàn thành. Một cột retention_until tính máy móc từ created_at sẽ sai cả nhóm này.
Rút lại đồng ý có SLA pháp lý. Phản hồi trong 2 ngày làm việc, thực hiện trong 15–20 ngày. Nghĩa là hệ thống phải có đường xoá dữ liệu chủ động chạy được theo yêu cầu, không phải "để đó rồi tính".
Bằng chứng đồng ý phải in ra được. Lưu một boolean consented = true là không đủ. Phải lưu: thời điểm, phiên bản văn bản đồng ý, phạm vi mục đích, và hình thức thu thập — đủ để tái dựng thành văn bản khi bị kiểm tra.
Đồng ý phải tách theo mục đích. Không được gộp. Nghĩa là schema consent là quan hệ một-nhiều (một chủ thể × nhiều mục đích), không phải một cột.

Công nghệ bổ trợ

S3 Object Lock / WORM OpenTelemetry (audit trail) Vault / KMS (quản lý khoá) OPA (chính sách truy cập) Column-level encryption Data catalog + PII tagging Consent management platform

Chỉ số đầu ra

Số hợp đồng sắp hết hạn 30/60/90 ngàyTỉ lệ hồ sơ DPIA/TIA đã nộp đúng hạn Thời gian trung bình xử lý yêu cầu rút đồng ýSố truy cập dữ liệu nhạy cảm bất thường Tỉ lệ tài liệu quá hạn lưu trữ chưa xử lý

Nhân sự, Lương & Vận hành nội bộ

HR, Payroll & Internal Ops Nền tảng

Dữ liệu gốc

Hồ sơ nhân sự — HĐLĐ, chức danh, phòng ban, ngày vào/ra
Chấm công — log ra/vào từ máy chấm công, app, hoặc bảng công thủ công
Bảng lương — lương cơ bản, phụ cấp, khoản bổ sung, khấu trừ

SHUI — số sổ BHXH, mức đóng, kỳ đóng, biến động tăng/giảm
Thuế TNCN — người phụ thuộc, số thuế khấu trừ, quyết toán năm
Nghỉ phép & làm thêm — số ngày phép còn lại, giờ OT theo tháng/năm

Đặc thù Việt Nam — tỉ lệ đóng SHUI

Quỹ	Người lao động	Doanh nghiệp	Tổng
BHXH — hưu trí & tử tuất	8%	14%	22%
BHXH — ốm đau & thai sản	0%	3%	3%
BHXH — tai nạn LĐ & bệnh nghề nghiệp	0%	0,5%	0,5%
Bảo hiểm y tế	1,5%	3%	4,5%
Bảo hiểm thất nghiệp	1%	1%	2%
TỔNG	10,5%	21,5%	32%

Căn cứ Luật BHXH 41/2024/QH15 Điều 33–34, NĐ 158/2025/NĐ-CP, NĐ 188/2025/NĐ-CP (BHYT), Luật Việc làm 74/2025/QH15 + NĐ 374/2025/NĐ-CP (BHTN). Mức TNLĐ-BNN giảm còn 0,3% nếu DN đủ điều kiện.

Người lao động chỉ đóng vào quỹ hưu trí – tử tuất. Hai quỹ ốm đau-thai sản và TNLĐ-BNN do doanh nghiệp chịu 100%. Nếu công thức payroll của bạn nhân 10,5% lên toàn bộ rồi chia lại, kết quả sẽ đúng tổng nhưng sai phân bổ theo quỹ — và báo cáo BHXH cần đúng theo quỹ.

Đặc thù Việt Nam — trần và sàn đóng

"Lương cơ sở" đã được thay bằng "mức tham chiếu" trong Luật BHXH. Luật 41/2024 Điều 141 khoản 13 quy định: khi chưa bãi bỏ lương cơ sở thì mức tham chiếu bằng lương cơ sở. Lương cơ sở nâng lên 2.530.000 đ từ 01/07/2026 theo NĐ 161/2026/NĐ-CP → mức tham chiếu tự động theo.

Loại	Công thức trần	Giá trị từ 01/07/2026
BHXH bắt buộc	20 × mức tham chiếu	50.600.000 đ/tháng
BHYT	20 × mức tham chiếu	50.600.000 đ/tháng
BHTN	20 × lương tối thiểu vùng	V-I 106.200.000 · V-II 94.600.000 V-III 82.800.000 · V-IV 74.000.000

Trần BHTN dùng công thức KHÁC hai loại kia — theo lương tối thiểu vùng, không theo mức tham chiếu. Và từ 01/01/2026 tất cả nhóm đều dùng 20× LTT vùng Luật Việc làm 74/2025 Điều 34 khoản 2. Nghĩa là hàm tính trần phải nhận thêm tham số vùng của nơi làm việc — một nhân viên chuyển từ chi nhánh Vùng III lên Vùng I thì trần BHTN đổi.

Lương tối thiểu vùng 2026 NĐ 293/2025/NĐ-CP, hiệu lực 01/01/2026, tăng bình quân 7,2%:

Vùng	Đồng/tháng	Đồng/giờ
Vùng I	5.310.000	25.500
Vùng II	4.730.000	22.700
Vùng III	4.140.000	20.000
Vùng IV	3.700.000	17.800

Danh mục địa bàn đã cập nhật theo 34 tỉnh/thành sau sáp nhập — nếu bảng ánh xạ địa bàn→vùng trong hệ thống của bạn còn theo danh mục tỉnh cũ, nó đã sai.

Đặc thù Việt Nam — thuế TNCN chỉ còn 5 bậc

Biểu thuế đã đổi từ 7 bậc xuống 5 bậc — Luật TNCN 109/2025/QH15. Hiệu lực đặc thù cần chú ý khi cấu hình: luật hiệu lực 01/07/2026, nhưng quy định về thu nhập tiền lương/tiền công của cá nhân cư trú áp dụng từ kỳ tính thuế năm 2026, tức từ 01/01/2026.

Bậc	Thu nhập tính thuế / tháng	Thuế suất
1	Đến 10 triệu	5%
2	Trên 10 – 30 triệu	10%
3	Trên 30 – 60 triệu	20%
4	Trên 60 – 100 triệu	30%
5	Trên 100 triệu	35%

Giảm trừ gia cảnh NQ 110/2025/UBTVQH15: bản thân 15.500.000 đ/tháng (186 triệu/năm), mỗi người phụ thuộc 6.200.000 đ/tháng.

Các mức khác theo NĐ 253/2026/NĐ-CP: trần giảm trừ bảo hiểm hưu trí tự nguyện 3.000.000 đ/tháng; giảm trừ chi phí y tế tối đa 23.000.000 đ/năm, giáo dục tối đa 24.000.000 đ/năm; ngưỡng khấu trừ 10% thu nhập vãng lai nâng lên 5.000.000 đ/lần chi trả (trước là 2 triệu). Tiền lương làm thêm giờ và làm ca đêm — phần trả cao hơn — được miễn thuế; tiền nghỉ phép năm chưa sử dụng cũng miễn nếu phù hợp Điều 113 BLLĐ.

Đặc thù Việt Nam — phụ cấp nào đóng, phụ cấp nào không

PHẢI đóng BHXH — "phụ cấp lương"

Phụ cấp chức vụ, chức danh
Phụ cấp trách nhiệm
Phụ cấp nặng nhọc, độc hại, nguy hiểm
Phụ cấp thâm niên
Phụ cấp khu vực, lưu động, thu hút

KHÔNG đóng BHXH — 14 khoản

Thưởng chuyên cần, thưởng sáng kiến
Tiền ăn giữa ca, hỗ trợ xăng xe, điện thoại, đi lại
Hỗ trợ nhà ở, giữ trẻ, nuôi con nhỏ
Hỗ trợ hiếu hỉ, sinh nhật
Trợ cấp tai nạn LĐ / bệnh nghề nghiệp

Điều kiện bắt buộc để 14 khoản kia không phải đóng: phải được ghi thành mục riêng trong HĐLĐ TT 10/2020/TT-BLĐTBXH Điều 3 khoản 5. Nếu gộp vào lương hoặc trả cố định như một phần lương thì vẫn phải đóng BHXH. Nghĩa là data model lương phải giữ từng khoản riêng biệt có nhãn loại, không được gộp thành một cột total_allowance — gộp là mất khả năng chứng minh khi thanh tra. Căn cứ danh mục: CV 1198/CTL&BHXH-BHXH (2025).

Trần miễn thuế TNCN tiền ăn giữa ca: 1.200.000 đ/người/tháng NĐ 253/2026 Điều 8 khoản 2 điểm g — tăng ~64% so với mức 730.000 đ cũ. Ngoại lệ quan trọng: nếu doanh nghiệp tự tổ chức bữa ăn (tự nấu, mua suất ăn, cấp phiếu) thì miễn thuế toàn bộ, không áp trần. Trần 1,2 triệu chỉ áp cho chi bằng tiền mặt.

Đặc thù Việt Nam — giới hạn làm thêm giờ

Giới hạn	Mức	Ghi chú
Giờ làm bình thường	≤ 8 giờ/ngày, ≤ 48 giờ/tuần	Nhà nước khuyến khích 40 giờ/tuần
Làm thêm theo ngày	≤ 50% giờ bình thường; tổng ≤ 12 giờ/ngày	—
Làm thêm theo tháng	≤ 40 giờ	Ràng buộc hay bị vượt nhất
Làm thêm theo năm	≤ 200 giờ	≤ 300 giờ với ngành đặc thù
Giờ làm đêm	22h00 – 06h00	Phụ cấp đêm +30%

BLLĐ 45/2019 Điều 105–107. Ngành được áp 300 giờ/năm: dệt may, da giày, điện tử, chế biến nông–lâm–thuỷ sản, điện, viễn thông, lọc dầu, cấp thoát nước, và công việc cấp bách không thể trì hoãn. Lưu ý: NQ 17/2022/UBTVQH15 từng cho phép 60 giờ/tháng — nghị quyết này đã hết hiệu lực, hiện áp dụng đúng BLLĐ 2019.

Đơn giá làm thêm BLLĐ Điều 98: ngày thường ≥150%, ngày nghỉ tuần ≥200%, lễ tết ≥300%, làm đêm +30%, làm thêm vào ban đêm +20% cộng thêm.

Bẫy kỹ thuật

Chấm công thô không phải giờ công. Log máy chấm công là chuỗi sự kiện quẹt thẻ — có quẹt trùng, quên quẹt ra, quẹt hộ, thiết bị lệch giờ. Phải có tầng chuẩn hoá (ghép cặp vào/ra, xử lý ca đêm vắt qua nửa đêm, gắn cờ bất thường) trước khi tính lương. Đừng nối thẳng log vào công thức.
Ca đêm vắt qua nửa đêm phá logic GROUP BY DATE. Ca 22h–6h thuộc về ngày nào? Phải có khái niệm ngày công tách khỏi ngày lịch, và quy tắc gán nhất quán trên toàn hệ thống.
Giới hạn OT là ràng buộc tích luỹ. 40 giờ/tháng và 200 giờ/năm nghĩa là hệ thống phải cảnh báo trước khi duyệt thêm giờ, không phải phát hiện sau khi đã vượt. Đây là kiểm tra ở tầng ứng dụng, không phải báo cáo cuối kỳ.
Bảng lương là snapshot bất biến. Đã chốt kỳ lương thì các tham số (mức đóng, trần, giảm trừ) phải được đóng băng theo kỳ đó. Nếu tính lại kỳ cũ bằng tham số hiện tại, số sẽ khác và không đối chiếu được với chứng từ đã nộp BHXH/thuế.
Dữ liệu nhân sự là dữ liệu cá nhân, phần lớn là nhạy cảm. Tình trạng sức khoẻ, thông tin gia đình để tính người phụ thuộc, tài khoản ngân hàng nhận lương — đều thuộc nhóm nhạy cảm theo NĐ 356/2025. Access control ở đây không phải nice-to-have.
Mở rộng đối tượng BHXH bắt buộc. Luật 41/2024 đưa thêm chủ hộ kinh doanh có ĐKKD, người làm việc không trọn thời gian (nếu lương ≥ mức đóng thấp nhất), và hạ ngưỡng HĐLĐ từ 3 tháng xuống từ đủ 1 tháng. Nếu hệ thống lọc "chỉ tính BHXH cho HĐLĐ ≥ 3 tháng", logic đó đã lỗi thời.

Công nghệ bổ trợ

Bảng tham số theo kỳ (effective dating) Temporal tables / SCD Type 2 Rule engine cho công thức lương Column-level encryption (PII) Row-level security Reconciliation job: payroll ↔ kế toán TK 334

Mẫu hình quan trọng nhất ở miền này là effective dating. Mọi tham số pháp lý (tỉ lệ đóng, trần, bậc thuế, giảm trừ, lương tối thiểu vùng) đều thay đổi theo thời gian và phải tra được theo ngày của kỳ lương, không phải theo ngày chạy job. Đây là khác biệt giữa một hệ thống chạy được 1 năm và một hệ thống chạy được 10 năm.

Chỉ số đầu ra

Tổng quỹ lương theo phòng ban/kỳChi phí SHUI doanh nghiệp chịu Giờ OT tích luỹ theo tháng/năm — cảnh báo ngưỡngTỉ lệ nghỉ việc (turnover) Số ngày phép tồn đọngChi phí nhân sự / doanh thu

Lớp 2 / 3

Vận hành & Động cơ

Ba miền chứa khối lượng giao dịch lớn nhất và nhiều nguồn rời rạc nhất. Bài toán chính ở đây không phải "lấy được dữ liệu" mà là khớp cùng một thực thể qua nhiều hệ thống — cùng một đơn hàng tồn tại ở POS, ở sàn, ở đơn vị vận chuyển, ở ngân hàng, dưới bốn mã khác nhau.

Tồn kho & Chuỗi cung ứng

Inventory & Supply Chain Vận hành

Dữ liệu gốc

Danh mục hàng hoá — SKU, đơn vị tính, quy cách đóng gói, nhóm hàng
Phiếu nhập / xuất kho — chứng từ gốc, có giá trị kế toán
Tồn kho theo kho & theo lô — số lượng, giá trị, hạn sử dụng

Kiểm kê — số sổ sách vs số thực tế, chênh lệch, nguyên nhân
Vận đơn — mã vận đơn, trạng thái, lịch sử chuyển trạng thái
Điều chuyển nội bộ — giữa kho, giữa chi nhánh

Đặc thù Việt Nam

Đơn vị tính đa cấp là chuẩn, không phải ngoại lệ. Cùng một SKU tồn tại ở nhiều đơn vị: thùng / lốc / lon, bao / kg, cây / mét. Hệ số quy đổi có thể thay đổi theo thời gian (nhà cung cấp đổi quy cách đóng gói) và theo nhà cung cấp. Nếu schema chỉ có một cột quantity không kèm đơn vị và hệ số quy đổi tại thời điểm giao dịch, tồn kho sẽ sai âm thầm.

TT 99/2025 đưa vào phương pháp standard cost cho hàng tồn kho — thay đổi so với chế độ cũ. Nghĩa là chênh lệch giữa giá chuẩn và giá thực tế phải được theo dõi và phân bổ, không chỉ ghi nhận giá thực tế.

Bán hàng đa kênh làm phân mảnh tồn kho. Một SKU có thể được giữ chỗ ở Shopee, Lazada, TikTok Shop, website, và cửa hàng vật lý cùng lúc. "Tồn kho khả dụng" là một phép trừ có nhiều số hạng, và mỗi kênh có độ trễ đồng bộ riêng.

Cách lấy dữ liệu — đơn vị vận chuyển

Đây là nhóm dễ tích hợp nhất trong toàn bộ landscape — cả ba đơn vị lớn đều có tài liệu API công khai.

Đơn vị	Đặc điểm kỹ thuật
GHN Tài liệu công khai	Tracking: `online-gateway.ghn.vn/shiip/public-api/v2/shipping-order/detail`. Header `Token` + `ShopId`. Tra được bằng `order_code` của GHN hoặc `client_order_code` — mã đơn của chính bạn, nên không cần lưu mapping hai chiều. ⭐ Response chứa mảng `log` = toàn bộ lịch sử chuyển trạng thái → tính được lead time từng chặng chỉ với một lần gọi, không cần poll liên tục. Có webhook callback.
GHTK Tài liệu công khai	Base `services.giaohangtietkiem.vn`. Cần hai header: `Token` và `X-Client-Source` — thiếu cái thứ hai là lỗi thường gặp nhất. Tra trạng thái `GET /services/shipment/v2/{LABEL_ID}`. Có webhook.
Viettel Post Có Swagger spec	Spec OpenAPI thô đọc được tại `partnerdev.viettelpost.vn/v2/v2/api-docs` → sinh client code tự động được, không phải đọc PDF. Header auth tên `Token`. Tracking `GET /order/getOrderDetailV3`. Chưa xác minh webhook, rate limit, host production.

Bẫy kỹ thuật

Tồn kho là số dẫn xuất, không phải số gốc. Số gốc là chuỗi phiếu nhập/xuất. Nếu pipeline chỉ snapshot bảng tồn kho mỗi đêm, bạn mất khả năng truy vết vì sao tồn kho đổi và không tái dựng được tồn kho tại một thời điểm bất kỳ trong quá khứ. Đúng: đồng bộ chứng từ, tính tồn kho từ chứng từ.
Snapshot đêm che mất biến động trong ngày. Một SKU nhập 100 rồi xuất 100 trong cùng ngày sẽ hiện là "không có gì xảy ra" — trong khi thực tế đã có hai giao dịch cần đối soát.
Kiểm kê tạo bút toán điều chỉnh lùi ngày. Phát hiện chênh lệch hôm nay nhưng chênh lệch phát sinh từ tháng trước. Pipeline phải cho phép ghi nhận điều chỉnh có ngày hiệu lực trong quá khứ, và báo cáo phải nói rõ "số này đã điều chỉnh".
Hàng đang trên đường không thuộc kho nào. Hàng đã xuất khỏi kho A chưa nhập vào kho B, hoặc đã giao cho shipper chưa giao khách. Nếu data model chỉ có "tồn tại kho X", nhóm này biến mất khỏi tổng — và tổng tồn kho sẽ không khớp sổ kế toán.
Hàng hoàn (COD trả về) là luồng ngược ít được mô hình hoá. Tỉ lệ hoàn ở thương mại điện tử Việt Nam đáng kể. Nếu không mô hình hoá luồng hoàn, doanh thu ghi nhận sẽ cao hơn thực tế và tồn kho thấp hơn thực tế.

Công nghệ bổ trợ

Event sourcing cho chuyển động kho Bảng quy đổi đơn vị có hiệu lực theo thời gian Kafka / Redpanda (luồng sự kiện kho) TimescaleDB / ClickHouse (chuỗi thời gian tồn kho) Webhook receiver + retry queue

Chỉ số đầu ra

Vòng quay hàng tồn khoSố ngày tồn kho bình quânHàng chậm luân chuyển (quá N kỳ) Tỉ lệ chính xác kiểm kêLead time từng chặng giao hàngTỉ lệ giao thành công / hoàn Tỉ lệ hết hàng (stockout)

Mua hàng & Quan hệ nhà cung cấp

Procurement & Vendor Relations Vận hành

Dữ liệu gốc

Yêu cầu mua hàng — ai đề nghị, mặt hàng, số lượng, lý do
Báo giá nhà cung cấp — thường là PDF/email, ít khi có cấu trúc
Đơn đặt hàng (PO) — điều khoản, giá, thời hạn giao

Hoá đơn đầu vào — XML từ nhà cung cấp, khấu trừ thuế GTGT
Tờ khai hải quan — với hàng nhập khẩu
Hồ sơ nhà cung cấp — MST, điều khoản thanh toán, đánh giá

Đặc thù Việt Nam

Hoá đơn đầu vào là tài sản thuế, không chỉ là chứng từ. Thuế GTGT đầu vào chỉ được khấu trừ khi có hoá đơn hợp lệ. Một hoá đơn thiếu điều kiện = mất tiền thật. Vì vậy pipeline hoá đơn đầu vào cần kiểm tra tính hợp lệ, không chỉ nạp dữ liệu.

NĐ 254/2026 có thay đổi đáng chú ý: định nghĩa "sử dụng hoá đơn không hợp pháp" đã bỏ tiêu chí "thiếu nội dung bắt buộc". Đồng thời bổ sung yêu cầu ghi mã địa điểm kinh doanh với DN nhiều địa điểm, và tên hàng hoá phải bằng tiếng Việt theo danh mục pháp lý.

Đối chiếu ba chiều là nghiệp vụ bắt buộc: PO ↔ phiếu nhập kho ↔ hoá đơn đầu vào. Ba chứng từ này đến từ ba nguồn khác nhau, ở ba thời điểm khác nhau, và thường có sai lệch nhỏ về số lượng/giá. Đây là nơi phát hiện gian lận mua hàng.

Thuế GTGT 8% không áp đều. Cùng một đơn mua có thể có mặt hàng 8%, mặt hàng 10% (thuộc nhóm loại trừ), mặt hàng 5%. Tính thuế ở mức đơn hàng thay vì mức dòng hàng sẽ sai.

Bẫy kỹ thuật

Nhà cung cấp trùng lặp là bài toán khớp thực thể. "Công ty TNHH ABC", "Cty TNHH ABC", "CÔNG TY TNHH A.B.C" là ba bản ghi khác nhau trong hệ thống nhưng một pháp nhân. Mã số thuế là khoá tự nhiên đáng tin cậy nhất — dùng MST làm khoá khớp, tên chỉ để hiển thị.
Báo giá thường nằm ngoài hệ thống. Trong email, Zalo, file Excel đính kèm. Nếu muốn phân tích xu hướng giá mua, phải có bước số hoá báo giá — thường là điểm dừng thực tế của nhiều dự án procurement analytics.
Hoá đơn đầu vào đến chậm hơn hàng. Hàng nhập kho tháng 1, hoá đơn về tháng 2. Nếu ghép PO–nhập kho–hoá đơn theo cùng kỳ, tỉ lệ khớp sẽ thấp giả tạo. Phải khớp theo chuỗi tham chiếu, không theo kỳ.
Giá mua thay đổi giữa PO và hoá đơn do biến động tỉ giá, phụ phí, chiết khấu sau mua. Model phải cho phép nhiều phiên bản giá trên cùng một dòng hàng, kèm lý do chênh lệch.

Công nghệ bổ trợ

Parse XML hoá đơn đầu vào Entity resolution theo MST OCR + LLM extraction (báo giá PDF) Fuzzy matching (rapidfuzz) cho tên hàng Workflow engine cho luồng duyệt 3-way match reconciliation job

Chỗ LLM thực sự hữu ích trong miền này: trích xuất có cấu trúc từ báo giá PDF/ảnh (mặt hàng, đơn giá, điều kiện giao hàng, hiệu lực báo giá). Nhưng phải có cổng người duyệt trước khi đưa vào hệ thống — đây là dữ liệu dẫn đến quyết định chi tiền, không để mô hình tự quyết.

Chỉ số đầu ra

Chi phí mua theo nhóm hàng/nhà cung cấpTỉ lệ khớp 3 chiều (3-way match rate) Lead time đặt hàng → nhận hàngTỉ lệ giao đúng hạn của NCC Biến động giá mua theo thời gianMức tập trung nhà cung cấp (rủi ro phụ thuộc)

Bán hàng & Đơn hàng khách

Sales & Customer Orders Vận hành

Dữ liệu gốc

Đơn hàng — từ POS, website, sàn TMĐT, telesales
Khách hàng — thông tin liên hệ, lịch sử mua, phân khúc
Giao dịch thanh toán — cổng thanh toán hoặc chuyển khoản ngân hàng

Khuyến mại & chiết khấu — mã giảm giá, chương trình, điều kiện áp dụng
Hoá đơn bán ra — XML đã phát hành cho khách
Hoàn/huỷ đơn — lý do, thời điểm, hoàn tiền

Cách lấy dữ liệu — POS & thương mại điện tử

Hệ thống	Auth & giới hạn	Điểm cần biết
KiotViet API tốt nhất nhóm	OAuth2 `client_credentials` chuẩn. Token endpoint `id.kiotviet.vn/connect/token`, TTL 24 giờ. Base `public.kiotapi.com`, header `Retailer` + Bearer. Rate limit: 5.000 GET/giờ.	⚠️ Phân biệt `orders` (đơn đặt) và `invoices` (đã thu tiền) — báo cáo doanh thu phải dùng `invoices`. Schema khác nhau giữa ngành (bán lẻ / F&B / salon) — đừng dùng chung.
Haravan Rate limit rõ ràng	Leaky bucket: bucket 80, leak 4/giây. Header `X-Haravan-Api-Call-Limit` (vd `32/80`). Vượt → HTTP 429 + `Retry-After`.	Mô hình rate limit dễ code nhất nhóm: đọc header mỗi response, giữ ~4 req/s, backoff theo `Retry-After`. Inventory khuyến nghị ≤ 200 items/request.
Nhanh.vn Giới hạn chí mạng	Open API v3.0 (v2.0 hết hỗ trợ 30/11/2026). `POST pos.open.nhanh.vn/v3.0/order/list`, phân trang cursor. Rate limit chưa xác minh.	⭐ Chỉ lấy được đơn trong 31 ngày gần nhất. Nhanh.vn không phải system of record lịch sử — phải build warehouse và sync liên tục. Pipeline chết quá 31 ngày = mất dữ liệu vĩnh viễn.
Sapo Một phần chưa xác minh	Có OAuth, webhook, Order API (GET/PUT). Rate limit, base URL pattern chưa xác minh.	Kiến trúc giống Shopify → hợp lý khi giả định leaky bucket, nhưng phải test thực tế, đừng code theo giả định.
Shopee / Lazada / TikTok Shop Tài liệu bị gate	Đều có Open Platform nhưng tài liệu yêu cầu tài khoản developer / JS rendering. Ký request bằng HMAC-SHA256 với quy tắc khác nhau từng sàn.	TikTok Shop đánh version theo mã ngày (`202309`, `202407`) — phải pin version. Token ngắn hạn → cần service refresh token riêng, không nhét vào job ETL. Mỗi sàn một cơ chế ký → chi phí bảo trì nhân theo số sàn.

Cách lấy dữ liệu — thanh toán

Hai lớp hoàn toàn khác nhau về kỹ thuật đối soát:

Cổng thanh toán

VNPay, MoMo, ZaloPay. Merchant chủ động tạo giao dịch với mã đơn của mình → cổng trả lại đúng mã đó. Khớp là chuyện dễ.

MoMo: HMAC_SHA256, orderId merchant đặt được trả nguyên vẹn trong IPN. resultCode = 0 là thành công. Giới hạn 10.000 – 50.000.000 đ. Lưu ý requestId là idempotency key, không phải khoá đơn hàng.

ZaloPay: callback verify bằng HmacSHA256 với key2. Merchant trả return_code = 1 khi nhận thành công.

Tổng hợp biến động số dư

Casso, SePay. Khách chuyển khoản thẳng vào tài khoản ngân hàng — không có mã đơn nào tồn tại về mặt kỹ thuật. Phải parse nội dung chuyển khoản. Đây là nơi 90% lỗi đối soát phát sinh.

Casso: GET oauth.casso.vn/v2/transactions, header Authorization: Apikey. Gói STANDARD 20 request/phút. Webhook verify bằng header secure-token.

SePay: webhook có sẵn trường code — hệ thống tự parse mã thanh toán, giảm việc regex phía bạn. Vẫn nên giữ content thô để đối soát khi parse sai.

Bài học kiến trúc từ tài liệu ZaloPay: "Sau 15 phút kể từ khi tạo đơn, nếu vẫn chưa nhận được callback, merchant cần chủ động gọi QueryOrder API để lấy kết quả cuối cùng." → Webhook là at-least-once và có thể mất. Luôn phải có vòng quét chủ động để đóng khoảng trống. Thiết kế đúng: webhook để phản hồi nhanh, job quét theo giờ để đối soát.

Ràng buộc quyết định thiết kế mã đơn hàng · VietQR

Đây là con số ảnh hưởng đến schema nhiều nhất trong cả miền này. API VietQR POST api.vietqr.io/v2/generate, tham số addInfo (nội dung chuyển khoản):

addInfo tối đa 25 ký tự — "Nhập tiếng Việt không dấu, tối đa 25 ký tự. Không chứa các ký tự đặc biệt".

Bốn nguyên tắc thiết kế mã đơn suy ra từ ràng buộc này:

Tổng ≤ 25 ký tự kể cả prefix. Prefix 2–4 ký tự → còn ~20 ký tự cho ID. UUID không dùng được.
Chỉ [A-Z0-9]. Loại bỏ -, _, #, / và mọi dấu tiếng Việt khỏi mã đơn.
Prefix phải hiếm trong ngôn ngữ tự nhiên. Prefix DH sẽ false-positive với chữ "DH" khách tự gõ. Chuỗi 4 ký tự lạ an toàn hơn.
Luôn giả định khách gõ sai. Nội dung chuyển khoản là free-text: khách xoá nội dung, gõ thêm chữ, ngân hàng chèn tiền tố riêng (MBVCB.xxx, CT DEN:xxx). Bắt buộc có unmatched queue và fallback khớp theo (số tiền + thời gian + tên người chuyển).

Bẫy kỹ thuật

Mã tham chiếu cổng thanh toán phải unique theo ngày. VNPay vnp_TxnRef và ZaloPay app_trans_id đều yêu cầu vậy, nên nhiều hệ thống dùng orderId + timestamp. Điều này phá join 1-1 nếu warehouse join thẳng vnp_TxnRef = order_id — phải lưu bảng mapping riêng.
Đơn hàng ≠ doanh thu ≠ tiền về. Ba con số khác nhau, ở ba thời điểm khác nhau: đơn tạo hôm nay, hoá đơn phát hành ngày mai, tiền về sau 7 ngày (COD). Dashboard trộn ba khái niệm này là lỗi phổ biến nhất trong báo cáo bán hàng.
Không thấy được hard delete qua API. Đơn bị xoá ở hệ thống nguồn vẫn nằm trong warehouse của bạn mãi mãi. Chỉ CDC mới thấy DELETE. Với API, phải có job đối soát tổng số bản ghi định kỳ.
Đơn đa kênh trùng khách. Cùng một người mua ở Shopee (username), ở web (email), ở cửa hàng (số điện thoại). Không hợp nhất được thì mọi chỉ số về khách hàng (LTV, tần suất mua) đều sai lệch xuống.

Công nghệ bổ trợ

Webhook receiver + idempotency key Dead letter queue Token refresh service (tách khỏi ETL) Airbyte / Meltano (connector sàn) Regex + fallback matcher (đối soát CK) Unmatched queue + giao diện xử lý tay

Chỉ số đầu ra

Doanh thu theo kênh / theo ngàyGiá trị đơn trung bình (AOV)Tỉ lệ huỷ / hoàn đơn Tỉ lệ đối soát thanh toán tự độngSố giao dịch chưa khớp tồn đọng Thời gian từ đơn đến tiền vềTỉ lệ khách mua lại

Lớp 3 / 3

Tăng trưởng & Trí tuệ

Ba miền có một đặc tính chung mà hai lớp dưới không có: dữ liệu không đứng yên sau khi ghi. Số liệu quá khứ bị viết lại, cửa sổ truy cập có hạn, và một phần dữ liệu do người dùng viết ra nên không có schema. Pattern append-only ở đây chắc chắn cho ra số sai.

Chăm sóc khách hàng & Trải nghiệm

Customer Support & Experience Tăng trưởng

Dữ liệu gốc

Hội thoại — Zalo OA, Facebook Messenger, live chat, email
Ticket — trạng thái, người xử lý, thời gian phản hồi, thời gian đóng
Cuộc gọi — tổng đài, thời lượng, ghi âm, kết quả

Đánh giá & phản hồi — rating sàn TMĐT, khảo sát NPS/CSAT
Khiếu nại — loại vấn đề, sản phẩm liên quan, cách xử lý
Bài viết tự phục vụ — lượt xem, tỉ lệ giải quyết được

Đặc thù Việt Nam — cửa sổ nhắn tin Zalo OA

Zalo là kênh CSKH chính của phần lớn doanh nghiệp Việt Nam, và nó có một ràng buộc mà bắt buộc phải đưa vào thiết kế SLA ngay từ đầu:

Loại tin	Cửa sổ thời gian	Chi phí	Khung giờ
Tin Tư vấn (customer service)	365 ngày qua OA Manager 07 ngày qua OpenAPI	Miễn phí trong 48 giờ, tính phí sau	24/7
Tin Broadcast	Bất kỳ lúc nào tới follower	Theo quota gói thuê bao	Chỉ 06:00–19:59
ZNS Template	—	Theo lượt gửi, cần duyệt template	—

⭐ Bẫy lớn nhất: cửa sổ qua OpenAPI chỉ 07 ngày, trong khi qua giao diện OA Manager là 365 ngày. Nghĩa là một hệ thống ticket tự động build trên OpenAPI có cửa sổ trả lời ngắn hơn 52 lần so với nhân viên thao tác tay. Đây là ràng buộc phải biết trước khi thiết kế, không phải phát hiện sau go-live.

Mốc 48 giờ tính phí biến "first response time < 48h" thành KPI có giá trị tiền thật, không chỉ là chỉ số đẹp — vượt mốc là phát sinh chi phí gửi tin.

So sánh đa kênh: Facebook Messenger có cửa sổ chuẩn 24 giờ; ngoài cửa sổ chỉ gửi được tin phi khuyến mại kèm message tag hợp lệ (ACCOUNT_UPDATE, POST_PURCHASE_UPDATE, HUMAN_AGENT…). → Nếu build inbox hợp nhất, cửa sổ phải là thuộc tính per-channel trong data model, không hard-code một giá trị chung.

Bẫy kỹ thuật

Coi nền tảng là transport, không phải kho lưu trữ. Chính sách retention lịch sử tin nhắn của Zalo OA chưa xác minh được từ tài liệu chính chủ, và cửa sổ OpenAPI chỉ 7 ngày. Kiến trúc đúng: bắt webhook và ghi ngay vào storage của mình. Nếu chờ đến lúc cần mới đi lấy thì có thể đã muộn.
Nội dung hội thoại chứa PII không lường trước. Khách gửi ảnh CCCD, số tài khoản, tình trạng bệnh vào chat. Đây là dữ liệu nhạy cảm theo NĐ 356/2025 lọt vào hệ thống mà không qua form nào. Cần quét và phân loại ở cửa vào, không giả định chat log là dữ liệu vô hại.
Thời gian phản hồi phải trừ giờ không làm việc. Tin nhắn 22h thứ Bảy, trả lời 9h thứ Hai — SLA thô tính 35 giờ, SLA nghiệp vụ tính 1 giờ. Cần lịch làm việc trong tính toán.
Một khách nhiều kênh. Cùng người hỏi trên Zalo rồi gọi tổng đài. Không hợp nhất thì đếm thành hai ticket và nhân viên thứ hai không biết ngữ cảnh.

Công nghệ bổ trợ

Webhook ingest ngay lập tức PII scanner ở cửa vào Embedding + vector search (phân cụm chủ đề) LLM phân loại ý định & sentiment Bảng lịch làm việc cho SLA Identity graph đa kênh

Ứng dụng LLM đáng giá nhất ở đây: phân loại tự động chủ đề khiếu nại từ chat log để phát hiện vấn đề sản phẩm đang tăng đột biến — thứ mà không ai có thời gian đọc thủ công. Nhưng kết quả phân loại phải được coi là gợi ý cần kiểm chứng, và tuyệt đối không đưa PII từ chat ra API bên thứ ba khi chưa rà soát nghĩa vụ chuyển dữ liệu xuyên biên giới (mục 02).

Chỉ số đầu ra

Thời gian phản hồi đầu tiên (trong/ngoài 48h)Thời gian giải quyết trung bình Tỉ lệ giải quyết ngay lần đầuCSAT / NPSTop chủ đề khiếu nại theo tuần Chi phí tin nhắn phát sinh do trả lời chậm

Performance Marketing

Performance Marketing Tăng trưởng

Dữ liệu gốc

Chi phí quảng cáo — theo campaign / adset / ad / ngày
Hiệu suất — impression, click, CTR, CPC, CPM
Conversion — theo mô hình attribution của từng nền tảng

Sự kiện website/app — pageview, add to cart, purchase
Sự kiện server-side — CAPI, Enhanced Conversions
Doanh thu thật — từ miền 06, để đối chiếu

Vấn đề cửa sổ attribution — bản chất kỹ thuật

Đây là thứ khiến số liệu quảng cáo không bao giờ immutable, và nếu không hiểu thì pipeline sẽ sai âm thầm.

Nguyên nhân gốc: conversion được quy về ngày CLICK, không phải ngày CONVERT. Người dùng click quảng cáo ngày 1, mua ngày 6. Với cửa sổ 7-day click, conversion đó được cộng ngược vào dòng dữ liệu của ngày 1.

Bốn hệ quả trực tiếp lên thiết kế pipeline:

Dữ liệu quá khứ bị viết lại (restatement). Con số của ngày 1 kéo vào ngày 2 khác con số của ngày 1 kéo vào ngày 10. Không phải bug — đúng thiết kế.
Không dùng được append-only incremental. Pattern bắt buộc là rolling re-sync: mỗi lần chạy kéo lại toàn bộ N ngày gần nhất và upsert theo khoá (date, entity_id). N ≥ cửa sổ attribution dài nhất đang bật. Connector Airbyte cho Meta mặc định lookback 28 ngày chính vì lý do này.
Không cộng được conversion giữa các nền tảng. Meta mặc định 7-day click; Google có mô hình riêng; TikTok single-touch với CTA/VTA/EVTA. Cộng "conversions" từ 3 nền tảng luôn lớn hơn số đơn thật vì cùng một đơn được cả ba cùng nhận công. → Đơn hàng thật phải lấy từ miền 06; số liệu ads chỉ dùng so sánh xu hướng trong nội bộ từng kênh.
Multi-segment gây row explosion. Google cảnh báo rõ: mỗi segment thêm vào có thể làm số dòng tăng theo cấp số nhân. Phải giới hạn segment và tính trước chi phí lưu trữ.

Hai thay đổi lớn năm 2026 — phải biết

Meta · hiệu lực 12/01/2026

Áp dụng cho MỌI phiên bản API cùng lúc — không lùi được bằng cách pin version cũ.

Bỏ 7d_view và 28d_view. Còn lại: 1-day click, 7-day click, 28-day click, 1-day engaged view, 1-day view.
Retention aggregate: 37 tháng
Retention breakdown unique-count & hourly: 13 tháng
Retention breakdown frequency: 6 tháng
MMM breakdowns chuyển sang chỉ chạy async job

Duy trì advanced access cần ≥ 1.500 API call trong mỗi cửa sổ trượt 15 ngày — dưới ngưỡng có thể bị thu hồi quyền.

Google Ads · hiệu lực 01/06/2026

Phiên bản mới nhất tại thời điểm viết: v25.1 (19/08/2026).

Segment chi tiết (segments.date, segments.week) chỉ còn lookback 37 tháng.
Phân tích xa hơn 37 tháng bắt buộc dùng segments.month / quarter / year.

→ Nếu cần lịch sử daily quá 37 tháng, bạn phải tự lưu — Google không còn là nguồn backfill nữa. Đây là lý do đủ mạnh để snapshot daily ngay hôm nay dù chưa có nhu cầu phân tích dài hạn.

Tình trạng thực tế của cookie và ATT — nói cho đúng

Third-party cookie KHÔNG bị khai tử trên Chrome. Ngày 22/04/2025 Google thông báo giữ nguyên cách tiếp cận hiện tại và sẽ không tung prompt lựa chọn riêng cho third-party cookie. Nhiều tài liệu trong ngành vẫn đang viết sai điểm này.

Tiếp đó, ngày 17/10/2025 Google thông báo khai tử hàng loạt API của Privacy Sandbox: Attribution Reporting API, IP Protection, Protected Audience, Topics, Private Aggregation, SelectURL và nhiều API khác.

Kết luận đúng cho 2026: signal loss trên web không đến từ Chrome, mà đến từ Safari (ITP) và Firefox (ETP) vốn đã chặn third-party cookie từ lâu, cộng ad blocker và giới hạn tuổi thọ cookie do JS đặt trên Safari. Đồng thời các API thay thế mà ngành từng đặt cược đã bị huỷ — không có "phương án B chuẩn hoá" nào đang tới. Điều này càng đẩy trọng số về phía server-side tracking và first-party data.

Server-side tracking thực sự giải quyết được gì — nói chính xác:

CÓ

Khôi phục sự kiện browser-side bị mất (ad blocker, cookie bị xoá, JS lỗi)
Gửi được conversion xảy ra ngoài web: CRM, tổng đài, giao COD thành công, hoàn hàng
Cải thiện match rate nhờ first-party identifier đã hash

KHÔNG

Không "phá" được iOS ATT
Không khôi phục định danh xuyên app khi người dùng từ chối
Không biến attribution thành deterministic 100%

Đánh đổi mới mà engineer phải chịu: hashing phải chuẩn hoá trước — lowercase, trim, số điện thoại về E.164. Sai chuẩn hoá thì hash không khớp, match rate tụt mà không có báo lỗi nào. Đây là loại lỗi âm thầm nguy hiểm nhất nhóm này. Ngoài ra, chạy song song Pixel + CAPI bắt buộc phải dedup, nếu không sẽ đếm đôi.

Công nghệ bổ trợ

Rolling re-sync + upsert (date, entity_id) Airbyte / Fivetran connector Snapshot daily ngay từ đầu Server-side GTM Chuẩn hoá PII trước khi hash (E.164) Event dedup theo event_id Bảng ánh xạ chi phí ↔ đơn hàng thật

Chỉ số đầu ra

Chi phí theo kênh / campaignCAC — dùng đơn hàng THẬT ở mẫu số ROAS nội bộ từng kênh (không cộng chéo)Tỉ lệ conversion nền tảng báo / đơn thật Match rate của server-side eventsĐộ lệch số liệu giữa lần kéo đầu và lần kéo cuối

Sản phẩm & R&D

Product & R&D Tăng trưởng

Dữ liệu gốc

Phản hồi sản phẩm — từ CSKH (miền 07), đánh giá sàn, khảo sát
Báo cáo QC — lô sản xuất, chỉ tiêu kiểm, tỉ lệ lỗi, nguyên nhân
Telemetry sản phẩm — với sản phẩm số: sự kiện sử dụng tính năng

Vòng đời phát triển — ý tưởng → thử nghiệm → ra mắt
Bảo hành & đổi trả — lý do kỹ thuật, chi phí xử lý
Công thức & định mức — BOM, hao hụt định mức vs thực tế

Đặc thù & điểm cần lưu ý

Telemetry sản phẩm nay là dữ liệu NHẠY CẢM tại Việt Nam. NĐ 356/2025 Điều 4 xếp "dữ liệu theo dõi hành vi, hoạt động sử dụng dịch vụ viễn thông, mạng xã hội, dịch vụ trực tuyến" và "hoạt động, lịch sử hoạt động trên không gian mạng" vào nhóm dữ liệu cá nhân nhạy cảm. Nghĩa là clickstream và product analytics của người dùng Việt Nam chịu yêu cầu đồng ý chặt hơn, access control, và mã hoá khi chuyển ra nước ngoài — bao gồm cả việc gửi vào công cụ analytics đặt server ở nước ngoài.

QC là nơi dữ liệu định lượng gặp dữ liệu định tính. Chỉ tiêu đo được (kích thước, độ ẩm, độ bền) nằm cạnh nhận xét bằng chữ của kiểm tra viên. Giá trị phân tích lớn nhất đến từ việc nối tỉ lệ lỗi QC với khiếu nại khách hàng ở miền 07 — nhưng hai bên thường dùng hai bộ mã sản phẩm khác nhau.

Vòng phản hồi bị đứt ở đâu. Khiếu nại → CSKH ghi nhận → không ai chuyển về R&D → sản phẩm không sửa → khiếu nại lặp lại. Về mặt dữ liệu, chỗ đứt là không có khoá chung giữa ticket CSKH và mã sản phẩm/lô sản xuất. Đây là thứ đáng sửa trước khi build bất kỳ dashboard nào.

Bẫy kỹ thuật

Mã sản phẩm không thống nhất giữa các miền. SKU bán hàng ≠ mã vật tư sản xuất ≠ mã trong hệ thống QC ≠ tên sản phẩm khách gọi khi khiếu nại. Cần bảng ánh xạ trung tâm, và bảng đó phải có phiên bản theo thời gian vì SKU bị đổi/gộp.
Phản hồi tiêu cực bị lấy mẫu lệch. Chỉ khách rất hài lòng hoặc rất bực mới để lại đánh giá. Kết luận "sản phẩm tốt vì rating 4.8" bỏ qua nhóm im lặng. Cần đối chiếu với tỉ lệ mua lại (miền 06) — chỉ số hành vi, không phải chỉ số phát biểu.
Định mức hao hụt là số thoả thuận, không phải số đo. Chênh lệch giữa định mức và thực tế có thể là vấn đề kỹ thuật, có thể là vấn đề ghi nhận. Đừng kết luận từ một phía.
Telemetry dễ phình chi phí. Ghi mọi sự kiện của mọi người dùng là cách nhanh nhất để hoá đơn cloud vượt ngân sách. Cần thiết kế lấy mẫu và mức độ chi tiết theo mục đích ngay từ đầu — và giờ còn thêm lý do pháp lý để không thu thập quá tay.

Công nghệ bổ trợ

Bảng ánh xạ mã sản phẩm có phiên bản Kiểm soát chất lượng thống kê (SPC) Topic modelling trên phản hồi Feature flag + A/B framework Lấy mẫu telemetry theo tầng Consent-aware event collector

Chỉ số đầu ra

Tỉ lệ lỗi theo lô / theo dây chuyềnChi phí bảo hành / doanh thu Thời gian từ phản hồi đến thay đổi sản phẩmTỉ lệ dùng tính năng mới Chênh lệch định mức vs thực tếTop nguyên nhân đổi trả

10 Mẫu hình nạp dữ liệu — chọn cái nào cho hệ thống nào

Bốn mẫu hình, và bảng ánh xạ sang đúng loại hệ thống trong landscape Việt Nam. Đây là quyết định kiến trúc khó đảo ngược nhất — chọn sai thì phải xây lại, không phải sửa.

A · CDC — Change Data Capture

Đọc transaction log của database, stream từng INSERT/UPDATE/DELETE. Với Debezium SQL Server connector — quan trọng vì phần lớn ERP Việt Nam chạy SQL Server:

Yêu cầu SQL Server 2016 SP1 trở lên, bản Standard hoặc Enterprise
Phải bật CDC ở cả hai cấp: sys.sp_cdc_enable_db và sys.sp_cdc_enable_table cho từng bảng
SQL Server Agent bắt buộc phải chạy
Mô hình: snapshot ban đầu → streaming, theo dõi vị trí bằng LSN
Không hỗ trợ capture từ indexed/materialized view

B · Batch export · C · API polling · D · File drop

Batch export — query WHERE updated_at > :watermark trên replica, hoặc restore backup đêm rồi extract.

API polling — gọi REST theo lịch với cursor tăng dần. Phổ biến nhất với SaaS.

File drop — Excel/CSV/XML đẩy vào SFTP hoặc thư mục chia sẻ. Rẻ nhất, không cần nhà cung cấp hợp tác, nhưng không có schema contract và cực dễ hỏng khi ai đó thêm một cột. Bắt buộc validate schema ở cửa vào, không nạp thẳng.

Loại hệ thống	Ví dụ	Mẫu hình phù hợp	Đánh đổi cốt lõi
ERP on-prem, SQL Server, không API	MISA SME.NET, FAST, BRAVO	CDC nếu bản quyền + DBA cho phép; nếu không thì batch export đêm	CDC cho độ trễ giây và bắt được cả DELETE/UPDATE — thứ API không bao giờ cho thấy. Nhưng cần Std/Ent edition, SQL Agent, và schema hoàn toàn không có hợp đồng: nâng cấp phần mềm có thể đổi cột và phá pipeline âm thầm.
ERP có Linked Server được thừa nhận	BRAVO	Batch export qua view / linked server	Được nhà cung cấp thừa nhận nên ổn định hơn CDC lén; đổi lại latency theo lịch và thường không thấy bản ghi đã xoá.
SaaS có API + webhook	KiotViet, Sapo, Haravan, MISA AMIS	API polling incremental (cursor `updatedAt`) + webhook cho realtime	Không cần DBA, có hợp đồng schema. Nhưng bị rate limit (KiotViet 5.000 GET/h; Haravan 4 req/s), phân trang tốn kém (MISA take ≤ 100), và không nhìn thấy hard delete. Webhook giảm latency nhưng at-least-once và có thể mất → luôn cần vòng quét đối chiếu.
SaaS cửa sổ lịch sử ngắn	Nhanh.vn — 31 ngày	API polling BẮT BUỘC + warehouse là system of record	Ràng buộc cứng, không phải tối ưu hoá. Pipeline chết quá 31 ngày là mất dữ liệu vĩnh viễn. Phải alert trên độ trễ pipeline, không chỉ trên lỗi.
Marketplace	Shopee, Lazada, TikTok Shop	API polling + quản lý refresh token	Token ngắn hạn → cần token refresh service riêng, không nhét vào job ETL. Cửa sổ query lịch sử hẹp → phải tự lưu. Mỗi sàn một cơ chế ký khác nhau → chi phí bảo trì nhân theo số sàn.
Cổng thanh toán	VNPay, MoMo, ZaloPay	Webhook/IPN (chính) + query API (đối soát)	Webhook một mình không bao giờ đủ. Kiến trúc đúng: webhook để phản hồi nhanh, job quét theo giờ để đóng gap.
Tổng hợp biến động số dư	Casso, SePay	Webhook + REST sweep định kỳ	Casso 20 req/phút (gói STANDARD) → sweep theo trang, không brute-force. Điểm khó không phải kỹ thuật mà là khớp bằng regex trên free text → bắt buộc có unmatched queue.
Quảng cáo	Google Ads, Meta, TikTok	Batch report pull với rolling lookback window	Không dùng append-only. Re-sync N ngày gần nhất và upsert theo `(date, entity_id)`, N ≥ cửa sổ attribution dài nhất. Đánh đổi: chi phí API và compute lặp lại mỗi ngày, đổi lấy số đúng.
CSKH	Zalo OA, Messenger	Webhook là chính — coi nền tảng là transport	Cửa sổ OpenAPI Zalo chỉ 7 ngày, retention chưa xác minh → bắt webhook ghi ngay vào storage của mình. Chờ đến lúc cần mới lấy thì có thể đã muộn.

Bốn trục đánh đổi khi chọn — thường không tối ưu được cả bốn

Trục	Xếp hạng
Độ trễ	CDC (giây) > Webhook (giây, có thể mất) > API polling (phút–giờ) > File drop (giờ–ngày)
Độ trung thực	CDC là mẫu hình DUY NHẤT thấy được hard DELETE và mọi bước UPDATE trung gian. API và file chỉ cho trạng thái tại thời điểm chụp — một đơn đổi trạng thái 3 lần giữa hai lần poll thì bạn mất 2 bước.
Rủi ro vỡ	CDC và direct DB bám vào schema nội bộ không có hợp đồng → rủi ro cao nhất khi nhà cung cấp nâng cấp. API có versioning (Nhanh.vn v2→v3, TikTok Shop 202309/202407) → vỡ có báo trước.
Gánh nặng vận hành	CDC nặng nhất (cần DBA, monitor lag, xử lý schema drift). File drop nhẹ nhất nhưng đẩy gánh nặng sang khâu validate và con người.

11 Phân loại dữ liệu & thời hạn lưu trữ

Hai bảng dưới đây quyết định schema, access control và retention policy của toàn bộ nền tảng. Nên đọc trước khi thiết kế bảng đầu tiên, không phải sau khi go-live.

Phân loại dữ liệu cá nhân — NĐ 356/2025/NĐ-CP

Dữ liệu CƠ BẢN (Điều 3)

Họ tên khai sinh, tên gọi khác
Ngày sinh, giới tính
Nơi ở, nơi thường trú/tạm trú
Quốc tịch, hình ảnh
Số định danh cá nhân
Tình trạng hôn nhân, quan hệ gia đình
Thông tin tài khoản số

Dữ liệu NHẠY CẢM (Điều 4) — 12 nhóm

Chủng tộc, dân tộc, quan điểm chính trị, tôn giáo
Đời sống riêng tư, bí mật cá nhân/gia đình
Tình trạng sức khoẻ, sinh trắc học, di truyền
Đời sống/xu hướng tình dục
Tội phạm và vi phạm pháp luật
Vị trí cá nhân qua dịch vụ định vị
Tài khoản/mật khẩu VNeID, ảnh thẻ căn cước
Tài khoản ngân hàng, lịch sử giao dịch tài chính
⭐ Dữ liệu theo dõi hành vi, hoạt động sử dụng dịch vụ trực tuyến

Hai thay đổi so với NĐ 13/2023 mà mọi data catalog cần cập nhật: (1) Số CMND, mã số thuế, số BHXH bị bỏ khỏi nhóm cơ bản — thay bằng số định danh cá nhân. (2) Dữ liệu hoạt động trên không gian mạng chuyển từ cơ bản sang nhạy cảm — kéo gần như toàn bộ clickstream và product telemetry vào nhóm nhạy cảm.

Thời hạn lưu trữ chứng từ kế toán — Luật Kế toán 88/2015 + NĐ 174/2016/NĐ-CP

Thời hạn	Nhóm tài liệu	Căn cứ
Tối thiểu 5 năm	Tài liệu dùng cho quản lý điều hành, không sử dụng trực tiếp để ghi sổ và lập BCTC. Phiếu thu/chi, phiếu nhập/xuất kho không lưu trong tập tài liệu kế toán.	Điều 12
Tối thiểu 10 năm	Chứng từ sử dụng trực tiếp để ghi sổ và lập BCTC; sổ kế toán chi tiết & tổng hợp; BCTC tháng/quý/năm; báo cáo quyết toán; tài liệu thanh lý/nhượng bán TSCĐ; tài liệu chia tách/sáp nhập/giải thể/phá sản; hồ sơ kiểm toán, thanh tra. Và mọi tài liệu không thuộc Điều 12 hay Điều 14 — tức đây là nhóm mặc định.	Điều 13
Vĩnh viễn	Báo cáo quyết toán NSNN đã được Quốc hội phê chuẩn; hồ sơ quyết toán dự án nhóm A và dự án quan trọng quốc gia; tài liệu có tính sử liệu, ý nghĩa về kinh tế, an ninh, quốc phòng.	Điều 14

Hoá đơn điện tử thuộc nhóm 10 năm. NĐ 254/2026 Điều 5 quy định thời hạn lưu trữ HĐĐT theo pháp luật về kế toán — và hoá đơn là chứng từ dùng trực tiếp để ghi sổ → rơi vào Điều 13. Trách nhiệm lưu trữ thuộc người nộp thuế, thuê nhà cung cấp dịch vụ không chuyển giao nghĩa vụ này.

Hai hệ quả kỹ thuật: (1) Hệ thống phải hỗ trợ retention policy nhiều tầng theo document class, với khoá WORM/immutability trong suốt kỳ lưu trữ. (2) Ngày bắt đầu tính retention khác nhau: đa số tính từ ngày kết thúc kỳ kế toán năm, nhưng tài liệu thanh lý TSCĐ / chia tách / hồ sơ kiểm toán tính từ ngày sự kiện hoàn thành. Một cột retention_until tính máy móc từ created_at sẽ sai cả nhóm sau.

Lưu trữ dữ liệu tại Việt Nam & nhật ký hệ thống

Luật An ninh mạng 116/2025/QH15 Điều 25 khoản 3 + NĐ 333/2026/NĐ-CP (hiệu lực 19/08/2026). Doanh nghiệp trong nước và nước ngoài cung cấp dịch vụ trên mạng tại Việt Nam có thu thập, xử lý dữ liệu cá nhân và dữ liệu do người dùng tại Việt Nam tạo ra phải lưu trữ dữ liệu này tại Việt Nam và đặt chi nhánh hoặc văn phòng đại diện.

Yêu cầu	Thời hạn	Tình trạng xác minh
Nhật ký hệ thống (tài khoản, thời gian đăng nhập/xuất, IP, nhật ký xử lý)	Tối thiểu 12 tháng	Xác minh trong NĐ 333/2026
Dữ liệu người dùng theo yêu cầu của cơ quan chức năng	Tối thiểu 24 tháng	Con số này từ NĐ 53/2022 đã bị thay thế — chưa đối chiếu được bản chính NĐ 333/2026
Phản hồi yêu cầu của cơ quan chức năng	24 giờ (khẩn cấp: 3–6 giờ)	Xác minh

Với doanh nghiệp nước ngoài, nghĩa vụ này vẫn mang tính kích hoạt, không tự động: chỉ phát sinh sau quyết định bằng văn bản của Bộ trưởng Bộ Công an, và sau đó có 12 tháng để hoàn tất. Ngoài ra NĐ 333/2026 yêu cầu tối thiểu 15% ngân sách dự án chuyển đổi số dành cho an ninh mạng.

12 Khớp định danh — bài toán khó nhất xuyên suốt 9 miền

Mỗi miền dùng một khoá khác nhau cho cùng một thực thể. Không giải bài này thì mọi chỉ số tổng hợp đều sai, và không có công cụ nào giải hộ được.

Thực thể	Khoá tin cậy nhất	Khoá phụ	Vì sao khó
Nhà cung cấp / khách hàng doanh nghiệp	Mã số thuế	Tên pháp nhân, địa chỉ ĐKKD	Tên viết nhiều kiểu ("Công ty TNHH ABC" / "Cty TNHH ABC" / "CÔNG TY TNHH A.B.C"). MST là khoá tự nhiên ổn định — dùng MST để khớp, tên chỉ để hiển thị.
Khách hàng cá nhân	Số điện thoại (chuẩn hoá E.164)	Email, số định danh cá nhân	Một người nhiều số; một số dùng chung (số của công ty, của người nhà). Username sàn TMĐT không liên kết được với số thật. Không có khoá nào đủ tin cậy một mình.
Đơn hàng	Mã đơn nội bộ	Mã đơn sàn, mã vận đơn, mã tham chiếu thanh toán	Cùng một đơn có ≥4 mã ở 4 hệ thống. Mã tham chiếu thanh toán phải unique theo ngày → không join 1-1 được với mã đơn.
Sản phẩm	SKU nội bộ	Mã vật tư, mã QC, barcode, tên trên sàn	Bốn hệ thống bốn bộ mã. SKU còn bị đổi/gộp theo thời gian → bảng ánh xạ phải có phiên bản theo thời gian.
Nhân viên	Mã nhân viên nội bộ	Số BHXH, số định danh cá nhân	Tương đối dễ nhất trong nhóm — nhưng lưu ý số BHXH nay không còn thuộc nhóm dữ liệu cơ bản.

Ba nguyên tắc thực hành

Không ép khớp 100%. Thiết kế đúng có ba nhóm: khớp chắc chắn, khớp nghi ngờ (cần người xác nhận), không khớp. Nhóm giữa phải có giao diện xử lý, không được tự động gán bừa — một lần gán sai khách hàng sẽ lan ra mọi báo cáo phía sau.
Lưu cả khoá gốc lẫn khoá đã hợp nhất. Bảng ánh xạ phải giữ được đường quay ngược về bản ghi nguồn. Ghi đè khoá gốc là mất khả năng kiểm chứng và không sửa lại được khi phát hiện khớp sai.
Chuẩn hoá trước khi khớp, và chuẩn hoá một chỗ duy nhất. Số điện thoại về E.164, tên viết hoa/thường thống nhất, bỏ dấu khi so sánh. Nếu mỗi pipeline tự chuẩn hoá theo cách riêng thì kết quả khớp sẽ khác nhau giữa các báo cáo — lỗi rất khó truy.

13 Lộ trình triển khai

Thứ tự dưới đây theo phụ thuộc dữ liệu, không theo mức độ hấp dẫn. Làm ngược thứ tự này là cách phổ biến nhất để có dashboard đẹp trên nền số không đối chiếu được.

Giai đoạn 0Kiểm kê nguồn: hệ thống nào, ai giữ credential, đường vào là gì. Lập data flow diagram — cũng là đầu vào bắt buộc cho hồ sơ DPIA.

→

Giai đoạn 1Lớp Nền tảng. Kế toán trước — vì đây là chuẩn đối soát cho mọi thứ sau. Kèm retention policy và phân loại PII ngay từ đầu.

→

Giai đoạn 2Lớp Vận hành. Bán hàng + tồn kho + thanh toán. Đối soát ngược lên kế toán ở Giai đoạn 1 để chứng minh số đúng.

→

Giai đoạn 3Lớp Tăng trưởng. Marketing và CSKH — dùng đơn hàng thật từ Giai đoạn 2 làm mẫu số, không dùng số nền tảng báo.

Việc phải làm ngay từ Giai đoạn 0, không hoãn được

Snapshot daily dữ liệu quảng cáo — Google chỉ còn lookback 37 tháng cho segment ngày; không snapshot hôm nay thì mất vĩnh viễn.
Bắt webhook CSKH — cửa sổ Zalo OpenAPI 7 ngày, không lấy kịp là mất.
Sync Nhanh.vn liên tục — quá 31 ngày là không lấy lại được theo ngày.
Lưu bản sao XML hoá đơn — nghĩa vụ pháp lý 10 năm thuộc về bạn, không phải nhà cung cấp.
Bảng tham số theo kỳ cho payroll — trước khi hard-code bất kỳ tỉ lệ nào.

Việc dễ bị bỏ quên nhưng có deadline pháp lý

Hồ sơ DPIA — nộp A05 trong 60 ngày kể từ ngày xử lý dữ liệu đầu tiên, cập nhật 6 tháng/lần.
Hồ sơ TIA — nếu dùng cloud region hoặc SaaS nước ngoài, nộp trong 60 ngày kể từ lần chuyển đầu tiên.
Quy trình báo cáo vi phạm 72 giờ — phải có sẵn trước khi cần dùng, kèm người chịu trách nhiệm.
Nhân sự bảo vệ DLCN — tối thiểu cao đẳng + 2 năm kinh nghiệm liên quan.
Nhật ký hệ thống 12 tháng — thiết kế log retention từ đầu, không bật sau.

Doanh nghiệp nhỏ và startup được hoãn 5 năm nghĩa vụ DPIA và bổ nhiệm nhân sự bảo vệ dữ liệu — trừ khi xử lý dữ liệu nhạy cảm, dữ liệu quy mô lớn, hoặc kinh doanh dịch vụ dữ liệu. Doanh nghiệp siêu nhỏ và hộ kinh doanh được miễn hoàn toàn với cùng điều kiện loại trừ. Lưu ý điều kiện loại trừ khá rộng — product telemetry nay là dữ liệu nhạy cảm, nên nhiều startup công nghệ không được hưởng miễn trừ này.

14 Quiz · 30 câu

Chọn đáp án cho tất cả các câu rồi bấm Nộp bài. Không chấm từng câu — chấm một lần khi nộp, đúng kiểu thi thật. Có thể sửa đáp án trước khi nộp.

Đã chọn 0 / 30

0 / 30

15 Nguồn tham chiếu & mức độ tin cậy

Nhóm nội dung	Nguồn	Mức tin cậy
Chế độ kế toán, thuế GTGT/TNDN, hoá đơn điện tử	Văn bản gốc: TT 99/2025, NĐ 254/2026, TT 91/2026, Luật 67/2025, NQ 204/2025, Luật 09/2026	Cao — có số hiệu tra cứu được
SHUI, lương tối thiểu vùng, thuế TNCN, BLLĐ	Luật 41/2024, NĐ 158/2025, NĐ 293/2025, Luật 109/2025, NQ 110/2025, NĐ 253/2026, NĐ 161/2026, BLLĐ 45/2019	Cao — đối chiếu nhiều nguồn
Bảo vệ dữ liệu cá nhân, an ninh mạng, chữ ký số	Luật 91/2025, NĐ 356/2025, NĐ 330/2026, Luật 116/2025, NĐ 333/2026, Luật GDĐT 20/2023, NĐ 23/2025	Cao
Lưu trữ chứng từ kế toán	Luật Kế toán 88/2015 Điều 41, NĐ 174/2016 Điều 12–15	Cao
API MISA AMIS, KiotViet, Haravan, Nhanh.vn, Casso, SePay, GHN, GHTK, Viettel Post, Odoo	Tài liệu kỹ thuật chính chủ của từng nhà cung cấp	Cao — đọc được tài liệu gốc
API Shopee, Lazada, TikTok Shop, Sapo, FAST, SAP B1, 1C	Cổng tài liệu tồn tại nhưng bị gate / JS-rendered / robots.txt	Thấp — phải tự xác minh khi có tài khoản developer
Cửa sổ tin nhắn Zalo OA, Messenger; thay đổi Meta & Google Ads 2026; Privacy Sandbox	Tài liệu chính chủ Zalo/Meta/Google + blog Privacy Sandbox	Cao
Debezium SQL Server CDC	Tài liệu Debezium chính thức	Cao
Thời hạn lưu trữ 24 tháng theo NĐ 333/2026	Con số gốc từ NĐ 53/2022 đã bị thay thế; bản chính NĐ 333/2026 chưa đối chiếu được điều khoản này	Chưa xác minh — phải đọc bản chính trước khi thiết kế
Chuẩn XML hoá đơn (QĐ 1271/QĐ-CT)	Ban hành dưới chế độ NĐ 123/NĐ 70 nay đã bãi bỏ — chưa rõ còn hiệu lực hay đã có quyết định thay thế	Chưa xác minh — xác nhận với Cục Thuế trước khi tích hợp

Hai điểm phải tự kiểm trước khi đưa vào production — được nêu lại ở đây vì chúng có rủi ro kỹ thuật cao nhất: (1) chuẩn XML hoá đơn điện tử dưới chế độ NĐ 254/2026 + TT 91/2026 mới vận hành từ 01/07/2026, quyết định kỹ thuật cũ có thể đã bị thay; (2) quy định lưu trữ dữ liệu tại Việt Nam theo NĐ 333/2026 ban hành 19/08/2026 — chỉ mới vài ngày, nguồn thứ cấp chưa trích dẫn đầy đủ điều khoản.

Tài liệu này là bản đồ, không phải spec. Rate limit, endpoint, TTL token, và cả văn bản pháp luật đều thay đổi — như chính năm 2026 đã chứng minh với 4 khung pháp lý bị thay trong 8 tháng. Dùng đây để biết cần hỏi gì và tra ở đâu, rồi xác minh lại tại thời điểm triển khai.