在使用Infor ERP LN的过程中，由于网络中断或者不稳定经常会出现用户打开某个Session的时候报错，信息类似如下：
Fatal error : value DsNheight=-280 out of range
那么这时候，用户怎么也打不开想要使用的Session了，这时候就需要用到这个有用的Session：Remove User Defaults.
输入用户的账号，选择相应的公司，然后输入对应的Session Code，点击Remove即可。
概念：
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在Barcode，或者说WMS领域的产品Factory Track，但一直未看到过演示，也未体验操作过。近期在Jerry Huang的帮助下，终于一睹真面目。
先发个截图，需要更多截图，请加入我的知识星球：Infor ERP LN私房菜
目前有个直观印象，下一步想深入体验和研究一下，以下是我的一些感触：
亮点：
不足：
疑问：
迁移网站到WordPress的时候，因为Linux服务器对长文件名和文件名中的空格支持不好，2006年发布到西山之家的一个培训视频，没办法下载，今天改了一下名，提供下载：BaaN视频培训教程《How to use ttaad4500 display database table information》
前面发了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天完成采购订单和销售订单的后继操作，看看到底税率和发票的操作有没有问题。
再假如说你要测试退货的问题，你可以选择一个老采购或销售订单，选择在第三天进行操作，就知道问题所在了。
好久都不上BE论坛，这个全球最大的中文BaaN论坛，原因是创始人Tony Deng从BaaN ERP转型做了SAP，后来一门心思做管理，不搞技术了。但当年Tony做得这个纪念杯，一直还用着。
偶尔翻起以前的聚会照片，那些曾经的笑脸，又浮荡在脑海，下图是贴在目前论坛（http://www.baanerp.com/com/ebuddy.htm）的一张照片，记得没错的话是2009年10月20日，金秋时节，大家都意气风发。
论坛的核心管理团队已然在网上，但好多都不再做BaaN了。
创始人Tony、刘佳伟（Jerry）、魏广伟都已经不再从事BaaN相关的职业好多年，陈定亮虽也接触，但主业已经是EDI/B2B系统集成相关。
唯有黄庆忠Jerry Huang、Javan、曹志贵、施嘉美、毛庆丰（未核实）依然在坚持。
从2007年开始BaaNERP.com，至今10多年，涌现出很多年轻的高手，但没能在BaaNERP.com抛头露面，多少有些遗憾。
尽管从一开始，我就作为BE的首席规划师协助Tony运营，期间Tony的号召力、组织能力得到大家一致认可和欣赏，只可惜国内从业者太少，厂商又不给力，最近的几年大家都独自依靠，寻求发展。目前论坛也是冷清的很。
未来，我还是希望发挥一定的光和热，继续为国内的BaaN ERP – 准确的说现在应该叫Infor ERP LN做好自媒体宣传，圈子的交流分享。如果从历史的积累和影响力来说，如果要选一个国内Infor BaaN ERP LN自媒体传播第一人，这个角色人选，应该非我莫属。
具体到下一步的行动有三个：
1、继续经营好个人博客和BaaN ERP LN私房菜知识星球（原小密圈）
2、从上述的原BaaNERP.com的团队开始，从2007年聚会的战友开始，逐一亲密接触，记录访谈内容，分享他们的心得体会，传播其个人品牌形象。
3、发掘新人、牛人，让他们浮出水面
昨天介绍了《Infor ERP LN中销售订单状态说明》，按照计划今天要详细介绍销售订单的标准处理程序（流程），开始之前先通过今天工作中的一件小事，插播下一个小观点：在一个组织中，在执行层面员工需要更多的被动培训，而管理者更多的时候需要自己成长，主动寻求内外部的学习资源，并能够提供给下属或基层（底层）员工不同级别、不同形式的培训指导。
事情背景是这样的，公司的仓库部门的系统操作员人员更替比较频繁，并且工作交接基本上没有，那么知识、技能断层严重，同时仓库老员工也存在明显流失现象。这时候日常的仓库运营系统操作就存在问题：不会操作、操作错误、效率低。最后问题推到IT来，需要反复、及时提供最基础的操作培训。明白人一看就懂问题出在哪里，但多说无用。作为一个服务部门，作为一个美资企业，针对不懂英文的仓库人员，必须要花费更多的时间准备中文的讲解，更加细致的培训教程。这不，下面是我列出来的一个提纲（其中的理解和定义纯属个人意见，不全面请勿拍砖），还是做带语音的中文培训视频。
仓库 Warehouse
仓库最核心的职能是负责公司库存的实物和系统管理，做到账实相符。
采购入库、检验 Purchase Order Receiving & Inspection
正常采购订单
MRO采购（Cost Order）
采购退货出库 Return Purchase Order Shippment
销售出库 Sales Order Shippment
销售退货入库 Return Sales Order Receiving
转移订单入库 Transfer Order Receiving
转移订单出库 Transfer Order Shippment
工单发料 Production Order Issue
工单接收（成品入库） Production Order Receipt
库位转移 Location/Bin Transfer
仓库转移 Warehouse Transfer
转料号 Item Transfer
库存盘点 Inventory Cycle Counting
库存调整 Inventory Adjustment
库存查询及报表 Inventory Inquiries & Reports
这不今天周五还算效率高的，花了几个小时弄了5个视频，视频总长度只有30多小时吧。想起来容易，行动起来发现提前准备数据、资料、讲述的文字特别重要，当然后期的编辑处理和渲染也花不少时间，关键是输出为mp4为单线程，占用电脑，还得等着。
好了言归正传，相对于销售模块、采购模块，我目前并没有整理出来类似的一个培训清单，只不过是想起来一个大概的提纲，就大致的介绍一下流程和步骤，因为我觉得和仓库相对，还是仓库的文员的素质更需要细致的培训。这里并没贬低的意思，单从学历上来看。但如果一个熟练的仓库文员，数据输入效率是很高的！并且准确率特别高，当然了做到这些以后，基本上会被提拔到更好的职位到办公室去做其它岗位了。
今天销售标准程序呢，我就把我日常的理解列出纲要，然后针对核心的内容解释一下。
Sales Order
Procedure
Create Order – Free
Customer Code
Order Type
Order Prefix
Planned Delivery Date
Payment Term
Delivery Term
Warehouse
Currency
Ship to Address
Order Quantity
Price
Approve SO – Approved
Print Sales Order –
Preview
Acknowledgements / RMAs
Change Order / Order Line-
Modified
Redo approve
Redo Print SO
Release to Warehousing
Not mandatory (Cost and Service items/Direct delivery)
If has Margin/Credit check –
Blocked
Release to Warehousing –
Released
Warehouse Shipment – In Process
Warehouse
procedure depends on the Sales Order Type
Release to Invoicing
Print Sales Draft
Invoices
Billing Requests –
Confirmed/Released
Compose/Print/Post Invoices
– Posted/Invoiced
Process Delivered Sales Order
– Closed
Cancel SO – Cancelled
Order
Order Line
首先解释一下，上述步骤有些是非必要的，比如Release to Warehousing，对于Direct Delivery订单是不需要的，对于不占用仓库的Cost & Service Item也是不需要的。
第二点，跟Sales相关的模块，有一个Central Invoice模块（简称CI），这个模块有些公司是财务来做，有些是销售来做的。也就是上述Release to Invoicing之后的发票处理。
第三个呢，我们做销售平常肯定会有退货，这时候 Return Order就涉及到原始SO订单的问题，价格、数量、发票金额等都需要考虑。
第四条是Inventory Commitment，就是你有些货是必须要有充足的库存被分配到，这个订单才能下单到仓库。这种是处理抢手货或者多客户销售的一种很好的策略。
第五条涉及到销售订单的锁定问题，这点主要是从销售利润（Margin Check）、客户的授信（Credit limit）等角度进行系统自动控制，必要的时候需要财务和足够级别的高层来解除锁定（Release Sales Order Line Block）。
第六条是导入订单的问题，这个问题呢其实应该由厂商来提供标准接口，可惜不是SAP（其实我也不知道SAP有没有标准接口，只不是很多人都以为SAP很强大，是否够人性化、本地化？Who knows），相信作为销售的你，如果针对的是国内的客户，很多人家可能连系统都没有，首先不用考虑对接EDI订单了，另外对方发过来的可能是传真或者邮件，作为销售文员，你这时候就非常需要一个导入工具。我们公司是自己开发的，只要导入客户编码、料号、数量，订单类型和序列可选择，其它的都是读取客户的系统设置（价格、付款方式、送货地址等）。
最后一条，在中国做销售，你逃不过的是金税发票，一般都需要定制开发一个打印发票文件（有些是txt，有些是Excel，我们2者都有，我开发的Excel的）的接口，然后导入到金税系统，方便开票。作为销售，客户的银行账号、税号等信息必须要一直不差的维护到ERP系统。
今天周五，本来想着速战速决，但越写越有废话。也许这就是参加21天打卡营活动带来的影响。首先能坚持、其次开始思考！
我们每天都在接收新的资讯、新的技术，君不见微信朋友圈的那些转发，微信公众号的那些推送，看了能记住的能有多少？看了能带来影响的能有多少？此刻的我，忽然觉得“少即是多”很有道理，读了那么书，懂那么多道理，最后还是没办法改变生活，为何？因为那些都是别人的，都不是经过我们思考成为我们自己的，获取更多的同时，开始整理、回顾、提炼、深思，向内心求，在键盘上打出自己的想法，也许不成熟，不完美，但会引起更多的反思，串联曾经所读、所观、所学、所知。从而举一反三，触类旁通。
过去，不少人，包括曾经熟悉我的同事、朋友、同学，问我现在主要做什么，我竟一时语赛，至今不能用简单的一句话说出我是干什么的。通过坚持写作，总结我曾经做过的，记录我现在做的，写下未来想做的，也许有一天，我能用一句简单的话，告诉他们我现在做什么工作。