农户
槟榔鲜果的自然人供应方，完成实名、资料确认、订单确认和收款。
00 / 业务背景
海南槟榔业务介绍
本系统聚焦海南槟榔鲜果从农户交付到企业采购结算、反向开票的真实业务闭环。收购点和加工厂都作为企业客户，订单最终归属当前企业。
业务定位
这不是单纯的称重或收款工具：每笔交易都要把自然人农户、企业主体、订单证据、付款结果和发票结果关联起来。
农户种植与交货自然人供应方
企业收购或接收收购点 / 加工厂
称重与验收商品、重量、证据
创建采购订单现场或远程建单
农户确认核对交易事实
企业付款全额结算
反向开票支付后异步处理
售后与对账退款、红冲、核对
企业
收购点或加工厂均按企业客户管理，负责采购、付款和实际反向开票。
悠然居
SaaS 平台运营方，负责多企业数据隔离和支付宝第三方应用接入。
支付宝
提供企业授权、供应商关系、订单、付款、状态和反向开票等外部能力。
业务特点
- 交易对象分散，农户通常是自然人。
- 订单既可能现场创建，也可能由企业远程建单。
- 需要记录重量、商品、磅单及车辆/司机等交易证据。
- 付款和开票不是同一个状态，必须分别跟踪。
V1 业务边界
- 只处理企业向自然人采购槟榔鲜果，一单对应一个自然人并整单付款。
- 订单只归属当前企业，不选择收购点；远程影像不要求农户与产品合照。
- 暂不展开加工工艺、物流、行情价、企业间销售和多渠道开票。
槟榔鲜果采购结算与农户反向开票
这是一个面向多家企业的交易、结算和票据 SaaS 平台。V1 只聚焦企业向农户采购槟榔鲜果，把主体资料、订单证据、企业付款、反向开票、售后和对账关联成一条可追溯链路。
01 / 核心认知
四条核心原则
模块边界和异常处理遵循以下四条原则。
企业是业务责任主体
企业是采购方、付款责任方和实际反向开票主体。平台方悠然居负责 SaaS 运营和支付宝第三方应用接入。
一单只对应一个自然人
业务上称“农户”，系统主体类型是自然人。自然人可以关联多家企业，但每家企业的资料和交易关系独立。
三个状态必须分开
订单状态、支付状态、开票状态分别存储和推进。付款前审核、外部订单创建、退款和红冲也不能塞进订单状态。
外部结果才是最终事实
支付宝回调、主动查询或对账结果决定支付和开票是否成功，前端不能把处理中或失败手工改成成功。
02 / 产品范围
V1 做什么，不做什么
V1 聚焦采购、结算与反向开票闭环，长期能力按版本路线逐步扩展。
V1 纳入范围
- 产品：仅槟榔鲜果；收购点和加工厂都作为企业客户。
- 交易：企业向自然人采购，一单一自然人，只支持整单付款。
- 证据：面对面建单必须有农户与产品合照、磅单照片；远程建单不要求农户与产品合照，照片按需上传且限于磅单、商品、车辆/司机相关内容。
- 票据：支付成功后反向开票，开票成功后订单才完成。
- 售后：整单退款、整单红冲，默认需要企业审批。
- 平台：多企业数据隔离、企业准入、跨企业管理、企业工作台和报表。
V1 明确不做
- 正向开票、企业向企业销售订单和企业供应商交易。
- 部分付款、分期付款、拆单退款、部分红冲、差额补单。
- 平台资金池、代收代付、资金托管和平台服务费结算。
- 称重设备直连、复杂弱网离线作业和复杂加工生产管理。
- 支付宝以外渠道的实际反向开票交易。
- 业务小程序企业切换、移动数据看板和完整基础配置。
V1.0 · 当前
采购结算与反向开票
三端闭环、支付宝交易、退款红冲、报表和后台协助。
V2.0
企业间销售协同
只做信息流，不引入资金流和票据流。
V3.0
多渠道反向开票
支付宝、微信、乐企等渠道适配和路由。
V4.0
工厂加工数字化
加工过程、协同数据和智能工艺优化。
03 / 端与数据范围
三端协作，但责任不重叠
同一套核心对象由不同入口操作。后台管理端跨企业，企业端只看当前企业，小程序只加载唯一企业上下文。
后台管理端
全部企业或绑定企业范围
企业数据范围 enterprise_id
供应商、订单、资金、发票、附件、报表都归属一家企业
自然人主体
可关联多家企业，但关系资料和交易数据不跨企业共享
04 / 系统架构
一个 SaaS 平台，多企业，一套统一业务 API
V1 虽然只启用支付宝，但业务模型要保留渠道标识、外部流水和状态适配边界。
应用端用户可见入口
后台管理端 Web企业端 Web统一支付宝业务小程序农户页面 / 支付宝官方页面
应用接入与业务 API统一认证和业务约束
登录与企业上下文权限与数据范围业务校验幂等与防重复提交
核心业务服务层核心领域对象
企业准入农户供应商商品计量采购订单资金支付反向开票退款红冲对账报表
平台支撑与自动化层跨模块公共能力
数据隔离RBAC审批配置OSS 文件异步任务回调处理短信操作日志
外部接口适配层外部能力不能直接扩散到业务层
支付宝OCR短信服务外部 OSS后续微信 / 乐企
数据与文件层业务数据与证据链
业务数据指标数据文件元数据外部流水操作日志外部 OSS 文件内容
05 / 主流程
一笔采购业务如何走完闭环
各节点包含参与端、业务产出和主要阻断条件。
06 / 重点流程一
创建采购订单：先形成可信业务事实
订单不是“填完表单就成功”，提交前必须完成主体、商品、计量、金额、资料和权限校验。
07 / 重点流程二
付款流程：审核、余额、入口和结果分开
农户确认订单不等于支付成功。付款前审核是独立审批，支付结果只能由支付宝可信结果确认。
01
订单已确认
农户完成订单确认，订单状态进入已确认。
02
付款前审核
企业默认需要审核；无需审核也要记录配置结果。
03
余额与账户
付款前查询企业支付宝账户，余额不足阻断。
04
外部状态
外部订单状态可付款，才能推进付款入口。
05
全额付款
一次全额付款；处理中不得重复发起。
需要付款前审核
企业内部审核通过后，再调用支付宝外部订单审核接口；内部审批和支付宝审核是两个概念。
按支付宝返回结果承载入口
业务小程序展示二维码、营业员页面或农户官方收款页面，不自行拼接支付链路。
回调 / 查询 / 对账确认
支付状态进入成功或失败；结果不明确时保持处理中并继续查询，不能人工改成功。
付款尝试和付款入口版本必须区分
二维码只是某一次付款尝试下的入口版本。入口过期且尚未开始付款，可以在原尝试下换码；支付明确失败，才创建新的付款尝试；已扫码、支付已开始或结果不明确时，必须先查询，禁止换码或重复扣款。
08 / 重点流程三
开票流程：支付成功后异步推进
支付和开票是两条状态线。支付成功只触发开票，不能直接把订单置为完成。
支付成功
保存支付金额、时间、外部流水号和结果来源。
待开票
允许触发反向开票，订单仍是已确认。
开票中
通过回调、主动查询或对账等待最终结果。
已开票
保存票号、外部发票标识、文件和备注快照。
订单已完成
仅当支付成功且开票成功时进入。
开票失败怎么处理订单仍为“已确认”，支付仍为“支付成功”，开票状态为“开票失败”；使用原订单关系和幂等键重试，不能重复开票。
发票备注从哪里来由后台维护的模板填充购方、农户、银行信息、生产地址、支付渠道和交易单号，并按支付宝长度规则校验。
09 / 重点流程四
退款、红冲与对账：售后不回写订单主状态
售后动作有自己的记录、审批和外部状态。已完成订单仍保持完成，售后结果在独立台账展示。
已开票订单：先红冲，再退款
退款/红冲申请
记录申请人、原因、金额和原票。
红冲审批与执行
红冲处理中或失败不能直接退款。
退款执行
按正式接口结果更新退款记录。
约束：V1 只支持整单红冲和整单退款，默认开启审批；红冲、退款失败不能手工标记成功。
对账：把本地记录与外部流水对齐
订单
企业、农户、商品、重量和金额。
支付/发票
外部流水、票号和状态结果。
差异处理
认领、补录、查询和人工关闭。
产出：采购、资金、票款和综合对账，支持从差异回钻到订单、付款尝试、发票或售后记录。
10 / 状态契约
订单、支付、开票三条状态线
状态是跨端公共契约。页面可以按不同端展示，但服务端状态推进规则必须统一。
订单状态
采购生命周期草稿
→待确认
→已确认
→已完成
草稿可编辑；农户确认后进入已确认；只有支付成功且开票成功才能完成。付款前审核不新增订单状态。
支付状态
资金结果待支付
→支付中
→支付成功
支付中
→支付失败
↻重新付款
支付中或结果不明确时禁止重复付款；失败重试保留原尝试，成功只能由外部可信结果确认。
开票状态
票据结果待开票
→开票中
→已开票
开票中
→开票失败
↻重新开票
只能在支付成功后发起；开票失败不回退支付，也不提前完成订单。
完成条件
订单已完成 = 支付成功 + 开票成功 + 外部订单状态已可信核验且允许完成。任何一个条件未知或处理中，都不能提前完成。
取消条件
草稿、待确认、已确认且未发生成功付款时可按规则取消；支付中必须先查询，不能直接取消或把结果当作未支付。
11 / 外部能力
支付宝接口：名称、职责与边界
V1 使用支付宝完成企业能力查询、供应商关系、订单、支付、开票与红冲；关键字段和研发边界如下。
| 接口/能力 | 作用 | 关键字段或结果 | 研发边界 |
|---|
统一原则：服务端负责鉴权、验签、幂等、原始响应留存、状态映射和重试记录；前端只展示服务端状态，不直接接触密钥，也不依据一次请求返回就判定业务成功。
12 / 公共技术契约
所有业务模块都必须遵守的底层规则
这些不是某一个页面的功能，而是订单、资金、票据和跨端协作能稳定运行的前提。
企业数据隔离
业务表、API、异步任务、消息、文件、统计和导出都要带企业上下文；服务端校验 enterprise_id，不能只依赖前端隐藏菜单。
RBAC+数据范围（ABAC）
菜单权限只控制可见性，接口还要校验功能权限、企业绑定和数据范围；停用用户、角色或企业后立即失效。
快照与版本
订单保存供应商、商品、计量、金额和票面资料快照；主数据后续修改不能改变历史订单事实。
文件与敏感资料
图片、证照、磅单和发票文件内容放外部 OSS，本系统保存元数据；身份证、银行卡、手机号和照片需脱敏、加密和审计。
异步与最终一致
OCR、外部订单创建、开票、回调查询、对账和导出使用任务记录；处理中、失败和结果不明确都要有下一步处理路径。
计量与金额
重量按克保存，页面可显示斤和千克；1 斤 = 500 克。单价和金额保留 2 位小数，最终金额用于付款、开票和统计。
13 / 研发落地
研发拆解建议与验收重点
公共契约和企业准入是主链路的前置基础，订单、付款开票、售后对账依次组成 V1 闭环。
01
公共基础
认证、企业上下文、RBAC、数据隔离、字典、文件和日志。
02
企业准入
企业资料、OCR、人工确认、支付宝授权和反向开票能力。
03
主体与商品
自然人关联、实名、生产资料、商品同步、等级和计量。
04
采购订单
现场/远程建单、校验、快照、外部订单创建和农户确认。
05
付款开票
付款前审核、余额、付款入口、支付回调、开票和重试。
06
售后对账
退款、红冲、票款关联、差异处理、台账和报表。
07
平台协助
跨企业查询、异常处理、批量任务、受控导出和发布。
首轮联调/验收必须覆盖
企业 A 无法访问企业 B 的用户、供应商、订单、文件、资金和报表。
订单创建重复提交、外部请求超时、回调重复都不会生成重复订单或重复付款。
农户拒绝、二维码过期、余额不足、支付处理中、支付失败和开票失败均有明确下一步。
支付成功但开票失败时，订单不完成；开票重试不重复开票。
已开票订单先红冲成功再退款；售后记录不改写订单三类主状态。
联调确认项
支付宝目标企业是否具备审核后由系统直接完成付款的能力，还是必须回到官方农户页面。
反向订单、退款、红冲、发票交付的正式接口权限、状态枚举和有效期。
票种、税率、备注长度、农户发票查看承载形态和正式留存期限。
OCR、短信、OSS 的供应商、鉴权方式、文件大小和失败重试策略。
复杂弱网、称重设备、远程收款有效期等后续能力的正式版本安排。