前端原型：https://1ay6cx.axshare.com

一、强调说明

（一）添加/编辑策略-参数“刊登至来源渠道”：多选，刊登的目标“来源渠道”。

1、校验策略时，需要形成一个“来源渠道”列表，先校验来源渠道的“已刊登数、刊登上限”

2、校验通过后，再为刊登的目标“来源渠道”，找SKU

二、刊登数量限制

（一）JD侧逻辑：ware&sku，是1对多关系

1、刊登数量限制对象是ware

2、故，ware数量≤1000

（二）Walmart刊登对象是SKU，且无刊登数量限制

（三）总结

1、刊登至JD，遵守≤1000
2、刊登至Walmart，没有刊登数量限制

三、渠道SKU说明

（一）刊登至JD成功后，才会获取JD_SKU，我们将其作为渠道SKU。故刊登至JD失败，没有渠道SKU

四、队列数量&单次刊登数量限制（≤1000）&参数“每小时刊登数”

（一）待刊登SKU数量×刊登至来源渠道数量=待刊登listing数量

（二）“待刊登SKU、待刊登listing”队列内的SKU排序：按ERP-SKU创建时间-倒序排列【产品定义：越新的产品，越符合当前市场】

（三）参数“每小时刊登数”：判断对象是“待刊登listing数量”

优化项

五、更新父类目、子类目关系

（一）前端“自动刊登策略-JDWalmart-策略详情-刊登至类目”：不做父类目、子类目联动

（二）后端：存类目数据时，不做联动

六、上架底价

（一）业务上没有限制

（二）场景上

1、日常：必然不允许低于成本价，也就是产品采购价

2、促销：才可能出现低于成本价的情况

（三）能区分场景，就能按场景区分、控制价格是否允许不限制底价

1、目前没办法通过场景来区分，因为listing管理1.0没法区分促销的参数

2、就不可以通过“是否促销”区分“促销or日常”

3、就没办法硬的控制

（四）方案：加一个软的监控。

1、目的：不影响刊登，但为了事后查询、找数据

（五）产品逻辑

1、前端：刊登队列，增加1列参数“上架价格”、增加筛选条件“低于采购价”

①参数“上架价格”：不低于“ERP产品库的采购价”时，仅展示刊登的价格

②参数“上架价格”：低于“ERP产品库的采购价”时，展示刊登的价格+标记“低于采购价”

③筛选条件“低于采购价”：枚举“不限、是、否”，默认不限

2、后端

①公式：ERP产品库的采购价=供应商报价+采购运费

②取值：产品库中心——产品管理编辑——产品价格——默认产品供货价

③“采购价”和“上架价格”的换算，要用汇率；“ERP-系统管理-汇率显示”页面的后端表里取；开发：程伟

七、刊登-图片取值逻辑

JDW-商品图-1张主图、5张普图

 

李冠：这里不落库，直接使用redision布隆过滤器处理，能99.99避免图片重复，或场景图顺序一样的问题

八、参数详细

（一）刊登中、刊登失败 不允许编辑

（二）参数“主图”，可以上传的本地图片类型是“主图、备选主图”，数量限制1

（三）参数“详情图”，可以上传的本地图片类型是“普图”，数量限制5

（四）修改图片：提示信息

1.通过系统上架的产品，展示上架使用的园片，从平台同步的产品，图片除主图外，随机抓取6张进行展示

2.接受的文件类型JPG，PNG, GIF, BMP，最小尺寸：500*500px，最大尺寸：3000*3000px，最大文件大小：1MB

3.拖动国片，调节国片顺序，鼠标点击国片，查看原园，主图上传1张、普图上传5张

（五）强电：不选-则该条件不参与校验；勾选-可单选，可多选

（六）起批量等区间类参数：不填-则该条件不参与校验；填了-必须2个都填、不能只填1个

（七）敏感词

1、高危，删除

2、普通，不处理

3、只检测亚马逊美国站点和亚马逊全站点的敏感词

九、因“变体属性名称&变体属性值”导致刊登失败问题-解决方案：类目库优化、“变体属性名称&变体属性值”取值调整

问题背景

1、API文档未说明“变体属性值”
2、销售给出的原业务需求是“所有类目都按color、size填写”

产品设计

功能点1：“无多属性”类目，只进行单体刊登

一、需求分析
（一）情况：业务策略“对此类类目，不进行多变体刊登、只进行单体刊登”，但作为“SKU来源的产品库”，策略选中的SKU可能是多变体。
（二）系统现状：自动刊登策略-策略规则-SKU来源
1、“产品库、指定SKU（仅上架自身）”为单体刊登，
2、“指定SKU（上架所有变体）”-“N条变体刊登为N条listing”为单体刊登，
3、“指定SKU（上架所有变体）”-“N条变体刊登为1条listing”为多变体刊登

二、产品设计
（一）当参数“刊登至类目”，选中“仅单体刊登”的类目时
1、参数“SKU来源”选中“指定SKU(同时上架所有变体)”时，
①参数“多变体产品刊登方式”枚举“多变体上架为1条listing”置灰、不可选择，默认选中枚举“N条变体上架为N条listing”【见原型图】

2、参数“刊登至类目”：放到参数“策略名称”下方
3、交互
①当参数“刊登至类目”选中“type=正常”的类目，选中了“多变体上架为1条listing”后，又将参数“刊登至类目”选中“type=仅单体刊登”的类目：选中枚举“N条变体上架为N条listing”，“多变体上架为1条listing”变为置灰、不可选择

功能点2：“type=不做此类目”的类目

一、需求分析
（一）情况：业务策略“因为此类类目，因为各种原因无法做，具体原因见"类目变体属性"”

二、产品设计
（一）本地类目库，在为前端参数“刊登至类目”返回类目数据时，屏蔽“不做此类目”的类目

功能点3：变体属性名称variantAttributeNames，取值逻辑

一、需求分析
（一）由于各Walmart类目的“variantAttributeNames”的枚举不同，故需要知道各个类目应该选择哪些枚举。故需要对照表

二、产品设计
（一）根据“类目变体属性”表
1、自动刊登策略的参数“刊登至类目”选中了“type=正常、仅单体刊登、新增”的类目，按表中该类目所在行的“变体属性名称1、变体属性名称2”取值
2、“变体属性名称1、变体属性名称2”其中1个字段为空时，则意味着该类目，只有1个变体属性名称，则只取有值的1个

功能点4：变体属性值variantAttributeValues，取值逻辑

一、需求分析
（一）平台现状：参数名称为选中的“variantAttributeNames枚举”的名称
（二）系统现状
1、产品库的数据结构，无法体现出生成变体的主属性，故无法通过“产品库”来确定“变体属性”
2、无法确定“产品库的变体属性”与“variantAttributeNames”枚举的对应关系。故只能约定。
3、产品库的数据结构中，能作为变体属性的只有“颜色”、“尺寸”

二、产品设计
1、“variantAttributeNames”枚举=color，变体属性值variantAttributeValues的参数“color”，取产品库-该SKU-变体管理中参数“颜色”的值
2、“variantAttributeNames”枚举=size、clothing size，变体属性值variantAttributeValues的参数“size、clothing size”，都取“产品库-该SKU-变体管理”中参数“尺寸”的值

功能点5：类目库同步逻辑优化

一、产品设计
（一）新增的类目
1、“type”默认为“新增”
2、“状态”默认为“生效”
3、只能单体刊登
4、参数“SKU来源”选中“指定SKU(同时上架所有变体)”时，
①参数“多变体产品刊登方式”枚举“多变体上架为1条listing”置灰、不可选择，默认选中枚举“N条变体上架为N条listing”
②在枚举“多变体上架为1条listing”下增加提示语：此类目为新增类目，请维护“变体属性名称”【见原型图】

（二）平台删除的类目：“状态”变更为“失效”
（三）参数“type”枚举：正常、不做此类目、仅单体刊登、新增
（四）参数“状态”枚举：生效、失效

十、出现了：刊登成功但无库存、退货地址查不到的问题

一、背景

（一）出现了问题：刊登成功但无库存、退货地址查不到的问题
（二）JD排查原因：因“我们店铺归属于JD的几号店，就应该刊登到JD几号店”

（三）Joybuy-Z15003-Hui之前做过1号店，后来没做了；转2号店了

1、JD的数据库 会存历史做过的几号店
2、则通过jd.jdw.channels.walmart.product.queryChannel接口没办法判断
3、只能通过映射关系来维护

（四）系统需要这个映射关系，需求方和我都是不知道的。因为JD未告知、文档无说明

 

二、方案

（一）增加映射关系，按照如下文档

 

（二）JD系统：刊登到几号店，是通过userPIN来控制
1、userPIN通过jd.jdw.channels.walmart.product.queryChannel接口获取
2、店铺是几号店，就取几号店的userPIN
e.g.：店铺是1号店，就取1号店的userPIN

十一、Listing管理：参数“销售类型=自主上架”

十二、后端业务逻辑-敏感词：定时处理禁售SKU ，对SKU进行下架。定时扫描在线listing表，如果命中敏感词和品牌词，调用平台接口删除。

十三、后端业务逻辑-敏感词：检测敏感词

一、已知敏感词是绑定平台和站点的，那么存在以下2种情况。

1 敏感词A属于亚马逊全站点

2 敏感词B属于亚马逊日本站点。

那么敏感词B 在jDW会不会检测出来

1、只检测亚马逊美国站点和亚马逊全站点的敏感词

 

二、高危和普通全检测，只有高危影响提交。参见产品方案文档-敏感词，和产品原型-listing管理-编辑

十四、后端业务逻辑-敏感词：过滤敏感词name、seoKeys、pcDesc、packingListDesc

十五、后端业务逻辑-敏感词：商标、禁售、敏感词

一、禁售、商标：两个不同的数据源、负责人

田新旭：菜单，禁用词管理
田新旭：菜单，商标库

二、系统逻辑：禁售分平台、商标不分平台，商标不分语言、敏感词分语言

（一）示例

1.销售平台敏感词管理（禁用词） ，理解为不能写的词：例如毒药，吸毒，等，他有多语言的说法
2.商标库(知名的品牌商标)，如：huawei，xiaomi ，LG，LV 等 他没有多语言的说法的，品牌商标都是全球通用的

三、数据源情况：没做特殊逻辑处理，都是运营策略

1、敏感词、商标词数据源：风控部人工维护

2、判断风险等级是普通、高危：风控部人工打标签

3、普通、高危：通用模块没有逻辑限制，亚马逊平台运营规则-高危不允许上架，其他平台都可以

四、敏感词平台&站点：亚马逊平台、Ebay平台、Walmart平台、JD国际平台，站点都是“美国” 

十六、策略参数：强电-交互

1、强电：不选-则该条件不参与校验；勾选-可单选，可多选

①强电，下级选项：不选-则该条件不参与校验；勾选-可单选，可多选

2、起批量：不填-则该条件不参与校验；填了-必须2个都填、不能只填1个

十七、刊登逻辑：多变体刊登，示例

一、示例

 

（一）示例2、3 都没问题

（二）示例1的正确逻辑

①通过SKU2，找到母体，然后再找到SKU1\2\3

②SKU1在平台禁售

③刊登SKU2、SKU3

④且由于是刊登为1条，那么listing包含这2个SKU

十八、刊登逻辑：第一次单体刊登，第二次变体刊登，在变体刊登时，要不要把第一次单体刊登的SKU也与变体再次刊登

一、结论：每次执行，只管本次的
（一）你筛选出来SKU1、2、3
（二）SKU1如果已经在前一次刊登上去了，那么会触发“同SKU只能刊登1条”的互斥逻辑，然后本次刊登只会刊登SKU2\3

十九、刊登状态-刊登失败补偿：“刊登失败”的SKU，会被后续执行的策略抓取，进行再次刊登；“刊登失败”的本地listing，会继续存在

二十、刊登状态：刊登中、刊登失败，不允许编辑

二十一、刊登数据-价格：低于采购价标记

一、调研：上架的底价，业务上没有限制

二、分析

（一）场景上

日常：必然不允许低于成本价，也就是产品采购价

促销：才可能出现低于成本价的情况

（二）能区分场景，就能按场景区分、控制价格是否允许不限制底价

目前没办法通过场景来区分，因为listing管理1.0没法区分促销的参数

就不可以通过“是否促销”区分“促销or日常”

就没办法硬的控制

 

三、方案：软性监控

（一）目的：不影响刊登，但为了事后查询、找数据

（二）产品逻辑

1、前端：刊登队列，增加1列参数“上架价格”、增加筛选条件“低于采购价”

①参数“上架价格”：不低于“ERP产品库的采购价”时，仅展示刊登的价格

②参数“上架价格”：低于“ERP产品库的采购价”时，展示刊登的价格+标记“低于采购价”

③筛选条件“低于采购价”：枚举“是、否、不限”。默认不限

2、后端

①公式：ERP产品库的采购价=供应商报价+采购运费

②取值：产品库中心——产品管理编辑——产品价格——默认产品供货价

③“采购价”和“上架价格”的换算，要用汇率

④在“ERP-系统管理-汇率显示”页面的后端表里取。开发：程伟

 二十二、刊登数据-价格：价格计算器公式

二十三、刊登数据-销售属性：当前为固定取值

 

二十四、刊登数据-类目：大类，API会区分“普通商品、WFS商品、修改数据模板、普通转WFS”

前端查询时，只查询“type=普通商品”的类目

二十五、刊登问题：Lagtime处理方式

背景

1、Walmart的listing数据结构：分listing主体信息、附属信息“退货地址、lagtime、退货规则”

2、lagtime=刊登失败，JD的API返回的还是刊登成功，导致刊登成功Walmart没可售数、JD有

3、lagtime=刊登失败，原因：JD系统异常

4、lagtime=刊登失败，不会出现在“全量商品查询”中

 

验证

1、现在再刊登10条，看lagtime是否失败【验证“自动刊登”的逻辑，是否会导致lagtime失败比率增加】

2、11点半、12点，看下“JD后台-副属信息-上传lagtime”之后，“lagtime失败”的数据，“lagtime状态”是否从“刊登失败”变成了待处理【验证通过JD后台，是否能完成“lagtime=失败”的人工补偿逻辑】

3、11点半、12点，看下“商品管理-商品总表-搜索lagtime状态=失败”，“导出的SKU”是否等于“搜索出的SKU”【验证数据导出是否正确，验证SOP步骤是否可行】

4、验证“全量商品查询API”，是否有返回“lagtime=失败”的listing，“状态=stage”

 

解决方案-当前版本：采用SOP

1、销售同事，每周1上午12点之前，检查一次自己负责的店铺，“lagtime状态=失败”的数据是否超过了本店铺总刊登数的1%【已与清华排查：目前店铺的“lagtime状态=失败”listing数/总刊登数=3‰，销售不处理这部分数据，因为浪费的SKU数占比低】
2、“lagtime状态=失败”listing数/总刊登数＜“1%”：不处理【已与清华确定】
3、“lagtime状态=失败”listing数/总刊登数≥“1%”：处理
①步骤1：JD后台“商品管理-商品总表-搜索lagtime状态=失败”，“导出的SKU”excel
②步骤2：JD后台“通过excel”，批量下架【已验证，通过JD后台下架了“lagtime=失败”的SKU，Walmart的listing也会下架】
③步骤3：将“导出的SKU”excel，发给产研，由产研对“listing管理”中的本地数据下架【会安排迭代需求：listing管理-增加“excel模板-进行批量下架”】

 

解决方案-全面解决【迭代】

一、背景：“lagtime=失败”的SKU，无法在全量商品查询中查到

二、产品设计

1、全量商品查询——数据对比本地listing——没通过全量商品查询到的listing，记录为延迟下架队列

2、全量商品查询——对比延迟下架队列——如果有超过2日未查询到的延迟下架队列，则对listing操作下架

3、下架listing，如果上架了【每日更新状态定时任务，会更新这个状态】

二十六、1.0版本的数据初始化方案

1、没渠道SKU&SKU关联关系的

2、全量——JD_SKU——分页查询——只查“在线”——落库到listing表

3、历史刊登的listing，只拉取“上架”的，非“上架”意味着不使用，如果上架了意味着要开始使用，能通过【每日更新listing】拉到