方案设计：生鲜损耗控制
业务规则设计
基于需求探索阶段的分析，我们设计了以下业务规则：
1. 差异容忍规则
| 条件 | 动作 | 触发通知 | 备注 |
|---|---|---|---|
| 实际重量 = 采购重量 ± 2% | 直接入库，系统自动平账 | 无 | 允许 2% 正常误差 |
| 实际重量 > 采购重量 + 2% | 暂停入库，通知采购员决策 | 采购员（微信/短信） | 可能需要退货或补单 |
| 实际重量 < 采购重量 - 2% | 生成损耗单，通知财务审核 | 财务、采购员 | 需要审核确认后入库 |
规则说明：
- 2% 是基于行业经验的合理误差范围
- 可以针对不同品类设置不同的容忍度（例如：冻品 3%，生鲜 2%）
2. 自动平账逻辑
场景 A：正常误差（± 2% 以内）
实际重量：490kg
采购重量：500kg
差异：-10kg（-2%）
系统自动处理：
1. 入库重量：490kg
2. 采购单价：30元/kg
3. 应付金额：490kg × 30元 = 14,700元
4. 自动生成入库单和财务凭证
5. 记录损耗：10kg（自然损耗）场景 B：多收（> +2%）
实际重量：520kg
采购重量：500kg
差异：+20kg（+4%）
系统处理流程：
1. 暂停入库
2. 微信/短信通知采购员
3. 采购员选择：
a) 全部收货 → 补签采购单
b) 退回多余部分 → 按 500kg 入库
4. 完成采购员确认后，系统自动入库和平账场景 C：少收（< -2%）
实际重量：480kg
采购重量：500kg
差异：-20kg（-4%）
系统处理流程：
1. 生成损耗单（待审核）
2. 通知采购员和财务
3. 财务审核：
a) 正常损耗 → 审核通过，按 480kg 入库和结算
b) 异常损耗 → 要求供应商补货或赔偿
4. 审核通过后，系统自动完成入库和平账业务流程图
总体流程
详细流程说明
步骤1：收货称重
- 仓管员扫描采购单二维码
- 系统自动显示：采购品名、规格、采购重量
- 仓管员将货物放上电子秤
- 系统自动读取实际重量
步骤2：自动判断
差异判断接口规范
接口名称: checkWeightDifference
输入参数:
- actualWeight: 实际重量(number, kg)
- purchaseWeight: 采购重量(number, kg)
- tolerance: 容忍度(number, 默认0.02)
输出格式:
typescript
{
status: "AUTO_APPROVE" | "NEED_BUYER_APPROVE" | "NEED_FINANCE_APPROVE",
difference: number,
percentage: number,
action: string
}业务规则约束:
- 差异百分比 = (实际重量 - 采购重量) / 采购重量 × 100
- |差异百分比| ≤ 容忍度 → AUTO_APPROVE
- 差异百分比 > 容忍度 → NEED_BUYER_APPROVE
- 差异百分比 < -容忍度 → NEED_FINANCE_APPROVE
错误码定义:
- E001: 参数缺失
- E002: 重量为负数
- E003: 容忍度超出范围(0-1)
步骤3：执行动作
根据判断结果，系统自动执行相应动作（见流程图）
数据结构设计
收货记录表
typescript
interface ReceiptRecord {
id: string; // 收货单号
purchaseOrderId: string; // 采购单号
supplierId: string; // 供应商ID
productId: string; // 商品ID
// 重量信息
purchaseWeight: number; // 采购重量（kg）
actualWeight: number; // 实际重量（kg）
difference: number; // 差异（kg）
differencePercentage: number; // 差异百分比（%）
// 处理状态
status: 'AUTO_APPROVED' | 'PENDING_BUYER' | 'PENDING_FINANCE' | 'COMPLETED';
// 处理结果
finalWeight: number; // 最终入库重量
finalAmount: number; // 最终结算金额
// 审核信息
buyerApproval?: {
approver: string;
decision: 'ACCEPT_ALL' | 'RETURN_EXCESS';
approvedAt: Date;
};
financeApproval?: {
approver: string;
decision: 'APPROVED' | 'REJECTED';
approvedAt: Date;
reason?: string;
};
// 时间戳
receivedAt: Date; // 收货时间
completedAt?: Date; // 完成时间
}界面设计要点
仓管员收货界面（移动端）
┌─────────────────────────┐
│ 收货：海鲜-大虾 │
│ │
│ 采购重量：500.00 kg │
│ 实际重量：490.00 kg │
│ 差异：-10 kg (-2%) │
│ │
│ [✓ 自动入库] │
│ │
│ 系统已自动处理： │
│ • 入库：490kg │
│ • 损耗：10kg（正常） │
│ • 应付：14,700元 │
└─────────────────────────┘采购员处理界面（微信通知）
【收货异常通知】
商品：海鲜-大虾
采购重量：500kg
实际重量：520kg
多收：+20kg (+4%)
请选择处理方式：
[ ] 全部收货（需补签采购单）
[ ] 退回多余部分
[查看详情] [立即处理]关键技术点
1. 电子秤集成
- 支持蓝牙电子秤
- 实时读取重量数据
- 自动传输到系统
2. 规则引擎
- 可配置的容忍规则
- 支持不同品类设置不同规则
- 规则变更不需要改代码
3. 通知机制
- 微信公众号/企业微信通知
- 短信通知（备用）
- 系统内消息推送
方案验证
方案验证路径
阶段一：原型验证
- 验证目标：确认自动判断逻辑是否符合业务预期
- 关键依赖：需要客户提供历史收货数据样本(至少100条)
- 验证标准：误判率 < 5%
阶段二：小范围试点
- 试点范围：选择2个高频供应商(每日收货 > 5次)
- 规则调优：根据实际数据调整容忍度
- 关键指标：自动处理率 > 80%, 误判率 < 3%
阶段三：全面推广
- 推广策略：按供应商类别分批上线
- 风险控制：保留人工复核通道，双轨运行
下一步
方案设计已完成并验证可行，下一步进入 开发资产 → 阶段，沉淀可复用的开发规则和代码。