简介这份文档面向企业信息化建设者、CRM项目选型人员及销售管理岗位从业者系统梳理了一套CRM客户管理系统的完整功能框架可用于需求调研、系统选型对照或功能设计参考。资源为单个doc文档压缩包约376KB以表格化清单形式组织内容按模块逐级列出功能点与说明便于快速检索和比对。文档覆盖计划管理、销售合同管理、开票管理、帐款管理、业绩考核管理、市场信息、促销品广告、统计报表及公共关系管理等模块每个模块下细分销售计划维护、合同变更、调拨开票、月末结账、费用报销、市场活动评估等具体功能并标注功能描述与层级编号。已有801人学习下载适合作为CRM系统功能规划与需求梳理的对照清单使用。1. 从一张“功能清单”到能交付的 CRM 方案很多团队拿到 CRM 需求时第一反应是打开原型工具画页面结果画到第三周发现销售计划、合同、调拨、开票、回款这几块的数据是串起来的页面画得再漂亮单据之间的关联关系没定清楚后面全得返工。这份 CRM 客户管理系统功能清单的价值就在这儿——它把 9 个一级模块、几十个二级功能按业务链路排好了序从计划管理一路走到统计报表和公共关系管理本质上是一张“业务数据流图”。这套方案适合两类人做毕设或课程设计、需要一份结构完整的功能设计文档的学生以及要给中小型销售型企业出一版可交付 CRM 方案的从业者。下面按需求、架构、模块实现、避坑、验收的顺序拆开讲能照着改。2. 需求与总体架构九个模块怎么串成一条业务链2.1 先理清业务主线再谈模块划分这份清单乍看是平铺的功能罗列但把编号读一遍就能看出主线XSP01 计划管理定目标XSP02 合同管理定承诺XSP03 开票管理定交付XSP04 帐款管理定回款XSP05 业绩考核把前面四块的结果折算到人XSP06 到 XSP08 是市场、广告、报表三条支撑线XSP09 公共关系管理是协同工具层。这条主线决定了数据库设计的方向——所有单据都必须能往上追溯到合同、往下关联到回款中间不能断链。我一般会把系统切成四层接入层Web 端 导入接口、业务层九个模块的服务、单据流转层合同→调拨→发票→回款的状态机、数据层主数据 单据 统计快照。单据流转层是这套系统真正的核心也是最容易在毕设答辩时被追问的地方。举个具体例子可开票量的公式在清单里写得很明确——可开票量 实际库存 − 开票未提。这个公式背后要求库存表、调拨单表、发票表三者实时对得上任何一张单据状态变更都要触发重算不能靠定时任务糊弄。2.2 技术选型为什么这套系统不适合“全微服务”功能清单里大量出现“审核”“反结账”“红冲”“单据跟踪”这类词说明这是一个强事务、强状态一致性的系统。月末结转要求“结转后无法修改已结账的应收账款”反结账又要求能把已结数据置回未结——这是典型的需要跨表事务保证的操作。我的建议是单体应用 模块化分包数据库用单一实例用事务把结转、反结、红冲包住统计报表单独走只读从库或物化视图避免大查询拖慢单据操作。技术栈上后端用 Spring Boot MyBatis-Plus 足够前端用 Vue 3 Element Plus报表部分用 ECharts 画合同履约和产销存对比。不建议一上来就上消息队列拆异步这套系统的单据量级中小型企业单体扛得住拆了反而让“调拨与税票对账”这种需要强一致的逻辑变复杂。选型的原则只有一条凡是清单里写了“审核后不可修改”的功能就必须落在同一个事务边界内。2.3 核心数据表设计单据关联是骨架把清单里的关联关系翻译成表结构关键就几张主表和一张关联表。下面这段是核心单据表的建表片段重点看状态字段和关联字段的设计-- 销售合同主表合同是整条链路的源头 CREATE TABLE sale_contract ( id BIGINT PRIMARY KEY, contract_no VARCHAR(32) NOT NULL UNIQUE, -- 合同编号业务唯一键 customer_id BIGINT NOT NULL, -- 关联经销单位 sign_date DATE NOT NULL, total_amount DECIMAL(14,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0草稿 1已审核 2变更中 3已关闭 version INT NOT NULL DEFAULT 1 -- 变更时递增配合变更历史表 ); -- 调拨单间接开票方式下的核心单据 CREATE TABLE transfer_order ( id BIGINT PRIMARY KEY, transfer_no VARCHAR(32) NOT NULL UNIQUE, contract_id BIGINT, -- 可为空无合同也可调拨 apply_id BIGINT, -- 来源调拨申请可空 warehouse_id BIGINT NOT NULL, -- 按库房打印分割单的依据 qty DECIMAL(12,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0待审 1已审 2已开票 3已作废 4已红冲 invoiced_qty DECIMAL(12,2) DEFAULT 0 -- 已开票数量用于算可开票量 ); -- 单据关联表支撑“单据跟踪”和“调拨出库关联查询” CREATE TABLE doc_relation ( id BIGINT PRIMARY KEY, src_type VARCHAR(16) NOT NULL, -- CONTRACT/APPLY/TRANSFER/INVOICE src_id BIGINT NOT NULL, dst_type VARCHAR(16) NOT NULL, dst_id BIGINT NOT NULL, create_time DATETIME NOT NULL );doc_relation这张表是清单里 XSP03.16“单据跟踪”和 XSP03.18“调拨出库关联查询”的落地基础。很多同学做毕设时把关联关系直接写成外键字段结果合同变更后历史链路就断了用独立的关联表记录每一次流转才能既查到当前状态、又查到历史路径。transfer_order.invoiced_qty这个冗余字段是刻意的——可开票量查询是高频操作每次去汇总发票表算已开票量会拖慢列表页用冗余字段 开票时同步更新是这类系统的常规做法。3. 计划与合同模块审核流和变更历史怎么落地3.1 计划管理的统一模型五类计划一套代码清单里 XSP01 下面有五类计划——销售、回款、费用、生产、要货功能描述几乎一模一样分年/月/季录入增删改查加审核。这种“同构功能”最忌讳复制五套代码。我的做法是抽一张计划主表加一个类型字段用策略模式区分校验规则// 计划类型枚举对应清单里的五类计划 public enum PlanType { SALES, PAYBACK, EXPENSE, PRODUCTION, REQUISITION } // 统一计划实体period_type 区分年/月/季 public class Plan { private Long id; private PlanType type; private String periodType; // YEAR / MONTH / QUARTER private String period; // 2024 / 2024-06 / 2024-Q2 private BigDecimal amount; private Integer status; // 0草稿 1待审 2已审 3已驳回 } // 审核动作统一走状态机不同计划类型只覆写校验 public void approve(Long planId, String auditor) { Plan plan planMapper.selectById(planId); if (plan.getStatus() ! 1) { throw new BizException(仅待审状态可审核); } plan.setStatus(2); planMapper.updateById(plan); auditLogService.record(planId, auditor, APPROVE); }这样做的收益在后期客户要加第六类计划比如“促销品要货计划”只需要加一个枚举值和一条校验规则列表页、审核流、权限都不用动。清单里五类计划都写了“审核”说明审核是共性需求把它做成统一状态机比每类计划各写一套 if-else 靠谱得多。period字段用字符串存而不是拆三个字段是为了让“按年汇总、按月明细”的查询用一条LIKE 2024%就能覆盖代价是牺牲了一点类型严格性在这个场景下划算。3.2 合同变更版本号 历史表别在原记录上改XSP02 里“合同变更维护”和“合同变更历史查询”是成对出现的这提示了一个关键设计合同变更不能直接 UPDATE 原记录。正确做法是主表保留当前版本变更时把旧版本快照写入历史表主表version加一。清单里 XSP02.05 要求“合同履约情况查询可以用图形方式显示”履约数据要按版本追溯如果历史丢了图形就只能画当前版本答辩时一问就露馅。变更历史表的结构建议包含contract_id、version、change_type金额变更/数量变更/交期变更、before_json、after_json、operator、change_time。用 JSON 存前后快照的好处是字段增减不用改表结构坏处是不能直接按字段查询——所以变更类型要单独存一列查询时先按类型过滤再解析 JSON。合同导入功能XSP02.01要注意校验电子文本合同导入必须做编号去重和金额格式校验导入失败的记录要落错误表并给出行号否则用户拿着一份几百行的 Excel 根本不知道哪行错了。3.3 履约图形化数据准备比图表本身重要履约情况图形化难点不在 ECharts 配置在于“履约”怎么定义。我的口径是合同总量 vs 已开票量 vs 已回款额三条曲线按时间轴铺开数据来源分别是合同表、调拨/发票表、回款表。这三张表的时间字段口径必须统一——开票按发票日期、回款按到账日期不能一个用创建时间一个用审核时间否则曲线对不上用户第一眼就质疑数据准确性。图形接口建议做成按合同 ID 聚合的单接口前端一次拿全量数据避免三个接口分别请求导致时间轴错位。4. 开票与帐款模块状态机、结转与反结的硬骨头4.1 直接开票与间接开票两条路径一套状态机清单里 XSP03 把开票拆成两条路径间接开票走“调拨申请→调拨计划→审批→调拨单→发票”直接开票把调拨开票和发票管理合成一步。很多实现会把这两条路径写成两套代码结果对账时发现状态对不上。我的做法是统一状态机直接开票只是跳过中间节点// 调拨单状态流转直接开票时从待审直接跳到已开票 public enum TransferStatus { PENDING(0), APPROVED(1), INVOICED(2), VOIDED(3), RED_FLUSHED(4); public static boolean canTransit(int from, int to) { // 合法流转表待审→已审→已开票已审→作废已开票→红冲 return switch (from) { case 0 - to 1 || to 3; case 1 - to 2 || to 3; case 2 - to 4; default - false; }; } }红冲XSP03.04 提到的“单据的红冲处理”要生成一张负数调拨单而不是删原单原单状态置为已红冲两张单通过doc_relation关联。作废和红冲的区别要在文档里写清楚作废用于未开票单据红冲用于已开票单据这个区分在答辩时是加分项因为清单里两个词都出现了但没解释差异。4.2 月末结转三件套正式结转、模拟结转、反结XSP04.02 这三个功能是整个系统事务要求最高的地方。正式结转把当期应收账款锁定模拟结转只出结果不落库反结把已结数据置回未结。实现要点有三个第一结转操作必须在一个事务里完成“生成结转批次记录 更新应收账款状态 写结账日期”任何一步失败全回滚第二模拟结转复用正式结转的计算逻辑但走只读事务、结果写临时表或直接返回绝不碰正式数据第三反结要校验“该批次之后没有新的结转”否则会出现时间线错乱。-- 结转批次表反结的依据 CREATE TABLE settle_batch ( id BIGINT PRIMARY KEY, settle_month VARCHAR(7) NOT NULL, -- 2024-06 settle_type TINYINT NOT NULL, -- 1正式 2模拟 status TINYINT NOT NULL, -- 0进行中 1已完成 2已反结 operator VARCHAR(32), settle_time DATETIME, reverse_time DATETIME );反结时把status置 2同时把该批次涉及的应收账款记录状态批量改回未结。这里有个血泪经验反结必须记录操作日志因为财务数据被回退是敏感操作出问题时要能查到是谁在什么时候反的。清单里 XSP04.03“结账日期查询”正好可以复用这张批次表按settle_month倒序查即可。4.3 可开票量与开票未提两个高频查询的索引设计可开票量 实际库存 − 开票未提这个公式要落地成查询涉及库存表、调拨单表、发票表三表关联。开票未提查询的是“已开调拨单但未提货”的单据本质是按调拨单状态过滤。这两个查询都是列表页高频调用索引必须提前设计调拨单表在(status, warehouse_id)上建联合索引发票表在(transfer_id)上建索引库存表按(warehouse_id, product_id)建唯一索引。没有这些索引数据量上到十万级列表页就会转圈演示时很尴尬。调拨与税票对账XSP03.09建议做成差异列表而不是全量比对只列出调拨单金额与发票金额不一致、或调拨单已开票但无对应发票的记录。全量比对在页面上没法看差异列表才是财务人员真正要的东西。5. 业绩、市场与协同模块统计口径和提醒机制5.1 业绩考核费用借还和销量必须同口径聚合XSP05 这块的核心是“业绩考核查询”——按年月、部门、地区统计费用、销量、销售额。难点在口径统一费用来自借款、报销、分类费用三张表销量来自调拨或发票销售额来自合同或发票。我的做法是建一张月度汇总快照表每月结转后跑一次聚合任务把每个人每个维度的费用、销量、销售额算好存进去查询直接读快照。实时聚合在数据量小时没问题但业绩考核往往要跨年对比实时算会越来越慢。个人欠款查询XSP05.05的逻辑是“借款总额 − 已报销冲抵 − 已还款”这个余额要能按人、按时间点查。建议在借款表和报销表上都加person_id和biz_date查询时用窗口函数按时间累计比在应用层循环算可靠。5.2 市场信息与促销品主数据先行XSP06 和 XSP07 看起来是录入类功能但“目标市场划分”要求按省份、地区、品牌统计销量说明地区、品牌是主数据必须先建字典表再谈录入。经销单位信息XSP06.04是客户主数据合同、调拨、回款都引用它这张表的字段设计要预留信用额度、结算方式等扩展位不然后面加字段要改一堆关联查询。促销品库存XSP07.08是简单的出入库台账入库加、出库减库存 入库累计 − 出库累计。别把它做成复杂的仓储系统清单里只要求“查询当前库存”过度设计反而增加维护成本。广告合同四类户外、促销公关、电视报纸、印刷品结构相同用一张合同表加ad_type字段区分即可和计划管理的思路一致。5.3 公共关系管理提醒任务的调度设计XSP09 的生日节日管理、任务管理、日程表、短信发送记录本质是一个轻量提醒系统。设计要点是“提醒规则”和“发送记录”分离规则表存“谁的生日、提前几天提醒、通过短信还是邮件”发送记录表存每次实际发送的结果。短信发送记录XSP09.07要记录成功与否和失败原因方便排查。调度用简单的定时任务扫规则表即可不需要引入复杂的调度框架但要注意幂等——同一天重复扫描不能重复发送用“规则 ID 日期”做唯一键去重。6. 避坑与排查这类系统最容易翻车的五个点6.1 结转后数据还能改事务边界没包住现象是正式结转完成后应收账款仍能被编辑。原因通常是结转逻辑和单据编辑逻辑不在同一个服务里编辑接口没校验结账状态。解决办法是在应收账款的更新入口统一加拦截先查该记录所属月份是否已正式结转已结转则拒绝修改并提示“请先反结账”。这个校验要放在服务层而不是前端前端校验只是体验服务层才是底线。6.2 可开票量算出来是负数冗余字段没同步现象是列表页显示可开票量为负。原因多半是invoiced_qty冗余字段在红冲或作废时没回退。解决方法是把所有影响已开票量的操作开票、红冲、作废收敛到一个服务方法里方法内统一更新冗余字段禁止其他地方直接改这个字段。再加一条对账 SQL 定期跑汇总发票表实际已开票量和冗余字段比对不一致就告警。6.3 合同变更后历史查不到直接 UPDATE 了原记录现象是变更历史列表为空或只有最新一条。原因是变更时直接改了主表没写历史表。解决办法是变更入口强制走“快照 版本递增”流程并在数据库层给历史表加触发器或由服务层保证成对写入。排查时对比主表version和历史表最大版本号不相等就是漏写了。6.4 报表数字和单据对不上统计口径混用现象是销售月报的金额和合同列表合计不一致。原因通常是报表用了创建时间而单据列表用了审核时间或者一个含作废单据一个不含。解决办法是在需求文档里把每个报表的口径写死统计哪些状态、按哪个日期字段、含不含红冲。口径一旦定下就写进代码注释和接口文档后续改动要评审。6.5 导入合同大量失败但不知道哪行错错误定位缺失现象是用户导入 Excel 后提示“导入失败”没有行号。原因是校验异常被统一捕获后只返回了概括信息。解决办法是逐行校验、逐行收集错误返回结构包含行号、字段名、错误原因前端渲染成表格让用户直接改。导入这种功能错误提示的友好程度直接决定用户会不会用第二次。7. 验收与答辩用一张单据链路图讲清整套系统验收这套系统我一般不看页面数量只看一条链路能不能走通新建销售计划 → 审核 → 签合同 → 合同变更并留历史 → 生成调拨申请 → 审批 → 开调拨单 → 开票 → 回款登记 → 月末模拟结转 → 正式结转 → 反结 → 再正式结转 → 查业绩考核和销售月报。这条链路走完九个模块里至少七个被覆盖剩下的市场信息和公共关系管理单独点几下即可。答辩时把这条链路画成一张图手画或 PPT 都行比逐页翻功能列表有说服力得多。验收清单建议做成表格逐项打勾验收项通过标准检查方式计划审核流五类计划均能走完待审到已审每类各建一条走一遍合同变更追溯变更后历史可查、版本递增改一次金额查历史表可开票量与手工计算一致造三条调拨单对比结转与反结反结后数据可改、再结正常连续两次结转反结单据跟踪合同到发票链路完整按合同号查关联表报表口径月报合计等于合同列表合计同条件两处对比答辩被问得最多的问题是“为什么这么设计”而不是“这个功能怎么用”。所以每个模块的准备重点应该是设计理由为什么用关联表而不是外键、为什么结转要批次表、为什么冗余已开票量。把避坑章节里那五个点提前想好答案基本能接住追问。从那以后我每次带这类单据型系统都会在开发前先把“状态机 关联表 结转批次”三张表定死再动手写页面——这三样定不下来后面写多少代码都是返工。希望帮到你。本文还有配套的精品资源点击获取
简介这份文档面向企业信息化建设者、CRM项目选型人员及销售管理岗位从业者系统梳理了一套CRM客户管理系统的完整功能框架可用于需求调研、系统选型对照或功能设计参考。资源为单个doc文档压缩包约376KB以表格化清单形式组织内容按模块逐级列出功能点与说明便于快速检索和比对。文档覆盖计划管理、销售合同管理、开票管理、帐款管理、业绩考核管理、市场信息、促销品广告、统计报表及公共关系管理等模块每个模块下细分销售计划维护、合同变更、调拨开票、月末结账、费用报销、市场活动评估等具体功能并标注功能描述与层级编号。已有801人学习下载适合作为CRM系统功能规划与需求梳理的对照清单使用。1. 从一张“功能清单”到能交付的 CRM 方案很多团队拿到 CRM 需求时第一反应是打开原型工具画页面结果画到第三周发现销售计划、合同、调拨、开票、回款这几块的数据是串起来的页面画得再漂亮单据之间的关联关系没定清楚后面全得返工。这份 CRM 客户管理系统功能清单的价值就在这儿——它把 9 个一级模块、几十个二级功能按业务链路排好了序从计划管理一路走到统计报表和公共关系管理本质上是一张“业务数据流图”。这套方案适合两类人做毕设或课程设计、需要一份结构完整的功能设计文档的学生以及要给中小型销售型企业出一版可交付 CRM 方案的从业者。下面按需求、架构、模块实现、避坑、验收的顺序拆开讲能照着改。2. 需求与总体架构九个模块怎么串成一条业务链2.1 先理清业务主线再谈模块划分这份清单乍看是平铺的功能罗列但把编号读一遍就能看出主线XSP01 计划管理定目标XSP02 合同管理定承诺XSP03 开票管理定交付XSP04 帐款管理定回款XSP05 业绩考核把前面四块的结果折算到人XSP06 到 XSP08 是市场、广告、报表三条支撑线XSP09 公共关系管理是协同工具层。这条主线决定了数据库设计的方向——所有单据都必须能往上追溯到合同、往下关联到回款中间不能断链。我一般会把系统切成四层接入层Web 端 导入接口、业务层九个模块的服务、单据流转层合同→调拨→发票→回款的状态机、数据层主数据 单据 统计快照。单据流转层是这套系统真正的核心也是最容易在毕设答辩时被追问的地方。举个具体例子可开票量的公式在清单里写得很明确——可开票量 实际库存 − 开票未提。这个公式背后要求库存表、调拨单表、发票表三者实时对得上任何一张单据状态变更都要触发重算不能靠定时任务糊弄。2.2 技术选型为什么这套系统不适合“全微服务”功能清单里大量出现“审核”“反结账”“红冲”“单据跟踪”这类词说明这是一个强事务、强状态一致性的系统。月末结转要求“结转后无法修改已结账的应收账款”反结账又要求能把已结数据置回未结——这是典型的需要跨表事务保证的操作。我的建议是单体应用 模块化分包数据库用单一实例用事务把结转、反结、红冲包住统计报表单独走只读从库或物化视图避免大查询拖慢单据操作。技术栈上后端用 Spring Boot MyBatis-Plus 足够前端用 Vue 3 Element Plus报表部分用 ECharts 画合同履约和产销存对比。不建议一上来就上消息队列拆异步这套系统的单据量级中小型企业单体扛得住拆了反而让“调拨与税票对账”这种需要强一致的逻辑变复杂。选型的原则只有一条凡是清单里写了“审核后不可修改”的功能就必须落在同一个事务边界内。2.3 核心数据表设计单据关联是骨架把清单里的关联关系翻译成表结构关键就几张主表和一张关联表。下面这段是核心单据表的建表片段重点看状态字段和关联字段的设计-- 销售合同主表合同是整条链路的源头 CREATE TABLE sale_contract ( id BIGINT PRIMARY KEY, contract_no VARCHAR(32) NOT NULL UNIQUE, -- 合同编号业务唯一键 customer_id BIGINT NOT NULL, -- 关联经销单位 sign_date DATE NOT NULL, total_amount DECIMAL(14,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0草稿 1已审核 2变更中 3已关闭 version INT NOT NULL DEFAULT 1 -- 变更时递增配合变更历史表 ); -- 调拨单间接开票方式下的核心单据 CREATE TABLE transfer_order ( id BIGINT PRIMARY KEY, transfer_no VARCHAR(32) NOT NULL UNIQUE, contract_id BIGINT, -- 可为空无合同也可调拨 apply_id BIGINT, -- 来源调拨申请可空 warehouse_id BIGINT NOT NULL, -- 按库房打印分割单的依据 qty DECIMAL(12,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0待审 1已审 2已开票 3已作废 4已红冲 invoiced_qty DECIMAL(12,2) DEFAULT 0 -- 已开票数量用于算可开票量 ); -- 单据关联表支撑“单据跟踪”和“调拨出库关联查询” CREATE TABLE doc_relation ( id BIGINT PRIMARY KEY, src_type VARCHAR(16) NOT NULL, -- CONTRACT/APPLY/TRANSFER/INVOICE src_id BIGINT NOT NULL, dst_type VARCHAR(16) NOT NULL, dst_id BIGINT NOT NULL, create_time DATETIME NOT NULL );doc_relation这张表是清单里 XSP03.16“单据跟踪”和 XSP03.18“调拨出库关联查询”的落地基础。很多同学做毕设时把关联关系直接写成外键字段结果合同变更后历史链路就断了用独立的关联表记录每一次流转才能既查到当前状态、又查到历史路径。transfer_order.invoiced_qty这个冗余字段是刻意的——可开票量查询是高频操作每次去汇总发票表算已开票量会拖慢列表页用冗余字段 开票时同步更新是这类系统的常规做法。3. 计划与合同模块审核流和变更历史怎么落地3.1 计划管理的统一模型五类计划一套代码清单里 XSP01 下面有五类计划——销售、回款、费用、生产、要货功能描述几乎一模一样分年/月/季录入增删改查加审核。这种“同构功能”最忌讳复制五套代码。我的做法是抽一张计划主表加一个类型字段用策略模式区分校验规则// 计划类型枚举对应清单里的五类计划 public enum PlanType { SALES, PAYBACK, EXPENSE, PRODUCTION, REQUISITION } // 统一计划实体period_type 区分年/月/季 public class Plan { private Long id; private PlanType type; private String periodType; // YEAR / MONTH / QUARTER private String period; // 2024 / 2024-06 / 2024-Q2 private BigDecimal amount; private Integer status; // 0草稿 1待审 2已审 3已驳回 } // 审核动作统一走状态机不同计划类型只覆写校验 public void approve(Long planId, String auditor) { Plan plan planMapper.selectById(planId); if (plan.getStatus() ! 1) { throw new BizException(仅待审状态可审核); } plan.setStatus(2); planMapper.updateById(plan); auditLogService.record(planId, auditor, APPROVE); }这样做的收益在后期客户要加第六类计划比如“促销品要货计划”只需要加一个枚举值和一条校验规则列表页、审核流、权限都不用动。清单里五类计划都写了“审核”说明审核是共性需求把它做成统一状态机比每类计划各写一套 if-else 靠谱得多。period字段用字符串存而不是拆三个字段是为了让“按年汇总、按月明细”的查询用一条LIKE 2024%就能覆盖代价是牺牲了一点类型严格性在这个场景下划算。3.2 合同变更版本号 历史表别在原记录上改XSP02 里“合同变更维护”和“合同变更历史查询”是成对出现的这提示了一个关键设计合同变更不能直接 UPDATE 原记录。正确做法是主表保留当前版本变更时把旧版本快照写入历史表主表version加一。清单里 XSP02.05 要求“合同履约情况查询可以用图形方式显示”履约数据要按版本追溯如果历史丢了图形就只能画当前版本答辩时一问就露馅。变更历史表的结构建议包含contract_id、version、change_type金额变更/数量变更/交期变更、before_json、after_json、operator、change_time。用 JSON 存前后快照的好处是字段增减不用改表结构坏处是不能直接按字段查询——所以变更类型要单独存一列查询时先按类型过滤再解析 JSON。合同导入功能XSP02.01要注意校验电子文本合同导入必须做编号去重和金额格式校验导入失败的记录要落错误表并给出行号否则用户拿着一份几百行的 Excel 根本不知道哪行错了。3.3 履约图形化数据准备比图表本身重要履约情况图形化难点不在 ECharts 配置在于“履约”怎么定义。我的口径是合同总量 vs 已开票量 vs 已回款额三条曲线按时间轴铺开数据来源分别是合同表、调拨/发票表、回款表。这三张表的时间字段口径必须统一——开票按发票日期、回款按到账日期不能一个用创建时间一个用审核时间否则曲线对不上用户第一眼就质疑数据准确性。图形接口建议做成按合同 ID 聚合的单接口前端一次拿全量数据避免三个接口分别请求导致时间轴错位。4. 开票与帐款模块状态机、结转与反结的硬骨头4.1 直接开票与间接开票两条路径一套状态机清单里 XSP03 把开票拆成两条路径间接开票走“调拨申请→调拨计划→审批→调拨单→发票”直接开票把调拨开票和发票管理合成一步。很多实现会把这两条路径写成两套代码结果对账时发现状态对不上。我的做法是统一状态机直接开票只是跳过中间节点// 调拨单状态流转直接开票时从待审直接跳到已开票 public enum TransferStatus { PENDING(0), APPROVED(1), INVOICED(2), VOIDED(3), RED_FLUSHED(4); public static boolean canTransit(int from, int to) { // 合法流转表待审→已审→已开票已审→作废已开票→红冲 return switch (from) { case 0 - to 1 || to 3; case 1 - to 2 || to 3; case 2 - to 4; default - false; }; } }红冲XSP03.04 提到的“单据的红冲处理”要生成一张负数调拨单而不是删原单原单状态置为已红冲两张单通过doc_relation关联。作废和红冲的区别要在文档里写清楚作废用于未开票单据红冲用于已开票单据这个区分在答辩时是加分项因为清单里两个词都出现了但没解释差异。4.2 月末结转三件套正式结转、模拟结转、反结XSP04.02 这三个功能是整个系统事务要求最高的地方。正式结转把当期应收账款锁定模拟结转只出结果不落库反结把已结数据置回未结。实现要点有三个第一结转操作必须在一个事务里完成“生成结转批次记录 更新应收账款状态 写结账日期”任何一步失败全回滚第二模拟结转复用正式结转的计算逻辑但走只读事务、结果写临时表或直接返回绝不碰正式数据第三反结要校验“该批次之后没有新的结转”否则会出现时间线错乱。-- 结转批次表反结的依据 CREATE TABLE settle_batch ( id BIGINT PRIMARY KEY, settle_month VARCHAR(7) NOT NULL, -- 2024-06 settle_type TINYINT NOT NULL, -- 1正式 2模拟 status TINYINT NOT NULL, -- 0进行中 1已完成 2已反结 operator VARCHAR(32), settle_time DATETIME, reverse_time DATETIME );反结时把status置 2同时把该批次涉及的应收账款记录状态批量改回未结。这里有个血泪经验反结必须记录操作日志因为财务数据被回退是敏感操作出问题时要能查到是谁在什么时候反的。清单里 XSP04.03“结账日期查询”正好可以复用这张批次表按settle_month倒序查即可。4.3 可开票量与开票未提两个高频查询的索引设计可开票量 实际库存 − 开票未提这个公式要落地成查询涉及库存表、调拨单表、发票表三表关联。开票未提查询的是“已开调拨单但未提货”的单据本质是按调拨单状态过滤。这两个查询都是列表页高频调用索引必须提前设计调拨单表在(status, warehouse_id)上建联合索引发票表在(transfer_id)上建索引库存表按(warehouse_id, product_id)建唯一索引。没有这些索引数据量上到十万级列表页就会转圈演示时很尴尬。调拨与税票对账XSP03.09建议做成差异列表而不是全量比对只列出调拨单金额与发票金额不一致、或调拨单已开票但无对应发票的记录。全量比对在页面上没法看差异列表才是财务人员真正要的东西。5. 业绩、市场与协同模块统计口径和提醒机制5.1 业绩考核费用借还和销量必须同口径聚合XSP05 这块的核心是“业绩考核查询”——按年月、部门、地区统计费用、销量、销售额。难点在口径统一费用来自借款、报销、分类费用三张表销量来自调拨或发票销售额来自合同或发票。我的做法是建一张月度汇总快照表每月结转后跑一次聚合任务把每个人每个维度的费用、销量、销售额算好存进去查询直接读快照。实时聚合在数据量小时没问题但业绩考核往往要跨年对比实时算会越来越慢。个人欠款查询XSP05.05的逻辑是“借款总额 − 已报销冲抵 − 已还款”这个余额要能按人、按时间点查。建议在借款表和报销表上都加person_id和biz_date查询时用窗口函数按时间累计比在应用层循环算可靠。5.2 市场信息与促销品主数据先行XSP06 和 XSP07 看起来是录入类功能但“目标市场划分”要求按省份、地区、品牌统计销量说明地区、品牌是主数据必须先建字典表再谈录入。经销单位信息XSP06.04是客户主数据合同、调拨、回款都引用它这张表的字段设计要预留信用额度、结算方式等扩展位不然后面加字段要改一堆关联查询。促销品库存XSP07.08是简单的出入库台账入库加、出库减库存 入库累计 − 出库累计。别把它做成复杂的仓储系统清单里只要求“查询当前库存”过度设计反而增加维护成本。广告合同四类户外、促销公关、电视报纸、印刷品结构相同用一张合同表加ad_type字段区分即可和计划管理的思路一致。5.3 公共关系管理提醒任务的调度设计XSP09 的生日节日管理、任务管理、日程表、短信发送记录本质是一个轻量提醒系统。设计要点是“提醒规则”和“发送记录”分离规则表存“谁的生日、提前几天提醒、通过短信还是邮件”发送记录表存每次实际发送的结果。短信发送记录XSP09.07要记录成功与否和失败原因方便排查。调度用简单的定时任务扫规则表即可不需要引入复杂的调度框架但要注意幂等——同一天重复扫描不能重复发送用“规则 ID 日期”做唯一键去重。6. 避坑与排查这类系统最容易翻车的五个点6.1 结转后数据还能改事务边界没包住现象是正式结转完成后应收账款仍能被编辑。原因通常是结转逻辑和单据编辑逻辑不在同一个服务里编辑接口没校验结账状态。解决办法是在应收账款的更新入口统一加拦截先查该记录所属月份是否已正式结转已结转则拒绝修改并提示“请先反结账”。这个校验要放在服务层而不是前端前端校验只是体验服务层才是底线。6.2 可开票量算出来是负数冗余字段没同步现象是列表页显示可开票量为负。原因多半是invoiced_qty冗余字段在红冲或作废时没回退。解决方法是把所有影响已开票量的操作开票、红冲、作废收敛到一个服务方法里方法内统一更新冗余字段禁止其他地方直接改这个字段。再加一条对账 SQL 定期跑汇总发票表实际已开票量和冗余字段比对不一致就告警。6.3 合同变更后历史查不到直接 UPDATE 了原记录现象是变更历史列表为空或只有最新一条。原因是变更时直接改了主表没写历史表。解决办法是变更入口强制走“快照 版本递增”流程并在数据库层给历史表加触发器或由服务层保证成对写入。排查时对比主表version和历史表最大版本号不相等就是漏写了。6.4 报表数字和单据对不上统计口径混用现象是销售月报的金额和合同列表合计不一致。原因通常是报表用了创建时间而单据列表用了审核时间或者一个含作废单据一个不含。解决办法是在需求文档里把每个报表的口径写死统计哪些状态、按哪个日期字段、含不含红冲。口径一旦定下就写进代码注释和接口文档后续改动要评审。6.5 导入合同大量失败但不知道哪行错错误定位缺失现象是用户导入 Excel 后提示“导入失败”没有行号。原因是校验异常被统一捕获后只返回了概括信息。解决办法是逐行校验、逐行收集错误返回结构包含行号、字段名、错误原因前端渲染成表格让用户直接改。导入这种功能错误提示的友好程度直接决定用户会不会用第二次。7. 验收与答辩用一张单据链路图讲清整套系统验收这套系统我一般不看页面数量只看一条链路能不能走通新建销售计划 → 审核 → 签合同 → 合同变更并留历史 → 生成调拨申请 → 审批 → 开调拨单 → 开票 → 回款登记 → 月末模拟结转 → 正式结转 → 反结 → 再正式结转 → 查业绩考核和销售月报。这条链路走完九个模块里至少七个被覆盖剩下的市场信息和公共关系管理单独点几下即可。答辩时把这条链路画成一张图手画或 PPT 都行比逐页翻功能列表有说服力得多。验收清单建议做成表格逐项打勾验收项通过标准检查方式计划审核流五类计划均能走完待审到已审每类各建一条走一遍合同变更追溯变更后历史可查、版本递增改一次金额查历史表可开票量与手工计算一致造三条调拨单对比结转与反结反结后数据可改、再结正常连续两次结转反结单据跟踪合同到发票链路完整按合同号查关联表报表口径月报合计等于合同列表合计同条件两处对比答辩被问得最多的问题是“为什么这么设计”而不是“这个功能怎么用”。所以每个模块的准备重点应该是设计理由为什么用关联表而不是外键、为什么结转要批次表、为什么冗余已开票量。把避坑章节里那五个点提前想好答案基本能接住追问。从那以后我每次带这类单据型系统都会在开发前先把“状态机 关联表 结转批次”三张表定死再动手写页面——这三样定不下来后面写多少代码都是返工。希望帮到你。本文还有配套的精品资源点击获取
