.Net下请求Infor LN ERP WebService的5种方式

随着这几年Restful API的兴起,Web API遍地都是。以前老的WCF、WebService等的SOAP的份额越来越少。但总有些古老的应用或者企业级如ERP应用还是通过Web Service的方式提供对外集成接口。Infor LN ERP就是其中一个。

我这几年尝试了以下5中方法,与LN进行对接。

1、客户端代理类
2、动态代理类
3、WebClient
4、WebRequest
5、HttpClient

但前两种已经被我放弃了,后三种呢其实都是HTTP Request,通过标准的写法都可以很方便的与LN对接,注意两点:

1、拼接发起请求的XML
2、LN WebService返回500报错的时候,报错信息的转换
3、不要直接用using的方式使用HttpClient,因为由来已久的高并发时无法释放资源的bug,会让你崩溃。

至于后面三个方法,你可以从网络上找到一大把的Util/Helper类库,我就不贴出来了。

通过Infor LN ERP中的EAN字段来聊聊UPC和Code 128

很多人一提起条码(BarCode),我就犯嘀咕,因为我不知道他们每个人所表达的是否是一个东西。

因为条码实在太多了,一维的,二维码,图书的,行业专用的。如果打开BarTender软件,你会发现选择如下。而GS1只是GTIN是全球贸易项目代码(Global Trade Item Number)的一个数据来源而已。

我们常见的微信二维码用得是 QR Code,图书用的是ISBN,商场超市买的很多物品是EAN或UPC编码。

言归正传,在我们Infor LN ERP里面的General Item Data里面有个可以维护EAN的地方,截图如下,红色框里的按钮是我们的客户化定制,连接了一个Web,会自动传递当前的Item Code,如果未匹配过EAN Code,就会自动从已购买的清单里面分配一个,如果已获取就直接显示出来。这个Web页面后台有个数据库,记录着Item Code和EAN Code的一一对应,同时也有一个所有的EAN Code的清单,这个是从第三方机构付费购买的。

如果是美国的公司,这里的EAN Code大概率都是用UPC-A编码,因为UPC(Universal Product Code)码是美国统一代码委员会制定的一种商品用条码,主要用于美国和加拿大地区。

UPC条码也有标准版和缩短版两种,标准版由12位数字构成,缩短版由8位数字构成。

标准版的UPC12的编码结构为:系统码(1位)+厂商码(5位)+商品码(5位)+校检码(1位)。

后来随着欧洲、亚洲、澳洲的需求,增加了一位国家代码,就是第一位,UPC也变成了13位了。美国和加拿大的国家码是0。

标准版的UPC13的编码结构为:国家码 (1位)+ 系统码(1位)+厂商码(5位)+商品码(5位)+校检码(1位)。

而EAN(European Article Number)码是国际物品编码协会制定的一种商品用条码,已经在全球90多个国家和地区使用,通用于全世界。

分配给中国物品编码中心的前缀区间为690-696,再由中国物品编码中心统一分配企业代码,产品代码则由制造商根据规定自己编制。

贴一张最近在国内热销的酒精制品的商品条码图,你用微信扫一扫就能看到来自中国物品编码中心的查询信息。

标准EAN13编码结构为:国家码(2/3位)+厂商码(5/4位)+商品码(5位)+校检码(1位)。

对比一下EAN和UPC的编码,你会发现这两个条码简直一模一样,宽度、高度、条码粗细,位置。不同处是
1、EAN把国家码打在左侧条码内外侧,而UPC是只讲国家码打在条码外侧
2、而最后一位5,EAN打印在条码内测,UPC打印在外侧。

所以当你看到左右两侧都有数字的时候,就是UPC码,卖到美国和加拿大的。

再回到上面看我贴得医用酒精消毒棉片,看看到底是UPC还是EAN?

因为EAN码是在UPC码基础上形成的,所以,在技术上EAN系统的光电阅读器可以阅读UPC系统的条码,而UPC系统的光电阅读器却不能阅读EAN码。

从位数上看的出区别,所以美国亚马逊的商品默认用UPC的话,一旦要上架到欧洲市场,就可以简单的在UPC编码前增加0变成13位的EAN码即可。

亚马逊规定,要在亚马逊上传商品每个商品都需要相对应的条码,UPC码或者EAN码都行。当然了EBay也有同样的要求!中国区的用户可以去亚马逊官方指定的供应商购买,网址:www.barcodestalk.com。

上面是大概的价格,当然购买中国区的到中国物品编码中心官网: http://www.ancc.org.cn/ ,价格上除了一次性加入费用,还有胶片制作费和系统维护费。

说了这么多了,你对EAN和UPC的定义、差别、价格、用途等都了解过了,再来看下Code 128,这个其实在我们仓库、生产运营中更常见,我们常见的生产工单、料号、数量、批次、波次等信息大都用这种条码形式来打印。最普通的扫描枪也能识别这个条码。Code 128可以接受标准数字和大写字母,小写字母,特殊字符,所以除了在企业内部管理,在物流、仓储领域应用非常广泛。

到此为止,我们把Infor LN ERP应用最多的条码就介绍完毕了,如果你还有其它问题,欢迎留言探讨。

Infor ERP LN有用的Session whinp1200m000: Rebuild Planned Inventory Transactions

在仓库的Inventory Planning模块,可以看到Planned Inventory Transactions(whinp1500m000)可以看每一个Item Code在某个仓库的计划进出状态及明细,当然了这里的数据也会反映在计划模块的Item Order Plan(cprrp0520m000)上,但有很多时候,因为网络中断或者其它原因造成在其它业务模块所操作的订单,未能正确的在此处进行必要更新,就造成了不同步。

比方说采购员取消一个采购订单行的时候,如果订单行取消成功了,但此处未更新,就会造成看到还有一笔Open的待收货订单,当然了跑MRP的话,也会根据此错误信息来下采购单。

其实很多时候,我们应该用事务处理,就是一旦失败,就回滚操作,但因为业务逻辑太复杂,此处并未使用事务操作。正因为如此,才有了一个标准的Session – whinp1200m000,你可以通过这个Session来模拟运行来检查一下你公司的系统数据时候有问题。

注意这里有个选项:Update Mode,默认是模拟Simulate,如果要修正数据记得勾选为Update。

Infor ERP LN/BaaN中Economic Stcok的计算公式

闲来无聊,问了几个同事,居然没有一个答对的。

有的说Economic Stock需要考虑Inventory Blocked,有人说需要考虑Committed(上图没有显示出来,因为默认不显示,而我们公司在用Commitment),核心的On Order和Allocated是大家公认的。

于是花了几分钟从代码中找到正确的公式: Economic Stock = On Hand + On Order – Allocated

function calculate.total.fields()
{
select sum(whwmd215.qhnd):cum.stoc, sum(whwmd215.qall):cum.allo,
sum(whwmd215.qord):cum.ordr, sum(whwmd215.qblk):cum.blck
from whwmd215
where whwmd215._index2 = {:whwmd215.item}
selectdo
cum.econ = cum.stoc + cum.ordr – cum.allo
selectempty
cum.stoc = 0
cum.allo = 0
cum.ordr = 0
cum.blck = 0
cum.econ = 0
endselect
display.total.fields(
“whwmd215.qhnd”, cum.stoc,
“whwmd215.qall”, cum.allo,
“whwmd215.qord”, cum.ordr,
“whwmd215.qblk”, cum.blck,
“econ.stock”, cum.econ,
“tcibd001.cuni”, tcibd001.cuni)
}

发现越来越没追求了,静搞些初级的东西。

每个甲方的Infor ERP LN/BaaN从业者必读:《掌控你的ERP命运》

估计来访的朋友中甲方的占多数,推荐一本书《掌控你的ERP命运》,文中的很多观点我很认同。

首先这是一本站在企业角度来探讨ERP实施方法的书,并非单纯的技术图书。

说得直白一点,这本书有助于甲方的IT从业者,学习如何甄选ERP产品以及有高效的与第三方顾问公司的协作。

想把ERP项目做好,需要做好大量的工作,比如搭建好组织架构、做好知识转移、做好软件选型、用好外部顾问、培养好内部顾问、制订好进度计划,以及做好系统分析、系统设计、系统建设、系统测试、系统切换等。对于这些工作,企业只要有一项没有做好,那么实施与应用ERP的效果就会大打折扣。

这本书是2016年出版的,来自美国的Steven Scott Phillips(史蒂文·斯科特·菲利普斯) 著,吴学强翻译。

京东配送的购买地址:点击这里

C#访问SOAP Web Service时500报错后的返回信息获取

调试Infor ERP LN Web Service的时候,你会发现如果调用不成功,返回的Http Header是500,但用SoupUI还是能看到结果返回,是不是很诡异。

因为这个东西,曾浪费了好几天,换了多种方式调用Web Service:引用、静态、动态、HTTP Post都试了。最后用Fiddle监控本地服务,然后开SoupUI代理,获取到下图。

这就造成了当使用HttpWebRequest访问时,不成功就会出现System.Net.WebException: ‘The remote server returned an error: (500) Internal Server Error.’报错(如下图),获取不到结果了。

怎么办呢,这里只能通过获取异常,然后将异常的相应结果返回。

用下面的代码就不论500错误是否发生,都能获取到Web Service返回值的源代码。

            //500 error but get the message
            HttpWebResponse res;
            try
            {
                res = (HttpWebResponse)webRequest.GetResponse();
            }
            catch (WebException ex)
            {
                res = (HttpWebResponse)ex.Response;
            }
            StreamReader sr = new StreamReader(res.GetResponseStream() ?? throw new InvalidOperationException(), Encoding.UTF8);
            var result = sr.ReadToEnd();

H5 WebApp禁止Webform页面回发

前一阵写一个H5的WebApp,用得老技术Webform,然后找人封装一下,优化一下WebView等,主要是实现运行于安卓系统的PDA能很方便的查询库存、进行库存的收发操作。

其中有一个扫码查询,允许用户手动输入,针对input textbox做了onchange事件,但是提交就会出现一个页面自动回发的问题。

用了比较原始的方式:

1、先给页面的表单设置DefaultButton(这里设置的是btnSubmit)。作用是:回车时会以该按钮被点击来提交表单进行回发。

<form id="form1" runat="server" defaultbutton="btnSubmit">

2、为btnSubmit设置Enabled=”False”。作用是:回车后发现btnSubmit不能使用,所以这次提交也就不能成功了

3、如果不想看到这个btnSubmit,就加上样式style=” display:none”进行隐

好了看一下截图吧:

Infor LN ERP中1个物料2个供应商同时供货,不分配采购订单

概念:
Sourcing percentage – A percentage used to calculate how orders are divided among suppliers.

故事背景:

供应商 A,Sourcing Percentage: 60%,MOQ: 25,Lead Time:90,Priority:999,供应商状态正常,没有特殊设置
供应商 B,Sourcing Percentage:40%,MOQ:30,Lead Time:90,Priority:999,供应商状态正常,没有特殊设置
大概1年前修改为此设置,从那以后,订单再也没有分配给B。

数据分析:

拉出采购订单明细,发现几十个采购订单下单数量最多时才65个。

原因分析:

假设订单量为100,那么A分配60,B分配40,并且都大于各自的MOQ,可按照预期下单。

假设订单量为20,那么小于任何一个供应商的MOQ,没办法生成订单。

假设订单数量为50,那么A分配30,B分配20,但B的MOQ为30,无法下单,只能全部下给A,50个。

原理分析:

但从数量上来看,要做到能够按照设定的比例分配数量,那么需求数量的最小值应该为:MAX(30/40%,25/60%),即75个。

解决办法:

理论上一个产品的最小订单量可以谈到2个供应商一致,类似交期、价格等。

当订单量小于允许分配的最小分配量时,两者优先级设为不一致。

从源头控制,针对需求和预测,做到订单数量可被分配。

其它我不知道的方法。

可能通过这种思路也无法解决,只能改变模式,分周期设置主供应商。

有空加一下

近期被多人在微信、QQ问些Infor ERP LN问题,最后不欢而散。

问得人觉得,他很客气和礼貌的询问了我是否有空、是否愿意回答,觉得理所当然。而他们不知道,我碍于面子,没有直接回绝。

当我问对方是否加入了我创办的Infor ERP LN私房菜的时候,对方居然都会有一样的回答:有空加一下

看到这句话,我知道他不会加入,哪怕免费都不会。因为有些问题,我让他看我博客的分享,他都不愿意行动。

他以为我是要他的99元终生的会费,他不知道的是我在评估自己:看我义务回答了问题的时间,对别人是否有价值。

我坚信自己所做的事情是有价值的,相信只有你产生了价值认可,彼此才会共享价值。

从今以后,不再理所当然的回答任何人的LN问题。我会说:有空回你

不是我吓唬你,还没加入的,赶紧啦!

 

做一次知识搬运工:Infor Mongoose Hello World官方培训视频

上周开始看Infor Mongoose这个开发平台,所幸YouTube上有官方的公开培训视频,为了方便国内的战友们,当一次搬运工,陆续会将以下视频放到腾讯视频(这其实应该是Infor China市场部应该做的事情)。

目前已完成Infor Mongoose的入门课程,对应英文Infor Mongoose Hello World,共7个视频,请猛击:http://v.qq.com/vplus/82eb992d15c8acd8a25e9827b38c171e/foldervideos/fq5002901feth6d

还有4个视频专辑已下载,陆续找机会上传,分别如下:

  1. Infor Mongoose Developer Demo
  2. Infor Mongoose How To Videos
  3. Infor Mongoose 101
  4. Infor Mongoose Introduction