对接数云相关FAQ

目录

由于数云系统的特殊性，数云方不提供测试环境，Linkflow在对接开发迭代的过程中主要依赖客户方提供的真实线上系统账号进行测试开发，目前已经对接完成的功能中间可能有部分疑惑的点，梳理如下：

订单相关：

1、如果一个订单退款了，订单状态是什么样子的？

答：

举例如下：
1笔主订单只有一笔子订单时：
一、售前部分退款，主订单状态是：TRADE_FINISHED
二、售前全额退款，主订单状态是：TRADE_CLOSED_ALL_REFUND
三、售后部分/全额退款，主订单状态是：TRADE_FINISHED

1笔主订单有多笔子订单时：
一、售前部分子订单部分退款，主订单状态是：TRADE_FINISHED
二、售前部分子订单全额退款，主订单状态是：TRADE_FINISHED
三、售前全部子订单部分退款，主订单状态是：TRADE_FINISHED
四、售前全部子订单全额退款，主订单状态是：TRADE_CLOSED_ALL_REFUND

2、当订单状态为交易成功时，是否为终态呢，后续是否还会再发生退款的情况？

答：不是最终态，后续可以继续退款。

3、如果一个订单退单，那么接口中获取时是什么样子的？

答：

举例如下:
一个用户购买了 3件商品 A、B、C，在订单接口查到的就是一个主单信息，然后附带三个A、B、C子订单
那如果这个用户退了2个商品A和B， 在接口查询的时候是 查到一个新的主单，然后附带A和B两个退单子订单吗?

答:首先退单不会生成一个新的订单号。他会通过2个字段做区分，是在子订单上的refund fee(退款金额)和 is refund(是否退单成功)。
退单时，视退单状态为区分，可以分2种:
第一种是用户申请退款了，但是申请退款没有成功。这时，refund fee 有金额，但是is refund 是0(未退单)。主订单上的refund fee 没有金额
第二种是用户申请退款了，申请退款也成功了。 这时，refund fee 有金额，isrefund 是1(退单成功)。主订单上的refundfee有金额。
所以获取订单时，需要判断2次，第一次是以普通的订单入库，第二次是需要判断订单中是否已经有部分商品已经退单.

4、Linkflow记录订单事件的功能不是走的更新逻辑，而是每次请求到最新更新的这部分订单数据就存储，中间必然会存在订单重复的问题，且无法通过状态是否一致来决定是否去重不记录，是否有别的方法去重？

答：只能通过字段：shuyun_modified，这个是订单的更新日期，通过比对这个日期，来做更新或者跳过处理。即：每次只能通过这个时间字段，来将当前订单的所有字段跟前一次记录的订单所有字段进行匹配，如果不一致才记录

5、子订单里面的退单，是指整个子订单被退，还是子订单的部分退款？

举个例子，比如一张主订单，包含3个子订单，其中1个子订单里面有2个商品，然而这个子订单如果只是退了其中一个商品，那会怎么样？

答：如果只退了一个商品，不会显示退货数量，只会有实际退款金额。同时，一个子订单，无法发起2次退款。其中，退货数量没有单独的字段会体现，即：无法区分子订单的部分退款情况。

6、订单接口中的last_update字段的详细说明。

答：last_update是各个线上平台，正单的最后更新时间。如果订单产生了退款，这个时间不会更新，且不会记录退款时间，只会更新数据库修改日期，接口中有一个shuyunModified 字段，是数云数据库修改日期，通过此字段来判断后续这张订单的持续更新时间节点。

7、grade字段是否存在字典值供我们请求？

背景：如果客户端将对应的值进行了更改，那么不会推送给Linkflow，那么我们保存的值依然是修改之前的，那么在Linkflow做等级字段分析的时候就无法对应上。

答：等级字典接口地址 https://open.shujuyingjia.com/#/apidoc?type=41&apiId=98

目前客户只存在1个卡计划的情况下，客户可以自行通过配置等级元数据的字典值来实现等级名称保持最新。

异常情况：如果客户存在两个卡计划，即存在两套等级体系的话，方案待定。

8、数云定义的outer_sku_id以及skuid是如何定义的？

答：outer_sku_id应该是客户在京东或者淘宝店铺上自己维护的，对应淘宝外部商品编码。

skuid就是淘宝自己生成的商品id

9、关于数云这边全渠道的订单数据，其中订单号是否有可能会重复？目前来看，比如有赞的订单，系统里能看到是直接用的有赞提供的订单号，那么多渠道的话是否有可能会跟京东或者淘宝的订单号重复呢？

答：理论上不太会，但是从技术角度来考量，建议加入一些联合主键，例如用platCode + shopId + orderSn（主订单号） ，这样做，可以确保一定不会重复。

10、订单接口中的num字段是该订单商品的总数量吗？接口文档中没有这个字段的说明。extendProps还有一个product_num，是一样的吗？等于各子订单的数量总和?

答：是的。

11、receiver_mobile、receiver_district、receiver_name、receiver_address这四个字段是不返回的吗？这个字段在文档上有，但是接口中不返回

答：淘宝隐私改造，不返回了。

12、订单order_status状态有哪几种？枚举在哪里看？

答：https://open.shujuyingjia.com/#/document/docs?docId=42

13、针对订单事件中的很多重复的事件记录，目前的做法是怎么样的？

答：每天批量删除部分重复事件数据，规则是：event删事件同一订单编号、同一状态留最后一条，删除之前的订单事件和相应的子事件，

（先尝试分析结果：租户734/737/740（只有这3个对接了数云），事件SHUNYUN__MEMBER_SO子事件SHUNYUN__MEMBER_SO_ITEM，订单编号s_orderSn，订单状态s_orderStatus）

14、全量同步订单，如果该订单是非会员下的单子，那么系统是如何记录订单事件？

答：订单是全量同步，其中包含了某些非会员的订单，Linkflow会将这部分非会员的订单创建完用户之后，再将订单事件挂在对应用户身上。

会员相关：

1、同步后的会员数量为什么和数云后台的总数不一致？

答：

数云系统逻辑：

数云的每一个会员在一个店铺会生成一个platAccount以及memberID，然后在每一个店铺下的唯一识别ID是platAccount字段，数云方针对会员会通过一定的算法进行合并，其中合并完之后的memberID会变化（具体算法不详，可能后面的memberID覆盖前面的，也有可能前面的覆盖后面的），所以，在Linkflow端无法使用memberID作为用户的唯一识别id，只能使用platAccount字段。

场景举例1：数云端有1张会员卡的情况下，以张三为例

1、1日，进入店铺A，入会1，生成memberid：x1，platAccount：a

2、2日，进入店铺B，入会1，生成memberid：x2，platAccount：b，合并后memberid：x2或者是 x1

那么，在Linkflow端同步情况如下

1日同步，记录memberid：x1，platAccount：a

2日同步，记录memberid：x2或者是 x1，platAccount：b

结果为，数云中会员1人，在CDP1中，就是张三在Linkflow中会产生2个联系人，在CDP2中，自动合并成1个人

场景举例2：数云端有2张会员卡的情况下，以张三为例

1、1日，进入店铺A，入会1，生成memberid：x1，platAccount：a

2、2日，进入店铺B，入会1，生成memberid：x2，platAccount：b，合并后memberid：x2或者是 x1

3、3日，进入店铺C，入会2，生成memberid：x3，platAccount：c，

4、4日，进入店铺D，入会2，生成memberid：x4，platAccount：d，合并后memberid：x4或者是 x3

那么，在Linkflow端同步情况如下

1日同步，记录memberid：x1，platAccount：a

2日同步，记录memberid：x2或者是 x1，platAccount：b

3日同步，记录memberid：x3，platAccount：c

4日同步，记录memberid：x4或者是 x3，platAccount：d

结果为，数云中会员2人，在CDP1中，就是张三在Linkflow中会产生4个联系人，在CDP2中，自动合并成1个人

2、业务上，会员是否有有效期？今天是会员明天可能就不是会员了？

答：有可能的，用户如果自行做了解绑的动作，那么就变成非会员了。状态显示：解绑。

3、卡计划id是什么？从哪里获取？

答：

• 一个会员卡会有一个卡计划ID。  有几个会员卡视品牌希望做几个会员体系而定。
• 卡计划ID需要向数云工作人员询问获取。
• 卡计划跟店铺之间可能是一对一，也可能是一对多。不可能多对多。

4、接口中的会员卡号如何使用？

答：这个字段忽略，业务上用不到了，以后接口拿到不到这个数据。

5、同步进Linkflow系统中的联系人跟数云系统中店铺下用户的属性明细是否可能是不一致的？

答：是的。

举例说明：

首先，Linkflow取数云的字段列表来源，如下：

以张三为例，从A、B两个店铺进来，分别入会，但是填入的信息如果是不一致的情况下，那么数云这边会将两个人合并成一个会员，其中上表中第一个接口返回的数据是合并后的统一的数据（如果两次会填写的不一样，会返回一样的数据，具体前面覆盖后面还是后面覆盖前面是根据数云的算法定的），上表中第二个接口返回的是在各个店铺的这个用户的信息（如果两次会填写的不一样，会返回不一样的数据），上表中第三个接口返回的是会员在对应卡下的等级（数云方合并后是一样的）

所以，如果在数云中直接查看这个用户在对应的店铺下的详细信息，这种情况下，看到的用户的数据是数云合并前原始数据，差异的数据主要会集中在上表中第一个接口的部分字段值。

6、同步过来的用户一定都有手机号码吗？

答：不一定的，目前未承诺100%存在，主要取决于数云解析的能力。

7、客户方如果新增卡计划、新增店铺，那么在Linkflow中是否需要重新开始同步？

答：CDP1不需要，CDP2需要。

在CDP1中如果尚未开始同步会员或者订单，那么在新增完卡计划以及店铺之后，开始同步即可；如果已经开始同步会员以及订单，在后面再新增更多的卡计划以及店铺，那么不需要再次点击同步按钮，Linkflow会自动轮询到对应的卡计划id以及店铺id进行同步相应的会员以及订单数据。

（CDP1中的缺陷在于，后续新增的卡计划以及店铺，自动同步的数据是从当前节点开始往后的，而非全量开始同步）

在CDP2中将卡计划、店铺分开独立管理配置，每新增一个店铺，需要单独开始同步对应的订单，每新增一个卡计划，需要单独开始同步对应的会员。

8、用户属性中部分字段并非来自于数云接口映射，是什么逻辑？

答：

以上6个字段是在系统创建连接成功之后，Linkflow自动生成的6个字段。

以上字段的属性值计算逻辑：根据接口返回属性的绑定状态（绑定哪个平台），来决定将上述对应的属性字段值置为“是”，解绑或者没有属性值，则置为空。

也就是通过这个字段来判断当前用户是否是平台的会员。

9、目前系统只支持淘宝、京东、有赞、线下、抖音、小红书（其中cdp1不支持小红书）这个平台的店铺，所以在系统中新建店铺的时候只能选择到以上6个？

答：是的，如果需要支持更多的平台店铺，后续提需求进行开发迭代。

10、为什么京东店铺同步进来的会员跟订单是无法区分的？

答：针对京东渠道，目前会员透出的ID是pin码，而订单里的客户ID，是openId
因为openId 和 pin Id 本身就是2种不同的加密方式，所以京东的订单无法区分是不是会员单。

11、对接的淘宝、有赞、京东店铺中，当会员发生等级变更和积分变更事件时，有返回店铺id，但是部分平台编码platCode显示是DATAWINER，这是什么原因？

答：如果返回值，都是 DATAWINER，这表示，这笔积分的流水产生，是因为数云中台操作导致的。如果积分的产生，是别的渠道，例如淘宝，京东，那么对应的platCode就是 TAOBAO 或者 JOS。

12、is_refund，是否退单，接口返回是0或者1，但是字典值有3个，为什么不一致？

答：文档的公共字典处显示的是否退单，是针对另外一个字段的，目前数云方尚未透出，所以无法使用到。而对接中使用到的这个字段0代表无退单，1代表部分退单以及全部退单。

13、会员的等级显示处理逻辑是什么？

答：租户在配置完事件中会员等级元数据的字典之后，我们系统中可以显示对应id的字典值，且配置的时候需要配置数云系统中长的那串等级id。（原因在于如果有多个卡计划的情况下，短的id会出现重复的情况）

举例如下：

 "grades": [{
            "gradeId": 12445,
            "name": "普通会员",
            "id": 1
        }, {
            "gradeId": 12446,
            "name": "高级会员",
            "id": 2
        }],

数云系统中每设置一个等级会有两个id，配置元数据字典需要使用的是长的这个gradeId。

完成以上设置后，开始同步会员信息，首先我们系统中会拉取字典表，逻辑是：

• 每次点击同步卡计划就通过遍历店铺去获取对应的等级字典
• 第一次点击以后如果拉取不到字典或拉取到的字典卡计划id与同步的不一致都会报错
• 在全量同步的过程中默认使用一开始拉取到的字典，不更新拉取到的
• 在增量同步过程中，跟着定时任务一起每半小时更新一次
• 在更新过程中如果没有拉取到最新的字典则默认使用一开始全量同步前拉取到的字典