简介一份面向金蝶K3系统的物料引入工具采用SQL脚本形式专为需要批量创建或维护物料档案的财务、仓库及IT运维人员准备尤其适合处于系统初始化阶段或日常数据维护频繁的场景能有效解决手工逐条录入效率低、易出错的问题。整个压缩包仅1个文件即SQL数据库脚本大小约6KB轻量且无需额外依赖可直接在K3对应的数据库环境中执行操作门槛低无需二次开发。已有265人学习/下载适合正在实施K3系统或日常需要维护物料数据的用户参考。拿到脚本后可立即运行完成物料基础数据的初始化导入大幅节省重复操作时间同时脚本也可作为理解K3物料表结构与字段关系的入门样例帮助用户在此基础上按需调整字段、扩充数据逻辑编写更贴合实际业务的个性化导入方案。此类脚本执行还可减少人工误操作带来的数据不一致问题便于后续审计与追根溯源。1. K3 物料引入工具到底解决什么问题从手工建 400 条料号说起做过金蝶 K3 实施的人都有过这种体验业务部门报过来一张 Excel上面是几百条新料号规格、单位、默认仓库、物料属性写得还算齐但就是没人愿意去 K3 界面里一条一条点「新增」。因为一条物料从「物料代码 名称 规格」到「计量单位、计价方式、默认仓库、税目、核算项目、自定义字段」加起来有三四十个字段要填手录 400 条录到第 200 条的时候界面卡一下前面没保存的全没了这种翻车现场我见过不止一次。K3 物料引入工具K3 物料引入就是来解决这个问题的把线下整理好的物料主数据通过 Excel 模板、后台 SQL 脚本或二次开发的小工具批量、带校验地写进 K3 账套让物料基础资料在一天之内从手工录入变成批量作业。这套思路适合三类人金蝶 K3 的实施顾问和二次开发工程师、企业里的 ERP 管理员和 IT 运维以及需要定期维护物料编码体系的 PMC 或财务人员。它解决的问题很直接——建料效率、数据规范性、以及多部门协作时「谁改了物料谁负责」的追溯问题。下面我按自己做过的最常见方案把这个工具的选型、实现、坑位和验证方法拆开讲。2. K3 物料引入的三条落地路径Excel 模板、SQL 脚本、二次开发工具怎么选2.1 为什么不能靠界面手录一条物料背后有 50 多个字段要管先说结论K3 物料引入之所以存在是因为 K3 的物料主数据不是一个「单表」而是一组关联表。界面上你看到的是一个物料卡片点了保存之后K3 同时往t_ICItem物料主表、t_ItemDetail物料明细表、t_ItemProp物料属性扩展表以及核算项目相关的表里写数据。手工录的时候 K3 帮你做了这些联动批量导入的时候这些联动就要你自己负责。物料引入的难点不在「写入」本身而在「校验」。K3 对物料代码FNumber是全局唯一约束的同一个账套里不能出现两个一模一样的料号物料名称FName不能为空计量单位FUnitID必须存在于t_MeasureUnit表物料属性FItemClassID控制着这个物料是外购、自制还是委外这些属性直接决定后续 MRP 运算和凭证生成的逻辑。手录时这些问题被界面逐字段挡掉了批量引入时一条脏数据就能让整个批次报错或者更麻烦——不报错但后续跑 MRP 的时候结果不对劲那种问题最难查。所以选引入方案之前先看你的物料数据长什么样几十条的小批量、数据源就是一张手工整理的 Excel直接用 K3 自带的引入功能几百上千条、需要反复从别的 ERP 或者 PLM 系统同步建议走 SQL 脚本或者写个小工具如果是给客户做项目交付物料引入以后要长期维护那二次开发一个带校验、带日志、带许可控制的引入工具才是正路。下面按这三条路径展开。2.2 金蝶自带 Excel 引入模板从导出到读日志的完整操作K3 WISE 从 12.3 开始到 15.1 仍然是这个路径在「系统设置 → 基础资料 → 物料」里带了一个「引入」功能它本身就是一个轻量物料引入工具。使用方式是先点「引出」从 K3 里导出一份标准物料 Excel 模板然后在模板里按列填数据填完再点「引入」。模板里预置好的列包括物料代码、物料名称、规格型号、辅助属性、基本计量单位、默认仓库、物料属性、计价方式、税率、是否启用等。需要注意导出模板里的列名是 K3 固定好的你不能自己改列名只能增删行。我一般会在模板右边追加几个辅助列做公式检查比如用COUNTIF提前查一下物料代码有没有重复引入的时候就能少报一半错。实际操作步骤如下1. 登录 K3 客户端进入「系统设置 → 基础资料 → 物料」。 2. 菜单栏点「引入 → 引出」选择保存路径得到物料引入模板.xls。 3. 用 Excel 打开模板按列填数据物料代码、名称、基本计量单位必填。 4. 填完后点「引入」选择该 xls 文件勾选「覆盖引入」/「新增引入」。 5. 引入完成后查看引入日志日志路径一般在 K3 安装目录的 K3ERP 临时文件夹下。这里有一个关键参数引入方式。K3 引入界面会让你选「新增」还是「更新」。新增模式遇到相同物料代码会跳过或报错更新模式会把已有物料的名称、规格等字段覆盖掉。如果你的 Excel 里只有新料号选新增最安全如果是从其他系统同步过来的全量数据才考虑更新。引入完以后日志文件的最后几行SELECT TOP 100 * FROM t_ICItem WHERE FNumber IN (M001,M002,M003) ORDER BY FInterID DESC注意这个 SQL 是写进查询分析器跑的目的是在正式引入前先确认目标物料代码没有被占用。金蝶自带引入的局限性在于它只能处理物料主表上的常规字段物料里的自定义字段、核算项目、多计量单位组通过自带引入经常映射不上这时候就需要下一条路。2.3 直接往 SQL Server 写物料主表最小 INSERT 与字段含义第二条路径是绕过 K3 界面直接对着 SQL Server 写。金蝶 K3 的数据后台是 SQL Server账套库名一般是AIS2023...这样的格式物料主表就是t_ICItem。直接写库的前提是你理解 K3 的表结构并且有账套库的 db_owner 权限。这种方式适合实施顾问做项目初始化或者企业 IT 从外部 ERP 同步物料。一个最小可用的物料 INSERT-- 插入 K3 物料主表最小必填字段 INSERT INTO t_ICItem ( FItemID, -- 物料内码K3 自增 ID FNumber, -- 物料代码账套内唯一 FName, -- 物料名称必填 FModel, -- 规格型号可为空但建议填 FItemClassID, -- 物料属性1外购 2自制 3委外来自 t_ItemClass FUnitID, -- 基本计量单位 ID来自 t_MeasureUnit 表 FSource, -- 0K3 新增 1引入 FErpClsID -- ERP 分类标识外购一般填 0 ) SELECT (SELECT MAX(FItemID) 1 FROM t_ICItem), -- 手动取号避免和已有数据冲突 M2024001, 不锈钢板 304 2mm, 304/2mm/1219x2438, 1, (SELECT FMeasureUnitID FROM t_MeasureUnit WHERE FName 张), 1, 0这段 SQL 是最小写法实际生产里不会只有一个 INSERT通常是一整批数据从 Excel 或临时表循环插入。在写之前这两点要注意一下。先说t_ICItem的主键。K3 的表结构比较老FItemID不是严格的IDENTITY自增列很多时候 K3 通过后台的规则取号。所以脚本里直接SELECT MAX(FItemID) 1是常见做法但在并发插入时会有问题简单场景够用高并发场景我会加一个取号表或者用 UUID 数值。FItemClassID这个字段尤其重要它决定物料是外购、自制还是委外。填错了后续采购下单、MRP 运算会全部乱套。FUnitID对应的是t_MeasureUnit表里的计量单位不是简单的kg、张这样的文本所以子查询里用单位名称查出对应的单位 ID这是最稳妥的写法。直接写库的优势是快、可控、不受 K3 界面的字段限制劣势是你绕过了 K3 中间层的字段校验和日志记录数据一旦写错t_ICItem里的脏数据很难从界面删干净只能再写 SQL 清理。所以这类脚本只建议对测试账套先跑一遍或者在一个可以随时还原的账套上跑。2.4 什么时候才值得做二次开发物料引入工具第三条路径是写一个独立的 K3 物料引入工具。常见的形态是 C# 或 Java 写一个控制台程序或 Windows 服务先连 SQL Server 读取 Excel 或 API 推送的物料数据做完校验后调用 K3 的 SQL 写入逻辑有些场景是直接写表有些场景是通过 K3 的ICClassBill、ICClassMtl单据类接口最终生成一份「哪条成功、哪条失败、为什么失败」的导入报告。什么时候值得做我自己的判断标准是一次性导入几百条不值得每个月都要导入而且数据来源是别的系统PLM、PDM、老 ERP值得客户要求物料引入必须带审批流或版本记录值得导入的数据需要同时生成物料、计量单位、核算项目、BOM 草稿值得。二次开发工具最常见的做法是// 伪代码示意二次开发引入工具的校验与落库流程 foreach (var row in excelRows) { // 第一步基础合法性校验 if (string.IsNullOrEmpty(row.FNumber)) { log.Error(物料代码为空); continue; } if (string.IsNullOrEmpty(row.FName)) { log.Error(物料名称为空); continue; } if (checkFNumberExists(row.FNumber)) { log.Error(物料代码重复); continue; } // 第二步转换关联 ID row.FUnitID GetUnitIdByName(row.UnitName); row.FItemClassID GetItemClassIdByName(row.ItemClassName); // 第三步写库 记录导入日志 InsertIntoT_ICItem(row); InsertIntoT_ItemDetail(row); log.Info($物料 {row.FNumber} 引入成功); }这段伪代码的逻辑并不复杂真正的复杂度在GetUnitIdByName、GetItemClassIdByName这些转换上因为源系统里的单位叫「pcs」K3 里叫「PCS」或者「件」物料属性叫「外购」K3 里的FItemClassID对应的是数字1。这些映射关系需要在工具里维护一张映射表而不是写在代码里。3. 物料引入的数据映射与校验字段对照表、必填项和入库前的 SQL 体检3.1 物料字段映射表Excel 列名、K3 后台字段与长度约束无论走哪条路径做物料引入前都要先做一张自己的字段映射表。K3 自带引出的 Excel 模板和数据库字段之间的对应关系不直观Excel 里叫「基本计量单位」数据库字段叫FUnitID实际存的是数字 ID。如果不先把这张表理清楚填模板的时候很容易把单位填成文本「张」导入后界面显示一片空白。下面这张映射表是我做 K3 物料引入时的标准参考覆盖了主表上的高频字段Excel 列名自带模板数据库字段t_ICItem类型/长度是否必填说明物料代码FNumbervarchar(80)必填账套内唯一不允许重复物料名称FNamevarchar(240)必填界面显示名不要带特殊符号规格型号FModelvarchar(240)选填建议填出库单上要展示基本计量单位FUnitIDint必填存的是 t_MeasureUnit 的 ID物料属性FItemClassIDint必填1外购2自制3委外见 t_ItemClass默认仓库FDefaultLocint选填对应 t_Stock 表的 FStockID计价方式FPriceMethodint选填0加权平均1先进先出等税率FTaxRatenumeric选填百分比数值是否启用FDeletedint必填0启用1删除/禁用备注FNotevarchar(255)选填一般放物料用途说明映射表里面最容易被忽略的是FDeleted。Excel 模板里你看到的「停用勾选框」后台对应的就是FDeleted。很多人引入物料时没勾停用代表0正常启用。但如果你的源数据里有「已停用」的状态标识不要把它映射成「是/否」文本K3 只认0/1。另外补充一个 K3 15.1 上常见的问题物料代码FNumber长度老账套可能允许 40 位新账套 80 位。如果你的上游系统编码是「物料大类-小类-流水号」那种长编码引入前先查t_ICItem字段定义避免引入到一半遇到截断报错。3.2 引入前的三张前置表校验编码、计量单位、物料属性物料引入报错八成不是死在 INSERT 那一下而是死在数据没过前置校验。我自己会把校验拆成三层编码层、引用层、业务层。编码层校验物料代码有没有重复、有没有非法字符引用层校验计量单位、仓库、物料属性这些外键值在 K3 里真实存在业务层校验比如「自制物料是不是漏了默认 BOM」。引用层校验最值得写脚本因为人眼根本看不出来「kg」和「KG」在 K3 后台里是两条记录还是同一条。常见做法是把 Excel 里的值先落到一张临时表然后用 LEFT JOIN 去匹配-- 前置校验检查 Excel 临时表中的单位名称是否都能在 K3 里找到 SELECT tmp.FNumber, tmp.FUnitName, ISNULL(u.FMeasureUnitID, -1) AS K3单位ID FROM tmp_MaterialImport tmp LEFT JOIN t_MeasureUnit u ON LTRIM(RTRIM(u.FName)) LTRIM(RTRIM(tmp.FUnitName)) LEFT JOIN t_MeasureUnit u2 ON LTRIM(RTRIM(u2.FNumber)) LTRIM(RTRIM(tmp.FUnitName)) WHERE u.FMeasureUnitID IS NULL AND u2.FMeasureUnitID IS NULL这个 SQL 的逻辑是先把 Excel 里的数据导进tmp_MaterialImport临时表可以先导入到 SQL Server 的一张表里然后用单位名称和单位编码两个维度去匹配 K3 的t_MeasureUnit匹配不上的拉出来人工处理。用LTRIM(RTRIM())是为了处理 Excel 里不小心带出的前后空格。同样的套路也要对物料属性FItemClassID做一遍匹配。业务人员在 Excel 里写的「外购」「自制」是中文K3 里对应的是数字如果 K3 版本里外购的FItemClassID不是1不同历史账套可能不同你的工具里写死1就会翻车所以要用t_ItemClass表动态匹配。3.3 自定义字段和辅助属性的匹配FEntrySelf 与计量单位组聊到自定义字段就说到物料引入真正让人头疼的地方。K3 物料上容易加几十个自定义字段比如「技术图号」「质检等级」「供应商默认交期」。这些字段在自带 Excel 模板里不一定有在数据库里也不在t_ICItem主表里而是存在t_ItemProp或扩展表里。K3 的自定义字段分两类单值辅助字段和多值辅助字段前者存在辅助属性表里后者涉及一张单独的关联表。SQL 直接写的场景下我给一个相对通用的写法-- 自定义字段写入示例t_ItemProp 是物料属性扩展表 -- 假设自定义字段 F_123 在 Excel 里的列名为「技术图号 JY-2024-001」 INSERT INTO t_ItemProp (FItemID, F_123) SELECT ic.FItemID, tmp.FCustomValue FROM tmp_MaterialImport tmp INNER JOIN t_ICItem ic ON ic.FNumber tmp.FNumber WHERE tmp.FCustomValue IS NOT NULL AND tmp.FCustomValue ! 这里的F_123不是固定的字段名每个账套根据自定义字段的添加顺序会生成不同的名字比如F_1001、F_1002。怎么查在 SQL Server 里执行SELECT * FROM t_ItemProp WHERE 10看字段结构带F_前缀的列就是自定义字段。另外K3 中间层在引入物料的时候也会校验自定义字段的数据类型比如数字类型字段你传了「1.5kg」导入就会被拒。关于计量单位组这也是个典型坑。K3 物料界面里的「基本计量单位」和「辅助计量单位」是分开的引入模板里只有一个基本计量单位字段辅助计量单位进不来。如果你的物料需要采购用「吨」、库存用「千克」那 Excel 里就要额外处理单位组和换算率自带引入不处理这个逻辑SQL 方案里要单独写单位组的 INSERT。4. K3 物料引入的 6 个真实踩坑记录现象、原因、解决4.1 坑一FNumber 看似不重复引入后材料出库串料现象引入时 K3 没报错物料也建出来了但过了一个月做材料出库单的时候发现两张完全不同的物料代码显示同一个名称仓库发料发错了账实差异拉出来全是问题。原因Excel 里的物料代码看起来不同实际存在隐藏字符。常见的有三种一是全角/半角空格不仔细看完全看不出来二是 Excel 单元格里M001和M001后面带个不换行空格在视觉上几乎一致但 K3 后台字符串比对不认为它们相同三是物料代码用了相似字符数字0和字母O混用。解决引入前先做一次「清洗」把物料代码里的空格、特殊字符全部去掉再做重复性检查。SQL 里处理-- 检查清洗后是否存在重复物料代码 SELECT LTRIM(RTRIM(REPLACE(FNumber, , ))) AS CleanNumber, COUNT(*) AS Cnt FROM tmp_MaterialImport GROUP BY LTRIM(RTRIM(REPLACE(FNumber, , ))) HAVING COUNT(*) 1这段 SQL 把物料代码里的空格去掉以后再分组统计查出重复的代码在引入之前让业务人员确认到底哪个才是正确的。并且要求 Excel 里所有文本列设置成「文本」格式避免长编码被 Excel 转成科学计数法。4.2 坑二引入完成后 k3listserver 无法正常工作账套登录报错现象物料引入工具跑完SQL 显示几百条插入成功但 K3 客户端登录账套时报「连接中间层失败」或者「k3listserver 无法正常工作」相关的报错彻底进不去系统了。原因这种情况在 K3 15.1 上遇到过触发点不一定是物料引入本身。最常见的是引入时一次性往数据库写了太多数据导致账套库的事务日志快速增长中间层服务在连接账套时做初始化操作超时还有一种情况是t_ICItem表上的统计信息过期K3 中间层打开物料列表时要扫描大量数据内存被占满后服务进程崩了。解决第一步先把 k3listserver 对应的 Windows 服务重启K3 中间层服务一般叫K3Server或类似名称第二步清理账套的事务日志不要用SHRINK直接暴力压缩先BACKUP LOG再收缩第三步也是治本的办法物料引入分成多批提交单批不超过 500 条。这个我后面第 5 章会专门展开。注意k3listserver 异常不一定是引入工具造成的但大批量写入之后发生基本可以按「日志膨胀 统计信息过期」来排查。排查顺序先看 SQL Server 的错误日志再看 K3 中间层日志最后才动数据库。4.3 坑三导入成功但计量单位显示空白现象SQL 插入成功界面上物料编码、名称都在但「基本计量单位」一格是空的物料单据保存不了。原因FUnitID字段写入的数据在t_MeasureUnit表里不存在或者写入了单位组 ID 而不是单位 ID。K3 里计量单位分两层计量单位组比如「重量组」和组里的单位千克、克、吨。t_ICItem.FUnitID存的是单位 ID不是组 ID。很多写 SQL 的人从t_MeasureUnit里取FMeasureUnitID的时候取到了单位组表的 ID。解决写一个关联检查确认引入后的FUnitID在t_MeasureUnit主键里真实存在-- 检查引入后的物料单位是否有效 SELECT ic.FNumber, ic.FName, ic.FUnitID, mu.FName AS UnitName FROM t_ICItem ic LEFT JOIN t_MeasureUnit mu ON mu.FMeasureUnitID ic.FUnitID WHERE mu.FMeasureUnitID IS NULL AND ic.FDeleted 0上面这条 SQL 能一次性查出所有单位无效的物料。查出结果后如果数量不多直接在 K3 界面重新选一次单位保存数量多就写 UPDATE 脚本批量修。特别注意一个习惯写引入工具时不要直接把文本单位名写进FUnitID一定要走一次单位名到 ID 的映射函数。4.4 坑四核算项目/自定义字段没有带出来物料只进了一半现象物料引入后主表数据都在但物料的核算项目比如「存货科目」「税金科目」是空的或者自定义字段供应商默认、质检等级全部丢失。原因t_ICItem只是物料主表核算项目、自定义字段存的是关联表。SQL 脚本只写主表没写t_ItemDetail和t_ItemPropK3 界面上自然不显示。我在 2.3 里给的是「最小 INSERT」实际生产里这是远远不够的写完整需要同时维护多张表。解决写引入脚本前先明确一个规则——凡是 K3 物料界面上存在的字段都要在引入脚本里找到对应的落库位置。标准做法是建一张「字段映射配置表」把目标字段、来源字段、表名写进去脚本循环读取这张配置表生成 INSERT而不是手写每个字段。这样物料引入工具的可维护性会高很多。4.5 坑五Excel 模板列名对不上引入日志一堆「找不到字段」现象用 K3 自带功能引入 Excel 时日志提示Field xxx not found或者「模板列无效」引入 0 条。原因业务人员为了方便在模板里加了一列命名为「物料名称(必填)」或者把 K3 导出的模板列名手动改成了「名称」。K3 自带引入是按列名精确匹配的列名多一个空格、多一个括号都不认。解决不要手改模板列名所有列保持 K3 导出的原名额外的计算列追加在模板右侧并且不要在表头写入任何字符。如果确实需要给用户看的友好列名做一个映射功能把用户上传的 Excel 表头翻译成 K3 标准列名这是二次开发工具里很有价值的一个小功能。4.6 坑六大批量导入把账套拖慢其他用户做单卡死现象晚上跑 5000 条物料导入第二天一早上班其他用户反馈录入销售订单、出库单特别卡点保存要转十几秒。原因物料引入的 INSERT 事务持续时间长持有了t_ICItem表上的锁同时大批量插入导致表碎片化严重统计信息过期后K3 界面打开物料列表时走了全表扫描。而且 K3 用户操作业务单据时经常要关联物料表被阻塞直接在所难免。解决第一引入时间放在业务低峰期分批提交第二跑完以后立刻执行一次索引重建和统计信息更新第三如果引入频率高把引入工具改成「先把数据写到中间表再通过 K3 的接口分页提交」而不是直连表 INSERT。5. 大批量物料引入的性能与事务分批参数、锁等待和回滚策略5.1 分批提交为什么 200500 条是一个安全区间物料引入写库本身很快慢的是校验和关联。我自己的经验值是单批 200500 条最稳。低于 200 条批次太多、循环开销大高于 500 条事务持续时间变长锁等待和日志暴涨的风险开始显现。如果一条物料还要连带写核算项目、自定义字段、计量单位组单批建议压到 200。分批写法用一个循环控制-- 分批插入示例一次取 200 条逐批提交 DECLARE BatchSize INT 200; DECLARE StartRow INT 0; DECLARE EndRow INT 0; WHILE 1 1 BEGIN ;WITH CTE AS ( SELECT ROW_NUMBER() OVER (ORDER BY tmp.FNumber) AS RowNum, * FROM tmp_MaterialImport tmp ) INSERT INTO t_ICItem (FNumber, FName, FModel, FItemClassID, FUnitID, FDeleted) SELECT FNumber, FName, FModel, FItemClassID, FUnitID, 0 FROM CTE WHERE RowNum StartRow AND RowNum StartRow BatchSize; SET EndRow StartRow BatchSize; -- 如果本次批量插入的行数为 0说明已经处理完退出循环 IF ROWCOUNT 0 BREAK; SET StartRow EndRow; END这个脚本的核心在ROW_NUMBER()排序后按行号切批。每一批是一个独立事务默认 autocommit一批失败不影响下一批。要注意ORDER BY的字段选一个稳定唯一的建议用FNumber清洗过重复之后不要用自增 ID 排序因为临时表 ID 顺序不代表业务顺序。分批的另一个好处是错误定位快。跑完以后看日志落在哪个批次复查那个批次的数据就好不用 5000 条一起从头查。另外分批时记得观察 SQL Server 的sys.dm_exec_requests里有没有长时间阻塞。5.2 事务与锁等待xact_abort、批次 COMMIT 和阻塞 SQL 排查写直连库的引入脚本事务控制是保命的一环。我有一次没加SET XACT_ABORT ON脚本跑到 3000 条的时候遇到一条数据违反约束批里前面的 2999 条全部回滚了。加上这一句以后任何运行时错误都会让当前事务直接终止回滚行为可预期。还有一个容易被忽略的参数是LOCK_TIMEOUT。默认情况下 SQL Server 遇到锁会无限期等待生产账套高峰期跑物料引入一旦被别的会话阻塞这个等待可能把引入工具挂在那里几个小时。建议设置一个合理的锁等待时间-- 引入工具建议的事务参数 SET XACT_ABORT ON; -- 出错自动回滚当前事务 SET LOCK_TIMEOUT 30000; -- 锁等待 30 秒超时超时报错跳出 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; -- 避免脏读同时不用锁太多资源锁等待超时以后脚本会报 1222 错误这时候要查一下到底谁在阻塞-- 查看当前阻塞链 SELECT blocking_session_id AS 阻塞源会话, session_id AS 被阻塞会话, wait_type, wait_time / 1000 AS 等待秒数, command, text AS SQL文本 FROM sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) txt WHERE blocking_session_id 0如果是 K3 用户在正常做单导致阻塞避让是更好的选择把引入时间切到业务低峰期如果是自己之前的批次没提交查一下活动事务ROLLBACK掉再继续。5.3 半途失败不用重来批次日志表与回滚策略写引入工具的人一开始都不重视日志直到翻了两次车就老实了。我推荐在引入工具里固定一张日志表每批次写完以后不管成功失败都往里写一条记录-- 批次日志表结构简化版 CREATE TABLE tmp_ImportLog ( LogID INT IDENTITY(1,1) PRIMARY KEY, -- 日志自增 ID BatchNo INT, -- 批次号 StartTime DATETIME, -- 开始时间 EndTime DATETIME, -- 结束时间 TotalCount INT, -- 本批总条数 SuccessCount INT, -- 成功条数 FailCount INT, -- 失败条数 ErrMsg NVARCHAR(1000) -- 第一条错误信息方便快速定位 );跑完以后一条查询就能看出全局情况SELECT BatchNo, TotalCount, SuccessCount, FailCount, CASE WHEN FailCount 0 THEN ErrMsg ELSE OK END AS 状态 FROM tmp_ImportLog ORDER BY BatchNo;失败批次的数据不用删掉重来把失败原因修掉以后从失败的批次号继续跑就行。这里有一个设计要点临时表tmp_MaterialImport里要加一个IsImported标记导入成功后置1这样重跑的时候就能自动跳过已成功的数据。这个标记比按批号重跑更可靠因为一个批次里可能部分成功部分失败只靠批号判断会重复导入。6. 引入完的验证技巧用三类核对 SQL 确认物料“真的进去了”6.1 数量与字段抽样核对先算总数再抽 10 条看关键列引入完成不等于引入正确。我的习惯是三步验证先总数再抽样最后差异比对。总数对比最简单Excel 源数据里的物料条数和t_ICItem里新增的条数对一下-- 核对数量按引入日志标记统计本次引入的物料数 SELECT COUNT(*) AS 引入总数 FROM tmp_MaterialImport WHERE IsImported 1;抽样核对关关键看三个字段物料代码、计量单位、物料属性。其他字段可以依权重抽查。一次性抽样 10 条人工过一眼比直接对比几百条更现实。6.2 用 EXCEPT 做源表与物料的差异比对如果源数据质量高可以用EXCEPT做一次全字段的集合比对。把 Excel 清洗后的数据落到临时表然后和t_ICItem在主键匹配的基础上做差集能查出「临时表里有但 K3 没有」的所有物料相当于给整个引入过程上了一道保险-- 差异比对找出临时表数据与 K3 物料表不一致的记录 SELECT tmp.FNumber, tmp.FName, tmp.FModel FROM tmp_MaterialImport tmp WHERE tmp.IsImported 1 EXCEPT SELECT ic.FNumber, ic.FName, ic.FModel FROM t_ICItem ic;这个查询的关键是EXCEPT比较的是整行行里任何一个字段不同都会被拉出来。日常维护物料的人可以每月跑一次这个脚本也能顺便发现业务在界面上改过哪些物料。6.3 不同 K3 版本之间的引入差异与我的收尾习惯做物料引入这件事K3 版本之间的差异比想象中大。老版本12.x的自定义字段命名规则和 15.1 不一样t_ItemProp里自定义字段的字段名、类型限制在不同账套里可能不同引入脚本的元数据最好在目标账套上动态读取不要从别的账套复制一份就拿来用。另外K3 15.1 对物料编码唯一性的校验更强SQL 直插如果直接绕过中间层某些版本会出现界面缓存不刷新的情况重启客户端或者清一下本地缓存目录即可。我个人的收尾习惯是每次物料引入工具跑完专门花 10 分钟打开 K3 物料界面随机翻 3 条物料看看显示效果再做一次盘点用的进销存查询确认物料关联的库存、核算数据没有异常。因为工具只对写入负责业务上数据合理不合理最终还是靠人去确认。提示如果物料引入后紧接着要做核算或下采购单第一步永远是让财务先做一次存货档案核对而不是急着跑 MRP。物料基础资料这种底层数据一次错会传导到后续所有单据回头看的时候代价最大。希望上面这些路径、参数和踩坑记录能帮你在做 K3 物料引入时少走几趟弯路。本文还有配套的精品资源点击获取
