WMS的查询分析改革
客户每次有一个问题的订单或者lpn条码;
我们自己往往也要分析半天(可能要1分钟以上),才能给出结论,
要查询订单信息,任务信息,接口信息,日志信息等;
作为开发者本身,都分析的如此麻烦,那么你怎么能保证客户能够迅速分析呢,
如果你自己都要花费数分钟,客户自己分析岂不是要用上半小时;
1.我们上网用的最频繁的网页时什么,也许是“百度”吧。
所以我们对于查询分析,为什么不借鉴百度的做法;
就一个统一的文本查询框,可以输入 条码,订单,SKU编号等,系统自动识别输入的类型;
如果是条码,系统就会把条码相关的信息列出来;
比如:
1.该条码是否在货架上,如果是,在哪个位置;
2.该条码是否在输送机上,如果是,在那个地方;
3.该条码对应的sku是什么,多少数量,所属订单是什么,订单当前什么状态;
4.该条码当前有没有任务,如果有,目的地是哪里;
5.该条码最近发生的日志信息;
....
如果是订单,会显示:
1.该订单是上位系统什么时候提供的;
2.该订单已经执行到什么阶段,其各个订单行执行的情况各是什么;
3.订单所对应的各个LPN条码所在位置;
4.订单和上位接口交互的日志信息,和自身操作的日志信息;
...
如果是SKU,会显示:
1. 在库里面占用多少货位,总数量;
2.当日的入出库数量;
3.正在输送线的含有该SKU的lpn是那些;
4. 含有该SKU的执行中的订单有那些;
.............
这样就类似珍珠项链一样,用一个绳子把所有的珠子串起来;
而且由于是类似百度网页的,查询 LPN条码的时候,会显示对应的订单信息,这样显示的订单号可以高亮带链接,
点了订单号,就会直接进入订单号的分析页面;订单号分析里,又会显示相应的LPN ,点击该lpn,又会继续分析;
所有就有点“联想”分析的味道;非常方便,适合傻瓜化分析;
2.单层列表太单薄,嵌套联想多层类表带来很大的分析便利性;
我们现在做的大部分都是单列表查询,每次查询往往只能显示一个列表,信息“很单薄”,要分析一连串的信息,往往辗转于多个查询,
为此,像笔者这样的老年人,就经常查询的眼花缭乱,到处切换查找;一天工作下来,就协助客户分析问题,头都查昏了;
痛苦了这么多年,早就想在各个列表里,都增加了嵌套列表的连锁联想查询;最终今年年初实现了这个功能;
1个主列表下可以嵌套多个分列表查询,
当然一个分列表下可以继续嵌套下去,实现多层子列表联想查询,这个如今还没精力去做,应该实现不难;这种嵌套联想子查询非常实用;
有了这种嵌套联想查找的设计,分析问题,再也头不昏眼不花了,一口气走上5楼也不心跳了;
3.拼音查找
汉字输入就是麻烦,像我们天天守在电脑旁的人,查询起来都嫌麻烦;
现在所有的手机,都支持拼音查找吧,而且全拼或首字母简拼都支持,你要给谁打电话,不会真的敲入汉字去找吧?
当然现在是手机互联网时代,手机厂商能不注重用户体验吗?
按说,电脑上开发,要比手机丰富的多,所有我们在电脑上查询,不做拼音的查找,真是没天理啊.
这个简单的功能,目前还没有做成通用的框架,自己一直在使用自己做的一个工具,一直没这个拼音查找, 实在忍受不了,就改了:
(缺图)
但愿以后再WMS也能到处做到拼音查找(除非你不用中文),可能有的设计人员不屑于这种便利性的改进;
不过客户有的时候不就是看你系统使用的方便性吗;
现在互联网的大佬们无不把用户体验上升到产品制高点的位置;
2021-03-31 15:31