如果你近期看到这个帖子,请直接扫码免费加入我创建的小密圈,已发出邀请给多位国内的BaaN (ERP LN)大咖作为嘉宾做客。
如果二维码失效,请先加我给我,可能需要付费加入了。
如果你近期看到这个帖子,请直接扫码免费加入我创建的小密圈,已发出邀请给多位国内的BaaN (ERP LN)大咖作为嘉宾做客。
如果二维码失效,请先加我给我,可能需要付费加入了。
这是10年来最严重的LN停机事故,写下来给所有LN开发、管理人员。
Before making any changes, make sure you have a system/database backup so that it can be restored in the event there are major errors. Anytime you work with table definitions/changes, there exists the possibility of data loss.
Before setting the new table definitions, have all users out of the system, then do a convert to runtime with wide open range to make sure all existing pending changes (such as those from PMC solutions) have been completed. Then log out and back in.
Then define your new table and references and convert to runtime again so we know it is just these new changes being converted. You will want to convert at the very least both the new table and tccom001, but ideally open range again.
If you do get errors when converting to runtime, stop working with the runtimes and stop trying again. (call Infor immediately. If you run convert again after the failure, you could overwrite the log files and prevent us from debugging the error.)
If you have no Infor support, and still get errors when converting to runtime failed many times, you should restore the system/database immediately.
今天说一个典型的应用:外协在购订单上的料号是一个SUB的专用料号(每家外包供应商一个),如果想知道这些采购订单对应的成品和数量,就得自己弄报表来实现,下面是关键代码。
function get.production.order.and.part.numnber()
{
select tdpur402.*,tisfc001.*
from tdpur402,tisfc001
where tdpur402.orno = :tdpur401.orno
and tdpur402.pono = :tdpur401.pono
and tdpur402.pdno = tisfc001.pdno
order by tisfc001._index1
selectempty
tisfc001.pdno = ""
tisfc001.mitm = ""
endselect
}
直接上图吧,看懂的人自然能看懂。
需要通过GTM工具修改数据。
Table whinh312
Field pmsk
before:nennnnnnnnnnnnn
after:neyynnnnnnnnnnn
Field acti
before:-
after:whinh3201m000
Table whinh210
Field pmsk
before:nennnnnnnnnnnnn
after:neyynnnnnnnnnnnn
Field acti
before:-
after:whinh3201m000
今天去参加了2016上海Tableau的年度峰会,感触颇多。开始之前,先说一点激励的体悟,一个公司有时候因为整体行业形势、个体业绩等原因造成大环境没有升职加薪的机会,这点任何部门、任何人都没有机会的时候,如何留住团队的骨干就涉及到激励。有时候除了加薪、升职之外,还有荣誉奖励、培训、接触行业动态机会等。如果你也做领导,记得尝试一下这些方式,如果你站在普通员工角度考虑,不妨利用好机会,把去抱怨的时间拿出来给自己充电、提升自己的价值,那么终有一天,你的价值会体现出来,不在此处,便在彼处!
我们做IT,很多时候都是比较专注,专注于技术,反而对同行的交流、跨行业的接触以及外面的世界不太关心。所以,对于市场上什么技术已经流行,什么产品是未来的趋势都不太关心。而那些做得好的IT始终保持一种开放的心态,去认识趋势,顺应趋势。大多数时候,我们提到“随波逐流”,都认为是没有主见,但当破浪来临的时候,难道你要逆水行舟?
就像当年各大公司都在上ERP,尽管结果有好有坏,难道你不上?连联想的柳传志有一句名言:“不上ERP等死,上了ERP找死。” 但是联想还是上了ERP,没办法,哪个公司不经历“出生入死”能依然屹立不倒,百年长青?再举个例子,电子商务,你说现在哪个公司敢说拒绝电子商务?
今天Tableau峰会的主题就是报表可视化,这里明确了2个趋势:
1、可视化报表,一图胜千言(无图无真相)
2、面向最终用户,而非面向IT的BI
何以见得:第一上午峰会开幕参会人员809(下午又多了一些),第二参会的人大部分是来自业务部门,第三这家公司的股票(美国纳斯达克DATA)
我也在反思我们公司用得的BI产品是大名鼎鼎的SAP旗下Business Objects,但是用户不喜欢用?就连我都不喜欢用!
微软虽然在线的Office365的在线Excel,也有自己的数据库MSSQL的报表分析工具,但还是要搞一个叫Power BI的可视化报表产品?
这不得不令我们深思,有时候我们的职业生涯是跟随着某个软件产品、某种开发语言、某个行业,入错行的意思是选择了一个错误的趋势,并且在趋势变化时,没有断臂归零求生存。比如说我选择了Infor ERP LN这个产品,前身叫BaaN ERP,有好几位前伟创力的同事都换行去做了SAP或Oracle,他们的路越走越宽,而我一直在围绕这个产品,职场上的选择机会就相对少了很多很多!
不说了,说多了都是泪,女怕嫁错郎,男怕入错行, 做IT的错在没有顺应趋势!
既然说无图无真相,就放上来一张图,让你看看哪些大公司都在用Tableau,看你会不会有下一步行动。
我的行动:
1、立马淘宝买了一套学习Tableau视频!
2、分享给好友
3、写下这篇博客
4、明天安装试用版,开始学习使用
5、以后分享使用心得
今天下午,质量部经理来问我关于来料检验基础信息的设置,并提及仓库擅自取消检验标示的问题。我不得不用几句话介绍我曾长篇大论《由Infor ERP LN中来料检验标志设置,说说懂业务的IT多重要》中提及的系统设置要领,同时跟他沟通业务的管控问题。
我跟他阐述了如下几点,并且告知,应该去找出问题的部门,问一下缘由,才能从根本上解决:
1、如果用户(一般是产品开发部,隶属供应链部门)要求系统设置检验,但是系统没设置,那是Document Control(有的叫Data Entry)部门的责任。
2、如果系统基础信息设置正确,采购下订单时,擅自修改检验标示,那是Buyer的责任。
3、如果订单上有需要检验,到了仓库收货时,取消了检验标示,那很明显是Warehouse的责任。
质量经理也就这些观点跟我达成共识,但是他还提出一点:”能否禁止仓库人员在入库时修改检验标示?“
我从系统灵活性和应用实际给他举了2个例子:
1、下单时需要检验,订单下好了,供应商确认了,下达到仓库了,此时仓库收货时是需要检验的。但是如果忽然说这批货不需要检验了,怎么办?
2、下单时不需要检验,订单下好了,供应商确认了,也下达到仓库了,此时仓库收货无需检验,但是如果紧急要求来料检验呢?
从业务灵活性来看,这里是没办法限定死收货时的检验标示的,同理采购订单上的检验标示也不能限制死。
尽管最终质量经理接受了目前的系统状况,但留给我一些思考:
1、我们怎么样能限定仓库的人针对检验标示的操作?转而将这部分修改权限交还给采购去处理?
2、实际业务的灵活,究竟需不需要系统做的那么灵活?
3、目前的任何大型ERP产品,都很庞大,说实话从用户体验上,跟互联网产品、App比起来都非常不好用,下一代的ERP应该是什么样的?
4、目前SAP、Oracel、Infor等ERP厂商,包括国内的金蝶、用友等,他们在ERP的道路上又是往哪方面发展的呢?
5、如果是一个中国企业,究竟是照搬国外,特别是标榜凝聚500强国际管理理念的软件产品?还是取其精华,灵身定制?
最后附上一段话,今天学习到的:再厉害的技术,也得应用到老百姓、消费者、客户、用户、自己公司的现实商业需求中。技术性偏的,最多只能做技术总监,而做不了CTO。只有洞察业务的现状结构、未来变化可能方向,你才有可能选择合适的技术架构,你才能够做到合适地满足现状,灵活地应对未来变化的扩展及变更。
1、世间有太多的事情都是有期限的
2、就连长期的劳务合同、终生制也是有生效和失效时间的
3、你买的房子,所有的得失,都在“得”时生效,“失”刻失效
4、人的生效期是生,失效期是死。
5、科学原理的生效期是被发现出来,失效期是被科学推翻
昨天一大早,销售经理抱着电脑来找我,满面春风的告诉我一个新客户:“前几天销售文员建好了系统,今天(六一儿童节)文员休假,财务收款做不了。”
公司几年前就制定了“一切为销售服务”的规章,谁让人家是给公司创造效益的人呢,放下手里的活,赶紧看看呗。
先看了一下销售经理收到的财务截图,报错信息如下:
我看到“Business Partner with Inactive status”第一反应就是到Business Partener去查这个客户的状态,可是显示如下,明明是Active呀!
转念一想,难道是收款日期还没生效?继续查,果然是,因为是生效时间12:00PM,而收款是 12:00AM,果断提前一天修改如下:
同时修改Sold-To,Ship-To,Invoice-To特别是Pay-By的生效日期
整个处理过程,都被销售经理看在眼里,我没再继续解释,相信他懂合同的大脑已经没有任何问题了。
我让他去找财务继续收款,有问题再找我。
整整一天过去了,都没再来找我。
通过这个Case,其实我们ERP系统很多地方都有Effective Date, Expriy Date的概念。这一点大家自己开发系统的时候一定要参考学习。这里举几个例子,来说明原因。
1、BOM:不同时间段可以有不同的版本
2、财务汇率:不同的有效期内的交易,都会自动使用汇率表的汇率
3、价格表:不管客户还是供应商的价格表,都有可能变化,既能保存历史记录,又能确保采购价格准确
日常工作或其它系统开发中,也会有类似需求
1、Outlook用户外出设定,自动在某时间段回复邮件或转发邮件
2、OA系统中用户可登录时间设定:无需删除用户、无需设定无效、只需设定可登录时间
3、公司颁布一项新的出差制度的自动失效先前版本
举了这么多例子,其实主要想表达:Infor ERP LN这个系统的错误提示相当友好,基本上通过错误提示信息,都可以去到相应的地方找到解决办法。这种占到我日常处理用户Case的一半一样吧。而对于那些莫名奇妙的报错,或者从来没遇到的问题,我的解决思路是自己研究,实在不行问总部,再不行就联系厂商Infor。
我自己研究的时候,我比较喜欢从程序员的角度考虑,所以喜欢看背后的数据(库),喜欢看相应的错误信息所涉及到的Session Script或底层dll的Program Script,喜欢从业务逻辑的角度来分析理解这里会有哪些商业逻辑。
所以,我喜欢肯思考的用户,喜欢动脑筋的用户,不会重复犯错误的用户。比如我们这位销售经理!
不喜欢那种,用了10次没报过错,11次的提示了一个信息,自己看都不看,就大惊小怪,邮件乱发一通,电话乱抱怨一通。死脑筋,不会变通的用户。
也不喜欢那种,相同的问题讲了3遍,依然错在同一个地方的用户!!!
自从坚持写作,我觉得每天碰到用户提交的问题时,都不由自主的想整理成文字,并渴望针对问题扩展开来,希望能够讲一个问题点引出一条线,甚至展示出一个平面。
今天一早销售经理抱着电脑来问我一个新客户无法系统收款的问题,这个足以写一篇超过500字的文章,我先记录下来,等没有话题的时候再展开,今天先写一个我不太擅长的财务模块的一个用户case。
坦白的说,我最初接触ERP的时候,是从每个月和财务一起对账开始的,那时候借贷方、科目等等熟悉的不能再熟悉,也自己看过几本财务书,但自从我在伟创力时曾经的顶头上司Max,用他专业的财务知识告诉我,财务部门的职能划分,高低层次以后,我发现我所了解的AP、AR、Cash、GL、Costing、FA等只是操作层面的,最底层的,就再也没有了方向。对于Reporting,Budget Control这种高级的计划层面的就一窍不通了。但我猜测,这就点像搞技术的,程序员负责实现功能,架构师负责系统的分解、结构、最优化,产品经理明确最终的目标和大方向。
所幸的是,今天财务的同事问得问题比较简单。她看到财务集成(Integration Transactions – tfgld4582m000)的里面有些集成并没有显示出来科目(Ledger Account),因为这是集成错误(最近几个月业务变化快,出现过多次集成错误),发给我让我查找原因。按照惯例,我要确定的确产生的Map或Post Intergration Error Log,我会直接发送给做财务集成的美国同事去处理,因为我没权限也不会统筹规划集成的科目和交易设置。但当我看到同事所发的集成交易当前状态是Logged,我就明白了,是她担心过度了。
先附上关于集成交易状态的系统帮助,再来重点解释一下这里集成交易处理的流程和状态之间的关系。
Logged
Mapped
Posted
Logging Error
Mapping Error
Posting Error
所谓集成交易,就是来自于其它业务模块的诸如采购、销售、仓库的交易。每一个业务交易背后都会反映到财务科目上相应的变化,那么在不同的业务交易的状态,都会(有可能)触发不同的集成交易数据(其实是将必要的业务数据,提交到财务模块,记录下来)。讲到这里,我不得不说一个概念:
财务期间及状态 Period & Period Status
一般来讲我们有可能用到3中财务期间,以应对灵活的期间定义和不同用途的期间设置(不懂什么叫期间的,请自行百度)
1、Fiscal
2、Tax
3、Reporting
针对每一个期间,我们都能设定不同年份的不同期间(可以不按照自然月)范围,每一个期间都有一个开始时间和结束时间,并且每个期间中都可以针对不同的业务模块划分来定义期间的状态,灵活控制(这里需要点赞!)。
1、ACP – AP
2、ACR- AR
3、CMG – CASH
4、INT – Intergration
5、GLD – GL
还是配上截图吧,大家更好理解
财务期间先表至此,回到正题,先看一下我画的一个简图:
从业务模块到了财务集成阶段,会经历3个状态:Logged、Mapped、Posted,每一种状态都有可能报错:Logging Error、Mapping Error、Posting Error。
Logged状态前主要检查财务期间INT的状态(这个也可以通过参数设定)以及跨期间交易的财务期间选择问题,如果所有可用的INT都是关闭的,比方说我们公司每月期初有几天都会关闭 INT,用来结账。
Mapped状态主要就是通过检查当前有效的Mapping Scheme(这个以后再来专门讲解),将业务交易根据交易类型等匹配到相应的Ledger Account和Dimension。如果此时Mapping有误,就会报错。当然了,Mapped之后,Posted之前,你还可以选择指定的Mapping Scheme来覆盖掉先前的。
Posted状态一旦出现,这个集成的账目就正式记录到GL财务帐上了,没有反悔啦。Posted状态之前,会检查财务期间GLD的状态,以及跨期间交易的财务期间选择问题。跟INT类似,但GLD一般都是某个财务期间最后一个关闭的状态,所以跨期间交易到底记录到哪个财务期间在此时特别重要,我们有财务的基础参数设置来完成。
你可以选择Post to Current Period,也可以Post to Next Open Period,还可以使用Exception来处理。
当然了除了期间GLD状态问题,还有可能document number的free number达到最大值或未设置引起。
3种状态,大家有个基本概念了,这其中有一个Map/Post Integrations的Session,一般情况下我们都是通过Job自动调度执行,一般每天早晚2次自动执行,如果手工执行,需要注意一下权限问题,大家可以通过Integration User Groups (tfgld4135m000)来设置Intergration Users。如果有报错,大家就可以通过Integration Transactions Error Log (tfgld4584m000)去查看详细记录,以便于排查问题。
到此为止,我们基本上知道了Infor ERP LN中集成业务的财务模块的相关知识,不知道你有没有发现,这里的设置的确很妙,很严谨?!
1、业务模块和财务模块相对独立
2、不同的财务集成Mapping方案,灵活应用到业务集成
3、从业务到财务,3个步骤,各司其职,周密而严谨
今天采购经理问我一个问题:我们系统中怎么样才能看到哪些订单供应商没确认或者确认过了?
我当时脑子里一转,好像系统没有这个状态,还有点担心:这么大的事情,Infor没考虑到?转念一想,就巴拉巴拉的解释了一通,然后就没有然后了。
虽然事后,我还专门微信给做SAP的老同事,确认SAP中怎么处理这种供应商确认订单的问题的,同时问了采购处理采购订单确认有啥特别的地方。尽管还没得到回复,但还是加会班,将这段思考记录下来吧。
回到问题的核心,我想我们需要考虑4件事情:
1、为什么需要供应商确认?
2、供应商究竟确认些什么?
3、常用的订单确认形式有哪些?
4、采购得到确认后做些什么?
先来思考第一个问题:
1、如果是有采购合同的话,这个采购订单确认是不是可以省略?
2、采购的过程是就是做生意的过程,采购方针和供应商之间有任何的生意变化(从无到有、从有到无、有之间的变化),诸如:新产品、加急订单、降价等等,都需要双方同意,才能成交,才有可能执行这个订单。
接下来就是第二点,究竟确认哪些信息?据我所知,常见的就是料号、数量、价格、交期(交货时间)、运输方式、交货方式、支付条款,对于质量(质检标识)、包装也常会涉及,其它的诸如保险、不可抗拒因素、仲裁等就鲜有涉及。
第三个问题,根据当前的国情,比较多的还在使用传真、电子邮件,还有少数人订单打印后邮寄,比较先进的企业都在使用Supplier Portal(供应商门户)一类的系统来跟供应商互动,当然,还有些公司使用EDI的形式对接供应商的系统,这样大家各自在自己的ERP系统中操作,系统就直接对接起来。 但是,更多的时候,采购员都必须拿起电话,针对未达成的共识进行沟通,因为有效沟通此时来的更重要了。
最后一个问题,比较重要,也是回答采购经理问题的关键:采购能得到供应商的信息无非2类:
A、确认无误
B、有问题需要变更(还需变更后继确认)
到这里,答案就比较明朗了:我们Infor ERP LN系统,在Approve订单后,订单状态变为Approved。之后Buyer打印订单,并发给供应商(我们是通过邮件发送订单pdf文件),此时订单变为Sent状态。
试想一下:
1、Sent状态的订单最多能存在多久?这不是这段时间是等待供应商确认?
2、Sent状态的下一个状态是In Process,是不是可以理解为供应商已经确认的?
3、如果Sent状态的订单,一段时间后,变为Modified,是不是理解为供应商未确认?
4、Modified之后,还需要重新Approve,重新打印订单并交由供应商确认,此时又回到Sent状态,如果每天都去关注Sent状态的订单明细,是否就能很好的督促采购跟供应商的订单确认?
相信说到这里,你已经知道该如何回答采购经理的问题了。
这里我们也可以了解到通常意义下Buyer的一项价值所在:跟踪并执行采购订单的整个流程。
大学的时候,其实有志于学习的是计算机硬件和网络方面的技术,大学里在建筑系的机房勤工俭学做网管近1年,后来第一份工作的前半年也是搞搞网络、电脑系统、打印机啥的,直到Sars出现,不得不搞搞网站设计,学学asp,学学html,css啥的。直到2014年第2份工作,碰到了王经理,招我进入一家像样的公司(中美合资、300多人、老板旗下还有其它公司,上海有500多人,至今此公司活得很好),作为Web Developer。后来因为资深的同事小赵(我的师傅)为爱情离职,我开始学习Grape City iERP的系统二次开发和维护,主要是负责问题解决、每月的关账、对账,那时候真的是有点不知所措,就这么阴差阳错的开始学习业务知识的同时,学习比较成熟的系统设计、技术。期间从销售、到采购、到最复杂的生产、还有仓库、最核心的财务,都必须从零开始学起,那时候有老师带,的确成长很快。不得不承认“站在别人的肩膀上,走的更快”,做IT必须借力借势!
后来,第一家公司的老板找我要搞互联网创业,另外我也很想试试。我就辞了职,此事我到现在都觉得很可惜!但是,路一旦迈出,就得往前走,谁知道前方究竟是泥潭还是美景。上苍眷顾我,大概就这么晃了半年,我被一家上海工厂员工近5000人的500强公司(伟创力Flextronics)录取了,做ERP工程师。顶头上司是香港人Max,非常的聪明,非常的努力的一个人,是他给我机会进到更大的平台,同时在最初的2年里,给我很手把手的辅导,让我有机会接触了BaaN,并成为当时一起在他手下的团队中唯一一个啃英文书啃出来会BaaN二次开发的人。后来,Max找了机会回到他最擅长的领域:财务。我又开始在各种Web Application和BaaN ERP中间徘徊,但正是这种机会,让我熟悉普通ERP之外的的HR、IT、Finance部门的各种审批流程,这样不仅对企业业务流程有了较深刻的理解,对企业日常运营方面的流程也是相当熟悉。这种快速的积累,虽广泛但不精深,待了5年不到,经曾经一个Team的同事Amy引荐,加入目前的公司,将WorkFlow工作流、BPM业务流程管理和ERP都纳入到自己的深耕范围。
6年过去了,总部的IT老大走了2轮,Amy也离职了好几年了,而我依然在做基础的工作、技术和业务都有了更深的认识。于是就有了今天主题里面讲到的这个来料检验的话题。
在讲系统之前,让我们梳理一下:
我们的要求:来料检验
我们可能的需求:
1、针对某个料号检验
2、针对某个供应商检验
3、针对某个供应商的某个料号检验
4、针对某个供应商的某个料号的某个订单(临时)检验(或取消)
5、针对某个供应商的某个料号的某个订单的某次入库(临时)检验(或取消)
6、上述所有可能情况下,指定时段检验(或取消)
搞清楚了实际业务的可能需求,作为一个成熟的ERP系统,是不是应该从上述的各种可能去考虑进行系统功能开发?那我们不得不说,Infor ERP LN这点绝对考虑周到。我们可以在以下界面进行系统设置或更改,足以显示其灵活性。
1. Item
2. Ship-from Business Partner
3. Item – Purchase
4. Item – Purchase BP
5. PO (one of above places:2,3,4)
6. Warehouse Receipt (Line)
但,有时候用户,特别是对口的用户不懂自己的业务的时候,你就得解释。当你的对口的用户,有一些落后或者超前的需求时,你就得苦恼。如:
1、我需要供应商的这颗料从今天开始所有的已下订单未收都必须检验(或取消检验)
2、我不想让仓库在Warehouse Receipt Line上做任何修改关于检验的设置
因为上述两条,本身就是矛盾的。
那怎么办呢?沟通,分析利弊,让用户选择取舍。沟通不成功,只好一句话:系统的标准功能,没办法改。我们要学习和使用500强背后的先进管理理念!
哈哈,上面的后半段话,是我意淫的,用户至上,做IT的地位没那么高。
但我相信,事在人为:除非你比业务更懂业务!!!
你不仅会技术,你比专业还专业!
你能在系统内外构建起更适合、高效的业务流程!
坚持,不放弃!