做企业信息化选型时「订货系统」是最容易被功能表带偏的一类产品。功能列表几乎每家都差不多商品管理、订单管理、库存、报表、小程序商城……真正决定成败的不是这些名字而是底下几条口径约定得清不清楚。这篇文章把踩过的坑整理成八条可执行的检查项供做选型评估的同行参考。一、先定「一客一价」的数据模型别急着上功能多级经销商的定价从来不是一张价目表。至少会同时存在四种价格来源1. 等级价按经销商等级统一给价2. 客户指定价单个客户单独议价3. 阶梯价按订货量分档4. 促销价限时限量问题在于优先级。如果系统没有明确「同一个商品同时命中等级价和指定价时谁生效」业务员就会在群里反复问价系统上线了也等于没上。选型要看的是这四类价格能不能在同一个商品上共存、冲突时规则是否可配置、以及手机端能不能改价很多系统只允许 PC 端设置指定价业务员在客户现场就没法处理。## 二、订单状态机要和财务口径对齐「已取消的订单算不算应收」——这一个问题能暴露系统的成熟度。常见情况是对账总表统计的是实际发生的收款而订单应收的导出把已取消订单也算进去两边数字对不上。如果账期内有取消订单差额通常正好等于这些订单的应收金额。所以评估时要追问订单状态有哪些、每个状态对库存和应收分别产生什么影响、导出报表时按哪个字段截取时间区间下单时间还是收款时间——跨月订单会落到不同账期。## 三、库存要区分「可用」与「占用」下单即占库存、还是付款才占库存超卖谁负责多仓场景下拆单规则怎么写这几条不定义清楚上线后就会出现「系统显示有货实际发不出」。多仓还要额外确认拆单是按库存所在地自动拆还是按配送范围拆以及拆单后运费怎么算。## 四、资金侧账期、信用额度、与支付通道的边界有账期的客户系统要能控制「超额不能再下单」。同时要分清两件事-系统内的应收应付是业务账-银行侧的账户状态是资金通道的事后者经常被误认为前者。举例下游客户开通云资金时提示「存在安全风险」绝大多数不是系统权限或资料问题而是该客户在银行侧的二类户长期没有交易往来、被判定为不动户后拦截了开户动作。这种提示只能由客户本人去银行侧解决业务员反复点「重新提交」没有用。知道这条边界在哪能省掉大量无效工单。## 五、权限模型按角色还是按数据范围只分「管理员/业务员」是不够的。真正需要的是数据范围权限业务员只能看到自己的客户和价格区域经理看本区域财务看全部订单但改不了商品。评估时用一句话测试能不能让「A 业务员看不到 B 业务员的客户价格表」。这是团队扩张后最容易出问题的地方业务员离职带走客户和价格表往往就是这里没管住。## 六、小程序商城不是「再做一个前端」订货小程序和零售电商小程序的产品逻辑不一样- 零售看转化率订货看复购效率- 零售要商品推荐订货要按客户显示不同价格- 零售下单即付款订货要支持账期与线下结算所以要看商城和小程序是不是共用同一套价格与库存口径。如果各管一套就会出现小程序显示的价格和业务员报的价不一致——这类问题在客户那里是信任事故。## 七、报表能不能导出「可核对」的明细报表的价值不在图表好看而在能不能和财务对得上。至少要能导出订单明细、收款明细、发货明细、以及按客户/按商品的汇总且导出字段口径与系统内一致。顺带提一个细节运费这类费用能不能按月导出汇总直接影响物流成本核算的准确度。## 八、实施与售后谁负责数据迁移上线失败八成都不是软件问题而是数据没准备好就开跑。正常顺序是先导商品再导客户最后导价格价格没确认就导订单后面必然返工。所以要提前问清实施方负责到什么程度、数据迁移谁来做、培训几次、上线后多久算验收。选型时把上面八条做成一张表逐项让对方给出具体口径而不是「支持」。凡是答「都支持、到时候配一下」的大概率意味着需要定制开发。—上面这些口径是我们在做订货系统实施时反复遇到的问题。订货宝目前有 800 万 使用用户覆盖 25 行业23 个城市有服务网点。如果是渠道分销、连锁供货这类场景需要看具体的价格体系与对账方案可以参考订货宝服务官网按行业整理的落地方案与常见问题。选型这件事问对问题比看对功能表更重要。
