PCBA 电子制造

本页是一篇完整方案指南:以 pcba-solution(com.auraboot.pcba-solution,pluginType: solution,命名空间 pcba_sol)为编排器的一套 PCBA 电子制造 ERP 为例,从用户场景一路讲到开发实施和典型错误。

这是一套多插件协作的行业方案:1 个 solution 编排器 + 9 个 bounded-context 子插件,合计 54 个 model、258 条命令、约 141 个页面,全部以 DSL JSON 声明,叠加在 AuraBoot 运行时和若干业务插件契约(crm、sales、procurement、inventory、finance、quality、product-catalog、org-management、quote-core)之上。已公开仓插件按源码链接标注;专业/行业插件按发行包交付口径描述。下面每个 model 码、命令码、权限码你都能在对应插件里 grep 到,对运行实例调得通。

命名约定先看一眼。子插件的 model 不用统一的 pcba_ 前缀,而是按它所扩展的核心域命名:RFQ 落在 CRM 域(crm_customer_request_pcba_rfq)、BOM 落在工程域(eng_bom_pcba_mbom)、工单落在制造域(mfg_work_order_pcba_execution)、销售单扩展走 sl_sales_order_pcba_ext。命令码一律是冒号格式 <ns>:<动词>_<名词> 或 <modelCode>:<动作>,不是点号。

1. 用户场景

一家 PCBA(印刷电路板组装)代工厂,接电子产品客户的板卡订单。一次询价涉及上百个元器件,每个元器件有湿度敏感等级(MSD)、可替代物料、多级工程 BOM、IPC/JEDEC 批次追溯要求。日常主线:

• 客户发来板卡需求 → 录入 RFQ,工程做 DFM 可制造性评审(通过 / 有条件 / 不通过);
• DFM 通过后 → 报价(quote-core 算成本)→ 客户接受 → 转销售订单;
• 工程整理 多级 BOM(MBOM)与工艺路线,有替代料和 ECN/ECO 工程变更;
• 跑 MRP 算物料需求 → 采购下单、来料 → 生产工单 排产、投产、报工;
• 生产途中 IQC/PQC/FQC 检验,异常开 NCR,湿敏器件按 MSD 计时烘烤;
• 出货前过 合规检查清单,留存 IPC 合规证据;最后包装、出货、开票、记成本。

CRM、销售、工程、生产、采购、质量、财务看到的视图和能做的操作各不相同。

2. 需求痛点

• 跨步契约靠人:数据应用构建器把每一步变成一个屏,但「DFM 没过不能报价」「BOM 没确认不能投产」这类跨步约束散落在 UI 分支和人脑里。
• 工程变更打断流程:ECN 中途到达,谁去通知在制工单用哪个 BOM 版本?手工传话容易投错料。
• 批次断链:哪一批料、哪个 MSD 记录用在了哪张工单、发给了哪个客户,事后查不到。
• 操作无授权无审计:谁把工单投产了、谁判的 DFM 通过,没有统一记录;改状态只能靠人盯。
• 集成困难:RFQ、报价、检验结果想自动触发下游动作,却只能靠人工二次录入。

这些都不是「再加一张表」能解决的,而是受控状态变更的问题。

3. 产品方案

在 AuraBoot 里,每一个业务动作都是一条命令,走统一的 命令管道:

• RFQ 详情页上的「发起 DFM 评审」按钮调用 pe:request_dfm_pcba_rfq,而不是裸写 PUT /api/...;命令在管道里统一鉴权 → 校验 → 执行 → 审计 → 发事件。
• 状态机由声明驱动:pe:request_dfm_pcba_rfq/pe:pass_dfm_pcba_rfq/pe:fail_dfm_pcba_rfq 把 RFQ 的 crm_crq_dfm_status 在 pending → in_review → passed/conditional/failed 之间流转,DFM 没过的 RFQ 在转单环节会被拒。
• 同一条命令既是 UI 按钮的目标,也能被自动化规则、BPM 流程、AI agent 调用(命令带 cmd_risk_level 和 agent_hint)——例如 qc:auto_trigger_fqc、qc:auto_trigger_pqc 就是检验自动触发命令,而 RFQ 创建命令的 agent_hint 直接写明它该怎么被 agent 使用。
• 跨模块编排靠 pcba-solution 这个 solution 型编排器:它通过 plugin.json 的 dependencies 声明对 11 个底座/子插件的依赖,只装合规子插件而不装它依赖的制造插件,会在导入时被引用校验拒绝。

4. 功能设计

4.1 数据模型(54 个,按域分插件)

每个 model 归属一个插件;pcba-solution 不持有业务 model,只做聚合与跨模块 wiring。

4.2 命令与状态机

命令命名是冒号格式:RFQ/DFM/仓储那一类用插件命名空间前缀(pe:<动词>_<名词>、qc:<动词>_<名词>),其余按 <modelCode>:<动作>(如 eng_bom_pcba_mbom:activate、mfg_work_order_pcba_execution:start)。代表性命令:

每条命令都是一段声明。例如 pe:request_dfm_pcba_rfq(在 pcba-crm/config/commands/crm_customer_request_pcba_rfq.json)的真实定义:

{
  "code": "pe:request_dfm_pcba_rfq",
  "displayName:zh-CN": "发起DFM评审",
  "displayName:en": "Request DFM Review",
  "description": "Move the PCBA RFQ engineering gate into DFM review.",
  "type": "state_transition",
  "modelCode": "crm_customer_request_pcba_rfq",
  "stateField": "crm_crq_dfm_status",
  "fromStates": ["pending"],
  "toState": "in_review",
  "permissions": ["pe.dfm.manage"],
  "extension": {
    "confirmMessage:zh-CN": "确认发起 DFM 评审？",
    "confirmMessage:en": "Start the DFM review for this RFQ?"
  }
}

读出来的设计信息:这是一条 state_transition,把 RFQ 的 crm_crq_dfm_status 从 pending 流转到 in_review;要求 pe.dfm.manage 权限;点击时弹出 confirmMessage 二次确认。它的兄弟命令 pe:pass_dfm_pcba_rfq(in_review → passed)、pe:flag_dfm_conditional_pcba_rfq(in_review → conditional)、pe:fail_dfm_pcba_rfq(in_review → failed)合起来,就是一台完整的 DFM 评审状态机。fromStates/toState 的合法值与 crm_crq_dfm_status 字典严格对齐(下面 4.4 字典)。

而 RFQ 的创建命令 pe:create_customer_request_pcba_rfq 还带 agent_hint("Create a PCBA RFQ sidecar 1:1-extending an existing crm_customer_request_common…")和 cmd_risk_level: "L1",这就是它能被 AI agent 安全调用的元数据。

4.3 权限与角色

权限码是 <模块>.<资源>.<动作> 形式。pcba-crm 自带 12 个 RFQ/DFM 相关权限码,pcba-solution 聚合了 48 个(含跨模块 model.<code>.read 数据范围权限)。RFQ 主线用到的 4 个:

pe.rfq.manage     pe.rfq.read      （RFQ 录单 / 只读）
pe.dfm.manage     pe.dfm.read      （DFM 评审门 / 只读）

8 个角色(定义在 pcba-solution/config/roles.json):

举例:质量工程师(pe_quality_engineer)能录检验、开 NCR、过合规清单,但不持有跨客户召回/作废这类高风险命令的权限——这类权限留给管理员或合规角色。整套授权是声明式角色配置,覆盖了原本要散落在 UI、Controller、报表里的分支逻辑。五层模型(RBAC / 数据范围 / ReBAC / ABAC / 字段级)的判定顺序见 权限。

4.4 页面与字典

约 141 个页面:各 model 的 list / form / detail,加上 RFQ 工作台(pcba_rfq_workspace_detail)、BOM 评审、工单作业、检验录入、合规清单等业务页;另有 dashboard。

关键字典(状态枚举,字段值与命令 fromStates/toState 必须一致):

• crm_crq_dfm_status:pending(待评审)/ in_review(评审中)/ passed(通过)/ conditional(有条件)/ failed(未通过)
• crm_crq_bom_status:not_uploaded / parsing / reviewing / confirmed / blocked
• mfg_wo_status:工单状态,confirmed → in_progress → …(被 mfg_work_order_pcba_execution:start 等命令驱动)

5. 具体开发与实施

先掌握基础。这套方案的子插件大多是 config 型,跨模块审批等少量逻辑在 pcba-solution 的后端 jar 里;主体全靠平台的几个核心契约。动手前请先读:Model 与 Field · Command · 命令管道 · Permission · 插件清单 · 纯配置 Plugin · Page Designer。

落地一套像 PCBA 这样的多插件行业方案,步骤是:

1. 划分 bounded context —— 按业务域拆子插件(CRM 扩展、工程、制造、采购、仓储、合规、财务),每个子插件一个 plugin.json,用 dependencies 声明它依赖的核心插件;再用一个 pluginType: solution 的编排器(pcba-solution)聚合权限、角色、菜单、dashboard 与跨模块审批 handler。详见 插件清单。
2. 定义 model 与字段 —— config/models.json + config/fields/。model 码按它扩展的域命名(crm_*_pcba_rfq / eng_*_pcba_* / mfg_*_pcba_*),字段类型用平台 dataType(string / integer / enum / decimal / date…),不要写 string(120) 这种内联长度。详见 Model 与 Field。
3. 声明命令 —— 每个 model 一个或多个 config/commands/<model>.json,状态流转用 type: state_transition + stateField + fromStates/toState,并在 permissions 绑权限码。详见 Command。
4. 配 model-field binding —— 放在 config/bindings/,并在 plugin.json 的 resourceDirs.modelFieldBindings 注册(本方案 pcba-crm 有 8 个、pcba-industry 17 个、pcba-manufacturing 24 个 binding 文件)。详见「典型错误」。
5. 设计页面 —— config/pages/,列表/表单/详情/工作台用 Page Designer 出 DSL。
6. 权限、角色、字典、菜单 —— 子插件持有本域的 permissions.json / dicts.json;solution 编排器聚合 roles.json / menus.json / dashboards。
7. 打包导入 —— 用 aura CLI 的 import-directory-sync(参数是目录 path)或平台导入接口;按依赖顺序导入(先核心插件,再子插件,最后 solution 编排器),校验返回 success:true 才算导入成功。

6. 常见配置

• DFM 评审门:RFQ 的 crm_crq_dfm_status 由 pe:request_dfm_pcba_rfq → pe:pass_dfm_pcba_rfq/pe:flag_dfm_conditional_pcba_rfq/pe:fail_dfm_pcba_rfq 驱动;DFM 未过(failed)的 RFQ 在报价/转单环节会被拒。
• 工程 BOM 版本:eng_bom_pcba_mbom:publish_version 发新版本,eng_bom_pcba_mbom:activate/:deactivate 切激活态;工单投产时锁定 BOM 版本,ECN/ECO 中途到达不改在制工单的版本。
• MSD 湿敏器件计时:eng_msd_pcba_record:open_package(开封起计)→ :start_bake/:complete_bake(烘烤)→ :expire(超时失效),全链路状态留痕。
• 生产工单流转:mfg_work_order_pcba_execution:confirm_materials → :confirm_routing → :start(confirmed → in_progress)→ :complete;:validate_material_binding 在投产前校验物料绑定。
• 检验自动触发:用自动化规则在工序完成事件上调 qc:auto_trigger_pqc / qc:auto_trigger_fqc,无需人工建检验单。
• MRP 运算:mfg_mrp_run_pcba_planning:execute 跑一次净需求计算,产出 mfg_planned_order_pcba_planning,再 :confirm/:convert 转采购或工单。

7. 典型错误

• 命令码用点号:写成 pcba_rfq.submit、pcba.dfm.request 跑不通——真实是冒号格式 pe:request_dfm_pcba_rfq、mfg_work_order_pcba_execution:start。点号是给权限码用的(pe.dfm.manage),命令码一律冒号。
• 猜 model 前缀:这套方案没有统一的 pcba_ model 前缀。RFQ 是 crm_customer_request_pcba_rfq(CRM 域)、BOM 是 eng_bom_pcba_mbom(工程域)、工单是 mfg_work_order_pcba_execution(制造域)。改命令/页面前先 grep 真实 model 码,别按「看起来该叫什么」编。
• 绕过命令直接改表:直接 UPDATE crm_crq_dfm_status 会跳过状态机校验(fromStates 守卫)、权限检查和审计/事件发布,导致 DFM 门形同虚设、下游收不到事件。一切状态变更都走命令。
• fromStates 与字典不一致:pe:pass_dfm_pcba_rfq 的 fromStates: ["in_review"] 必须是 crm_crq_dfm_status 字典里真实存在的值;字段值用了字典外的字符串,状态机直接拒。
• bindingRules 写进 commands.json 内联:不会被导入;必须独立的 binding 文件放在 config/bindings/ 并在 resourceDirs.modelFieldBindings 注册,否则报 [S-EXT-HANDLER] references unregistered handler。详见 纯配置 Plugin。
• 命令执行 payload 结构:字段放在 { "payload": { ... }, "operationType": ... },目标记录用 targetRecordId(不是 recordId)——放错位会出现「执行成功却字段为空」的迷惑性报错。
• 插件导入顺序:子插件依赖核心插件(crm、sales、quality…),pcba-solution 又依赖所有子插件。乱序导入会触发引用校验失败;按 dependencies 拓扑顺序导,最后导编排器。

下一步

• 系统总览 —— 插件、命令与运行时如何拼到一起
• 命令管道 —— 上面每条命令都走的执行契约
• 权限 —— 上面角色背后的五层模型
• Plugin Manifest —— 方案包如何声明插件依赖