大家好，我是十三。
导言：懂了业务流程，系统菜单还是看不懂
前面的 25 篇文章，我们一起走完了企业最核心的三条业务主线。
花钱的线：从采购申请到采购订单，从收货入库到发票校验，最后付款给供应商。赚钱的线：从销售机会到报价，从销售订单到发货开票，最后把应收账款收回来。管货的线：从入库出库到盘点调拨，从可用库存到安全库存，最后算清楚每一批货的成本。
这三条线环环相扣，理论上已经覆盖了企业日常运营的大部分场景。但有一个问题始终没有正面回答：如果你现在打开一套真实的 ERP 系统，面对左侧导航栏里密密麻麻的几十个菜单，你会怎么找功能？
采购申请在"采购管理"里，但信用额度又在"销售管理"里，而成本结转可能在"财务总账"里。同一个客户，销售看到的叫"客户档案"，财务看到的叫"应收对象"。如果没有人告诉你这些菜单是怎么被划分出来的，你很难凭直觉找到想要的东西。
这就是模块划分要解决的问题。业务流程告诉你"事情怎么做"，模块划分告诉你"功能放哪里"。 只有把业务流程合理地映射到系统菜单，系统才真的能用。
从今天这篇开始，我们进入"产品设计篇"。先解决最基础的一个问题：功能模块该怎么划分。
功能模块划分解决什么问题
在没有模块概念之前，很多企业系统的雏形是一张巨大的 Excel 表，或者一个包罗万象的内部后台。所有部门的数据都堆在一起，谁都可以改，谁也改不明白。
这种"大杂烩"式系统的后果很直观。销售填了一个客户名称，财务对账时发现这个字在发票上根本打不出来。仓库改了库存数量，采购看到的在途量却对不上。一个字段改了，三个部门的报表全崩。
业务定义：功能模块划分，就是按照业务领域把系统功能拆分成相对独立的单元。每个单元只负责一类业务，单元之间通过明确的"接口"交换数据。
你可以把模块划分理解成公司组织架构在系统里的映射。一家稍有规模的企业，不会把采购、销售、财务、仓储的人全部放在同一个办公室里办公。每个部门有自己的职责、自己的文件柜、自己的审批流程。部门之间通过工作交接单、邮件、系统审批流来协作。
模块划分的本质，就是把这套"部门分工"翻译成"系统分工"。
没有模块划分，系统就是一团乱麻。划分得太碎，又会导致操作一个完整业务需要在七八个菜单之间反复跳转。所以模块划分不是"拆得越细越好"，而是要在"职责清晰"和"操作便捷"之间找到平衡。
模块边界划分原则
那么，划分的依据是什么？业界有三个最基础的原则。
原则一：高内聚、低耦合
这是软件工程里最经典的划分原则。用通俗的话说：同一个模块里的功能，应该彼此紧密相关；不同模块之间的依赖，应该越少越好。
打个比方。你的厨房里，锅碗瓢盆、油盐酱醋都收在同一个橱柜里，这叫高内聚。而厨房和卧室之间，只需要一扇门来进出，不需要把灶台搬到床旁边，这叫低耦合。
在 ERP 里，"入库、出库、盘点、调拨"这些操作都跟实物库存强相关，所以它们应该被放在同一个库存模块里。但如果把"信用额度检查"也放进库存模块，就属于低内聚，因为信用检查关心的是"客户能不能赊账"，跟"仓库里有多少货"是两个维度的问题。
原则二：按业务域划分
模块的边界应该跟着业务域走，而不是跟着技术实现走。
采购域关心"从谁买、买什么、多少钱、什么时候到"。销售域关心"卖给谁、卖什么、多少钱、什么时候收"。这两个域天然就该分开。如果你按技术来分，比如"所有审批功能一个模块，所有报表功能一个模块"，那销售审批和采购审批被揉在一起，业务人员用起来会非常别扭。
原则三：数据归属原则
这一条在业财系统里尤其关键。数据的创建方和维护方，通常就是这个数据所属模块的决定性因素。
客户主数据由 CRM 模块创建和维护，销售订单只能引用，不能反向修改客户的基础信息。物料主数据由主数据模块维护，采购和销售只能读取 SKU 编码、规格、成本价。库存数量由库存模块维护，销售模块可以占用和释放，但不能直接改写库存账面数。
谁对数据的准确性负最终责任，这个数据就归谁管。其他模块需要时，走接口查询，而不是各存一份。
五大核心模块
基于以上三个原则，一套典型的进销存与业财系统，可以被划分为五个核心模块：采购、销售、库存、财务、主数据。
下面我们逐一来看每个模块的职责边界、核心功能和前文回顾。
采购模块：管住企业的每一笔支出
职责边界：采购模块覆盖从"想买东西"到"确定跟谁买"再到"钱付出去"的完整链路。它的核心对象是供应商和采购订单。
核心功能清单：
| 功能 | 说明 |
|---|---|
| 采购申请管理 | 业务部门提交需求，走审批流程 |
| 采购订单管理 | 向供应商下达正式订单，锁定价格和交期 |
| 收货协同 | 跟踪供应商发货，准备入库 |
| 发票校验 | 核对采购订单、入库单、供应商发票的一致性 |
| 付款申请 | 基于校验结果发起付款，进入财务审批 |
| 供应商管理 | 维护供应商档案、评级、合作历史 |
回顾前文：第 1 篇我们讲过采购申请（PR）和采购订单（PO）的流转。PR 解决的是"内部需求统一入口"的问题，PO 解决的是"对外法律承诺"的问题。第 2 篇讲了收货入库时系统如何确认资产增加。第 3 篇的三单匹配，正是采购模块和库存模块、财务模块之间的关键协作点。第 4 篇的结算付款，是采购模块向财务模块移交"应付账款"数据。第 6 篇的在途管理和第 7 篇的暂估入账，也都发生在采购模块和库存、财务模块的交界地带。
在模块视角下，采购模块的关键产出是"已确认的采购订单"和"已校验的发票"。这两份数据分别流向库存模块（驱动入库）和财务模块（驱动付款）。
销售模块：管住所赚的每一分钱
职责边界：销售模块覆盖从"发现潜在客户"到"签下合同"再到"把钱收回来"的完整链路。它的核心对象是客户和销售订单。
核心功能清单：
| 功能 | 说明 |
|---|---|
| 销售机会管理 | 记录潜在客户和跟进过程 |
| 报价管理 | 基于价格策略生成报价单 |
| 销售订单管理 | 客户确认后生成正式订单 |
| 信用检查 | 订单确认前检查客户信用额度 |
| 发货协同 | 通知仓库备货发运 |
| 开票与收款 | 驱动财务开具发票并跟踪回款 |
回顾前文：第 8 篇我们走过销售机会到销售订单的完整流程。第 9 篇的信用检查是销售模块内置的风控闸门，防止坏账。第 10 篇的发货出库标志着物权转移和收入确认的触发条件。第 11 篇的开票与收款完成了 O2C 的闭环。第 13 篇的价格策略决定了报价单上的数字怎么算。第 14 篇的应收账款，则是销售模块和财务模块之间最重要的数据交接。
销售模块的关键产出是"已确认的销售订单"和"已开票的客户应收"。前者流向库存模块（驱动出库），后者流向财务模块（驱动收款）。
库存模块：管住所拥有的每一件实物
职责边界：库存模块覆盖所有实物货物的"收、发、存、盘、调"。它的核心对象是仓库、库位和库存数量。
核心功能清单：
| 功能 | 说明 |
|---|---|
| 入库管理 | 采购入库、生产入库、退货入库 |
| 出库管理 | 销售出库、领料出库、调拨出库 |
| 库存调拨 | 多仓之间的货物转移 |
| 库存盘点 | 定期核对账实，处理盘盈盘亏 |
| 可用库存查询 | 实时计算可销售或可领用的数量 |
| 成本计价 | 计算发出商品的单位成本 |
回顾前文：第 15 到 18 篇我们系统性地讲了入库、出库、盘点、调拨四种核心操作。第 19 篇的可用库存回答了"账上有货为什么不能卖"的问题，这是库存模块对外提供的最核心服务。第 20 篇的安全库存是补货策略的数据基础。第 21 篇的成本计价方法（FIFO、加权平均、标准成本）直接决定了财务模块里的销售成本和期末存货价值。
库存模块是整个业财系统的"实物中枢"。它向上承接采购模块的入库指令，向下响应销售模块的出库请求，向内维护自身的账实一致，向财务模块输出成本数据。
财务模块：业务的最终数字出口
职责边界：财务模块负责把前端业务操作翻译成会计语言，生成凭证、账簿和报表。它是所有业务流程的终点。
核心功能清单：
| 功能 | 说明 |
|---|---|
| 应收管理 | 跟踪客户欠款，管理收款核销 |
| 应付管理 | 跟踪供应商欠款，管理付款审批 |
| 总账管理 | 生成会计凭证，维护科目余额 |
| 银行对账 | 核对银行流水与企业账簿 |
| 业财对账 | 核对业务系统数据与财务凭证 |
| 财务报表 | 输出资产负债表、利润表、现金流量表 |
回顾前文：第 22 到 25 篇我们用四篇文章完整覆盖了对账体系。应收对账确保销售收入准确无误。应付对账确保采购成本真实可靠。银行对账保证资金余额准确。业财对账则是业务系统和财务系统之间的最终校验，是关闭会计期间前的必要步骤。
财务模块不直接产生业务数据，它接收来自采购模块的应付数据、来自销售模块的应收数据、来自库存模块的成本数据，然后将这些数据转化为会计凭证。这种"只读业务、只写财务"的边界，是业财一致性的关键保障。
主数据模块：所有模块的通用语言
职责边界：主数据模块管理被多个业务模块共享的基础数据。它不直接参与业务操作，但缺了它，所有模块都会"对不齐"。
核心功能清单：
| 功能 | 说明 |
|---|---|
| 物料主数据 | SPU、SKU、规格、计量单位 |
| 客户主数据 | 客户档案、信用信息、开票信息 |
| 供应商主数据 | 供应商档案、资质、合作状态 |
| 组织架构 | 公司、部门、仓库、法人主体 |
| 价格主数据 | 价格清单、折扣规则、税率 |
回顾前文：第 5 篇我们专门讲了 SPU 和 SKU，这是物料主数据的核心概念。第 12 篇我们用了整篇文章讲 CRM 作为客户主数据底座的三层模型：身份层、属性层、关系层。当时我的结论是：CRM 不是销售工具，而是 O2C 流程的数据地基。把这个结论放大到整个 ERP，主数据模块就是所有业务流程的地基。
采购模块需要"供应商主数据"才能创建 PO。销售模块需要"客户主数据"才能创建 SO。库存模块需要"物料主数据"才能知道入库的是什么。财务模块需要"组织架构主数据"才能判断这笔业务记在哪个法人账上。
模块间的数据流
五个模块不是孤立的岛屿，而是一条流水线。理解它们之间的数据流转，是理解 ERP 系统架构的关键。
graph LR
A[采购模块] -->|采购订单| B[入库单]
B --> C[库存模块]
C -->|出库单| D[销售模块]
D -->|销售订单| C
D -->|应收账款| E[财务模块]
A -->|应付账款| E
C -->|成本结转| E
F[主数据模块] --> A
F --> C
F --> D
F --> E
这个数据流图有 6 个节点，对应五个业务模块和一个关键单据节点。下面逐条说明。
采购模块 → 入库单 → 库存模块：采购订单是仓库执行入库的唯一依据。没有 PO，仓库理论上不能收货。入库完成后，入库单回传采购模块，确认 PO 已部分或全部履约。
库存模块 ↔ 销售模块：销售订单向库存模块请求库存预占或锁定，库存模块执行出库后回传出库单，确认库存减少。这两个模块的交互最频繁，也是高并发场景最集中的地方。
采购/销售/库存模块 → 财务模块：采购产生应付账款，销售产生应收账款，库存产生销售成本和期末存货价值。这三路数据是财务模块生成凭证的基础。任何一路数据缺失或出错，财务报表就会失真。
主数据模块 → 所有业务模块：物料、客户、供应商等基础数据在业务发生前必须已存在，否则单据无法创建。主数据模块不提供业务流程，但它提供所有流程的"字典"。
模块划分的常见陷阱
即便有了划分原则，实际操作中仍然容易踩坑。以下是三类最常见的陷阱。
陷阱一：过度拆分
有些团队在微服务思维的影响下，把模块拆得极细。采购申请一个服务，采购订单一个服务，发票校验又是一个服务。结果是销售创建一张订单，需要调用十几个接口，任何一个环节超时，整个流程就卡住。
模块划分的粒度应该匹配业务操作的完整性。对于用户来说，"完成一次采购"是一个完整动作，不应该被拆成七八个菜单。模块内部可以有子功能，但对外应该呈现一个完整的业务单元。
陷阱二：边界模糊
最典型的模糊地带是"库存成本"到底归库存模块还是财务模块。从业务看，成本计算方法（FIFO、加权平均）由财务制度决定，似乎该归财务。但从系统看，成本又跟每一笔出入库单据强绑定，似乎该归库存。
这种模糊地带的处理原则是：谁产生原始数据，谁负责计算；谁使用计算结果，谁负责审核。 库存模块根据出入库记录计算成本，财务模块审核成本结转的合理性。各自有清晰的输入和输出，边界就不会乱。
另一个常见的模糊地带是审批流。采购审批和销售审批的底层机制是一样的，但审批规则、审批人、触发条件完全不同。如果把审批流抽成一个完全独立的通用模块，业务配置成本会很高。更务实的做法通常是：每个业务模块内置自己的审批配置，底层共享同一个审批引擎。这样既保持了业务完整性，又避免了重复开发。
陷阱三：数据冗余
为了"查询方便"，销售模块存一份客户地址，财务模块也存一份客户地址。一开始两处的数据是一样的，但半年后销售改了地址，财务没同步，发票就寄错了地方。
数据冗余的代价通常不是即时的，而是在业务流程跑了一段时间后集中爆发。解决方法是严格执行数据归属原则：客户地址由 CRM 维护，销售模块和财务模块只读取，不本地存储。如果查询性能有瓶颈，可以通过缓存或只读副本解决，但数据的唯一写入入口必须只有一个。
功能清单速查表
如果你正在参与一个 ERP 系统的需求评审或产品设计，可以用下面这张表做第一轮模块边界检查。
| 模块 | 核心功能 | 数据归属 | 上下游模块 |
|---|---|---|---|
| 采购模块 | PR、PO、收货、发票校验、付款申请 | 供应商、采购订单 | 上游：主数据；下游：库存、财务 |
| 销售模块 | 商机、报价、SO、信用检查、发货、开票 | 客户、销售订单 | 上游：主数据；下游：库存、财务 |
| 库存模块 | 入库、出库、盘点、调拨、可用库存、成本 | 库存数量、出入库单据 | 上游：采购、销售；下游：财务 |
| 财务模块 | 应收、应付、总账、对账、报表 | 会计凭证、科目余额 | 上游：采购、销售、库存 |
| 主数据模块 | 物料、客户、供应商、组织、价格 | 主数据档案 | 下游：所有业务模块 |
这张表不是标准答案，不同企业的业务形态会有差异。但它提供了一个判断框架：如果你发现某个功能在表里找不到归属，或者某个数据被两个模块同时维护，那就是模块边界需要重新审视的信号。
总结：业务流程是线，模块划分是面
回顾前面的 25 篇文章，我们沿着业务流程一根线一根线地走了下来。P2P 是一条线，O2C 是一条线，库存管理也是一条线。但真实的 ERP 系统不是线，而是一个面。模块划分，就是把这些线编织成面的那根经线和纬线。
采购、销售、库存、财务、主数据，这五个模块构成了业财系统最基础的功能骨架。每个模块有明确的职责，模块之间有清晰的数据接口，整条业务链路才能跑得通、对得齐、查得清。
理解了模块划分，你就具备了从"业务视角"切换到"系统视角"的能力。下一篇文章，我们继续深入产品设计，讲一个每个模块都会用到的核心机制：状态机设计。一张采购订单从"草稿"到"已完结"经历了哪些状态，这些状态之间如何跳转，为什么状态机设计不好会导致流程失控。
敬请期待。
往期回顾
- 业财通识25：业财对账——打通业务与财务的最后一公里
- 业财通识24：银行对账——银行流水与账本的逐笔核对
- 业财通识23：应付对账——管住每一笔该付的钱
- 业财通识22：应收对账——确保每一笔钱都收回来
- 业财通识21：库存成本计价——FIFO、加权平均与标准成本
- 业财通识20：安全库存——科学补货的数学基础
- 业财通识19：可用库存——为什么账上有货却不能卖
- 业财通识18：调拨——多仓协同的物流调度
- 业财通识17：盘点——账实一致的最后防线
- 业财通识16：出库——从销售发货到领料消耗
- 业财通识15：入库——四种场景下的库存增加
- 业财通识14：应收账款——从开票到回款的风险管控
- 业财通识13：价格策略——多维定价与动态调整
关于十三Tech
资深服务端研发工程师、架构师、AI 编程实践者。
专注分享真实的技术实践经验，持续记录企业系统、架构设计与 AI 编程实践。