合作伙伴管理

1、目 录合作伙伴管理 a1231 合作伙伴管理概述31.1 合作伙伴信息分类81.2 合作伙伴信息权限管理102 合作伙伴信息管理 a121132.1 新建合作伙伴信息流程 a1211142.2 查询合作伙伴信息流程 a1212172.3 共享其他合作伙伴信息流程 a1213182.4 修改合作伙伴信息流程 a1213213 合作伙伴信用管理 a122223.1 维护客户信用等级 a1221253.2 维护供应商信用等级 a122226合作伙伴管理 a12a12合作伙伴管理分为：n a121合作伙伴信息管理n a122合作伙伴信用管理1 合作伙伴管理概述合作伙伴管理是货运代理企业的最基础的组成部

2、分，是货运代理企业保证基础货源、不断增加货源、降低成本支出并且不断提高货运服务质量的关键，在合作伙伴管理里主要针对的对象是为我们提供货源的货运客户以及为我们提供服务的供应商和代理机构。我们的设计思路是将货运客户、供应商和代理机构等都看作我们的合作伙伴统一进行管理，这是由于货运业务的合作伙伴互为服务对象的特点而决定的。因为在货运业务中经常互为服务关系，互相变换客户和供应商的角色，这样就具备统一管理合作伙伴的基本条件。对于货运业务很多情况下经常会不好确定供应商之间单一的合作关系.因此,按合作伙伴统一管理更能够反映货运业务的特点。合作伙伴统一管理的优点还在于，将来系统数据维护过程中的便捷性和统一性。

3、合作伙伴的视图合作伙伴必然与公司组织构架相关，即对于同一物理合作伙伴，站在不同的组织结构上有不同的观点，我们称之为“视图（view）”。一个合作伙伴与特定的组织有业务往来，必须拥有对应的视图。这是一个集团业务控制的基础点。集团可以通过冻结操作控制合作伙伴与业务单元之间的关系。集团级系统管理合作伙伴的前提是：唯一的合作伙伴在集团内的id唯一，这样就要求制定集团层面的一个统一编码体系，最好建立统一集中的id维护机构，这样才能有效确保唯一性。不同的视图下的信息维护可以集中维护、也可以分开维护。合作伙伴的维护合作伙伴维护通常分为申请审批和信息维护两个流程，作为应用系统的核心应用为信息维护，申请审批通常

4、使用oa工作流完成，也可以纳入到系统中。信息维护主要从4个方面进行：1. 基础信息的维护：通常需要集团建立集中的机构维护，以确保唯一性，唯一性可以建立在合作伙伴某一唯一独立的信息上；2. 商务信息的维护：实质是在已经拥有基础信息及合作伙伴id后，针对该公司的合作伙伴信息扩展，一个合作伙伴对于该公司只有一条商务信息；3. 业务信息的维护：实质是在已经拥有基础信息及合作伙伴id后，针对该组织机构的合作伙伴信息扩展；特别地，针对评估，其核心内容是构建外部评估体系。（建立评估体系的关键内容参见企业组织构架），在系统中重点体现对评估信息的维护（初次维护、升级、降级等），以及特定级别变更后对后续业务的影响

5、。但是目前考斯特集团尚未建立起相应的现实业务管理体系。建议系统设计考虑此因素，但是具体开发等到现实业务体系基本建立并有效运行后再进行。从而我们可以根据这些需求，将用例进行如下的规划的优化： 建议按照以上思路优化现有的合作伙伴相关用例。 建议评估单元的具体开发等到相关业务管理体系建立后再进行，但在系统模型设计中给与充分考虑，以后只需要新增部门内容即可。合作伙伴（无论是客户、供应商，还是内部合作伙伴、外部合作伙伴）一定对应组织机构内某一个或多个维护人员（可能是销售人员，也可能是非销售人员），因此，需要在员工建立其维护的合作伙伴列表。一、总部至少指定1名专门的合作伙伴维护人员：维护原则：1、总部有新

6、建、删除、修改、查询合作伙伴信息的权限；2、每隔一个月，会对系统里各区域公司新建合作伙伴进行检查和整理；3、如总部想针对某一集团客户的合作伙伴进行管理，则会赋予所有该集团客户内的公司唯一的、统一的、新的合作伙伴代码；4、总部如果在查出某个集团客户在一年内没有任何出货量，且没有相关商务信息，则总部可以删除该合作伙伴，并通知相关公司合作伙伴维护员；5、一旦总部在检查时，发现了同一合作伙伴使用不同合作伙伴代码，则在删除其中之一后，通知被删除合作伙伴所在区域公司的合作伙伴维护员；二、各区域、网点根据业务情况，指定12人员作为合作伙伴维护人员:维护原则：1、只有指定的维护人员有权限新建、删除、修改、查询

7、合作伙伴信息；2、在新建时，一定注意尽量不要发生同一合作伙伴不同代码的情况，保证合作伙伴在系统内的唯一性；3、在输入合作伙伴信息时尽量保证其信息的真实性；4、在输入合作伙伴信息时尽量保证其信息的完整性；合作伙伴的分类从业务关系角度，分为客户与供应商，这里指的合作伙伴主要指关联交易方或结算方，对于委托单上标示的shipper/consignee/notify party，及提单上须显示的承运人海外代理等不作为合作伙伴的方式管理。我们可以进一步细分客户或供应商。如细分为：船公司、报关行等等。对于客户与供应商，我们可以分别建立各自的数据体系，但是这样需要对于即为供应商又为客户的同时在两套体系中维护信

8、息。 由于在货代中交易双方经常互为客户/供应商，所以如果技术上容易实现，可以考虑将两者统一，然后再后面信息中标注其可能的角度。 对于合作伙伴可以考虑供应商/客户合在一起，但是价格体系必须区分收支两条线。合作伙伴的层次关系、集团管理类似于企业内部组织构架的模型，合作伙伴的层次关系和集团管理可以同样通过层次编码完成。这样一个管理功能通常交给集团完成。这样用例的提取应该是针对合作伙伴的层次编码的维护或者分组。可以考虑在每个合作伙伴基本视图中设置一些分组字段，用于今后的灵活分析。对于集团将某些单元的信息分配给其他单元共享的问题，其实质就是一个查询权限的问题，所以对于这样的业务管理需求，其抽象的业务模型

9、就是一个系统权限设置的问题。再有，客户信息属于企业的资源，而非个人或特定组织的，企业应该判断哪些信息需要这样控制，哪些信息不需要。否则容易将一个简单问题复杂化。其中，合作伙伴基础信息的查询权限对系统内全部放开。参考的用例模型如下所示： 以上两个管理功能，可以放到相对较低的优先级，相对其他功能比较独立，对整体系统构建影响不大。内部合作伙伴（internal-trade party）合作伙伴除了外部客户/供应商以外，还分为以下两类：内部跨公司间合作伙伴和公司内部利润中心间合作伙伴。由于内部交易相互形成委托，因而在日后的报表中需要考虑相关数据报表合并的问题，就像集团财务需要合并一样。在这里就需要在所

10、有业务模型中构建贸易关联方（internal-trade party），即互为客户/供应商的内部各方在报表体现是需要抵减、而且公司内和公司间的抵减还有所差异。合作伙伴要设置考斯特集团外、考斯特集团内考斯特物流外部、考斯特集团内考斯特物流内部三种选择项，以便区别和统计内外部合作伙伴情况 需要认真考虑内部交易后产生的合并报表问题以及实现方式，这一点对数据模型影响较大；关于合作伙伴相关的审批流程合作伙伴的审批流程通常不建议纳入业务操作系统，而是通过工作流软件或外部管理，相关内容参见基础信息审批及文档管理应用构架根据对组织结构的设置，客户、供应商的信息与业务单元和商务单元的关系是：n 合作伙伴（无论是

11、客户还是供应商）的基础信息的维护权限要落实到具体有权限的人员（如合作伙伴信息维护员），但查询权限对系统内全部放开。n 合作伙伴（无论是客户还是供应商）的商务信息与商务有关，信息的维护权限只能放到组织机构的商务科相关有权限的信息维护人员，但不需要细化到具体人员进行维护。n 合作伙伴的业务信息与人员有关，信息的维护权限要落实到具体人员（合作伙伴信息维护员或销售人员）。n 附权限表如下：查询权限维护权限（增加/修改/删除）船期表信息全部公司内有权限的人员合作伙伴基础信息全部组织机构内有权限的人员合作伙伴销售信息个人及授权个人及授权合作伙伴商务信息公司内有权限的人员组织机构内有权限的人员拜访计划个人及

12、授权个人及授权拜访记录个人及上级个人及授权个人及上级个人及授权拜访反馈个人及上级个人及授权个人及上级个人及授权合作伙伴共享申请个人及上级个人及授权个人及上级个人及授权合作伙伴共享批复个人及上级个人及授权个人及上级个人及授权协议个人及授权个人及授权组信息（客户组/港口组/等等）公司内有权限的人员组织机构内有权限的人员1.1 合作伙伴信息分类根据合作伙伴不同属性，可以分为客户和供应商两类，而具有客户属性的合作伙伴可以再细分为直接货主、货代、其他客户等不同角色，具有供应商属性的合作伙伴可以再细分为目的港代理、船公司、货代、报关公司、码头公司堆场公司、集卡公司等不同角色。同一合作伙伴根据实际业务需求可

13、以具有客户或供应商的多个角色，不同角色存在不同的信息内容。根据合作伙伴的不同角色，其信息的维护也存在一定的区别。可以根据合作伙伴类型查询，可多选。根据合作伙伴的具体内容分类，合作伙伴信息可以三类：n 公共（基础）信息n 业务信息n 商务信息合作伙伴的公共信息就是所有合作伙伴角色都具有的信息，包括以下内容：n 合作伙伴注册中英文名称n 合作伙伴中英文简称(规则？)n 合作伙伴助记码（助记码规则？）n 合作伙伴代码（不是系统自动生成）规则？n 合作伙伴地址信息n 合作伙伴角色n 合作伙伴所属地？n 合作伙伴主营业务n 合作伙伴主联系人及职务n 主联系方式（电话、传真、电子邮箱）n 维护负责人n 各

14、种样章n 集团客户n 不同的合作伙伴角色都存在不同的信息维护分类，可以分为以下两类： n 业务信息：由销售科维护的关于合作伙伴销售相关的基本信息包括：u 合作伙伴业务联系人信息u 合作伙伴业务联系方式（电话、传真、电子邮箱）u 信用等级（5级，1级最差，5级最优）u 合作伙伴所属销售人员u 业务额度u 业务描述（货类普通货/冷藏货/危险品/超标货/均有、货品、航线、每月货量、业务类型整/拼/散、海运/陆运/报关/仓储、进出口类型）可与拜访计划/拜访记录导入导出u 业务其他描述（如淡旺季、现供应商等文字性描述）u n 商务信息：由商务科维护的关于合作伙伴财务相关的基本信息包括：u （本外币）结算

15、方式u （本外币）结算对象u 合作伙伴商务联系人信息u 合作伙伴商务联系方式（电话、传真、电子邮箱）u 信用额度u 银行帐户信息u 信用等级（5级，1级最差，5级最优）u 合作伙伴所属商务人员u 只要系统有合作伙伴基础信息，则对于系统内任一公司而言，如未新建合作伙伴商务信息，结算方式默认为付款交单，商务等级、信用额度均为最低。合作伙伴所属商务人员默认为商务信息创建者，合作伙伴所属销售人员默认为销售信息创建者，可更改。合作伙伴的集团客户，建议设立为基础信息的一部分内容。系统外判断：如果填写合作伙伴基础信息时，选择的“集团客户”，则填写所知道的该客户的最高级别客户全称或简称，使两者相关联，以便统计

16、。委托书在委托人项录入合作伙伴（客户）后，揽货人项相应调用该合作伙伴（客户）在该公司所对应的业务信息中的所属销售人员，有多个则由录入员选择一个，也可手工更改录入。同一合作伙伴根据属性分类可能存在不同的角色分类，也就是说同一合作伙伴可能具有直接货主、货代、船公司、堆场、报关行等角色中的其中一种或者几种角色。同一合作伙伴只有唯一的基础信息，但其基础信息下又可能有多种业务信息和商务信息。为确保合作伙伴的唯一性，如果该合作伙伴已经在系统中维护并生成相应的合作伙伴代码，则不能重新建立合作伙伴信息，只能在原有合作伙伴中加入新的销售或商务信息。有权限的人员只能查询、维护自己建立的销售信息，且各公司中有权限的

17、人只能查询、维护本公司建立的商务信息。具有权限人员可分别打印合作伙伴基础信息、销售信息、商务信息和三者的集合，三者的集合和该合作伙伴的业务统计可生成该合作伙伴档案表。1.2 合作伙伴信息权限管理合作伙伴信息的权限管理分为客户信息权限管理和供应商信息权限管理两种: n 客户信息权限管理根据信息分类也分为两种情况分别处理：u 客户业务信息权限管理：客户业务信息由客户所属销售人员查询和修改，为了保证系统内合作伙伴的唯一性，由销售人员提交客户新建申请，由合作伙伴信息维护人员根据规则（如工商注册名称）统一进行唯一性校验，录入该业务单元的客户基本资料并生成客户代码和助记码，从而创建生成客户（基础）信息。销

18、售人员能够查询和修改所辖客户的业务信息，不同销售人员之间除非经过共享审批流程一般不能互相查询不同客户的业务信息，销售科长和上级领导可以查询所辖销售人员的客户业务信息。u 商务相关人员经过授权可以查询客户/供应商务单元信息。u 客户商务信息权限管理：只要有客户基础信息，就可由商务科相关授权人员补充该组织机构的客户商务信息。如尚未存在客户基础信息，由商务人员提交客户新建申请，由合作伙伴信息维护人员根据规则（如工商注册名称）统一进行唯一性校验，录入该业务单元的客户基本资料并生成客户代码和助记码，从而创建生成合作伙伴公共（基础）信息。u 同一公司内的人员可以查询该公司维护的客户/供应商商务信息。n 供

19、应商基本信息权限管理根据基本信息分类也分为两种情况分别处理：u 供应商业务信息权限管理：供应商业务信息一般由销售科长统一负责收集由专人根据工商注册名称维护。为了保证系统内合作伙伴的唯一性，由销售科长统一提交供应商新建申请，合作伙伴信息维护人员统一进行唯一性校验，录入该业务单元的供应商基本资料并生成供应商编码。同一组织机构下的各个业务单元可以共享查询所有供应商的业务信息u 供应商商务信息权限管理：创建过程与客户商务信息的创建过程一致n 如果合作伙伴涉及多个销售人员或者在多个区域公司被维护，那么如果查询该合作伙伴在其他销售人员下或者其他业务单元和商务单元内的业务信息和商务信息，需要通过【a1213

20、共享其他合作伙伴信息流程】以获得相应的查询权限。合作伙伴角色分类现在整理的已有的合作伙伴角色分类如下：参见代码表中文名称英文名称码头公司港务局货运代理freight forword直接货主direct consigner海运承运人 ocean carrier公路承运人highroad carrier驳船承运人barge carrier铁路承运人rail carrier船舶代理shipping agency订舱代理booking agency目的港代理destination port forword箱经营人container owner报关行customs broker场站container y

21、ard堆场stockyard仓库depot装卸公司load and unload company理货公司tally company熏蒸公司fumigate company海关三检customs and three check海事局maritime safety2 合作伙伴信息管理 a121a121合作伙伴信息管理分为如下几个部分：n a1211新建合作伙伴信息n a1212查询合作伙伴信息n a1213共享其他合作伙伴信息n a1214 修改合作伙伴信息2.1 新建合作伙伴信息流程 a1211业务规则：n br-a1-0075：客户基本信息的新建不需要相应的资质审核；但要对客户进行唯一性校验；

22、n br-a1-0080：供应商合作协议的新建首先需要存在供应商代码和合作伙伴信息。前提条件：合作伙伴基础信息在系统中没有维护。角色：销售人员、商务人员、合作伙伴信息维护人员输入：合作伙伴的基本信息资料基本流程：a.直接创建合作伙伴1. 销售或商务人员判断是否能够新建合作伙伴信息，参见业务规则br-a1-0075和br-a1-0080。2. 销售或商务人员根据合作伙伴基本信息，进入【a1212查询合作伙伴信息流程】，判断合作伙伴在系统中是否已经存在。3. 如果该合作伙伴基础信息已经维护，则不能再创建该合作伙伴的基础信息。那么销售人员判断是否需要共享查询该合作伙伴已经维护的信息。如果需要共享查询

23、，那么进入【a1213 共享其他合作伙伴信息流程】4. 如果该合作伙伴在系统中不存在已维护的合作伙伴信息，那么需要在系统中新建该合作伙伴。5. 销售或商务人员填写合作伙伴新建申请表（系统外）。6. 合作伙伴信息维护人员根据提交的新建申请表，进行合作伙伴的唯一性校验。7. 通过唯一性校验，生成合作伙伴代码，录入合作伙伴基础信息；没有通过唯一性校验，那么说明合作伙伴已经被该销售人员维护，通知相关销售或商务人员。8. 销售或商务人员在此基础上创建合作伙伴的销售或商务信息。a.先创建临时合作伙伴，后创建合作伙伴i. 销售或商务人员判断是否能够新建合作伙伴信息，参见业务规则br-a1-0075和br-a

24、1-0080。ii. 销售或商务人员根据合作伙伴基本信息，进入【a1212查询合作伙伴信息流程】，判断合作伙伴在系统中是否已经存在。iii. 如果该合作伙伴基础信息已经维护，则不能再创建该合作伙伴的基础信息。那么销售人员判断是否需要共享查询该合作伙伴已经维护的信息。如果需要共享查询，那么进入【a1213 共享其他合作伙伴信息流程】iv. 如果该合作伙伴在系统中不存在已维护的合作伙伴信息，那么需要在系统中新建该合作伙伴。销售或商务人员录入合作伙伴基础信息及相关的销售信息或商务信息。此时，该合作伙伴属性为临时状态，只能由该创建者查询、修改及创建拜访计划和拜访记录，不能参与统计等其他功能。v. 当该

25、合作伙伴与我司将要发生业务时，销售人员或商务人员向合作伙伴信息维护人员提交改变合作伙伴临时状态申请表（系统外）。vi. 合作伙伴信息维护人员根据提交的申请表，进行合作伙伴的唯一性校验。vii. 通过唯一性校验，生成合作伙伴代码，改变临时状态；没有通过唯一性校验，那么说明合作伙伴已经被该销售或商务人员维护，通知相关销售或商务人员。viii. 销售或商务人员在临时状态上创建合作伙伴的销售或商务信息及拜访记录和拜访计划继续有效。相关功能：查询合作伙伴基本信息、填写合作伙伴新建申请、修改合作伙伴新建申请、查询合作伙伴新建申请、驳回合作伙伴新建申请、录入合作伙伴业务信息、录入合作伙伴商务信息输出：合作伙

26、伴基本信息记录相关表证单书：青岛客户档案资料，上海客户档案资料，广州客户档案资料系统用例：2.2 查询合作伙伴信息流程 a1212查询合作伙伴信息流程的主要作用是通过查询条件的录入，对全系统内的合作伙伴信息进行检索，显示本地的合作伙伴信息及通过申请后查看异地合作伙伴信息记录。业务规则：n br-a1-0100：系统所有内部用户能够查询系统中所有合作伙伴的公共信息，包括注册名称、代码以及所属区域公司等n br-a1-0110：销售人员能够查询自己所辖合作伙伴的全部信息n br-a1-0120：销售人员不能查询其他销售人员所辖合作伙伴的销售信息n br-a1-0130：在公司组织架构中，销售科长、

27、上级领导和相关授权人员能够查询所辖销售人员的所有合作伙伴信息记录。n br-a1-0140：在集团组织架构中，处于上级公司的相关授权人员能够查询所辖下级公司的所有合作伙伴信息记录。n br-a1-0150：如果销售人员需要查询其他人员（本地或者异地）维护的合作伙伴基本信息，那么进入a1213共享其他合作伙伴信息流程。前提条件：需要查询的合作伙伴信息已经维护在系统中角色：销售相关人员输入：查询条件基本流程：1. 销售人员录入合作伙伴信息查询条件2. 系统判断查询权限，参见业务规则br-a1-0100、br-a1-0110、br-a1-0120、br-a1-0130和br-a1-0140。3. 判

28、断合作伙伴所属并进入【a1213共享其他合作伙伴信息流程】，参见业务规则br-a1-0150。相关功能：输出：合作伙伴信息记录系统用例：2.3 共享其他合作伙伴信息流程 a1213a1213共享其他合作伙伴信息流程具有两个层次的共享审批流程：n 公司内部合作伙伴信息的共享：体现在客户相关信息在不同销售人员之间的共享审批流程。n 公司之间合作伙伴信息的共享：针对区域公司需要查询其他同级区域公司或者上级公司的客户相关信息的共享审批流程。能够共享的客户信息包括业务信息、商务信息以及业务量情况等相关信息。系统对需要共享的客户信息进行分类，并能够让销售人员确定需要共享查询合作伙伴的某些信息，其他合作伙伴

29、所属销售人员在批注共享意见的时候，能够从中选择并确定某些信息同意共享，某些信息不同意共享，这样能够灵活地实现客户信息共享的流程。业务规则：n br-a1-0170：当销售人员需要查询其他销售人员所辖的合作伙伴详细信息时，需要进入该流程；否则，不需要进入该流程。n br-a1-0180：销售人员能够选择需要对方销售人员共享的合作伙伴信息。n br-a1-0190：如果销售人员所在的组织机构公司和需要共享的合作伙伴信息所属的组织机构是一致的，那么该合作伙伴属于该组织机构的本地；否则，属于异地。n br-a1-0195：合作伙伴基本信息的查询对系统内部全部开放。n br-a1-0200：针对共享异地

30、合作伙伴销售信息的情况，申请者所属组织机构的负责人在审核时需要判断共享申请的必要性。n br-a1-0210：信息所在机构的负责人在签署共享审批意见时，能够从申请者需要共享的合作伙伴信息中确定其中销售或商务信息是否同意共享，并可批注相关意见。n br-a1-0220：针对共享本地合作伙伴销售信息的情况，那么最终的审批确认和共享权放在该组织机构的负责人。n br-a1-0230：针对共享异地合作伙伴销售信息的情况，根据集团组织架构确定共享查询的审批路径：u 如果需要共享查询其他同级别组织或者其他同级别的下级组织的合作伙伴销售信息，那么最终的审批确认和共享权放在该组织的上级组织机构。u 如果需要共

31、享查询直接上级组织或者直接上级组织的同级别组织的合作伙伴销售信息，那么最终的审批确认和共享权就放在该组织直接上级的上级组织机构。u 如果需要查询总部的合作伙伴销售信息，那么批注意见和最终的审批确认和共享权都放在总部。u 合作伙伴共享申请一经提交，不得修改和删除；u 共享合作伙伴信息只能被查询，不能被修改或者删除；前提条件：参见业务规则br-a1-0170角色：销售人员、本地上级领导、其他合作伙伴信息所属销售人员、上级合作伙伴信息共享审批人员输入：合作伙伴共享申请基本流程：1. 销售人员填写合作伙伴基本信息共享申请表，参见业务规则br-a1-01802. 判断需要共享的合作伙伴属于本地的还是异地

32、的，参见业务规则br-a1-01903. 如果是本地合作伙伴，那么由合作伙伴所属销售人员签署意见，参见业务规则br-a1-0210，再由销售科长根据销售人员意见进行审批确认和共享，参见业务规则br-a1-02204. 如果异地合作伙伴，首先经过本地区域审批，参见业务规则br-a1-0200。那么由合作伙伴所属销售人员签署意见，参见业务规则br-a1-0210。再由上级区域根据销售人员意见进行审批确认和共享，参见业务规则br-a1-0230。相关功能：填写合作伙伴基本信息共享申请表、修改合作伙伴基本信息共享申请表、查询合作伙伴基本信息共享申请表、审批合作伙伴基本信息共享申请表、批注合作伙伴基本信

33、息共享申请表、驳回合作伙伴基本信息共享申请表、共享合作伙伴基本信息输出：共享的合作伙伴信息记录相关表证单书：系统用例：2.4 修改合作伙伴信息流程 a1213业务规则：n br-a1-0240：合作伙伴的修改权限与合作伙伴的查询权限相同，原则是谁维护就谁修改n br-a1-0250：有权限的销售人员能够修改所辖合作伙伴的业务信息，有权限的商务人员能够修改所辖合作伙伴的商务信息n br-a1-0260：合作伙伴基本信息的注册名称和代码不能通过此流程修改，只能走新建流程。前提条件：合作伙伴信息有变化角色：合作伙伴信息维护人员、销售人员、商务人员输入：需要更新的合作伙伴信息基本流程：1. 通过a12

34、12查询合作伙伴信息流程查询得到相关合作伙伴信息2. 修改合作伙伴的信息，参见业务规则br-a1-0240、br-a1-0250和br-a1-02603. 生成合作伙伴信息修改记录，内容包括修改人、修改时间、修改后数据等信息 相关功能：查询合作伙伴基本信息、查询合作伙伴信息修改记录、归档合作伙伴信息修改记录输出：修改后的合作伙伴基本信息系统用例：3 合作伙伴信用管理 a122合作伙伴信用管理分为客户信用等级管理和供应商信用等级管理两部分，对于同时具有客户和供应商双重属性的合作伙伴，其相应的合作伙伴角色也分别具有客户信用等级和供应商信用等级。合作伙伴信用等级不是单纯依靠系统的相关统计结果自动计算

35、的，而是销售人员或者商务人员参考系统的相关统计结果，并综合主观理解和认识，依据相关的信用等级评定规定，综合判断得到的。业务规则：n br-a1-0265：合作伙伴信用等级评定的考虑因素：分别从业务和商务角度来考虑，客户信用等级分为以下两种：u 客户业务等级：客户业务等级由销售科根据客户的业务量情况以及潜在货量等因素综合决定。具体的参考标准有：l 以客户在一定期间（月度、季度、年度）完成的货运量为标准。l 以客户在货运淡季的支持量为标准。l 以客户的规模、潜在货量为标准。l 以客户的公司性质作为标准，如直接客户、货代等。u 客户商务等级：客户商务等级由商务科根据客户的收入利润以及帐龄分析等因素综

36、合决定。具体的参考标准有：l 以客户付费期缴付费用情况为标准。l 以客户以往缴费情况为标准。l 以客户的收入利润为标准。l 以客户的结算方式为标准。分别从业务和商务角度来考虑，供应商信用等级分为以下两种：u 供应商业务等级：供应商业务等级由销售科根据供应商的业务量、价格和服务质量等因素综合决定。具体的参考标准有：l 供应商的规模和实力。l 长期合作的供应商的价格是否合理。l 长期合作的供应商的价格是否优惠。l 提供的服务是否全面。l 提供的服务质量是否达到标准。l 处理特殊情况的能力是否强。l 供应商的以往信誉。u 供应商商务等级：供应商商务等级由商务科根据供应商的结算方式以及财务状况等因素综

37、合决定。具体的参考标准有：l 供应商的结算方式。l 供应商注册资本等财务状况信息。n br-a1-0270：合作伙伴（包括客户和供应商）信用等级（包括业务信用等级和商务信用等级）评定的具体标准由总部统一制定，在制定过程中可以参照公司现有的相关文件进行明确规定。n br-a1-0290：合作伙伴的信用等级的业务等级和商务等级一般分别由销售科长和商务科长负责定期更新，特殊情况下（比如客户恶意欠款等情况），可以及时更新合作伙伴信用等级。n br-a1-0300：在每票业务完成之后，由业务操作部对该票业务涉及的供应商的服务质量进行评价并打分，从而能够较好的量化供应商的服务质量。在具体操作中，考虑到业务

38、操作人员的工作量，可以在多数情况下不打分而是采用缺省分数，只需要在服务极好和极差的情况再单独相应分数。供应商的服务质量按照5分制进行量化，缺省情况下每票业务的供应商的分数为3分，业务操作人员可以根据实际情况调整供应商的分数，当供应商分数为5分或者1分的时候，需要打分者提供相应的备注，解释服务质量很好和很差的原因。n br-a1-0350：供应商的价格比较是指通过比较一段时期内相同服务内容的不同供应商的价格，确定相应供应商的价格表现，具体价格分析视图可以参见商务分析相关报表。n br-a1-0355：考虑到各个区域公司的实际情况，系统需要采用配置方式灵活设定客户和供应商信用等级评定的量化指标。n br-a1-0356：合作伙伴等级评定标准解决方法：由总部制定统一的合作伙伴等级评定标准，规定合作伙伴等级评定需要考虑的主要因素，各口岸公司和网点根据实际业务需求参照执行。3.1 维护客户信用等级 a1221前提条件：参见业务规则br-a1-0290角色：销售科长/商务科长输入：客户相关信息基本流程：1. 销售科长统计客户月度、季度和年度业务量并排名，确定客户的业务表现值2. 销售科长统计客户月底、季度和年度收入利润并排名