包花厂集采业务逻辑

结论

包花厂集采是一条「运营发计划、供应商报价、系统定采、仓库收货、平台结算」的链路：

1. 运营发布采购计划，写清品类、规格、各等级收购扎数和最高价、哪些供应商能报。
2. 供应商按等级报单价和可供扎数，截止前可以改报。
3. 报价截止后系统自动定采：每个等级取价格最低的前 5 家，依次分到需求量为止，给中选的供应商各生成一张供货单。
4. 仓库给供货单签到 → 打印标签 → 开始盘点 → 扫码。每扫一张标签 = 入库 1 扎，库存在扫码那一刻就加上。
5. 提交盘点后供货单进入待结算，3 天后按冻结报价自动结算；送多了（超量）要先人工处理才能结算。

三条贯穿全链路的口径：

• 单位一律是扎，单价是元／扎。每扎多少枝（specNum）只用于展示和标签，不参与任何乘法。
• 价格在定采那一刻冻结到供货单，之后改商品售价、改报价都不影响结算。
• 采购计划和供货单的状态互相独立。计划「已完成」只表示定采流程结束，货还没收、钱还没结。

开发实现、接口、锁与定时任务见 包花厂集采开发文档。

角色与业务对象

数量与金额口径

应结算金额 = Σ（等级应结算扎数 × 等级冻结单价）

例：A 级 3 扎、2.50 元／扎，B 级 2 扎、1.80 元／扎，每扎 20 枝：

3 × 2.50 + 2 × 1.80 = 11.10 元   （不再乘 20 枝）

主流程

运营配置品类、规格、等级数量、供应商范围、时间
  └─ 发布采购计划（报价中）
       └─ 供应商按等级报价 / 改报
            └─ 两类供应商的报价截止都已过（或运营提前终止）
                 ├─ 没人报价 / 没有可分配的量 ──→ 计划关闭
                 └─ 自动定采 → 生成供货单 → 计划立即「已完成」
                                   └─ 供货单：待签到
                                        └─ 签到 → 打印标签 → 开始盘点 → 扫码（同步入库）
                                             └─ 提交盘点 → 待结算（未扫标签作废）
                                                  ├─ 有超量 → 按等级确认结算数 → 处理超量
                                                  └─ 无超量 / 已处理 → 到期自动结算 或 手动结算 → 已结算

采购计划状态

供货单状态

标签状态

规则：发布采购计划

发布前必须确定：发布主体、场次、二级分类、包装规格、毛花 / 成品花、商品规格、开放的等级，以及每个等级的收购扎数、最高价、最小提交量、单家最大提交量。

供应商范围

所有范围的基础条件都是「花材供应商且 data_status=2」。范围命中 0 家时不能发布。

产出截止（采集截止）

产出截止决定供货单最晚什么时候必须有产出，过了还没扫过一张就会被自动取消。

产出截止 = max（场次次日 12:00，最晚签到截止 + 2 小时）

• 场次 11-05，最晚签到截止 11-05 20:00 → max（11-06 12:00，11-05 22:00）= 11-06 12:00
• 场次 11-05，最晚签到截止 11-06 11:00 → max（11-06 12:00，11-06 13:00）= 11-06 13:00

发布后的调整

规则：供应商报价

报价截止提前 5 秒

供应商实际能提交的最后时刻 = 配置的报价截止 − 5 秒，到达该时刻即拒绝。

例：配置截止 10:00:00，供应商必须在 09:59:55 之前完成请求；09:59:55 已提示「报价已截止，报价和改价须在截止时间前5秒完成提交」。运营端仍按原截止时间（10:00:00）推进定采。

定采前调价

规则上要求：计划处于待定采、自己的报价未被定性、没有供货单、且仍在报价截止前 5 秒之前。正常流程中计划进入待定采时报价截止已过，所以自然截止后基本不可能调价，调价诉求应在报价中用「修改报价」完成。

供应商列表

列表只显示场次日期在服务器当天往前一个月及以后的计划（包括未来场次）。更早的计划在有权限时仍能打开详情。

规则：自动定采

触发：两类供应商的报价截止都已过（系统每 5 分钟检查一次），或运营提前终止且有报价。

算法（每个等级独立计算）：

1. 候选 = 该等级可供扎数 > 0 的当前报价（填 0 的只报价不参与）。
2. 排序：价格低优先 → 同价提交早优先 → 再按供应商 ID 小优先。
3. 只取前 5 家。
4. 从第 1 名开始，每家最多拿自己的可供量，凑满该等级需求就停。
5. 前 5 家合计不够时如实少采，不找第 6 家补。

例：某等级需求 1000 扎，前 5 名按价格从低到高为 甲 500、乙 200、丙 500、丁 100、戊 100：

甲 500 + 乙 200 + 丙 300 = 1000 扎，丁、戊一扎不分

例：需求 1000 扎，前 5 名可供合计只有 800 扎 → 分 800 扎，缺 200 扎，第 6 名也不补。

结果：

• 同一供应商在多个等级中选 → 合并成一张供货单；供货单保存各等级冻结单价。未中选的等级也可能保留报价明细（可在额度内为这些等级补打标签，见「规则：签到与打印标签」）。
• 有中选结果 → 生成供货单，计划立即「已完成」。
• 没人中选 → 计划「已关闭」。
• 判断结果以供货单为准，不以是否收到「已采用」消息为准。

规则：签到与打印标签

签到：待签到的供货单签到后转待盘点。超过签到截止仍可以签到，系统记迟到标记；集采签到不触发基地迟到处罚。

正常 / 增量打印（待盘点、待结算可用）：

例：整单定采 50 扎（上限 100 张）。A 级已生成 10 张，改成 12 → 只新增 2 张（序号 11、12）。若 A 已 60 张、B 填 50 张 → 合计 110 张，超过 100 张被拒。

重打：按「等级 + 序号区间」重新取回原标签，复用原码，不新增数量。区间必须在 1 ~ 已生成张数之间，区间内有作废标签则不能重打。已取消的供货单不能重打。

规则：扫码入库

1. 先点「开始盘点」占用这张供货单。同一张单同时只允许一个人盘点；扫码、撤销、提交盘点都必须是占用人本人。暂停或交班时用「释放占用」。
2. 「首码识别」只用于确认标签属于哪张单，不计数、不入库。
3. 扫码成功时，以下动作在同一个事务里完成：标签置已扫码、该等级扫码数 +1、整单实际产出 +1、发布主体对应商品库存 +1 扎。

扫码被拒（接口外层成功，但内层 data.success=false，本次不计数）：

撤销扫码：只能撤销本人扫的、且供货单仍待盘点的标签，同时扣回 1 扎库存。若这批库存已经卖出、剩余库存不够扣，撤销失败。

规则：提交盘点

提交后系统：

1. 按各等级扫码数重算实际产出，默认应结算扎数 = 扫码数，算出金额；
2. 未扫标签全部作废；
3. 供货单转待结算，释放占用；
4. 计划结算时间 = 提交盘点时间 + 3 天；
5. 实际产出 > 定采扎数时标记未处理超量 overFlag=1。

提交后不能再扫码或撤销。要改付款数量，在待结算阶段按等级改应结算扎数，不要改扫码数据或重复提交。

规则：超量处理

超量单仍是「待结算」，不单独设异常状态。有未处理超量的单既不会自动结算，也不能手动结算。

超量扎数 = max（实际产出 − 定采扎数，0）

处理时选两种类型之一，并填写处理说明。

类型 1：供应商自身超送

供应商自己多送了。必须先按等级确认应结算扎数（哪怕决定全额结算，也要显式提交一次），再登记「自身超送」。

类型 2：混货 / 错贴标签

当前单扫到了别家的货。处理步骤：

1. 按等级把当前单的应结算扎数改小，扣减量 = 扫码数 − 应结算数。
2. 逐条登记被占用方：同一计划下的其他供应商、等级、被占用扎数、补偿方式。被占用方必须有效且已待结算（未提交盘点、已结算都不行），且其供货单包含该等级。
3. 对平：每个等级的扣减量必须等于该等级所有补偿明细的被占用扎数合计（三种补偿方式都算），两边任何一个等级对不上都拒绝。

例：当前单 A 级扫码 20 扎、定采 11 扎，改应结算为 11 扎（扣减 9 扎）。被占用方原应结算 10 扎：

登记补款 2 扎 + 线下补偿 3 扎 + 无需补偿 4 扎 = 9 扎   （与扣减对平 ✔）
被占用方应结算 = 10 + 2 = 12 扎                     （只有登记补款进系统应付）

compensateAmount 补偿金额可以手填（≥ 0，最多两位小数），不填按被占用方冻结单价 × 扎数计算。它是台账金额，不会覆盖任何供货单的应结算金额。

处理之后

• 当前单 overFlag 清为 0，记录处理人、时间、说明。
• 运营端列表：已处理的单显示超量扎数 0、超量金额 0.00；详情仍保留原始超量差额和按冻结价算的历史超量金额。
• 列表提示消失 ≠ 库存退回 ≠ 应结算金额变 0。各端显示不一致时先看处理标识、处理时间和等级结算明细，不要重复处理。
• 处理超量不等于付款。若计划结算时间已过，下一轮自动结算会接住；没到期则继续等，或手动结算。
• 历史已处理数据不会随新规则自动冲回，发现差异交开发和财务核对。

规则：结算

记账动作（运营后台、仓库端、自动任务共用同一套）：

• 金额为 0 时也置已结算并留审计，但不产生余额账变，仍会给供应商发结算通知。
• 结算记入的是供应商平台余额，不代表银行转账或提现已经完成。
• 结算通知在数据库提交后发送，消息没收到 ≠ 没结算，不能因此再结一次。
• 运营后台手动结算失败、超时或无返回时，先刷新供货单和账变确认结果，再决定是否重新操作。

规则：取消供货单

取消后未扫标签全部作废。

规则：商品与库存

• 商品归发布主体。打印时按「发布主体 × 二级分类 × 等级 × 商品规格」找商品映射，没有就自动建品（集采专用建品 type=3，不是到场货 type=1）。
• 自动建的商品：价格 0、库存 0、下架、无图。库存靠扫码增加。
• 入库后需要运营在「包花厂商品」里确认售价并手动上架，0 元商品会被上架校验拦截。「已入库但采购端看不到」多半是没上架，不是扫码失败。
• 核对商品要同时看主体、分类、等级、完整规格和映射，不要只按商品名找。
• 改商品售价不影响供货单冻结报价。库存推送异常查推送日志，不要用再扫一次码来补。

现场操作清单

到场先确认

1. 环境、当前场次、运营账号、仓库账号；当班业务负责人和技术升级联系人。
2. 当天的采购计划和关联供货单；两类供应商的报价截止、签到截止；供货单的产出截止。
3. 拿一张正常供货单走一遍签到、打印、开始盘点、扫码入口；确认打印机、标签纸、扫码枪可用。
4. 当天待盘点、超量待处理、已到期未结算的单据，先处理会阻塞作业或付款的。
5. 请开发确认运营端需求推进任务、供应商端自动结算 / 自动取消任务的启用状态和最近执行结果。

记录问题时至少写

环境、发生时间、账号角色、场次、采购计划号、供货单号、操作步骤、完整提示。扫码问题补标签码；资金问题补处理前后的应结算扎数和金额。

交接时当面核对

现场环境和服务版本、当日场次与截止时间、可用账号和设备、待处理异常单清单、定时任务的频率与负责人、升级联系人、未完成的资金或库存核查。每项遗留都要有单号、当前状态、下一步、负责角色。

常见问题排查