金蝶二开的需求怎么提才不返工？把「要什么、在哪做、算多少、谁验收」说清楚

找金蝶二开商做开发，最常见的结局不是「做不出来」，而是「做出来了，但不是我要的」。改一轮、再改一轮，工期一拖再拖，双方都不痛快。真去复盘，代码层面的问题很少，绝大多数返工都出在需求阶段：一句话需求丢过来，开发按自己的理解做了，交付时才发现理解不一样。这篇文章把二开需求拆成四段来讲——要什么、在哪做、算多少、谁验收，最后给一份可以直接复制的需求模板。

一、二开返工，多半不是代码问题

先说一个我们经常遇到的场景。客户说：「帮我在销售订单上加个功能，能自动分配仓库。」

这句话里有太多空白。「分配」是自动还是人工确认？按什么规则分——就近、按库存，还是按客户指定？分不出来的时候是报错，还是给出建议？「仓库」指的是仓，还是仓加位？

开发按自己的理解做了一版，交付时客户说「不是这个意思」。这一轮往返，两周就没了。

根子在于：业务语言和技术语言之间隔着一层翻译。业务说的是「动作」，开发要的是「数据」——哪张单、哪个字段、什么状态、什么时候触发。这层翻译不做，返工就是大概率事件。

所以我们接二开需求时，会把「把需求说清楚」当成项目的第一步，而不是开发的第一步。下面四段，就是把这件事拆开来讲。

二、要什么：把「想要个功能」翻译成单据、状态、字段

任何二开需求，落到系统里都是对某张单做某件事。所以「要什么」这一段的写法是固定的三问：

1. 在哪张单上做？销售订单、采购订单、发货单、收款单——说清楚是标准单据还是自定义单据。如果涉及多张单联动（比如订单保存后自动生成发货单），每张都要说到。
2. 什么时候触发？是录单时自动算、保存时校验、审核后执行，还是定时批量跑？触发时机不同，实现方式完全不同。举个例：保存时校验，不满足就直接报错拦住；审核后执行，就只能事后纠正。
3. 涉及哪些字段？新增字段叫什么、什么类型、从哪取值、是否必填、要不要显示在列表上。这一步写得越具体，后面越省事。

一个说清楚的需求长这样：

「在销售订单上新增一个仓库字段（下拉选择，必填）；保存时按客户所在区域和商品是否有现货，自动带出默认仓库，允许人工修改；已经人工改过的单不再被自动覆盖。」

这样一句话，开发就能直接开工了。

三、在哪做：标准配置、插件、接口，三条路先分清

很多需求其实用不着二开。金蝶云星空、云星辰本身有大量配置能力：审批流、单据转换规则、自定义字段、打印模板、权限方案。这些东西用配置就能实现，比写代码快，升级时也基本不受影响。

所以需求提上来，我们会先判断它落在哪条路上。大致分三种：

这里有一条经验：能用配置解决的不用代码，能用接口解决的就不改核心。同一个效果，走配置的可能十年不用管；改核心的，每次升级都要重新适配一遍。需求阶段先把路径分清，能省掉后面很多麻烦。

四、算多少：数量和频率，是工作量的底

「加个字段」和「加个字段还得管 3 万条历史数据」，工作量差着量级。所以需求里要带上量化信息，主要看两个维度：

• 数量：单据量级（每月几百单还是几万单）、涉及的商品与客户数量、要处理的历史数据条数、要适配的仓库或门店个数。
• 频率：是录单时实时触发，每天跑一次，还是每月一次。实时触发对性能要求最高；批量跑则要考虑错峰执行和失败重跑。

还要说清是否涉及历史数据。如果新功能要对已有单据生效，就得评估历史数据的补录或迁移方案——这一步经常被忽略，等到上线前才发现，时间就来不及了。

另外，新功能会和哪些现有功能发生关系也要提前说：要不要进报表、要不要参与成本计算、要不要放进审批流。这些「牵连」决定改动范围，也直接决定工作量。

五、谁验收：验收口径要在开发前定下来

二开最容易扯皮的地方不是开发，是验收。「我觉得还差点意思」这种反馈，既没法改，也没法结项。

所以我们在开工前，会和客户一起把验收口径写下来，至少包含四项：

1. 验收人是谁。谁签字算通过。业务提出人、财务、IT 三方意见不一致时，以谁为准，先讲好。
2. 验收用例。把正常走一遍、边界情况、异常情况各列一到两条。比如退货单数量超过原销售单数量时，系统应该报错还是放行。
3. 验收数据。用测试账套还是正式账套、用哪批数据。这一步建议一律在测试账套做，验收通过再上正式。
4. 本期不做什么。把不做的东西明确划出来。这条最容易被忽略，却恰恰是防止范围无限扩大的关键。

这四条写下来，开发过程中再有人提新想法，直接对照清单——属于本期的排进去，不属于的留到下一期。双方都省事。

六、一页需求模板（可直接复制）

把上面四段拼起来，就是下面这份模板。照着填，基本能覆盖大部分二开需求：

一句话目标：要解决什么业务问题
在哪张单：单据名称，标准单还是自定义单
什么时候：录单时 / 保存时 / 审核后 / 定时批量
涉及字段：字段名 / 类型 / 取值来源 / 是否必填 / 是否上列表
触发规则：满足什么条件做什么动作，不满足怎么处理
数量与频率：单据量级 / 触发频率 / 是否涉及历史数据
牵连范围：是否进报表 / 是否参与成本 / 是否走审批流
验收方式：验收人 / 三条测试用例 / 测试账套 / 本期不做什么

这套模板我们内部一直在用，客户填一遍，需求基本就能说清。填不出来的地方，通常就是还没想清楚的地方——这正是它的用处。

顺便说一下我们的边界，免得白聊：

• 接：金蝶云星空与云星辰的单据二开、插件开发、报表二开、WebAPI 与 OpenAPI 对接，以及与电商、物流、支付、数电票系统的集成、历史数据迁移与清洗。
• 不接：把标准产品整包换掉的重构、没有明确业务目标的功能堆砌，以及需要改动金蝶核心代码、影响后续升级的方案。

第二条不是推脱。改动核心代码看着能快速满足当下需求，但下一次金蝶升级就会变成大麻烦，最后还是得推倒重来。我们更愿意在需求阶段就把这件事讲清楚。

七、小结：需求说清楚，双方都省钱

二开这件事，最值钱的工作其实在写第一行代码之前。把「要什么、在哪做、算多少、谁验收」四段说清楚，返工能少一大半，工期和报价也更准——因为开发不用猜，也不用留一大块冗余去兜风险。

如果你手上正好有个二开需求，可以照上面那份模板先填一遍。填完还有说不清的地方，也可以直接打 13632123901 聊，我们帮你把需求先理清楚，再看要不要开发、怎么开发。