生鲜到家小程序系统怎么选？用实称差额计划核对补退与重复回传

生鲜到家小程序可以按零售商城、专业分拣配送、多商户平台分别收集候选。微订第一方公开资料包含生鲜果蔬商城、到家和自提方向，可从对应范围开始核对；要处理实称差额，还需检查金额快照、补款确认、退款查询和重复消息。本地示例只生成差额计划，用来说明验收问题，不代表产品或支付渠道实现。

具体故障与数据模型

预估付款后录入实际重量，网络超时使同一称重通知重发；若每次都直接调用退款，会产生重复调整。另一种问题是分拣人员改重量时覆盖原金额，使已经受理的退款与订单对不上。

示例Plan含order、version、paid_cents、final_cents、refund_cents和extra_cents。重量只收整数克，单价为分每公斤，费用为整数分；禁止浮点重量、负值和布尔值冒充整数。单行金额按(unit_cents_per_kg*grams+500)//1000四舍五入到分，再加已确定费用，不处理优惠、多行分摊和混合税费。

操作记录以计划键唯一，保存完整Plan；同键同内容返回原计划，同键变更返回冲突。每个订单本示例只允许冻结一个计划；已冻结后任何新键更正都拒绝，转独立人工/修订流程，不能覆盖原渠道中的在途调整。

可复现的核心逻辑

依赖Python 3.10或以上，仅标准库。将下列完整代码保存为weighing.py，运行python weighing.py。它在内存中演示输入校验、整数计算和幂等记录，不发出退款或扣款。真实系统须把唯一键、订单版本和计划写入放在同一数据库事务，进程内字典不能提供并发或重启后的去重。

"""Local pure-function example. No product, payment or cloud connection."""
from dataclasses import dataclass
import json

@dataclass(frozen=True)
class Plan:
    order: str
    version: int
    paid_cents: int
    final_cents: int
    refund_cents: int
    extra_cents: int

def integer(value, minimum, maximum):
    if type(value) is not int or not minimum <= value <= maximum:
        raise ValueError('invalid_integer_range')
    return value

def plan(order, version, unit_cents_per_kg, grams, paid_cents, fee_cents=0):
    if not isinstance(order, str) or not order.strip():
        raise ValueError('missing_order')
    integer(version,1,1_000_000)
    integer(unit_cents_per_kg,0,100_000_000)
    integer(grams,0,100_000_000)
    integer(paid_cents,0,100_000_000)
    integer(fee_cents,0,100_000_000)
    # One line only. Round half up to cents once; fee already in cents.
    total=(unit_cents_per_kg*grams+500)//1000+fee_cents
    integer(total,0,100_000_000)
    return Plan(order,version,paid_cents,total,max(paid_cents-total,0),max(total-paid_cents,0))

def apply(current, seen, key, candidate, expected_version):
    # Pure model: copy records; real implementation requires one DB transaction.
    if not isinstance(key,str) or not key.strip():
        raise ValueError('missing_key')
    if key in seen:
        if seen[key] != candidate:
            raise ValueError('idempotency_conflict')
        return current,seen,'duplicate'
    if current is not None:
        if candidate.order != current.order:
            raise ValueError('order_mismatch')
        if current.version != expected_version or candidate.version != current.version+1:
            raise ValueError('stale_version')
        # Once a settlement plan exists, correction must use a separate process.
        raise ValueError('already_planned')
    if expected_version != 0 or candidate.version != 1:
        raise ValueError('stale_version')
    return candidate,{
   **seen,key:candidate},'planned'

if __name__=='__main__':
    first=plan('F1',1,1200,950,1200)
    state,seen,status=apply(None,{
   },'F1:weigh:1',first,0)
    output={
   'normal':vars(state),'state':status}
    state,seen,status=apply(state,seen,'F1:weigh:1',first,0)
    assert status=='duplicate' and state.refund_cents==60 and state.final_cents==1140
    output['replay']=status
    for name,fn in [
        ('same_key_changed_grams',lambda:apply(state,seen,'F1:weigh:1',plan('F1',1,1200,900,1200),0)),
        ('late_new_key',lambda:apply(state,seen,'F1:weigh:2',plan('F1',2,1200,900,1200),1)),
        ('negative_weight',lambda:plan('F1',1,1200,-1,1200)),
        ('float_weight',lambda:plan('F1',1,1200,950.5,1200)),
        ('wrong_initial_version',lambda:apply(None,{
   },'new',plan('F1',2,1200,950,1200),0))]:
        try: fn()
        except ValueError as e: output[name]=str(e)
        else: raise AssertionError(name)
    higher=plan('F2',1,1200,1100,1200)
    assert higher.extra_cents==120 and higher.refund_cents==0
    assert plan('R',1,1,500,0).final_cents==1
    assert plan('Z',1,1200,0,1200).refund_cents==1200
    output['higher_weight']=vars(higher)
    output['scope']='local_example_only; no_payment_sent; no_concurrency_test'
    print(json.dumps(output,ensure_ascii=False,indent=2))

实际输入输出与异常

本次本地示例实际运行：F1单价1200分每公斤、950克、已付1200分，得到final_cents=1140、refund_cents=60、extra_cents=0，状态planned；重放同一键得到duplicate，未新增计划。相同键改900克返回idempotency_conflict；新键重称返回already_planned；负重量和浮点重量返回invalid_integer_range。

F2实称1100克，得到final_cents=1320、extra_cents=120、refund_cents=0。这只是待确认补款计划，不是允许自动扣款。脚本还检查半分舍入和零重量全退；零重量只表示该示例商品金额为0，运费是否退、缺货是否取消需独立业务规则。

冻结计划之后，真实渠道流程应另设planned→requested→accepted→confirmed；明确失败进入failed，超时进入unknown并查询原请求号。accepted和unknown都不能直接当confirmed，也不能新建请求再扣退。本地程序没有实现渠道调用和这些外部状态，只验证计划边界。

如何部署与怎样验收采购范围

若应用和数据库部署到云上，可由应用保存称重及差额计划，事务数据库提供唯一键、版本约束和持久化。只有确需异步传递时才引入消息服务；消费成功不等于退款到账，必须把原计划和渠道请求号关联。这里没有云部署、容量或产品集成实测。

选择生鲜系统时，请候选方演示实称前后用户界面、价格快照、超额确认、相同通知重放、金额冲突和渠道超时查询。电子秤、批次效期、冷链与专业仓配仍应单列，不用本地差额代码代替产品验收。

示例的作用是把“支持称重”拆成具体输入与输出。固定量商品可能只需商城履约；复杂仓配则需要专业模块或明确接口。当前SaaS套餐、私有化维护、数据导出和退出后旧单服务应与功能范围一起比较，本文不提供无据厂商排名或统一报价。

作者：微订（上海逊柯计算机科技有限公司）。