電商所謂營銷，歸根結底都是訂單金額的變化;如果我們清楚的知道訂單金額的計算流程是怎樣的，那麼我們只需要順著系統的計算流程做促銷，就不用擔心各種促銷型別之間產生重疊或者衝突的情況了。當我們知道這個關係後，就可以將營銷活動區分為三種型別：改商品價格、改商品小計價格、改訂單價格，因為無論什麼營銷歸根結底都是可以描述成改價格。

購物車中任何增刪查改都要重新計算促銷，所以促銷的計算變得尤為重要，感覺京東已經把促銷做到了極致。

從模式上來講，我們公司的促銷就相當於京東自營，所以很多也都是參考京東自營的，但我們還沒法做到像京東促銷那樣強大。

這裡，將我們做的促銷跟大家分享一下，只涉及後臺介面邏輯部分。

介面的功能就是輸入商品列表，返回加了促銷分組後的商品列表。

首先要宣告兩點：

一、不是通用的促銷設計，只是我們公司目前支援的促銷設計及邏輯;

二、作者水平有限，不會畫圖，所以圖畫得比較醜，也很粗，希望大家不要介意;

三、不談效能

廢話就不多說了，下面正式開始。。。

促銷型別

前面說了，促銷歸根結底是改價格。在我們這裡其它單品促銷就是改商品價格;而條件促銷就相當於改小計的價格;至於贈品促銷不設計改價格，可以認為是單品促銷的一種型別。

主流程

“同型別透過實體進行互斥、不同型別可以相互疊加。”這是別人總結的設計電商促銷系統的基本原則，我也比較認同。

上面介面主流程就是先應用單品促銷，再應用條件促銷。稍微再細化一點兒就是這樣的：

先處理贈品促銷，將贈品掛載到主商品(原先使用者新增的購物車中的商品我稱之為主商品)上，再應用單品促銷。

在進行單品促銷的時候，很有可能同一個商品命中多個單品促銷。這個時候只能取一個促銷，此處的計算邏輯是這樣的：

·優惠券力度最大的優先

·優惠力度相同時，取最新建立的那個(建立時間最新)

例如：

商品A命中四條促銷，分別是：【促銷1】直降2元，【促銷2】折扣8折，【促銷3】直降1元。假設A的原價時10元，那麼經過計算【促銷1】8元，【促銷2】8元，【促銷3】9元。這個時候，【促銷3】應該被剔除，假設【促銷2】的建立時間比【促銷1】要晚，那麼應該取【促銷2】。即商品A最終命中【促銷2】。原價10元，促銷價8元。

計算商品價格流程

稍微解釋一下：

特價：商品A原價12元，今日特價9.9元。

折扣：商品打幾折。

直降：商品A原價12元，今日直降3元，所以最終9元。且當促銷價低於原價的70%時恢復原價。

限購流程

這裡有兩點需要說明：

1、限購的話需要查訂單系統，但是剛才說了購物車中的任意增刪查改都要重新計算促銷，所以如果這裡直接調訂單的話可能訂單的頂不住(技術實力還比較薄弱，無奈!!!)，考慮到這裡我們冗餘了訂單資料，每次從本地資料庫去查。當然，這樣肯定不準，但是我們只保證90%的情況就可以了，所以這裡我們採用這種方式。

2、拆商品行。還是用上面的例子，商品A命中了【促銷2】，假設【促銷2】限購每人每單1件，而現在A 的數量時3，那麼我們會拆成2行，第一行商品A售價8元數量1件，第二行商品A售價10元數量2件。

條件促銷分組

同一個商品可能會命中多個條件促銷，而最終每個商品只能應用一個條件促銷(即每個商品最終只能屬於一個組)

我們說，同種型別的促銷不能疊加，不同型別的促銷可以疊加。在我們這裡，單品促銷和單品促銷不能疊加，條件促銷與條件促銷不能疊加，單品與條件可以疊加。

程式走到這裡，我們已經完成了單品促銷的處理，接下來處理條件促銷。在決定商品應該最終應用哪個條件促銷時，我們的原則是這樣的：

1、優先考慮滿足條件的促銷

這句話的意思是，假設商品A，商品B滿足【促銷1】滿100減20這個階梯，同時A和B又都命中了【促銷2】但是不滿足【促銷2】的條件，因為假設【促銷2】的最小階梯是滿150減30。那麼這個時候，雖然A和B都同時命中【促銷1】和【促銷2】，但A和B一起正好符合【促銷1】滿100減20的條件，所以這個時候促銷A和B應該最終取【促銷2】

2、同時滿足多個條件促銷時，取後建立的那個(建立時間最近)

還是上面的例子，假設A和B的總金額加起來是160元，那麼它們都滿足【促銷1】和【促銷2】，假設【促銷2】是後建立的，所以此時它們最終命中的條件促銷應該取【促銷2】。並且，之後應該講它們從【促銷1】的商品組中剔除(PS：因為一個商品只能屬於一個組，即只能應用一個條件促銷)。京東在這裡對每種促銷做了計算，把最終用哪個促銷的決定權交給使用者去選，我們這裡不搞這麼複雜。

說了這麼多，可能有點暈，下面舉個例子