spark的自留地(ofbiz/eclipse rcp/shark/opentaps)

            BlogJava :: 首頁 :: 聯系 :: 聚合  :: 管理
            54 Posts :: 0 Stories :: 112 Comments :: 0 Trackbacks

          #

          線索、聯系人和客戶概覽

          在CRM應用中有一個核心應用是將線索/潛在客戶轉化成客戶。在opentaps中的CRM應用,潛在客戶是在[線索]中做為線索創建的。一個線索是一個公司里的一個聯絡人且不能擁有更多的相關聯絡信息。在你進行線索篩選后,例如進行了電話跟進,你可以標記此線索有效。這時,當線索變成客戶,你可以將線索轉換成客戶客戶和一個聯絡人。你也可以為這個客戶客戶建立更多的聯系人信息。

          注意如果你有關于同一家公司客戶的多個線索時,系統允許你建立它們為不同的線索,而把它們轉換成一個客戶客戶。線索轉換屏幕允許你選擇一個已經存在的客戶客戶。

          這里沒有關于什么樣的線索可以轉換成一個客戶客戶的正式要求——你可以按照你自己的應用需求來進行調整。

          技術性備注:做為一個客戶、線索或客戶,一個參與者必須擁有“Account”, “Contact”,或 “Prospect” 的PartyRole并需要與另一個參與者有一個PartyRelationship。因此,不滿足此要求的OFBiz參與者是不能做為一個account, lead, 或contact的。同樣,一個客戶客戶是一個OFBiz的PartyGroup,線索和聯系人是一個OFBiz Person。

          客戶

          在0.9.1版本之前,客戶所有者默認是可以管理客戶組,但不能為此客戶創建機會。因此,在你創建一個客戶后,你除了無法創建機會外可以做任何事。創建一個客戶組,且你在此組上有擁有完整的用戶(讀/寫)使用權限時,你可以創建機會。

          在0.9.1版本之后,客戶所有者可以為其創建機會。

          每個客戶可以擁有一個父級客戶,父級客戶可以在[創建客戶]或在修改時輸入。

          客戶列表根據客戶名稱排序。

          聯系人

          在聯系人創建后,聯系人可以通過客戶主頁面上[新聯系人]菜單或是聯系人主頁面上的[新客戶]方式來加入到客戶上。

          聯系人列表根據聯系人的姓/名排序。

          線索

          線索是一個原始狀態的聯系人/客戶信息。當一個線索進行轉換后,將后生成一個聯系人與客戶。

          線索可以擁有父級對象。此父級對象應是一個已存在的客戶。

          線索默認會被分配給線索創建者。

          當你進行一個線索識別后,點擊[線索識別]來標識它已經通過“識別”。

          當你轉換一個線索,你將被帶到一個屏幕并被詢問是做為一個新建客戶還是一個已存在的客戶的聯系人。如果此線索的公司已經被建立,選擇已存在的客戶。否則,保持此字段為空。線索中關于聯絡人的信息將會被轉換成一個聯系人。如果選擇了一個已存在的客戶,線索將轉換成它的聯系人。如果未選擇已存在的客戶,將會基于線索中的公司信息創建一個新的客戶,線索信息將成為此客戶的一個聯系人。

          線索在轉換成聯系人/客戶時必須擁有公司名稱才會轉換成功。


          注意:如果你在轉換線索時選擇了一個已存在的客戶,這時線索中的所有公司信息將會丟失。這包括:“公司名稱”、“年營業額”、“行業”…

          在擁有關聯機會的線索進行轉換時,關聯機會同將會自動轉換成目標客戶、聯系人的機會信息。

          如果你根據線索生成了一個新的客戶,線索中的聯系信息(地址、電話、電郵)自動轉換成客戶中的聯系信息。如果你基于一個已存的客戶進行轉換線索,則線索中的聯系信息不會拷貝到客戶中。

          線索在未識別或轉換前可以被刪除(示例:還處于“新建”或“被分配”狀態)。在0.9.1版本前,你不能刪除任何擁有關聯活動(事件或任務,如電子郵件)的線索。

          線索列表可以根據線索中的公司名稱、姓、名的任一項排序

          合并線索/聯系人/客戶

          從0.9.1版本開始,你可以將重復的線索/聯系人/客戶進行合并。使用左邊的快捷菜單中[合并___]鏈接并輸入從-和至- 線索/聯系人/客戶的partyId。頁面將會要求你進行確認,在你確認合并操作后,

          合并特性中來源的線索/聯系人/帳戶信息可能不支持過多的數據。

          機會

          當機會剛建立時,階段是用于表明機會成功的概率,成功概率可以在以后進行修改,但是當它更新到一個新的階段,概率就會自動更新至新階段的概率。估計結束日期是用于提供機會未來預期情況。

          一個機會只能在來源于一個帳戶但可以關聯多個聯系人。

          在編輯/更新機會時,你必須屬于其所屬帳戶組,在帳戶上創建機會時,你一定有權限更新此帳戶。更新機會要求你填寫更改備注。

          在版本0.9.1,機會可以在線索識別后創建一個機會。當線索轉換后,機會將同時關聯于帳戶與聯系人。

          注意機會的“預測關閉日期”實際上存儲做為一個日期-時間(Java中的Timestamp類型),

          機會階段的概率存儲于SalesOpportunityStage.defaultProbability字段

          案例

          案例必須創建關聯于至少一個帳戶或聯系人。一個案例可以有多個聯系人或帳戶關例,雖然現在沒有與之關聯的接口。

          “我的案例”顯示所有分配給你的帳戶或聯系人相關的案例。它默認分配給用戶權限是:如果你被分配一個帳戶,而它有關聯的案例,那這個案例就屬于你。

          更新案例時,你需要擁有相關的帳戶/聯系人權限。

          將案例關閉需要特別的權限。

          發送電子郵件

          在帳戶,聯系人或線索的聯系人信息屏幕中,你可以點擊任何的電子郵件,將彈出一個發送郵件的屏幕。你可以輸入另一個電子郵件地址或查詢機會/案例。當你完成時,你可以點擊[發送]郵件或[保存以后發送]。[保存以后發送]將把電子郵件保存為收件人的一個待辦活動。在成功發送后,電子郵件將保存為活動歷史的一部分。

          如果電子郵件地址不是收件人參與者的電子郵件地址,你將獲得一個錯誤。

          注意[文本]和[超文本]按鈕將切換電子郵件MIME格式為文本與超文本,但當前超文本編輯器還沒有整合進來。因此,如果你打算使用超文本格式郵件時,直接通過粘貼或編寫html格式內容。已計劃提供一個整合瀏覽器的超文本編輯器。

          篩選接收的電子郵件

          在opentaps0.9.1,CRM/SFA應用可以篩選你接收的電子郵件,將它們保存為系統的通訊活動,且將它們關聯到你的用戶、聯系人、帳戶或線索上。配置此功能,首先應按照“Configuration and Setup”進行郵件容器的配置。接著編輯此文件

          hot-deploy/crmsfa/servicedef/smcas.xml

          把用于接收郵件的主機信息改正確后,重啟你的服務,系統將開始覽視你的主機并且保存新的電子郵件。它將根據郵件的來源電子郵件地址嘗試匹配你的帳戶/線索/聯系人,根據接收人/抄送電子郵件地址匹配你的CRM用戶。

          在接收到一封新的電子郵件時,它將在系統中記錄為一個通訊事件(CommunicationEvent)。如果來源電子郵件地址匹配了一個參與者電子郵件地址(帳戶、線索或聯系人),它將被記錄為來源于參與者。如果接收郵件地址匹配另一個參與者的電子郵件地址,它將被記錄為發送給該參與者的電子郵件。(技術備注:CRM/SFA應用使用OFBiz storeIncomingEmail服務,當使用WorkEffort調用和關聯收件人做為WorkEffort的參與者)

          新電子郵件做為關聯于參與者(帳戶、線索、聯系人)和接收者(用戶)的一個待辦活動創建。當你登錄至CRM/SFA應用時,你將可以在“待辦活動”列表中查看到你收到的郵件且在發件人(帳戶/線索/聯系人)的“待辦活動”中查看到它。你可以點擊這個活動查看電子郵件,這將把它標記為開始,當你完成時將把它標記為結束(技術備注:CRM/SFA應用將把電子郵件的通訊事件CommunicationEvent在你開始活動時標記為待辦“Pending”,結束時標記為完成“Complete”)

          未關聯到任何參與者的電子郵件將保存在系統中。你可以使用參與者管理應用來進行手工篩選。在[Party]>[Comm]查詢類型為“自動電子郵件”狀態為“未知參與者”的通訊事件。然后編輯它們關聯至系統用戶,標記它們為“完成”。

          活動

          這里有兩種活動類型:任務和事件。事件用于顯示在日歷中的會議。任務是電話、電子郵件或不顯示在日歷中的普通任務。在你初次登錄時可以在“我的起始頁”中顯示待辦活動列表,它們包括事件與任務。

          事件可以通過日程(點擊時間圖標)或帳戶、聯系人、線索、案例、機會屏幕兩種方式創建。任務只能在后者或任務列表中創建,因為它們是不在日歷中顯示的。

          當你創建一個活動時(任務或事件),你可以輸入計劃的起始日期/時間和持續的期間。如果用戶在此期間將會忙于處理此事,則點擊“忙”或“離開”。如果有另一個任務或事件已經在使用此時段并標記為“忙”或“離開”,將會產生一個錯誤信息。如果你堅持要使用此時估,點擊“忽略日程沖突”。當你更新事件時,你一樣需要設置“忽略日程沖突”如果它與已存在的事件時間沖突。

          記錄一件已發生過的活動時。這些活動將會創建做為完成的,用戶也會要求輸入實際的開始與結束時間。

          為計劃某事創建一個新的活動,事件或任務時,用戶輸入計劃開始時間和結束日期。原狀態為“計劃”的事件可以為“已確認”。當確認后,你可以在事件中加入參與者并通過發送郵件邀請他們。加入一個參與者自動確認他們。邀請他們發送發送電子郵件。輸入的備注將被包含在其中,而且這個電子郵件將包含兩個鏈接:接入與拒絕。

          如果參與者已經在相同時段置“忙”于另一個事件或任務,他們是無法加入到事件中。如果未設置狀態,則此段時間被假設為可用。

          當你擁有自己的事件時,你可以在發生期間內(開始至結束時間)內把它標記不“已完成”。

          還有一個任務創建為“已計劃”時,當用戶準備開始此活動,更新任務至“已開始”且輸入開始時間。如果未輸入時間,系統將記錄當前時間做為開始時間。類似地,當用戶準備標記它完成時(“已完成”),如果未輸入時間,系統將記錄當前時間做為完成時間。

          至于一封電子郵件,當你點擊[發送電子郵件]系統將記錄它作為開始時間。當你點擊[發送],系統記錄它作為結束時間。如果你保存以后發送,此活動將不會記錄它為完成直至你實際發送此郵件。

          當查看活動時,你將在上面查看到活動的詳細內容,在中間的關聯的活動參與者(帳戶/聯系人/線索/組成員)、如果這是封電子郵件,電子郵件在下方。注意OFBiz設計為允許每個work effort中允許多個通訊事件,但我們在活動中只顯示其中的一個。這個概念稍微有點落后:在OFBiz,你創建work effort作為“項目”并與很多電子郵件并進行關聯。在這里,work effor用于分離的“任務”,如發送一個電子郵件。你可以創建work effort作為項目,但它可以分離成調用子任務。它在Workeffor Manager中支持,但在CRM/SFA中沒有這樣的用法。

          當你記錄電話或電子郵件時,“呼入/呼出”標志參與者是主動方還是被動方。

          參與者列表顯示任務或事件的參與者(帳戶/聯系人/線索),當前只有日程擁有者(如活動的創建人)可以更新參與者可用狀態及增加/刪除他們。未來版本可能會改變這點限制。

          查詢活動將顯示那些已完成的活動或任務列表。

          當事件被取消,它將不再顯示于日歷中。

          預測

          銷售預測使用機會概率和數據來計算在未來時間段的預期銷售額。預測來源于機會的計算,每個銷售員預測基于自己的客戶機會和線索相關聯的機會計算。與其相關的任何客戶和已確認的線索可以用于計算預測。因此,所有銷售員銷售預測合計將超過整個公司的銷售預測,因為很多銷售員擁有相同的客戶,為了獲得公司的預測,每次只一個增加銷售經理而且每個客戶和線索只計算一次。

          所有銷售員可以創建自己的預測和輸入他的銷售定額。只有銷售經理可以創建組/銷售區域的預測。當前每個銷售員只能創建自己的預測。

          創建你自己的預測,選擇[創建預測]并選擇相應的季度來創建。只有未關閉的季度,即在還未到結束日期的季度可用于創建預測。

          你將會被要求輸入此季度的按月銷售定額。當你完成后,點擊[創建]。你的銷售定額將輸入進系統且按月/季度的預測將會被創建軍。每個月的銷售預測計算基于:
          1. 成交金額=此月狀態為“已關閉”機會金額累計
          2. 最好金額=預計在此月關閉的機會金額累計,不管當前的階段
          3. 預測金額=所有高于最低概率的機會金額*概率的累計金額。最低門檻定義于crmsfa.properties配置文件中.


          季度預測是基于月度預測的累計。

          查看任何的預測需要特別的權限。否則,你只能查看你自己的預測。

          如果你擁有查看別人預測的權限,點擊[查詢預測]可以查詢其它人的預測。你可以根據組成員或時間段來進行查詢。查詢的預測是按季度的。

          默認的,只有銷售經理或管理員可以修改已存在的預測。修改一個預測,點擊預測的月份,輸入修改后的定額,填寫更改備注,然后點擊[修改]。此月和季度的預測值將會被修改。

          每當預測被修改,舊的版本將會被保存為歷史。當查看預測時,你可以查看整個的預測修改歷史(包括舊版本的修改日期與定額、最好預期和預期)

          當一個時間段正式關閉或已結束,對應的預測不允許再修改。

          如果在一個時間段已創建一個預測,當新的機會創建或已存在的機會更新時,它將自動更新。與該機會相關的客戶/線索相關的預測成員將會自動更新。如果機會預計關閉日期被移至一個新的時間段,受影響的預測將會更新。然而如果機會移動到一個未建預測的時間點時,新的預測將會自動建立。


          報價

          報價部分允許你為自己的客戶查看和創建報價。關鍵特性包括根據報價名稱、類別、狀態查詢報價;創建報價;根據報價創建訂單。注意這些屏幕同樣是“訂單管理”中的報價屏幕的一部分。
          報價的重要功能包括:
          • [查詢報價] –查詢報價信息
          • [查看報價] – 查看報價的摘要信息
          • [報價] – 管理報價的表頭信息,包括客戶與倉庫
          • [報價細項] – 增加/刪除報價項和修改它們的價格
          • [創建訂單] – 根據報價內容創建訂單


          訂單

          訂單部分允許你在CRM/SFA應用中查詢訂單或創建新訂單。

          0.9.x版本的訂單頁是基于OFBiz訂單管理導入的,可以在“General Overview”中查看相應的詳細文檔。

          1.0.x及之后版本的訂單頁重寫支持訂單的輸入和查詢。你可以在此頁中為客戶創建和查詢訂單。

          “我的訂單”頁用于顯示當前登錄用戶的訂單。

          你可以客戶詳細信息屏幕中的訂單頁中使用快速創建訂單,或直接使用[創建訂單]鏈接來創建一個新的訂單。

          如果你使用快速創建訂單,你必須輸入客戶、訂單名稱,和要求發貨日期。你可以輸入一個產品id,系統將會加入數量為1.0此產品進入你的訂單。

          注意在訂單管理中“要求發貨日期”與“發出日期”是相同的。它不是訂單管理中的“要求發貨日期”。那個字段在現階段不支持。

          當你輸入所有的訂單項目后,點擊[完成訂單]。你將查看到一個要求你為每個訂單項選擇發貨目的地與方式的屏幕。在你確認后,系統將自動創建多組分離的目的地與發貨方式的發貨組。

          其它的訂單項屏幕與訂單管理中的相同。

          訂單項產品倉庫配置于config/crmsfa.properties文件中。當前CRM訂單項系統支持每個訂單項只來源于一個產品倉庫。這次不支持產品目錄。

          市場

          市場頁準備用于不同的市場相關的功能。當前只有系統中的調查列表及允許你查看這些調查反饋的結果。

          服務調查

          這里有一個獨立的web應用用于發送客戶調查、投票。當前,這是一個非常簡單的web應用可以用于顯示調查,收集反饋然后向客戶答謝。

          你可以在內容管理中創建調查,然后通過以下地址訪問它:
          http://www.mysite.com/surveys/control?surveyId=${surveyId}
          其中${surveyId}是你的調查在內容管理中的ID
          你可以通過crmsfa/webapp/surveys/子目錄中的文件來定制它。

          OFBiz

          你可以通過crmsfa.properties中的“crmsfa.tab.ofbiz.show”參數來啟用/禁用顯示返回至OFBiz鏈接,如果啟用,你將在標簽頁中查看到OFBiz的鏈接。

          如果你打算為你的用戶設置訪問OFBiz應用權限,請查看Security Documentation了解更詳細的內容。

          技術備注:同其它應用整合

          報價,訂單和市場頁實際上是重用訂單管理與內容管理(調查)中的屏幕,它們是這樣做的:
          1. 在CRM/SFA應用中創建裝鈰頁面
          2. 在web.xml中設置對應應用main-decorator-location 參數,這樣這些屏莫在CRM/SFA應用中調用時,它們將使用CRM/SFA中的屏幕樣式來替代原來的樣式顯示。
          3. 從原來的controller.xml中復制相關的view- 和 request-maps到 CRM/SFA應用中的controller.xml
          4. 在訂單項中,原來訂單管理中客戶的鏈接是鏈接至Party Manger的,而在CRM/SFA中應將參數修改至客戶頁面。

          本文檔譯自opentaps v0.9 manual,本人翻譯,歡迎轉載,請注明出處.

          posted @ 2008-10-01 15:55 shanghai_spark 閱讀(1879) | 評論 (2)編輯 收藏

          2004年開始,我開始讓研發團隊基于Eclipse插件技術開發通用管理軟件(最近的一個產品是一體化企業管理軟件CRM+OA+DSS+進銷存的E-System)

          選取RCP方式開發管理軟件,我們的初衷是期望使得用戶界面的豐富性和易操作,能夠充分利用Eclipse本身豐富的SWT/JFACE/GEF/EMF等技術來完美我們的界面表現,應該說這方面Eclipse RCP確實不辜負我們的期望。

          在四年的Eclipse RCP開發經歷中,經歷了很多坎坷和難以逾越的障礙,其中有一個至今仍在困擾著我們的問題就是Eclipse RCP的性能問題,它主要有以下幾個方面問題:

          1、如何高性能處理服務端與客戶端的數據傳遞?

          2、因為我們軟件面向的用戶是通用市場,用戶機器環境良莠不齊(從最新的四核處理器到十年前的P3機都有人使用,內存從256M到2G都有)?如何克服Eclipse RCP對客戶端應用的高性能要求(用過老機器使用Eclipse開發的都知道那導出Eclipse RCP漫長等待的滋味,2 hours,真是生不如死呀!)?并能盡量發揮機器的處理能力?

          在這方面我嘗試了很多方法,可以用于改善這兩個問題:
          1、選擇最合適的數據傳遞方法,rmi、web-service、hessian、tcp client/server做了下對比,我覺得如何你需要傳遞的數據如果耦合層次比較低、業務關系簡單其實完全可以模擬http方式,用自己的request/response對象進行傳遞。那rmi/web-service是蠻好的選擇。但如果數據之間耦合關系緊密、業務關系復雜(我現在的系統有312個POJO,它們之間都有或緊或密的關系,而視圖由于我讓客戶可以自定義,所以無法在設計階段確定form view與action對象)這樣顯然無法使用web-service(web-service只支持最原始的幾種數據類型)、而直接將對象序列化進行傳遞的方法也不可取(因為pojo對象均有關聯,直接序列化的對象幾乎就是整個數據庫的內容,因為form不確定也無法構造對應的action對象來完成傳遞)。掙扎了很久,最后用了一種折衷的方法,數據傳輸采傳值拷貝序列化方式(但默認只拷貝兩層,即引用的對象中只包含原始屬性,不再包括它引用的對象/集合屬性),在特殊需應用到多層對象級聯數據傳遞時才定制request對象中的約定參數來表明傳遞層次。傳輸方式使用自己定制的tcp client/server方式,選用這種方式主要是為了降低數據傳輸的尺寸(web-service中垃圾太多了),其中細節當然很多(如如何自動為request對象補充未傳輸數據、服務端hibernate對象如何將POJO代理對象拷貝成值對象...),每個問題都是我們的一個血淚史,嘿....

          2、Eclipse對系統硬件的高要求地球人都知道,如何盡量降低它呢?我的原則是盡量不要使用非必要插件,RCP每加載一個插件自然就會多消耗。另外還有一個很重要的方法就是關掉不使用的perspective,NND,當初系統剛出街時,很快就有客戶投訴早上打開系統很快,中午就慢如蝸牛了,一頓臭罵呀!當然也不能隨用隨開,那Eclipse要隋性加載干啥,一樣客戶臭罵(怎么我每點一次鼠標就要出去抽只煙呀?),沒計,只好寫個計數器,從客戶登錄開始就記錄各perspective的使用頻率,把超出范圍(根據客戶的內存選擇,我認為有閑置256M內存不要超過5個,512M內存可以15個,1G以上就可以不關了)的perspective關掉,保持最高使用率的perspective可以隨點隨開。

          BTW:千萬記得要在eclipse rcp中加上運行參數(如果客戶內存富裕你也可以在安裝程序中調高它,我的程序默值是這樣),不然內存被它吃光了,就聽客戶狂打你們客服電話吧!

          -vmargs
          -Xverify:none
          -XX:+UseParallelGC
          -XX:PermSize=20M
          -XX:MaxPermSize=128M
          -Xms64M
          -Xmx128M

          Eclipse RCP關于管理軟件方法應用的開發資料很少,歡迎同道之人相互交流!

          本人原創文章,歡迎轉載,轉載請注明出處!
          posted @ 2008-09-30 13:41 shanghai_spark 閱讀(1653) | 評論 (2)編輯 收藏

          CRM/SFA應用用途

          CRM/SFA設計用于銷售代表、銷售經理、客戶服務代碼管理公司中銷售和客戶服務的應用,它的主要功能點是:
          • 跟蹤銷售情報
          • 識別銷售線索并將此轉換成客戶
          • 跟蹤客戶聯系
          • 輸入和跟蹤商機開始到結束的生命周期
          • 管理客戶銷售報價
          • 創建和查看客戶/聯系人銷售訂單
          • 生成銷售預測
          • 管理客戶案例子 (客服請法語)
          • 發送電子郵件
          • 管理活動和工作,包括會議、電話、電子郵件
          • 跟蹤市場活動如:客戶調查


          創建新用戶

          創建新用戶需要在Party Manager中操作,點擊[Party] > [Create]創建一個新的參與者。至少為其分配一個以下角色:“Account manager”, “Account Rep”, “CSR”。注意每個用戶可以擁有其它的角色如“Employee”、但只有以上三個角色用于CRM/SFA應用,下一步創建一個用戶登錄并且為其分配安全組:SALES_MANAGER, SALES_REP, 或 SALES_REP_LIMITED, 或 CSR

          注意:在party manager中的角色與CRM/SFA中的角色是不同的,在party manager,角色僅定義為一些人或組面對另一些人或組時的身份。在CRM/SFA中,角色意味在客戶銷售關系中的分演的角色,而且它也暗指著一組對應的權限。

          如果用戶忘記自己密碼,可以通過“忘記密碼”功能將新密碼郵至原來預設的個人郵件地址中。

          用戶概況

          在CRM/SFA應用界面中的頂部[概況]鏈接位居用戶名與[登出]按鈕之間。點擊此鏈接可訪問用戶概況頁面,你可以在此頁面中修改用戶名稱,修改密碼,增加聯系方式信息(如:電郵、郵政地址、電話等)。注意你不可能在這里更改用戶登錄信息(這只能在Party Manager中操作)。此頁還可以查看用戶過往的訪問歷史。

          我/我的團隊

          從0.9.1版本開始,你可以在[我的帳號]的右邊看到[我的團隊帳戶],如果你點擊我的帳戶,你的登錄將被配置為只查看你的個人信息而非使用團隊帳號。這個功能工作于線索、聯系人、案例、機會。

          帳號組

          CRM/SFA應用中的帳號組是通常用于工作于同一組角色和權限組合的團隊, 一個組在它建立時可以被分配一個帳號。接著,帳號組管理員或帳號所有者可以重新分配組成員或他們的責任,這樣很大程度不同于“軍事單位”組,通常那些組是一直擁有固定的領導、成員的。

          為了創建一個組,你需要使用Party Manger。在[Party] > [Create] >> [Create New Party Group]并給你的組命名。然后在[Roles]處分配一個[Account Team]角色給它。然后在[Relationships]處加上你的組成員。以下信息項必段輸入:
          • 組PartyId
          • 組成員角色 (Account Manager, Account Rep, 或 CSR), 基于早先創建的用戶所分配的角色.
          • “Is a” 字段必須設置為“Assigned To”
          • 組角色應該設置為 “Account Team”
          • 設置起時日期
          • Party Relationship Security 必須是你的組安全權限.  在 Party Manager, 一長串安全組將會顯示,選擇一個與CRM/SFA 應用相關的安全組.  (查看 “Security Documentation.”)
          聯系信息

          系統允許你為每個人/組建立多重的聯絡方式信息,你的帳號、線索、聯系人都可以根據你的需求輸入任意多的電話號碼、地址、電子郵件地址。每個聯絡信息都需要標識出它的用途。


          當你使用[創建聯系人]、[創建線索]、[創建帳號],系統將基于你的表單輸入創建以下聯系信息:
          • 地址信息將被做為“一般信函地址”與“一般收貨地址”
          • 電話號碼將做為“主電話號碼”
          • 電子郵件將做為“主電子郵件地址”
          • 網站地址將做為“主網站地址”


          但你在創建聯系信息時,你應當創建電子郵件作為主電子郵件地址及地址做為一般收貨地址。主電子郵件地址將用于發送自動通知郵件。一般收貨地址用于訂單發貨。

          電話號碼和電子郵件在所列帳號、線索、聯系人的主電子郵件和主電話號碼。

          你可以點擊任何的列在聯絡系統中的電子郵件地址來發送電子郵件,查看下面的“發送電子郵件”

          備注

          在CRM/SFA應用中,很多東西可以創建和保存備注。備注菜單通常在屏幕的下方。

          本文檔譯自opentaps v0.9 manual,本人翻譯,歡迎轉載,請注明出處.

          posted @ 2008-09-28 17:46 shanghai_spark 閱讀(1352) | 評論 (2)編輯 收藏

          架構

          CRM/SFA應用很大程度不同于其它的OFBizBiz應用,OFBIZ應用設計為一組可以整合在一起適合各種商業活動的進程,CRM/SFA應用設計為支持角色/活動的全部活動在CRM應用中,這樣子,它將帶來與其它應用的很多不同點

          1.CRM/SFA的商業邏輯粒度小于其它OFBiz,而且通常會調用很多其它應用中的action。如當創建一個帳戶時,CRM/SFA應用將調用另一個OFBiz服務創建Party、PartyGroup、PartyRole、PartyRelationship等等

          2.在OFBiz其它應用中高度抽象的數據模型在這里表達成更傳統直觀的概念。示例,“Party”被表達成為account ,lead, contact, team, 或 team member,  它們擁有不同的用戶界面和業務邏輯。

          3.OFBiz的“WorkEffort”面向用戶時表達為“Activity”,而且只是事件和業務可作為“Activity”,其它的 “WorkEffort”例如制造產品過程在CRM/SFA中不顯示出來。

          4.它擁有PartyRelationship.securityGroupId定義多個參與者之間權限的不同的安全模型(示例,組成員A是否有權訪問B帳戶?)它使用了不同的安全方法(查看“Security Documentation”了解詳細信息)

           

          用戶界面原則


          CRM/SFA應用有一個不同于其它OFBiz應用的界面原則。簡單來說,此原則就是 建立一個容易讓用戶明白和使用的界面,好過讓用戶不停的思考如何使用。


          示例,“work effort”是一個OFBiz中的a task, a project, an event, 或a manufacturing production step,在OFBiz的WorkEffort應用中讓用戶自己創建它時選擇對應的實例選項,而在這里,WorkEffort被分離在不同的人機界面上顯示各自的特性。


          大多數使用者,不會想“我打算創建一個work effort在參與者X和Y之間”,他們通常想“我為參與者X和Y在明天上午建立一個約會”。這樣CRM/SFA應用提供創建約會界面并加入參與者X和Y,在此界面啟動約會及完成它。


          所以這意味著有些在OFBiz中允許的操作在CRM/SFA界面中不再被允許。示例,在OFBiz創建一個“EVENT”類型的work effor時可把它關聯到貨運或產品制作過程。這些信息在OFBiz的work effort中是可見字段,盡管work effort在event中并無這些關聯字段。另一面,在CRM/SFA中界面看不到這些字段


          這樣的功能減少帶來的是操作的易于理解,且也讓一些日常的操作減少不必要的步驟。

          另一個UI原則是將很多分離的步驟合而為一個操作步驟。最好的例子是當你創建一個聯系人時,你可以在一個屏幕內輸入所有聯系人信息,而系統會自動的根據信息創建參與者、聯系信息及關聯項,將很多分離在不同OFBiz中的應用合而為一。

           
          最后,我們打算避免用戶點擊回退、向前去查看信息,所以太多數屏幕都把信息顯示在同一個屏幕里,而不是提供很多的信息標簽


          編碼約定

          另外,創建CRM/SFA應用,我們還有一些與其它不同的編碼約定:
          1.強制要求將視圖與數據準備分離,我們限制視圖層如freemaker頁/XML只承擔展現數據功能。這樣意味著在form組件中不會存在”action”標簽。

          2.在屏幕組件定義中,使用beanshell腳本比<entity-one> XML操作更好。

          3.Minilang腳本在一個方法中不要超過十行。使用java來編寫復雜的商業邏輯。不要在minilang中使用<or>、<and>及計算。

          4.保證代碼塊簡捷。一般的,如果你的方法超過兩百行,建議你考慮如何重構它。

          5.為你的代碼加上注釋。描述你編碼的目的和結果,而不僅是你做了什么。示例,如果你編寫了如下代碼
           invoiceId=null;
          不要注釋寫成://設置InvoiceId為null
          而應該寫成://invoiceId應該為空,否則服務不會創建一個新的發票

          6.使用較長的變量/方法名稱,如:computeForecastParentPeriod,而不是一個很短無意義的名稱。

          7.使用意指你所調用的實體對象的變量名,而不僅是一個縮略的變量名。 示例,如果你獲得一個orderItems集合,變量名不要僅叫做”item”——可以叫它們”orderItems”或”nextOrderItem”,諸如此類。如果你獲得一個OrderPaymentPreference實體,不要命名為“payments”,因為Payment實體同你命名的這個對象不是同一個東西。

          8.在FTL、表單組件、beanshell和Java服務中使用java來幫助將復雜的邏輯進行分離。

          9.將代碼分離在應用的不同目錄中,將表單、屏幕組件XML文檔放在widgets目錄中,將JAVA包放在src/目錄下,FTL放在webapp/crmsfa/,BSH腳本放在webapp/crmsfa/WEB-INF/actions/中…


          10.在服務XML中加了相關注釋指出需注意的事項或此服務可能發生的意外

          本文檔譯自opentaps v0.9 manual,本人翻譯,歡迎轉載,請注明出處.

          posted @ 2008-09-28 15:45 shanghai_spark 閱讀(1792) | 評論 (0)編輯 收藏

          僅列出標題
          共6頁: 上一頁 1 2 3 4 5 6 
          主站蜘蛛池模板: 古蔺县| 仪征市| 图木舒克市| 两当县| 保定市| 化州市| 新巴尔虎右旗| 扎鲁特旗| 湖南省| 兴宁市| 浪卡子县| 丹凤县| 祁门县| 枝江市| 德格县| 广汉市| 开远市| 离岛区| 麻阳| 犍为县| 广东省| 东乌珠穆沁旗| 绩溪县| 方山县| 太白县| 新泰市| 淮滨县| 南雄市| 安徽省| 黄大仙区| 宣恩县| 天津市| 靖安县| 基隆市| 图们市| 万山特区| 长子县| 祁门县| 田林县| 双柏县| 舟曲县|