库存物料(Inventory Item)导入
物料导入/导出主要的目的是在不同系统之间的数据的导入/导出,以某一种数据信息格式和某一种传输方式获取数据。在不同系统间的数据导入/导出必须解决的最重要的问题是数据校验,以满足数据在不同系统间的可用性。根据这两周的学习,总结一下Item导入遇到的一些问题和解决的方法。
数据导入在处理流程上大致分为三个部分:
(1)是处理数据文件,插入客户化接口表;
(2)是处理客户化接口表数据,插入标准接口表;
(3)是提交标准请求,导入标准表。
在导入的类型上来说,有三种情况:
(1)创建物料
(2)更新物料
(3)组织分配
API中主要涉及的都是客户化和标准系统的衔接问题,所以熟悉标准系统表,接口表,客户化表是一个非常重要的过程,在API中还会调用系统的标准导入请求,标准导入的数据必须是符合系统的数据,所以API中一个重要步骤就是验证数据,处理数据。用一个Master Item 的导入作例子。
1. API被调用及输出关系
库存Master Item 导入API的起点是客户化接口表,终点是标准表,而客户化接口表的数据来源可以是多种,取决于接口程序(平台)的整体架构,无论是文件还是信息流的形式,经过适当处理之后,导入客户化接口表,并且有必有提供数据批次的唯一标识和数据行级别的唯一标识。导入程序所定义的并发程序应该在数据处理之后被调用,必要参数是数据的批次标识,并发程序应该返回数据导入处理的状态和必要的错误/警告信息(如果有)。
2. API伪代码
Begin
获取参数;
根据数据批次号,从客户化接口表获取数据;
FOR EACH Record
验证数据;
判断数据创建/更新/分配标识位;
导入系统接口表;
END FOR;
提交系统导入系统标准请求;
打印错误报告;
End
3. Master Item 导入涉及到的主要的表/视图及描述
Table Name | Select | Insert | Update | Delete | Description |
|
|
|
|
|
|
org_organization_definitions | X |
|
|
| 系统组织定义 |
mtl_system_items_b | X | X | X |
| 系统标准物料基表 |
mtl_system_items_b_kfv |
|
|
|
| 系统标准物料关键性弹性域视图 |
mtl_item_revisions_b | X | X | X |
| 系统标准物料修订基表 |
mtl_item_categories_v | X |
|
|
| 系统标准物料类别视图 |
mtl_item_categories | X | X | X |
| 系统标准物料类别表 |
mtl_system_items_interface | X | X |
| X | 系统标准物料接口表 |
mtl_item_revisions_interface | X | X |
| X | 系统标准物料修订表 |
mtl_item_categories_interface | X | X |
| X | 系统标准物料类别表 |
xxinv_item_int | X |
| X |
| 客户化接口表 |
mtl_interface_errors | X | X |
|
| 系统标准接口错误表 |
mtl_units_of_measure_vl | X |
|
|
| 系统标准物料度量单位多语言视图 |
mtl_parameters | X |
|
|
| 系统标准组织参数表 |
mtl_default_category_sets_fk_v | X |
|
|
| 系统标准类别集视图 |
mtl_category_sets | X |
|
|
| 系统标准类别集表 |
mtl_categories_b_kfv | X |
|
|
| 系统标准类别集视图 |
mtl_categories_kfv | X |
|
|
| 系统标准类别集关键性弹性域视图 |
4. 特殊逻辑
(1) 验证客户化接口表数据
Item导入API是根据数据的批次号,从客户化接口表获取相应数据,验证过程主要依据大致和标准物料的标准是一致的,虽说在提交标准请求时,系统也会验证数据,但是标准请求只有输入输出,过程不可见,所以在客户化接口表这个阶段验证可以保证数据错误的可控制性;另一方面,系统请求一般请款比较慢,特别是计划的周期请求,多个批次也容易混淆,所以在客户化表中验证,如果不符合要求,直接返回,省去标准请求所耗费的资源。
主要验证有:非空验证,组织验证,单位验证,修订号验证,类别验证等,涉及到的表或视图之前列过了。
(2) 是否是新物料(创建物料/更新物料/组织分配)
这里的判断决定了导入程序需要往标准接口表里插入几次,主要原因是,如果是一个新物料,系统中不存在,则需要往这个物料所对应的组织的主组织中也插入一条数据,即标准接口表里有两条组织不一样的相同物料信息。
- 创建物料:系统标准物料表中不存在,且标准接口表中不存在(这里需要判断标准接口表这个中间表的原因是,如果同一批数据是同一个物料不同的组织,而且是新物料,如果不判断系统接口表,就会有多个主组织数据存在于系统接口表中,提交标准请求时,就会出现重复记录的错误)
- 更新物料:同一个物料,同一个组织存在
- 组织分配:统一个物料,主组织物料存在,子组织物料不存在
(3) 标准请求
物料导入请求:Item Import(包括item和revision信息)
类别分配请求:Item Category Assignment Open Interface(category信息)
(4) Revision处理
客户化接口表的记录有revision信息存在,则要处理revision。新/旧/分配 的判断和(2)中基本一致。在做这一部分的时候,发现了一个问题,Revision在标准系统中是字符串类型的,所以在比较旧的修订号和新的修订号的时候,特别要注意数字的位数问题,例如 :‘9’ 这个字符串是比 ’10’ 这个字符串“大”,但 ’09’ 这个字符串比 ’10’ 这个字符串“小”。验证通过之后直接往标准接口表里导入,修订号取最“大”的一个。
Revision的标准请求合并在物料信息导入的标准请求(Item Import)。
(5) Category处理
Category处理存的标准请求时单独的,叫Item Category Assignment Open Interface,这里的特殊逻辑总结为如下几种:
- 新物料,无category信息:分配当前category set 下得默认category
- 新物料,有category信息:分配这个category 给主组织物料和当前子组织物料
- 更新,无category信息:不处理
- 更新,有category信息:更新当前组织category信息
- 组织分配,有category信息,分配这个category信息给这个子组织
- 组织分配,无category信息,不处理
在处理Category标准请求的时候,与物料信息不同的是,这个标准请求没有“1”或者“2”的标识参数标识创建或者更新操作模式,提交标准请求的顺序是先提交物料信息请求(item import),再提交类别请求(category assignment),多次测试这个标准请求和物料信息的标准请求后发现,在物料信息的标准请求完成之后,已经有这category信息在标准类别表视图(mtl_item_categories_v)中了,category信息是默认的category,所以此时提交category assignment的标准请求,只能去update(以上a—f的6中情况都是这样处理),而update操作必须有”old_category”这个信息,所以在update之前需要获得这个物料老的category;如果是新物料,则更新default category。(default category就是当前category set 下的default category)
(6) 组织分配属性冲突
导入程序常见的错误是,在物料组织分配的时候,有可能出现“master child conflict”。在标准Item的属性控制中,有“master level”和“org level”两种,如果某一属性设置成了“master level”,则在导入时,要么不导入这个属性信息,要么导入的必须和主组织的属性信息一致,否则就会报这个错误(系统标准功能)。导入程序API中有必要判断,在组织分配的情况下,从客户化接口表到标准接口表导入的时候,并且把一些客户化接口表里面没有,但是属性控制中为“master level”的属性值,赋为主组织的属性。