本節書摘來自華章計算機《SAP CRM管理與實施指南》一書中的第2章，第2.2節,作者：鄒蔭文 著，更多章節內容可以訪問云棲社區“華章計算機”公眾號查看。

2.2　SAP CRM基礎功能

本節介紹SAP CRM的一些基礎的通用功能，主要包括合作伙伴處理、業務事務處理、定價與條件技術、日期管理、CRM的操作管理、文本管理及調查問卷管理等。這些功能在銷售、服務及營銷等各種業務流程中均被廣泛使用，具有很強的通用性。
2.2.1　合作伙伴處理
業務處理中，通常有多種類型的合作伙伴參與各類業務，并承擔著不同的功能，如負責員工、銷售經理、潛在客戶及聯系人等。合作伙伴處理指確定事務處理中可用的合作伙伴職責功能、確定參與的合作伙伴以及設定對合作伙伴的控制。
1.?合作伙伴功能
合作伙伴功能用于描述參與事務的業務合作伙伴所承擔的功能角色。例如售達方、送達方、開票方、收票方、負責員工、聯系人、銷售經理及渠道合作伙伴等都可以是合作伙伴功能。系統提供諸多標準的合作伙伴功能，可以根據業務需求通過配置自行定義。合作伙伴功能有一個編號、描述、縮寫，選擇功能類別，比如員工類或聯系人類等。
合作伙伴功能類別用來指定合作伙伴功能的分類和性質，由系統程序代碼中固定，如售達方、送達方及服務接受方、活動伙伴及員工等。在定義合作伙伴功能時可以指定一個關系類別，該類別可以用與合作伙伴確定。例如銷售經理和負責員工都屬于員工類別，而潛在客戶和活動合作伙伴（Activity Partner）均屬于活動合作伙伴。
見圖2.31“商機中的合作伙伴功能”（路徑：銷售專員業務角色>銷售周期>商機），列出了商機中的業務合作伙伴功能，其中聯系人、銷售小組及相關方都屬于合作伙伴功能，比如這里列出了銷售代表、負責人及活動伙伴（潛在客戶）。銷售代表和負責人通常創建商機時根據一定的規則自動確定。

圖2.31　商機中的合作伙伴功能
在合作伙伴主數據中，可以設置該合作伙伴不能使用的合作伙伴功能（即被排除的合作伙伴功能）。例如某個合作伙伴不能作為開票方和收票方，因為其只能作為售達方使用；競爭對手不能作為售達方等。在事務維護中，指定合作伙伴時，系統檢查該合作伙伴是否可以用在該合作伙伴功能上，如果不能使用，則可以提示錯誤信息，阻止事務的開展。
2.?合作伙伴的自動確定
在事務處理中，系統可以根據系統中所定義的業務規則自動確定合作伙伴。合作伙伴確定中可以使用多種來源的信息，如合作伙伴主數據、組織結構數據及相關業務背景信息，如事務類型等。例如創建銷售訂單時，用戶錄入售達方，系統即自動讀取該售達方的主數據及關系數據確定該售達方相關的送達方、開票方、聯系人及負責員工等合作伙伴。
合伙人確定過程：合作伙伴確定過程中包含了一個或者多個合作伙伴功能以及對每個合作伙伴功能的確定設置和控制，例如圖2.32“合作伙伴確定過程”（路徑：配置>CRM>基本功能>基本功能>合作伙伴處理>定義合伙人確認過程），這是標準的銷售訂單中的合作伙伴確定過程，包括的合作伙伴功能有售達方、收貨方、收票方、付款方及負責
員工。

圖2.32　合作伙伴確定過程
合作伙伴確定過程中的主要設置和控制功能有：
全局設置：該確定過程是否不啟用自動確定功能，即“凍結確定”，凍結后系統不執行自動確定的程序；是否記錄合作伙伴確定過程的日志；允許使用僅在合作伙伴確定過程中指定的合作伙伴功能，還是可以使用系統中所有的合作伙伴功能。這些全局配置在合作伙伴過程的抬頭中設置。
在“程序中的合作伙伴功能”中，選擇可用的合作伙伴功能，可以選擇能在事務中使用的合作伙伴功能。
最大最小數量：可以設置合作伙伴功能的最大最小值，即對該合作伙伴功能，最大或最小可以錄入多少個合作伙伴。如果最小值設置為1，則該合作伙伴必須填寫。
是否可以更改：即確定或錄入后，是否可以將該合作伙伴修改成其他合作伙伴。
可變地址：事務處理中，是否可以修改該合作伙伴的地址。例如在銷售訂單中，通?？梢栽谟唵沃行薷乃瓦_方的地址（即默認從送達方主數據中獲取送貨地址信息，如果需要，可以在訂單中修改，成為訂單特定的合作伙伴功能地址）。
日歷：是否將此事務放置到該合作伙伴的日歷中，通常用于業務活動處理中。
存取順序：系統根據什么規則確定合作伙伴。
確認時間：系統什么時候觸發自動確定合作伙伴的功能。
用戶程序：指定該合作伙伴程序所使用的事務類別和行項目類別，例如用于銷售、服務合同等業務中。
界面設置：可以設置顯示合作伙伴的字符串順序，例如編號和地址順序。
合作伙伴確定過程可以分配給訂單類憑證抬頭，即事務類型，也可以分配給憑證的行項目。合作伙伴確定也可以分配到營銷對象及產品類別等業務中，以便在營銷計劃、營銷項目、對象和產品中使用合作伙伴功能。
見圖2.33“合作伙伴功能確定設置”（路徑：配置>CRM>基本功能>合作伙伴處理>定義合伙人確認過程>功能明細），設置售達方功能的控制參數，即錄入后，不可更改，必須填寫或確定售達方，可以修改地址，使用了0001先前憑證作為存取順序，確認時間為
經常。
合作伙伴確定存取順序：通過存取順序為系統確定合作伙伴的順序和策略，即在事務憑證中，根據何種數據源（前序憑證、合作伙伴、組織數據、用戶及崗位等數據）自動尋找并確定滿足條件的業務合作伙伴。如果多個合作伙伴滿足條件，系統會列出供選擇。見
圖2.34“合作伙伴功能的存取順序”（路徑：配置>CRM>基本功能>基本功能>合作伙伴處理>定義合伙人確認過程>功能明細），0001的存取順序，該存取順序包含兩個存取10與20，系統先根據訪問數序10從數據源先前憑證的活動合作伙伴中讀取，如果未找到，系統就存取20中查找。這里的數據源為COM_PARTNER_A即先前憑證，系統從先前憑證中讀取指定合作伙伴功能的數據，然后復制到目標合作伙伴功能（售達方）中。數據源即指定系統如何尋找合作伙伴的具體規則。系統提供了合作伙伴確定的數據源，并且可以通過BADI自定義數據源。
在線索及商機等事務中，可以使用重新確定合作伙伴的功能。例如當用于確定合作伙伴的數據已經修改，這是可以重新手工觸發合作伙伴確定的功能。在事務抬頭工具欄中，可以點擊重新確定合作伙伴，系統即重新運行合作伙伴確定過程確定滿足條件的合作伙伴?？梢赃x擇添加新合作伙伴、替換已存在的合作伙伴。添加新合作伙伴時，系統保留已確定或已錄入的合作伙伴。替換已存在的合作伙伴即清除已確定或錄入的合作伙伴，重新確定合作伙伴。在商機的購買中心中，合作伙伴的類別為聯系人，重新確定購買中心的合作伙伴時，新增聯系人的屬性為空，需要設置屬性如影響程度以及和其他聯系人的關系；替換已有聯系人后，系統先刪除原有聯系人，然后使用新聯系人，但原有聯系人的屬性和關系將被刪除。
推薦可替換的合作伙伴：即在事務中可以手工選擇其他滿足條件的合作伙伴。例如，客戶有兩個聯系人，在憑證中已經確定并選擇其中一個，但后來需要修改成另外一個聯系人，即可以使用推薦功能，系統列出兩個聯系人供重新選擇。
3.?合作伙伴相關的其他功能
合作伙伴處理與合作伙伴主數據：合作伙伴主數據是合作伙伴處理的重要數據，其中合作伙伴主數據的關系尤為重要。關系分成兩類，一類是通用的關系，與銷售范圍無關；一類是銷售范圍相關的，設置在具體的銷售范圍中，該關系僅對設定的銷售范圍相關（在合作伙伴關系維護中，選擇用法，然后在用法中選擇銷售范圍并選擇該銷售范圍下的合作伙伴功能）。在合作伙伴確定過程中這兩種類型的客戶關系均可以使用。
維護組織模型時，系統為組織單元生成合作伙伴數據，擁有組織單元的角色，可以應用到合作伙伴處理中使用。如在跨公司開票中，組織單元本身可以作為開票方。系統使用組織數據確定的規則確定組織單元所對應的合作伙伴，使用的數據源為CRM_PARTNER_B（根據組織數據確定合作伙伴），需要指定組織結構確定規則。
合作伙伴團隊：合作伙伴團隊是與特定的商機相關的一組客戶或者人員。在商機中稱為購買中心，購買中心中的成員均為聯系人，合作伙伴功能類別為聯系人，承擔一定的功能，具有一定的關系，對項目的影響和重要程度也不盡相同。更多關于購買中心的功能可以參考4.2.4.2節的“購買中心”部分。
合作伙伴處理的基本配置路徑為：配置>CRM>基本功能>合作伙伴處理，可以定義合作伙伴功能、存取順序及合作伙伴確定過程等。
技術指南：
線索和商機等事務中使用合作伙伴重新確定功能時，需要：啟用BADI ES_CRM_PARTNER_REDETERMIN的實施ES_CRM_SET_ACTIVE；在系統用戶參數中，需要將參數CRM_REDETERMINATION設置為X（事務代碼SU3），事務對象必須維護在表格COMS_PARTNER_DET中，例如線索、商機、申索（Claim）及預付款申請。在合作伙伴功能定義中，可以設置是否凍結重新確定，如果選擇凍結，則該合作伙伴功能確定或錄入后，不會被重新確定（路徑：配置>CRM>基本功能>合作伙伴處理>定義合伙人功能）。
合作伙伴確定的關鍵函數為COM_PARTNER_DETERM_STEP_ONE_OW，從中可以了解合作伙伴確定過程邏輯。合作伙伴確定數據源COM_PARTNER_A（先前憑證）、COM_PARTNER_B（分配到用戶的合作伙伴）以及COM_PARTNER_C（當前合作伙伴_C）等通過參數配置實現，即在存取過程中使用這些來源時可以指定一些參數，例如使用的源合作伙伴功能和功能類別，由COM_PARTNER_DETERM_STEP_ONE_OW中直接獲取。來源COM_PARTNER_X、COM_PARTNER_Y、COM_PARTNER_Z由BADI COM_PARTNER_BADI實現；其他來源通常通過增強BADI COM_PARTNER_DETERM自行定義。系統使用該業務增強實現了諸多合作伙伴確定邏輯，可以根據實際情況靈活采用。例如來源CRM_PARTNER_C使用的合作伙伴中通用的關系，而CRM_PARTNER_A使用了合作伙伴的銷售范圍相關的關系。
SAP CRM和SAP ERP在合作伙伴處理各有特點，并且通常需要做一定的映射關系，以便能正確的交換客戶及訂單等數據。ERP中，員工、客戶和供應商屬于不同類型的合作伙伴，需要在不同的應用中維護，使用不同的數據表；而CRM中的合作伙伴使用相同的數據表，通過角色區分，只需維護一次即可以在多個應用中使用。ERP中使用賬戶組，而CRM通過角色確定分類；ERP和CRM交換客戶數據時，需要在ERP 事務代碼PIDE中進行映射；CRM中使用搜索策略搜索和確定合作伙伴，而ERP確定數據來源較少，通常使用客戶主數據、用戶、客戶層次結構、T024P及用戶出口進行確認，而CRM中可以使用合作伙伴、合作伙伴關系、前序憑證、事務中已有的合作伙伴、組織結構、定價層次結構、用戶及BADI等多種方式確定合作伙伴。
2.2.2　業務事務處理
CRM中的諸多業務和功能均以事務為基礎。事務通常是構成業務流程的基礎。本節首先介紹業務處理的基本結構和功能，然后介紹業務處理中的狀態管理功能。
2.2.2.1　基本結構和功能
業務事務（Business Transaction）是與客戶交互的核心對象，對客戶開展的營銷、銷售及服務業務均可以通過事務憑證體現。事務代表著與客戶在一定時間之內的各種業務交互，記錄相關信息與結果。在營銷管理中，線索也屬于業務事務；在銷售業務中，報價單、銷售訂單、銷售合同、銷售協議及商機等都為業務事務；在服務管理中，服務合同、服務請求、服務訂單、投訴、退貨、服務確認等都為業務事務。
業務事務具有相同的框架結構，具有相類似的基礎功能和數據確定方式。業務事務通常由抬頭和行項目組成，事務的抬頭由事務類型進行標識和控制，而行項目由行項目類別進行標識和控制。抬頭信息對整個事務起作用，如事務類型、創建時間及人員、抬頭合作伙伴、狀態、組織及抬頭日期等信息。行項目由產品組成，可以進一步設置行項目的分類、狀態及合作伙伴等信息。業務活動和線索通常沒有行項目。在業務事務配置上，主要需要考慮事務類型、業務事務類別、行項目類別及行項目對象類型。
1.?事務處理的基本功能
業務事務基于統一的框架和結構，具有一致的處理規范和方法。業務事務中集成了其他多種基礎功能，如定價、合作伙伴確定、日期確定、文本確定及操作確定等。事務處理的基本功能點參見表2.13。

2.?事務類型和業務事務類別
事務類型（Transaction Type），也稱為交易類型或業務類型，用于確定業務事務的性質以及相關的事務確定與處理，例如，如何確定合作伙伴、日期、文本及用戶狀態等。可以根據實際的業務需求，靈活定義各類事務類型。事務類型是事務處理的基礎，創建事務時，首先需要選擇或確定所用的事務類型，然后系統使用該事務類型的特性和控制功能。事務類型的關鍵分類是主要事務類別，其決定事務類型的性質和屬性。
系統提供諸多標準的事務類型，可以參考標準事務類型新建所需的其他事務類型，如銷售訂單可分成標準訂單、退貨訂單及寄售訂單等各種類型，但都屬于銷售訂單類別；銷售合同、報價單也屬于銷售事務；而服務訂單、服務合同、服務確認等為服務類的事務；營銷中的線索、費用申索、資金計劃及資金等也都屬于事務類型。在SAP CRM中也稱為統一訂單類的憑證（One Order），或者稱為訂單類憑證類型。
應用舉例：
業務活動：出差、拜訪客戶等使用的業務活動，交互記錄，任務及電子郵件等。
銷售訂單：分成B2B網上訂單、標準銷售訂單、退貨訂單、銷售報價單等。
服務訂單：分成常規保養訂單、大保養訂單、大修訂單、中修訂單、小修訂單。
見圖2.35“事務類型的基本配置”（路徑：配置>CRM>交易>基本設置>定義業務類型>明細），列出了標準的投訴憑證類型的基本配置信息。事務類型編號為四位字符串，自定義的事務類型通常為Y或Z開始，在描述字段中設定該事務類型的名稱。主要事務類別用于確定確定該憑證的業務分類與性質，如銷售訂單、服務訂單、投訴、線索、商機或業務活
動等。
事務類型通過諸多參數確定系務該如何處理該事務，如參數文件中指定相關數據的確定方式。見圖2.36“事務類型參數文件”（路徑：配置>CRM>交易>基本設置>定義業務類型>明細），為事務類型指定各種參數文件，如：文本確定過程、合作伙伴確定過程、狀態參數文件、組織數據確定參數文件、日期參數文件、操作（活動）參數文件及審批確定程序等。
　
　　
　　　　圖2.35　事務類型的基本配置　　　　　　　　　 　圖2.36　事務類型參數文件
事務類型通常是事務的基礎，牽引著諸多相關功能，在事務類型定義中，事務類型的主要功能點參見表2.14。

在事務類別分配中，一些常用的事務類別配置參見表2.15。

當然，有很多其他配置與事務類型相關，例如該事務類型所能使用的行項目類別，請參考相關章節的功能。事務類型的配置路徑為：配置>
CRM>交易>基本設置>定義業務類型。
3.?行項目類別及行項目對象類型
行項目類別（Item Category）是對行項目屬性、分類和控制的定義。行項目類別通常由事務類型及產品主數據的行項目類別組及用法共同確定。行項目類別中可以進行一些行項目的控制配置，如指定合作伙伴、文本、日期及操作等相關參數文件，
見圖2.37“行項目類別”（路徑：配置>CRM>交易>基本設置>定義項目類別>
明細）。
應用舉例：
銷售訂單行項目類別：分成標準行項目（需要開具發票）、免費行項目、退貨行項目。
服務訂單行項目類別：標準服務行項目（需要開票）、免費服務、服務計劃等服務診斷行項目。
行項目類別的主要配置和功能參見表2.16。

技術指南：
對象子類型：業務事務類別由一系列對象子類型（Subobjects）組成，子對象包含了具體的功能，如訂單抬頭、行項目、狀態、日期、活動抬頭及憑證流等一系列對象及處理，可以被多種事務重用。子類型可以分成多種類型，如抬頭、行項目、拓展（Extension）及數據集（Set）。系統中子對象的數據表為CRMC_OBJECTS。一個事務類型所能使用哪些子對象，由系統配置表CRMC_OBJECT_ASSI決定，而對象類型決定一個行項目類別所能使用的子對象類型，由數據表CRMC_OBJ_ASSI_I確定。事務類型的主要事務類別數據表為CRMC_SUBOB_CAT。一個主要事務類別只能與部分事務類別組合，例如銷售事務類別可以與業務活動事務類別組合，但不能與服務處理事務類別組合，這種組合關系由數據表CRMC_BUS_SUBOB_C決定。行項目類別可用的對象類型存儲在數據表CRMC_SUBOB_CAT_I中。事務類別決定該事務分配了哪些行項目對象類型，這由數據表CRMC_BT_BTI_ASSI控制，數據表CRMC_BUS_SUBOB_I確定行項目對象類型可以在哪些主要事務類別中使用。行項目對象類型可使用的子對象類型由表CRMC_OBJ_ASSI_I決定。
事務處理事件：事務的子對象與子對象之間是相對獨立的、低耦合度組織在一起的，系統通過事務的事件（Event）實現子對象之間的通信和相互影響。相關業務操作中會觸發相關的事件，通過事件的發布與訂閱機制啟動相關處理函數調用，即子對象之間不直接通信。系統提供了諸多預定義的事件及調用函數（Callbacks），同時可以自定義事件及調用。通過事務代碼CRMV_EVENT可以管理事務對象的事件，如抬頭狀態變更時，調用某個函數，執行一些操作等。事件管理中，可以對事務類型和行項目類別，確定相關的事件調用。在設計自定義事件函數調用時，需要考慮系統性能，最好限定特定的事務類別，減少調用的范圍，提升系統性能。CRM的事件具有一個完整的技術框架。有應用程序在適當的時點觸發事件（函數CRM_EVENT_PUBLISH_OW），通知事件處理句柄（Event Handler），事件處理句柄即注冊該事件并確定需要的調用（Callbacks），然后系統根據處理時間設置處理相關調用（如立即處理或事務處理后執行）。一個事件的觸發和執行可能會產生一系列其他事件的執行，因此在事件響應函數開發時需要限制數據處理的范圍，指定具體的事務類別、對象和參數，減少對系統性能的影響，請仔細閱讀事務代碼CRMV_EVENT的說明文檔。應用舉例：服務訂單中，添加備件行項目時，調用自定義事件，檢查是否需要自動添加相關的服務行項目；訂單處理中，創建或者修改行項目時，立即調用自定義事件，對相關數據進行檢查并且提示相關信息。
業務事務的增強：通過簡易增強工作臺EEW（Easy Enhancement Workbench）可以對事務進行增強，為抬頭、行項目等對象添加自定義字段和自定義表。也可以通過應用增強工具AET（Application Enhancement Tool）對事務進行增強，提供了EEW之外的一些補充功能?？梢酝ㄟ^業務插件BADI對事務進行增強，如抬頭變更、行項目變更及訂單保存時的檢查等。部分BADI如果使用不好，會對系統性能產生較大的影響，例如權限檢查、字段選擇、中間件自定義字段、復制控制及對象控制，因此實際應用時需要考慮這些BADI的性能問題，如果能夠指定具體事務類型的，建議指定具體事務類型，以提升效率。另外在多行項目的業務場景中，需要特別注意性能影響。
事務處理的性能優化：性能優化的定價功能，見SAP注釋1436942，優化了定價執行的接口，跨行項目的延遲定價等功能；使用開票請求行（Billing Request Lines）能夠提升合同維護的效率（性能比使用開票請求行項目Billing Request Items要好，但有一些限制）。事務的異步更新，即保存時系統在后臺異步更新數據，如果有錯誤，系統通過郵件等通知用戶，因此，用戶點擊保存后即可繼續使用其他功能，無需等待事務的保存處理。多行項目的事務中，系統針對行項目的顯示、搜索等處理進行了優化。
2.2.2.2　狀態管理
業務流程中，同一個憑證在不同時期可以處于不同的狀態。比如一個業務活動，開始時為打開（Open）或處理中，處理完成以后關閉。狀態表示當前該事務的處理情況，每個狀態均代表兩種功能，一是標識當前所處的特定狀態，如訂單已審批、服務單已釋放等，二是確定后續可以或者不可以執行的事務。系統執行一個事務時，系統可能會設置或者刪除該對象的一系列狀態。
事務狀態分兩種類型：系統狀態和用戶狀態，系統狀態由系統自有流程確定，執行相關事務時系統會自動觸發設置相關的系統狀態，通常無法手工直接修改，通常也無法自行定義。系統狀態起著對流程的系統控制作用，比如訂單釋放后復制到ERP系統，營銷執行項目中釋放以后才能創建后續的費用申索單等。而用戶狀態是可以根據實際業務需求自行配置設定，這樣系統就具有很強的靈活性，不同的業務流程可以使用不同的用戶狀態序列來實現流程管理與控制。用戶狀態由用戶狀態參數文件定義和決定，用戶狀態參數文件分配到事務類型或者行項目類別中。同時用戶狀態和系統狀態可以相互影響，比如用戶狀態設置為審批通過時自動設置系統為已釋放，將銷售訂單復制到ERP，即設置系統狀態為分銷到ERP。見圖2.38“商機中的狀態”（路徑：銷售專員業務角色>銷售周期>商機），這是一種類型的商機的用戶狀態，為打開、處理中、成功、失敗、停止及推遲等。
應用舉例：
業務活動的用戶狀態：分成打開、處理中、已完成及已關閉。
服務訂單處理的用戶狀態：打開、已分配、執行中、執行完成及關閉。
備件行項目用戶狀態：打開、已交貨、已開票、已關閉。（同時ERP中交貨后設置該項目的用戶狀態為已交貨，ERP中開票或者CRM中對該行項目開票后自動設置用戶狀態為已開票。）
1.?狀態參數文件
狀態參數文件將多個用戶狀態組織在一起，并決定相關的控制參數。事務處理中，事務類型和行項目類別均可以分配一個狀態參數文件。然后在該事務或行項目中即可使用對應的用戶狀態。見圖2.39“狀態參數文件”（路徑：配置>CRM>交易>基本設置>狀態管理>定義用戶狀態的狀態參數），狀態參數文件CRM ACTIV是CRM業務活動的標準的用戶狀態。

圖2.39　狀態參數文件

2.?業務事務與系統狀態
用戶狀態配置中可以設定允許操作或不允許操作的事務。系統狀態也可以控制允許或禁止使用的事務。見圖2.40“系統狀態”（事務代碼：BS22），為系統狀態已完成（I1005）的對事務處理的控制表，如允許、警告、禁止的事務。禁止即為該系統狀態下禁止執行該業務事務。業務事務由相關業務操作操作和事件觸發，例如釋放、關閉、設置為已完成等。系統狀態和用戶狀態可以相互影響。而在事務代碼BS33中，可以查看業務事務以及業務事務對系統狀態的影響（執行事務時對系統狀態無影響或者設置、刪除相關的系統狀態）。
業務事務具有一定的生命周期，系統通過五個狀態進行關鍵的生命周期控制，主要有：
1）打開（Open）：事務已經創建，但還未處理。
2）處理中（In Process）：事務正在處理中。
3）已釋放（Released）：釋放后，相關的后續事務可以觸發，如分發、開票、打印等。
4）已完成（Completed）：所有直接關聯的操作均以完成。
5）已關閉（Closed）：所有間接關聯的操作均已完成，整個事務結束。
事務處理中，可以在事務抬頭或行項目中設定拒絕或凍結原因，拒絕該事務或行項目，凍結交貨或凍結開票。
技術指南：
通過函數CRM_STATUS_CHANGE_FOR_ACTIV_OW可以執行相關業務事務或檢查一個對象是否可以執行某個業務事務。CRM_STATUS_SET_INTERN_OW可以修改系統狀態。部分修改狀態的函數不會觸發狀態變化的事件，需要了解相關函數的功能。程序CRM_STATUS_CON中定義了系統狀態和業務事務的全局變量，可以從變量定義中了解相關意義。
常用事務代碼：BS33（事務及事務對后續系統狀態的影響）；BS22（系統狀態以及系統狀態對業務事務的影響）；BS13（狀態參數文件中指定所用的對象類型，對象類型中包含了可用的業務事務）；BS03（狀態參數文件）。部分系統狀態可以通過工具欄按鈕等相關操作設置，表格CRMC_STATUS_PROC中維護的系統狀態可以在應用中手工觸發。
常用數據表：TJ30（狀態參數文件）、CRM_JEST（對象的狀態表）、CRM_JCDS（狀態更改歷史表）。其中CRM_JEST中記錄了事務抬頭及行項目所經歷的各種狀態以及標識了當前激活的狀態，包括系統狀態和用戶狀態。而CRM_JCDS中記錄了狀態的變更歷史，從中可以找到某個狀態變化時的具體時間。這兩個表數據量通常都很大，在大批量讀取時需要考慮性能問題。例如如果某個狀態變更的時間非常重要，可以考慮在訂單保存時加入到日期或擴展字段中，這樣能夠方便查看，讀取該狀態的時間時，性能通常會更好。
2.2.3　定價與條件技術
營銷、銷售和服務等業務中通常都會使用到定價，包括價格、折扣、運費及稅等各種類型。不同企業對不同的業務通常有不同的定價模式并且差別較大，要求定價引擎能夠具有足夠的靈活性和拓展性，以便能夠通過配置實現和適應企業的各類需求。SAP CRM具有靈活的定價機制，具有完整的定價引擎，基本功能與SAP ERP的定價引擎相同，能夠靈活的實現各類定價需求。本節首先介紹定價的維護和應用，然后介紹定價條件技術和配置，最后介紹使用定價條件相關的一些功能，如免費貨物。
2.2.3.1　定價的維護和應用
定價條件類型表示一種類型的價格，常用的價格條件類型有銷售價格、稅、運費及折扣等。定價條件類型可以根據實際的業務情況進行靈活配置，即根據一定的屬性組合，如銷售組織、產品、客戶、客戶組、產品組及定價組等定價字段，設定價格數據。在業務處理中，系統根據業務的具體信息自動確定價格數據。
1.?價格維護
可以在SAP CRM使用價格維護應用直接維護價格，也可以在其他多個應用和功能中維護價格數據，例如合同中的價格協議、產品、產品層次結構、合作伙伴、合作伙伴層次結構、營銷計劃、交易稅引擎、服務管理以及XIF接口中均可以維護條件。維護前需要選擇應用范圍，然后選擇定價條件，系統顯示該定價條件可用的字段組合，按照固定的定價字段組合維護價格數據。
見圖2.41“價格主數據”（路徑：銷售專員業務角色>銷售運行>價格），維護了客戶特定產品的價格，即價格和客戶、產品及銷售區域相關，選擇銷售組織、分銷渠道、產品和客戶，維護具體的價格，同時設定價格的有效期。在價格維護中，可以創建等級（Scale），即不同數量范圍段可以設置不同的價格，以實現階梯定價功能。
在（銷售/服務）合同和框架協議中，系統使用價格協議確定用戶可以享受的折扣或優惠價格。SAP ERP零售解決方案中的促銷價格也可以同步到CRM中，供CRM銷售訂單使用。

圖2.41　價格主數據
2.?價格清單
價格清單（Price List）為在一定有效期內向客戶出具的針對一定范圍產品的價格列表。價格清單使用已維護的價格條件主數據，以清單列表的形式展示?？梢詮目蛻簟a品及客戶產品范圍等主數據中創建價格清單?？梢詫r格清單輸出為PDF文件，可以打印預覽、打印及通過郵件發送給客戶。價格清單還應用于產品推薦、貿易促進管理中，即推薦產品時系統會列出產品的價格，計算貿易促進的價格。
3.?價格應用
價格主數據維護后，事務處理中即可自動確定相關價格。見圖2.42“訂單中的定價”（路徑：服務專員業務角色>服務訂單>明細），為服務訂單行項目中的定價，價格中列出各種價格要素（即為條件類型），價格與貨幣中列出該產品每個單位的基本價格，這里價格為499美元，共訂購了3個，所以結果值是499×3＝1497美元。使用簡易條件錄入功能，可以簡化事務中的價格維護。即在事務的行項目表格中直接填寫價格，無需進入行項目價格頁面中維護。通過系統配置，最多可以設置五個條件類型為簡易錄入的條件
類型。
可以在事務憑證的抬頭或者行項目中維護價格。通常抬頭顯示的價格由行項目定價加總而成。根據定價過程對條件類型的配置，系統可以自動確定價格條件，也可以由用戶手工錄入或修改已確定的價格。如果設置為不能手工錄入，該條件僅能通過定價條件主數據確定，用戶無法修改。如果某條件類型不在已有列表中，可以添加，選擇可用的價格條件，錄入價格?？梢灾匦聢绦卸▋r，重新執行時可以選擇是否要保留手工錄入的價格條件，也可以讓系統重新確定所有條件，即重置手工錄入或修改的價格。行項目開票以后，行項目的價格即被固定，不能再次修改。
4.?價格變更的審批
通過定價數據維護的權限和工作流設置，可以實現價格變更審批功能。即當用戶沒有權限修改事務憑證中的價格時，用戶仍然可以在憑證中修改價格，但該價格處于未激活狀態，同時系統啟動價格維護審批工作流，審批人員對該價格的修改進行審批。審批通過后，該價格條件才生效，設置為激活狀態，如果審批不通過，則該價格條件無效，不參與憑證的價格計算。
技術指南：
在營銷活動、產品、客戶以及價格維護應用本身能夠維護哪些條件類型的價格數據，由條件維護組決定。價格數據最終保存在條件數據表中。條件維護組中指定了可供維護的條件表和條件類型的組合，即如果一個條件類型由多個條件表組成，可以在條件維護組中維護多條記錄，維護時即可選擇對應的條件表和條件類型組合。例如條件類型0PR0（價格），可以使用SAP004（產品價格）和SAP005（客戶產品價格）條件表。不同的應用場景可以使用不同的條件維護組，例如客戶、產品和價格維護應用中，可以指定可用的條件維護組。配置路徑為：配置>主數據>條件和條件技術>條件技術：基礎>創建條件維護組以及定義上下文的維護組。
標準的價格清單所用的定價過程為0NPL01，包含0PR0價格和客戶或物料相關的折扣價格條件。價格清單類型確定價格清單的屬性和操作，包括所用的定價過程（因此能使用該定價過程中的條件類型所對應的價格），輸出所用的活動參數文件等，價格清單的配置請參考：配置>主數據>價格清單。通過事務代碼SMARTFORMS編輯智能表單BEA_CNPL_BILLING_SF，調整價格清單PDF文件的格式和內容。通過程序BEAR_CNPL_PDL_PROCESS可以創建價格清單，而程序BEAR_CNPL_PL_PROCESS可以重新計算價格清單中的價格。這兩個報表程序均可以設置成后臺作業定期運行。
系統配置中可以為定價過程設置五個用于簡易價格錄入的條件類型，即在事務行項目表格中直接維護這些條件類型的價格，參考：配置>CRM>基本功能>定價>業務交易中的定價>設置輕松條件條目。
價格變更審批的工作流模板為CND_APPR（WS52600001），業務增強/SAPCND/DBA_SAVE_WS的實施CRM_CND_APPROVE中檢查是否有滿足條件的未激活的條件需要觸發審批，而通過增強BADI CRM_CNDCHG_APPROVAL_WF可以觸發價格審批的工作流。關于審批功能，可以參考SAP注釋986344。
價格相關的性能優化：在行項目多、數據量大的應用中，為盡可能提升系統性能，系統修改了一些價格存取方法，啟用相關的業務功能和配置后，能有效地提升定價的系統性能。SAP CRM 7.0 EHP1之前，對于有大量行項目的合同和訂單，更改單據時（即使是定價無關的字段編輯）系統均會將相關定價信息傳遞到定價引擎IPC中進行重新計算，如果行項目多，系統性能會受到影響。EHP1中（啟用業務功能CRM_PERFORMANCE），可以指定哪些字段變更才需調用定價引擎，同時可以使用延遲的跨行項目定價功能（Delayed Cross-Item Pricing）。對銷售類單據、服務類單據、銷售合同等有顯著影響，詳細可以參考SAP注釋1436942。SAP CRM 7.0 EHP2起（啟用業務功能CRM_PERFORMANCE_2），可以使用快速組條件（Fast Group Condition）來加快事務中的定價處理，定價引擎會識別需要進行價格重新計算的行項目并僅對這些行項目及相關行項目進行價格重新計算，無需對所有行項目進行重新計算?？梢詤⒖糞AP注釋1487240查看相關用戶出口等信息。定價性能提升的相關配置見：配置>CRM>基本功能>定價>業務交易中的定價>性能優化條件處理和定價。
合同中的價格協議即使用條件記錄技術，在合同的價格協議中維護價格時，系統自動將合同的抬頭或行項目內部編號（GUID）作為價格組成字段之一，即條件表中使用了合同行項目GUID作為定價字段之一，例如定價表SAP00090。在合同中維護價格協議時，此字段為隱藏字段，自動填充。啟用合同中的價格協議需要配置所用的條件維護組，并分配給合同事務類型或行項目類別（行項目類別配置的參數文件中，可以指定條件組），路徑：配置>CRM>交易>合同的設置>價格協議和配置。
2.2.3.2　定價條件技術
本節首先介紹在事務憑證中，系統確定價格的過程步驟，然后介紹定價技術和配置，從而了解SAPCRM的定價引擎是如何工作的。
1.?定價確定步驟
SAP CRM的定價處理的，系統自動確定可用的條件類型和價格，主要過程為：
1）維護事務憑證（如銷售訂單或服務訂單）時，系統根據錄入的客戶、組織數據（銷售范圍）及事務類型等數據，確定系統所用的定價過程。
2）定價過程包含了多個定價類型，設定了條件類型的控制方式和計算方式，如是否必填、是否允許手工錄入、所滿足的條件、計算公式以及記賬控制等。
3）在條件類型配置中指定了所用的價格的訪問順序。價格訪問順序中可以包含一個或者多個定價數據表。定價數據表中保存了價格主數據。
4）定價表包含了用于維護定價的多個屬性，如客戶、物料、銷售組織等。
5）最后系統就把當前業務場景中的相關屬性傳遞給這些定價數據表，搜索價格數據，如果能讀取到價格數據，系統即把價格填充到對應單據的條件類型中。
2.?定價過程的確定
定價過程即用來確定事務憑證中可用的價格條件、計算方法，控制價格的計算和功能，是價格確定的核心參數文件，起到統領定價的作用。因此，在事務處理中，首先要根據各種信息確定正確的定價過程。見圖2.43“定價過程確定”（路徑：配置>CRM>基本功能>定價>業務交易中的定價>確認定價過程），定價過程的確定由五個參數決定，即銷售組織、分銷渠道、部門、憑證定價過程和客戶定價過程，這五個參數能夠唯一確定一個定價程序。
其中銷售組織、分銷渠道、部門由事務憑證中的組織數據決定，即創建事務時，自動確定或錄入的組織數據后，即被確定。
憑證定價過程由事務類型唯一確定，每一個單據類型都可以分配一個憑證定價過程，見圖2.44“事務類型中的憑證定價過程”（路徑：配置>CRM>交易>基本設置>定義業務類型>明細>業務事物類別分配>銷售）。創建事務憑證，選擇事務類型時，即確定了憑證定價過程。
　
　
　　　 　　圖2.43　定價過程確定　　　　　　　　　　　 圖2.44　事務類型中的憑證定價過程
而客戶定價過程由客戶主數據的銷售范圍數據中的客戶定價過程確定，見
圖
2.45“客戶主數據中的客戶定價過程”（路徑：銷售專員業務角色>客戶管理>客戶>銷售區域數據），客戶主數據中，選擇一個銷售范圍，然后在開票數據中可維護客戶定價過程，如這里為標準。因此，事務處理中，錄入客戶后，確定組織數據后，客戶的定價過程即被確定。
定價過程確定后，系統即使用該定價過程中的定價條件、公式等配置信息，讀取訪問順序和條件表獲取定價數據，或根據定價公式計算出相關價格數值。
3.?定價過程
定價過程（Pricing Procedure，也稱定價程序）包含多個定價條件類型，指定了各條件類型的順序、滿足計算的條件、計算公式、累計方式及條件的記賬方式等。見圖2.46“定價過程”（路徑：配置>CRM>基本功能>定價>定義定價的設置>創建定價程序），0CRM01是CRM中的一個標準定價過程，該定價過程中使用了0PR0價格、折扣以及0TTE稅計算等諸多條件類型。如果使用ERP中定價條件和過程，可以將ERP中的定價配置和價格主數據復制到CRM系統中。初始復制后，SAP ERP中修改和新增的價格數據會自動同步到CRM系統中。“源系統”中確定該定價程序來自ERP或本地CRM。CRM中創建的定價過程來源為本地CRM。

圖2.46　定價過程
定價過程的控制有：
每個條件均會指定一個順序的級別，對于折扣加總、價格加總等可以設置加總條件類型的范圍，例如總折扣金額設置了100到299，即將級別為100到299的條件（為各類折扣）加總成本行的“總折扣金額”。
手工條件、強制條件和統計條件：即是否允許手工錄入該條件類型，該條件類型是否必填，該條件是否為統計類條件，統計類條件僅供顯示和查看使用，不改變憑證的定價值。
小計：將該條件類型的結果值小計到某個指標中，如果多個條件均小計到同一指標中，該指標即包含這些條件的累計值。小計通常用于定價計算。
公式：條件公式用來計算該條件類型的數值；基本公式用來計算基礎條件值，例如在折扣中，折扣會扣減條件值，而額外的價格會增加條件值；要求中設置該條件類型啟用時所滿足的條件。
其他：對于必填條件，可以設置提示信息類型為錯誤或警告?？梢栽O置打印輸出控制和權限控制級別。
4.?條件類型
一個條件類型（Condition Type）表示一類定價，如銷售價格、折扣、運費及稅等。系統根據一定的輸入參數自動找到或計算價格條件值。
見圖2.47“條件類型（1）”（路徑：配置>CRM>基本功能>定價>定義定價的設置>創建條件類型），條件類型0PR0為CRM的標準銷售價格；源系統為本地，說明該條件類型是在CRM中創建，如果是從ERP復制過來的，數據源為ERP系統；訪問順序中，使用了0PR0的訪問順序，訪問順序決定使用哪些定價條件數據表。
見圖2.48“條件類型（2）”（路徑同上圖），列出了部分的條件類型控制數據，首先條件類別可以為價格、折扣或運費等，表示條件類型的基本分類，這里0PR0的條件類別為普通價格；計算類型可以有數量、百分比或固定值等，這里與數量相關，說明如果1個單位的產品是100元，那么訂購2個單位的產品，價格為100×2＝200元；如果是百分比折扣，那么會根據價格乘于這個百分比計算出折扣金額。手工輸入表示是否允許手工錄入，有一些條件必須通過計算得出，可以表示為不允許手工錄入。項目條件表明該條件應用于訂單的行項目中。
5.?訪問順序
訪問順序（Access Sequence）確定定價所用的價格數據表。一個訪問順序可以有一個或多個訪問（即存取序列），每一個訪問都對應一個定價表。系統運行定價時，對于一個定價條件，系統找到該定價條件的訪問順序，根據業務參數（如客戶、物料等）依次讀取訪問順序的數據表，找到滿足條件的定價數據，并應用到單據中。例如先根據客戶及產品共同確定價格，如果沒有確定，就根據產品確定價格。
見圖2.49“訪問順序”（路徑：配置>CRM>基本功能>定價>定義定價的設置>創建訪問順序>訪問順序>
訪問），0PR0訪問順序有訪問序列5、10、20、30、40及50，第二列為具體的數據條件表；第三列為是否排除，即如果選中，找到該條件后即不再執行后續訪問順序；第四列為滿足的條件，只有滿足這些個條件才使用該訪問序列。
見圖2.50“訪問順序所用的字段”（路徑：配置>CRM>基本功能>定價>定義定價的設置>創建訪問順序>訪問順序>訪問>字段），即訪問順序0PR0所使用的一個表SAP005，這個表使用了字段有銷售組織、分銷渠道、客戶及物料，即價格是根據定價表的這四個屬性確定，即不同客戶對同一產品可以設置不同的銷售價格，即客戶物料價格。
6.?條件表
用于保存定價數據。不同數據表可以有不同的定價字段組合，比如根據客戶、產品設定銷售價格，或者直接根據產品設定價格?？梢赃x用定價字段定義各種價格條件表。
見圖2.51“條件表”（路徑：配置>CRM>基本功能>定價>定義定價的設置>創建條件表），顯示了SAP005的價格條件表，右邊列出了所使用的字段，銷售組織、分銷渠道、售達方及產品。最終的價格主數據即保存在這些數據表中。如果標準的定價表不能滿足業務需求，可以自定義數據表。

圖2.51　條件表
技術指南：
如果需要在事務中分析定價如何獲取，可以在事務代碼SU3中設置用戶參數PRC_TRACE＝X，這樣能夠跟蹤單據中的定價確定。定價在VMC虛擬機容器中的IPC中執行，如果查看IPC的RFC調用，可以設置用戶參數PRC_RFC＝X，然后計算定價時系統會在調用IPC RFC函數前設置調試斷點。IPC中的定價計算公式通過Java實現，可以執行報表RSVMCRT_MINI_DEBUGGER查看相關源代碼，參數為dbsources。如果使用ERP的定價配置，對于ERP自定義的計算公式，需要在IPC Java中重新實現后才能在CRM中使用。事務代碼SM53為VMC系統管理，可以查看定價的計算日志。
SAP注釋1746584中能找到有關定價、條件技術和計稅的常見問題。VPRS成本價格可以通過自定義定價條件的方式復制到CRM中，但是有一定的限制，如成本更新不如ERP中及時等，可參考SAP注釋653046。CRM_COND_COM_BADI是定價中常用的增強，通過修改和確定ITEM_COMMUNICATION_STRUCTURE結構中的數值，影響定價。
CRM定價和ERP定價的差異：CRM使用ERP中相同定價技術。但ERP中使用的部分條件類型在CRM中不能使用，如EK01及EK02的價格計算、AZWR預付費處理、RL00及MW15的發票清單因素折扣、EDI1及EDI2的EDI客戶期望價格以及從物料成本中確定的VPRS成本。CRM中的價格數據變化并沒有憑證的歷史記錄功能，無法批量復制定價條件。在數據模型上，CRM定價與ERP定價也有差異。CRM定價技術應用于多種應用程序和用途中，是一個集成的條件技術應用，并且CRM的產品數據、價格數據、組織結構等數據模型均與ERP對應功能的數據模型不同，因此在數據模型上存在較大差異。CRM中定價表的數據表組成為：前綴（CNC）＋應用程序（CRM及TTE等）＋用途（如PR為銷售與服務、FG為免費貨物）＋表名（SAP開始的表為標準表或者CUS開始的表為自定會議表）。例如ERP中的標準定價表004的價格數據表為A004，對應CRM中為CNCCRMPRSAP004，ERP中A910的自定義價格表在CRM中為CNCCRMPRCUS910。CRM中價格數據的級別設置保存在CNL為前綴的數據表中，如CNLCRMPRSCALEDIM為級別和定價值的關系表。
2.2.3.3　免費貨物
免費貨物（Free Goods）使用與定價相同的條件技術，客戶購買一定數量的產品后，可以獲取一定數量的免費產品，以激勵客戶購買更多產品。
免費貨物分包含性免費貨物（Inclusive）和排除性免費貨物（Exclusive）。包含性免費貨物指客戶購買一定數量的產品中有一定數量的貨物是免費贈送的，即如果客戶購買十個產品，只需要支付九個產品的價格，其中一個為免費提供。而排除行免費貨物中，客戶購買十個產品以后，支付十個產品的價格，然后能夠額外獲得一個免費貨物，因此客戶支付十個產品的價格得到了十一個產品。
CRM中所用的免費貨物功能及技術與ERP中的免費貨物相同。可以將ERP中的免費貨物配置和條件主數據復制到CRM中，供CRM使用。創建訂單時，系統自動讀取免費貨物的條件數據，滿足條件時，系統會自動添加免費貨物行項目，該行項目與定價無關，免費提供。
在系統配置方面，免費貨物使用了與定價相同的條件技術，系統提供標準的0NA001的免費貨物確定程序，其中使用了0NA0的條件類型，訪問順序為0NA0。
見圖2.52“免費貨物條件類型”（路徑：配置>CRM>基本功能>免稅貨物>設置自由貨物>創建條件類型），免費貨物條件類型0NA0的應用程序為CRM、用法為FG。
免費貨物的確定過程與定價程序的確定過程類似，由銷售范圍、客戶定價程序、憑證定價程序組合確定。免費貨物條件主數據可以在Web UI主數據中維護。
1.?免費貨物的等級及計算類型用法
可以使用條件的等級功能（Scale），定義不同訂購數量所獲取的不同比例的免費貨物，如訂購數量為10，免費貨物數量為1，訂單數量為20及以上則免費貨物為2個。通過計算類型用法，可以控制客戶訂購數量不等于（大于或小于）免費貨物規則中定義的數量時如何取值。例如免費貨物的規則為訂購100個，其中10個免費，如果客戶訂購150個，系統根據計算類型確定所能獲取的免費貨物數量。如果設置為類型1，即按比例兌現，那么可以獲取15個免費貨物，因為比例是十比一；如果設置為類型2，即單位相關，即每100的單位能夠獲取10個免費貨物，150個不滿足兩個單位條件，因此能夠獲取10個免費貨物；如果設置類型為3，只有滿足條件確定數量時才贈送，因此購買150個，客戶不能獲取免費貨物，當然在這種模式下，如果使用兩個訂單，其中一個為100個，另外一個為50個，就能夠享受10個免費貨物。
2.?免費貨物的配置
免費貨物的基本配置可以參考配置>CRM>基本功能>免費貨物，可以定義免費貨物所用的條件表、訪問順序以及條件類型，定義免費貨物的確定過程，分配免費貨物確定過程。
2.2.4　日期管理
日期管理是SAP CRM系統重要的基礎功能。業務處理中，往往需要多種類型的日期，根據一定的規則計算和確定日期；在全球跨時區的業務應用中，通常還需要考慮時區轉換問題。在SAP CRM系統中，可以靈活定義各種類型的日期、周期和日期計算規則，同時可以考慮時區轉換。見圖2.53“投訴單中的日期”（路徑：服務專員業務角色>投訴和退貨>投訴>明細），為投訴單中的日期，點擊“編輯清單”，可以列出該憑證類型允許的日期類型，可以進行填寫或者系統在流程操作中自動填充。在操作管理中，也需要使用日期管理功能，設定基于時間的操作條件。
應用舉例：
業務活動：計劃開始日期、計劃結束日期、實際開始日期與實際結束日期。
商機：演示日期、評估日期、招標日期、投標日期、商務談判日期、技術談判日期等。
服務：服務請求開始日期、計劃執行日期、實際執行日期、任務分配日期。
日期管理的基本功能參見表2.18。

下面簡要介紹日期相關的配置及控制功能。
1.?日期類型及規則
通常根據業務需求定義各種類型的日期，定義日期的計算規則。而日期參數文件將日期類型、持續時間和日期規則組織在一起，實現對日期的控制和管理。下面介紹日期類型、持續時間和日期規則的定義和功能，路徑為：配置>CRM>基本功能>日期管理>定義日期類型，持續類型和日期規則。
日期類型?？梢远x各種日期類型，指定編號和描述，如開票日期，報價開始日期等。
“日期參數文件”標識：該日期類型是否可以在日期參數文件中使用。
“里程碑”標識：該日期是里程碑日期，用于商機管理中。通常的日期類型包括日期和時間，并且由開始日期和結束日期成對組成，即持續一段時間。而里程碑日期不包含具體時間，同時無法設置持續周期。
持續時間。持續時間（Duration）用來定義兩個時間點之間的間隔。持續時間可以用于日期參數文件中，指定持續時間數量和單位，用于計算日期，比如響應時間為接收到客戶的服務請求后的四個小時。持續時間配置中僅指定編號和名稱，應用到日期參數文件時才需要指定數量和時間單位。
日期規則。用于確定如何計算該日期，可以通過XML定義日期計算公式或者函數計算出來。日期規則中可以使用其他類型的日期、持續時間以及參考對象。日期參數文件中的每個日期類型均可以分配一個日期計算規則，然后系統根據此規則確定日期。
見圖2.54（路徑：配置>CRM>基本功能>基本功能>日期管理>定義日期類型，持續類型和日期規則>日期規則），日期規則維護的編輯器。這是一種基于XML的日期規則編輯工具。比如這里SRV_0001的計算規則，首次響應時間為SRV_START開始日期加上SRV_RF_DURA持續時間。
圖2.55中（路徑同上圖），系統通過ABAP函數CRM_SERVICEPLAN _I _PLANDATE計算該日期。該日期用于周期性的預防性維護中，根據服務計劃，每隔一定時間自動產生某種服務訂單，包含相關的服務任務。系統運行時直接根據這個函數，根據上一次的計劃時間、服務執行周期，計算出下一次的服計劃服務日期。
日期計算規則應用舉例：
在服務管理中，企業可以根據產品可用性、產品的采購周期，及與客戶的合同約定（如假期、服務等級等）等條件，自定確定服務的開始時間。而在商機管理中，也可以根據一定的條件計算銷售項目預計結案時間。
在服務計劃中，根據計數器讀數、時間以及企業的其他業務規則，確定下次服務時間。
2.?日期參數文件及分配
日期參數文件將日期類型、持續時間、日期規則以及日期相關的控制組織在一起。日期參數文件可以分配給事務類型或行項目類別中，以便在事務中使用。下面介紹日期參數文件的配置和功能，配置路徑為：配置>CRM>基本功能>日期管理>定義日期參數
文件。
參考對象。選擇可以在該日期參考文件中使用的參考對象。參考對應用于確定日期計算時所使用的時區和日歷。參考對象由系統提供，不同對象有不同的確定過程，有以下對象：
系統（SYSTEM）：SAP服務器的系統時區，如果未指定，就使用操作系統的時區。
用戶（USER）：用戶主數據中指定的時區。
業務合作伙伴（CUSTOMER）：通過憑證抬頭中的合作伙伴確定。在任務和業務合作伙伴中，系統系統“聯系合作伙伴”的合作伙伴功能類別確定所用的合作伙伴，其他憑證中使用售達方功能類別。
運達方（SHIP_TO）：使用憑證抬頭中送達方類別的合作伙伴。
作業位置的時間區（ACTIVITY）：使用業務活動中指定的時區和日歷。
服務參數文件（SERWI）：使用合同行項目中的時區。
通常，如果時區無法確定，則讀取用戶所在的時區，然后讀取系統所在的時區。
日期規則。選擇可以在日期參數文件中使用的日期規則。
持續期間。選擇可以在日期參數文件中使用的持續時間，并且指定持續時間的數量和單位，同時指定參考對象，例如提前期為3天。
日期類型。選擇可以在日期參數文件中使用的日期類型并設定相關參數。見圖2.56
（路徑：配置>CRM>基本功能>日期管理>定義日期參數文件>日期類型），顯示了投訴COMPLAINT的日期參數文件，包含了開票日期、發票創建日期、要求開始日期及要求結束日期等各種日期。日期參數文件中，每一個日期均可以進一步指定控制參數，比如要求的開始日期SRV_CUST_BEG的日期參數文件為SRV_0001首次響應，見圖2.57（路徑：配置>CRM>基本功能>基本功能>日期管理>定義日期參數文件>日期類型>明細）。日期規則確定如何計算該日期。如果選擇只確定一次日期，日期成功確定一次后，如果相關條件發生變化，該日期不會再次被確定。顯示格式中，可以指定是否顯示日期、時間及區域。如果不顯示時間，那么就只有日期，顯示時間時系統會顯示具體的時分秒。如果設定為當前時間，系統會直接用系統的當前時間填充該日期類型。參考對象是確定時區的重要參數，在多時區業務中，可以根據系統時區、用戶時區或者送達方等客戶數據時區確定時間和日期。系統保存時均會保存為UTC格林威治標準時間，同時會記錄時間的時區。不同時區的用戶可以得到一致的正確的時間顯示。
日期參數文件的分配。在訂單類憑證中，日期參數文件分配給事務類型。一個事務類型擁有一個日期確定過程。日期參數文件也可以分配給行項目類別，在行項目中使用日期。見本章業務事務處理2.2.2.1基本結構和功能部分。
技術指南：
通過查詢數據表CRMD_LINK（OBJTYPE_SET=30）和SCAPPTSEG可以從數據表中查詢對象的各種日期。
如果在多個國家中開展業務，在日期類型配置和數據導入時通常需要考慮時區。系統根據日期規則所用的參考對象確定時區，可以參考函數CRM_DATES_TIMEZONE_BY_OBJ_OW，了解各種參考對象時區的確定順序和方式。同時可以使用BADI CRM_TIMEZONE_BADI自定義時區的確定方式。
日期規則使用了XML編輯器，具有一定格式的語句，可以使用時間語句、持續時間語句和參考對象語句，具體用法可以參考文章http://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=326600223。
2.2.5　操作管理
CRM中的操作（Action，也稱為活動、動作）為滿足一定條件時所觸發的相關動作，比如創建后續單據、提醒、輸出打印及觸發工作流等。操作是流程自動化、維持良好的客戶關系的重要工具和功能。通過定義各種操作和條件，可以在適當時候觸發相關動作，例如通知提醒等。在CRM中，輸出確定也使用CRM操作技術。
在實際應用中，操作具有多種表現形式。例如憑證的操作信息塊中，可以列出或執行關聯的操作；事務抬頭或行項目的工具欄按鈕可對應于某個操作；在保存或更改時，系統也可以觸發相關操作。見圖2.58“商機中的銷售助理功能”（路徑：銷售專員業務角色>銷售周期>商機），這是商機的銷售助理功能，即為系統定義的一系列的操作。不同階段可以定義不同的工作任務，激活以后，系統即自動為該商機創建后續業務活動，分配相關人員進行處理，可以規范銷售的具體過程，規范沒有銷售環節中需要完成的各種任務。銷售助理功能，即通過CRM操作實現。
應用舉例：
事務處理：如創建后續事務創建后續的任務、業務活動等相關憑證；合同結束前自動創建合同報價單；投訴中自動創建貸項憑證、退貨、發貨等行項目；商機中根據銷售助理創建工作任務；服務處理中根據時間的響應觸發服務升遷處理。
輸出和數據發送：如訂單釋放時，調用操作將訂單相關數據通過IDOC方式發送給合作伙伴。
打印和預覽：使用智能表格打印單據，同時可以在單據明細中預覽打印效果。
通知：服務請求、服務訂單、業務活動等的郵件通知，審批通知等。
了解CRM的操作管理，可以從操作、條件以及操作參數文件著手，了解操作在各種業務中的應用及控制。如圖2.59“CRM操作定義與執行”所示，操作參數文件中包含一個或者多個自定義的操作，每一個操作均會執行一些功能，通過操作方法指定（如調用業務對象方法、創建后續業務憑證、觸發工作流、調用智能表格進行通知或打印等）。滿足計劃條件時，該操作進入計劃階段，例如可以顯示在對話框清單中。滿足開始條件時，即可以執行此操作。操作參數文件分配到事務類型或者行項目類別中。

圖2.59　CRM操作定義與執行
下面以標準的投訴行項目的操作為例，介紹操作參數文件和操作的控制。
1）全局配置。新建或復制操作參數文件時，首先要設定操作參數文件的全局參數。雙擊操作參數文件設置全局參數，主要有：
對象類型：活動參數文件用于哪個對象類型中，例如用于投訴行項目的對象類型為BUS2000160。指定對象類型后，在操作條件中能夠使用該對象類型的屬性。
日期參數文件：如果使用時間相關的條件，可以使用日期參數文件中的日期規則。
上下文類：指定確定上下文屬性的程序類，例如訂單通常為CL_DOC_CONTEXT_CRM_ORDER。
2）操作。一個操作參數文件中包含一個或者多個操作，每一個動作定義了具體的觸發方式，需要完成的功能。動作由編號和描述組成，可以設置顯示順序、是否激活；見圖2.60（路徑：配置>CRM>基本功能>操作>事務活動>更改操作和條件>定義操作參數文件和操作），這是投訴單中投訴行項目的標準操作參數文件，該參數文件中定義了多個動作，CREDIT是創建貸項憑證子項目，DEBIT是創建借項憑證子項目，RETURN_REQ是創建退貨申請子項目，SUBST_DEL是創建替代發貨子項目，TASK_ITEM是創建單獨的后續處理任務。系統會拷貝投訴行項目，將相關信息、比如產品編號及數量等復制到后續創建的子項目中。
3）動作明細。見圖2.61（路徑：配置>CRM>基本功能>操作>事務活動>定義操作參數文件和操作>動作定義明細），以RETURN_REQ退貨申請行項目為例說明動作的明細控制。
處理時間：包括立即處理、用選擇報表處理及保存文檔時處理。立即處理即滿足條件時即處理，例如點擊生成退貨或發免費發貨行項目時，立即產生子行項目；用選擇報表處理即滿足計劃條件時，操作進入選擇報表（事務代碼：SPPFP）中，滿足執行條件時，可以執行該操作，通常設置后臺作業，自動定期執行選擇報表中的操作；保存文檔時處理，即保存時如果滿足條件則執行此操作。
自動計劃：即如果滿足計劃條件時，是否自動執行該操作。如果不選擇，計劃以后，需要手工觸發或者使用選擇報表觸發才能執行該操作。
處理后刪除：指成功處理后刪除該操作，如果處理錯誤，則不會被刪除。
顯示和執行：是否顯示在對話框即操作處理頁面中，是否可以在對話框中手工執行，是否可以更改。
合作伙伴確定：即指定操作所用的合作伙伴功能，例如為客戶或負責員工發送郵件時通常需要指定發送郵件時所用的合作伙伴功能。
規則類型：用于確定操作條件的設置方式，可以選擇使用工作流（WF）或BADI增強（COD）。如果使用工作流，即在計劃條件和開始條件中使用規則編輯器，選擇相關字段，構造出條件公式。如果使用BADI增強則通過BADI實現。
操作合并：如何合并多個操作，例如一個操作定義最多有一個未處理的操作，或者一種處理類型最多有一個未處理的操作等。
4）處理類型。即為該操作的底層執行方式，支持的類型有：
方法調用：調用某方法；方法調用中可以指定一些參數，如狀態、事務類型等。
工作流：觸發工作流。
外部通信：調用外部函數。
智能表單打印、傳真：打印、傳真智能表單。
智能表單郵件：將智能表單通過郵件的方式發送，比如業務活動的提醒通知，即為智能表郵件。
見圖2.62（路徑：配置>CRM>基本功能>操作>事務活動>定義操作參數文件和操作>動作定義>處理類型），退貨申請行項目允許的動作處理類型為方法調用，即直調用某個類的函數。退貨請求申請操作（RETURN_REQ）中調用的方法為RETURN_REQ。這里的方法調用是一種BADI業務增強，即通過BADI EXEC_METHDCALL _PPF創建自定義的調用方法。在這個BADI實施中，用戶可以自定義業務處理邏輯，例如自動創建后續憑證、生成IDOC向外部系統發送數據等。
5）條件。設定操作參數文件中的每個操作的計劃條件和開始條件。根據規則類型的不同對于工作流類型，可以使用工作流的條件編輯器，使用上下文屬性構造各種復雜的條件，例如狀態、時間或日期規則等。如果使用BADI增強，則創建BADI實施，這里指定BADI實施的過濾值。在郵件智能表單發送中，可以設置處理參數，如接收人的郵件地址、郵件清單或組織單元崗位等。（路徑：配置>CRM>基本功能>操作>事務活動>更改操作和條件>定義條件。）
6）操作參數文件確定。對于復雜的操作，可以使用條件技術確定所用的操作參數文件。路徑：配置>CRM>基本功能>操作>事務活動>設置操作參數文件確定。
7）分配。見本章2.2.2.1節。操作參數文件可以分配給訂單類單據抬頭，即事務類型，也可以分配給單據的行項目類別。
8）操作監控。通過事務代碼SPPFP，可以查看、選擇和處理操作。系統列出滿足計劃條件操作，然后可以執行。也可以創建后臺作業，定期執行一些滿足計劃條件的操作；后臺作業執行時，系統評估開始條件，滿足開始條件則執行此操作。
技術指南：
操作使用了SAP的后處理框架（Post Processing Framework，PPF），PPF是SAP底層技術。操作定義中，如果規則類型使用BADI實現，則操作的計劃條件可以通過BADI EVAL_SCHEDCOND_PPF實現，開始條件通過BADI EVAL_STARTCOND_PPF實現；而執行通過BADI EXEC_METHODCALL_PPF實現。例如實施COPY_DOCUMENT創建后續憑證，COMPLETE_DOCUMENT設置憑證為完成，CREDIT_MEMO創建貸項憑證等，可以在SE18中查看該BADI的實施。
操作的配置可以參考：配置>CRM>基本功能>操作。除了業務事務以外，營銷計劃、開票、返利、客戶計劃等應用中也使用操作，需要在對應的配置菜單中配置，配置步驟和方法與事務的操作配置類似。
如果操作的處理時間選擇通過報表選擇處理，那么可以使用事務代碼SPPFP啟動該報表，在選擇條件中，可以指定對應的操作參數文件、操作、激活狀態及時間范圍等，然后系統列出滿足條件的操作，可以手工執行，也可以通過后臺作業批量處理。但這時候需要考慮所后臺作業所執行的操作數量，如果數量過多，需要對操作的數據表PPFTTRIGG建立適當的索引，對于無法成功執行的操作，需要注意，如果累計過多，并且每次都執行，會浪費系統資源（例如在狀態中選擇未執行和未成功執行的操作，但因為有很多操作無法成功執行，這樣每次都會執行這些操作）。
2.2.6　文本管理
文本管理是CRM跨應用的基礎功能。通過文本類型管理，可以為業務憑證、各種對象和應用設置多種類型的文本注釋。與普通的文本字段不同，文本注釋是一種長文本，沒有字數限制，用于對事務及各種對象進行詳細描述和說明。在不同的文本類型中維護不同的內容，這樣可以對說明文字進行分類、規范。文本管理的核心配置是文本確定過程，需要分配到相關應用中，例如客戶主數據、產品主數據、營銷對象及訂單憑證等應用。
應用舉例：
投訴中，可以設置投訴內容、內部說明、解決方案。
在訂單中可以設置交貨說明；在業務活動中，可以設置客戶拜訪日程及拜訪報告總結。
見圖2.63“商機中的文本類型”（路徑：銷售專員業務角色>銷售周期>商機>注釋），顯示了商機中的文本類型，一種單據類型（對象）可以分配一個或者多個文本類型，維護備注時選擇文本類型及語言，然后填寫內容。

圖2.63　商機中的文本類型
下面介紹文本管理的功能和配置。
1.?文本編輯器
支持簡易文本編輯器和HTML文本編輯器，HTML文本編輯器中可以設置文本格式。簡易文本編輯器，僅支持文本內容，沒有格式。自SAP CRM 7.0 EHP1增強包1，可以使用HTML的文本編輯器，可以為文本設置字體、顏色等格式。同時可以在HTML模式和結果顯示模式中切換，即可以直接編輯文本的原始HTML內容。對于增強的HTML文本，需要在定義文本類型時選擇“帶格式”的標識。
2.?文本類型
SAP CRM系統中，文本對象為文本的實際應用對象，比如客戶主數據（BUT000）、產品主數據（Product）、單據抬頭（CRM_ORDERH）、單據行項目（CRM_ORDERI）及營銷項目（CGPL_TEXT）等。每個文本對象中，可以定義一個或多個文本類型，文本類型即為對各種備注長文本說明的分類。見圖2.64（路徑：配置>CRM>基本功能>基本功能>文本管理>定義文本對象和文本類型>文本對象和標識），單據類訂單抬頭（文本對象為CRM_ ORDERH）中列出了部分使用的文本類型。比如C001到C003用戶投訴單，C001為投訴內容，C002為內部處理意見，而C003為解決方案。
3.?文本確定過程
文本確定過程包含可用的文本類型以及對文本的確定和控制，見圖2.65（路徑：配置>
CRM>基本功能>基本功能>文本管理>定義文本確定過程>文本對象>程序>程序定義）。在文本對象中定義該對象可以使用的文本確定過程。
選擇文本確定過程中所包含的為文本類型。從該文本對象的文本類型中選擇。
順序：在文本確定過程中的順序。
更改控制：是否只讀或允許編輯，是否保留日志。如果設置為保留日志，那么每次對該文本的修改都會添加到原有文本中。
傳輸控制：即從前序對象中復制文本時的控制，允許完整復制文本或僅保存參考文本鏈接或使用動態讀取（即不保存在該對象中，讀取時，從原有對象中讀取）。
是否必填：該文本類型是否必填。
存取順序：設定文本確定規則，自動復制或確定相關文本，例如將客戶主數據中的交貨要求文本復制到銷售訂單中。
4.?存取順序
文本的存取順序用來確定文本。比如將客戶主數據中的發貨備注復制到銷售訂單抬頭中的發貨備注中。見圖2.66（路徑：配置>CRM>基本功能>基本功能>文本管理>定義文本確定過程>文本對象>存取順序），01的存取順序，表示從售達方客戶主數據BUT000中的0001發貨備述文本類型復制到銷售訂單抬頭中的發貨備注中。

圖2.66　文本的存取順序
5.?文本確定過程的分配
文本確定過程可以分配給訂單類單據抬頭，即事務類型，也可以分配給單據的行項目。對于客戶數據和營銷對象，直接通過文本對象合作伙伴（BUT000）、營銷項目（CPGL_TEXT）等確定。在訂單類單據中，文本確定過程分配給對應的事務類型。一個事務類型擁有一個文本確定過程，見本章2.2.2.1節。
6.?標準文本
可以定義標準文本（事務代碼：SO10），填寫文本名稱，文本編號為ST，選擇語言，可以維護標準文本內容。在應用的文本編輯器中，可以直接插入定義的標準文本。通過這種方式，可以重復使用固定的文本，規范標準文本的應用。
技術指南：
定義文本類型時，如果需要將文本類型翻譯成其他語言，需要用對應的語言登錄系統，然后設定文本類型描述。
在文本存取順序中，如果通過指定數據源不能滿足文本復制和確定要求，可以指定文本確定過程的函數自行確定文本，有固定的輸入和輸出結構，可參考函數CRM_TEXT_DETERMINE_TEXT。
2.2.7　調查問卷管理
問卷（Survey）是SAP CRM的一種通用功能，可以用問卷工具設計與維護問卷，問卷維護后可以通過配置分配給事務類型，這樣在該類事務中即可使用。通過問卷可以收集各種數據，對業務進行分析和評估。問卷在CRM的各種模塊和業務流程中均可以使用，比如：
業務活動與外呼活動；
線索；
商機、報價單與訂單；
服務訂單。
應用舉例：
服務完成后，例如購買機器、設備安裝后，外呼業務活動中使用問卷對客戶進行滿意度調查，了解客戶滿意度信息。
營銷活動執行過程中，產生業務活動，并關聯調查問卷，收集客戶購買意向和市場信息。
線索中，通過調查問卷，收集客戶購買意向程度，然后綜合線索的其他信息對線索自動計算評分，評分達到一定程度的，分配銷售資源，進入商機跟蹤處理階段。
商機中，通過調查問卷對商機進行評估或收集商機相關信息。
商機中的評估即為該商機關聯的調查問卷，可以關聯一個或者多個調查問卷。見
圖2.67“商機中填寫調查問卷”（路徑：銷售專員業務角色>銷售周期>商機>評估>明細），商機中編輯該問卷，可以查看該問卷的內容，可以更改與填寫。系統對填寫的內容產生不同的版本，同時記錄處理時間與人員。

圖2.67　商機中填寫調查問卷
1.?問卷的維護
調查問卷可以在SAP GUI中進行維護，也可以在Web UI中直接維護。SAP GUI中，通過事務代碼CRM_SURVEY_SUITE維護問卷。
在Web UI中，問卷維護與SAP GUI中類似，界面更為友好與直觀，見圖2.68“調查問卷設計工具：Web UI”（路徑：銷售專員業務角色>銷售運行>調查）。應用程序為該問卷所屬的應用，如業務活動、交互中心、營銷、商機、服務及銷售等各種應用，每個應用下面可以創建多個問卷；問卷有版本管理，每次激活均產生一個新的版本；問卷具有狀態（激活/不激活），激活后方可使用；問卷支持多語言管理。打開問卷以后，可以預覽。

圖2.68　調查問卷設計工具：Web UI
在Web UI中編輯問卷，即可以進入該問卷的設計模式，見圖2.69“調查問卷設計工具：答案類型”（路徑：銷售專員業務角色>銷售運行>調查>調查預覽>編輯），這里對于每一個問題，可以設置多個答案。答案有各種類型，比如是多選、單選或日期等。

圖2.69　調查問卷設計工具：答案類型
答案類型的種類主要有：輸入字段、長文本、復選框、日期、時間、編號、單選、復選、帶多選的列表框、單選列表框、動態帶多選的列表框或動態單選列表框等。
2.?問卷的確定
問卷的確定一般分配給事務類型或者事務類型的行項目類別，在維護該類型單據時，系統即顯示滿足條件的問卷，可能有多個問卷。
圖2.70“業務活動中的問卷確定”（路徑：配置>CRM>交易>活動設置>調查問卷>定義調查問卷的確定：業務活動）為業務活動的問卷確定方法，即問卷確定過程。

圖2.70　業務活動中的問卷確定
問卷確定的主要配置是指定某個交易類型及行項目類別在一定的時間段所能使用的調查問卷。配置參數說明如見表2.19。

總結

以上是生活随笔為你收集整理的《SAP CRM管理与实施指南》一一2.2　SAP CRM基础功能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。