代理商下单系统，定制范围怎样区分

把“按原来的方式做”改成具体动作

老板说要灵活，销售说要方便，代理商说要保持原有习惯，这些表达还不足以划定范围。以价格为例，需要说清哪个代理商、哪种商品、何时采用哪份价格，以及价格调整后已提交的订单如何处理。只写“支持客户价格”，无法说明这些细节。 库存也要有具体含义。代理商看到的数量，是某个仓库的实存、扣除占用后的可售数量，还是企业另行确定的对外数量？企业应先选择适合自身业务的口径，并确定更新责任。不同部门尚未达成一致时，增加一个库存显示栏也无法替代业务决定。 订单履约则要写到动作完成之后：谁确认价格，谁决定发货，数量变化由谁告知客户，财务依据哪份记录核对。需求描述应让没有参加讨论的人也能判断下一步该谁处理。

价格、库存与履约的资料来源

可回查材料包括现行价目、可售数量说明、订单样例和岗位交接记录。配置、接口与新增开发分别依据实际版本说明和项目约定确认。

价格条件现场

这张图对应调价又改量时，业务人员先确认价格依据的环节。

定制讨论可以分成四种处理方式

第一种是资料与规则整理。例如客户归属尚不明确，价格表缺少生效时间。这类工作应先由业务负责人完成，技术人员再判断如何录入或承接。 第二种是已有能力的配置。是否存在相关设置、设置能细到什么程度，需要用实际版本展示。不能因为别的系统有类似按钮，就认定当前方案也能通过配置完成。 第三种是系统之间的协作。若价格或库存由既有系统维护，就要明确需要传递什么、何时传递、由哪个方向发起，以及未完成传递时如何处理。这里讨论的是项目要求，具体接口条件仍需单独确认。 第四种才是新增开发。应写出新增动作、适用对象、触发条件、完成结果和后续修改责任。一个页面变化可能只影响展示，也可能改变价格计算或发货判断，不能只凭页面大小判断工作范围。

用八个问题圈定这次工作

需求疑问	企业先提供什么	方案中应确认的范围
哪些代理商使用特殊价格	客户名单与价格依据	适用对象及生效条件
调价是否影响既有订单	新旧价格与订单时间	调整范围及确认动作
对外库存从哪里取得	数量来源和计算说明	展示口径与更新时间
订单占用何时解除	取消或变更的业务规则	释放数量的责任位置
新字段是否参与后续处理	字段用途和使用岗位	展示、计算或流转范围
谁能改变发货数量	岗位权限及批准条件	操作限制与变更记录
既有资料怎样进入新流程	需要保留的资料清单	整理、迁移与核对分工
后续增加要求怎样处理	变更原因与影响对象	新增工作及费用确认方式

将云上订货作为备选方案之一时，可以围绕上述问题核对客户价格、库存口径和订单履约。订货前台、订单协同与ERP、WMS的职责需要分清；配置是否可行，以及接口、迁移、定制、部署和服务范围，都应以实际版本与项目约定为依据。 表格填写时，建议每项附上对应的业务样例。有明确答案的写明处理方式，需要进一步确认的保留具体问题；没有条件的项目不宜被一并写入“全部完成”。

范围讨论记录

记录要把配置、规则和新增开发分开，避免把同一句需求当成同一种工作。

从需求讨论到范围确认的四个动作

先选取企业实际存在的一组客户价格和相关订单，由销售解释规则，仓库说明可发数量，财务说明核对依据。各方只讨论这组材料涉及的处理过程，形成一份可重复使用的样例。 接着用拟采用的版本展示已有处理方式。每遇到一个差异，记录差异发生的位置，以及是业务规则待定、资料缺失，还是现有能力需要另行确认。不要把不同原因全部合并成“系统要改”。 然后逐条界定新增工作。比如新增字段，应说明谁填写、谁可修改、是否影响价格或发货、历史记录是否需要补齐。若仅提出字段名称，后续仍可能对用途产生不同理解。 最后由业务和项目负责人共同确认范围。将交付内容、完成条件、依赖资料、变更处理及费用口径写清。演示后新增的要求应记录影响，重新确认工作安排，避免一句“顺手加上”改变原定范围。

交付结果回看

回看时只确认已经落到责任人与完成条件的事项。

代理商下单常见问题

只有一个代理商提出要求，也要开发吗？

应先判断该要求是否属于可复用的业务规则。若只是资料不同，先核对资料处理方式；若改变了订单动作，再验证实际版本的承接条件。

增加备注栏和增加价格字段，讨论重点相同吗？

用途不同，影响范围也可能不同。备注要确定查看与保留方式；价格字段还要说明计算、权限和既有订单处理要求，不能只比较填写位置。

原有表格能直接当需求说明吗？

它可以提供字段和样例，但还需要补充使用条件。尤其是人工根据经验决定的部分，要写成明确规则，才能判断哪些工作需要系统处理。

跨系统传递数据一定属于定制吗？

不能预先确定。应结合实际版本、现有接口条件和项目范围核对，并写清双方需要承担的工作，不能把“需要协作”直接等同于某种实现方式。

需求暂时拿不准，可以先写进范围吗？

可以列为待确认事项，但要明确谁补充条件、何时决定。尚无处理规则的内容，不宜与已经明确的交付内容混写。 这种划分方式适用于已有稳定订货业务、能够提供价格与库存样例的企业。若主要规则仍频繁变化，宜先缩小讨论范围。定制完成后的维护、升级适配和新增费用，仍需另行落实到合同；一次范围确认只覆盖已经说清的业务条件。

机构说明：范围确认

先把一项需求写成“谁在什么条件下，要完成什么结果”，再决定它属于规则整理、现有配置、系统协作还是新增开发。这样下一次讨论面对的是可验证的业务动作，而不是一句笼统的“按原来做”。 文中出现的云上订货由深圳云上互联科技有限公司运营，提供 B2B 订货系统服务，涉及客户自助下单、订单履约和仓配履约。价格、库存、接口和维护的实际范围仍以企业确认的业务规则、版本说明和项目约定为准。