xst
e34a3c64ce
知识库更新: - historical_defects.md: +4条数据上报领域真实缺陷模式 (阶段依赖链断裂/重试幂等/跨模块数据不一致/省份代码硬编码) - common_missed_scenes.md: +11条数据上报专项易漏场景 (多阶段依赖/第三方核验逐项/重试并发/跨模块一致性/省份隔离等) - data_reporting_cases.md: 新增数据上报类需求优秀用例范式 (8大覆盖框架+5条示例用例+7项关键风险点) - terminology.md: +14条数据上报领域术语 系统修复: - case_pipeline.py: 注册 data_reporting_cases.md + order_manage_cases.md - governance_audit.py: 更新 case_generate/AGENTS 关键词期望(旧→新架构) - AGENTS.md/README.md/.claude: 补全缺失关键词，治理审计通过 - .claude/skills/case_generate/: 创建向后兼容别名 skill
92 lines
6.9 KiB
Markdown
92 lines
6.9 KiB
Markdown
# 业务术语表
|
|
|
|
> 本文件定义了项目中长期稳定、运输场景高频出现的核心业务术语。AI 在生成分析、测试点和测试用例时必须优先使用这些词汇，禁止混用口语化同义词。
|
|
>
|
|
> 使用原则：
|
|
> 1. 先使用本术语表中的标准词。
|
|
> 2. 若需求文档使用了不同但已明确的项目术语，以需求文档为准。
|
|
> 3. 对于行业内存在多种解释的术语，生成结果中应尽量写全称，避免简称歧义。
|
|
> 4. 私域、分销、储值、CRM 等可选领域术语不放在本文件常驻输入中，由流水线按需求内容自动识别后补充加载。
|
|
|
|
## 1. 角色与业务主体
|
|
|
|
- **运八平台端**: 平台总部或托运人使用的管理后台，用于统一管理货源、审核、司机、车辆、货主、打款、数据等能力。
|
|
- **运八司机端**: 司机、车队长使用的移动端，包括 Android/iOS/小程序，用于司机、车队长接单、派单、运输、提现等能力。
|
|
- **运八货主端**: 托运人使用的平台，包括 Android/iOS/PC端等，用于货主发布货源、结算、付款等能力。
|
|
- **货主**: 有运输需求的托运人，可以使用运八平台端、运八货主端进行货源、资金等管理。
|
|
- **车队长**: 可以理解为一个运输企业，本身该角色不能进行实际运输，仅执行接单后，将运输的单子指派给名下的司机。
|
|
- **司机**: 进行实际货物运输，需要上传装卸货的资料以及图片。
|
|
- **运营人员**: 负责审核工作包含司机、车辆、货主等所有角色注册和运输的审核，也可代货主发布货源、结算运单。
|
|
- **客服**: 负责处理订单咨询、异常协查等问题的后台角色。
|
|
- **财务**：负责处理运单实际打款的角色。
|
|
- **滇运通**：负责帮司机代开发票的系统。
|
|
|
|
## 2. 货源
|
|
|
|
- **手动清分**: 该货源下所有运单结算方式名称。
|
|
- **车队长全额收款**: 该货源下所有运单结算方式名称。
|
|
- **自动清分**: 该货源下所有运单结算方式名称。
|
|
- **垫资**: 货源下运单能否进行进行垫资打款的标识。
|
|
- **电子围栏**: 当前货源下所有运单装卸货位置是否进行限制。
|
|
|
|
## 3. 运单
|
|
|
|
- **车队长运单**: 由车队长接单分派给司机的运单。
|
|
- **司机运单**: 由司机自行接单的运单。
|
|
- **垫资运单**：货主、货源都标记为垫资时对应货源下的所有运单。
|
|
- **非垫资运单**：货主、货源下只要有一个没有标记为垫资时对应货源下的所有运单。
|
|
- **运单**: 用户对货源接单后形成的数据，是支付、履约的核心载体。
|
|
- **运单状态**: 运单在生命周期中的阶段标识，如待运输、运输中、已卸货、已结算、已垫付、已打款等。
|
|
- **运单关闭**: 因司机取消运单终止运单继续流转。
|
|
- **逆向流程**: 运单创建后的反向处理链路，如取消、每个节点的审核驳回。
|
|
|
|
## 4. 支付与资金
|
|
|
|
- **调账**: 运单在打款后，用户未提现进行的资金调整。
|
|
- **电子回单**: 运单产生支付记录后银行推送的回单。
|
|
- **支付方式**: 用户完成付款所使用的资金渠道，如光大银行、浦发银行。
|
|
- **货主合计付款**：货主实际需要支付给平台的费用，基础运费+服务费。
|
|
- **合并打款**：货主-平台-司机一次性打款的操作。
|
|
- **货主打款**：货主给平台支付费用。
|
|
- **财务打款**：平台给司机、车队长支付费用。
|
|
- **垫资-财务打款**：垫资运单由平台先行垫付运费给司机。
|
|
- **垫资-货主打款**：垫资运单平台垫付运费后货主偿还费用。
|
|
- **能源费**: 货主配置里的比例金额，对应货主名下所有货源司机接单后自动将部分运费转化为能源费。
|
|
- **居间费**: 手动清分运单车队长收款的金额。
|
|
- **清分司机费用**: 手动清分运单司机收款的金额。
|
|
- **车队长收款**：车队长实收费用，需要根据居间费给车队长多打1%的税费。
|
|
- **资损**: 因金额计算错误、重复打款等问题导致平台或货主资产损失。
|
|
|
|
## 5. 风控、权限与系统能力
|
|
|
|
- **风控拦截**: 系统判定运单存在风险后自动阻断继续执行的行为。
|
|
- **权限控制**: 根据角色、数据范围、组织关系等限制用户可见、可操作范围的机制。
|
|
- **越权**: 用户访问或操作了其本不应拥有权限的数据或功能。
|
|
- **幂等性**: 同一业务请求被重复提交时，系统结果保持一致，且不会重复扣款、重复创建、重复退款或重复扣减资源。
|
|
- **并发**: 多个请求或多个用户在同一时间窗口内对同一资源发起操作的情况。
|
|
- **限流**: 为保护系统稳定性，对请求频率或并发量做出的限制。
|
|
- **降级**: 当依赖异常或系统压力过大时，关闭部分非核心能力以保证核心链路可用的处理策略。
|
|
- **回调**: 外部系统处理完成后主动通知本系统结果的机制，常见于支付、退款、物流等链路。
|
|
- **审计日志**: 用于记录关键操作人、操作时间、操作对象和变更结果的可追溯日志。
|
|
|
|
## 6. 术语使用约束
|
|
|
|
暂无
|
|
|
|
## 7. 数据上报（监管平台对接）
|
|
|
|
- **安徽运八**: 安徽省网络货运信息监测系统，平台需向其分阶段上报运单数据。
|
|
- **三阶段上报**: 装货完成（第一次）→ 打款完成（第二次）→ 开票完成（第三次）的上报链路，前一阶段为后一阶段的前置条件。
|
|
- **上报看板**: 集中展示所有上报阶段运单汇总状态的首页，支持筛选、详情、申诉操作。
|
|
- **核验**: 监管平台对上报数据进行的自动校验，第二次上报含7类核验（运单重复/车辆资质/司机资质/集中支付/资金流水/合同/车辆轨迹合规）。
|
|
- **核验状态**: 上报数据经监管平台核验后的结果，分为通过、异常两种。
|
|
- **异常项**: 核验不通过的具体项目，如"车辆资质核验""资金流水核验"等。
|
|
- **申诉**: 运营人员对核验异常结果向监管平台发起的重新审核请求。
|
|
- **申诉状态流转**: 未申诉 → 申诉中 → 申诉通过 / 申诉驳回 →（驳回后可补充材料）重新申诉。
|
|
- **补传轨迹**: 第二次上报车辆轨迹合规核验异常时的补救功能，补充GPS轨迹数据后重新核验。
|
|
- **上报日志**: 记录所有上报接口调用详情（请求/响应报文、HTTP状态码、响应时间）的审计日志。
|
|
- **省份代码**: 上报数据中标识目标省份的编码，如云南省=28、安徽省=34，需根据目标监管平台动态获取，不可硬编码。
|
|
- **重试策略**: 上报失败后自动重试，最多3次，间隔递增，全部失败后通知运营人员。
|
|
- **ETC发票上传**: 车辆通行高速公路ETC发票作为税务抵扣凭证的上报，税额=发票金额×3%。
|
|
- **收款账号类型**: 区分个人账户（司机银行卡，蓝色标签）和对公账户（企业银行账号，绿色标签）。
|