一位创作者提供模板，一位维护生成程序，还有人负责销售和客户修改。三个人合作卖出同一项服务，如果只按函数调用次数分钱，模板设计和售后劳动就很容易从账上消失。
先把一笔订单算清楚：买家付了钱，第一次生成失败，上游仍收了费，后来又退款。谁承担这次成本，销售分成是否退回，人工修改怎样记？这些决定不能等到账单出来以后再由系统猜。
早期用合作协议、成本表和每月对账已经可以运行。约定分的是总收入还是扣除哪些成本后的余额，并把退款和争议处理写清，比急着自动分账更重要。
执行部分接入 EasyNet 后，可以把订单关联到模板处理、生成和导出等调用，提供方返回产物与运行事实。各方只能读取获准的订单信息，原始客户素材不必为了核算收入流转给所有合作者。
支付、退款、上游成本和人工工作仍需从各自记录接入。一次调用完成不证明钱已到账，也不说明贡献比例；真正的打款、税务和法律安排应由相应服务与负责人处理。
请每位参与者独立核算一张成功订单、一张失败订单和一张退款订单。大家能从同一组记录得到一致结果，再考虑自动执行已达成的规则；若结果不同，先修订约定，不让自动化放大分歧。
- 01
一笔已收订单
收款、支付费、上游成本分别记账
- 02
执行关联
模板、生成、导出对应同一订单
- 03
按已同意规则复算
先核对成功、失败、退款，再安排结算
用分为单位复算一笔示例订单
假设三方已经同意扣成本后按 20/30/50 分配，示例只算账、不打款。比例和亏损承担必须事先约定。
本地示例 · python
paid_cents = 10000
refund_cents = 0
payment_fee_cents = 300
upstream_cost_cents = 1700
balance = paid_cents - refund_cents - payment_fee_cents - upstream_cost_cents
if balance < 0:
raise ValueError("Apply the separately agreed loss rule")
template = balance * 20 // 100
generation = balance * 30 // 100
operations = balance - template - generation
assert template + generation + operations == balance
print(template, generation, operations)预期结果：输出 1600 2400 4000；改成全额退款时明确进入亏损规则，而不是照样自动分账。
接入时的检查项
- 同一订单的收入、成本、退款与分配能够完整对上，参与者看到一致口径。
- 失败重试和测试调用不会自动变成新的可结算收入。
- 比例变更有生效日期，旧订单按已约定规则结算且可追溯。