库存物料( 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” 的属性值,赋为主组织的属性。