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 阅读(1865) | 评论 (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 阅读(1641) | 评论 (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 阅读(1339) | 评论 (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 阅读(1786) | 评论 (0)编辑 收藏

仅列出标题
共6页: 上一页 1 2 3 4 5 6