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.拿著這個唯一號，去查詢是否上架成功，上架成功會有基本屬性，還有自定義屬性。