taiyi/dingdanquanliucheng
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2301b18411
dingdanquanliucheng/未完成功能清单.md

17 KiB
Raw Blame History

未完成功能清单

说明：本清单基于《确定版需求说明书.md》《开发细节/》系列文档，并结合当前系统代码扫描结果，从“需求应有能力”与“现有代码实现”两侧做差集整理。这里把“未完成”定义为：需求已明确、文档已细化，但当前代码中缺少实现、只做了占位、只实现了部分链路、或实现与需求存在明显偏差的功能。

1. 结论摘要

当前系统已经覆盖了订单、客户、产品、工厂、司机任务、提醒、报表、配置、审计、系统用户与角色菜单等主干模块，但仍有不少关键能力处于“半成品”或“缺失”状态。

最核心的未完成项集中在以下几类：

  1. 订单流程未闭环：提交、审批、取消、确认下发工厂、司机履约之间的状态和数据联动还不完整。
  2. 权限与字段隔离不完整：部分端/角色的字段可见性、数据范围、按钮权限仍有缺口。
  3. 系统管理不完整：菜单、角色、用户、授权虽已存在，但分页、筛选、CRUD 完整性仍不足。
  4. 物流、AI、提醒、报表等高级能力大多为“有接口壳、缺实际业务联动”。
  5. 数据库级、审计级、配置级要求尚未完全落实到代码行为中。

2. 按需求域整理的未完成功能

2.1 登录鉴权与权限体系

未完成项

  • 角色登录态与菜单/按钮权限的完整联动不足

    • 需求要求登录后返回 menus、permissions，并由前端动态控制页面入口和按钮权限。
    • 当前代码里有登录和权限校验，但从端到端看，权限菜单树、按钮权限、角色授权后的即时生效链路仍不够完整。

  • 权限体系存在“接口有了，细粒度控制未完全落地”的问题

    • 例如订单详情、列表、司机任务详情等接口在需求中要求按角色隐藏不同字段，但目前更多是业务员端做了简单过滤，其他端的字段隔离与页面级按钮联动还不充分。

  • 管理员/管理层/业务员/司机的角色能力边界尚未完全收敛

    • 需求里每个角色的可见范围、可操作范围定义较明确，但当前实现中仍可能存在接口共享、前端页面复用过宽的情况。

2.2 系统用户、角色、菜单管理

未完成项

  • 用户管理的分页、筛选与完整 CRUD 仍不完整

    • 目前代码中已有用户列表、新增、更新、重置密码，但列表分页是由外层切片实现，接口层未形成完整分页查询能力。
    • 删除、停用/启用切换等操作在需求中被提到，但代码层未形成完整闭环。

  • 角色管理缺少完整生命周期操作

    • 目前可新增、更新、授权菜单，但缺少更完整的角色停用/启用流程与异常约束的全量实现。

  • 菜单管理未完全覆盖需求字段

    • 需求细化中提到 icon、sort_no、status、多级菜单等能力；现有实现虽有菜单树，但仍偏基础。

  • 角色授权后的“权限码 + 菜单树”同步返回与前端刷新机制不完整

    • 需求要求授权后登录刷新生效，但代码层没有看到完整的权限缓存刷新、会话失效或即时同步机制。

2.3 客户管理

未完成项

  • 客户导入能力未见完整代码闭环

    • 需求要求支持导入模板、去重、重复提示、失败行返回等。
    • 当前代码里客户创建、列表、详情有实现，但导入链路在代码中没有看到完整接口/服务实现。

  • 客户去重规则未完全按“姓名 + 手机号”强约束落地

    • 需求明确要求以“姓名 + 手机号”做重复校验，并用于新客户自动同步。
    • 代码在订单创建时会查找客户，但是否在所有客户新增/导入路径统一强校验，还不完整。

  • 月结信息、欠款信息的维护和展示不完整

    • 客户资料中要求有结算方式、账期起算口径、欠款金额等字段。
    • 现有实现中可见基础字段，但围绕欠款、结算模式、账期配置的管理页面与联动还不完整。

2.4 产品与产品分类管理

未完成项

  • 产品分类独立管理虽已出现接口痕迹，但整体功能仍不完整

    • 需求明确要有独立 product_category 及其维护页面。
    • 目前代码虽出现产品分类相关 API，但前端页面、联动选择、停用约束、导入/展示等未形成完整闭环。

  • 产品状态对订单下单的约束不足

    • 需求测试中要求禁用产品不可下单。
    • 当前代码中未见订单创建时对产品启用状态、分类状态的完整校验链路。

  • 产品快照机制未完全前置到所有场景

    • 需求要求订单明细保存名称、规格、单位快照，历史订单不随产品变化。
    • 当前订单明细读取已有快照字段，但产品维护、价格变更、分类变更后的历史一致性校验仍不完整。

2.5 工厂/供应商管理与下发文本

未完成项

  • 工厂下发文本的“生成 + 确认 + 留痕”链路未完全闭环

    • 需求要求审批通过后生成可复制文本，且需要确认下发、记录文本日志。
    • 当前 get_supplier_text / confirm_supplier_text 已有基础实现，但：
      • 下发文本历史记录表的实际持久化链路不完整；
      • 按不同工厂模板生成内容的规则还偏简单；
      • “复制文本体验”前端未完全落实。

  • 工厂模板类型的业务差异未完全实现

    • 需求强调不同工厂可有不同模板，但本期以文本复制为主。
    • 当前实现多为统一模板拼接，模板可配置性不足。

2.6 销售订单录入、提交、审批

未完成项

  • 订单创建接口与需求字段存在明显缺口

    • 需求要求订单录入包括客户、物流、回扣、费用、订单明细等完整结构。
    • 当前创建接口虽然支持核心字段，但很多需求中的派生字段、校验细节、权限字段和审核前信息展示仍不完整。

  • 订单编辑/草稿保存的完整能力未完全实现

    • 需求中明确有“保存草稿”“编辑草稿”“保存并提交”等页面操作。
    • 代码目前主要看到创建、提交、取消、审批，缺少完整的更新/编辑接口和前端联动。

  • 订单提交审核的完整校验不充分

    • 需求要求提交时检查明细完整性、客户匹配、新客户入库、状态流转、通知等。
    • 当前已实现基础提交，但订单完整性校验和通知联动不全面。

  • 审批页所需的利润计算过程展示未完全落地

    • 需求要求管理层审批时看到利润、利润率以及计算过程。
    • 当前接口能返回结果值，但“计算过程明细”和页面级展示还未完整实现。

  • 审批退回后的业务员通知未完整落地

    • 需求明确要求退回后通知业务员。
    • 代码中有审计写入，但通知中心/消息推送联动不完整。

  • 订单取消的特殊审批逻辑未完全实现

    • 需求要求：草稿、待审核直接取消；已通过后需何总确认；履约阶段走特殊审批。
    • 当前实现中有 cancel_pending，但特殊审批规则、履约中分支和状态恢复链路还不够完整。

  • 取消原因/意见/前状态的审计留痕不够完整

    • 数据库设计要求保存取消前状态、申请人、申请时间等。
    • 代码有部分字段更新，但与取消审批、恢复状态、日志完整链路仍未完全闭环。

  • 订单状态机仍是“部分可改状态”，不是完整流程驱动

    • 需求中状态流转非常明确。
    • 当前代码允许通过一个通用状态变更接口改到多个状态，但缺少严密的状态机约束与自动联动。

  • 订单通知规则未完整实现

    • 需求要求订单状态变化时相关角色收到通知。
    • 目前只有订单事件写审计，未见完整消息通知写入、推送或站内信列表。

2.7 司机任务管理与履约

未完成项

  • 司机任务的创建、分配与订单状态联动不完整

    • 需求要求管理层或后台创建任务，订单审批后进入司机接单环节。
    • 目前虽有物流任务相关模块，但任务创建的完整接口、分配策略与状态联动还不充分。

  • 司机任务列表/详情的可见性控制未完全细化

    • 需求要求司机仅能看取货地址、取件内容、数量、工厂、部分业务员信息。
    • 当前已有脱敏思路，但司机端显示字段、接口过滤与页面控制并未完全统一。

  • 司机接单、揽货、送达的业务约束不完整

    • 需求要求：
      • 接单后才能揽货；
      • 揽货需图片上传；
      • 提交前可撤回，提交后不可撤回；
      • 送达后更新任务和订单状态。
    • 当前代码可能存在基本状态流转，但“提交前可撤回、提交后不可撤回”与图片必填约束还未完整闭环。

  • COS/OSS 图片存储与附件管理未完全统一

    • 需求对图片上传、附件元数据、存储路径、类型有明确约束。
    • 当前文件服务存在，但司机揽货上传、附件表、对象存储元信息的统一落实仍不足。

  • 微信订阅消息通知未实现

    • 需求明确提到通过微信订阅消息通知相关人员。
    • 当前没有看到实际推送实现。

2.8 物流与 AI 辅助识别

未完成项

  • 物流轨迹对接快递100的完整实现未落地

    • 需求要求物流信息对接快递100接口。
    • 当前代码更像是手动维护/查询轨迹的雏形，第三方对接、失败重试、节点同步尚未完整。

  • 物流超时提醒的“一次性提醒”策略未完全实现

    • 需求要求首个物流节点超过 2 天无流转仅提醒一次。
    • 目前提醒模块存在，但是否按“首节点 + 仅一次 + 去重”规则执行，还需补齐。

  • AI 图片识别链路不完整

    • 需求要求：AI 仅做辅助识别，保留原始结果与人工修正结果。
    • 当前已有 AI 接口和记录思路，但：
      • OCR/识别结果人工确认界面未完全实现；
      • 相似订单人工判断流程未完全实现；
      • 原始结果与修正结果的可追踪展示不够完整。

  • 识别失败、置信度过低、结果冲突的人工兜底流程未闭环

    • 需求强调最终由人工确认。
    • 目前更多是接口层记录，缺少业务流程层兜底。

2.9 提醒中心、欠款提醒、长时间未下单提醒

未完成项

  • 提醒中心页面与接口联动不完整

    • 需求中提醒中心应支持列表、查看、标记已读、筛选等。
    • 目前虽有提醒接口，但页面展示和状态流转未见完整实现。

  • 欠款提醒的起算规则未完全落地

    • 需求允许按订单日期、对账日期、发货日期配置起算口径。
    • 现有代码中欠款同步逻辑存在，但不同口径切换与账期计算未完整实现。

  • 欠款提醒“提醒对象为业务员”的规则未完全验证

    • 需要确保提醒分发给对应业务员，而不是泛化通知。
    • 当前缺少完整的接收人策略展示。

  • 长时间未下单提醒的金额阈值和沉默周期配置未完全形成业务闭环

    • 需求要求低于金额阈值的小客户不纳入提醒。
    • 代码中配置接口和提醒接口有，但定时检查、筛选逻辑、重复提醒控制未完全看到。

2.10 业绩统计报表

未完成项

  • 报表口径统一还未完全消除差异

    • 需求要求按月/季/年、工业品/日用品拆分统计，剔除电商订单，支持提成核对。
    • 代码中已有报表接口，但分类映射、来源标签剔除、提成核对字段的完整统计口径仍需联调。

  • 报表导出能力可能仍是简化版本

    • 需求要求支持导出文件，并与页面一致。
    • 目前可见报表接口和导出路径，但异步导出、文件持久化、权限控制和大数据量性能处理不足。

  • 报表图表与明细维度未完全实现

    • 页面原型要求柱状图、折线图、表格等。
    • 代码中更多是数据接口层，前端图表表现仍需补齐。

2.11 配置管理

未完成项

  • 系统配置项仅覆盖基础字段，未形成统一配置中心体验

    • 需求要求支持物流超时、沉默客户周期、欠款起算、金额阈值、报表分类映射等。
    • 代码中有配置服务，但配置项的初始化、展示、编辑、即时生效和审计闭环未完全统一。

  • 敏感配置的安全存储未完全体现

    • 例如 OSS、AI 凭证不应进入明文配置。
    • 当前代码层尚未完整体现环境变量/密钥管理策略。

2.12 审计日志

未完成项

  • 审计日志写入覆盖面仍不够全面

    • 需求要求所有新增、修改、删除、提交、审批、取消、接单、揽货、送达等关键操作都写日志。
    • 目前订单、系统用户、角色、菜单等有部分写入，但物流任务、提醒、导入、导出、AI 修正等关键动作未完全覆盖。

  • 审计日志查询和前后值展示未完整落地

    • 需求要求能查看前后值差异。
    • 现有代码更偏基础查询，前后值 diff 展示与页面化浏览未完整实现。

2.13 前端各端页面

未完成项

  • WEB 业务员端仍有较多页面是“能用但不完整”

    • 订单列表、录单、详情、提醒页有基础结构，但按钮状态、字段脱敏、草稿编辑、审批后文本复制等体验未完全落地。

  • WEB 管理后台的业务面板未完全覆盖需求页面

    • 用户、角色、菜单、客户、产品、工厂、订单、任务、提醒、报表、配置、审计等页面需要统一入口和联动。
    • 当前页面结构存在，但细节操作、分页筛选、批量导入、导出、权限控制仍有缺口。

  • 微信小程序管理层端存在若干页面仅实现骨架

    • 审批列表、审批详情、取消审批、下发文本、任务创建、经营数据等页面基本存在，但与真实接口和业务规则的深度联动不足。

  • 微信小程序司机端页面需要补齐“任务状态驱动 UI”

    • 任务列表、任务详情、接单、揽货、送达、附件上传等页面的状态控制还不够严谨。

3. 按“第一性原理”归纳的本质缺口

从第一性原理看，当前系统真正未完成的，不是“某几个按钮没做”，而是以下 6 个基础闭环还没完全建立：

3.1 数据闭环未闭合

  • 订单创建后，客户、产品、工厂、任务、附件、审计、提醒、报表之间的关联没有完全形成单一事实来源。
  • 许多模块是“各自能查”，但还没有做到“一个事件触发全链路更新”。

3.2 状态机未完全收敛

  • 订单状态、任务状态、提醒状态、欠款状态、审批状态之间存在多个可变点。
  • 目前更像“允许改状态”，而不是“严格按状态机推进”。

3.3 权限隔离未完全落地

  • 需求要求不同角色看到不同字段、不同按钮、不同菜单、不同数据范围。
  • 现在已有角色判断，但字段级、按钮级、行级的权限隔离还不彻底。

3.4 配置驱动未完全实现

  • 需求中大量规则本应由配置驱动，例如提醒周期、欠款起算、报表分类、模板类型。
  • 当前仍有不少规则写死或半写死。

3.5 外部能力未完全接通

  • 快递100、AI OCR、OSS、微信订阅消息等外部能力多数停留在接口壳或简化实现。
  • 真实生产可用需要：鉴权、失败重试、幂等、日志、降级、人工兜底。

3.6 体验层未完全收口

  • 页面原型要求的可见字段、按钮时机、复制体验、导出体验、空态/错误态、权限态，还没有完全体现在前端。

4. 建议优先级

P0：必须优先补齐

  1. 订单编辑/草稿保存
  2. 订单取消特殊审批闭环
  3. 订单下发工厂文本日志化与确认闭环
  4. 司机任务创建、接单、揽货、送达状态联动
  5. 物流轨迹与超时提醒一次性去重
  6. 欠款生成口径与提醒对象规则
  7. 字段级权限与角色数据隔离

P1：尽快补齐

  1. 客户导入与去重
  2. 产品分类完整 CRUD
  3. 审批退回通知
  4. AI 识别结果人工修正页面
  5. 报表口径统一与导出
  6. 配置中心完整化

P2：体验与增强

  1. 工厂文本复制体验优化
  2. 审计日志前后值展示
  3. 通知中心/消息中心
  4. 页面空态、加载态、错误态统一
  5. 报表图表化展示

5. 结语

如果把当前系统理解成一条业务流水线，那么现在已经有了“入口、若干节点、若干出口”，但真正还没完全完成的是“状态驱动的完整闭环”。建议后续优先围绕订单状态机、任务状态机、提醒状态机、权限隔离、配置驱动这五条主线补齐。