CN110852545A - 统一服务管理方法和平台 - Google Patents

Abstract

本发明公开了统一服务管理方法和平台，涉及计算机技术领域。该方法的一具体实施方式包括统一服务管理平台中的应用程序从本地数据库获取与用户搜索请求对应的商品编码；调用统一服务管理平台中的平台商品库提供的商品接口，从平台商品库中查询与商品编码对应的基础信息；统一服务管理平台中的应用程序从本地数据库获取与基础信息对应的详情信息，将详情信息与基础信息组装后得到与用户搜索请求对应的商品信息并展示。该实施方式降低了能够通过统一服务管理平台提供多个应用场景，将交易体系统一到平台上，便于交易和财务管理，利于平台掌握交易数据。

Description

统一服务管理方法和平台

技术领域

本发明涉及计算机技术领域，尤其涉及一种统一服务管理方法和平台。

背景技术

SaaS(Software-as-a-Service，软件即服务)平台通过统一平台提供多种SaaS服务，服务符合平台规范，在帐号体系等方面同平台保持一致。目前已有许多服务商采用此类模式为企业提供服务，其中有些是把SaaS平台嵌入自己的其他产品中，如一些办公协同服务平台通过SaaS平台将第三方应用提供给客户。

现有的SaaS平台除了统一的帐号体系外，往往还向上层应用提供地理位置、文件传输、语音识别、消息通知等服务，供开发者灵活调用。但大多SaaS平台并不针对交易提供统一的服务，应用内产生的交易行为往往由应用自行对接第三方支付并进行独立的交易管理，即交易不统一于平台，而是由应用独立实现。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

(1)支付不统一：客户需要在不同的应用中使用不同的支付方式，使用和管理都会比较繁琐；

(2)交易数据管理困难：客户在平台中生成的订单分布在不同的应用中，不利于统一管理，甚至还会造成统计遗漏；

(3)资产管理困难：客户的资金账户会由于开通不同应用而增多，比如在应用A中有个预存款账户，在应用B中有个金融账期账户，在应用C中有个第三方支付账户等；甚至还会出现企业资金账户和个人资金账户同时存在的情况，如企业在应用A中有一笔预存款，对应为发放给其员工的可消费积分；

(4)资金压力大：客户可能需要在多个应用中分别充值，对资金占用较多；

(5)平台对交易数据无掌控：交易产生在应用内部，平台无从获取相关信息。

发明内容

有鉴于此，本发明实施例提供一种统一服务管理方法和平台，能够通过统一服务管理平台提供多个应用场景，将交易体系统一到平台上，便于交易和财务管理，利于平台掌握交易数据。

为实现上述目的，根据本发明实施例的一个方面，提供了一种统一服务管理方法。

根据本发明实施例的统一服务管理方法包括：

统一服务管理平台中的应用程序从本地数据库获取与用户搜索请求对应的商品编码；

调用统一服务管理平台中的平台商品库提供的商品接口，从平台商品库中查询与商品编码对应的基础信息；

统一服务管理平台中的应用程序从本地数据库获取与基础信息对应的详情信息，将详情信息与基础信息组装后得到与用户搜索请求对应的商品信息并展示。

可选地，基础信息包括以下至少之一：商品标识、商品名称、商品价格。

可选地，根据本发明实施例的统一服务管理方法还包括：统一服务管理平台中的应用程序响应于用户的下单请求，调用统一服务管理平台中的平台订单中心提供的下单接口；平台订单中心生成与下单请求对应的平台订单，将平台订单返回至统一服务管理平台中的应用程序。

可选地，根据本发明实施例的统一服务管理方法还包括：统一服务管理平台中的应用程序响应于用户的支付请求，调用统一服务管理平台中的平台订单中心提供的订单管理接口；平台订单中心确定与支付请求对应的收银台，在用户支付成功后更新平台订单的订单状态，并将更新后的订单状态返回至统一服务管理平台中的应用程序。

可选地，收银台包括：企业收银台和个人收银台；

平台订单中心确定与支付请求对应的收银台包括：若用户为企业用户，则与支付请求对应的收银台为企业收银台；若用户为个人用户，则与支付请求对应的收银台为个人收银台。

可选地，根据本发明实施例的统一服务管理方法还包括：用户通过统一服务管理平台的资产管理中心进行支付。

可选地，企业用户在所述资产管理中心的账户资产包括：账期额度和平台余额；个人用户在所述资产管理中心的账户资产包括：平台积分和平台余额；

其中，账期额度是指企业用户在资产管理中心的信用额度；平台余额是指企业用户或个人用户在资产管理中心充值后的现金余额；平台积分是指个人用户获得的积分。

根据本发明实施例的一个方面，提供了一种统一服务管理平台。

根据本发明实施例的统一服务管理平台包括：应用程序和平台商品库；

应用程序从本地数据库获取与用户搜索请求对应的商品编码；调用统一服务管理平台中的平台商品库提供的商品接口，从平台商品库中查询与商品编码对应的基础信息；从本地数据库获取与基础信息对应的详情信息，将详情信息与基础信息组装后得到与用户搜索请求对应的商品信息并展示。

可选地，基础信息包括以下至少之一：商品标识、商品名称、商品价格。

可选地，根据本发明实施例的统一服务管理平台还包括：平台订单中心；应用程序响应于用户的下单请求，调用平台订单中心提供的下单接口；平台订单中心生成与下单请求对应的平台订单，将所述平台订单返回至应用程序。

可选地，根据本发明实施例的统一服务管理平台还包括：收银台；应用程序响应于用户的支付请求，调用平台订单中心提供的订单管理接口；平台订单中心确定与支付请求对应的收银台，在用户支付成功后更新平台订单的订单状态，并将更新后的订单状态返回至应用程序。

可选地，收银台包括：企业收银台和个人收银台；

平台订单中心确定与支付请求对应的收银台包括：若用户为企业用户，则与支付请求对应的收银台为企业收银台；若用户为个人用户，则与支付请求对应的收银台为个人收银台。

可选地，根据本发明实施例的统一服务管理平台还包括：资产管理中心；用户通过资产管理中心进行支付。

可选地，企业用户在资产管理中心的账户资产包括：账期额度和平台余额；个人用户在资产管理中心的账户资产包括：平台积分和平台余额；

其中，账期额度是指企业用户在资产管理中心的信用额度；平台余额是指企业用户或个人用户在资产管理中心充值后的现金余额；平台积分是指个人用户获得的积分。

上述发明中的一个实施例具有如下优点或有益效果：平台商品库仅定义交易必须的商品的基本信息，不统一商品的详情信息等数据；商品的详情信息由各个应用自由定义并自行从其本地数据库获取，应用程序接收到用户搜索请求后，调用平台商品库提供的商品接口获取商品的基础信息、从平台商品库中查询商品的详情信息，然后将详情信息与基础信息组装后展示，如此能够使不同应用程序内的商品统一为平台商品，将商品体系统一到平台，实现对不同品类和属性的商品的兼容。各个应用程序调用平台订单中心提供的下单接口进行下单，能够将订单体系统一到平台；用户通过服务平台中的收银台进行支付，能够将支付通道统一到平台；通过资产管理中心管理用户资产，能够将资产体系统一到平台。本发明能够使服务管理平台的各个应用程序依赖服务管理平台实现交易，使服务管理平台对交易进行统一的支持和管理。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的统一服务管理方法的主要流程的示意图；

图2是根据本发明实施例的统一服务管理平台的架构示意图；

图3是根据本发明实施例中将商品体系统一到平台的主要流程的示意图；

图4是根据本发明实施例中订单体系的示意图；

图5是根据本发明实施例中将订单体系统一到平台的主要流程的示意图；

图6是根据本发明实施例中将支付通道统一到平台的主要流程的示意图；

图7a是企业资产管理体系的示意图，图7b是企业资产管理体系的示意图；

图8是根据本发明实施例的统一服务管理平台的主要组成的示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

交易体系通常包括商品体系、订单体系、支付通道、资产体系等。其中资产账户不同于账号体系，而是客户及其终端用户在SaaS应用中的资产。现有技术中，这些体系在不同应用程序中没有统一标准。图2是根据本发明实施例的统一服务管理平台的架构示意图，图中，商品代指商品体系，订单代指订单体系，支付代指支付体系，账户代指资产体系。

本发明中，每个应用程序对应一个本地数据库，本地数据库中存储对应应用程序中各个商品的相关数据，例如属性、品类、库存等。商品的品牌、产地、大小、颜色等都是商品属性。有些是通用的属性比如品牌；有些是品类属性，即特定品类的商品才具有的属性，比如电脑这个品类下的商品具有CPU型号、内存大小等属性。在向用户展示商品信息时，商品的详情信息(例如商品的属性、品类、库存等)不是交易必须的信息，这些信息由各个应用程序从其自身的本地数据库中获取。

由于不同品类的商品具有不同的属性，因此本发明中平台商品库仅定义商品的基本信息，不统一商品的详情信息等数据。基础信息的具体内容可以根据实际情况进行选择性设定，例如基础信息包括以下至少之一：商品标识、商品名称、商品价格等交易必须的信息。实际应用过程中，本领域技术人员也可以设置其他基本信息，例如平台需要统计其中各个应用的交易中商品的品牌属性时，也可以将品牌属性作为一项基础信息。平台商品库中不记录库存数据，应用内浏览有货商品及下单库存校验等仍由每个应用各自完成；若平台本身提供自营商品(服务)开放给应用程序进行销售，则需提供配套的库存数据。

本发明将分布在每个SaaS应用程序内部的交易体系集中到平台统一的交易体系中，应用程序依赖平台实现交易，平台对交易进行统一的支持和管理。

为实现上述目的，根据本发明实施例的一个方面，提供了一种统一服务管理方法。

图1是根据本发明实施例的统一服务管理方法的主要流程的示意图。如图1所示，根据本发明实施例的统一服务管理方法包括：步骤S101、步骤S102和步骤S103。

步骤S101、统一服务管理平台中的应用程序从本地数据库获取与用户搜索请求对应的商品编码。

商品编码是指提前存储在本地数据库中的能够唯一标识一个商品的编码。例如事先将应用程序中各个需要在平台中销售的商品的商品标识、商品名称、商品价格等交易必须的信息登记为一条记录，记为SKU(Stock Keeping Unit，即库存进出计量的单位)，然后将该SKU分别存储在本地数据库和平台商品库中。每个商品标识唯一标识一件商品，每个SKU唯一标识一条记录，SKU还可以标记每个商品所属的应用程序。

步骤S102、调用统一服务管理平台中的平台商品库提供的商品接口，从平台商品库中查询与商品编码对应的基础信息。

步骤S103、统一服务管理平台中的应用程序从本地数据库获取与基础信息对应的详情信息，将详情信息与基础信息组装后得到与用户搜索请求对应的商品信息并展示。

应用程序侧的数据(即应用程序对应的本地数据库中的数据)包括各种商品的详情数据，平台数据库中的数据包括商品的基础信息；当然，也可以将商品在平台商品库中登记的基础信息同步存储到应用程序侧，此时应用程序侧应该是全量数据，平台商品库侧数据只是其一个子集。两侧的数据通过商品编码来关联，平台商品库根据商品编码确定当前用户搜索请求属于哪个应用程序。如果不同应用程序中的商品相同，则会在平台商品库侧形成多条不同的数据，每条数据的商品编码不同。不同应用程序中商品的商品名称、商品价格可以相同也可以不同。

例如：平台商品库侧存储数据如下：ID001-应用A-商品名称001-100元；应用程序A侧存储数据如下：ID001–商品名称001-100元-品类1-属性1-属性2-属性3。其中，ID001为与用户搜索请求对应的商品编码。用户在应用程序A中浏览时，应用程序A根据用户的搜索行为，在本地数据库中检索出符合条件的所有商品编码，根据这一组商品编码通过平台商品库提供的商品接口查询查询各个商品编码对应的商品的基础信息，然后各个商品的基础信息与本地数据库中的详情信息组装后展示出来。

现有技术的SaaS平台体系中，不同品类商品在一套体系中难以实现兼容，因为品类不同，商品的属性也会不同，尤其是实物商品和虚拟商品(服务)之间的差异更大。而且，各个应用程序的商品数据遵循各自不同的标准存储于应用程序的本地数据库，无法统一。本发明中，平台商品库仅定义交易必须的商品的基本信息，不统一商品的详情信息等数据；商品的详情信息由各个应用自由定义并自行从其本地数据库获取，如此能够使不同应用程序内的商品统一为平台商品，将商品体系统一到平台，实现对不同品类和属性的商品的兼容。

图3是根据本发明实施例中将商品体系统一到平台的主要流程的示意图。如图3所示，用户在应用程序侧发起搜索请求，应用程序侧本地预处理，根据品类、标签等信息匹配平台SKU。然后调用平台商品库的相关接口，按照SKU进行查询。平台商品库根据SKU查询商品的基础信息，例如商品名称、价格等，并将查询到的基础信息返回至应用程序侧。应用程序进行组装，将基础信息与详情信息组装在一起，然后在应用程序内展示给用户。

可选地，根据本发明实施例的统一服务管理方法还包括：统一服务管理平台中的应用程序响应于用户的下单请求，调用统一服务管理平台中的平台订单中心提供的下单接口；平台订单中心生成与下单请求对应的平台订单，将平台订单返回至统一服务管理平台中的应用程序。任何应用内的交易均通过平台统一下单接口生成平台订单，平台基于统一的订单中心记录订单关联的SKU等信息，并记录下单的应用实例、用户类别等。本发明实施例中，各个应用程序调用平台订单中心提供的下单接口进行下单，能够将订单体系统一到平台

图5是根据本发明实施例中将订单体系统一到平台的主要流程的示意图。如图5所示，应用程序侧执行前序流程如商品展示、加购物车等，在应用程序侧用户触发下单，然后应用程序侧调用平台下单相关接口(即平台订单中心提供的下单接口)将下单数据发送至平台订单中心。平台订单中心侧根据下单数据生成平台订单，计算订单金额，然后将订单号返回至应用程序侧。在应用程序侧的后续流程中，用户触发确认、支付等操作。当用户支付成功后，平台订单中心同步订单状态，将同步后的订单状态(如已支付)返回至应用程序，应用程序进行内部处理(如更新本地数据库中商品的库存信息等)。

可选地，根据本发明实施例的统一服务管理方法还包括：统一服务管理平台中的应用程序响应于用户的支付请求，调用统一服务管理平台中的平台订单中心提供的订单管理接口；平台订单中心确定与支付请求对应的收银台，在用户支付成功后更新平台订单的订单状态，并将更新后的订单状态返回至统一服务管理平台中的应用程序。用户通过服务平台中的收银台进行支付，能够将支付通道统一到平台。

可选地，收银台包括：企业收银台和个人收银台；平台订单中心确定与支付请求对应的收银台包括：若用户为企业用户，则与支付请求对应的收银台为企业收银台；若用户为个人用户，则与支付请求对应的收银台为个人收银台。

企业收银台可以整合企业预存款、第三方资金账户、账期类金融工具、在线支付、公转等支付方式，用于企业的直接消费和间接消费(由终端用户通过积分等方式交易后由企业实际付款)。企业收银台可以支持特定情形下的自动支付，即平台根据约定方式直接扣除企业预存款项或账期额度等。个人收银台可以整合个人银联支付、微信支付、支付宝支付等支付方式，用于企业终端用户的直接消费。

当应用程序通过平台订单中心产生订单后，应用程序可以根据业务类别和付款人跳转到企业收银台或个人收银台，收银台就业务类别和付款人提供当前可用的支付方式并引导完成支付操作，支付信息反馈至应用和平台订单中心。

支付通道的收款方可以根据平台资质以及平台与应用程序的合作关系而定。若平台先收款后再与应用程序结算，则支付通道的收款方为平台；若应用程序直接收款、平台收取手续费，则存在两种方式：一是收款方为平台和应用程序，用分账付款的方式一次性完成交易，二是收款方为应用程序，交易后与平台结算手续费。

图6是根据本发明实施例中将支付通道统一到平台的主要流程的示意图。如图6所示，应用程序侧执行前序流程如下单并获取平台订单号，用户确认订单或者系统自动确认订单之后，若用户时企业用户则跳转到企业收银台、若用户时个人用户则跳转到个人收银台。用户在收银台进行，收银台确认支付结果之后更新订单状态，然后将更新后的订单状态(例如支付结果)同步至应用程序，应用程序在执行后续流程(例如进行订单生产和发货等)。

可选地，根据本发明实施例的统一服务管理方法还包括：用户通过统一服务管理平台的资产管理中心进行支付。通过资产管理中心管理用户资产，能够将资产体系统一到平台。

可选地，企业用户在所述资产管理中心的账户资产包括：账期额度和平台余额；个人用户在所述资产管理中心的账户资产包括：平台积分和平台余额；其中，账期额度是指企业用户在资产管理中心的信用额度；平台余额是指企业用户或个人用户在资产管理中心充值后的现金余额；平台积分是指个人用户获得的积分。

图7a是企业资产管理体系的示意图。如图7a所示，企业资产体系即平台为企业用户设立的资金体系，其资产在各应用程序中通用，用户无须在不同应用中分别建立账户并存入资金。企业资产体系可以包括平台为企业开放的账期额度(可以先消费再按账期还款)和平台余额(需要企业充值)。

图7b是企业资产管理体系的示意图。如图7b所示，个人资产体系即积分等可消费资产，个人用户可以用该资产在相关应用程序内进行交易支付；个人虚拟资产的来源可以是个人自行充值或由企业为其分配(福利积分发放/消费积分奖励等)的，如果是后者，则其费用由发放企业承担并通过其他方式完成支付。个人资产体系可以包括平台余额(需个人充值)和企业发放给个人的积分(消费后由企业买单)。

图4是根据本发明实施例中订单体系的示意图。如图4所示，

平台订单在平台订单中心完成支付后会通过MQ((Message Queue,消息队列)等机制同步给应用程序，后者负责订单的后续生产工作，对于平台自营的商品(服务)则下发给相应系统进行生产。平台订单中心通过订单管理接口向用户提供订单管理根据，其中，企业用户对应企业订单管理工具，用于企业用户管理企业收银台(例如充值、提现、查询等)，个人用户对应个人订单管理工具，用于个人用户管理企业收银台(例如充值、提现、查询等)。

根据本发明实施例的一个方面，提供了一种统一服务管理平台。

图8是根据本发明实施例的统一服务管理平台的主要组成的示意图。如图8所示，根据本发明实施例的统一服务管理平台800包括：应用程序801和平台商品库802；

应用程序从本地数据库获取与用户搜索请求对应的商品编码；调用统一服务管理平台中的平台商品库提供的商品接口，从平台商品库中查询与商品编码对应的基础信息；从本地数据库获取与基础信息对应的详情信息，将详情信息与基础信息组装后得到与用户搜索请求对应的商品信息并展示。

可选地，基础信息包括以下至少之一：商品标识、商品名称、商品价格。

可选地，根据本发明实施例的统一服务管理平台还包括：平台订单中心(图中未示出)；应用程序响应于用户的下单请求，调用平台订单中心提供的下单接口；平台订单中心生成与下单请求对应的平台订单，将所述平台订单返回至应用程序。

可选地，根据本发明实施例的统一服务管理平台还包括：收银台(图中未示出)；应用程序响应于用户的支付请求，调用平台订单中心提供的订单管理接口；平台订单中心确定与支付请求对应的收银台，在用户支付成功后更新平台订单的订单状态，并将更新后的订单状态返回至应用程序。

可选地，收银台包括：企业收银台和个人收银台；

平台订单中心确定与支付请求对应的收银台包括：若用户为企业用户，则与支付请求对应的收银台为企业收银台；若用户为个人用户，则与支付请求对应的收银台为个人收银台。

可选地，根据本发明实施例的统一服务管理平台还包括：资产管理中心(图中未示出)；用户通过资产管理中心进行支付。

可选地，企业用户在资产管理中心的账户资产包括：账期额度和平台余额；个人用户在资产管理中心的账户资产包括：平台积分和平台余额；

其中，账期额度是指企业用户在资产管理中心的信用额度；平台余额是指企业用户或个人用户在资产管理中心充值后的现金余额；平台积分是指个人用户获得的积分。

附图中的流程图和框图，图示了按照本发明各种实施例的平台、方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

根据本发明实施例的技术方案，平台商品库仅定义交易必须的商品的基本信息，不统一商品的详情信息等数据；商品的详情信息由各个应用自由定义并自行从其本地数据库获取，如此能够使不同应用程序内的商品统一为平台商品，将商品体系统一到平台，实现对不同品类和属性的商品的兼容。各个应用程序调用平台订单中心提供的下单接口进行下单，能够将订单体系统一到平台；用户通过服务平台中的收银台进行支付，能够将支付通道统一到平台；通过资产管理中心管理用户资产，能够将资产体系统一到平台。本发明能够使服务管理平台的各个应用程序依赖服务管理平台实现交易，使服务管理平台对交易进行统一的支持和管理。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (14)

1.一种统一服务管理方法，其特征在于，包括：

统一服务管理平台中的应用程序从本地数据库获取与用户搜索请求对应的商品编码；

调用统一服务管理平台中的平台商品库提供的商品接口，从所述平台商品库中查询与所述商品编码对应的基础信息；

统一服务管理平台中的应用程序从本地数据库获取与所述基础信息对应的详情信息，将所述详情信息与所述基础信息组装后得到与所述用户搜索请求对应的商品信息并展示。

2.如权利要求1所述的方法，其特征在于，所述基础信息包括以下至少之一：商品标识、商品名称、商品价格。

3.如权利要求2所述的方法，其特征在于，还包括：统一服务管理平台中的应用程序响应于用户的下单请求，调用统一服务管理平台中的平台订单中心提供的下单接口；所述平台订单中心生成与所述下单请求对应的平台订单，将所述平台订单返回至统一服务管理平台中的应用程序。

4.如权利要求3所述的方法，其特征在于，还包括：统一服务管理平台中的应用程序响应于用户的支付请求，调用统一服务管理平台中的平台订单中心提供的订单管理接口；所述平台订单中心确定与所述支付请求对应的收银台，在用户支付成功后更新所述平台订单的订单状态，并将更新后的订单状态返回至统一服务管理平台中的应用程序。

5.如权利要求4所述的方法，其特征在于，所述收银台包括：企业收银台和个人收银台；

所述平台订单中心确定与所述支付请求对应的收银台包括：若所述用户为企业用户，则与所述支付请求对应的收银台为企业收银台；若所述用户为个人用户，则与所述支付请求对应的收银台为个人收银台。

6.如权利要求4所述的方法，其特征在于，还包括：用户通过统一服务管理平台的资产管理中心进行支付。

7.如权利要求6所述的方法，其特征在于，企业用户在所述资产管理中心的账户资产包括：账期额度和平台余额；个人用户在所述资产管理中心的账户资产包括：平台积分和平台余额；

其中，账期额度是指企业用户在所述资产管理中心的信用额度；平台余额是指企业用户或个人用户在所述资产管理中心充值后的现金余额；平台积分是指个人用户获得的积分。

8.一种统一服务管理平台，其特征在于，包括：应用程序和平台商品库；

应用程序从本地数据库获取与用户搜索请求对应的商品编码；调用统一服务管理平台中的平台商品库提供的商品接口，从所述平台商品库中查询与所述商品编码对应的基础信息；从本地数据库获取与所述基础信息对应的详情信息，将所述详情信息与所述基础信息组装后得到与所述用户搜索请求对应的商品信息并展示。

9.如权利要求8所述的平台，其特征在于，所述基础信息包括以下至少之一：商品标识、商品名称、商品价格。

10.如权利要求9所述的平台，其特征在于，还包括：平台订单中心；应用程序响应于用户的下单请求，调用平台订单中心提供的下单接口；所述平台订单中心生成与所述下单请求对应的平台订单，将所述平台订单返回至应用程序。

11.如权利要求10所述的平台，其特征在于，还包括：收银台；应用程序响应于用户的支付请求，调用平台订单中心提供的订单管理接口；所述平台订单中心确定与所述支付请求对应的收银台，在用户支付成功后更新所述平台订单的订单状态，并将更新后的订单状态返回至应用程序。

12.如权利要求11所述的平台，其特征在于，所述收银台包括：企业收银台和个人收银台；

所述平台订单中心确定与所述支付请求对应的收银台包括：若所述用户为企业用户，则与所述支付请求对应的收银台为企业收银台；若所述用户为个人用户，则与所述支付请求对应的收银台为个人收银台。

13.如权利要求11所述的平台，其特征在于，还包括：资产管理中心；用户通过资产管理中心进行支付。

14.如权利要求13所述的平台，其特征在于，企业用户在所述资产管理中心的账户资产包括：账期额度和平台余额；个人用户在所述资产管理中心的账户资产包括：平台积分和平台余额；

其中，账期额度是指企业用户在所述资产管理中心的信用额度；平台余额是指企业用户或个人用户在所述资产管理中心充值后的现金余额；平台积分是指个人用户获得的积分。

Images