--- title: "Đồng bộ tồn kho giữa web, sàn thương mại điện tử và file Excel" url: https://phatdev.net/vi/blog/sync-inventory-web-marketplace lang: vi updated: 2026-10-21 alternate: en: https://phatdev.net/en/blog/sync-inventory-web-marketplace markdown: https://phatdev.net/vi/blog/sync-inventory-web-marketplace.md --- # Đồng bộ tồn kho giữa web, sàn thương mại điện tử và file Excel > Một chiếc loa cuối cùng, ba đơn cùng lúc. Vì sao tồn kho lệch, năm cách xử lý từ làm tay tới nối API, và nên bắt đầu từ đâu. Chuyên mục: Backend | Đăng: 2026-10-21 | Cấp độ: Trung cấp | 7 phút đọc Tags: inventory, sync, api, marketplace, webhook, ecommerce Chiều thứ sáu, cửa hàng còn đúng một chiếc loa cuối cùng. Cùng một lúc, khách mua trên web, khách khác chốt đơn trên sàn, còn nhân viên bán lẻ ngoài quầy thì đưa nốt cho người đang đứng đó. Ba đơn cho một chiếc loa. Hai khách sẽ nhận tin "xin lỗi, hết hàng", và một trong hai sẽ để lại đánh giá một sao. Đây là lỗi lệch tồn kho, và nó xuất hiện ở hầu hết shop bán trên nhiều nơi. Bài này giải thích vì sao nó xảy ra, các cách xử lý từ thủ công đến tự động, và nên bắt đầu từ đâu. ## Vì sao tồn kho bị lệch ![Một kho gốc nối tới web, sàn và bảng tính](https://phatdev.net/uploads/blog/sync-inventory-web-marketplace/sync-1920.webp) Gốc của vấn đề rất đơn giản: cùng một con số tồn kho nhưng được ghi ở nhiều nơi. Web có một số, mỗi sàn có một số, file Excel của kho có một số, phần mềm bán hàng ở quầy có một số. Mỗi nơi chỉ cập nhật khi có người hoặc có hệ thống nói cho nó biết. Hãy tưởng tượng bốn cuốn sổ ghi cùng một kho hàng, mỗi cuốn do một người giữ. Có hàng bán đi ở cuốn này thì ba cuốn kia vẫn ghi số cũ cho tới khi ai đó chép sang. Khoảng chờ đó là lúc bán trùng. Ngoài chuyện chậm, còn vài nguyên nhân hay gặp. Đơn bị huỷ hoặc khách trả hàng nhưng tồn kho không được cộng lại. Hàng đang nằm trong giỏ hoặc đơn chưa thanh toán, nơi này tính là đã giữ chỗ còn nơi kia thì chưa. Kho nhập thêm hàng nhưng quên cập nhật lên sàn. Hai người cùng sửa một file Excel và đè lên nhau. Mã sản phẩm ở mỗi nơi đặt một kiểu nên đối chiếu nhầm. ## Các cách làm, từ thủ công đến tự động ### Cách 1: Làm tay theo lịch Mỗi sáng và mỗi chiều, một người đối chiếu tồn kho giữa các nơi và sửa tay. Cách này phù hợp khi shop có vài chục sản phẩm và vài đơn mỗi ngày. Nó rẻ, không cần kỹ thuật, nhưng phụ thuộc người nhớ làm và vẫn có khoảng trống giữa hai lần cập nhật. ### Cách 2: Một file gốc, nhập xuất định kỳ Chọn một nơi làm "sổ gốc" (thường là file Excel hoặc phần mềm kho). Các nơi khác nhận số từ đó qua việc nhập file CSV hoặc Excel, mỗi ngày vài lần. Phần lớn nền tảng web và sàn đều có chức năng nhập tồn kho hàng loạt bằng file. Bạn bớt gõ tay và bớt sai, nhưng vẫn có độ trễ, và vẫn phải có người bấm. ### Cách 3: Chạy tự động theo lịch Một chương trình nhỏ chạy mỗi vài phút: đọc số từ sổ gốc, so với từng nơi, cập nhật chỗ nào khác. Chương trình này có thể đọc trực tiếp từ file hoặc cơ sở dữ liệu của phần mềm kho. Độ trễ giảm còn vài phút, và không cần người nhớ. ### Cách 4: Nối qua API, nghe sự kiện API là cách để hai phần mềm nói chuyện với nhau mà không cần người. Hầu hết các sàn lớn đều có nền tảng dành cho nhà phát triển, ví dụ [Shopee Open Platform](https://open.shopee.com/), [Lazada Open Platform](https://open.lazada.com/) và [TikTok Shop Partner Center](https://partner.tiktokshop.com/). Nền tảng web bán hàng cũng có API, như [WooCommerce REST API](https://woocommerce.github.io/woocommerce-rest-api-docs/). Khi nối bằng API, hệ thống của bạn có thể làm hai việc: đẩy số tồn kho mới lên sàn ngay khi có thay đổi, và nhận thông báo (nhiều nơi gọi là webhook) mỗi khi có đơn mới để trừ kho. Độ trễ xuống còn vài giây tới vài phút. Vài điều cần biết trước vì mỗi sàn khác nhau và có thể đổi theo thời gian: thường phải đăng ký tài khoản nhà phát triển và được duyệt, mỗi sàn có cách xác thực riêng, có giới hạn số lần gọi, và tài liệu cập nhật liên tục. Mình không liệt kê tên chức năng cụ thể ở đây vì sai một chi tiết là gây hại; hãy đọc tài liệu chính thức của sàn bạn dùng, hoặc nhờ dev đọc giúp. ### Cách 5: Dùng công cụ có sẵn Có những phần mềm quản lý bán hàng đa kênh làm sẵn việc đồng bộ. Ưu điểm là nhanh, không phải lập trình. Nhược điểm là trả phí hằng tháng, và không phải lúc nào cũng khớp với cách làm riêng của shop. Nếu quy trình của bạn khá chuẩn thì đây thường là lựa chọn hợp lý nhất. ## Nên bắt đầu từ đâu Trước hết, chọn **một** nơi làm sổ gốc. Mọi thay đổi lớn (nhập hàng, kiểm kê) ghi vào đây, các nơi khác chỉ là bản sao. Nếu không chọn được, lệch là điều chắc chắn. Sau đó, đếm quy mô: bao nhiêu sản phẩm, bao nhiêu kênh, mỗi ngày bao nhiêu đơn, hàng bán nhanh hay chậm. Shop ít đơn, hàng bán chậm thì cách 1 hoặc 2 là đủ. Hàng bán nhanh hoặc có hàng hiếm, đơn nhiều trong giờ cao điểm thì mới cần cách 3 hoặc 4. Có một mẹo rẻ mà hiệu quả cho mọi cách: giữ lại một lượng hàng an toàn. Ví dụ kho còn 3 chiếc thì chỉ hiển thị 1 hoặc 2 trên sàn. Nếu có chậm đồng bộ thì bạn vẫn còn đệm, thay vì bán trùng. ## Lỗi hay gặp khi tự động hoá Có shop nối hai chiều giữa web và sàn mà không có sổ gốc. Hai bên liên tục ghi đè số của nhau, và kết quả nhảy lung tung. Luôn có một hướng chính. Có shop cập nhật tồn kho mà quên tính đơn đang chờ thanh toán, nên hiển thị còn hàng trong khi hàng đã được giữ. Có shop chạy tự động mà không có nhật ký. Khi số lệch thì không ai biết lệch từ lúc nào, ở đâu. Hãy ghi lại mỗi lần cập nhật: giờ, sản phẩm, số cũ, số mới, nguồn. Và có shop không thử với hàng thật trước khi bật. Nên chạy thử với vài sản phẩm, so tay với thực tế vài ngày rồi mới mở rộng. ## Cho bạn nào viết code Một vài nguyên tắc dev nên giữ. Coi mỗi lần cập nhật là thao tác có thể chạy lại mà không gây hậu quả (gọi hai lần vẫn ra cùng kết quả), vì mạng lỗi thì sẽ phải thử lại. Cập nhật theo số tuyệt đối từ sổ gốc thay vì "trừ 1", để một lần lỡ nhịp không làm lệch mãi. Tôn trọng giới hạn số lần gọi của sàn và có cơ chế chờ rồi thử lại. Đối chiếu toàn bộ một lần mỗi đêm để bắt những chỗ lệch mà các sự kiện bỏ sót. Phần cơ chế cache và độ trễ có điểm chung với [Cho web nhanh hơn bằng Redis: nhớ tạm kết quả để database đỡ quá tải](https://phatdev.net/vi/blog/redis-cache-aside-api), còn cách thiết kế API an toàn khi gọi lại nằm ở [Thiết kế API cho người khác dùng: báo lỗi, chia trang, thử lại và giới hạn lượt gọi](https://phatdev.net/vi/blog/rest-api-design-practical). ## Nên làm gì tiếp theo Tuần này, làm một việc nhỏ: ghi ra giấy mỗi nơi đang lưu tồn kho, ai cập nhật, cập nhật lúc nào. Chỉ riêng bảng đó đã cho thấy lệch phát sinh ở đâu. Sau đó chọn sổ gốc, bật mức hàng an toàn, và quyết định cách nào hợp với quy mô của bạn. Nếu shop của bạn đã bán trên nhiều nơi và muốn tự động hoá, cứ liên hệ mình qua phatdev.net, kèm danh sách các kênh đang bán. Mình sẽ nói rõ cách nào đáng làm và cách nào chưa cần. ## Nguồn tham khảo - [Shopee Open Platform](https://open.shopee.com/) - [Lazada Open Platform](https://open.lazada.com/) - [TikTok Shop Partner Center](https://partner.tiktokshop.com/) - [WooCommerce REST API documentation](https://woocommerce.github.io/woocommerce-rest-api-docs/) ## Bài liên quan - [Thiết kế API cho người khác dùng: báo lỗi, chia trang, thử lại và giới hạn lượt gọi](https://phatdev.net/vi/blog/rest-api-design-practical.md) - [Cho web nhanh hơn bằng Redis: nhớ tạm kết quả để database đỡ quá tải](https://phatdev.net/vi/blog/redis-cache-aside-api.md) - [Viết API đầu tiên với FastAPI: quản lý sản phẩm, kiểm dữ liệu và tài liệu tự sinh](https://phatdev.net/vi/blog/python-fastapi-first-api.md)