需求背景
一、重构亚马逊listing，保证搞可用性、扩展性的数据结构与产品架构，并解决卡顿问题
需求描述
功能点1：搭建数据结构&取值【见文档“Amazon listing详情数据”】
功能点2：数据同步逻辑
一、第一步：获取“待获取实时数据”的listing队列
（一）场景“迁入新店铺、功能上线数据初始化、每月数据校准”：全量获取“All Listings Report”【API：https://developer-docs.amazon.com/sp-api/docs/reports-api-v2021-06-30-reference】
1、每月数据校准：每月1月3日中国时间19点（美国时间凌晨4点）执行
（二）场景“日常运营”：增量数据同步
1、listing参数变化-数据更新：数据源如下、更新逻辑见流程图【目的：保证listing参数与亚马逊后台同步】
①库存
1）FBA的SKU：NOTIFICATIONS API “FBA_INVENTORY_AVAILABILITY_CHANGES”
2）FBM的SKU
2.1）新系统改动的数据更新：本地任务 “本地listing数据更新”
2.2）老系统、后台改动的数据更新：REPORTS API “GET_MERCHANT_LISTINGS_DATA”【问题：涵盖订单、人为调整引起的变化，但时效性低-24h/次更新】
②价格
1）新系统改动的数据更新：本地任务 “本地listing数据更新”
2）老系统、后台改动的数据更新：REPORTS API “GET_MERCHANT_LISTINGS_DATA”【问题：涵盖人为调整引起的变化，但时效性低-24h/次更新】
③状态：NOTIFICATIONS API “LISTINGS_ITEM_STATUS_CHANGE”
1）status是返回一个状态数组，包含枚举buyable、discoverable、deleted；
返回buyable意为可购买，不返回buyable意为不可购买，
返回discoverable意为可见，不返回discoverable意为不可见，
返回deleted意为该listing将被删除
2）示例：意为“可购买、可见”
"Status": [
"BUYABLE",
"DISCOVERABLE"
③状态对应
Status=BUYABLE、DISCOVERABLE，listing_status=在售
Status=DISCOVERABLE，listing_status=售完
Status=DELETED，listing_status=删除
④商品名、商品描述、主图：NOTIFICATIONS API “BRANDED_ITEM_CONTENT_CHANGE”
PS、报告状态：NOTIFICATIONS API “REPORT_PROCESSING_FINISHED”
PS、接口
NOTIFICATIONS API：https://developer-docs.amazon.com/sp-api/docs/notifications-api-v1-reference
REPORTS API：https://developer-docs.amazon.com/sp-api/docs/reports-api-v2021-06-30-reference
2、有销量渠道SKU-数据更新【目的：保证相对较高的实时性；有销量SKU对价格、可售数的数据时效性要求更高、有销量SKU不一定发生了价格变动】
①每天6点、12点、18点、24点，获取亚马逊当天有销量的渠道SKU
1）数据源：ERP，RB_Report_OrderSourceSKUDay
1.1）该表数据更新频率：4次/天
1.2）OrderSourceID=1，为亚马逊平台；OrderSourceSKU，为渠道SKU；SalesNum为销售数量
②处理逻辑
1）获取“OrderSourceID=1、SalesNum≠0、SalesDay=当天”的渠道SKU
2）对比：本次SalesNum是否与今日、上次的值一致
3）如果一致，则过滤掉此渠道SKU
4）如果不一致，则将渠道SKU记录到“待获取实时数据”listing队列
二、第二步：获取实时数据
1、1h、4h/次，获取实时数据，用“在售、已下架、不可售”状态listing的MSKU批量获取listing详情数据&并落库【https://developer-docs.amazon.com/sp-api/docs/listings-items-api-v2021-08-01-reference#getlistingsitem】
2、本接口返回的“状态”，如果不等于上一个接口的状态，则以此接口状态，更新listing状态
3、本接口返回的FBM_Listing、FBA_Listing的“可售库存、价格”，更新到本地listing表
PS、目的：保证数据实时性、同时减少数据拉取量
三、更新本地listing数据
1、从“listing管理”调用feeds-API-上传“价格、可售数”模板（见文件夹“价格、可售数模板”）来调整“价格、可售数”，收到异步回执“成功”，则按成功的数据更新本地listing的“价格、可售数”数据
2、1h/次，获取亚马逊订单-各SKU数量（记录该SKU对应的listing），再根据SKU数量，更新对应本地listing的“可售数”
PS、涉及API：https://developer-docs.amazon.com/sp-api/docs/feeds-api-v2021-06-30-use-case-guide【刊登接口】
PS、设计目的：价格、可售数主要依赖本地listing的数据更新，减少与平台交互
四、修改FBM的可售库存、修改FBM\FBA的价格
1、文本框失焦时，判断是否与原值有差异，有差异则以该listing，调用刊登接口
PS、涉及API：https://developer-docs.amazon.com/sp-api/docs/feeds-api-v2021-06-30-use-case-guide【刊登接口】
五、销售&店铺，对照关系
（一）调研内容&调研结论&方案确认
1、行为：销售会每月统计“正常运营的店铺、店铺负责人变更-店铺A负责人变更为C”
2、问题：销售去系统更新店铺负责人不及时，导致2类情况，C在listing页，搜自己搜不出“店铺&lsiting”、搜店铺&lsiting“名字不是自己”
3、不及时、没法确定时间的原因&当前解决方案：
①C的工作规划如果是本月15号开始做这个店铺，15号再改负责人也没问题
②操作时，看到不是自己名字，会汇报给上级去刷
③销售一般是月度调整，因为涉及业绩统计
4、listing/渠道SKU授权：B把店铺中的SKU授权给C，业务意义为“店长背负整个SKU业绩考核，店员分担”【当前考核方式：某几个SKU由C卖，可以刊登到C负责的店铺去（具体上架到哪些店铺：部分有要求），来完成对此SKU的业绩考核】
①店铺负责人不是C，B把其中的渠道SKU授权给C，能看到listing
②授权listing/渠道SKU后，会授权SKU权限
③SKU权限+店铺权限=渠道SKU（能看哪些listing）。与身份无关-店铺负责人、渠道SKU负责人
5、小结：当前解决方案、销售操作无问题。梳理出了最新对照关系，没改因为不需要改
6、结论：新listing页的“销售&店铺对照关系”：以系统的对照关系
（二）方案：“订单来源渠道管理”，取“来源渠道类型=亚马逊”的数据“首选业务员”是销售“渠道名称/真实店铺名称”是店铺
