技术领域
[0001] 本发明属于网约车技术领域，具体涉及一种补全下车坐标点与地址的候补方法。
相关背景技术
[0002] 在网约车场景中乘客实际下车点经纬度和下车地址都是由司机操作订单服务完成动作后，司机App主动上报到服务器端的。
[0003] 但经常会有少部分订单由于司机App原因、网络信号或司机未主动开启定位无法采集经纬度等原因，导致订单上缺失乘客实际的下车点经纬度和下车点地址。最终无法精准核算订单的费用，也为后续客服处理客诉带来了困扰。因此如何补齐由于以上种种原因导致的缺失乘客实际下车点经纬度和下车点地址成为必须要解决的问题。
[0004] 为此，本发明设计了一种补全下车坐标点与地址的候补方法。
具体实施方式
[0035] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0036] 请参阅图1‑2，本发明提供一种技术方案：一种补全下车坐标点与地址的候补方法，本发明是一种程序能够自动探测订单上缺失两项数据时，主动补齐两项数据的有效方案。当司机在司机App上操作服务完成后，程序在2分钟内若检测到订单上缺失两项数据的任何一项时，则向乘客端App推送问询乘客是否已在订单预约下车点下车的确认消息，当乘客点击【确认】动作后，由乘客端App采集当前乘客的经纬度数据并主动上报至服务器端，服务器端收到请求后再将该信息更新至订单上，最终达到为订单补齐两项数据的目的。
[0037] 本发明分为自动探测订单是否缺失两项数据和补齐两项数据这两个部分；
[0038] 自动探测订单是否缺失两项数据的具体执行步骤如下：
[0039] S11：司机在司机App上触发了服务完成动作；
[0040] S12：以订单号作为入参，调用订单详情服务接口，查询订单详情数据；
[0041] S13：从订单详情数据中获取订单状态码；
[0042] S14：判断订单状态码是否大于等于40，40状态码表示订单为服务结束待乘客支付状态；若否，则执行步骤S15；若是，则执行步骤S16；
[0043] S15：以订单号作为消息体。发送延迟5秒消费的MQ消息；
[0044] 发送MQ消息的目的是重新从头开始执行当前模块的各步骤；以便程序在2分钟内能够持续不断的检测订单上是否缺失两项数据的任何一项；
[0045] S16：从订单详情数据中获取订单服务完成时间；
[0046] S17：判断系统当前时间与订单服务完成时间的时间差是否在两分钟内；若是则继续；否则结束；若不在两分钟内就停止探测，不可让程序一直不断的持续探测下去，这样会耗费很多硬件计算资源；
[0047] S18：从订单详情数据中获取乘客实际下车点经纬度和下车点地址数据；
[0048] S19：判断实际下车点经纬度和下车点地址数据是否有其中任何一项为空；都非空则结束；否则继续；
[0049] S110：调用消息推送服务接口，向乘客端App推送需要乘客确认的消息；消息内容如下：
[0050] 您好，系统检测到司机已服务完成，请确认您是否已在订单约定的下车点下车？[0051] S111：结束。
[0052] 补齐两项数据的具体执行步骤如下：
[0053] S21：接收乘客端App上报的乘客确认请求；
[0054] S22：从请求中解析出订单号、实际下车点经纬度等核心请求参数数据；
[0055] S23：判断步骤S22中的订单号、下车点经纬度是否都非空；都非空则继续，否则结束；
[0056] S24：以订单号作为入参，调订单详情服务接口，查订单详情数据；
[0057] S25：判断订单详情是否为空；为空则结束；否则继续；
[0058] S26：以下车点经纬度作为参数，调用LBS服务接口根据经纬度反查出经纬度对应的中文地址信息；
[0059] S27：以订单号、下车点经纬度、中文地址作为参数，调用更新订单服务接口更新两项数据；
[0060] S28：结束。
[0061] 尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。
