楼主，ERP没这么简单。即使抛开你描述和别人理解上的偏差问题，这个建议也有许多需要商榷的东西。 比如说，首先你没有界定，这订单是门店下给供应商的，还是物流中心下给供应商的，这两种订单关注的业务重点是有不小的区别的。 如果是门店，这门店是大卖场、标超、专卖店，还是便利店？业态不同，下订单的方式也会有很大差异。 如果是物流中心，这次的订单是基于新品的、促销品的，还是正常销售的老商品的，订单制作时关注的重点也会有差别。 另外，你经营的商品中，有没有季节商品？如果有，你列出供应商和部门后，两百种商品可能有150种都不在季，你看着都烦吧？ 还有，要货为什么要有部门限制呢？部门就那么重要吗？流程就不能优化下吗？你第一天给供应商的A部门商品下了5万块的订单，转天又扔一张订单，让他给B部门送50块的货，第三天在给C部门送100块……，他不骂死你(⊙o⊙)，你说我要按部门收货，那你一次要货，然后自动分单收货不就完了？ 如果你说，我完善下我的建议：不在季商品不列出来，可以了吧？ 呵呵，没有！这事儿没完的。如果有200种商品，你这次只希望补25种，翻来翻去的找，你烦不烦？ 你可能又说了：我再完善下我的建议，需要补货的25种列出来，其他的不列。呵呵，这事情可就大了去了，你就看着一帮ERP厂商哭吧。哪儿有那么容易的事哦？这是智能补货，说起来容易，真正要在企业里实行，没个一年半载，门儿都没有。即便花了时间，即便花了大价钱，即便公司上上下下闹得鸡飞狗跳，怨声载道，加班加点的做数据分析和初始化工作，最后真正适合智能补货的商品也不是全部，能有40%算不错了，当然这个也要看业态，如果是服装业，那直接就悲剧了，根本没用。 可能还可以完善，…… 但这功能如果真经过如此这般的一番“完善”，它还叫“订单”吗？这个“订单”功能，他究竟是给企业里哪个岗位，什么业务能力和知识背景的人用的？想清楚了吗？ 其实这建议最大的问题，是考虑功能的出发点局限在了“方便”，而没有基于真正的“业务”需求。并不是“方便”不重要，但一要注意层次和业务背景，二要考虑矛盾的主次。 ERP软件的功能设计，优先考虑的是分析和解决业务问题，有了这个正确的功能框架，才能谈框架内的便捷。比如6楼提到的生鲜商品下订单，往往需要变价。如果仅仅是为了这点事，何必把所有商品订单都撕开一个能变价的口子呢？单独提供一个“生鲜订单”功能就可以了。还方便权限的监督和控制。 还有因为质量问题而需要变价，那考虑了要记录变价原因的因素了吗？你可能说：记到备注里吧。但记到备注里能方便统计吗？供应商考核模块缺了这个原始数据，怎么办呢？另外，这批货有质量问题，难道也要按正常商品价格卖吗？有人可能又会说，那再加一个变售价的“快捷”功能吧。嗯，我再给你补充一个：还要再加一个自动打印变价签的功能，更好。是吧？ 是什么呀！全乱套了！事前的申请、审批在哪里？事中的审核在哪里？事后的稽核在哪里？或者最起码的紧急审批，总该有吧？ 你看，也许我说的细节并不全对，但至少问题并不象看上去那么单纯，是吧？一个小小的“能否变价”，虽然从技术上很简单，在某个朦朦胧胧的厂家业务代表的苦苦哀求下，某个懵懵懂懂的软件工程师，可能顺手就给你改了。但业务体系上却已经埋下了隐患。如果一直照这种思路去建议和修改ERP，最终的结局无论对零售商还是对软件商，都将是一场灾难。 这就是先考虑业务需求，尤其要分析“需求背后的需求”，再考虑不同业务场景下，如何具体优化的重要意义。 | 
