业务口径分销开票
开票物流费与繁花包干
物流费导入前后 / 更新前后各申请顺序的票据变化、不可开票物流收据、繁花包干城市仓开票逻辑与建议口径
Markdown 原文（给 AI 用）：https://doc.xfun.fun/partner-invoice-logistics.md
先看结论
- 线上分销发货单的实际运费目前全部为 0，所以现在每一笔开票申请，物流票据都是 0，用户付的物流加价全部算进了 平台服务费（花古德）。
- 系统 每次都按最新运费重新拆分金额；已经申请的项目金额固定，没申请的项目跟着最新运费变。
- 因此只要 一个订单分几次申请、中间运费有变化，累计票据就不等于用户实付：会 多开，也可能 少开。不可开票物流走收据，问题一样。
- 繁花包干城市仓（繁花到店）订单和普通繁花订单 走同一套开票逻辑，没有单独分支；城市仓加价归入平台服务费。
- 建议口径：订单任意一项第一次申请时，就把当时的物流金额定死（包括 0），之后不再随运费变化。
待产品确认
金额怎么拆（复习）
每个分销订单的钱，按下面的顺序依次分配，各项之和恒等于用户实付（现金 + 寻梦币）：
① 花材款 = 供货价 × 数量（可开票供应商开发票，不可开票的由平台开收据） ② 物流票据 = min( 实际运费分摊, 用户物流加价, 剩余额度 ) → 捷通（可开票物流）/ 收据（不可开票物流） ③ 供应链服务费 = min( 打包服务费, 剩余额度 ) → 花序 ④ 平台服务费 = 剩下的全部 → 花古德
- 实际运费取发货单的
实付运费 − 补偿/赔付（运费对账单导入的那个金额，不要求已结算），再按发货单下各分销订单的物流加价比例分摊到订单。 - 物流加价 = 折进商品单价的物流加价 + 一次性物流加价。
- 运费为 0 或取不到 → 物流票据为 0，物流加价顺延进平台服务费。
- 可开票物流：运营在后台勾选的物流商出发票（捷通）；没勾选的物流商，这部分金额走 收据。
物流费导入前 / 导入后
用一笔真实的繁花到店订单举例（20261011604480968105）：实付 51.60，花材供货价 30.30，物流加价 11.80，打包服务费 2.20。
| 时点 | 花材 | 物流票据 | 供应链服务费（花序） | 平台服务费（花古德） | 合计 |
|---|---|---|---|---|---|
| 导入前（运费 0） | 30.30 | 0 | 2.20 | 19.10 | 51.60 |
| 导入后，分摊到本单运费 8 | 30.30 | 8.00 | 2.20 | 11.10 | 51.60 |
| 导入后，分摊运费 ≥ 11.80 | 30.30 | 11.80（封顶加价） | 2.20 | 7.30 | 51.60 |
单看任一时点都是平的；问题出在 不同时点申请了不同的项。
**剩余额度很小时，运费会挤掉供应链服务费。**例：订单 20261011361232240029 实付 76.82，花材 71.30，物流加价 35.20，打包服务费 6.19，花材后剩余只有 5.52。
导入前：物流 0、花序 5.52、花古德 0；导入 8 元运费后：物流 5.52、花序 0、花古德 0。这种订单受影响的是 花序，不是花古德。
各种申请顺序下会怎样
仍用上面实付 51.60 的订单。已申请的项金额在申请时写进申请明细，之后不变；未申请的项每次打开页面重新算。
| # | 场景 | 运费变化后系统表现 | 累计票据 | 结果 |
|---|---|---|---|---|
| 1 | 运费导入 之后才第一次申请（一次或分批都行，期间运费不再变） | 各项按同一运费计算 | 51.60 | 正确 |
| 2 | 导入前 全部类型一起申请（此时物流 = 0，没有物流项） | 导入后物流项冒出来，显示「待申请」8.00 | 59.60 | 多开 8.00 |
| 3 | 导入前只申请了平台服务费 / 供应链服务费 | 同上，物流项可申请 8.00 | 59.60 | 多开 8.00 |
| 4 | 按运费 8 只申请了物流，后台把运费改成 12（封顶 11.80） | 物流已申请不变 8.00；平台服务费重算为 7.30 | 47.80 | 少开 3.80，永远开不出 |
| 5 | 按运费 8 只申请了物流，后台把运费改成 5 | 物流不变 8.00；平台服务费重算为 14.10 | 54.60 | 多开 3.00 |
| 6 | 先申请了平台服务费（物流 8 但没勾），后台把运费改成 5 | 平台服务费已按 11.10 开出；物流可申请 5.00 | 48.60 | 少开 3.00 |
| 7 | 按运费 8 所有类型一起申请，之后运费怎么改 | 全部已固定，物流项也已占用不能再申请 | 51.60 | 正确 |
- 场景 2/3 是 线上现在的常态：运费全是 0，已申请的订单将来只要导入运费，全部会出现可申请的物流项。
- 可申请池只含 确认收货 3 个月内的订单，超过 3 个月的老订单导入运费后也看不到，不会多开，但也开不出物流。
- 运费结算驳回被清零时，已开出的物流票据不会回滚（同理）。
不可开票物流
物流商没被运营勾选为可开票时，「物流票据」那一份钱 由平台出收据，其余规则完全一样。
| 时点 | 物流收据 | 这部分钱去哪了 |
|---|---|---|
| 导入运费前 | 0 | 用户付的物流加价全部在 花古德的平台服务费发票里（剩余额度小的订单还会在花序里） |
| 导入运费后 | min(运费分摊, 加价) | 平台服务费相应减少；若平台服务费已经开出，物流收据仍可再申请 → 与场景 2/3 一样 多开 |
导入前已开出的金额（10-16 统计，近 3 个月已完成分销订单，运费全为 0）：
| 出票方 | 按现行规则（物流 = 实际运费 = 0） | 对照：若物流收据按物流加价出 |
|---|---|---|
| 捷通 / 物流收据 | 0 | 886.30 万（收据） |
| 花序 · 供应链服务费 | 140.79 万 | 64.79 万 |
| 花古德 · 平台服务费 | 879.48 万 | 69.13 万 |
即：现行规则下，不可开票物流的收据是 0，物流加价约 886 万全部落在花古德（和少量花序）的发票里。「物流收据按加价出」那一列只是对照方案，产品未拍板。
繁花包干城市仓（繁花到店）
是什么
- 繁花惠小程序下单、收货点是城市仓的订单（订单
partner_id=140、ware_id>0），即运营后台显示「（包干）」的繁花订单。 - 它们的
app_id仍是繁花惠，所以 进同一个分销开票池，按第二节同一套规则拆分，代码里没有针对包干的特殊处理。
金额构成
| 订单上的钱 | 开票归属 |
|---|---|
| 花材供货价 | 花材款（供应商发票 / 平台收据） |
| 物流加价 | 物流票据（受实际运费封顶），超出部分进平台服务费 |
| 打包服务费 | 供应链服务费（花序） |
| 城市仓加价、满减、小件分拣费等 | 不单独列项，全部进 平台服务费（花古德） |
量级参考（10-10 ~ 10-12 三天已完成订单）：
| 订单数 | 实付 | 物流加价 | 城市仓加价 | 打包服务费 | |
|---|---|---|---|---|---|
| 繁花到店（包干城市仓） | 800 | 7.38 万 | 2.21 万 | 1.15 万 | 0.41 万 |
| 繁花直发 | 3,693 | 34.77 万 | 11.05 万 | 5.27 万 | 1.67 万 |
| 优花速达 | 3,381 | 41.97 万 | 17.88 万 | 4.03 万 | 2.01 万 |
物流费
- 到店订单的发货单同样 实际运费为 0（只有系统估算的「预估运费」，开票不读预估运费），所以第三、四节的问题对它同样成立。
- 抽查 10-11 的 169 张繁花到店发货单，都没有和城市仓自己的订单混在同一张发货单。若开启「合并发货」导致混单：运费只会分摊给其中的分销订单（以其物流加价为上限），城市仓订单不参与分摊。
不进这套开票的
- 城市仓包干收益、补短运费：是平台 / 繁花惠与城市仓之间的结算，不进终端用户的票据。
- 城市仓自己的订单（花仓酷城市仓、城市仓包干
partner_id=0）：不是分销小程序订单，走普通大件批发开票流程。 - 分销商物流结算（按场次整笔扣分销商运费）：9-01 至今繁花 152.52 万、优花速达 219.62 万，是按场次的整笔金额，没有落到发货单上，开票不读这张表。如果「导入运费」指的是这里，需要另外确认怎么拆到发货单。
建议口径 待产品确认
订单第一次申请任意一项时，把当时算出的物流金额记下来（包括 0） 不管这次勾了哪些类型，发票侧、收据侧都记。
以后这个订单再申请其他项，物流都用记下的值，不再读最新运费 累计票据恒等于实付；第四节 2~6 场景都不会出现多开 / 少开。
代价 订单开过任何一项之后，再导入或修改的运费不会体现在票上；那部分钱已经在平台服务费（或花序）里开出去了。
备选：允许按新运费补开物流，但需要对已开的平台服务费红冲重开，流程重、涉及已开发票，不建议。
依据代码：PartnerInvoiceAmountCalculator、PartnerLogisticsCostProvider、PartnerInvoiceLogic、PurchaserReceiptLogic（xm-bulky-mall-purchaser，master）。数据取自生产库只读查询。相关文档：开票逻辑梳理。