Tóm tắt nhanh: một đơn cần ba lần “chốt” khác nhau
Muốn biết đơn nào thật sự có lãi, doanh nghiệp không nên chờ cuối tháng rồi lấy tiền sàn chia ngược cho số đơn, cũng không nên tin ngay con số profit hiện lúc vừa phát sinh đơn. Cách đủ chặt là giữ ba phiên bản. Estimated margin dùng để kiểm giá và campaign trước khi kho làm hàng. Settled margin dùng fee và cash thực tế để đối soát. Realized contribution bổ sung hàng hoàn, QC, rework, write-off, bồi thường và late adjustment sau khi đủ bằng chứng. Mỗi phiên bản phải có thời điểm, nguồn, rule version và trạng thái completeness.
Nếu điểm nghẽn chỉ là gom đơn và file settlement, OMS-only có thể đủ ở giai đoạn đầu. Khi lợi nhuận phụ thuộc vào SKU thực xuất, barcode, bin location, PDA, split parcel, picking, checking, packing, vật tư, nhiều kho/3PL, return QC và phần giá trị hàng phục hồi được, cần dữ liệu OMS + WMS. Không có một ngưỡng đơn chung: hãy nhìn số fee code, tỷ lệ return, số node, mức phức tạp SKU và số giờ con người bỏ ra để giải thích chênh lệch.
Thông tin thực thể liên quan
| Thực thể | Vai trò trong lợi nhuận đơn |
|---|---|
| JST ERP Việt Nam | Lớp ERP/OMS + WMS cho doanh nghiệp ecommerce Việt Nam cần nối đơn đa kênh, kho, fulfillment, COD, settlement, hàng hoàn và báo cáo vận hành. |
| OMS | Sở hữu order/line, shop/channel, price, voucher, status, COD, reservation, parcel relation và settlement state phía seller. |
| WMS | Sở hữu physical execution: SKU/lot, bin, PDA task, pick, check, pack, material, handover, return receiving, QC và inventory adjustment. |
| Marketplace/carrier/3PL | Phát sinh fee, cash, parcel, custody, return, claim và adjustment event cần đối soát bằng ID và thời điểm. |
| Finance/management accounting | Định nghĩa cost, accrual, period close, late adjustment, allocation và sign-off; không để dashboard tự quyết rule kế toán. |
1. Khoảng trống nội dung: “có báo cáo lợi nhuận” chưa đồng nghĩa số đủ để ra quyết định
Rà soát nguồn công khai cho thấy thị trường đã tiến xa hơn các bài chỉ liệt kê phí. BigSeller mô tả báo cáo lợi nhuận theo đơn, shop và SKU. Haravan nói rõ phí sàn tạm tính có thể thay đổi đến khi hoàn tất. Sapo đưa giá vốn, phí sàn, vận hành và voucher vào công thức bảo vệ margin. Shopee Help cho thấy return có thể đảo doanh thu, giá vốn, tạo chi phí khác và bồi thường ở các thời điểm khác nhau. Đây là những mảnh ghép hữu ích.
Khoảng trống còn lại nằm ở governance: lúc nào số chuyển từ ước tính sang settled và realized; làm sao giữ lịch sử khi fee đổi; refund một phần map về order line nào; hàng hoàn có còn đủ giá trị; chi phí kho phân theo driver nào; late adjustment vào kỳ nào; ai đóng variance. Seller discussion xác nhận nỗi đau nhưng không được dùng làm benchmark. Bài này chuyển những câu “tùy phí”, “tùy hàng hoàn” thành data contract, công thức, timeline và checklist nghiệm thu.
| Nguồn đối chiếu | Nội dung đã có | Khoảng trống vận hành |
|---|---|---|
| BigSeller – Báo cáo lợi nhuận | Công khai lợi nhuận theo đơn, gian hàng và SKU; thời gian quyết toán dựa trên giao dịch cuối và có phân biệt một số trạng thái kênh. | Buyer vẫn cần quy tắc riêng cho estimated–settled–realized, cost version, return cohort, accrual, close/reopen và variance owner. |
| Haravan – Phí sàn tạm tính | Nêu rõ phí sàn tạm tính là ước tính và số thực nhận có thể tiếp tục thay đổi đến khi đơn hoàn tất. | Chưa thay cho order-profit ledger nối phí ước tính với fee line thực tế, giá vốn xuất kho, QC hàng hoàn và period close. |
| Sapo – Bảo vệ lợi nhuận khi sàn tăng phí | Khuyến nghị đưa giá vốn, phí sàn, vận hành, voucher và lợi nhuận mục tiêu vào quyết định giá. | Công thức giá bán hữu ích nhưng chưa xử lý thời điểm ghi nhận, cohort hoàn, fee version, allocation và bằng chứng theo từng đơn. |
| Shopee Help – quản lý trả hàng/hoàn tiền | Cho thấy doanh thu, giá vốn, chi phí khác và bồi thường có thể được ghi nhận/điều chỉnh ở các bước khác nhau của return. | Xác nhận phải tách financial event với physical return/QC; buyer đa kênh vẫn cần taxonomy chung giữa các sàn. |
| SERP và seller discussion công khai | Lặp lại câu hỏi phí tăng, lợi nhuận mỏng, đơn hoàn, COD, chi phí quảng cáo và dashboard không khớp. | Pain point xác nhận nhu cầu; ý kiến cá nhân và số lẻ không được dùng làm benchmark ngành. |
So sánh nhanh theo mức độ vận hành: estimated, settled và realized
Một đơn không có một con số lợi nhuận bất biến. Nó có chuỗi ước tính được cải thiện dần khi bằng chứng đến. Điều quan trọng là không ghi đè: quản lý cần biết ở thời điểm nhận đơn hệ thống đã dự báo gì, settlement đã thay đổi gì, và return/claim làm kết quả cuối lệch bao nhiêu. Khi đó pricing team mới cải thiện rule thay vì tranh luận bằng ký ức.
| Lớp | Thời điểm | Dữ liệu chính | Dùng để làm gì |
|---|---|---|---|
| Estimated margin | Ngay khi đơn hợp lệ hoặc trước release | Giá bán, voucher dự kiến, fee rule hiện hành, COGS snapshot, standard fulfillment cost | Pricing, campaign guard và cảnh báo đơn âm dự kiến |
| Fulfilled margin | Sau pick–check–pack và bàn giao | SKU/quantity thực xuất, parcel, vật tư, trọng lượng, split, rework, carrier service | Nhìn chi phí thực thi và lỗi kho trước khi tiền về |
| Settled margin | Khi nhận đủ fee/settlement line chính | Tiền thực nhận, phí thực tế, refund/adjustment, COD, claim/compensation đã ghi | Đối soát finance và variance so với estimated |
| Realized contribution | Sau cửa sổ return/claim hoặc accrual đủ tin cậy | Settled margin + return recovery − return/QC/rework/write-off − late adjustments | Ra quyết định SKU, kênh, campaign và giá |
| Fully loaded profit | Kỳ quản trị sau phân bổ overhead | Realized contribution − chi phí chung được phân bổ theo driver | P&L quản trị; không dùng để che unit economics trực tiếp |
2. Bắt đầu bằng grain và identity, không bắt đầu bằng dashboard
Grain an toàn nhất thường là order line hoặc allocation line, vì một đơn có thể có nhiều SKU, nhiều warehouse node, nhiều parcel, refund một phần và nhiều settlement line. Nếu chỉ lưu một dòng trên order, doanh nghiệp buộc phải chia đều các khoản không đều hoặc mất lineage. Combo cần bung component cho COGS và warehouse execution nhưng vẫn giữ bundle ID để giải thích giá bán. Một return line phải nối được original order line và parcel đã giao.
Identity map phải chống duplicate và đổi mã. Channel order ID không đủ nếu sàn tái sử dụng sub-order, split parcel hoặc tạo return ID riêng. Dùng internal immutable ID, lưu external ID theo source, và đặt unique/idempotency rule. File settlement ingest cần source file checksum, row ID và batch ID để chạy lại không cộng tiền hai lần.
| Nhóm dữ liệu | Trường tối thiểu | Nguyên tắc |
|---|---|---|
| Order identity | channel, shop, order ID, order line, parcel, settlement line, return line | Không ghép bằng tên khách hoặc số tiền khi có ID tốt hơn |
| Product identity | internal SKU, channel SKU, combo component, UoM, lot/serial nếu có | Giữ mapping có effective date và lịch sử |
| Revenue | item gross, seller discount, platform subsidy, shipping charged, tax treatment | Tách khoản shop chịu khỏi khoản nền tảng tài trợ |
| Marketplace/payment | commission, fixed/service/payment fee, affiliate, program fee, adjustment | Mỗi fee line giữ code, basis, rate/version và source |
| Logistics/COD | outbound, COD, remote/weight surcharge, return shipping, claim | Nhãn in không phải bằng chứng handover; settlement không phải parcel event |
| COGS | cost layer/version, quantity shipped, write-off, recoverable return value | Không dùng giá vốn hiện tại để viết lại lịch sử |
| Warehouse execution | node, pick/check/pack, material, labor standard/actual, rework, split | WMS/PDA cung cấp event và reason thay vì nhập số tổng cuối tháng |
| Returns | return ID/line, refund, received, QC grade, disposition, restock, salvage | Refund và return-to-stock là hai event độc lập |
| Period control | order date, ship date, delivery date, settlement date, return date, close batch | Một dashboard phải nói rõ đang cohort theo ngày nào |
3. Công thức lợi nhuận: giữ các tầng để không trộn câu hỏi
Chủ shop hỏi “đơn này lời bao nhiêu” có thể đang hỏi ba việc: sản phẩm có tạo contribution dương không; kênh/campaign sau fee và logistics có hiệu quả không; hay doanh nghiệp sau mọi overhead có lãi không. Một chỉ số không trả lời tốt cả ba. Vì vậy nên giữ CM1, CM2, realized contribution và fully loaded view riêng. Đây là công thức quản trị minh họa; cách ghi nhận kế toán, thuế và hóa đơn cần theo chính sách doanh nghiệp và chuyên gia phù hợp.
| Chỉ số | Công thức vận hành | Lưu ý |
|---|---|---|
| Net merchandise revenue | Giá trị hàng gộp − voucher/discount do shop chịu − refund hàng | Không trừ trợ giá do nền tảng tài trợ hai lần |
| Net cash from channel | Tiền hàng + khoản hoàn/trợ cấp/bồi thường − toàn bộ fee/adjustment/withholding thực tế | Khớp tổng file settlement và dòng ngân hàng/ví |
| Order contribution 1 (CM1) | Net merchandise revenue − COGS theo quantity thực xuất | Đo economics sản phẩm trước phí kênh và fulfillment |
| Order contribution 2 (CM2) | CM1 − phí sàn/thanh toán/affiliate − logistics/COD − fulfillment trực tiếp | Thước đo chính để so đơn/kênh trước ads và overhead |
| Realized contribution | CM2 − return/refund/QC/rework/write-off + compensation + recoverable inventory value | Chỉ cộng giá trị hàng hoàn đã QC, không cộng nguyên giá mặc định |
| Contribution margin rate | Realized contribution ÷ mẫu số doanh thu đã quy định | Mẫu số có thể là gross hoặc net revenue; phải cố định và ghi rõ |
| Profit variance | Realized contribution − estimated contribution tại thời điểm order accepted | Phân variance theo price, fee, freight, COGS, warehouse, return và adjustment |
Realized contribution = settled CM2 − return/QC/rework/write-off + compensation + recoverable inventory value.
Không dùng realized contribution làm “lợi nhuận kế toán” nếu chưa reconcile với sổ và chính sách ghi nhận. Giá trị của chỉ số này là unit economics có thể truy nguyên đến order–SKU–parcel–return. Nó giúp quyết định giá, channel mix, promotion và root cause; period P&L vẫn cần accrual, overhead, tax treatment và close riêng.
4. Ví dụ minh họa: một đơn 500.000 đồng không tạo ra 270.000 đồng lợi nhuận
Giả sử đơn có giá hàng 500.000 đồng và COGS 230.000 đồng. Nếu dừng ở đây, margin nhìn như 270.000 đồng. Nhưng đơn dùng voucher shop 40.000 đồng, bị refund một dòng 80.000 đồng, có 62.000 đồng fee thực tế, 38.000 đồng logistics/ fulfillment, 18.000 đồng return/QC/rework. Sau QC, hàng hoàn chỉ phục hồi 52.000 đồng giá trị. Realized contribution minh họa còn 84.000 đồng trước ads và overhead. Các số chỉ để diễn giải công thức, không phải benchmark thị trường.
| Thành phần | Giá trị minh họa (VND) | Cách hiểu |
|---|---|---|
| Giá trị hàng trước giảm | 500.000 | Hai dòng SKU; đây chưa phải tiền thực nhận |
| Voucher do shop chịu | -40.000 | Trợ giá nền tảng nếu có được lưu riêng |
| Refund sau bán | -80.000 | Một phần order line; không đảo toàn bộ đơn |
| Phí sàn/thanh toán/affiliate thực tế | -62.000 | Số minh họa, thay bằng settlement line thật |
| Logistics/COD/fulfillment trực tiếp | -38.000 | Gồm parcel outbound và thao tác trực tiếp theo rule nội bộ |
| COGS lượng thực xuất | -230.000 | Snapshot theo cost version khi xuất |
| Chi phí return/QC/rework | -18.000 | Không gồm phần hàng đã phục hồi |
| Giá trị hàng hoàn có thể phục hồi sau QC | +52.000 | Không mặc định bằng giá vốn ban đầu |
| Realized contribution minh họa | 84.000 | 500 − 40 − 80 − 62 − 38 − 230 − 18 + 52 |
Nếu ads 70.000 đồng được attribution đáng tin cho đơn, contribution sau ads chỉ còn 14.000 đồng. Nếu attribution chưa đủ tin cậy, đừng gắn con số giả vào order; hãy giữ ad spend ở campaign cohort và so incremental contribution. Nếu tháng sau nhận thêm compensation 20.000 đồng, hệ thống tạo adjustment liên kết đơn cũ, không sửa âm thầm bản realized version đã dùng cho báo cáo tháng trước.
5. Margin bridge: biến chênh lệch thành nguyên nhân có owner
Estimated margin sai không phải lúc nào cũng là lỗi hệ thống. Nó có thể sai vì voucher được chỉnh sau, fee policy đổi effective date, carrier cân lại parcel, kho split đơn, COGS dùng nhầm UoM, khách trả một dòng hoặc late claim. Margin bridge giữ estimated snapshot và lần lượt cộng/trừ từng variance. Tổng variance phải bằng realized trừ estimated; nếu không bằng, có missing/duplicate/allocation gap cần xử lý trước khi tin dashboard.
| Variance | Tín hiệu | Owner | Evidence |
|---|---|---|---|
| Price/discount variance | Giá hoặc seller-funded voucher khác snapshot | Ecommerce/campaign | Order promotion breakdown và approval |
| Fee variance | Fee code/rate/basis thực tế khác rule dự kiến | Finance + channel owner | Settlement line, policy/version, effective date |
| Freight/weight variance | Phụ phí, đổi cân nặng, split parcel hoặc return freight | Logistics | Parcel, measured weight, label, handover, carrier invoice |
| COGS variance | Thay cost layer, substitution, combo component hoặc unit conversion | Finance + inventory | Issue transaction, lot/UoM, approved cost version |
| Warehouse variance | Repack, relabel, short pick, damage, extra material hoặc overtime | Warehouse/3PL | PDA task, reason, material issue, incident |
| Return variance | Refund, no-return refund, QC grade, salvage và write-off khác giả định | CSKH + return team | Return line, photos, condition, disposition |
| Timing variance | Fee/refund/claim đến sau kỳ đóng | Finance | Late-arriving event và reopen/next-period policy |
| Unknown variance | Chưa xác định nguồn | Named reconciliation owner | Có tuổi nợ và hạn RCA; không dùng làm bucket vĩnh viễn |
Unknown variance không được xóa. Hãy đặt SLA điều tra theo giá trị/rủi ro, theo dõi aging và tỷ lệ unknown trên tổng adjustment. Một hệ thống “khớp” bằng cách đẩy mọi thứ vào phí khác chỉ làm mất khả năng cải thiện. Ưu tiên root cause theo tổng tiền ảnh hưởng, số đơn, khả năng lặp lại và tác động khách hàng—không chỉ theo một đơn lớn gây chú ý.
6. Cohort và maturity: vì sao hai dashboard đúng vẫn có số khác nhau?
Dashboard marketing thường cohort theo order date; vận hành theo ship date; finance theo settlement date; return team theo received/QC date. Cùng một kỳ 1–7 tháng 8, bốn bảng chọn bốn population khác nhau. Không nên ép chúng bằng nhau. Thay vào đó, mỗi chỉ số công khai cohort field và cung cấp bridge: order cohort đã được giao bao nhiêu, settled bao nhiêu, còn open bao nhiêu, return mature bao nhiêu.
| Cohort | Population | Phù hợp |
|---|---|---|
| Order cohort | Đơn được accepted trong tuần/tháng | Đánh giá pricing/campaign nhưng cần theo dõi đến đủ maturity |
| Shipment cohort | Parcel bàn giao trong kỳ | Đánh giá fulfillment, carrier, COD và SLA |
| Settlement cohort | Fee/cash được quyết toán trong kỳ | Khớp tiền nhưng trộn đơn thuộc nhiều tháng bán |
| Return cohort | Return/refund phát sinh hoặc được QC trong kỳ | Quản lý reverse logistics nhưng không đại diện doanh số gốc |
| Matured order cohort | Order cohort đã qua cửa sổ return/claim định nghĩa | So realized margin công bằng hơn giữa channel/campaign |
Khi so campaign, dùng matured order cohort hoặc accrual return rate dựa trên lịch sử của cùng ngành hàng/channel/ promise. Gắn confidence band nếu dữ liệu ít. Không so campaign vừa kết thúc với tháng thường đã qua hết cửa sổ hoàn. Maturity curve nên hiển thị ngày 0, 7, 14, 30 hoặc theo policy thực tế, nhưng không tự tạo ngưỡng nếu doanh nghiệp chưa có baseline và rule của kênh.
7. Hàng hoàn: refund tài chính không phải return-to-stock
Đây là nơi OMS-only thường bắt đầu thiếu bằng chứng. Marketplace có thể hoàn tiền trước khi kiện về. Carrier có thể đánh dấu delivered-to-seller nhưng kho chưa nhận đúng kiện. WMS cần scan return ID/parcel, kiểm SKU hoặc serial, tình trạng, phụ kiện và disposition. Chỉ QC A/sellable mới tăng ATP. QC B cần rework task; QC C dùng salvage value; mất/hỏng/sai hàng tạo claim hoặc write-off.
| Trạng thái | Xử lý lợi nhuận/tồn | Kiểm soát |
|---|---|---|
| Refund-only, không cần trả hàng | Ghi giảm doanh thu/refund và cost-to-recover decision | Không tự động hoàn nhập COGS hoặc tăng tồn |
| Return in transit | Giữ expected recovery như estimate có haircut | Theo dõi parcel, deadline claim và aging riêng |
| Received, chờ QC | WMS scan kiện và return line; giữ tồn ở trạng thái hold | Chưa cộng ATP, chưa ghi full recoverable value |
| QC A – sellable | Nhập đúng SKU/bin/status và ghi recoverable value theo policy | Idempotency để không restock hai lần |
| QC B – rework/repack | Ghi cost rework, vật tư, thời gian và giá trị sau phục hồi | Chỉ chuyển sellable sau khi hoàn tất task |
| QC C – clearance/salvage | Ghi giá trị thu hồi thấp hơn và kênh xử lý | Không dùng full COGS như thể hàng mới |
| Damage/lost/wrong item | Write-off hoặc claim; giữ evidence và owner | Bồi thường chỉ ghi khi đủ điều kiện theo policy kế toán |
Expected recovery không phải full COGS: dùng xác suất về × giá trị sau QC dự kiến − chi phí thu hồi còn lại, với rule được phê duyệt.
Nếu chưa có đủ dữ liệu, giữ conservative accrual và điều chỉnh khi QC xong. Không invent recovery rate. Sau vài cohort, doanh nghiệp có thể xây matrix theo SKU category, reason, carrier, days-in-transit và condition. Những tham số này cần backtest định kỳ vì policy và customer behavior thay đổi.
8. Phân bổ chi phí: chính xác đủ dùng, không tạo độ chính xác giả
Direct cost nên đi thẳng về object gây ra nó khi có evidence. Fee line gắn order line thì không phân lại. Parcel freight có thể cần allocation vì một kiện chứa nhiều SKU. Vật tư có thể lấy từ actual issue hoặc standard theo box. Warehouse labor nên dùng standard minute theo activity/profile thay vì tổng lương chia số đơn, vì multi-line, bulky, combo, serial và return tạo workload khác nhau.
| Khoản | Driver gợi ý | Guardrail |
|---|---|---|
| Phí theo % đơn | Phân theo basis của settlement hoặc net item value | Không chia đều nếu fee line có basis theo SKU/ngành hàng |
| Phí cố định mỗi order | Giữ ở order hoặc phân theo rule ổn định cho order line | Tách khi phân tích SKU để tổng line khớp order |
| Cước một parcel nhiều SKU | Phân theo chargeable weight, unit, value hoặc driver được duyệt | Báo cả order total và line allocation để tránh coi allocation là hóa đơn thật |
| Vật tư đóng gói | Actual scan/issue nếu có; nếu không dùng standard theo box/profile | Version standard theo effective date |
| Nhân công kho | Standard minute × rate theo activity/profile; actual cho incident đặc biệt | Không lấy tổng lương chia đơn mà bỏ qua multi-line/bulky/return |
| Quảng cáo | Direct attribution khi đáng tin; phần còn lại theo campaign/cohort | Không ép mọi ad spend vào từng đơn với độ chính xác giả |
| Overhead | Tách khỏi CM2; phân bổ ở fully loaded view bằng driver quản trị | Không dùng overhead allocation để quyết định tắt SKU có contribution dương một cách máy móc |
Mỗi allocation output cần giữ method ID, rule version và unallocated remainder. Tổng line phải roll up đúng order/ parcel/campaign total. Nếu một khoản không thể phân hợp lý, giữ ở cohort/channel thay vì ép vào order. Quyết định giá không nên dựa vào fully loaded margin duy nhất; nhìn cả CM2 để biết SKU có tạo contribution trực tiếp trước overhead.
9. Fee và cost versioning: điều kiện để lịch sử không bị viết lại
Phí sàn, gói freeship, affiliate, payment fee, tax treatment và carrier surcharge có thể đổi. Mỗi rule cần source, channel/shop scope, category, basis, rate/fixed component, cap/floor nếu có, effectiveFrom/effectiveTo và approvedBy. Estimated margin dùng version hiệu lực lúc order accepted. Settled margin dùng fee line thực tế. Variance được phân reason: rule outdated, mapping sai, platform adjustment, seller program hoặc unknown.
COGS cũng cần version. Moving average, FIFO hoặc standard cost là policy cần finance chọn; bài viết không áp một phương pháp chung. Điều bắt buộc về vận hành là order line phải biết cost snapshot/layer nào đã dùng, UoM nào, quantity nào và adjustment sau đó đi qua bút toán có lineage. Không lấy giá nhập hôm nay nhân vào đơn sáu tháng trước.
Trước khi activate rule mới, backtest một sample có standard, campaign, refund, multi-line, category khác nhau và settlement thật. Kiểm tổng estimated fee, line allocation, rounding và edge case. Chỉ publish khi owner ký effective date; nếu thiếu dữ liệu, gắn estimate confidence thấp và cảnh báo thay vì trả về số có vẻ chính xác.
10. Timeline dữ liệu end-to-end từ order đến khóa lợi nhuận
| Mốc | Evidence cần ghi | Owner hệ thống |
|---|---|---|
| T0 – order accepted | Snapshot giá, voucher, fee rule, channel, SKU, cost version, estimated margin | OMS/ecommerce |
| Release to warehouse | Kho/node, reservation, service class, cut-off, expected fulfillment cost | OMS + WMS |
| Pick–check–pack | Quantity/SKU thực, scan, substitution, parcel, material, rework, weight | WMS/PDA |
| Carrier handover | Custody proof, manifest, COD/prepaid, carrier service và parcel ID | WMS/logistics |
| Delivery/failure/return | Status, attempt, refund, return ID, claim và reason | OMS/carrier/channel |
| Settlement ingest | Fee line, cash, adjustment, withholding, period và source checksum | Finance/integration |
| Return receiving/QC | SKU/serial, condition, disposition, recoverable value, restock/write-off | WMS return |
| Close/reopen | Khóa profit version; late event tạo adjustment có lineage | Finance/management accounting |
Control total chạy ở mỗi biên: OMS đã release bao nhiêu order/line; WMS accepted/rejected bao nhiêu; packed bao nhiêu parcel; carrier handover bao nhiêu; settlement cover bao nhiêu order; return scan bao nhiêu line. Missing, duplicate, out-of-order và rejected event vào queue có owner. “API realtime” không đủ nếu không có completeness và reconciliation.
Mỗi event nên có occurredAt, receivedAt, source, event ID, schema version và reason. occurredAt phục vụ business time; receivedAt đo latency. Late event không bị bỏ; nó cập nhật current view và tạo accounting/management adjustment theo close policy. Audit view phải cho thấy số cũ, số mới, ai/tiến trình thay đổi và evidence.
11. OMS-only hay OMS + WMS? Quyết định theo bằng chứng cần có
| Mô hình | Phù hợp khi | Giới hạn |
|---|---|---|
| Spreadsheet + Seller Center | Ít đơn, một shop, ít refund và một người hiểu toàn bộ file | Khó giữ version, order-line grain, late adjustment và audit trail |
| OMS-only | Cần gom order/settlement đa kênh; hàng hoàn đơn giản và chi phí kho dùng standard | Đủ cho estimated/settled margin nhưng yếu ở return QC và execution cost thực |
| OMS + WMS | Nhiều SKU/kho/3PL, barcode/PDA, split, vật tư, return QC, rework, mất/hỏng | Nối financial state với physical evidence và cost driver theo task |
| Data warehouse/BI bổ sung | Nhiều pháp nhân, channel, currency, ad source và cần cohort/model phức tạp | BI không sửa dữ liệu nguồn sai; vẫn cần OMS/WMS ownership và close control |
OMS-only đủ khi warehouse cost có thể dùng standard ổn định, return ít và không cần condition-level recovery. Nếu doanh nghiệp bán nhiều SKU gần giống, dùng PDA/barcode, nhiều bin/node, split parcel, 3PL, serial/lot, packing material hoặc return QC, lợi nhuận bị quyết định bởi physical execution. OMS + WMS tạo evidence ai lấy gì, ở đâu, đóng kiện nào, dùng vật tư gì, hàng hoàn về tình trạng nào và adjustment tồn nào xảy ra.
WMS không thay finance và OMS không thay WMS. OMS giữ commercial promise, pricing inputs, order identity, ATP/routing, channel status và settlement linkage. WMS giữ physical state/task. Finance giữ cost/close/allocation policy. BI có thể tổng hợp nhưng không nên trở thành nơi duy nhất “sửa” ID hoặc phí không khớp. Source owner phải sửa hoặc phát adjustment.
12. Close theo ngày, tuần, tháng và sau campaign
| Nhịp | Việc chính | Owner |
|---|---|---|
| Hằng ngày | Ingest settlement; kiểm control total, duplicate/missing; queue đơn âm bất thường và hàng hoàn aging | Finance ops + ecommerce ops |
| Hằng tuần | Margin bridge estimated→settled, fee variance, freight, return cohort, top exception và action | Channel/finance/warehouse owners |
| Cuối tháng | Chốt source files, cost versions, accrual, mature cohort, late events và reconciliation sign-off | Finance accountable |
| Sau campaign | So cohort có cùng maturity; tách voucher, fee, ads, peak warehouse, split và return | Campaign owner + operations |
| Khi policy đổi | Tạo rule version mới có effective date, backtest mẫu và không viết lại đơn cũ | Finance + channel owner + data owner |
Kỳ đóng cần quy định materiality: chênh lệch nào mở lại kỳ, chênh lệch nào vào kỳ hiện tại; ai phê duyệt; báo cáo cũ có restate hay chỉ ghi adjustment. Đây là chính sách nội bộ cần finance xác nhận. Về hệ thống, yêu cầu tối thiểu là không xóa dấu vết, không đổi rule lịch sử và có thể roll forward open item như claim, return in transit, withheld cash.
Daily dashboard tập trung exception, không cố đóng profit cuối cùng. Weekly review nhìn top variance và process owner. Monthly close reconcile order ledger với settlement totals, bank/wallet, inventory movement và approved accrual. Sau campaign, đợi maturity hoặc dùng accrual được backtest; so với baseline cùng category/channel/order profile.
13. Cảnh báo vận hành nên dựa trên cả giá trị và cơ chế
Cảnh báo đơn âm dự kiến giúp chặn pricing/campaign sai trước release, nhưng không được tự hủy đơn nếu chưa có authority. Cảnh báo fee variance tìm fee code mới, rate/basis khác rule hoặc adjustment lặp lại. Cảnh báo return recovery tìm SKU có refund nhiều nhưng QC A thấp. Cảnh báo warehouse variance tìm node/ca/profile có repack, short pick, split hoặc vật tư vượt chuẩn. Cảnh báo cash gap tìm settlement overdue hoặc control total thiếu.
Ngưỡng không nên copy từ thị trường. Bắt đầu bằng baseline 8–12 tuần, phân distribution theo channel/category/order profile, rồi đặt alert theo materiality của doanh nghiệp. Dùng cả absolute amount, rate và persistence: một variance nhỏ lặp 10.000 đơn có thể quan trọng hơn một đơn lớn. Alert cần evidence link, owner, due time, status và closure reason.
14. Mười sai lầm phổ biến khi trả lời “đơn này lời bao nhiêu?”
| Sai lầm | Vì sao sai | Cách sửa |
|---|---|---|
| Dùng doanh số làm lợi nhuận | Doanh số có thể gồm đơn chưa trả tiền, hủy/hoàn hoặc chưa trừ chi phí. | Tách order GMV, net revenue, net cash, CM1, CM2 và realized contribution. |
| Chỉ có một cột profit | Không biết số đang estimated, settled hay realized. | Lưu profit version, as-of time, source completeness và maturity. |
| Cập nhật phí mới cho toàn bộ lịch sử | Đơn cũ bị viết lại theo policy chưa tồn tại lúc bán. | Fee rule và cost rule phải có effective date. |
| Dùng giá vốn hiện tại | Giá nhập thay đổi làm sai margin lịch sử. | Snapshot cost layer/version khi xuất và điều chỉnh có lý do. |
| Hoàn tiền là cộng lại toàn bộ giá vốn | Hàng có thể chưa về, thiếu, hỏng hoặc cần rework. | Chỉ ghi recoverable value sau WMS receiving/QC. |
| Bỏ đơn âm khỏi báo cáo | Che vấn đề pricing, fee, fulfillment hoặc abuse. | Giữ mẫu số và phân reason; chỉ loại test/duplicate theo rule. |
| Chia đều mọi chi phí | SKU nhỏ gánh cước của bulky hoặc item rẻ gánh fee ngành hàng khác. | Dùng driver phù hợp và công khai allocation method. |
| Gộp unknown vào “phí khác” | Không có owner và không học được nguyên nhân. | Reason taxonomy, aging, RCA due date và unknown-rate KPI. |
| So campaign chưa đủ maturity | Campaign mới nhìn đẹp vì hàng hoàn/fee muộn chưa đến. | Dùng matured cohort hoặc accrual có confidence band. |
| BI tự sửa dữ liệu nguồn | Dashboard đẹp nhưng tổng settlement, kho và ngân hàng vẫn lệch. | Reconcile source control totals trước khi tính margin. |
Những câu trả lời kiểu “phí khoảng…”, “lợi nhuận thường…”, “tùy sàn” chỉ đúng ở mức cảnh báo. Để vận hành, “tùy” phải trở thành input: shop tier, category, program, payment method, parcel profile, return reason, cost version và effective date. Khi chưa đủ input, hệ thống phải trả estimate có confidence/completeness flag, không được tự tạo một con số chắc chắn.
15. Buyer execution checklist: năm việc có thể làm trong 30 ngày
- Chọn 100–300 đơn đại diện gồm prepaid, COD, nhiều dòng, combo, split, hoàn một phần, no-return refund và claim; nối order–parcel–settlement–return line bằng ID thật.
- Viết data dictionary cho gross sales, net revenue, net cash, COGS, CM1, CM2 và realized contribution; ghi rõ mẫu số, thời điểm, currency/tax và owner.
- Tạo fee/cost rule có effective date; backtest estimated margin với settlement thực tế và phân top variance theo price, fee, freight, COGS, warehouse, return.
- Thiết kế close policy: thời điểm đơn chuyển estimated→settled→realized, cách accrual return/claim, xử lý late event, reopen và sign-off cuối tháng.
- Chạy pilot hai kỳ settlement và ít nhất một return cycle; chỉ dùng dashboard để quyết định giá/campaign sau khi control total, duplicate, missing và unknown variance đạt gate nội bộ.
Ngày 1–5 chọn sample và identity map. Ngày 6–10 viết metric/data dictionary. Ngày 11–15 ingest settlement và xây margin bridge. Ngày 16–20 nối return receiving/QC với financial refund. Ngày 21–30 shadow close hai kỳ, review variance và sửa rule. Không cần chờ data warehouse hoàn chỉnh; nhưng mỗi bước phải có control total và rollback khỏi quyết định tự động nếu dữ liệu chưa đạt gate.
16. JST ERP hỗ trợ theo dõi lợi nhuận đơn bằng OMS + WMS như thế nào?
JST ERP có thể giúp doanh nghiệp gom order/line từ Shopee, Lazada, TikTok Shop, website và social commerce; chuẩn hóa SKU mapping; quản lý COD, parcel, trạng thái, tồn khả dụng và settlement relation ở OMS. Ở kho, WMS/PDA ghi receiving, bin, picking, checking, packing, barcode, vật tư, handover, return receiving, QC và inventory adjustment. Khi hai lớp nối bằng ID/event, finance có thể giải thích margin variance bằng evidence thay vì hỏi qua nhiều nhóm chat.
Phạm vi thực tế cần khảo sát nguồn settlement/API, policy fee, phương pháp giá vốn, mức chi tiết warehouse cost và quyền kiểm soát dữ liệu. JST ERP không nên cam kết một tỷ lệ lợi nhuận hoặc tiết kiệm phổ quát. Cách triển khai an toàn là dùng sample thật, thống nhất definition, chạy shadow report, reconcile control totals và chỉ đưa dashboard vào quyết định giá/campaign sau acceptance. Những chỗ cần dữ liệu khách hàng thật gồm estimated-vs-realized variance, return recovery, fee leakage, warehouse cost/order và thời gian close; không có dữ liệu được phép công bố thì giữ công thức.
Trước buổi tư vấn, hãy xem sản phẩm OMS + WMS, giải pháp đa kênh, giải pháp vận hành kho, cam kết dịch vụ, FAQ, settlement waterfall COD–phí sàn–hàng hoàn, khung cost-to-recover hàng hoàn và khung chi phí–ROI WMS. Mang theo 8–12 tuần order line, settlement, parcel, return/QC, cost snapshot và ba chênh lệch khó giải thích nhất.