金蝶云星空(K3Cloud)中的核算维度

朋友公司在用金蝶云星空,他需要将凭证数据通过OpenAPI的方式下载到本地数据库,以便后续的一些业务分析,这个下载的接口对接起来挺方便的,轮训自增Id(作为凭证号)去获取每个凭证的数据和分录。其中有用到核算维度,这个概念跟Infor LN ERP财务模块中的Dimensions是同样的概念。

以下金蝶运行接截图均来自网络

01015b97af3420464cd0bef3eea136410df0.png

自定义核算维度后,关联到科目,并指定是否是必填。

Infor ERP LN中序号被占用怎么解决?

如果你遇到系统断线等异常情形,可能会出现如下类似的报错。

大概的意思是某个号码被占用了。

以前的BaaN 5时代可以直接找到First Free Number这个Session,在LN中需要从Numbers Group的Session中找到相应的序列,并修改其First Free Number。

Infor LN ERP在线帮助、用户手册

又有新同事来问我有没有LN ERP的宝典,可以学习一下的。

除了让他看已经录制的微课短视频以外,还提示他善用F1来看实时的帮助文件。

最后我推荐他到Infor的官方网站来看Infor Documentationhttps://docs.infor.com/zh-cn/,这里以中文版为例,登录进去以后长这样:

然后选择ERP & Finance下的LN

这时候,你可以选择合适的ERP版本了,截止发文时间,默认是CE

你会发现有3个链接,分别对应

Infor LN UI 用户手册简体中文2021-04-29
Infor LN 联机帮助简体中文2021-07-13
Infor LN Documentation List CEEnglish2021-07-02

我们切换到10.4,也是我现在用的版本

Infor LN ERP 10.4在线手册:https://docs.infor.com/zh-cn/ln/10.4

当然了你还可以切换到其它版本,我都帮你列好了!

Infor LN ERP 10.7在线手册:https://docs.infor.com/zh-cn/ln/10.7

Infor LN ERP 10.6在线手册:https://docs.infor.com/zh-cn/ln/10.6

Infor LN ERP 10.5在线手册:https://docs.infor.com/zh-cn/ln/10.5

Infor LN ERP 10.5在线手册:https://docs.infor.com/zh-cn/ln/10.3

非常规方式处理Oracle+.NET开发全球化的时区显示

咨询了几个大牛有关.NET开发中全球化的时区显示问题,大家的意见有三个:

1、使用UTC Time记录到数据库,展示的时候根据用户所选择的时区进行转换展示
2、使用固定时区DateTime记录到数据库,展示的时候根据用户所选择的时区进行转换展示
3、记录timestamp到数据库,选择DateTime.UTCTime转为秒或毫秒级别的timestamp,展示的时候转为时间类型,并根据用户所选择的时区进行转换展示

大部分人喜欢1,其次是3,最后是2

而我今天要分享的这个Oracle数据库下的开发,有个前提就是我不能修改数据库,也不能修改写入数据库的时间是指定时区的,因为Infor LN ERP中更新此时间字段,幸运的是它本来就是UTC Time。

但是呢,我不能直接用第1条方案,因为我有些筛选条件,根据用户的日期(时间)还需要筛选数据,那么我不想:既修改展示阶段的时间时区,又修改查询时候的输入时间。

于是就有了今天的非常规方案:sessiontimezone

当我们在Oracle数据库中执行以下SQL时,可以知道数据库的时区和我当前连接的时区。

SELECT BTIMEZONE,SESSIONTIMEZONE,TZ_OFFSET(DBTIMEZONE),TZ_OFFSET(SESSIONTIMEZONE) FROM DUAL;

那么我们就可以使用:TO_NUMBER(SUBSTR(TZ_OFFSET(sessiontimezone),1,3))/24,来动态的展示当前连接所在时区的时间了

SELECT TO_CHAR(A.T$CNFT + TO_NUMBER(SUBSTR(TZ_OFFSET('" + GetUserTimeZone() + "'),1,3))/24, 'YYYY-MM-DD HH24:MI:SS') AS ConfirmedTime FROM MYTABLE A

此处的GetUserTimeZone就是根据当前用户的市区设置,读取到一个“-5:00”或”6:00″形式的TimeZone。

至于用户的时区是根据用户所属的国家来还是根据用户的个人设定,这里的逻辑可以灵活设定优先级。

虽然非常规方案可以满足需要,但是不具备普遍性,性能上也会很依赖Oracle数据的配置。

如果您碰巧也有类似的场景,不妨试试这个方案。

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牛年大吉大利、身体健康、万事如意!

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

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

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

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

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

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

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

通过税改,看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天完成采购订单和销售订单的后继操作,看看到底税率和发票的操作有没有问题。

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

重磅:增税改革Infor ERP税率调整方案及相关税务处理建议

自4月12日《制造业增值税降低,Infor ERP LN中税率调整的注意事项》发布后,我一直等待着Infor官方的消息,至今未看到。但可喜的是看到来自拓创,这家圈内很有名气的Infor ERP咨询顾问公司的一篇公众号文章,介绍LN和BaaN 4的调整内容和修改方案,还有政策解读和财务层面需要多注意的事项,真得要赞一个。

忍不住贴一张图,更多详情请访问:《增税改革Infor ERP税率调整方案及相关税务处理建议

一段思考,鼓励自己,也希望可以帮助到一些人

近期跟10多年前就就久仰大名,加了电话到通讯录,却从未谋面的BaaN圈内知名人士、创业者熊宇,终于有了第一次面对面交流。其学业和职业的发展经历甚是与众不同,更加不同的,可以说是独特的是其创业的初心、对企业的定位、人生的理解。短暂相聚,未能尽兴,虽说几个小时的聊天,那些紧张、惊险、曲折又生动的经历足可以写一篇上万字的杂记,但我觉得还是需要去花更多时间,去写一篇关于他的更加专业的人物访谈。今天就写点,通过此次交流,带给我一些新的思考。

如果你无路可走,你会拼命寻找出路;

如果你只找到1条路,你会毫不犹豫的走下去;

但如果你有2条路可走,你一定会犹豫,到底选择走哪条路好。

成功一定有方法,失败一定有原因。

成功者的道路都是相似的:想法 》行动》挣扎》突破》成功

大多数人在挣扎过程放弃,放弃的原因不是真的坚持不住了。

是禁不住诱惑,转行了。

我们都会犯这样的错误,得不到的永远是最好的,其他行业都比我们从事的好。

做.NET遇到瓶颈了,发现当下Java工资更高,PHP更流行,Python更热门,就转型了。

做Infor LN /BaaN ERP,发现SAP不错,Oracle不错,干了没几年就放弃LN了。

做传统制造业太压抑了,没啥前景,互联网行业自由发展快,跳槽去做互联网了。

做了之后才发现到处是坑,然后就像兔子一样在各个不同领域跳来跳去,想找一个没坑的,工资高的,升职快的,赚钱容易的,直到一事无成。

机会越多不代表越好,最难的是保持专注,我过去10多年随接触领域和行业颇多,也做了不少尝试,大家可以通过博客了解到,但我的职业从未离开过Infor LN/BaaN ERP,从未离开.NET,未离开Web,从未离开制造业企业信息化。

虽然我积累的速度慢,但在这2个领域,再持续努力个几年,加上中国制造2025的到来,我相信届时不成为此方面的专家、大牛也难。

就像熊宇所创立的指北,从2001年的13家BaaN咨询顾问公司,到如今全中国才只有3-5家。大浪淘沙,现在还在坚持着的,本身就已经是成功。我很感谢熊宇所说的一句话:你能坚持10多年在写博客,本身就是中国Infor LN/BaaN ERP自媒体传播第一人了。

不管这句话是否是恭维,但我相信,从这个月初我重新定位博客和Infor ERP LN私房菜知识星球,并提出这个目标开始,我已经走在路上。无非是坚持的问题了。

我认为:自媒体的能带给大家的最大价值就是传播价值,虽然我可以创作有价值的分享,但去传播那些乐于分享的人、以及其自己的经历、经验、闪光点,才更有价值。

我相信:只有自己相信,才能更可信,才有人愿意追随、愿意支持你。