库存物料（Inventory Item）导入

 

库存物料（ 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 ）        是否是新物料（创建物料 / 更新物料 / 组织分配）

这里的判断决定了导入程序需要往标准接口表里插入几次，主要原因是，如果是一个新物料，系统中不存在，则需要往这个物料所对应的组织的主组织中也插入一条数据，即标准接口表里有两条组织不一样的相同物料信息。

1. 创建物料：系统标准物料表中不存在，且标准接口表中不存在（这里需要判断标准接口表这个中间表的原因是，如果同一批数据是同一个物料不同的组织，而且是新物料，如果不判断系统接口表，就会有多个主组织数据存在于系统接口表中，提交标准请求时，就会出现重复记录的错误 ）
2. 更新物料：同一个物料，同一个组织存在
3. 组织分配：统一个物料，主组织物料存在，子组织物料不存在

 

（ 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 ，这里的特殊逻辑总结为如下几种：

1. 新物料，无 category 信息：分配当前 category set 下得默认 category
2. 新物料，有 category 信息：分配这个 category 给主组织物料和当前子组织物料
3. 更新，无 category 信息：不处理
4. 更新，有 category 信息：更新当前组织 category 信息
5. 组织分配，有 category 信息，分配这个 category 信息给这个子组织
6. 组织分配，无 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” 的属性值，赋为主组织的属性。