Tối ưu vận hành đơn hàng đa kênh: Đồng bộ tồn kho tức thời, quy trình đóng gói chuẩn và đối soát vận chuyển
Kinh doanh Online 03/09/2026 · 27 phút đọc

Tối ưu vận hành đơn hàng đa kênh: Đồng bộ tồn kho tức thời, quy trình đóng gói chuẩn và đối soát vận chuyển

Một nguồn tồn kho dùng chung giúp chặn bán vượt số lượng. Quy trình còn phải nối đơn hàng, đóng gói, vận chuyển và đối soát giữa mọi kênh.

Một SKU còn đúng một chiếc. Website vừa nhận thanh toán, trong lúc cửa hàng đã bán chiếc đó và TikTok Shop vẫn cho phép một khách khác đặt mua. Ba màn hình đều báo giao dịch hợp lệ; kho chỉ có một món hàng. Đến lúc in phiếu nhặt, nhân viên mới biết hai đơn sẽ không thể hoàn thành.

Đây là lỗi thiết kế vận hành. Mỗi kênh đang giữ một con số riêng, còn doanh nghiệp chưa quy định hệ thống nào có quyền trả lời câu hỏi: ngay lúc này còn bao nhiêu hàng có thể bán? Sửa số sau mỗi lần phát hiện chỉ trì hoãn lần lệch tồn tiếp theo.

Quản lý đơn hàng online đa kênh cần ba lớp kiểm soát nối liền nhau: một nguồn tồn kho có thẩm quyền, một quy trình xác nhận hàng rời kho và một phép đối soát tiền sau giao hàng. Bài này cung cấp sơ đồ SSOT, checklist đóng gói sáu bước và mẫu đối soát cước, COD để đưa vào quy trình nội bộ. Nếu doanh nghiệp còn ở giai đoạn chọn kênh, nên đọc trước lộ trình kinh doanh online cho SMEcách phân vai giữa sàn, mạng xã hội và website.

1. Lệch tồn kho bắt đầu trước khi kho báo hết hàng

Một shop thường nhìn thấy lệch tồn ở kết quả cuối: hủy đơn, gọi khách xin đổi màu hoặc mượn hàng từ chi nhánh khác. Nguyên nhân xuất hiện sớm hơn, khi cùng một SKU có nhiều tên, đơn vị tính hoặc nơi được phép sửa số lượng. Một hộp được nhập theo mã A-01 trên phần mềm kế toán, đăng thành A01-BLUE trên sàn và được nhân viên gọi bằng tên sản phẩm. Hệ thống không thể tự biết ba bản ghi ấy là một món.

Bán vượt tồn thường đến từ đơn mới chưa kịp giữ hàng; đơn hủy hoàn tồn sai; hàng chuyển kho được cộng ở nơi nhận trước khi trừ ở nơi gửi; hoặc hàng hỏng và hàng chờ kiểm tra vẫn nằm trong số được bán. Đồng bộ nhanh không sửa được dữ liệu sai nghĩa. Trước khi nối API, shop phải chuẩn hóa SKU, biến thể, vị trí kho và trạng thái hàng.

Một đơn hủy có thể ảnh hưởng đến quyền lợi của cả gian hàng

TikTok Shop gọi tỷ lệ hủy do lỗi của người bán là SFCR. Theo tài liệu SFCR áp dụng tại Việt Nam, chỉ số này tính trên bảy ngày, gồm trường hợp hết hàng, sai giá và tự động hủy vì người bán không chuẩn bị hoặc bàn giao kiện đúng hạn. TikTok Shop yêu cầu người bán đặt mục tiêu dưới 2,5%; khi SFCR cao, nền tảng có thể giới hạn lượng đơn và trừ điểm tình trạng tài khoản. Ngưỡng thực thi có thể đổi, nên quản lý phải kiểm tra Seller Center khi cập nhật SOP.

Ở Shopee, tỷ lệ đơn không thành công và giao trễ thuộc nhóm tiêu chí để duy trì Shop Yêu Thích. Điều khoản Shopee Mall cũng nêu các tiêu chuẩn vận hành được đánh giá qua Hệ thống Sao Quả Tạ và nhãn Mall có thể bị gỡ nếu điểm phạt vượt mức cho phép. Nhãn Shop Yêu Thích xuất hiện trên gian hàng, sản phẩm và trong bộ lọc tìm kiếm; mất nhãn làm mất một điểm nhận diện cùng một bề mặt lọc. Shopee không công bố công thức đủ chi tiết để nói một mức NFR sẽ làm sản phẩm tụt một số bậc tìm kiếm xác định.

TikTok Shop cho biết hiệu suất cửa hàng tốt có thể hỗ trợ khả năng nhận lưu lượng và điều kiện tham gia chiến dịch. Vì thế, nên xem hủy đơn do hết hàng là rủi ro có thể lan sang phân phối nội dung, chiến dịch và niềm tin của khách, thay vì gắn nó với lời đồn về thuật toán. Chỉ số cần quản trị là tỷ lệ và nguyên nhân hủy theo SKU, kho, kênh và ca làm việc.

Theo dõi hằng tuần: số đơn hủy do hết hàng trên tổng đơn hợp lệ; thời gian từ lúc nhận đơn đến lúc SSOT giữ tồn; số lần tồn âm; số sự kiện đồng bộ lỗi; và số đơn phải đổi SKU sau xác nhận.

Doanh nghiệp có thể đặt phần vận hành này trong bức tranh rộng hơn của kinh doanh online toàn diện. Thêm một kênh chỉ có ích khi kho thực hiện được lời hứa mà kênh đó vừa bán.

Minh họa kiến trúc đồng bộ tồn kho tập trung Single Source of Truth theo phong cách Fluent 2.5D

2. Kiến trúc đồng bộ tồn kho tập trung: Single Source of Truth

Single Source of Truth, viết tắt SSOT, là bản ghi có thẩm quyền mà các kênh phải tham chiếu khi công bố số lượng có thể bán. SSOT có thể nằm trong OMS, ERP hoặc WMS. Tên phần mềm ít quan trọng hơn quy tắc: Shopee, TikTok Shop, website và POS không được tự duy trì bốn sự thật độc lập rồi ghép lại cuối ngày.

Tách rõ tồn thực tế, tồn đang giữ và tồn khả dụng

  • Tồn kho thực tế (on-hand): số đơn vị vật lý được ghi nhận tại một vị trí. Hàng đang chuyển kho cần trạng thái riêng để không xuất hiện đồng thời ở nơi gửi lẫn nơi nhận.
  • Tồn kho đang giữ (reserved hoặc hold stock): hàng dành cho đơn chưa hoàn tất. Shop phải chọn thời điểm giữ, chẳng hạn khi đặt đơn, thanh toán hoặc duyệt COD, và quy định lúc giải phóng.
  • Tồn kho khả dụng (available-to-sell): số lượng hệ thống cho phép các kênh bán tiếp, sau khi trừ tồn đang giữ, tồn an toàn và hàng bị khóa vì kiểm định, hư hỏng hoặc xử lý hoàn.

Tồn khả dụng = tồn thực tế – tồn đang giữ – tồn an toàn – tồn không đủ điều kiện bán.

Công thức áp dụng ở cấp SKU và vị trí kho. Nếu hai cửa hàng đều có một chiếc nhưng chỉ một nơi đóng gói được đơn online, SSOT không nên quảng bá hai chiếc. Quy tắc phân bổ còn phải xét giờ cắt đơn, vùng phục vụ và khả năng chuyển kho.

Sơ đồ luồng đồng bộ tồn kho tập trung

Shopee, TikTok Shop, website, POS → bộ tiếp nhận webhook/API → hàng đợi sự kiện → OMS/SSOT kiểm tra phiên bản và giữ tồn → WMS tạo nhiệm vụ nhặt hàng → bộ phát tồn khả dụng → cập nhật ngược về các kênh. Để định hướng tổng thể trước khi triển khai, bạn có thể tham khảo lộ trình kinh doanh online.

Khi một kênh báo đơn mới, lớp tiếp nhận xác minh nguồn gửi, lưu mã sự kiện và đưa sự kiện vào hàng đợi. SSOT kiểm tra sự kiện đã xử lý chưa, đọc phiên bản tồn mới nhất rồi tạo hold. Khi giao dịch giữ tồn thành công, bộ phát gửi số khả dụng mới về các kênh còn lại. Kho chỉ nhận pick-list nếu đơn có reservation hợp lệ.

Luồng được gọi là hai chiều vì đơn và trạng thái đi từ kênh về trung tâm, còn tồn khả dụng đi từ trung tâm trở lại kênh. Mọi hệ thống không được cùng quyền sửa tồn. WMS xác nhận xuất kho, OMS giữ hàng, ERP ghi nhận giá trị kế toán, còn kênh bán quản lý giao dịch với khách.

3-5 giây là mục tiêu vận hành, không phải lời bảo đảm

Với SKU bán nhanh, doanh nghiệp có thể đặt SLO nội bộ: 95% sự kiện từ lúc nhận webhook đến khi gửi cập nhật sang các kênh hoàn tất trong 3-5 giây. Độ trễ còn phụ thuộc thời điểm nền tảng phát webhook, giới hạn API, mạng và hàng đợi. Vì vậy, dashboard nên đo p50, p95, p99, số lần gọi lại và tuổi của bản cập nhật cuối theo từng kênh.

Ba cơ chế ngăn lỗi lặp là bắt buộc. Idempotency bảo đảm một webhook gửi hai lần chỉ trừ tồn một lần. Versioning ngăn bản cập nhật cũ ghi đè bản mới. Tác vụ đối soát định kỳ kéo snapshot từ từng kênh về SSOT để sửa sai khi webhook bị mất. Đồng bộ tức thời vẫn cần đối soát bù.

Trạng thái đơn Xử lý tồn Điểm kiểm soát
Đơn mới hợp lệ Tạo hold theo SKU và kho Khóa giao dịch để tránh hai đơn lấy cùng hàng
Chờ thanh toán Giữ theo thời hạn cấu hình Hết hạn thì giải phóng có nhật ký
Đã đóng gói Chuyển sang chờ xuất Chỉ chuyển sau khi quét đúng SKU
Đã bàn giao Trừ tồn thực tế Gắn mã vận đơn và biên bản
Hủy trước xuất Giải phóng hold Không hoàn hai lần khi sự kiện lặp
Hoàn về kho Chờ kiểm định Chưa cộng vào tồn bán ngay

BẢNG DỮ LIỆU CHI TIẾT • CHẠM ĐỂ PHÓNG TO
Bảng dữ liệu chi tiết - Tối ưu vận hành đơn hàng đa kênh: Đồng bộ tồn kho tức thời, quy trình đóng gói chuẩn và đối soát vận chuyển
🔍 Mở toàn màn hình (phóng to/thu nhỏ)

Nếu website mới trở thành nguồn đơn, hãy xử lý tồn trước ngày mở bán. Bài khi nào SME cần website riêng giải thích vì sao quy trình kho ổn định là một điều kiện triển khai.

3. Quy trình đóng gói 6 bước: mỗi kiện hàng phải để lại dấu vết

SSOT trả lời hàng nào được bán. Quy trình đóng gói chứng minh kho đã lấy đúng hàng và giao đúng kiện. Camera chỉ hữu ích khi video nối được với mã đơn; một thư mục chứa hàng nghìn clip không đặt tên khó giúp nhân viên tìm bằng chứng trước hạn khiếu nại.

Checklist sáu bước tại bàn đóng gói

  1. Xuất pick-list theo cụm đơn. OMS nhóm đơn theo khu vực kho hoặc tuyến nhặt. Mỗi dòng có mã đơn, SKU, biến thể, số lượng và vị trí. Thiếu hàng phải chuyển sang luồng ngoại lệ.
  2. Quét mã vạch kiểm tra sản phẩm. Nhân viên quét mã đơn rồi từng SKU. Hệ thống so biến thể và số lượng; chỉ quản lý mới được phê duyệt ngoại lệ có lý do.
  3. Ghi hình quá trình bọc lót. Camera góc rộng nhìn rõ mặt bàn, sản phẩm, phụ kiện và thao tác đưa hàng vào hộp. Với hàng có serial, hệ thống ghi thêm serial bằng máy quét hoặc ảnh.
  4. Dán tem niêm phong chống rạch. Tem đi qua mép mở chính; số lô tem được lưu với đơn nếu hàng có giá trị cao. Tem cho thấy dấu hiệu mở hộp nhưng không thay thế vật liệu chống sốc.
  5. In phiếu giao và dán phẳng. Mã vạch không gấp qua cạnh hộp, không bị băng dính phản sáng che vùng quét. Quét lại mã vận đơn để khóa quan hệ giữa đơn, kiện và video.
  6. Ký biên bản bàn giao với bưu tá. Biên bản ghi ngày giờ, hãng, ca lấy, số kiện theo mã hoặc dải mã, tên người giao và người nhận. Hai bên xử lý chênh lệch trước khi xe rời điểm lấy.

Tiêu chuẩn bằng chứng bàn giao

  • Ảnh và video tra cứu được bằng mã đơn hoặc mã vận đơn, có dấu thời gian và người thao tác.
  • Video nhìn thấy sản phẩm, phụ kiện và miệng hộp lúc niêm phong; ảnh cuối cho thấy nhãn giao cùng tem còn nguyên.
  • Biên bản khớp tổng số kiện trên manifest. Nếu bưu tá không ký từng mã, shop lưu dải mã cùng tổng kiện.
  • Thời hạn lưu căn cứ vào kỳ khiếu nại dài nhất của sàn và hợp đồng vận chuyển; quyền xem clip được phân vai và ghi nhật ký.

Bằng chứng tốt làm rõ chuỗi kiểm soát nhưng không bảo đảm sàn xử thắng mọi khiếu nại. Nhân viên vẫn phải nộp đúng tài liệu, đúng hạn và giữ file gốc. Camera có thể ghi thông tin cá nhân trên nhãn, nên doanh nghiệp phải giới hạn góc quay, thời gian lưu và người truy cập.

Minh họa bảng kiểm soát đối soát cước vận chuyển và dòng tiền COD 3 chiều theo phong cách Fluent 2.5D

4. Kỹ thuật đối soát cước vận chuyển và tiền COD: Bịt lỗ rò rỉ lợi nhuận

Một đơn giao thành công vẫn có thể lỗ hơn dự kiến nếu hãng ghi kích thước lớn hơn, áp sai bảng giá hoặc chuyển COD thiếu. Kế toán chỉ nhìn số tiền về ngân hàng sẽ khó biết chênh lệch nằm ở giá hàng, cước, phụ phí hay thời điểm chuyển khoản.

Đối soát ba chiều theo từng mã vận đơn

  • Dữ liệu kho: cân nặng sau đóng gói, ba kích thước phủ bì, ảnh cân đo, dịch vụ đã chọn và COD phải thu.
  • Dữ liệu hãng vận chuyển: khối lượng dùng tính cước, vùng giao, phụ phí, trạng thái và COD hãng xác nhận đã thu.
  • Dữ liệu tài chính: cước thực trừ, COD thực chuyển, phí COD, hoàn phí hoặc điều chỉnh trên sao kê và bảng kê đối tác.

Khóa nối ba nguồn là mã vận đơn, kèm mã đơn nội bộ để truy ngược video và phiếu xuất. Hệ thống đánh dấu ngoại lệ khi khối lượng tính cước vượt số kho ngoài dung sai; cước thực khác cước dự kiến; hoặc COD thực nhận khác COD phải thu sau các khoản được hợp đồng cho phép.

Khối lượng thể tích phải dùng đúng hệ số hợp đồng

Khối lượng thể tích (kg) = Dài (cm) x Rộng (cm) x Cao (cm) / hệ số quy đổi. Ở bước tiếp theo, Kinh doanh online nên bắt đầu sẽ giúp bạn mở rộng cách tiếp cận này.

Với hệ số 5000, hộp 40 x 30 x 25 cm có khối lượng quy đổi 6 kg. Nếu cân thực tế là 2,2 kg và hợp đồng tính theo số lớn hơn, hãng lấy 6 kg trước khi làm tròn theo nấc cước. Công thức chỉ đúng khi dịch vụ dùng hệ số 5000. GHTK công bố hệ số 6000 cho Express và 4000 cho BBS trong hướng dẫn của họ. Bảng đối soát phải lưu hệ số theo hãng, gói dịch vụ và thời gian hiệu lực.

Kích thước tính cước là kích thước kiện sau đóng gói, không phải kích thước sản phẩm trong danh mục. Bàn đóng gói nên có cân, thước hoặc thiết bị đo; ảnh bằng chứng đặt mã vận đơn cùng kết quả cân đo trong một khung hình nếu quy trình khiếu nại của đối tác chấp nhận.

Mẫu bảng đối soát cước và COD

Trường dữ liệu Nguồn Ví dụ giả định Quy tắc kiểm tra
Mã vận đơn / mã đơn OMS VD001 / WEB-1024 Không trùng hoặc bỏ trống
Cân kho / kích thước Bàn đóng gói 2,2 kg / 40 x 30 x 25 cm Có ảnh và thời điểm đo
Hệ số / khối lượng quy đổi Hợp đồng 5000 / 6 kg Dùng biểu phí còn hiệu lực
Khối lượng hãng ghi Hãng vận chuyển 8 kg Cảnh báo vì cao hơn số kho
Cước dự kiến / thực trừ OMS / bảng kê 42.000 / 56.000 đồng Chênh 14.000 đồng, mở kiểm tra
COD phải thu / hãng xác nhận Đơn / hãng 780.000 / 780.000 đồng Khớp trước phí thỏa thuận
COD thực nhận Sao kê 724.000 đồng Giải thích được khoản trừ
Trạng thái xử lý Kế toán vận hành Đang khiếu nại Có người phụ trách và hạn

BẢNG DỮ LIỆU CHI TIẾT • CHẠM ĐỂ PHÓNG TO
Bảng dữ liệu chi tiết - Tối ưu vận hành đơn hàng đa kênh: Đồng bộ tồn kho tức thời, quy trình đóng gói chuẩn và đối soát vận chuyển
🔍 Mở toàn màn hình (phóng to/thu nhỏ)

Ví dụ trên chỉ minh họa. Nếu hợp đồng cho phép trừ 56.000 đồng cước vào COD, khoản thực nhận 724.000 đồng khớp về số học nhưng cước vẫn bị tranh chấp vì chênh khối lượng. Kiểm tra COD và kiểm tra cước là hai phép đối soát riêng.

Hồ sơ khiếu nại nhảy cước

Mỗi ngoại lệ cần mã vận đơn, điều khoản áp dụng, ảnh cân đo, video đóng gói, dữ liệu hãng, phép tính chênh và yêu cầu điều chỉnh. Nhân viên gửi qua kênh được hợp đồng công nhận, lưu mã ticket và ngày hết hạn. Nếu hãng có ảnh đo lại, hãy so vị trí thước, đơn vị đo, cách làm tròn và tình trạng bao bì.

Chênh nhỏ có thể gom theo lô; khoản lớn hoặc lỗi lặp phải báo quản lý. Ngưỡng dựa trên chi phí xử lý và biên lợi nhuận. Một khiếu nại 3.000 đồng có thể không đáng mở riêng, nhưng 500 đơn cùng lỗi cần được điều tra. Bảng tính chi phí đơn hàng KDO-05 giúp đưa cước thực, phí sàn và hoàn hàng vào cùng phép tính.

5. Bảng điều hành nên ưu tiên ngoại lệ

Màn hình điều hành nên đưa các trường hợp sắp gây thiệt hại lên trước: đơn chưa giữ được tồn, SKU tồn âm, kiện thiếu manifest, COD quá ngày và cước vượt dung sai. Mỗi cảnh báo phải có người sở hữu cùng hạn xử lý.

  • Tỷ lệ hủy do hết hàng theo kênh, kho và SKU.
  • Độ chính xác tồn, độ trễ đồng bộ p95 và số sự kiện phải chạy lại.
  • Tỷ lệ quét sai, kiện thiếu bằng chứng, tổng cước chênh và COD đến hạn chưa nhận.

6. Triển khai theo thứ tự: dữ liệu, quy trình, rồi tự động hóa

Một shop ít đơn chưa chắc cần WMS. Bảng tính vẫn dùng được khi chỉ một người sửa tồn, SKU thống nhất và lượng đơn đủ thấp để kiểm tra theo ca. Dấu hiệu cần OMS hoặc WMS là xung đột lặp lại: nhiều người bán cùng lúc, nhiều kho, biến thể lớn, đơn cao điểm vượt sức kiểm tra hoặc đối soát tốn nhiều ngày công.

1. Làm sạch quyền sở hữu dữ liệu

Lập danh mục SKU gốc, mapping từng kênh, kho cấp hàng và trạng thái tồn. Chỉ định SSOT hiện tại, dù ban đầu là một hệ thống đơn giản. Khóa quyền sửa tùy tiện, quy định cách nhập, chuyển, hủy và hoàn. Kiểm kê SKU bán nhanh trước khi bật đồng bộ. Khi cần chuyển từ kế hoạch sang triển khai thực tế, lập trình website bán hàng là bước tiếp theo phù hợp.

2. Chạy thử một luồng hẹp

Chọn một kho, một nhóm SKU và hai kênh. Thử đơn trùng, webhook lặp, hủy sau thanh toán, API gián đoạn và hàng hoàn. So tồn thực tế với SSOT sau mỗi kịch bản. Chỉ mở rộng khi đội vận hành biết cách đưa hệ thống về trạng thái đúng.

3. Chuẩn hóa đóng gói và đối soát

Đặt mã vạch, camera, cân đo và máy in trong cùng luồng thao tác. Thiết kế manifest bàn giao. Nhập biểu phí cùng hệ số theo hợp đồng, rồi chạy đối soát song song với cách cũ qua ít nhất một kỳ thanh toán.

4. Mở rộng và đặt ngưỡng kiểm soát

Mở thêm kênh, kho hoặc hãng theo từng đợt. Đặt SLO 3-5 giây nếu hạ tầng và API cho phép, nhưng duy trì tác vụ đối soát bù. Xem lại ngưỡng hold, tồn an toàn và dung sai cước sau đợt sale. Chiến lược đa kênh KDO-09 giúp tránh thêm kênh chỉ vì kênh đó đang được chú ý.

Tiêu chí nghiệm thu: tạo đơn thử ở bất kỳ kênh nào, tồn khả dụng giảm đúng ở các kênh còn lại; quét sai SKU thì không thể hoàn tất; kiện bàn giao truy được video; và một dòng cước truy ngược được cân nặng, kích thước cùng biểu phí.

7. Hệ thống tốt làm cho sai lệch lộ ra sớm

Không có kiến trúc nào ngăn được mọi lỗi mạng, thao tác hoặc dữ liệu đầu vào. Một hệ thống quản lý đơn hàng thương mại điện tử đáng tin cậy phát hiện sai lệch khi còn đủ thời gian sửa: trước lúc nhận thêm đơn, trước khi dán nhãn sai và trước khi kỳ đối soát bị khóa.

Thứ tự đầu tư khá rõ: chuẩn hóa SKU và quyền ghi tồn; tách tồn thực tế, tồn đang giữ với tồn khả dụng; kết nối các kênh qua sự kiện có khả năng thử lại; sau đó buộc mỗi kiện đi qua sáu điểm kiểm soát và ghép dữ liệu kho, hãng vận chuyển, sao kê trên cùng mã vận đơn.

Chân Trời Tương Lai cung cấp giải pháp quản lý kho đa kênh và đồng bộ đơn hàng tự động cho doanh nghiệp cần tích hợp website, sàn, POS, OMS hoặc ERP. Phạm vi phù hợp chỉ xác định được sau khi rà SKU, luồng đơn, API từng kênh và hợp đồng vận chuyển; shop có quy trình đơn giản có thể chưa cần hệ thống tùy biến.

Xác định điểm gây lệch tồn và thất thoát cước trong luồng hiện tại

RÀ SOÁT VẬN HÀNH ĐA KÊNH

Xác định điểm gây lệch tồn và thất thoát cước trong luồng hiện tại

Mang theo danh mục SKU, một kỳ đối soát và sơ đồ các kênh đang bán. Chúng tôi sẽ cùng bạn xác định SSOT, điểm cần giữ tồn và phạm vi tích hợp phù hợp.

📞 Hotline: 0325.112.310

✉️ Email: [email protected]

🌐 chantroituonglai.com

Future Horizon

Tác giả

Future Horizon

Mục tiêu thành lập và xây dựng với sứ mệnh mang lại những công cụ và giải pháp kỹ thuật số (công cụ bán hàng online) tốt nhất cho các cửa hàng, doanh nghiệp nhỏ, hay đơn giản là những người mong muốn đạt được thành tựu trên không gian mạng nhưng cần sự giúp đỡ.

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Giỏ hàng của bạn 0

Giỏ hàng hiện đang trống

Thanh toán
0