HTF không phải catering. Chuỗi đúng là mua chân gà nguyên liệu nguyên xương, nhận hàng/QC, rút xương, đóng gói nhiều quy cách, bán cho đại lý/siêu thị, rồi truy xuất được từng lô nguyên liệu → thành phẩm → fulfillment/giao hàng. Tài liệu này gom lại phần giữ sạch, cần đổi nghĩa, cần dọn, và nên build tiếp.
Trạng thái phản ánh Harness truth (DEC/US), không phải runtime proof mới. Chi tiết runtime nằm ở các tab Manufacturing/Sales/Technical plan.
| Khối | Trạng thái | Ghi chú |
|---|---|---|
| ERP foundation (Auth/Org/Master Data nền/Procurement/GRN/Inventory/Transfer/Reports/Onboarding) | Implemented | Tái dùng từ foundation. Giữ làm nền; Sites đổi nghĩa thành plant/warehouse/cold storage. |
| Clean-slate guard (retired surfaces frozen, active-source strict check) | Changed · US-060 | Retired runtime surfaces fail-closed; frozen compatibility baseline; strict scanner. Story changed, chưa implemented tới khi cleanup proof đóng. |
| Sales / O2C foundation (customer role/profile, price list, sales order, charges, fulfillment qua Inventory) | Planned · US-059 | Accepted bằng DEC-0041; planned bằng US-059. Là demand driver chính. |
| Item Master semantics (raw/WIP/finished_good/by_product/packaging) | Planned | Physical catalog tables là compatibility cho tới khi rename/migration hoàn tất. |
| Procurement source decoupling (generic source thay legacy planning FK) | Planned | Historical source vẫn gắn legacy lineage; cần generic source enum. |
| Manufacturing (formula/BOM versioning, Work Order, inputs/outputs/by-product, QA disposition) | Planned | Net-new manufacturing spine; build sau khi Sales/Inventory source rõ. |
| Traceability read model (lot genealogy, recall query) + manufacturing reports | Planned | Read model trên movement/WO/GRN/fulfillment facts. |
| AR/invoice/payment · shipment logistics · advanced planning/MRP | Deferred | Chỉ giữ cấu trúc FK chứa được; không build logic ở slice đầu. |
Feature-first Hexagonal/DDD, static ERP module registration. Foyer chỉ là headless auth/runtime provider boundary; Desktop/Electron deferred.
Company profile, regions, sites (plant / warehouse / cold storage / sales warehouse). Scope cho mọi document.
Business parties + party roles, customer profiles, supplier profiles, sales channels, Item Master target (physical catalog compatibility), UOM/conversion.
Commercial demand: price lists, sales orders, lines, charges/allocations, events. Sở hữu commercial promise — không sở hữu stock vật lý.
Purchase orders, lines, generic source, events. Mua nguyên liệu theo material requirement.
GRN, received lots (supplier lot, expiry, temp), incoming QC hold/release trước khi vào Inventory.
Physical stock proof: batch/lot identity, stock levels, FEFO, append-only movements, stock documents (kể cả sales fulfillment). Sở hữu allocation + movement.
Formula/BOM + versions, work orders, inputs/outputs, by-products, yield/loss, QA dispositions. Work Order là quyền sản xuất.
Lot genealogy + recall query — read-only projection trên movement/WO/GRN/fulfillment, không tự ghi facts.
Headless auth/runtime provider. Permission htf.*, role profile htf-*, scope theo site/region. Không import Foyer UI/shell.
Mỗi use case neo vào một bounded context sở hữu và bộ entity/table chính. "Proof" là kỳ vọng validation; "Deferred" là phần ngoài slice đầu.
customer → fill customer profile (kênh, hạn mức, payment terms, rate phí VC/KG, % CK) → duyệt → sinh mãbusiness_parties, business_party_roles (+customer), customer_profilessupplier_profiles; một party có thể vừa supplier vừa customersales_channels, price_lists, price_list_items, customer_price_lists, price_periodssales_orders, sales_order_lines, sales_order_charges, sales_order_charge_allocations, sales_order_eventssales_orders (status), sales_order_eventsdraft→submitted→approved→…; permission htf.sales.order:approvework_orderspurchase_orders, purchase_order_lines, PO sources, PO eventsgrn, received lots, incoming QC, inventory_batchesformulas, formula_versions, work_orders, work_order_inputsstock_movements (consume)work_order_inputs, stock_movements, inventory_batcheswork_order_outputs, by-products, inventory_batches, stock_movementsinventory_batches (status)inventory_batches, stock levels, stock_movementsbusiness_purpose='sales_fulfillment' → allocate batch → ordered vs fulfilled → post sales_fulfillment_outstock_documents, stock document lines, stock_movements, sales_order_lines (fulfilled qty)Mỗi flow ghi rõ context sở hữu từng bước. Hộp viền cam đậm = điểm quyết định/phê duyệt; badge = context.
Sales sở hữu order; Inventory chứng minh xuất hàng. Invoice/AR chỉ giữ FK chứa được (W3).
MTO (từ SO) và MTS (từ stock target) hội tụ ở Work Order. Yield/loss/by-product ghi nhận lúc produce.
PO source là generic; supplier lot bắt buộc để giữ mắt xích recall từ nguyên liệu.
Partial fulfillment là first-class; SO line giữ ordered/fulfilled/remaining qty.
Backward trace từ shipment về supplier lot; forward trace ngược lại tìm mọi khách bị ảnh hưởng — đều qua FK + read model.
Mỗi khối là một bounded context với entity chính; đường nối là quan hệ FK/flow chính. Item Master target là vocabulary chuẩn; physical catalog chỉ là compatibility.
Đường cam = quan hệ trọng tâm (customer/price/item, consume/produce lot, sales_fulfillment). Item Master target thay physical catalog compatibility khi rename hoàn tất.
Mọi mắt xích nối bằng FK + append-only movement; recall đi 2 chiều (forward: supplier lot → khách; backward: khách → supplier).
Wireframe mức kiến trúc giúp reviewer hình dung surface — không phải bản thiết kế cuối, không phải app code.
| Item ▾ | UOM | Ordered | Unit price | Fulfilled | Remaining |
|---|---|---|---|---|---|
| FG-CGRX-0500 ▾ | Khay | 3.000 | 44.000 | 0 | 3.000 |
| FG-CGRX-1000 ▾ | Khay | 500 | 89.000 | 0 | 500 |
| + Thêm dòng… |
| Channel ▾ | Period | Tier (min qty) | Price (before VAT) | VAT | Status |
|---|---|---|---|---|---|
| ST — Siêu thị | 2026-Q2 | ≥ 1.000 | 44.000 | 10% | Approved |
| ĐL — Đại lý | 2026-Q2 | ≥ 500 | 42.500 | 10% | Approved |
| NM — Nhà máy/OEM | 2026-Q2 | ≥ 5.000 | 40.000 | 10% | Draft |
| I/O | Item | Planned | Actual | Lot |
|---|---|---|---|---|
| Input | RAW chân gà nguyên xương | 1.500 kg | 1.512 kg | RM-LOT-8841 |
| Output FG | FG-CGRX-0500 | 3.000 khay | 2.970 khay | FG-LOT-5520 |
| By-product | Xương (bone) | — | 410 kg | BP-LOT-1203 |
| Loss | Hao hụt | — | 2,1% | — |
| Lot | Item | Nguồn | Status | Disposition |
|---|---|---|---|---|
| FG-LOT-5520 | FG-CGRX-0500 | WO-2616 | On hold | Release ▾ |
| RM-LOT-8841 | RAW chân gà | GRN-3302 | Released | — |
| FG-LOT-5519 | FG-CGRX-1000 | WO-2615 | On hold | Reject / Rework ▾ |
Thứ tự triển khai từ clean-slate guard tới reports + financials. Mỗi phase có trigger/điều kiện vào.
inventory.stock_documentscustomer + customer_profiles mirror supplier_profiles (DEC-0041). Có cần customer-group/segment table sớm?business_purpose='sales_fulfillment' + source refs tới sales_order_lines; shipment aggregate chỉ khi cần logistics. Đồng ý?sales_order → fulfillment → invoice → payment → AR aging có đủ anchor để attach sau? Thời điểm e-invoice (NĐ 70/2025)?ERP phải trả lời được: lô nguyên liệu nào đi vào lô thành phẩm nào, lô thành phẩm nào đã giao cho khách nào, và điểm QA/hold/release nằm ở đâu.
Không xóa lịch sử migration đã apply. Cách sạch là freeze legacy/source-product demand, mở schema mới đúng manufacturing, rồi strangler từng surface.
| Nhóm | Giữ / sửa / dọn | Đề xuất xử lý |
|---|---|---|
| Giữ sạch | Auth, Organization, Party/Supplier, UOM, Item target/Product compatibility, RFQ/Quote, GRN, Inventory, Transfer, Data Onboarding | Giữ làm nền ERP. Sites đổi nghĩa thành plant, warehouse, cold storage, sales warehouse. UOM dùng cho kg/g/pack/carton và yield. Product physical names chỉ còn là staged compatibility cho Item Master cleanup. |
| Giữ + migrate | Historical recipe/formula tables | Không giữ UI hay permission active theo legacy recipe naming. Schema lịch sử được freeze như compatibility/history; hướng sạch là migrate sang manufacturing.formulas, formula_versions, inputs/outputs/by-products. |
| Giữ + migrate | HACCP concept, quality disposition, hold/release | Giữ concept food safety, nhưng chuyển từ serving evidence sang QA/CCP cho GRN line, work order operation, produced lot, shipment khi cần. |
| Dọn khỏi active | Retired planning, demand-forecast, serving-depth, and serving-time safety surfaces | US-060 đã retire/fail-close active RPC/permission surfaces và freeze compatibility baseline. Không route/nav/RPC/report/story depth mới; only archive/history/compatibility references được giữ. |
| Sửa sớm | Procurement PO source | purchase_orders.source_menu_plan_id đang NOT NULL và FK menu. Cần generic source: manual buy, reorder policy, production plan, work order, sales-driven buy, legacy menu chỉ cho historical rows. |
| Build mới | Sales, Production, Traceability, Manufacturing Reports | Sales theo DEC-0041/US-059. Production Work Orders tiêu thụ lot nguyên liệu và sinh lot thành phẩm. Lot genealogy/read model trả lời trace/recall. |
Clean target là Item Master với raw material, finished good, WIP, by-product, packaging, và consumable. Physical catalog tables chỉ là compatibility cho tới khi rename/migration hoàn tất.
Procurement historical source vẫn gắn menu-plan lineage. Cần generic source: manual buy, reorder policy, production plan, work order, sales-driven buy; legacy menu chỉ cho historical rows.
Cần thay bằng incoming QC, stock aging/expiry/quality hold, production yield/loss, shipment fill rate, supplier rejection, traceability exceptions.
US-060 đã bỏ retired formula permissions khỏi catalog/profile/seed/snapshots và legacy formula RPC fail-closed. Còn lại là historical schema/dead UI compatibility cần cleanup theo frozen baseline; hướng sạch là htf.manufacturing.formula:*.
inventory.stock_documents cần mở business_purpose='sales_fulfillment' và source refs tới Sales Order. Chỉ tạo shipment logistics tables khi logistics cần carrier/tracking/chứng từ giao hàng độc lập.
Tạo seed pack: plants, warehouses, cold storage, raw chicken feet suppliers, packaging, finished-good SKUs, sales channels/customers. Existing compatibility vocabulary phải đi qua active-source baseline, không được tăng thêm.
Các nguồn dưới đây không biến HTF thành dự án compliance đầy đủ ngay, nhưng chúng đặt đúng hình dạng dữ liệu: preventive controls, traceability, lot identity, BOM/formula, work order, co-/by-product.
FDA FSMA Preventive Controls, 21 CFR Part 117, Codex CXC 1-1969, ISO 22000.
FDA Food Traceability Rule, ISO 22005, GS1 Global Traceability Standard.
Odoo BoM, Oracle Work Orders, Dynamics formulas/by-products.
Không inline mọi thứ vào một phiếu. Dùng document tách rời, FK thật, lot genealogy, event/audit, condition records, và Work Order làm quyền sản xuất.
sales_channels để key giá bán.Nguồn đã tải ngày 22/06/2026 vào /Volumes/tuannguyen/Desktop/Workspace/erp-research/katana-sales/ và snapshot rộng từ https://support.katanamrp.com/en/ vào /Volumes/tuannguyen/Desktop/Workspace/erp-research/katana-support/ (manifest: 829 URL, 767 article, 52 collection, 9 link Katana upstream trả 404, 0 URL còn thiếu). Trạng thái dưới đây là hỗ trợ hôm nay trong htf-platform, không tính là đã hỗ trợ chỉ vì đã có kế hoạch.
| Use case Katana Sales | Nguồn Katana | HTF hỗ trợ hôm nay? | Kế hoạch / gap cần build |
|---|---|---|---|
| Sell screen: danh sách SO, Quotes, Returns, Price lists, Customers; thao tác từ một màn hình bán hàng | How to use the Sell screen | Chưa hỗ trợ | Chưa có features/sales hoặc route /sales/*. US-059 chỉ planned cho /sales/customers, /sales/price-lists, /sales/orders; Quotes/Returns không vào slice đầu. |
| Customer CRUD, tạo khách ngay trong SO, lưu contact/default currency/discount/billing/shipping address/import | Create customer · Edit · Delete · Addresses | Nền có sẵn một phần | Repo đã có Party/Supplier pattern; Customer runtime chưa có. DEC-0041/US-059 cần ALTER business_party_roles thêm customer + customer_profiles, không tạo bảng customer độc lập. Import customer nên đi qua Data Onboarding pack sau khi runtime ổn. |
| Customer discount mặc định, discount trên SO line, price-list override/precedence | Customer discounts · SO discounts · Price lists on SOs | Chưa hỗ trợ | US-059 planned: discount/support/freight là sales_order_charges + allocations, line snapshot khi approve. Cần chốt precedence HTF: customer default vs price list vs manual discount vs promo before runtime. |
| Price list setup: active/inactive list, item adjustment fixed/percentage/markup, gán nhiều customer, apply giá tự động lên SO | Setup price lists · Update price list · Apply on SO | Planned US-059 | Chưa có bảng sales.price_lists. DEC-0041 đã chốt price-list condition record keyed theo item/channel/scope/UOM/currency/tier/customer; khác Katana ở chỗ HTF cần approval lifecycle và validity window chặt hơn. |
| Bulk update price list bằng spreadsheet, download/import XLSX | Bulk update price list prices | Pattern có, Sales chưa | Data Onboarding import/export foundation đã có cho master data khác; price-list pack chưa có. Đưa vào follow-up sau khi sales.price_list_items runtime và approval workflow xong. |
| Quote lifecycle: tạo quote, quản lý pending/confirmed, in PDF/export, confirm thành SO, revert SO về quote | Create quote · Manage quotes · Confirm quote · Revert SO to quote · Export quotes | Deferred | US-059 non-goal: không có quote aggregate. Nên mở sau Sales Order foundation khi HTF xác nhận báo giá là workflow thật, không chỉ nhập đơn trực tiếp. |
| Tạo Sales Order thủ công hoặc sync ecommerce; header gồm customer ref, order #, deadline, currency, bill/ship to, ship-from location | Create sales order · Change SO location | Planned US-059 | Cần build sales.sales_orders, header snapshots, ship-from site, currency, source refs, idempotency. Ecommerce sync/API source là deferred integration; core manual entry trước. |
| SO lines: item, qty, UOM, price before tax, discount, tax, total; comments; line attributes/metadata cho MTO | SO line fields · Custom fields | Planned lõi | US-059 planned cho line snapshot/price/VAT/remaining qty/charge allocation. Custom fields user-defined, PDF placement, và line metadata UI là follow-up; không nên mở schema tự do trước khi core invariant ổn. |
| SO priority: drag/drop rank ảnh hưởng reservation, availability và linked MTO MO priority | Manage SO priorities | Chưa hỗ trợ | Inventory có stock facts nhưng chưa có Sales priority/commitment queue. Build sau core order: rank field + recalculation service + Inventory reservation/ATP port; MTO priority sync đợi Work Orders. |
| Sales item availability: In stock / Expected / Committed / Not available / Picked; Inventory Intel theo SO/MO/PO/OPO và multi-location | Sales item availability | Inventory nền có | US-059 validation đã yêu cầu availability preview; trạng thái đầy đủ kiểu Katana cần ATP/commitment/read model sau Inventory + Production. Không duplicate tồn trong Sales. |
| Delivery statuses: Not shipped, Packed, Partially packed, Delivered, Partially delivered; bulk status; revert inventory impact | Delivery statuses · Deliver SO · Revert Done to Open | Planned US-059 | US-059 maps fulfillment to inventory.stock_documents + sales_fulfillment_out. Need explicit partial fulfillment and cancel/revert guards; carrier-level shipment lifecycle remains deferred. |
| MTO partial delivery: linked MO partially complete → deliver some quantities; batch assignment during delivery | Partial delivery when MTO | Deferred | HTF Work Orders/BOM/yield are net-new manufacturing capabilities and not implemented in Sales foundation. Add SO line → WO link after Work Order runtime exists. |
| Pick/reserve specific bins, batch/serial on SO lines; consume selected bins on packed/delivered, release on revert/remove bin info | Add stock from bins to SOs | Batch nền có, bins chưa | Inventory already owns batch/lot and stock movement proof. Sales-specific bin reservation, serial handling, and release semantics should be an Inventory allocation story after US-059. |
| Kits & Bundles: bundle BOM, auto-assembly at Packed/Delivered, potential stock, Shopify bundle sync | Managing bundles | Deferred | HTF cần Formula/BOM + Work Orders trước. Bundles có thể map thành sellable kit SKU hoặc packaging BOM, nhưng không vào Sales foundation đầu tiên. |
| Shipping addresses on SO/Quote, order-specific override, delivered-lock, packing slips | SO addresses · Customer addresses | Planned snapshot | US-059 header should snapshot billing/shipping address. Address book UX, packing slip templates, and delivered-lock details are follow-ups unless HTF needs them in first smoke. |
| Shipping fees: add/edit/delete one SO shipping fee, tax, export as line item, ecommerce import | Shipping fees | Planned as charge | DEC-0041 explicitly rejects loose header-only fee. Model freight as typed sales_order_charges + allocations; HTF can support multiple fee/condition rows better than Katana's one-fee limitation, but runtime is not built. |
| Tracking number/link/carrier/method on SO, packing list barcode, API shipping workflow | Tracking info · Shipping overview · API shipping workflows | Deferred | DEC-0041 defers sales-owned shipment tables until carrier/tracking/customer-facing delivery docs are proven. First slice should not create logistics aggregate prematurely. |
| Returns/RMA: create linked return from completed SO, partial return, return reasons, batch-trackable returns, restock selected lines, credit-note sync | Returns overview · Create/edit return · Restock returns | Deferred | US-059 explicitly excludes returns/RMA. Add after fulfillment and quality disposition are stable because returns affect stock, traceability, credit note, and AR. |
| SO duplicate/delete/export; troubleshooting around missing items, locked delivered orders, unavailable stock | Duplicate SO · Delete SO · Export SOs · Troubleshoot SOs | Chưa hỗ trợ | US-059 should include cancel/delete guards and export/read models only after core command service exists. Duplicate/reopen/export are useful but not proof of MVP correctness. |
| Personalized tables, advanced filter/sort, saved views, custom field columns, export visible filtered rows | Personalized tables · Advanced filter/sort · SO custom fields | UI pattern có | Auth Web already has shared table/resource patterns for other modules. Sales-specific saved views/custom fields are not implemented; start with fixed columns/status filters, then add saved views if repeated Sales workflow needs it. |
| External ecommerce/accounting/shipping integrations: Shopify/WooCommerce/BigCommerce, QuickBooks/Xero, API shipping platforms | Ecommerce SO sync mention · API shipping workflows | Deferred | No external integration in current HTF Sales plan. Keep source refs and idempotency in schema so integration can attach later without reshaping the order core. |
Hai quy trình cốt lõi, vẽ bằng "hộp & mũi tên" để dễ hình dung công việc end-to-end.
Đơn hàng · Hóa đơn · Thanh toán là 3 chứng từ tách biệt (không gộp). Wave 1 dựng sẵn cấu trúc này dù vài bước còn làm tay → sau này chỉ bổ sung, không làm lại.
Đặt-mới: có đơn → tạo lệnh sản xuất → giao đúng đơn. Để-tồn: làm sẵn hàng, tính khả năng giao (ATP) rồi phân bổ cho các đơn theo ưu tiên.
Mỗi thẻ là một module/màn hình, kèm việc nó làm & giai đoạn đáp ứng.
Hồ sơ khách: kênh, sales phụ trách, hạn mức công nợ, % chiết khấu & phí vận chuyển/KG riêng.
Nhập đơn (đầu đơn + dòng SKU), tính tiền/VAT/KG/chiết khấu/phí VC tự động, duyệt đơn.
Giá theo SKU × kênh, giá sàn, theo tháng, 2 kịch bản 85T/65T.
Kế hoạch 12 tháng theo khách×SKU; chính sách chiết khấu + hỗ trợ; báo cáo MTD/YTD cộng dồn.
Xuất kho cơ bản (W1); giao hàng từng phần & phiếu giao (W2).
Nhận thanh toán + phân bổ; công nợ & tuổi nợ; chặn vượt hạn mức (Wave 3).
Sổ chi phí theo tháng: vận chuyển, kiểm dịch, tiếp khách, đối ngoại… (kế hoạch vs thực tế).
KPI doanh thu/sản lượng/chiết khấu/phí VC/số đơn; biểu đồ theo kênh; top khách.
Chương trình ưu đãi theo khách/kênh/SKU/kỳ để so kế hoạch vs thực tế đúng nghĩa.
Phác thảo low-fidelity các màn hình & form nhập liệu chính, để đội hình dung mình sẽ thao tác thế nào. Khung xám là bố cục; điểm cam là hành động/điểm nhấn chính.
| SKU ▾ | ĐVT | SL | Đơn giá | %VAT | Thành tiền |
|---|---|---|---|---|---|
| CGRX0500 ▾ | Khay | 3.000 | 44.000 | 10% | 132.000.000 |
| CGRX1000 ▾ | Khay | 500 | 89.000 | 10% | 44.500.000 |
| + Thêm dòng… |
| Loại chi phí ▾ | Kế hoạch | Thực tế | Chênh lệch | Ghi chú |
|---|---|---|---|---|
| Vận chuyển | 40.000.000 | 38.200.000 | −1.800.000 | — |
| Kiểm dịch | 12.000.000 | 10.500.000 | −1.500.000 | Lô T6 |
| Tiếp khách | 8.000.000 | 9.300.000 | +1.300.000 | — |
| Đối ngoại | 5.000.000 | 4.100.000 | −900.000 | — |
| TỔNG CHI PHÍ HOẠT ĐỘNG KD | 65.000.000 | 62.100.000 | −2.900.000 |
| Khách hàng | Kế hoạch | Thực tế | Chênh lệch | %HT |
|---|---|---|---|---|
| KH001 — Ngọc Tú | 9.0tr | 8.8tr | −0.2tr | 98% |
| KH012 — Đại lý Hòa | 14.0tr | 15.4tr | +1.4tr | 110% |
| KH018 — NM Sài Gòn | 6.0tr | 5.7tr | −0.3tr | 95% |
| Tổng cộng | 29.0tr | 29.9tr | +0.9tr | 103% |
Mỗi yêu cầu theo khung Tác động (Impact) – Công sức (Effort) – Vấn đề (Problem) – Cái đã có (Existing) – Hiện trạng (Current) – Bài học (Lesson), kết thúc bằng kết luận đáp ứng.
Muốn: khi nhập đơn phải ghi nhận phí vận chuyển; mỗi khách một mức phí/KG riêng.
Thu vận chuyển/KG trên khách (ST 1000 · ĐL 1500 · NM 500) → phí = KG × mức/KG.Muốn: xem chiết khấu THỰC TẾ vs KẾ HOẠCH, CỘNG DỒN theo tháng, để lên ưu đãi cho từng khách.
06_Map_ChietKhau (CK + Hỗ trợ), cột actual 10_Actual_Input, YTD cộng dồn 09_Plan_TongHop; prototype có MTD/YTD.Muốn: theo dõi chi phí phòng KD theo tháng — vận chuyển, kiểm dịch, tiếp khách, đối ngoại…
Ánh xạ từng chức năng (mục Chức năng ở trên) vào "làm ngay" hay "để sau" — kèm khi nào đáp ứng.
| Chức năng | ✅ Làm được ngay (Wave 1) | ⏳ Chưa — phát triển sau + khi nào |
|---|---|---|
| Khách hàng | Hồ sơ đầy đủ: kênh, sales, hạn mức, ngày TT, % CK & phí VC riêng | — |
| Đơn bán hàng | Đầu đơn + dòng, tính tiền/VAT/KG/CK/VC, duyệt đơn; ghi CK + hỗ trợ thực tế | Báo giá → đơn (W3); sửa/xóa đơn nâng cao |
| Phí vận chuyển (#1) | Mức/KG theo khách + chốt trên đơn + tách thu hộ/chi phí | Theo vùng/khoảng cách W2 |
| Chiết khấu (#2) | Ghi CK + hỗ trợ thực tế + báo cáo MTD/YTD cộng dồn | Chương trình khuyến mãi (promo) W2 · khi có module promo |
| Chi phí phòng KD (#3) | Sổ chi phí + danh mục sửa được + kế hoạch/thực tế theo tháng | — |
| Bảng giá & Kế hoạch | Giá SKU×kênh (sàn, theo tháng, 85T/65T); kế hoạch 12 tháng | Bảng giá bán riêng đầy đủ (nếu không tận dụng giá sẵn) W3 |
| Xuất kho / Giao hàng | Xuất kho cơ bản | Giao từng phần + phiếu giao W2 · sau khi có Kho/Tồn |
| Kết nối Sản xuất (MTO/MTS) | Đã dựng cấu trúc liên kết | Lệnh sản xuất, ATP, phân bổ W2 · sau khi có Inventory/ATP |
| Thu tiền & Công nợ | Nhận thanh toán + phân bổ (cơ bản) | Tuổi nợ, chặn hạn mức W3 |
| Hóa đơn VAT | Sẵn cấu trúc (VAT tra bảng) | Tích hợp HĐĐT W3 · sau khi chốt nhà cung cấp HĐĐT |
| Thưởng KPI / Dòng tiền | — | Thưởng 2 cổng, dashboard sales, dòng tiền W3 |
Mỗi đợt giao một bộ năng lực dùng được ngay — kèm điều kiện kích hoạt ("khi nào đáp ứng").
13 câu hỏi mở — phần lớn đã có khuyến nghị, đội chỉ cần xác nhận để chốt phạm vi.
HTF2025) — chưa phải ERP. Mỗi nghiệp vụ là một form phê duyệt + luồng duyệt riêng.Các form Lark tham chiếu trực tiếp tới Lark Base làm cơ sở dữ liệu nền; một số trường gọi API ngoài qua AnyCross.
Chứa bảng dimension dim · Khách Hàng (master khách hàng). Chọn 1 khách → tự kéo về: Khách hàng, Địa chỉ, Mã số thuế, Thông tin liên hệ, Địa chỉ giao hàng.
Chứa DIM Nhóm Hàng Hóa dạng cascading: Nhóm hàng hóa › Nhóm hàng hóa con › Mã nhóm.
Cấp options động cho Khu vực (dùng chung 1 token cho form Khách hàng & Kho) và Kênh bán hàng. Danh sách giá trị thực nằm ngoài form.
Mỗi nghiệp vụ là một form + luồng duyệt. Badge màu = vai trò xử lý; hộp viền cam đậm = bước phê duyệt; hộp gạch nối = điểm rẽ nhánh.
Trường chính: Khối KH (Data from Base) · Mã đơn (tự sinh) · Kho · Ngày giao · cờ Tồn kho?/Sản xuất?/Hóa đơn? · bảng hàng hóa (SL × Đơn giá → Thành tiền) · Vận chuyển / Chiết khấu / Thuế GTGT → Tổng · Kế hoạch thanh toán.
"Sẵn hàng" → bỏ qua bước PPF, sang thẳng duyệt. "Hết hàng" → qua kế hoạch sản xuất rồi mới duyệt.
Trường chính: Mã lệnh (tự sinh) · Loại lệnh (Một phần / Một phần & Đóng đơn / Đủ) · Mã đơn · Khách hàng · Kho · Ngày giao · bảng hàng hóa (SL yêu cầu vs SL thực xuất) · Xác nhận giao: Nhân viên xuất + Hình ảnh/Video.
Loại lệnh ≠ "Đủ" → chèn bước nhập "SL xuất kho yêu cầu" trước khi chuẩn bị hàng (xuất kho một phần).
Trường chính: Mã đơn · Ngày giao dự kiến · Yêu cầu hóa đơn? / Tên kho / Mã kho / Tồn kho đáp ứng? / Sản xuất đáp ứng? · Khối KH (master) · bảng hàng hóa có Khối lượng tịnh(g) · Thuế GTGT / Phí VC / Chiết khấu → Tổng · Điều khoản thanh toán.
Bản "Đơn Bán Hàng" (nhóm Release) gần như trùng nghiệp vụ với ② "Tạo Đơn Hàng" (HTF2025) — khác nhãn & có thêm Khối lượng tịnh. Đây là một nguồn trôi phiên bản cần hợp nhất.
Trường chính: Mã phiếu (tự sinh) · Mã đơn hàng · Kho xuất · Ngày giao · Nhân viên xuất kho · Khối KH · bảng hàng hóa (Khối lượng tịnh(g), SL yêu cầu vs SL thực xuất).
Trường chính: Mã chứng từ · Ngày giao dịch · Khách hàng · Tài khoản · Mã giao dịch · Nội dung · Tổng tiền thanh toán · bảng phân bổ (Mã đơn hàng, Số tiền) · cờ kiểm tra Bằng 0? (phân bổ đủ).
Cùng pattern "tạo mới có duyệt → Data Admin sinh mã": người dùng đề xuất, ACC kiểm tra, cấp quản lý duyệt, Data Admin tạo mã cuối cùng.
Trường chính: Mã KH (tự sinh) · Tên · Địa chỉ · MST · bảng liên hệ (Tên, Điện thoại*) · phân loại Khu vực/Kênh bán hàng (External API).
Trường chính: Mã hàng (tự sinh) · Tên hàng hóa · Đơn vị · phân loại cascading Nhóm hàng hóa › con › Mã nhóm (Data from Base: Inventory Master Data).
Rẽ nhánh theo phòng ban của người tạo: thuộc Sales → Sales Manager duyệt; ngược lại → Accounting Manager duyệt.
Trường chính: Mã kho (tự sinh) · Tên kho · Địa chỉ · phân loại Khu vực (External API) / Chế độ quản lý (Nội bộ / Thuê ngoài) / Chức năng kho (5 loại: vật tư tổng hợp / nguyên liệu / bán thành phẩm / thành phẩm / phế liệu).
Phác thảo lại các form phê duyệt Lark theo đúng trường & bố cục hiện hành, để đối chiếu với giao diện mới ở tab "Sắp triển khai".
| Hàng hóa ▾ | Đơn vị | Số lượng | Đơn giá | Thành tiền (ƒ) |
|---|---|---|---|---|
| CGRX0500 ▾ | Khay | 3.000 | 44.000 | 132.000.000 |
| CGRX1000 ▾ | Khay | 500 | 89.000 | 44.500.000 |
| + Thêm dòng… |
| Hàng hóa | Đơn vị | SL yêu cầu | SL thực xuất |
|---|---|---|---|
| CGRX0500 | Khay | 3.000 | 3.000 |
| CGRX1000 | Khay | 500 | 480 |
| Mã đơn hàng ▾ | Số tiền |
|---|---|
| SO-0670 | 60.000.000 |
| SO-0671 | 40.000.000 |
| Bằng 0? (Tổng − Σ phân bổ) | 0 ✓ |
Cách làm hiện tại đủ để vận hành, nhưng chạm trần khi cần kiểm soát công nợ, báo cáo tổng hợp và dữ liệu nhất quán.
8 form độc lập, nối nhau bằng Mã đơn hàng nhập tay — dễ lệch, khó truy vết Đơn → Xuất → Giao → Thu.
KH / Hàng hóa / Kho nằm ở 2 Lark Base + API ngoài; tạo mới phải qua duyệt rồi Data Admin sinh mã thủ công.
Thu tiền chỉ phân bổ trên form với cờ Bằng 0?; chưa có công nợ, tuổi nợ, chặn hạn mức.
Số liệu nằm rải trong từng phê duyệt — không có dashboard doanh thu / sản lượng / chiết khấu theo kênh.
Khu vực & Kênh bán hàng lấy từ AnyCross (open-sg) — phụ thuộc token & kết nối ngoài để mở form.
Song song bản v2.0/v3.0 (WIP/Archived) và HTF2025; ② "Tạo Đơn Hàng" vs ⑤ "Đơn Bán Hàng" trùng nghiệp vụ, khác nhãn/trường.
DEC-0041 đã khóa foundation: Customer đi theo Party/Role/Profile, giá bán đi qua Price List/Item, Sales Order là chứng từ thương mại, fulfillment đầu tiên dùng inventory.stock_documents, Inventory giữ ledger vật lý.Cột phải là cách làm đúng để không phải refactor. Mỗi dòng neo vào một quyết định (DEC-00xx) đã accepted.
| Lark làm tắt (hiện tại) | Mầm tech-debt | Contract đã chốt → làm đúng |
|---|---|---|
| "dim Khách Hàng" = bảng phẳng riêng | Đổi tên / migrate khi mở AR & hóa đơn | DEC-0041 Customer là role trên business_parties + bảng customer_profiles riêng. Không tạo bảng customer độc lập; giữ CustomerRef ở tầng application. |
| Vận chuyển / Chiết khấu = field công thức trên header | Đập schema khi cần phân bổ theo dòng / tách "thu hộ" vs doanh thu | DEC-0022 đã bác bỏ inline delivery_fee_amount. Dùng sales_order_charges (freight/discount/support) + allocation theo dòng. Phí VC/khách = rate snapshot lên đơn. |
| Số tiền lưu VND trần | Không gắn được đa tệ / nhập khẩu sau này | DEC-0014 mọi tiền = NUMERIC(18,4) + currency_code NOT NULL + fx_rate_to_base nullable. |
| Trạng thái = tên node duyệt của Lark | Báo cáo & guard không nhất quán | DEC-0013 enum trạng thái + transition guard (draft→submitted→approved→…). Mỗi document thu hẹp vocab riêng. |
| Nối chứng từ bằng "Mã đơn hàng" nhập tay | Mất toàn vẹn dữ liệu, không truy vết được chuỗi | FK thật Order → Fulfillment document → Invoice/Receipt + DEC-0015/DEC-0026 idempotency. |
| Thành tiền / Tổng tính trong form (computed field) | Lịch sử đổi theo khi giá / rate đổi | Tính ở domain layer (value object) rồi persist snapshot dòng + tổng. Hy sinh "computed field" để lấy bất biến. |
| Master data tham chiếu Lark Base + AnyCross API | Phụ thuộc token ngoài; danh mục ngoài tầm kiểm soát | Đưa Customer/Item/Warehouse/Region/Channel vào foundation sẵn có. Region đã có DEC-0021; Channel = bảng reference mới. "Tạo mới có duyệt → sinh mã" = business_code_no_reuse + state draft→approved. |
| Mỗi nghiệp vụ = 1 Lark App + node graph riêng | Workflow cứng, không tái dùng, khó phân quyền | Duyệt = capability + state machine, không hard-code graph. Permission htf.sales.order:approve (DEC-0036/DEC-0037) gán role profile, scope theo site/region (DEC-0023). |
Đọc 27 cặp migration up/down trong apps/business-api/migrations/pg/ từ 0002 đến 0028. Phần lớn tái dùng; chỉ thêm đúng bảng còn thiếu và ALTER nhỏ. Mọi bảng theo cùng convention: id·tenant_id·*_snapshot·revision·idempotency_key + soft-delete + FK composite (tenant_id, id).
| Nhu cầu Sales | Cách | Bảng thật trong repo |
|---|---|---|
| Identity khách hàng | ♻️ dùng lại | master_data.business_parties |
| Vai trò "customer" | 🔧 sửa | master_data.business_party_roles — ALTER CHECK thêm 'customer' (hiện chỉ 'supplier') |
| Hồ sơ KD của khách: kênh, sales phụ trách, hạn mức, payment terms, rate phí VC/KG, % CK, địa chỉ/liên hệ | ➕ bổ sung | master_data.customer_profiles — mirror supplier_profiles (cùng kiểu profile gắn vào party) |
| Kênh bán hàng (ST/ĐL/NM/BCN) | ➕ bổ sung | master_data.sales_channels (reference) |
| Item/SKU · nhóm hàng · ĐVT · quy đổi (khay↔KG) | 🔧 sửa | Clean target: items · item_groups; nếu staged thì giữ physical catalog tables tạm thời nhưng API/UI dùng Item. |
| Kho · Khu vực · Kỳ giá · Hồ sơ công ty | ♻️ dùng lại | organization.sites/regions · price_periods · company_profile |
| Giá bán Item×kênh×kỳ gap thật | ➕ bổ sung | sales.price_lists · sales.price_list_items · sales.customer_price_lists. Không tạo bảng giá theo physical product naming khi đang clean sang Item Master. |
| Đơn bán hàng (header + dòng + lịch sử) | ➕ bổ sung | sales.sales_orders · sales_order_lines · sales_order_events — mirror procurement.purchase_orders* |
| Phí VC + Chiết khấu + Hỗ trợ | ➕ bổ sung | sales.sales_order_charges + _charge_allocations — mirror inventory.stock_transfer_charges* (DEC-0022) |
| Xuất kho / fulfillment (SL yêu cầu vs thực xuất) | 🔧 sửa ♻️ dùng Inventory | Mở inventory.stock_documents thêm business_purpose='sales_fulfillment' + source refs tới sales_order_lines; post inventory.stock_movements. Shipment logistics tables chỉ defer cho carrier/tracking. |
| Idempotency · Audit | ♻️ dùng lại | business_api.idempotency_records · audit_events |
| Thu tiền + phân bổ ("Bằng 0?") · Hóa đơn VAT | ➕ bổ sung W3 | sales.customer_receipts + receipt_allocations · sales_invoices — defer |
business_party_roles.party_role hiện CHECK IN ('supplier') và supplier_profiles là profile gắn vào business_parties. Customer đi đúng đường đó: thêm role + customer_profiles — không tạo bảng customer độc lập. Một đối tác có thể vừa là supplier vừa là customer.Fan-out 6 góc · 29 nguồn · 87 claim → xác minh đối kháng 3 phiếu/claim. 24/24 claim trọng tâm xác nhận hướng thiết kế trên; 1 claim phụ (mã class điều kiện SAP) bị bác.
Oracle TCA giữ Party trung tâm + lớp Customer Account cho quan hệ bán; Odoo gộp mọi đối tác trong 1 res.partner. Khớp business_parties + customer role + customer_profiles.
SO → Delivery/Picking → Invoice → Payment → sổ AR, nối bằng FK (D365; Oracle EBS Booked→Ship→AutoInvoice). Khớp 4 document tách + link FK.
SAP condition technique: mỗi phí/CK/thuế/freight là 1 condition type riêng, áp ở dòng hoặc header (phân bổ xuống dòng), snapshot rate+basis+value lên dòng. Khớp charges + allocations.
SAP/Odoo: giá là bản ghi có Valid From/To, tách khỏi master, chỉ áp khi ngày chứng từ trong khoảng. Khớp price list / price-list item + price_periods.
Oracle EBS: đặt 50, tồn 20 → tách dòng 20 (Shipped) + 30 (Awaiting). Khớp ordered vs shipped vs invoiced qty trên dòng.
Oracle Receivables: invoice (RA_CUSTOMER_TRX) + receipt (AR_CASH_RECEIPTS) + junction (AR_RECEIVABLE_APPLICATIONS) + payment_schedules cho tuổi nợ. Khớp receipt_allocations.
docs.oracle.com/cd/E18727_01/…/T172155T172158.htmres.partner (single party model): github.com/odoo/odoo/…/res_partner.pylearning.sap.com/…/configuring-condition-types-for-pricing-elementslearning.sap.com/…/managing-condition-records-for-sales-pricesdocs.oracle.com/en/cloud/saas/financials/25d/faofc/receivables-tables.htmllearn.microsoft.com/…/order-to-cash-overviewchannel vào key của giá bán.Mở rộng cái đã có, không tạo nhánh song song. 3 bước nền trước khi build document.
docs/decisions/0041-htf-sales-management-o2c-foundation.md: customer role/profile, price-list condition record, Sales Order, charge/allocation, sales fulfillment qua Inventory stock documents, và ranh giới hoãn (shipment logistics/AR/HĐĐT/promo).
ALTER CHECK business_party_roles thêm 'customer' + thêm customer_profiles (mirror supplier_profiles: kênh, sales phụ trách, hạn mức, payment days, rate CK, rate phí VC/KG). Permission htf.sales.* + role profile htf-sales, htf-sales-manager (DEC-0036/0037/0038).
sales_channels thành bảng thật; tận dụng Region (DEC-0021) & price_periods. Thêm sales.price_lists/price_list_items keyed theo Item + channel; internal target/floor pricing vẫn là planning guard.
features/procurementSales Order ≈ Purchase Order về cấu trúc. Dùng đúng shape hexagonal & quy ước đặt tên đã có trong repo (domain → application(ports) → infrastructure(adapters) → interface).
apps/business-api/src/features/sales/
domain/ sales-order.ts (entity + invariant + Totals VO)
sales-charge-allocation.ts · sales-order-state-map.ts
application/ sales-order-command-service.ts · -command-types.ts
-read-model.ts · -write-repository-port.ts · customer-ref.ts
infrastructure/ postgres-sales-order-repository.ts · postgres-sales-order-read-model.ts
interface/ sales-rpc.ts
apps/auth-web/src/features/sales/ application · infrastructure · ui
apps/business-api/migrations/pg/00xx_sales_foundation.up.sql (+ .down.sql)
sales, tiền theo DEC-0014)sales_orders · _lines · _events — mirror purchase_orders*sales_order_charges · _charge_allocations — mirror stock_transfer_charges*master_data.customer_profiles — mirror supplier_profilesmaster_data.sales_channelssales.price_lists · price_list_items · customer_price_listsinventory.stock_documents purpose/source refs cho sales_fulfillmentbusiness_party_roles CHECK +customer| Luồng Lark | Khối htf-platform | Giai đoạn |
|---|---|---|
| ② Tạo Đơn Hàng & ⑤ Đơn Bán Hàng trùng | 1 Sales Order document (gộp 2 form trùng của Lark) | Wave 1 |
| ① Lệnh Xuất Kho & ④ Yêu Cầu Giao Hàng | Sales fulfillment qua Inventory stock document (ordered vs fulfilled, partial + backorder, batch trace) | W1 cấu trúc W2 sâu |
| ③ Thu Tiền KH ("Bằng 0?") | Receipt + allocation lines; "Bằng 0?" = invariant domain | W1 thin W3 AR |
| (ngầm) Hóa đơn VAT | Invoice document tách riêng (structure-ready) | W3 · HĐĐT |
| ⑥⑦⑧ Tạo mới KH / Hàng / Kho | master-data CRUD + state draft→approved + sinh mã; nhánh duyệt theo phòng (⑦) = permission | Wave 1 |
| Cờ "Sản xuất? Đáp ứng/Không" | Demand link SO line → Work Order (MTO); ATP/commitment thuộc Inventory | Wave 2 |
htf.sales.order:approveinventory.stock_documents + Inventory movement handoff + sổ chi phí phòng (#3)