1.抽取 minio 当做文件对象存储服务器，在上面封装一层api，方便操作。
（文件上传，指定路径上传，随机命名上传，前端获取token直接传，适合大对象，图片压缩）
2.规范整个java项目代码，代码风格，依赖最小重构，nacos配置文件统一抽取配置，统一http客户端，json序列化方式，上K8s，编写JDK的基础镜像，Skywalking基础镜像，统一异常TranceId，Docke file ，k8s yaml 清单实现优雅停机，定时任务全局开关，保证服务宕机代码安全性。
3.订单列表。

（查询业务中台数据）进行按照平台订单号加店铺汇合。
因为我们没有订单表，只有包裹表，就是发出去的一个个包裹，还有退回来的包裹。
一个包裹就是一个Nid，一个包裹下有多条SheetNum。就是一个包裹里面的货，按照公司货号做唯一键的。
解决大数据量查询慢，我们一天5W订单。5年有1亿条数据，分到sheetnum上有，3亿条。
开始优化，筛选项什么不选，只查询最近三个月订单。输入时间项，带上时间。全部筛选项带上索引。聚合字段orderid和storename带上startrocks的hash索引。异步缓存。

订单：平台订单号，平台，店铺。
支付总金额（客户实付，零售价+税+平台物流费/自营物流费-优惠券（平台/商铺）/折扣）
盈利=客户实付-税-理论或实际物流费-店铺优惠-理论或实际退货运费-产品成本价-平台佣金-营销活动费。（记在单一产品编号上）

客户实付的钱，税（给国家），物流费（付出的物流），优惠（平台优惠不用减，店铺优惠减），退货运费（未发货分为实际和理论），产品成本价，平台佣金（家具类亚马逊，超过200美金部分收10%，低于15%），营销活动费（额外推广费用）

包裹，平台sku，公司sku，数量，产品链接，长宽高，说明书，产品标题，销售，asin。
物流，发货物流，追踪号，发货仓库，原单的收货地址，签收证明。

客户信息，原单的收货地址，邮箱，支付方式，电话，姓名。
售后信息。

4.改发货信息，改sku，对接内部OMS系统。

5.订单售后，（亚马逊、Ebay）取消订单(平台订单号，里面的Asin)。
退款（部分退款），选到单个sheet上。

调平台接口（实退金额、实退税额、实退平台运费额，实退平台运费税额），加起来就是客户实收。只需要实退金额、实退平台运费额，平台会自己算退税。

税，美国亚马逊代扣代缴，受到的钱没有税（平台把税直接给国家），欧洲的包含税（增值税，公司收到之后给国家）
但是我们在处理的时候，都会把这个税算进实付金额里面。对于客户来说这就是付的钱，假设退实付金额的80%，就是上面两个参数都成80%，除不下，保留两位小数向下取整。假设多次退款达到全退时，把所有的钱退出去。

退货，先查客户原单的地址信息，（和包裹的地址信息不一致），根据国家查出退货物流，客户地址，收货仓库,sku信息长宽高数量，计算出理论退货费用。进行生成退货面单，发给客户贴上发过来。

补发/重发业务流程一样，责任的问题，补发是我们的责任（发货点WMS的责任），重发就是货的问题（生产链的责任）

流程就是再发一个包裹过去。

老系统的问题是，平台运费税，算在商品税里面，导致计算税额的时候税少了，部分退款钱多退了，多退了一大笔钱。

客服工作台
收件箱，顾客对产品不满意，发邮件给亚马逊，我们的目标是把邮件转接给我们系统，之后分配售后的运营的客服，去进行回复处理，左边是对话框，右边是该订单的详细信息。
亚马逊商家号后台，配置阿里邮箱代理（买的），类似一个webhook，客户邮件一来，会发到阿里邮箱里面。我们在去定时任务去拉邮件，拉最近三天的，唯一消息id，重复的就不新增了。
拉邮件IMAP（邮件服务器地址），账号，密码。
识别内容，把订单号正则出来，亚马逊的就是733格式，找到店铺，根据预定的分配客服规则，把邮件分配出去。
发邮件，回消息。推邮件SMTP（邮件服务器地址），账号，密码。发给阿里邮箱，阿里邮箱会转发给亚马逊，亚马逊转给顾客。
会出现邮件带敏感词，转发不了给顾客，平台会回给我们，告诉我们敏感词。我们会把敏感词存下来，构建一颗ｔｒｉｅ树，下次发的时候会先排除敏感词，各个国家敏感词都不一样。
对接ＡＩ，客户邮件对接Ｇｐｔ，判断邮件的情绪，情绪差邮箱处理，还有ai一键润色。
每十分钟跑一次。跑半小时内的邮件数据。根据唯一键，去重。
库存管理

1.拉取某一平台某一店铺下的上架sku。调接口，token，翻页翻过去，下载到我们自己的库，这就是全部的上架SKU（AmazonVendor，excel后台导入的）（WalmartCa/Walmart/Wayfair/Shein）（有些会带上平台仓编号和具体数量）
2.本地仓，各个大区个各个仓库，平台仓，各个平台的各个店铺下。配置平台仓对于多个本地仓。
3.查询各个平台sku对应的公司sku在各个本地仓的数量总和，也就是平台仓的数量和。
4.根据配置的计算规则，目前是固定或者百分比策略。0-100/10 数量*百分比。
5.调用平台修改库存接口，入参平台sku、平台仓编号、数量。

多平台上架

1.新增SKU的本地属性，（包括基础属性、动态属性,可以自定义新增）
2.新增上架sku，（单体，变体，属性填充，填充本地属性做保存）
单体就是单个上架sku。变体就是SPU级别，卖个阿迪的篮球，红色、黄色，目的告诉平台这两单体都挂在同一个变体主的sku下面。
3.拉取上架平台的店铺对应类目下面的上架平台属性。
4.配置本地属性和平台属性的对应规则，一个平台属性只对应一个本地属性，一个本地属性可对应多个平台属性，绑定的时候还有自定义正则，比如要把产品标题，某些品牌字符替换掉。
5.把配置好的上架sku进行上架listing，通过上架sku的本地属性就可以找到平台属性，调用平台接口进行上架。
接下来要做的：
5.黑词管理，上架的时候这个类目下面，每个属性下面，有些敏感词，写了这些敏感词上架极大可能会被下架或者侵权，黑词的源数据都是我们运营总结，会被下架，侵权。
6.下架管理，接到全部的下架sku。

调平台接口的过程，Temu（拼多多海外版）
1.查类目，catId=0， 响应全部的一级类目，Parentid，level=1。循环递归，先把这个平台所有的类目，存表，多层级的表。
2.根据类目id查上架模板，基本信息必填或非必填属性，还有层级和下拉关系，最大字符，文本类型。图文信息，资质信息。还有商户的自定义属性，这个自定义属性，我们可以提前调用接口，传给平台。
3.拿上架平台上架属性，变体，挂单体。多变体一起上架。传入对应属性，调接口，返回一个上架处理唯一号，对平台来说是异步的，需要审核什么的。
4.拿着这个唯一号，去查询是否上架成功，上架成功会有基本属性，还有自定义属性。