2012产品创新数字化峰会有奖征文火热进行中……
0 引言
Teamcenter是Siemens 公司在整合UGS 和SDRC 的产品和技术优势后所提供的一套完整的企业级PLM解决方案。Teamcenter能够支持由制造商、供应商、合作伙伴和客户组成的扩展企业在网络环境中生成、共享、管理、集成和评价各种产品数据(包括产品需求、项目数据、工程设计数据、零部件和文档以及产品配置数据等)。
某大型家电企业使用Teamcenter PLM系统作为其研发产品的生命周期管理工具。任何产品,需要以唯一的销售码形式存储在企业信息系统中,并且与对应的产品生产码、产品设计码相关联,满足单一数据源与数据可追溯性的要求,规范企业的生产与销售之间的关系。而企业应用于生产、销售的信息系统往往是分步实施,其间的关系混乱。为此,笔者力图通过客户端的二次应用开发,来解决特定需求,对其他类似问题也具有借鉴意义。
1 销售码应用开发方案
1.1 问题描述
企业产品的生产码、设计码、销售码存在以下现状。
产品的生产码作为产品的Item ID,也就是产品的物料编码,产品的生产码,在创建产品保存后系统根据生产码规则自动生成,一经生成便不可更改,并且,当为内销产品时,业务上被作为销售码使用。而产品的设计码,在创建产品保存后系统根据设计码规则自动生成,且可手工更改设计码,它作为产品版本对象表单属性进行存储。
其生产码生成规则如图1所示。
图1 生产码生产规则
第“5~7”位基准产品规格小类:为产品型号中的规格代码,对规格代码不足3位的应用“0”补足三位。超过3位的,1000L-3000L,10用A表示,11用B表示,以此类推。3000升及以上的统一用W00表示,字母O和I不得使用,字母X、Y、Z备用。例:BC-48冷藏箱,其规格代码为48,则应表示为“048”。如BD/BC-1065DKM,其规格代码为A65。
其设计码生成规则如图2所示。
图2 设计码生成规则
第一位至第三位取值:产品类别的值为:1、3、4归类为冰箱,对应的代码值只能从000-9ZZ,R00-ZZZ生成;产品类别的值为:5、6、7、8归类为冷柜,对应的代码值只能从C00-KZZ,P00-QZZ生成。第四位取值:根据产品在分类上的制冷剂分类属性值获取:R12-1;R134a-2;R600a-3;混合工质-4;R404a-5。
由冰箱产品的压缩机对产品成本影响很大,而压缩机型号及价格往往随市场波动很大,所以原本设计相同的同一种产品,由于压缩机不一样,产生了多个生产码,但由于其作为同一种产品对外销售,在ERP系统中,其销售码要唯一,而现阶段出现了同一产品多个销售码的状况。而且因以前的设计码历史数据的编码是手工编制,不是按顺序编制的,毫无规律可言,也相对混乱。所以急需在PLM系统中寻找一种解决此混乱情况的方法。
1.2 解决方案
根据企业要求销售码对象必须存储销售码、销售码描述、设计码、生产码(数组型)、品牌、品类,且销售码和销售码描述以及设计码必须按规则自动生成;销售码方案上线前的产品(称呼为老产品),其生产码从业务上还是作为销售码同时使用,若销售码方案上线前的产品(称呼为老产品)存在压缩机替代项,则必须由研发部门手工创建压缩机替代项产品(称呼为替代项产品),并且系统自动创建一个销售码对象,此销售码对象的销售码和设计码为老产品的生产码和设计码,销售码描述根据规则自动合成,销售码对象的生产码属性存储老产品的生产码和替代项产品的生产码;销售码与设计码前三位的关系为1:1;销售码与生产码关系为1:N,其都是基于型号和颜色决定唯一性。
1.3 应用开发控制方法
根据方案描述,需要在PLM系统对相应的业务点要进行控制。
在不同组织中,同一个销售码对应的多个产品(生产码),若产品对应的型号或颜色发生变化,要求销售码及其对应的多个产品的描述必须更改一致(仅针对描述中的型号和颜色)。
在不同组织中,一个产品因工厂转产存在多个具有相同生产码的产品(生产码后加工厂后缀区分),要求这些产品的描述必须更改一致。
产品分类属性中填写的压缩机属性值必须和产品实际BOM中的压缩机一致。
在不同组织中,一个产品因工厂转产存在多个具有相同生产码的产品(生产码后加工厂后缀区分),要求这些产品实际BOM中的压缩机及其配套物料必须一致。
在不同组织中,同一个销售码对应的多个产品(生产码),这些产品实际BOM结构必须一致(除压缩机及其配套物料之外)。
在不同组织中,不允许存在BOM结构完全一样而编码不一样的两个物料,包括产品和子装配件。(除生产工艺引起的原辅料和采购标识不同之外)。
2 系统应用开发
2.1 开发环境
Teamcenter的二次开发分为客户端和服务器端。客户端用Java语言开发,同样它的二次开发也使用Java语言;服务器端的二次开发利用集成工具包( Integrated Tool Ki,t ITK ) 及C语言。由于Teamcenter Engineering版本的升级可能导致所开发程序需要改写并重新编译, 所以二次开发的原则是尽可能利用Teamcenter Engineering已有的功能,减少二次开发量。基于以上考虑,二次开发的重心应放在客户端,尽量利用服务器端的已有功能。
开发程序应用环境如表1所示。
表1 应用环境
应用环境确定后,根据业务需求,PLM系统涉及的数据模型描述如表2所示。
表2 数据模型描述
2.2 系统Handler开发
Teamcenter提供了ITK的开发方式。事实上,ITK是Teamcenter与NX定义的一系列C函数,是一套经过封装的C语言程序集。其主要用于Handler的创建。
此handler为Workflow具体任务节点的ACTION-Handler,Handler名称可自定。使用此Handler时,“流程目标对象”会固定为M6_ProductRevision。主要用于新建与产品对应的销售码对象,或将新建产品分配入已有销售码对象。
具体实施建议放置在“新增图纸明细审核流程”的发放节点之后。程序逻辑如图3所示。
图3 销售码生成/关联逻辑图
判定检查“流程目标对象”的itemid是否为51开头,如果是则“通过”,不是则“不通过”;是否已存在匹配的“销售码对象”,获取“流程目标”的属性——“产品型号”将属性“产品型号”,作为搜索输入,去遍历M6_SalescodeRevisionMaster的属性字段——“产品型号”若返回存在满足条件的ITEM——M6_Salescode;则判定为“存在”;若返回结果为空,则判定为“不存在”;新建销售码对象,新建一个ITEM类——M6_Salescode,其itemid自动生成,规则为:“流程目标”的itemid经12位编码化后(十二位编码化:流程目标的itemid可能是xxxxxxxxxxxx,也可能是xxxxxxxxxxxx-xxx两种形式,只需要xxxxxxxxxxxx部分)。将12位化后的结果第2位码改为固定数字7后得到的“更新后12位编码”;与新增的销售码对象关联,将“流程目标对象”的itemid,Append至新增的“销售码对象”的属性字段,将新增的“销售码对象”ITEM类型——M6_Salescode,以关系M6_SalesRelation关联到“流程目标对象”所在的M6_Product对象下;加入到匹配的“销售码对象”中,在步骤逻辑步骤#1中,记录返回存在满足条件的ITEM——M6_Salescode的编码,将“流程目标对象”的itemid,Append至此满足条件的“销售码对象”的属性字段;产生“设计码”属性,按照规则自动生成“设计码”,并将生成的结果值,同时写入新增出的“销售码对象”的属性。
2.3 PLM系统与ERP系统接口传递
PLM系统与ERP系统之间的信息由接口进行传递。Teamcenter支持Plug-in开发方式实现其客户化需求。利用Teamcenter提供的开发入口Teamcenter\portal。将入口加入目标平台,即可利用Plug-in对Teamcenter进行客户化定制。信息的传递即通过Plug-in开发方式,读取PLM中的信息并将信息写入中间表,实现信息的传递。
利用JAVA线程技术,利用程序每隔20秒时间进行遍历读取器工作列表下的任务。顺序执行其获取的任务,根据任务类型选择具体的处理方法。信息机器人除了具有任务分析及处理功能外,还具备工作日志存储、出异常关闭、自动重启等功能。
对于物料的新建、更新,BOM的新建、更新,以及新供应商与物料供应关系,为了完成从PLM到ERP的传递,在PLM系统本地数据库中创建传递请求中间表,在ERP系统本地数据库中创建传递反馈中间表,对于每种需要传递的数据:
首先由PLM中的信息机器人,响应用户在工作流任务中提交的传递请求动作,将传递请求数据记录到PLM本地的请求中间表,该请求的初始状态为‘NEW’;
然后定时运行的ERP客户化程序读取状态为‘NEW’的请求数据,如果初步判断无法接受该请求,则更新PLM中间表的请求记录为‘REJECTED’状态;如果可以处理,则在ERP本地的反馈中间表生成对应的传递数据记录,经过进一步转换处理后,提交ERP标准处理程序进行处理,然后将中间表请求记录更新为‘ACCEPTED’状态;
ERP客户化程序跟踪ERP标准处理程序的执行结果,更新ERP本地反馈表中传递记录的的状态为‘SUCCESS’或‘FAIL’状态;
PLM中的信息机器人响应用户在工作流任务中执行的检查传递结果动作,读取ERP反馈表中状态,反馈给用户传递结果信息;PLM工作流中信息机器人的处理程序,检查传递必须成功,才允许流程向下推进。
其具体传递逻辑如图4所示。
图4 信息传递逻辑图
3 应用实例
该企业通过新增产品明细工作流程进行销售码的生成及数据的传递。主要包括工程师提交、标准化审核、会签、部长批准、系统发布、物料传递ERP、物料传递到OCM\BOM传递到ERP、BOM传递到OCM、发送通知等工作步骤。工作流程如图5所示。
图5 产品新增明显流程
在系统发布节点中加入销售码生成Handler程序,用于销售码的生成;在物料传递ERP节点,开发plug-in程序,用于销售码的物料传递及销售码与生产码关系传递。
销售码生成部分代码如下:
AOM_ask_value_string(revMasterTag,"m6_product_model",&xinghao_value1);
ICS_ico_find("",attachObjectTags[i],ICS_SEARCH_ORDER_BY_ID,&theCount,&theICOTags);
ICS_ico_ask_class(theICOTags[h],&theClassId);
ICS_ask_attribute_value(theICOTags[h],"*颜色",&attributeValue);
ICS_ask_attribute_value(theICOTags[h],"*制冷剂",&zhilengjiValue);
ICS_keylov_get_keylov(key_lov_id,&key_lov_name,&options,&n_lov_entries,&lov_keys,&lov_values,&deprecated_staus,&owning_site,&n_shared_sites,&shared_sites);
……
//销售码创建
ITEM_create_item(item_id,NULL,"M6_Salescode",NULL,&tagSalescodeItem,&tagSalescodeItemrev);
流程运行结束之后,实际产生销售码符合销售码生成规则,其与生产码关系传递正确。
4 结束语
PLM系统实施过程中,业务流程需求往往会产生新的技术需求。如何让PLM系统更适合具体企业,使其达到预期的效果,需要业务人员与开发人员紧密合作。此PLM系统销售码启用,正是业务人员与开发人员相互配合实施的良好案例。实践证明,Teamcenter系统中销售码的开发应用,满足了企业额业务需求,解决了企业销售码、生产码、设计码混乱的现状,提高了企业的生产效率,提升了企业的市场竞争力。
转载请注明出处:拓步ERP资讯网http://www.toberp.com/