附註
Dynamics 365 Commerce 的零售興趣群組已從 Yammer 移至 Viva Engage。 如果您無法存取新的Viva Engage社群,請填寫此表單 (https://aka.ms/JoinD365commerceVivaEngageCommunity) 以新增,並繼續參與最新的討論。
本文提供 Dynamics 365 Commerce 中建立及管理銷售價格流程的資訊。 內容聚焦於該流程中涉及的概念,以及銷售價格各種設定選項的影響。
術語
本文使用下列術語。
| 期間 | 定義、使用及注意事項 |
|---|---|
| 價格 | 產品在銷售點 (POS) 用戶端或銷售訂單中銷售的單一單位金額。 在本文中,價格一詞始終指銷售價格,而非庫存價格或成本價格。 |
| 基準價格 | 在已發佈產品的價格欄位中設定的價格。 |
| 貿易合約價格 | 透過使用價格 (銷售) 類型的交易協議,在產品或變體上設定的價格。 |
| 最佳價格 | 當多個價格或折扣可應用於產品時,會選擇產生客戶需支付最低淨額的最小價格金額和/或最大折扣金額。 在本文中,最佳價格的概念始終稱為「最佳價格」。此最佳價格與折扣併行模式中的最佳價格列舉值不同且不可混淆。 |
價格群組
價格群組是商務中價格及折扣管理的核心。 價格群組用來指派價格及折扣給商務實體 (即通路、目錄、聯盟及會員計畫)。 由於價格群組用於所有價格和折扣,啟動前規劃使用方式非常重要。
價格群組本身只是名稱、描述及 (選用) 定價優先順序。 關於價格群組,主要需記得的是它們用來管理折扣與價格與商務實體之間的多對多關係。
下圖展示價格群組的使用方式。 在此圖中,請注意「價格群組」確實位於價格與折扣管理的核心位置。 左側是可用於管理不同價格與折扣的商務實體,右側則是實際的價格與折扣記錄。
建立價格群組時,不應用單一價格群組管理多種商務實體類型。 否則,可能難以判斷為何特定價格或折扣被應用於交易。
如圖中紅色虛線所示,商務確實支援直接在客戶上設定價格群組的 Microsoft Dynamics 365 核心功能。 不過,在此情況下,僅能使用銷售價格交易協議。 若要應用特定客戶價格,建議不要直接在客戶上設定價格群組。 應改用聯盟設定。
若價格群組設定在客戶上,則此價格群組會與該客戶的銷售訂單標頭關聯。 若使用者變更訂單標頭的價格群組,舊價格群組僅會被新價格群組取代於目前訂單。 例如,舊價格群組不會影響目前訂單,但仍與該客戶關聯以用於未來訂單。
以下章節提供更多關於使用價格群組時,可用於設定不同價格的商務實體資訊。 所有這些實體的價格及折扣設定為兩步驟流程。 這些步驟可任意順序完成。 不過,邏輯順序是先在實體上設定價格群組,因為此步驟通常在實施時一次性完成。 接著,建立價格與折扣時,您可逐一在這些價格與折扣上設定價格群組。
通路
在商務行業中,不同通路設定不同價格很常見。 影響通路特定價格的兩個主要因素是成本與當地市場狀況。
- 成本 - 通路距離產品來源越遠,備貨成本越高。 例如,新鮮農產品保鮮期有限且有特定生產要求 (例如生長季節)。 冬季時,新鮮萵苣在北方氣候的成本通常高於南方氣候。 若為涵蓋大地理區域的通路設定價格,通常會在不同通路設定不同價格。
- 當地市場狀況 - 有直接競爭對手的店鋪價格敏感度較高,反之則較低。
隸屬關係
聯盟的通用定義是與某群體的連結或關聯。 在商務中,聯盟是客戶群組。 聯盟在客戶價格及折扣管理上,比 Microsoft Dynamics 365 的客戶群組和折扣群組更靈活。 首先,聯盟可同時用於價格及折扣,而非零售定價則有不同群組分別對應折扣與價格。 其次,客戶可屬於多個聯盟,但每種類型的非零售定價群組僅能屬於一個。 最後,聯盟雖可設定為與客戶關聯,但非必須如此。 即席聯盟可用於 POS 上的匿名客戶。 匿名聯盟折扣的典型例子是長者或學生折扣,客戶只需出示群組會員卡即可享折扣。
雖然聯盟多與折扣關聯,也可用於設定差異化定價。 例如,零售商賣給員工時,可能想調整售價,而非在正常價格上疊加折扣。 又如,零售商對取用者客戶與商業客戶同時銷售時,可能根據採購量給商業客戶較佳價格。 聯盟支援上述兩種情境。
酬賓方案
就價格與折扣而言,會員計畫是一種特殊命名的聯盟。 會員計畫同樣可設定價格與折扣,如同其他聯盟一樣。 然而,客戶在交易或訂單中獲得會員定價的方式,與他們獲得聯盟定價的方式不同。 客戶只有在交易中加入會員卡時,才能獲得會員定價。 當會員卡被加入交易時,會員計畫也會被加入。 會員計畫隨後啟用特殊價格和折扣。
會員計畫可設有多個階層,不同階層的折扣也可能不同。 透過此方式,零售商能夠給予常客更大的獎勵,而無需手動將這些客戶歸入特別群組。
會員計畫除了價格與折扣之外,還有其他功能。 不過,從價格與折扣的角度來看,它們與聯盟是相同的。
目錄
部分零售商會使用實體或虛擬目錄,針對特定客戶群行銷產品並設定價格。 作為透過目錄進行目標行銷的商業模式的一部分,這些零售商可在不同目錄上設定差異化價格。 Microsoft Dynamics 365 支援此功能,讓您能定義特定目錄的折扣與價格,正如您可定義通路特定或聯盟特定的折扣一樣。 編輯目錄時,您可將價格群組與目錄關聯,就如同可將價格群組與通路、聯盟或會員計畫關聯。
價格群組的最佳做法
不要將價格群組用於多種實體類型。 應針對通路使用一組價格群組,針對聯盟或會員計畫使用另一組價格群組,依此類推。 您可以在價格群組名稱中使用首碼或尾碼,以視覺上區分您所使用的各種類型價格群組。
避免直接在客戶身上設定價格群組。 應使用聯盟。 如此一來,您可以為客戶指派所有類型的價格與折扣,而非僅限銷售價格交易協議。
定價優先順序
定價優先權本身僅是數字與描述。 定價優先權可應用於價格群組,也可直接應用於折扣。 使用定價優先權時,零售商可透過控制價格與折扣套用順序,覆寫最佳價格原則。 數字較大的定價優先權會先於數字較小的定價優先權被評估。 此外,若在某優先權數字下找到價格或折扣,所有優先權數字較低的價格或折扣將被忽略。
價格與折扣可來自兩個不同的定價優先權,因為定價優先權分別適用於價格與折扣。
要對價格使用定價優先權,必須將定價優先權指派給價格群組,然後為該價格群組建立銷售價格交易協議。
定價優先權功能是為支援零售商想在特定門市套用較高價格的情境而引入的。 例如,零售商為美國東岸定義區域價格,但想在紐約市門市對某些產品訂較高價格,因為在市區販售某些產品成本較高,及/或因當地市場可接受較高價格。
如本文「最佳價格」段落所述,定價引擎通常選擇兩個價格中的較低者。 因此,零售商無法在同時包含東岸及紐約價格群組的門市使用較高價格。 在定價優先權功能引入之前,為解決此問題,零售商必須為每項產品設定兩組價格,且不能同時指派兩個價格群組。 或是必須建立額外價格群組,以隔離高價產品與正常低價產品。
然而,定價優先權功能讓零售商能為門市價格設定比區域價格更高的優先權。 或是零售商可僅為門市價格設定定價優先權,並將區域價格維持預設優先權 0 (零)。 這兩種設定都能確保門市價格優先於區域價格使用。
定價優先權範例
以下為門市價格優先於其他價格的範例。
一家國家/區域零售商以區域為單位設定大多數價格,共有四個區域:東北、東南、中西部與西部。 該零售商識別出數個能支持較高價格的高成本市場。 這些市場位於紐約市、芝加哥及舊金山灣區。
本範例使用東北區域。 門市 1 位於波士頓,門市 2 位於曼哈頓。 波士頓門市的通路連結兩個價格群組:東北與門市 1。 曼哈頓門市的通路連結三個價格群組:東北、紐約市與門市 2。
零售商設定兩個定價優先權:高成本優先權數字為 5,門市價格優先權數字為 10。 (請記得,預設定價優先權為 0 (零),數字較高的價格或折扣優先使用於數字較低者之前。) 東北價格群組的定價優先權維持預設值 0 (零)。 紐約市價格群組的定價優先權設為 5,因紐約市為高成本市場。 門市 1 與門市 2 價格群組的定價優先權皆設為 10。
零售商販售的兩項產品為產品 1,一件普通 T 恤,以及產品 2,品牌時尚牛仔褲。
| 產品 | 東北價格 | 紐約價格 | 門市價格 |
|---|---|---|---|
| T 恤 | $15 | 未設定 | 未設定 |
| 時尚牛仔褲 | 50 美元 | $70 | 未設定 |
T 恤在波士頓與曼哈頓門市的售價相同 (即 $15),因為東北價格群組中只設定了一個價格,而該價格群組同時連結這兩個通路。 時尚牛仔褲在波士頓門市售價為 $50,因為該門市僅有這個價格。 然而,在曼哈頓門市,有兩個價格可用:$50 與 $70。 因紐約市價格群組的定價優先權為 5,較東北價格群組的 0 (零) 優先權高,故在 POS 系統中以 $70 計價。
附註
對每個定價優先權,零售定價引擎需完整執行邏輯流程。 因此,為維持價格與折扣計算效能,應謹慎使用定價優先權。
價格類型
在 Microsoft Dynamics 365 中,您可以在三個地方設定產品價格:
- 直接在產品上 (基本價格)
- 銷售價格交易協議中
- 價格調整中
基本價格與交易協議價格是 Dynamics 365 核心功能的一部分,即使不使用 Commerce 也可使用。 價格調整功能僅在 Commerce 中提供。 下一節將介紹這些設定價格選項的詳細資訊,並說明這些選項如何互相搭配運作。
設定價格
基準價格
設定產品價格最簡單的地方是直接在產品上設定。 您直接在產品上設定的值通常稱為該產品的基本價格。 您可在已發佈產品詳細資訊頁的銷售索引標籤中的價格欄位設定基本價格。 您輸入的值是以公司貨幣計算。 預設情況下,價格是基於銷售索引標籤中單位欄位設定的計量單位 (UoM) 且數量為 1。實際單價取決於計量單位、價格數量及貨幣。
如果產品對所有人只有一個價格,基本價格是管理該產品價格最有效率的方式。 即使您使用交易協議設定價格,也可能在產品上設定基本價格。 如此一來,如果您不使用全部交易協議,當沒有適用交易協議時,仍有備用價格可用。
若通路貨幣與公司貨幣不同,該通路中的基本價格會透過對產品上設定價格的貨幣轉換決定。
雖然價格單位並非常見情境,但定價引擎支援此功能。 若價格單位設定為非 0 (零) 值,則單價為價格 ÷ 價格單位。 例如,若產品價格為 $10.00,價格單位為 50,則數量為 1 時價格為 $0.20 (=$10.00 ÷ 50)。
銷售價格交易協議
透過交易協議記錄,您可以為每個產品建立銷售價格交易協議。 在 Microsoft Dynamics 365 中,銷售價格交易協議有三種客戶範圍:資料表、群組與全部。 客戶範圍決定某銷售價格交易協議適用的客戶。
資料表銷售價格交易協議是直接在交易協議中設定的單一客戶價格。 此情境並非典型的企業對取用者 (B2C) 模式。 若發生此情況,定價引擎會使用資料表交易協議來決定價格。
群組銷售價格交易協議是最常使用的類型。 在非 Commerce 環境下,群組銷售價格交易協議用於簡單的客戶群組。 但在 Commerce 中,客戶群組概念已擴展為更通用的價格群組。 價格群組可連結至通路、聯盟、會員計畫或目錄。 有關價格群組的詳細資訊,請參閱本文前述「價格群組」章節。
附註
交易協議價格總是優先於基本價格使用。
價格調整
顧名思義,價格調整用於修改直接在產品上設定或透過交易協議設定的價格。 價格調整可用來降低或提高價格。 價格調整是零售商隨時間建立、追蹤與管理產品價格折讓的推薦方式。
價格調整有三種類型:百分比折扣、金額折扣與單位價格。 百分比折扣與金額折扣類型的價格調整,會一律套用於銷售交易。 然而,價格類型的價格調整只有在調整後的價格低於基本價格或交易協議價格時才會套用。 因此,如果價格調整中設定的價格高於未調整價格,該價格調整將不會被使用。
交易中產品價格的決定
交易中價格與折扣的計算原則是為客戶尋找最佳價格。 根據此原則,若發現多個價格,將使用最低價格。 此外,會採用能為整筆交易產生最大折扣額的折扣組合。 在某些情況下,單一產品需使用較小的折扣,以便讓交易中其他產品能使用更多折扣。
尋找最佳價格原則唯一的例外是「混合搭配最便宜折扣」選項。 此選項允許在產品被挑選與分組時,對零售商有利的最便宜折扣。 因此,當交易中產品數量超過符合最便宜折扣的條件時,定價引擎會選擇使客戶獲得最小折扣額的產品。
定價引擎會為每個產品返回三個價格:基本價格、交易協議價格與有效價格。
基本價格只是產品屬性,對所有人及所有地點均相同。
在銷售價格交易協議中,若尋找下一個選項設為是,則會採用所有適用銷售價格交易協議中發現的最低價格作為交易協議價格。 交易協議可透過價格群組或全部帳戶代碼查閱。 或是,交易協議可直接指派給客戶。 若尋找下一個選項設為否,則採用找到的第一個交易協議價格。 若找不到銷售價格交易協議,則交易協議價格設為基本價格。
有效價格是將交易協議價格加上適用於產品的最大價格調整所計算出來的價格。 若找不到價格調整,或計算出的有效價格高於交易協議價格,則有效價格設為交易協議價格。 適用的價格調整只能透過分配給通路、目錄、聯盟或會員計畫的價格群組找到。
類別價格規則
Commerce 中的類別價格規則功能提供簡便方式,為類別中所有產品建立新的交易協議。 此功能還能自動尋找類別中產品的現有交易協議並將其過期。
當選擇過期現有交易協議選項時,系統會為擁有有效交易協議的類別產品建立新的交易協議記錄。 不過,該記錄必須手動過帳。 此外,類別價格規則只能尋找使用相同價格規則 (即使用相同類別) 建立的現有交易協議。 若未使用相同價格規則,現有交易協議將不會過期。
價格可透過類別價格規則的價格規則與價格基礎欄位調整提高或降低。
在價格規則欄位中,選擇要使用的價格變動類型:
- 加價 - 以價格基礎的百分比計算銷售價格。 例如,成本為 10.00 元、售價為 15.00 元的產品,加價為 50%。
- 利潤率 - 以銷售價格的百分比計算利潤額。 例如,成本為 10.00 元、售價為 15.00 元的產品,利潤率為 33.3%。
- 固定金額 - 以加在價格基礎上的金額計算銷售價格。 例如,成本為 10.00 元、售價為 15.00 元的產品,固定金額為 5.00 元。
在價格基礎欄位中,選擇要修改的價格類型:
- 基本成本 - 零售商支付給廠商的金額。
- 基本價格 - 在套用交易協議和價格調整前的銷售價格。
- 目前價格 - 在套用交易協議和價格調整後的銷售價格。
若要輕鬆更新來自不同產品類別的多種產品價格,可將補充產品類別與類別價格規則搭配使用。
最佳做法
由於成本考量,Microsoft SQL Server Express 常用於通路資料庫。 請注意,SQL Server Express 有硬體限制及資料大小限制。 若規劃不當,可能快速達到 SQL Server Express 的資料大小限制。 此考量不僅適用於定價,也適用於產品的其他領域。 以下幾個最佳做法可幫助您減少資料大小:
若您使用交易協議且價格有變動,應透過設定結束日期來過期舊交易協議。 隨著時間推移,此方法有助於減少通路資料庫中保留的交易協議數量。 同時,也有助於減少定價計算演算法需處理的資料量。
若您的價格因產品變體而異,建議將產品基本價格設為最常見變體的價格。 然後,僅對例外的變體價格使用交易協議。 此方法可幫助減少交易協議記錄的數量。 因為在 Microsoft Dynamics 365 中匯入資料非常容易,所以您可能會想要為每一個產品的每一個變體匯入一筆交易協議。 然而,這種做法可能會產生許多具有相同數值的交易協議。 因此,它可能會不必要地增加您的資料量。
Commerce 會依照從最具體到最不具體的順序處理變體特定價格。 如果某個產品維度不影響價格,您就不需要為它定義交易協議。 例如,一個產品有三種顏色和四種尺寸,但價格只因尺寸而異。 如果您為每個變體定義一筆交易協議,則會建立 12 筆記錄。 相反地,您可以只為每個尺寸定義一筆交易協議,並將顏色維度留空。 在這種情況下,您只會產生四筆記錄。
或者,如果某個維度的每個數值不都會產生不同價格,您可以為產品主檔定義一筆交易協議,並將所有產品維度留空。 然後僅為會產生不同價格的各個維度值定義單獨的交易協議。 例如,如果 XXL 尺寸價格較高,而其他尺寸價格相同,您只需要兩筆交易協議:一筆給產品主檔,一筆給 XXL 尺寸。
含稅價格與未稅價格
在 Dynamics 365 中設定銷售價格時,您不需要指定所設定的價格是否包含稅金。 該數值僅代表價格。 不過,通路上的價格包含銷售稅設定可讓您設定通路的價格是否包含稅金。 此設定是在通路上設定的,甚至在同一間公司中也可能變更。
如果您同時處理含稅與未稅的價格類型,正確設定價格就非常重要,因為如果通路上的價格包含銷售稅設定被變更,客戶實際支付的總金額也會改變。
Commerce 價格與非 Commerce 價格的差異
單一的價格引擎會用來計算所有通路的價格:電話服務中心、零售門市與線上商店。 這有助於實現統一的 Commerce 情境。
價格設計是要搭配 Commerce 實體使用,而不是非 Commerce 實體。 具體來說,它是依據門市設定價格,而不是倉庫。
Commerce 價格引擎不支援以下定價功能:
不支援基於屬性的定價。
不支援廠商折扣轉嫁功能。
不支援通用幣別功能。 換句話說,即使交易協議已開啟包含通用幣別的切換項目,該交易協議仍只對所定義的幣別有效。
標準的 Supply Chain Management 價格引擎支援根據「要求出貨日期」、「要求收貨日期」及「目前日期」來計算價格。 但零售定價目前不支援這些數值。 原因是,在 B2C 情境中,客戶通常不會預期「要求的交貨日期」會影響商品價格。 在某些情況下,零售商同時有 B2B 和 B2C 的業務。 對 B2B 業務來說,根據交貨日期變更價格是很常見的。 這些零售商可以針對 B2B 業務使用 Supply Chain Management 價格,針對 B2C 業務使用零售價格。 零售價格僅在應用程式使用者被新增為電話服務中心使用者時才會生效,這樣零售商就能將某些使用者指派為使用 Supply Chain Management 價格的使用者,也可指派少數人使用零售價格。 換句話說,這些使用者應被新增為電話服務中心使用者。 此外,必須在商務參數頁面中價格與折扣標籤的其他區段中開啟使用今天的日期計算價格屬性。 如此一來,使用者可以繼續對 Supply Chain Management 價格使用「應收帳款」參數值中的「要求出貨日期」或「要求收貨日期」。 但零售價格仍會使用今天的日期來計算價格。
在交易協議中,Commerce 價格引擎僅支援以下維度:
- 產品維度:尺寸、樣式、顏色和設定
- 庫存維度:站點與倉庫
- 追蹤維度:序號
此外,只有 Commerce 價格引擎支援以下定價功能:
- 價格會依產品維度計算,順序為:最具體的變體價格 → 較不具體的變體價格 → 產品主檔價格。 若價格是使用兩個產品維度 (例如顏色和尺寸) 來設定,會優先於僅使用一個產品維度 (例如尺寸) 來設定的價格。
- 相同的價格群組可同時用來控制價格與折扣。
價格 API 強化
價格是影響許多客戶購買決策的最重要因素之一,許多客戶會在多個網站比較價格後才做出購買決定。 為了確保能提供具有競爭力的價格,零售商會密切關注競爭對手並經常舉辦促銷活動。 為了幫助這些零售商吸引客戶,產品搜尋、瀏覽功能、清單與產品詳細資訊頁面顯示最準確的價格是非常重要的。
Commerce 中的 GetActivePrices 應用程式介面 (API) 會傳回包含簡易折扣的價格 (例如不依賴購物車中其他項目的單一項目折扣)。 透過這種方式,顯示的價格會接近客戶實際支付的金額。 此 API 包含所有類型的簡易折扣:基於會員、基於會員、基於型錄與基於通路的折扣。 此外,API 會傳回套用之折扣的名稱與有效性資訊,使零售商能提供更詳細的價格說明,並在折扣即將到期時營造出緊迫感。