南京易企达交付的生鲜到家App：顾客按品类下单、选配送时段，门店按单分拣、骑手按时段派送；称重商品按预估价下单、出库按实重补差，缺货先确认再替换，退款走原路。
只列可核查的交付事实：项目定位、交付形态、覆盖范围、技术选型与归属口径。
每一项都是客户实际在用的功能，不是模块清单。
按蔬菜、水果、肉禽、水产、粮油分区陈列，标清规格与产地。称重类商品显示「约 500g」，把「约」字放在最前面，别让顾客到收货时才知道有出入。
顾客选送货或自提，再选时段（如次日 9:00-11:00）。每个时段有容量上限，满了就置灰；截单时间到了自动停止接单，避免下了单却凑不齐一趟车。
门店端按订单打印分拣单，按品类分区取货、逐项勾选。分拣完成后进入待派送，骑手按配送时段批量取单，一单送达即时回传签收。
下单时按预估价冻结金额，出库称重后按实重结算，差额自动补扣或退回，账单上明写「预估」与「实收」。顾客不必为了几毛钱找客服。
分拣发现缺货，先推送替代方案给顾客确认，同意的替换、不同意的整项退款。默认不自动替换——送到家才发现换了东西，比缺货更让人不满。
会员价、满减、优惠券可叠加规则在后台配置，前台展示优惠后的到手价。报表按品类看销量、损耗与退款率，哪些品该下架有数据可依。
先看入口与业务域，再看技术选型；只写结构与取舍，不写客户内部数据。
不是功能罗列，是当初的判断。
称重商品预估价与实收价分开列示，差额明细写在账单里。生鲜本来就有误差，把误差说清楚，比用「多退少不补」的话术更省客服。
缺货在分拣环节就推给顾客确认，同意替换或整项退款由顾客自己选。送达后再解释，损失的不只是这一单。
派单先按配送时段归堆，再看路线凑单。按订单先后逐单派，骑手会各自跑一趟，油钱和时间都耗在路上。
进货、销售、报损、退款四条线分开记，按品类看损耗率。哪个品一直在亏，账上看得到，不必凭感觉下架。
同样的需求，不同做法代价不同；这里写清楚为什么这样选。
称重商品没法在下单时就确定金额。先把预估价冻结、出库按实重结算，两条金额都留在订单上，退款与对账才有依据；合成一个数，后面每笔差额都要人工解释。
自动替换看起来省事，实际是把麻烦推给收货那一刻。推送给顾客选，同意就换、不同意就退，一次沟通换掉一次投诉。
每个时段能送多少单是运力决定的。时段不限量，订单就会堆在同一个时间窗，骑手跑不过来，最后受损的是口碑。
判断标准写在这里，避免双方预期错位。
问答与页面结构化数据同源，答案口径两站一致。
下单按预估价冻结，出库称重后按实际重量结算：多了补扣、少了退回，差额在账单上单独列出。这样顾客下单时看到的是「约」多少，收货时看到的是「实收」多少，两者都有记录，不靠客服口头解释。
分拣环节发现缺货会即时推送替代方案，由顾客在 App 里选同意替换或整项退款。系统不会默认自动替换，也不会等到送达才告知；退款按原支付渠道退回，通常当天到账。
按门店的实际运力设置每天的时段与每段容量，容量满了前台自动置灰。截单时间后不再接单，保证已接的订单能在承诺时段内送达。时段和容量都可以在后台按天调整。
可以。订单来源可以扩展到第三方平台，配送也可以交给第三方运力，系统侧做统一接单与状态回传。需要对方开放接口，具体能接到什么程度要在项目开始前确认。
优惠规则（会员价、满减、券）在后台配置，结算时按固定顺序计算并在订单上留下计算明细，出现争议可以逐项核对。规则越复杂越要限制叠加层数，否则顾客自己也看不懂为什么是这个价。
应用市场账号由客户主体注册并持有，我们协助准备上架材料、完成打包与提审。需要客户提供营业执照、隐私政策与相关资质；上架审核时间取决于各应用市场，通常几天到两周不等。
本页不含报价。费用主要取决于商品规模、是否对接第三方平台与配送、以及是否要接入已有 ERP 或收银系统。一般分两期：先上商品、下单与配送主线，再补会员优惠与损耗报表。