Tính ra số tiền thất thoát nguyên liệu mỗi ngày — không cần POS thật, chỉ cần Recipe/BOM

minh_dinh · July 6, 2026, 2:35am

Tính ra số tiền thất thoát nguyên liệu mỗi ngày — không cần POS thật, chỉ cần Recipe/BOM + no-code

Công thức là gì

Bài toán mình giải quyết cho 1 chuỗi F&B (15–80 chi nhánh): chủ chuỗi biết mình đang mất tiền vì thất thoát nguyên liệu, nhưng không biết mất ở đâu, mất bao nhiêu, mất từ khi nào. Cuối tháng nhìn báo cáo COGS thì đã quá trễ để hành động.

Công thức là 1 chuỗi khép kín gồm 4 lớp dữ liệu nối tiếp nhau, dựng hoàn toàn bằng Entity + Lookup + Rollup + Formula trên nền tảng no-code, không cần tích hợp POS thật ngay từ đầu:

Lớp 1 — Recipe/BOM (nền của mọi phép tính sau này) Mỗi món ăn được khai báo thành nhiều dòng “công thức”: 1 món = N nguyên liệu × định lượng cụ thể. VD: Trà sữa trân châu = 8g trà đen + 100ml sữa tươi + 20ml đường nước + 30g trân châu. Đây chính là dữ liệu gốc để suy ra “lẽ ra phải dùng bao nhiêu nguyên liệu” từ số lượng món đã bán — không cần đợi có máy POS kết nối trực tiếp, ban đầu có thể nhập tay số bill bán mỗi món mỗi ngày để mô phỏng.

Lớp 2 — Suy ra lượng nguyên liệu lý thuyết phải dùng Lấy (số bill bán món trong ngày) nhân (định lượng nguyên liệu trong Recipe của món đó), rồi cộng dồn theo từng nguyên liệu, ra sold_qty_theory — con số “lẽ ra phải hết đúng ngần này nguyên liệu”.

Lớp 3 — So với thực tế kiểm kê, ra hao hụt bằng tiền

variance_qty  = (tồn đầu ca + hàng nhận thêm − sold_qty_theory) − tồn cuối ca kiểm thật
variance_value = variance_qty × giá nguyên liệu

variance_value chính là số tiền thất thoát cụ thể của đúng 1 nguyên liệu, đúng 1 chi nhánh, đúng 1 ngày — không phải ước lượng cuối tháng nữa.

Lớp 4 — Khép vòng lặp: cảnh báo tự động, không chờ ai đọc báo cáo Nếu 1 nguyên liệu liên tục thiếu hụt khi chuyển hàng giữa kho tổng và chi nhánh (không phải lỗi bán hàng mà lỗi khâu vận chuyển/xuất kho), hệ thống tự đếm dồn số lần thiếu và tự gửi cảnh báo (kèm PDF tự sinh) về đúng người phụ trách mua hàng — thay vì chờ họ tự nhớ ra để đặt hàng bổ sung.

Điểm kỹ thuật khó nhất khi build: nền tảng no-code không cho Automation ghi dữ liệu chéo sang App khác, và cũng không cho Formula tính trực tiếp trên field Lookup. Giải pháp xuyên suốt cả 4 lớp: luôn kéo giá trị cần tính về Number thật qua 1 field Rollup trung gian trước, rồi mới đưa vào Formula — đây là “khuôn” lặp lại ở mọi bước tính toán trong toàn hệ thống, từ tính tổng tiền đơn hàng, tính tồn kho 2 chiều, cho tới tính hao hụt.

Bài toán doanh nghiệp nào nó giải quyết

Đây là bài toán kinh điển của bất kỳ chuỗi F&B/bán lẻ có sản phẩm chế biến từ nhiều nguyên liệu: quán trà sữa, quán cà phê, nhà hàng, tiệm bánh, chuỗi fastfood. Phòng ban hay “đau đầu” nhất vì bài toán này:

Chủ chuỗi/Ban giám đốc: biết COGS nguyên liệu chiếm 3–8% doanh thu bị “bốc hơi” nhưng không có công cụ để khoanh vùng nguyên nhân (do bán hàng gian lận, do pha chế dư định lượng, do thất thoát khi vận chuyển, hay do hết hạn phải bỏ).
Quản lý chi nhánh: phải tự kiểm kê tay, tự đoán “hao hụt bình thường” hay “có vấn đề”, không có số liệu đối chiếu tức thời.
Bộ phận mua hàng (Purchasing): chỉ đặt hàng theo cảm tính hoặc theo lịch cố định, không dựa vào dữ liệu thiếu hụt thực tế đang xảy ra ở từng chi nhánh.

Nên dùng công thức này khi: doanh nghiệp của bạn có công thức chế biến rõ ràng (Recipe/BOM có thể định lượng được) và có từ 1 điểm bán trở lên cần đối chiếu tồn kho định kỳ — không nhất thiết phải có POS hiện đại ngay từ đầu, vì lớp 1–2 vẫn chạy được với dữ liệu nhập tay mô phỏng.

Vì sao bạn nên thử công thức này

Biến 1 con số mơ hồ (“hao hụt khoảng vài %”) thành số tiền cụ thể theo từng nguyên liệu, từng chi nhánh, từng ngày — đây chính là thứ khiến ban giám đốc thật sự hành động được, thay vì chỉ nhìn báo cáo tổng cuối tháng.
Không cần đầu tư hệ thống POS/ERP đắt tiền để bắt đầu — vì lớp tính lý thuyết (Recipe × số bill) vẫn chạy đúng dù bạn nhập tay số bill mô phỏng ban đầu; khi có POS thật, chỉ cần đổi nguồn dữ liệu đầu vào, không cần đập đi xây lại công thức.
Tự phát hiện vấn đề, không cần ai “để ý”: nhờ cơ chế Rollup tự tính lại + Automation cảnh báo, hệ thống chủ động báo trước khi vấn đề tích lũy thành thiệt hại lớn, thay vì phải chờ 1 người có thói quen kiểm tra định kỳ.
Scale tốt theo số chi nhánh và số món trong menu: thêm chi nhánh mới hay món mới không phải viết lại logic — chỉ cần thêm dòng Recipe/dòng dữ liệu chi nhánh, công thức tự áp dụng đúng.
Đánh đổi cần biết trước: độ chính xác của variance_value phụ thuộc hoàn toàn vào việc Recipe/BOM được khai báo đúng và đủ chi tiết — nếu công thức pha chế thực tế hay thay đổi tùy hứng (không theo định lượng chuẩn), số liệu hao hụt sẽ bị nhiễu, cần chuẩn hóa quy trình pha chế song song với việc triển khai hệ thống.