门店DMS · 本阶段开发与上线准备总览

01概览

本系统为电动车门店端 DMS（经销商管理系统），覆盖工单流转、配件进销存、采购、顾客与车辆档案、结算、消息联动、打印留档等门店核心业务。以不依赖外部系统、保持轻量的 mock 数据呈现完整业务闭环。当前阶段「《系统流转框架示意图_详细版.html》所列门店端可用 mock 展示的功能缺口」已全部交付。

阶段结论

功能缺口清零 · 黄金主链实跑通过 · 可进入试运营

本轮把流程中缺失的 A–G 功能全部补齐，并把真实门店工作流的顾虑（纸质留档、角色权限、打印件）对应解决；上线前实跑验证了主链与数据一致性。接真实后端时的权限下沉是唯一要提前布防的点。

功能缺口 A–G 全部交付

打印单证体系（5 类）

上线硬阻断问题

留档「手动需复核」项

02功能缺口补齐 A–G

按「门店端前端可用 mock 展示」清单逐项补齐，全程复用 mock 数据、保证数据联动与消息通知闭环。

编号	功能	实现要点	状态
A	增项确认	技师提交增项→店长/前台确认/驳回→确认后扣库存并生成出库流水，联动消息通知，避免技师私自加价。	PASS
B	评价回访	工单完成后提交回访评价（满意度 / 结果 / 反馈），自动推送回访消息，形成售后闭环。	PASS
C	库存预警一键补货	库存低于预警值的配件一键生成待提交采购单草稿，缩短补货路径。	PASS
D	返厂 / 报废	配件出库类型扩展为「返厂」「报废」，生成对应库存流水，账实一致。	PASS
E	配件爆炸图	PartDetail 用 SVG 渲染分层分解图 + 序号圆点，直观定位配件位置。	PASS
F	委托书 / 质保卡打印	打印服务卡片新增两种文档类型，通过 window.print() 输出，满足纸质留档。	PASS
G	车辆报废注销	车辆新增「已报废」状态，支持状态流转与消息通知。	PASS

已通读《系统流转框架示意图_详细版.html》口径确认：门店端 A–G 已全部交付并通过浏览器端到端复核，当前范围内功能缺口为零。厂商平台、B2B 商城、支付/打印对接、C 端接口联调等「后期规划」项因属于对外部系统的对接，暂不纳入本次范围。

03顺带修复的小问题

小问题	处理方式
技师权限边界	明确不同角色操作边界：店长全量、前台可接单/取消/确认取车（不可维修领料）、技师仅能维修+领料/退料。前端按角色控制入口。
纸质留档	补齐打印体系（派工单/委托书/质保卡/结算单/出门单），匹配 4S 店纸质工单的现实习惯。
库存扣减时机	领料在「确认领用」后才扣库存并生成出库流水，避免草稿计入。
增项确认等待	技师增项走店长/前台确认链路，避免未审先扣。
消息刷屏	同门店同配件同类型未读预警做去重，减少无效打扰。
技师追加项目独立通道	OrderProject（追加，技师维修中直接加，计入结算）与 OrderAddition（增项，需确认）分离，金额并入结算单并在结算信息展示。
退料回充	POST /orders/:id/parts/:partId/return：仅维修中 + 负责技师/店长可退，扣减领用记录并向库存回充、生成「返料」入库存流水。
派工单打印补缺	openPrint 类型补充 dispatch，加入既有打印预览体系。

04打印单证体系

现实门店（尤其汽车 4S）习惯前台打印纸质工单降低争议、便于归档；本系统已统一接入同一打印预览对话框的五类单证：

派工单 —— 派工留痕，明确责任技师。
维修委托书 —— 客户授权维修的依据。
质保卡 —— 售后质保凭证。
结算单 —— 配件费 + 项目费 + 工时费 + 合计与支付方式。
出门单 —— 取车放行凭证。

打印为「随点随打」的简单方案（window.print()），满足当前留档诉求；正式上线可再对接条码/小票打印机。

05B2B 商城选型 · Bagisto

「后期规划」中的 B2B 商城为外部系统对接项。经评估，优先推荐 Bagisto 作为可落地的开源基座。

维度	说明
定位	基于 PHP/Laravel 的电商平台，原生内置 B2B 套件（企业客户、价格分级、采购单等）。
技术栈	后端 Laravel，前端 Vue.js——与本项目 PHP + Vue 技术路线同源，利于二次开发。
授权	MIT 开源许可，可免费商用，无授权费。
已有能力	商品/SKU、库存、订单、客户、价格层级、支付与主题商店等开箱即用，B2B 场景无需从零自研。
与 DMS 的关系	作为独立电商入口对接门店，通过 API 共享商品与客户数据，避免把商城逻辑塞进门店 DMS。
落地建议	先以 DMS 为主，商城作为后期扩展；接 Bagisto 前应先确认版本与 Laravel 运行环境，评估商品/客户数据对接粒度。

提醒：Bagisto 适合「自建并二次开发」的场景。若追求「零维护、快速上线」，可同时对比 SaaS 型 B2B 商城（如 ShopSphere / 本地化 SaaS），按是否需要源码掌控权衡。

06门店 App 方案

现有门店系统是 Web 后台，店员得守着电脑登录网页接单。门店 App 的意义是把高频操作搬到手机上，不必总守在工位/前台刷屏。

技师

在工位直接接单 / 完成维修 / 领配件，减少往返前台。

前台

拿手机接单确认 / 结算 / 取车，不占用台式机、客户等待时可移动处理。

店长

随时看今日完工与工单看板，不必守着电脑盯进度。

范围界定

App 不做低频重功能（如复杂报表、大屏看板），只承载移动化高频操作，与 Web 后台互补。

落地建议：先强化现有 Web 的响应式页面，用手机浏览器验证高频操作体验；确有打包原生/PWA 需求再独立 App，避免初期重复建设。

07真实工作流复核

担心「设计流程 ≠ 门店真实流转」（如纸质工单、角色分工、打印留档），因此引入专业角色复核机制，而不只靠开发自测。

复核方法	说明
角色复核表	建立「真实门店工作流基准 vs 现有系统」对照表，由店长 / 技师 / 前台三个角色按各自视角逐条核对。
外部参考	参考公开的 4S 店 / 电动车门店工作流分析资料，校准纸质工单、接单派工、检修、结算、取车等环节的真实顺序与留档习惯。
前置验证	把「纸质工单、打印留档、技师权限、增项确认」等真实门店关切点，在开发阶段就作为小问题解决，避免上线后再返工。

栏杆线：任何角色复核发现的「流程断点」必须先补上操作入口再放行——状态机里定义的每个状态都要有可达入口，防止流程断裂。

工单状态机（当前实现）

flowchart LR
  A(["待接单"]) -->|接单派工| B["维修中"]
  A -->|取消| X(["已取消"])
  B -->|完成维修| C["完工待确认"]
  C -->|驳回| B
  C -->|确认完工| D["待取车"]
  D -->|结算 + 确认取车| E(["已完成"])

工单状态机 · 待接单 → 维修中 → 完工待确认 → 待取车 → 已完成（含取消、驳回分支）

08上线前测试

以「不漏大问题、不可能完美但上线不出事故」为目标，按 4 层递减设计并实际执行。

测试分层

层级	内容	本轮结果
P0 黄金主链	建单→派工→领料→追加→完工→确认→结算→取车→回访	已实跑全通 ✔
P1 权限边界	店长/前台/技师各自可见与可操作范围	已核(前端) + 待角色实走
P2 数据一致 + 状态机	非法流转拦截、重复结算阻断、领/退料与库存流水、门店隔离	已核(后端) ✔
P3 消息联动 + 异常	结算/完工/回访消息、输入校验	部分核验 + 建议补充

黄金主链实跑结果（真实浏览器）

步骤	结果	实际情况
01 登录选店	PASS	admin 登录，进入淮安万达旗舰店
02 新建工单	PASS	WO20260821018，关联车辆档案，品牌/型号/车牌自动带出
03 接单派工	PASS	选技师王师傅，待接单→维修中
04 领用配件	PASS	领用铅酸电池×1(¥580)，库存扣减 + 出库流水
05 追加项目	PASS	整车深度清洁 ¥50，计入结算
06 完成维修	PASS	填检测结果，→完工待确认
07 确认完工	PASS	店长确认，→待取车
08 结算	PASS	自动汇总 ¥640（580+50），生成结算单，重复结算被拦截
09 确认取车	PASS	待取车→已完成
10 回访评价	PARTIAL	回访弹窗正常、反馈可填；「回访结果」未选时提交被拦——表单校验，非 bug

数据一致性与权限 · 后端卡控核验

防护项	是否落实	后端强制点
非法状态流转	PASS	状态机白名单，非法流转报「当前状态不允许变更为…」
仅待取车可结算	PASS	非待取车拦截
不可重复结算	PASS	已有 settlement 拦截「已结算，请勿重复结算」
领/退料与库存流水	PASS	领料限维修中；退料回充库存并生成返料入库流水
门店隔离	PASS	请求拦截器自动注入 storeId，查询按门店过滤
技师角色边界	前端约束	前端按角色控入口；后端 mock 未做角色校验——见「接后端」建议

模块就绪度

系统核心模块就绪度（高可用 mock 演示 = 1.0）

上线判定与建议

阻断项

本轮实跑 0 项硬阻断

未发现会导致崩坏、数据错乱或流程断路的硬性 bug；三项「手动需复核」均为 Element Plus 下拉浮层/打印/取消路径的人工点选，属自动化难点而非缺陷。

手动复核走一遍：下拉选人、打印预览、待接单→取消路径。
角色实走：换 wang(技师) 确认看不到添加工单/结算按钮；换 front(前台) 确认能接单/取车/取消但点不了维修领料。
接真实后端时把角色卡控下沉到服务端（当前权限在前端，直接调接口可绕过）——这是唯一要防的线上隐患。
跨店隔离：admin2(南京)登录应看不到淮安门店工单与配件。
异常值冒烟：空校验、手机号非法、负金额等各补一次提示是否友好。

09结论与后续路线

本阶段结论

门店端可用 mock 展示的功能缺口 A–G 已经清零；黄金主链端到端实跑通过，数据一致性与权限卡控到位，可以进入试运营。唯一前置条件是：接真实后端时把角色鉴权下沉到服务端。

后续路线

可继续推进（体验层）仪表盘视觉增强、收款对账深化、取车核销码等中低优先级优化。
后期规划（外部对接）厂商平台、独立门店 App、B2B 商城（可选 Bagisto）、支付/打印对接、C 端接口联调。

↑ 返回目录