业务要点

基于上篇提到的方案背景和设计原则，对接方案包含如下业务要点：

第三方公司传统的门店管理架构如下所示：

以上是比较典型的第三方公司的复杂架构体系，如果再考虑到组织内的各级员工管理，对接方案将会变得异常复杂。

实际上，我们可以将门店架构，精简为经典的门店--品牌商--经销商三级架构：

目前部分第三方公司对外的是SAAS 服务，账号体系不仅复杂，而且存在频繁的更新操作。此部分的数据同步，需要第三方公司和开放平台约定好机制。此外，开放平台将来也会提供账号同步接口。

第三方公司的员工账号系统是业务对接的一个难点，因为开放平台和它之间存在双向数据同步需求。员工的入职，换店，离职，病休，绩效等各种复杂的业务信息，会将对接方案变得异常繁杂。

根据方案的设计原则，账号系统的同步采用极简化方案设计：

经销商和品牌商，使用开放平台的账号体系，在开放平台的管理后台进行操作；开放平台和第三方公司无账号同步操作；
开放平台上，每个门店统一分配一个账号用于登录大屏；此账号独立于第三方公司账号体系；
第三方公司的检测订单，会有门店员工信息(比如检测技师的信息)，都仅仅作为附属信息，调用检测OPENAPI的时候传入开放平台；开放平台不对此类员工账号信息做任何校验，仅仅作为检测报告的附属展示信息；
因为不存在双方用户账户强关联关系，系统鉴权操作，统一用token机制进行权限认证；只要token合法，就认为拥有对应的操作权限；

第三方公司一般都有自己的车型车款信息系统，这些系统或是自建或是对接第三方；开放平台也有自己的车型车款信息。系统对接处理方案：

开放平台有一整套保养计划体系，第三方公司使用开放平台的保养计划。目前在保养计划环节，开放平台暂时不接受第三方公司的反向同步。举例来说，第三方收到保养计划后，某项保养任务完成后，不需要通知开放平台更新。

保养计划（包括非正常的问题点），将来会扩展API接口支持反向同步，来保证双方通过合作更好的维护一辆车的问题和保养。

需要额外注意的是，开放平台的保养计划的生成，依赖出厂日期、公里数等参数，第三方公司务必将这些参数传入。

第三方公司通常有自己一整套闭环的商品物流供应链体系，开放平台提供机制，将双方的推荐服务做关联。点击开放平台系统的大屏APP时，可以跳转到第三方公司的H5链接地址，后续操作由第三方公司完成商品交易闭环。

第三方公司通过SDK&API方式和开放平台进行业务对接。正常的检测流程，一般分为如下几个部分：

首先，以上三部分需求，都可以通过开放平台的OPENAPI进行对接；

其次，第三方通常对接车单环节有很多定制化需求，这部分推荐用OPENAPI解决；检测和施工环节，建议使用开放平台的SDK；检测报告，施工报告和保养计划，可以使用开放平台的H5页面，也可以使用接口返回的json格式数据自己定制页面。

Last updated 4 years ago