农产品的商品普遍存在不同客户不同名称不同价格,如果用原来的sku一条一条维护,那就有几千条商品,维护工作量大。
eg:针对同一个商品“赣南脐橙”的不同卖法举例:
赣南脐橙 | ||||||
---|---|---|---|---|---|---|
规格 | 客户 | 销售价 | 订货单位 | 结算单位 | 单价 | 销售名称 |
礼盒装4斤装 | 小王 | ¥40.00 | 件 | 斤 | 10.00/斤 | 赣南脐橙送礼精选4斤 |
礼盒装4斤装 | 小张 | ¥50.00 | 件 | 斤 | 12.00/斤 | 赣南脐橙精选4斤装 |
10斤装 | 小李 | ¥30.00 | 斤 | 斤 | 3.00/斤 | 赣南脐橙 |
10斤装 | 小马 | ¥27.00 | 斤 | 斤 | 2.70/斤 | 赣南脐橙 |
以举例来说,小王和小张是企业客户,订货的赣南脐橙用于节假日员工水果福利,这部分客户会下单礼盒装的赣南脐橙,小王的订货习惯是下单100箱,小张下单50箱,那自然小王和小张享用的单价也是不同的。小李和小马是门店客户,订货的赣南脐橙主要用于零售销售,下单通货10斤/框的赣南脐橙,小李的订货习惯是下单20框,小马下单10框,同理小李和小马享用的单价也是不同的。
这是最简单的一种场景,有4种卖法,实际情况中卖法更多,客户更多,让使用者建立4条商品信息,然后针对每一条进行定价这种方式显然是不合理的。针对多条规格,如果用原来的通用属性和属性值来对这个赣南脐橙进行多规格的划分,比如礼盒装、通货、显然也是不合理的。举个例子,如果有礼盒装5斤,通货10斤框,通货20斤框,那我必须现在属性值里面建好,然后赣南脐橙来关联,如果此时商品是巨峰葡萄礼盒装3斤,这样做就无穷无尽了。
所以我的思路是赣南脐橙建立自己的多条规格和卖法,商品-规格-单位形成一个sku,针对客户组进行定价和销售名称的设置,定价在后面的价格里面详细说。
库存预警数:原本我是不考虑做的,农产品以销定采,今天进今天出,设置库存预警提醒提前备货的意义何在?后来在调研一间仓库后发现他们会提前备一些调味品、干货、饮料。针对这种耐存放的标品,设置库存预警提醒采购员备货。
采购参考系数:推荐采购数量=采购数量+采购数量*系数,这个系数听上去很智能,减少损耗,实际上没人会参考这个系数,该采购多少,比原采购数量超出多少,采购员心里门清,他们有大量丰富的实际经验,不需要系统来推荐,这种完全用不上的功能就不要做了。
发货参考系数:推荐发货数量=订货数量+订货数量*系数,这个同上,分拣人员也有大量丰富的实际经验,不需要系统来推荐。