客户联系人的近期改造说明介绍
金蝶云社区-hansenchu
hansenchu
7人赞赏了该文章 4,927次浏览 未经作者许可,禁止转载编辑于2017年10月26日 17:50:55
summary-icon摘要由AI智能服务提供

八月份补丁对客户基础资料的联系人进行了改造,简化了表结构,取消了联系人分录表,统一保存于联系人资料公共表。改造解决了同步问题和用户扩展字段问题,简化了新增/修改联系人的操作,并建议设置默认联系人以增强过滤和引用。同时,业务单据和套打打印上的引用需通过默认联系人或新增客户联系人字段实现。

在八月份的补丁中,对客户基础资料的联系人做了一些改造调整,标准产品调整之后,客户的二开中如果涉及这方面的,也应该做一下相应的调整,主要涉及在业务单据对联系人信息的引用应用和套打打印时对联系人及地址信息的取数打印等。在这里,将对这次调整改造做一下说明介绍,简单介绍一下改造涉及的主要方面和应用,具体的二开调整请自行参考说明根据实际的业务需求进行修改。
一:改造前的现状。


8月份的补丁之前,客户的联系人既是客户基础资料的分录属性,保存在客户的联系人分录表中,同时又是联系对象基础资料,保存在联系人资料公共表中。当在客户基础资料里新增/修改联系人,或者是通过Excel批量引入联系人的时候,是先保存到联系人资料公共表,然后通过程序自动同步到客户的联系人分录表中。但是,这种结构设计将会带来一些问题。
1、新增联系人的时候,在弹出来的联系人编辑框中点了保存,这个时候这个联系人已经保存进了联系人资料公共表中。虽然界面上已经看到客户联系人分录中同步了这个联系人资料过来,但在点击客户保存按钮之前,这个分录表信息是不会保存的。如果这个时候误关了客户单据并且未执行保存,这个新建的联系人将不会真正同步到客户的联系人分录表中,重新再新增同一个联系人,就会产生多条重复的冗余信息。Excel引入联系人的时候,同样有这样的问题,不过引入时只会当程序中断或报错的时候才可能造成数据同步失败,可能性较低。也就是说,原来的两个表同步的结构设计,是很有可能造成系统中联系人资料的不同步。
2、用户自行扩展新增的联系人字段,无法做到同步。实际业务场景的不同,有些用户会需要在联系人资料中扩展新增一些字段,虽然点开新增/修改联系人可以看到,但却无法同步到客户联系人页签的分录里,这是因为这两个表之间的数据同步是有插件代码处理的,用户无法修改。
3、有些用户在业务单据或者套打模板上直接引用了客户联系人分录的字段,并且是引用到业务单据上某一个表头字段上。这种用法当客户里只有一个联系人的时候是没问题的,但如果有多个联系人的情况下,就永远只能取到第一行联系人,不管第一行联系人是否为默认联系人。这是因为这种用法实际上是将一个集合赋值给了一个字段,多对一的赋值,只能永远取到第一个。同样的,因为第2个问题中所说的, 两个表无法同步用户扩展新增的字段,因此业务单据上也无法引用到用户扩展新增的字段。

二:改造后
基于上述问题,以及一些其他细节上无法很好处理的不便之处,对客户联系人进行了改造。改造的核心是简化了当初不太合理的重复表保存的结构,客户的联系人分录上的分录表T_BD_CUSTCONTACT表不再使用,联系人数据统一只保存并来自联系人资料公共表T_BD_COMMONCONTACT表。改造之后,因为联系人数据只在一张表中,没有了同步数据的麻烦。
1、去掉了联系人分录表,相当于弱化了联系人资料作为客户分录属性的特性,更多的是将联系人作为一个相对独立的基础资料,由程序对两者进行关联,主要体现在客户的联系人信息是客户基础资料打开后再去查询并填充到联系人分录的。


联系人分录表去掉之后,对应的分录主键也没有了意义,一起去掉了,如上图所示。用户的二开中如果有使用到这两者,主要是在二开插件程序中,需要请二开的开发人员对此修改,去掉引用或改为其他方式实现需求。
2、为了方便用户对联系人字段进行扩展,修改了联系人页签中分录里的字段元素类型。


如图所示,联系人编码字段改了基础资料,而其他联系人名称等联系人的属性字段,都为基础资料属性字段。因此,用户二开中如果有直接使用这些字段的,也需要改为从联系人编码这个基础资料中引用,而不是直接使用联系人名称等基础资料属性。
不过,这个改动,则方便了用户扩展联系人字段,比如,用户在联系人新增/修改界面扩展新增了一个叫“联系人所在部门”的字段,用户只需要在客户的联系人分录中同样增加一个对应的基础资料属性字段,即可实现信息的同步携带,在业务单据上引用的时候,也是直接从联系人基础资料中引用,方便用户自行扩展信息。
3、在以前的模式下,新增一个联系人,需要点两次保存才能实际上保存完毕,一次是新增联系人时点保存,一次是客户基础资料的点保存,以同步存到分录表中,如果因为某些原因,第二次保存没有操作,系统中将出现一条垃圾信息,并且可能会在某次联系人引入操作时候重复关联进来。修改之后,新增联系人只需要执行一次保存即可,重复新增的联系人不会跟同一个客户都建立联系,减少一点垃圾信息。
4、客户的联系人分录已改为非物理表,仅仅只是一个动态分录,因此,在客户列表上的过滤中,已不能通过联系人分录进行过滤。但是在客户的商务信息页签中,实际上有一个目前不可见的默认联系人字段(下一个补丁将会把它改为可见)。这是一个物理字段,列表上的过滤可以通过它来进行,前提是,客户的基础资料中有设置默认联系人的勾选,这个勾选依然在联系人分录中操作完成。

同样的,在业务单据上,比如销售订单的客户字段上,客户字段的引用属性里,原有的联系人页签下的字段引用,如“联系人.姓名”不能再使用,而需改为"商务信息.默认联系人"。

如果单据上需要使用到联系人姓名、电话等信息并填在单据上的一些文本字段上,建议的参考方案可以这样:以销售订单为例,在表头新增一个基础资料字段,基础资料类型为客户联系人或者联系人(选择采购管理下的那个),但要注意的是,如果基础资料类型选择为联系人,则这个字段的过滤属性中要加上“FCOMPANYTYPE = 'BD_Customer'”如下图所示,


同时客户字段的引用属性增加商务信息.默认联系人,通过客户的值更新事件或实体服务规则等将默认联系人携带到新增的客户联系人字段上。然后再通过这个客户联系人基础资料字段作为源头,利用值更新事件或实体服务规则将联系人的名称、电话等属性信息带出,赋值到对应的文本字段上。

虽然这样的方案看似有点曲折,没有以前那样客户的引用属性中直接引用联系人.名称那样直接,但是需要注意到的时候,以前那样的引用方式,是将一个集合携带到一个字段的多对一的做法,实际上是不合理的,因为这种做法永远只能携带到客户联系人的第一行联系人记录,当客户有多个联系人且默认联系人不是第一行的时候,就会发现默认联系人设置无效,信息携带错误了。
也有一些用户是在套打打印上使用到联系人的属性信息,也可以通过上面所说的参考方案实现。或者在客户基础资料上增加冗余字段实现,具体的实现方案可以参照下帖:
http://club.kingdee.com/forum.ph ... &tid=1286816&extra=

总的来说,这次的修改,主要是简化了联系人的表结构,统一数据表为T_BD_COMMONCONTACT,原有的联系人分录字段不能直接使用,增强了客户默认联系人字段的作用。用户最好尽可能地设置好客户的默认联系人。联系人的新增和导入操作不变,但数据同步方面会更加方便,也方便用户自行扩展联系人的属性字段。从下一个补丁开始,默认联系人字段将会由不可见改为可见,客户列表的过滤可以通过默认联系人来过滤。业务单据上引用联系人属性也尽量从默认联系人携带而出。选择客户携带联系人时,如销售订单上选择了客户,自动携带收货方联系人,当客户有设置默认联系人时,收货方联系人自动带出默认联系人,否则,自动带出客户的第一行联系人。