Kaufland跨站卖货，库存文件别传错类型

准备把德国站的商品带到另一个Kaufland销售渠道，卖家很容易先想到翻译和价格。库存怎么连起来，反而像一个随后再处理的小问题。但同一批实物由几个站点一起销售时，商品编号、库存更新方式和文件类型，都会影响买家还能不能下单。

Kaufland的公开文档把商品资料与报价资料分开，也把完整库存文件与增量更新文件分开。同样是一份CSV，放到不同导入方式里，作用可能很不一样。要改十款商品，先确认这份文件准备更新什么范围，比直接点击上传更有用。

跨境团队把几个市场接进同一套经营流程时，需要先回答两个问题：哪些报价在销售同一批库存，哪些库存本来就应该独立。答案确定后，才能正确安排SKU、仓库和更新节奏。

完整库存文件与增量更新范围原创概念插画

一个商品，先有资料，再有卖家的报价

Kaufland所说的商品资料，包括描述商品的属性与技术信息；报价资料则涉及售价、库存和履约安排。商品已经在平台目录中存在时，卖家可以在核对后创建自己的报价；目录里没有相应商品时，则需要先建立商品资料。Kaufland商品资料说明

这一区分很重要。卖家发现商品没有正常展示，不能一概认为“库存没有上传成功”。商品资料缺少必填内容，报价所指的EAN找不到，或报价本身存在问题，都可能出现在上架过程的不同位置。应该看具体反馈，再去修改对应部分。

例如，一款收纳盒的颜色和尺寸没有准确填写，属于商品信息需要核对；库存还有多少盒、从哪个仓库发出，则属于卖家的销售与履约安排。把数量写进商品描述，不会代替库存字段；重复提交库存，也不会自动补全缺失的产品属性。

平台公开说明中列有商品资料反馈报告，包括找不到EAN的情况和缺少所需信息的无效商品。卖家可以按报告中的问题整理修正项。某次上传完成，只说明这一环节已经提交或处理，仍应核对商品与报价实际状态，不宜直接当成全部商品已经可以成交。

同一个SKU跨站，哪些信息会联动

在库存接口文档中，Kaufland用id_offer记录卖家定义的报价识别号。通过这个识别号连接的不同站点报价，数量与仓库信息会保持同步；价格、运输组、备货时间和备注等其他属性可以按站点不同，不按同一种方式同步。Kaufland库存管理文档

这意味着，一件商品在两个站点显示，不一定代表卖家真的拥有两份独立库存。假设同一批实物有五十件，两个渠道共同使用这批库存，卖家应按实际关联方式管理，而不能在经营计划里简单算成五十加五十等于一百件。

反过来，如果两批库存确实需要独立管理，就不能仅为方便，把它们当成同一批货来同步。官方文档说明，不希望数量与仓库共享的报价，需要采用不同的id_offer安排。具体设置仍要与实物库存、商品身份和所用系统一致，不能只在某个表格里改个名字，就认为整个流程已经隔离。

价格能不同，也需要单独维护。德国站的售价调整，并不意味着其他渠道所有价格都会跟着变化。卖家可以按各市场的费用、配送安排和经营计划分别定价，但应当知道哪个系统负责哪一组字段。否则，人工改过的价格，可能被下一次同步重新覆盖。

公开接口还提醒，同一个id_offer不能随意拿去对应不同EAN或不同商品状态。卖新商品与卖另一种状态的商品时，不能为了省编号，把两者混进同一库存关联关系里。编号看起来是后台数据，影响的却是订单最终该发哪一件实物。

扩展销售渠道，不宜重新手造同一条报价

Seller University对SKU有一条明确提醒：SKU要在报价创建完成前填写，已经创建的报价不能再直接补入SKU。开始整理商品时，最好先把编号安排确定下来，而不是等多个渠道都开始销售后，才试着补同一套规则。Kaufland报价管理说明

同一份说明还指出，EAN与SKU的组合跨国家和销售渠道适用。把已有报价扩展到另一个渠道，应按平台提供的转移方式处理，避免手工重复创建完全相同的组合。看到“SKU已经使用”时，不应立即给同一件商品随意换一个EAN来绕过去。

如果卖家使用整批报价转移功能，还要核对相应前提。官方说明提到，报价中需要定义备货时间，自动转移基于卖家自己上传的商品资料；直接依赖其他卖家商品资料的报价，不能按同样方式自动转移。具体哪一条商品符合条件，应逐条确认。

这也解释了为什么同一店铺中的商品可能出现不同处理结果：有些商品资料来自自己，有些使用了已有目录信息，准备程度不同。卖家需要补的是明确缺少的条件，不是把所有商品重新创建一遍。

扩大销售渠道时，还应按目标市场检查运输组和价格安排。平台能够帮助转移报价，并不代表原来的配送成本、备货条件和售后安排适用于所有目的地。操作完成后，卖家应看目标渠道的实际报价，确认它符合自己准备执行的经营方案。

完整文件会替换当前渠道的报价

Inventory Feed与Inventory Command是这里最值得先分清的两个名称。官方库存文件文档说明，Inventory Feed用文件中的完整库存资料替换对应销售渠道的当前资料；没有出现在文件中的报价，会从该渠道删除。它不是一份只处理已列出行的普通修改表。Kaufland库存文件文档

假设一个渠道当前有一百条报价，运营只导出了其中十条，准备调整售价。如果把这份十条文件作为完整Inventory Feed提交，剩余九十条报价没有包含在文件中，就涉及完整替换规则。这个例子是根据文件作用编写的说明，并非某次真实店铺事故。

因此，准备传完整文件时，需要确认它代表的是该渠道完整、有效的经营范围。表格筛选后看见多少行，文件导出里实际保存了多少行，以及是否遗漏正在销售的商品，都应该核对。文件名带有“库存”两个字，并不能证明它包含全部报价。

完整替换针对所指定的渠道，也需要与共享库存关系一起理解。不能把它说成一次操作会删除所有国家的报价；同时，也不能因为选择了一个渠道，就忽略关联商品的数量和仓库同步。报价在某站是否存在，与多站点是否共用库存，是两个需要分别核对的问题。

如果团队只需要更新少量商品，应先确认所用工具是否发送增量命令，以及每条命令带了什么内容。不能拿完整文件的模板随便删掉其他行，再把它当成增量更新。文件格式能打开，不代表导入含义已经正确。

增量文件，也要认清里面的命令

Inventory Command通过命令补充或更新报价。公开文档列有UPSERT、DELETE和FLUSH：前者更新已有报价或加入新报价，DELETE删除指定销售渠道中的相关报价，FLUSH则清除发送该文件的卖家在相应渠道中的全部报价。名称相似的文件，动作范围仍需要核对。

这里尤其不宜把FLUSH理解成“刷新库存”。它执行的是清除报价。卖家如果只想把一条商品改为另一个数量，就应该核对工具实际发送的更新，而不是选择一个看起来能刷新全店的操作。中文界面里的简写，也不能代替对动作作用的理解。

即便使用UPSERT，也不应认为其他站点完全不会受影响。对已经通过id_offer连接的报价，数量或仓库的修改会涉及关联同步；而价格等信息有另外的站点范围。想要检查影响，最好把同一商品的关联渠道一并列出来。

团队还可以明确每份文件的用途：完整重建某一渠道、更新若干商品，或删除指定报价。把用途放进内部操作说明，交接时就不必让下一个人根据文件名猜。真正准备执行删除时，应核对目标和商品范围，避免把原本用于更新的资料误传到删除流程。

多个站点同时上传，不能靠先后点击决定结果

Kaufland文档特别提醒，不同销售渠道的待处理文件，不保证按加入顺序执行。如果文件对关联报价写入不同的数量或仓库，最终保留的值可能来自其中任意一份。这个条件对同时管理多个渠道的团队很有实际意义。

举例说，两份文件都对应同一批商品，一份写库存五十，另一份写库存三十。如果它们在不同渠道待处理，又关联同一库存，卖家不能仅凭“后点击的那份是正确的”，就认定最后一定保留三十。具体处理结果需要回看实际数据。

比较清楚的经营安排，是确定共享库存的数据来源，并让其他渠道从同一来源取得一致数量。独立库存则按独立关系维护。这样做的目的，是让系统里的数量可以追到实物，而不是让各渠道运营分别填写自己估算的数字。

遇到数量来回变化时，也应先查是谁在写入。人工上传、定时文件和接口工具如果同时更新同一关联商品，修改一次未必能解决问题。需要核对各自的数据内容和实际处理状态，找到相互冲突的更新来源，再按原有经营安排修正。

处理完一批更新，还可以在内部记录对应渠道、文件生成时间和已经核对的结果。这样，下一次库存出现差异时，团队能区分旧文件重新传入、当前数据尚在处理，以及某条商品确实需要修正。记录服务于经营交接，不应以一行“上传成功”代替对结果的确认。

Kaufland多渠道销售的准备，最后落到很具体的关系上：商品身份能不能对应实物，报价使用哪批库存，文件更新哪个渠道，关联字段会影响哪些报价。把这些关系写清、核对清楚，增加一个销售入口才不会顺手增加一份库存误会。

声明：本文系作者独立观点，不代表ESG跨境立场。文中涉及的平台规则、费率及出海政策具有时效性，实际运营请以平台官方最新公布为准。如有版权争议、内容勘误或业务交流，欢迎随时与我们联系。