Infor ERP LN的数据表里的两个隐藏字段:T$REFCNTD和T$REFCNTU

拿Item General Data的Table – tcibd001举例,如果你在数据库里直接查询,你会看到两个字段:T$REFCNTD和T$REFCNTU,图示如下:

但是,如果从LN里面的ttaad4500看表结构,你是看不到的。

这两个字段有什么用呢?

refcntd – Referential Control Delete Mode
refcntu – Referential Control Update Mode

字段Refcntd存储一条记录的删除约束的数量
字段Refcntu存储一条记录的更新约束的数量。
只要通过Tools模块新增的表,这两个字段会自动添加到每个Baan/LN表中,您不必手动添加它们。

以下来自官方的介绍:

To guarantee referential integrity, the Baan/LN Database stores reference counters, which indicate how many times a record is used in a parent child relation. Since baan/LN can store each data in a several different database, we can not use the referential integrity mechanisms of the database itself. The field Refcntd stores the number of delete constraints to a record, the Refcntu stores the number of update constraints to a record. These fields are automatically added to each Baan table so you do not have to add them manually.

Only if the reference counter is zero, can the parent record be deleted.
Reference counters are only applicable if the Referential Control Delete Mode (refcntd) or Referential Control Update Mode (refcntu) in the relation is “Restricted (with counter)”.

为什么要说这个呢

重点来了,有时候,你需要从外部程序往Baan/LN的表写记录,那么就得考虑给这两个字段赋值的问题了。

别忘了在你的语句中增加这两个字段,比如:(T$REFCNTD,T$REFCNTU) VALUES (0,0)

至于为啥赋值为零,我这个新表其实没啥关联的表,那么都默认为0了。

好了,春节将至,特以此文收官祝广大Infor ERP LN/Baan战友们2021牛年大吉大利、身体健康、万事如意!

.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)
}

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

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();

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个供应商一致,类似交期、价格等。

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

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

其它我不知道的方法。

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

做一次知识搬运工: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

Infor Factory Track初印象

从多个渠道了解到Infor在Barcode,或者说WMS领域的产品Factory Track,但一直未看到过演示,也未体验操作过。近期在Jerry Huang的帮助下,终于一睹真面目。

先发个截图,需要更多截图,请加入我的知识星球:Infor ERP LN私房菜

目前有个直观印象,下一步想深入体验和研究一下,以下是我的一些感触:

亮点:

  1. 用户界面UI的确挺漂亮,特别是扁平化设计的各功能模块的图标
  2. 功能齐备:仓库的各种日常操作都可以在PDA手持设备上操作
  3. 实时通讯:与Infor ERP LN通过ION连接
  4. 独立部署:不需要跟Infor ERP LN安装在一起
  5. 兼容浏览器:相当于微信、手机自带的浏览器,那怕在平板或者电脑上都能使用用户端。

不足:

  1. 没看到原生的App,既然已经运行于安卓环境中,直接在浏览器中运行,那么很多硬件的功能就无法很好地使用,这点我想不通。
  2. 操作体验上,菜单和返回等明显太呆板,用过了微信,再用这种会发现一个返回、一个跳转就要多几次点击。

疑问:

  1. Infor官网看到Factory Track这个产品归类在Supply Chain Management,为何中文翻译为面对制造业流程自动化解决方案
  2. Infor Mongoose application development framework跟ION或本身LN的4GL相比,其定位是什么?

通过税改,看Infor ERP LN/BaaN的圈子氛围

前面发了2篇关于税改的文章,通过朋友圈发给自己的微信朋友们,同时也斗胆发送到几个自己所在的QQ群,通过各个群的一些反馈,从点滴中看到了目前整个圈子的氛围。

有些QQ群发了之后,就群主表达了欢迎之意,后面就没有人有任何反馈了;而有些群即便是有不少跟帖,但表现出的针锋相对、鄙夷、自信的确让人很费解。因涉及隐私,不便截图,就将一些QQ群的话摘录一下。

这个方案不靠谱,直接在国家税码中增加一个新税率就好,新税率的生效日期为2018-05-01

我的点评:我们不必因为自己公司的特殊应用,或未涉及的应用,而否定了别人的全盘周全考虑。但怀疑和否定的态度值得肯定!

可以直接将系统税码17的税率改成16,后台再修改名字,后台GTM修改名称把17修改为16

我的点评:这明显是IT技术思维,不是业务顾问的思考问题和解决问题的习惯。很多时候我们的确可以通过直接操作数据库来完成一些事情,但不到万不得已不能去用。应对税改的方案应该有很多,如果不放弃自己唯一的“后台思维”,怎能拥抱并拥有除此之外的N多个方案?

能不用后台改表不,我相信上面几个说的方案,运行一段时间后,系统会乱的一塌糊涂。别和我讨论这个话题啊。只有***给出解决方案是基本正确,有部分小瑕疵,不影响大局,其它都是错的。

我的点评:尽管我认同此人的“后台思维”,但并不表示你可以否定它。很多技术或顾问有个不好的习惯,不自觉的就以打击别人来提高自己,但殊不知:杀敌一千 ,自损八百的道理。还有,很多人愿意分享,不一定是因为自己非常强大才有资格分享,如果你真认为自己的方案更好、更完整,请多花点时间分享出来,不要费那么多时间去研究别人写得方案,而最终就是为了评价和贬低别人。

分享一下给我们啊,看不下去了

我的点评:真正的强者是可以接受别人的挑战的,如果自己技术和能力不行,多花点时间脑补,提高功力。激怒强者的结果未必好。但对于自高自大的强者,新人、年轻人其实无需畏惧,当你到了这个年龄,你会做得比他更优秀。智者千虑,必有一失;愚者千虑,必有一得。敢于挑战强者的勇气是需要的!

那些人直接通过GTM改的,是什么脑子哦

我的点评:虽然我也不认同直接GTM修改,但没必要通过这种损人不利己的话来显得自己的很专业,系统是人涉及的,熟悉业务的人,开发过这个系统的人,可以准确无误的仅通过数据库的操作来完成前台正常流程一模一样的数据。这并不为奇,同样我觉得这也是GTM存在的一个原因。

QQ群的交流,随着五一的来临还在持续,明显看出来,很多人看到上述的交流后,跟我有同样的感触,选择静默,继续潜水。

但我大胆呼吁:别人说得不全面,你可以补充;别人说得不对,你可以分享自己的做法;希望不管是甲方、还是乙方,不管是业务用户,还是IT用户,都能拥有包容和尊重的态度。

有一种理想的人际关系叫做:相互欣赏

即便我们做不到,但求同存异,共同发展,应该是我们的一致目标。

感谢你还一直看我啰嗦,那么最后来点干货吧,同时附上一张图,据说看懂得人都是聪明人。

关于采购订单和销售订单的税率的计算,以下是我的测试结果,如有异议,可自行测试。

采购订单上的Tax Amount是根据Planned Receipt Date(应该是Line的,不是Header的)来计算每个订单行所对应的税码在此时间生效的税率。

销售订单上的Tax Amount是根据Planned Delivery Date(应该是Line的,不是Header的)来计算每个订单行所对应的税码在此时间生效的税率。

如上图,5月1日生效的VAT17的税率为16%,那么计算的结果就是

800*0.16=128
43796.24*0.16=7007.49

如果不想批量改Open订单的Tax Code,并且Audit也没问题的话,用这个方法就行。不管你会不会用,反正我会用。

除了截图,我还附上一些代码,是通过Where Used Table Field 找到所有tcmcs032.edat的使用清单,逐个检查代码后找到的一个最简单的应用例子。估计能看此文看到这里的人都能看得懂:

function get.sing.tax()
{
	select	tcmcs032.*
	from	tcmcs032
	where	tcmcs032._index1 = {:tcmcs036.ccty, :tcmcs036.cvat}
	order by tcmcs032._index1 desc
	as set with 1 rows
	selectdo
		tax.rate = tcmcs032.pvat
	selectempty
		tax.rate = 0
	endselect
}

所以,税改的方案,每家公司都可以在自己的测试系统进行一些测试,省得盲信盲从。

比方说测试重点是老订单在新税率启用后,究竟如何操作的问题:你可以创建一些销售订单和采购订单,然后针对那个税码创建一个第二天生效的税率,接着第3天完成采购订单和销售订单的后继操作,看看到底税率和发票的操作有没有问题。

再假如说你要测试退货的问题,你可以选择一个老采购或销售订单,选择在第三天进行操作,就知道问题所在了。