CN112418968A - 订单数据处理方法 - Google Patents

订单数据处理方法 Download PDF

Info

Publication number
CN112418968A
CN112418968A CN202010182574.0A CN202010182574A CN112418968A CN 112418968 A CN112418968 A CN 112418968A CN 202010182574 A CN202010182574 A CN 202010182574A CN 112418968 A CN112418968 A CN 112418968A
Authority
CN
China
Prior art keywords
order
commodity
sold
information
payment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202010182574.0A
Other languages
English (en)
Inventor
朱婷婷
任雪逸
侯昱伸
徐雪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Bilibili Technology Co Ltd
Original Assignee
Shanghai Bilibili Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Bilibili Technology Co Ltd filed Critical Shanghai Bilibili Technology Co Ltd
Priority to CN202010182574.0A priority Critical patent/CN112418968A/zh
Publication of CN112418968A publication Critical patent/CN112418968A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明公开了一种订单数据处理方法及系统，该方法包括：获取用户下单时的商品信息和优惠信息；根据所述商品信息创建对应的订单，并确定所述订单的订单类型；当所述订单为混合订单且所述订单中不包括现货商品时，获取每种预售商品尾款订单，其中每种预售商品尾款订单包括第一下单数量和待补尾款金额；根据所述优惠信息和每种预售商品尾款订单进行计算，得到付款金额，以使所述用户根据所述付款金额进行付款。本发明能够极大地提高用户的购物体验，增强系统订单数据处理的灵活性和兼容性，同时极大地促进了平台低单价商品和跨品类商品的销售量，降低供应链成本。

Description

订单数据处理方法
技术领域
本发明涉及电商技术领域，具体涉及一种订单数据处理方法。
背景技术
目前电商购买场景中，二次元IP衍生品预售周期远远高于普通电商平台的周期。其中，70％二次元IP衍生品的等待期在6个月以上，加之平台新品预售比例超过50％，导致在较长的周期内，用户可能购买多个预售商品，购买数量越多，同时期开补款的商品比例也就越大。随着低货值商品质量的提升，销售也在逐步提升，单个商品的尾款金额往往都低于100元，在现有的补尾款付款时，仅能单个商品逐个付款的付款模式下，单个商品的付款金额很难满足平台包邮的门槛，也就更加无法满足使用优惠券的要求。这种现有的单个商品逐个付款的付款模式，极大地降低了用户体验。
发明内容
本发明的目的在于提供一种订单数据处理方法、系统、计算机设备及可读存储介质，用于解决现有技术中单个商品逐个付款的付款模式中，用户体验提的缺陷。
根据本发明的一个方面，提供了一种订单数据处理方法，该方法包括如下步骤：
获取用户下单时的商品信息和优惠信息；
根据所述商品信息创建对应的订单，并确定所述订单的订单类型，其中，所述订单类型包括混合订单和常规订单；
当所述订单为混合订单且所述订单中不包括现货商品时，获取每种预售商品尾款订单，其中每种预售商品尾款订单包括第一下单数量和待补尾款金额；
根据所述优惠信息和每种预售商品尾款订单进行计算，得到付款金额，以使所述用户根据所述付款金额进行付款。
可选地，所述根据所述商品信息确定所述订单的类型，包括：
若所述商品信息中包括多种预售商品或至少一种预售商品和至少一种现货商品的组合时，则确定所述订单为所述混合订单；
若所述商品信息中仅仅包括一种预售商品或至少一种现货商品时，则确定所述订单为常规订单。
可选地，当所述订单为所述混合订单且不包括所述现货商品时，所述根据所述商品信息创建对应的订单，包括：
根据所述商品信息判断每种预售商品是否处于补尾款状态；
当每种预售商品均处于补尾款状态时，从数据库获取每种预售商品对应的第一实库库存；
当所述第一实库库存均大于或等于所述第一下单数量时，创建第一父订单，并建立所述第一父订单与每种预售商品尾款订单之间的第一关联关系。
可选地，当所述订单为所述混合订单且所述订单中包括所述现货商品时，所述根据所述商品信息创建对应的订单，包括：
根据所述商品信息判断所述预售商品是否处于补尾款状态；
当所述预售商品处于补尾款状态时，从数据库获取所述预售商品的第一实库库存、所述现货商品的可售库存和第二实库库存，其中，所述现货商品信息包括现货商品种类和第二下单数量；
当所述第一实库库存大于或等于所述第一下单数量且所述可售库存和第二实库库存均大于所述第二下单数量时，根据所述现货商品信息创建第二父订单，并建立所述第二父订单与所述预售商品尾款订单之间的第二关联关系。
可选地，所述根据所述商品信息判断所述预售商品是否处于补尾款状态，包括：
获取所述预售商品的出到货时间并保存；
根据所述出到货时间开启对应的补尾款操作以及补尾款截止期限；
当所述补尾款操作已开启且处于所述补尾款操作截止期限内时，则判断所述预售商品处于所述补尾款状态。
可选地，所述方法还包括：
获取每种预售商品尾款订单和每种现货商品的售价金额；
根据所述优惠信息、每种预售商品尾款订单、所述第二下单数量和所述售价金额进行计算，得到所述付款金额，以使所述用户根据所述付款金额进行付款。
可选地，所述方法还包括：
当所述用户付款完成时，删除所述第一父订单和每种预售商品尾款订单或所述第二父订单和所述预售商品尾款订单，并生成支付订单并显示。
可选地，所述方法还包括：
当所述第二父订单创建成功时，获取有效付款时间，并判断是否检测到取消付款操作；
当超过所述有效付款时间或在所述有效付款时间内检测到取消付款操作时，判断所述补尾款截止期限是否到期；
若所述补尾款截止期限未到期，则删除所述第二父订单和所述第二关联关系；
若所述补尾款截止期限到期时，则删除所述第二父订单、所述预售商品尾款订单和所述第二关联关系。
为了实现上述目的，本发明还提供一种订单数据处理系统，该系统具体包括以下组成部分：
获取模块，用于获取用户下单时的商品信息、优惠券信息和包邮信息；
处理模块，用于根据所述商品信息创建对应的订单并确定所述订单的订单类型，其中，所述订单类型包括混合订单和常规订单；
所述获取模块，还用于当所述订单为混合订单且所述订单中不包括现货商品时，获取每种预售商品尾款订单，其中每种预售商品尾款订单包括第一下单数量和待补尾款金额；
计算模块，用于根据所述优惠券信息、所述包邮信息和每种预售商品尾款订单进行计算，得到付款金额，以使所述用户根据所述付款金额进行付款。
为了实现上述目的，本发明还提供一种计算机设备，该计算机设备具体包括：存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述介绍的订单数据处理方法的步骤。
为了实现上述目的，本发明还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述介绍的订单数据处理方法的步骤。
本发明提供的订单数据处理方法、系统、计算机设备及可读存储介质，通过判断用户的订单是否为混合订单，当为混合订单且所述订单中不包括现货商品时，将所有预售商品的尾款订单中的待付尾款金额一起计算，并结合优惠信息计算优惠价格，得到付款金额，以使所述用户根据所述付款金额进行付款。本发明通过将多个尾款订单一起结算，使得用户的付款金额满足平台优惠的要求，极大地提高了用户的购物体验，增强了系统订单数据处理的灵活性和兼容性，同时促进了平台的低单价商品和跨品类商品的销售量，极大地降低了供应链成本。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1为本公开实施例提供的订单数据处理方法的一种可选的应用环境图；
图2为本公开实施例提供的订单数据处理方法的一种可选的流程示意图；
图3为所述图2中步骤S102的一种可选的具体流程示意图；
图4为所述图2中步骤S102的另一种可选的具体流程示意图；
图5为混合订单中不包含现货商品情况时的订单关联示意图；
图6为所述图2中步骤S102的另一种可选的具体流程示意图；
图7为所述图4或图6中步骤S300的一种可选的具体流程示意图；
图8为本公开实施例提供的订单数据处理方法的另一种可选的流程示意图；
图9为本公开实施例提供的订单数据处理方法的另一种可选的流程示意图；
图10为本公开实施例提供的订单数据处理方法的另一种可选的流程示意图；
图11为本公开实施例提供的订单数据处理系统的一种可选的程序模块示意图；
图12为本公开实施例提供的计算机设备的一种可选的硬件架构示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
下面结合附图对本发明提供的订单数据处理方法进行说明。
图1为本发明订单数据处理方法的一种可选的应用环境图。图1中终端设备和服务器通过因特网进行通信连接。当用户通过在终端设备上对自己需要的商品执行下单操作时，终端设备接收所述用户的下单请求，并通过与服务器的通信连接，生成付款金额以使所述用户完成付款。
图2为本发明订单数据处理方法的一种可选的流程示意图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定，下面以计算机设备为执行主体进行示例性描述。所述计算机设备可以包括诸如手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(Personal Digital Assistant，PDA)、便携式媒体播放器(Portable Media Player，PMP)、导航装置、可穿戴设备、智能手环、计步器等移动终端，以及诸如数字TV、台式计算机等固定终端。
如图2所示，该方法具体包括以下步骤：
步骤S100：获取用户下单时的商品信息和优惠信息。其中，所述商品信息可以包括：一种或多种预售商品信息以及至少一种预售商品信息和现货商品信息的组合。所述优惠信息可以包括优惠券信息和/或包邮信息等。其中，所述优惠券信息预设有对应的付款计算规则，例如：全场满300减50，3件75折。所述包邮信息预设有对应的邮费减免计算规则，例如：满200包邮。
S102：根据所述商品信息创建对应的订单并确定所述订单的订单类型，其中，所述订单类型包括混合订单和常规订单。
在示例性的实施例中，如图3所示，所述步骤S102可以包括步骤S200和步骤S202。
步骤S200：若所述商品信息中包括多种预售商品或至少一种预售商品和至少一种现货商品的组合时，则确定所述订单为所述混合订单。
步骤S202：若所述商品信息中仅仅包括一种预售商品或至少一种现货商品时，则确定所述订单为常规订单。
具体地，用户下单中商品信息可以包括：一种预售商品(1件或多件)、多种预售商品、一种或多种预售商品+一种或多种现货商品、一种或多种现货商品。当所述商品信息中包括一种预售商品(1件或多件)或一种或多种现货商品时，则判断创建的订单为常规订单。当所述商品信息中包括预售商品+预售商品或者预售商品+现货商品时，则判断创建的订单为混合订单。例如：预售商品电脑+预售商品显示器为混合订单，预售商品电脑+现货商品显示器为混合订单，预售商品电脑(数量不限)为常规订单，现货商品显示器为常规订单。上述步骤能够准确的判断订单是常规订单还是混合订单，为后续的付款金额的计算和优惠信息的使用提供保障。
在示例性的实施例中，如图4所示，当所述订单为混合订单且不包括现货商品时，所述步骤S102还可以包括步骤S300～S304。
步骤S300：根据所述商品信息判断每种预售商品是否处于补尾款状态。
步骤S302：当每种预售商品均处于补尾款状态时，从数据库获取每种预售商品对应的第一实库库存。
步骤S304：当所述第一实库库存均大于或等于所述第一下单数量时，创建第一父订单，并建立所述第一父订单与每种预售商品尾款订单之间的第一关联关系。
具体地，当所述商品信息中仅仅包含多种预售商品(也即不包含现货商品)时，首先需要判断每种预售商品是否均处于补尾款状态，并分别判断对应预售商品的实库库存是否满足对应的下单数量。只有当每种预售商品均处于补尾款状态且每种预售商品的实库库存均大于或等于对应的下单数量时，才创建第一父订单，将所述第一父订单和每种预售商品尾款订单(也即子订单)进行关联，进而实现所述订单中的所有预售商品一起付款。示例性地，若预售商品1的下单数量为1，预售商品2的下单数量也为1，且判断出预售商品1和预售商品2均处于补尾款状态，并获取到预售商品1的实库库存为50，预售商品2的实库库存为100，判断出预售商品1和预售商品2的实库库存均大于对应的下单数量，则创建第一父订单，并建立第一父订单与预售商品1尾款订单和预售商品2尾款订单的关联关系。
需要说明的是，由于预售商品尾款订单在定金阶段已经判断过所述预售商品的可售库存是否大于或等于下单数量，且所述下单数量已被记录到所述预售商品的销量中，故在付尾款阶段时，预售商品仅仅需要判断所述预售商品的实库库存是否大于或等于下单数量即可。
在本实施例中，当所述第一父订单创建后，还在对应第一实库库存中锁定对应预售商品的下单数量，并从对应第一实库库存减去对应的第一下单数量，同时锁定所述优惠券信息和包邮信息，以便用户支付时并在达到使用优惠券和包邮的条件下，根据所述优惠券信息和所述包邮信息进行计算。所述第一父订单可以包括：订单号、优惠券信息、包邮信息和银行支付信息。需要说明的是，由于预售商品订单均以子订单的形式展示，故所述第一父订单中并未显示商品信息。所述第一父订单用于将各个预售商品尾款订单关联付款。上述步骤，通过虚拟组合订单的模式，将各个预售商品尾款订单作为子订单进行关联，实现多种预售商品同步下单，进而为用户支付提供便利。
请参阅图5，图5为混合订单中不包含现货商品情况时的订单关联示意图。图5中，父订单包括订单号，子订单1中包括预售商品1的定金和待付尾款金额，子订单2中包括预售商品2的定金和待付尾款金额...子订单m中包括预售商品m的定金和待付尾款金额。通过将所述父订单、所述子订单1、所述子订单2...所述子订单m打上对应的关联标识，建立所述父订单、所述子订单1、所述子订单2...所述子订单m之间的关联。需要说明的是，优惠券信息、包邮信息和银行支付信息在图5中未示出，图5仅以父订单中显示订单号为例进行说明。
在示例性的实施例中，如图6所示，当所述订单为混合订单且所述订单中包括所述现货商品时，所述步骤S102还可以包括步骤S300、步骤S302’以及步骤S304’。
步骤S300：根据所述商品信息判断所述预售商品是否处于补尾款状态。
步骤S302’：当所述预售商品处于补尾款状态时，从数据库获取所述预售商品的第一实库库存、所述现货商品的可售库存和第二实库库存，其中，所述现货商品信息包括现货商品种类和第二下单数量。
步骤S304’：当所述第一实库库存大于或等于所述第一下单数量且所述可售库存和第二实库库存均大于所述第二下单数量时，根据所述现货商品信息创建第二父订单，并建立所述第二父订单与所述预售商品尾款订单之间的第二关联关系。
具体地，当所述商品信息中既包含预售商品又包含现货商品时，同样需要判断每种预售商品是否均处于补尾款状态，然后分别判断对应预售商品的实库库存是否满足对应的下单数量，同时判断每种现货商品的可售库存和第二实库库存均大于对应的第二下单数量。只有当每种对应预售商品的实库库存均大于或等于对应的下单数量，且现货商品的可售库存和第二实库库存大于或等于对应的下单数量，才建立第二父订单，并将所述第二父订单和所述预售商品尾款订单(也即子订单)进行关联，进而实现所述订单中的所有预售商品和现货商品一起付款。示例性地，若预售商品1的下单数量为2，现货商品1的下单数量为1，且判断出预售商品1处于补尾款阶段，并获取到预售商品1的实库库存为50，现货商品1的可售库存为50，实库库存为60，经过判断，判断出预售商品1的实库库存大于预售商品1的下单数量，现货商品的可售库存和实库库存均待遇现货商品1的下单数量，则创建第二父订单，并建立第二父订单与预售商品1尾款订单的关联关系。
在本实施例中，当所述第二父订单创建后，预售商品的实库库存同上述实施例中预售商品实库库存的锁定方式，在此不再赘述。还在对应现货商品的可售库存和实库库存中锁定对应的第二下单数量，并从所述对应的可售库存和实库库存中减去所述第二下单数量。除此之外，还同时锁定所述优惠券信息和包邮信息，以便用户支付时并在达到使用优惠券和包邮的条件下，根据所述优惠券信息和所述包邮信息进行计算。所述第二父订单中至少包括现货商品信息和订单号，当然，还可以包括优惠券信息、包邮信息和银行支付信息。通过虚拟组合订单的模式，将现货商品订单作为父订单，并将预售商品的子订单尾款订单作为子订单进行订单的关联，实现预售商品与现货商品同步下单，进而为用户支付提供便利。
需要说明的是，所述第二父订单与预售商品尾款订单的关联关系图与图5的区别在于，所述第二父订单包括现货商品信息，故在此不作赘述，且不作另图显示。
在示例性的实施例中，如图7所示，所述步骤S300还可以包括步骤S400～S404。
步骤S400：获取所述预售商品的出到货时间并保存。
步骤S402：根据所述出到货时间开启对应的补尾款操作以及补尾款截止期限。
步骤S404：当所述补尾款操作已开启且处于所述补尾款操作截止期限内时，则判断所述预售商品处于所述补尾款状态。
具体地，在实际的电商销售场景中，当预售商品出货后即可开启补尾款操作，并根据预售商品的到货时间设置补尾款的截止期限，在补尾款操作开启后并在截止期限到来之前，用户可对所述预售商品进行补款。用户可进行补款操作的预售商品的状态称为补尾款状态。上述步骤能够准确地判断出预售商品是否处于补尾款状态，以确保父订单的成功创建。
步骤S104：当所述订单为混合订单且所述订单中不包括现货商品时，获取每种预售商品尾款订单，其中每种预售商品尾款订单包括第一下单数量和待补尾款金额。
具体地，通过获取预售商品尾款订单，可获取每种预售商品的待补尾款金额，结合每种预售商品的对应的第一下单数量，进而可计算出所有预售商品的总待补尾款金额。
步骤S106：根据所述优惠信息和每种预售商品尾款订单进行计算，得到付款金额，以使所述用户根据所述付款金额进行付款。
具体地，根据每种预售商品尾款订单计算所有预售商品的总待补尾款金额，并根据所述总待补尾款金额、所述优惠信息计算出总的付款金额。通过将多个尾款订单一起结算，使得用户的付款金额满足平台优惠的要求，低货值的商品通过凑单不仅可以容易达到优惠券使用门槛，同时还容易达到包邮门槛，大大提高了用户的购物体验，促进了用户的单次消费(也即客单价)，增强了系统订单数据处理的灵活性和兼容性，同时促进了平台低单价商品和跨品类商品的销售量，极大地降低了供应链成本。
在示例性的实施例中，如图8所示，所述方法还可以包括步骤S500和步骤S502。
步骤S500：获取每种预售商品尾款订单和每种现货商品的售价金额。
步骤S502：根据所述优惠信息、每种预售商品尾款订单、所述第二下单数量和所述售价金额进行计算，得到所述付款金额，以使所述用户根据所述付款金额进行付款。
具体地，当所述订单中存在预售商品和和现货商品时，需要同时获取每种预售商品尾款订单和每种现货商品的售价金额，并结合每种现货商品对应的第二下单数量计算出所述订单的总金额。然后，将根据所述总金额、所述优惠信息计算出总的付款金额。通过本方法，在提高用户购物体验的同时，极大地降低了仓储操作成本，极大地促进了跨品类商品的销售量。
在示例性的实施例中，如图9所示，所述方法还可以包括步骤S600。
步骤S600：当所述用户付款完成时，删除所述第一父订单和每种预售商品尾款订单或所述第二父订单和所述预售商品尾款订单，并生成支付订单并显示。
具体地，混合订单中无论是否存在现货商品，在检测到用户付款完成时，均需删除对应的父订单，所有预售商品对应的尾款订单(也即子订单)，并生成对应的支付订单。需要说明的是，所述支付订单可以模块化显示现货商品支付信息和预售商品支付信息，其中，所述预售商品支付信息包括所述预售商品种类、所述第一下单数量、定金和补尾款金额，所述现货商品支付信息包括支付信息。由于支付订单使用了优惠券，故，所述支付订单可根据所述预售商品的补尾款金额和现货商品的售价金额的比例，进行对应的优惠减免，并显示减免后的金额。本方法为用户查看各个商品付款信息提供方便，并且极大地提升了用户的购物体验。
在示例性的实施例中，如图10所示，当所述混合订单中不包含有现货商品时，所述方法还可以包括步骤S700～S706。
步骤S700：当所述第二父订单创建成功时，获取有效付款时间，并判断是否检测到取消付款操作。
步骤S702：当超过所述有效付款时间或在所述有效付款时间内检测到取消付款操作时，判断所述补尾款截止期限是否到期，当所述补尾款截止期限到期时，则执行步骤S704，否则执行步骤S706。
具体地，若超过所述有效付款时间或在所述有效时间内检测到取消付款操作，则代表用户需要取消所述混合订单。当用户需要取消所述混合订单时，通过补尾款截止期限的判断，在用户仅仅需要取消现货商品的购买的情况下，不会因为混合订单的取消而影响用户已付定金的预售商品订单，为用户的购买提供极大的便利和购物体验，同时保障用户的合法权益。
步骤S704：删除所述第二父订单和所述第二关联关系。
步骤S706：删除所述第二父订单、所述预售商品尾款订单和所述第二关联关系。
具体地，若所有的预售商品的补尾款截止期限均未到期，则仅仅删除第一父订单和第一父订单与所有子订单之间的关联关系。若其中一个预售商品的补尾款截止期限到期，则删除第一父订单、第一父订单和所有子订单之间的关联关系以及到期的预售商品尾款订单。在所述第一父订单删除的同时，还根据对应预售商品的第一下单数量将对应的第一实库库存加上所述第一下单数量(也即将所述预售商品归还对应的实库库存)，同时释放所述优惠券信息和包邮信息。
在示例性的实施例中，当混合订单中存在现货商品时，在删除第二父订单和第二父订单与所有子订单之间的关联关系的同时，还需根据对应现货商品的第二下单数量将对应的可售库存和第二实库库存加上所述第二下单数量(也即将所述现货商品归还对应的可售库存和实库库存)。本方法通过释放库存、优惠券信息和包邮信息的方式，在保障用户购物体验的同时，极大地降低了计算机内存占有率，提高计算机的处理性能。
基于上述实施例中提供的订单数据处理方法，本实施例中提供一种订单数据处理系统，所述订单数据处理系统可以应用于计算机设备。具体地，图11示出了该订单数据处理系统的可选的结构框图，该订单数据处理系统被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本发明。本发明所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，比程序本身更适合描述订单数据处理系统在存储介质中的执行过程，以下描述将具体介绍本实施例各程序模块的功能。
如图11所示，订单数据处理系统具体包括以下组成部分：
获取模块201，用于获取用户下单时的商品信息和优惠信息。其中，所述商品信息可以包括：一种或多种预售商品信息以及至少一种预售商品信息和现货商品信息的组合。所述优惠信息可以包括优惠券信息和/或包邮信息等。其中，所述优惠券信息预设有对应的付款计算规则，例如：全场满300减50，3件75折。所述包邮信息预设有对应的邮费减免计算规则，例如：满200包邮。
处理模块202，用于根据所述商品信息创建对应的订单并确定所述订单的订单类型，其中，所述订单类型包括混合订单和常规订单。
在示例性的实施例中，所述处理模块202还具体用于：
若所述商品信息中包括多种预售商品或至少一种预售商品和至少一种现货商品的组合时，则确定所述订单为所述混合订单；若所述商品信息中仅仅包括一种预售商品或至少一种现货商品时，则确定所述订单为常规订单。
具体地，用户下单中商品信息可以包括：一种预售商品(1件或多件)、多种预售商品、一种或多种预售商品+一种或多种现货商品、一种或多种现货商品。当所述商品信息中包括一种预售商品(1件或多件)或一种或多种现货商品时，则所述处理模块202确定创建的订单为常规订单。当所述商品信息中包括预售商品+预售商品或者预售商品+现货商品时，则所述处理模块202确定创建的订单为混合订单。例如：预售商品电脑+预售商品显示器为混合订单，预售商品电脑+现货商品显示器为混合订单，预售商品电脑(数量不限)为常规订单，现货商品显示器为常规订单。上述步骤能够准确的判断订单是常规订单还是混合订单，为后续的付款金额的计算和优惠信息的使用提供保障。
在示例性的实施例中，当所述订单为混合订单且不包括现货商品时，所述处理模块202还包括判断单元、获取单元和创建单元。
所述判断单元，用于根据所述商品信息判断每种预售商品是否处于补尾款状态。
所述获取单元，用于当每种预售商品均处于补尾款状态时，从数据库获取每种预售商品对应的第一实库库存。
所述创建单元，用于当所述第一实库库存均大于或等于所述第一下单数量时，创建第一父订单，并建立所述第一父订单与每种预售商品尾款订单之间的第一关联关系。
具体地，当所述商品信息中仅仅包含多种预售商品(也即不包含现货商品)时，首先所述判断单元需要判断每种预售商品是否均处于补尾款状态，并分别判断对应预售商品的实库库存是否满足对应的下单数量。只有当每种预售商品均处于补尾款状态且每种预售商品的实库库存均大于或等于对应的下单数量时，所述创建单元才创建第一父订单，将所述第一父订单和每种预售商品尾款订单(也即子订单)进行关联，进而实现所述订单中的所有预售商品一起付款。示例性地，若预售商品1的下单数量为1，预售商品2的下单数量也为1，且所述判断单元判断出预售商品1和预售商品2均处于补尾款状态，所述获取单元获取到预售商品1的实库库存为50，预售商品2的实库库存为100，所述判断单元判断出预售商品1和预售商品2的实库库存均大于对应的下单数量，则所述创建单元创建第一父订单，并建立第一父订单与预售商品1尾款订单和预售商品2尾款订单的关联关系。
需要说明的是，由于预售商品尾款订单在定金阶段已经判断过所述预售商品的可售库存是否大于或等于下单数量，且所述下单数量已被记录到所述预售商品的销量中，故在付尾款阶段时，预售商品仅仅需要判断所述预售商品的实库库存是否大于或等于下单数量即可。
在本实施例中，当所述第一父订单创建后，还在对应第一实库库存中锁定对应预售商品的下单数量，并从对应第一实库库存减去对应的第一下单数量，同时锁定所述优惠券信息和包邮信息，以便用户支付时并在达到使用优惠券和包邮的条件下，根据所述优惠券信息和所述包邮信息进行计算。所述第一父订单可以包括：订单号、优惠券信息、包邮信息和银行支付信息。需要说明的是，由于预售商品订单均以子订单的形式展示，故所述第一父订单中并未显示商品信息。所述第一父订单用于将各个预售商品尾款订单关联付款。上述步骤，通过虚拟组合订单的模式，将各个预售商品尾款订单作为子订单进行关联，实现多种预售商品同步下单，进而为用户支付提供便利。
请参阅图5，图5为混合订单中不包含现货商品情况时的订单关联示意图。图5中，父订单包括订单号，子订单1中包括预售商品1的定金和待付尾款金额，子订单2中包括预售商品2的定金和待付尾款金额...子订单m中包括预售商品m的定金和待付尾款金额。通过将所述父订单、所述子订单1、所述子订单2...所述子订单m打上对应的关联标识，建立所述父订单、所述子订单1、所述子订单2...所述子订单m之间的关联。需要说明的是，优惠券信息、包邮信息和银行支付信息在图5中未示出，图5仅以父订单中显示订单号为例进行说明。
在示例性的实施例中，当所述订单为混合订单且所述订单中包括所述现货商品时：
所述判断单元，还用于根据所述商品信息判断所述预售商品是否处于补尾款状态。
所述获取单元，还用于当所述预售商品处于补尾款状态时，从数据库获取所述预售商品的第一实库库存、所述现货商品的可售库存和第二实库库存，其中，所述现货商品信息包括现货商品种类和第二下单数量。
所述创建单元，还用于当所述第一实库库存大于或等于所述第一下单数量且所述可售库存和第二实库库存均大于所述第二下单数量时，根据所述现货商品信息创建第二父订单，并建立所述第二父订单与所述预售商品尾款订单之间的第二关联关系。
具体地，当所述商品信息中既包含预售商品又包含现货商品时，所述判断单元同样需要判断每种预售商品是否均处于补尾款状态，然后分别判断对应预售商品的实库库存是否满足对应的下单数量，同时判断每种现货商品的可售库存和第二实库库存均大于对应的第二下单数量。只有当每种对应预售商品的实库库存均大于或等于对应的下单数量，且现货商品的可售库存和第二实库库存大于或等于对应的下单数量，所述创建单元才建立第二父订单，并将所述第二父订单和所述预售商品尾款订单(也即子订单)进行关联，进而实现所述订单中的所有预售商品和现货商品一起付款。示例性地，若预售商品1的下单数量为2，现货商品1的下单数量为1，且所述判断单元判断出预售商品1处于补尾款阶段，所述获取单元获取到预售商品1的实库库存为50，现货商品1的可售库存为50，实库库存为60，所述判断单元经过判断，判断出预售商品1的实库库存大于预售商品1的下单数量，现货商品的可售库存和实库库存均待遇现货商品1的下单数量，则所述创建单元创建第二父订单，并建立第二父订单与预售商品1尾款订单的关联关系。
在本实施例中，当所述第二父订单创建后，预售商品的实库库存同上述实施例中预售商品实库库存的锁定方式，在此不再赘述。还在对应现货商品的可售库存和实库库存中锁定对应的第二下单数量，并从所述对应的可售库存和实库库存中减去所述第二下单数量。除此之外，还同时锁定所述优惠券信息和包邮信息，以便用户支付时并在达到使用优惠券和包邮的条件下，根据所述优惠券信息和所述包邮信息进行计算。所述第二父订单中至少包括现货商品信息和订单号，当然，还可以包括优惠券信息、包邮信息和银行支付信息。通过虚拟组合订单的模式，将现货商品订单作为父订单，并将预售商品的子订单尾款订单作为子订单进行订单的关联，实现预售商品与现货商品同步下单，进而为用户支付提供便利。
需要说明的是，所述第二父订单与预售商品尾款订单的关联关系图与图5的区别在于，所述第二父订单包括现货商品信息，故在此不作赘述，且不作另图显示。
在示例性的实施例中，所述判断单元还用于：
获取所述预售商品的出到货时间并保存；根据所述出到货时间开启对应的补尾款操作以及补尾款截止期限；当所述补尾款操作已开启且处于所述补尾款操作截止期限内时，则判断所述预售商品处于所述补尾款状态。
具体地，在实际的电商销售场景中，当预售商品出货后即可开启补尾款操作，并根据预售商品的到货时间设置补尾款的截止期限，在补尾款操作开启后并在截止期限到来之前，用户可对所述预售商品进行补款。用户可进行补款操作的预售商品的状态称为补尾款状态。上述步骤能够准确地判断出预售商品是否处于补尾款状态，以确保父订单的成功创建。
所述获取模块201，还用于当所述订单为混合订单且所述订单中不包括现货商品时，获取每种预售商品尾款订单，其中每种预售商品尾款订单包括第一下单数量和待补尾款金额。
具体地，所述获取模块201通过获取预售商品尾款订单，可获取每种预售商品的待补尾款金额，结合每种预售商品的对应的第一下单数量，进而可计算出所有预售商品的总待补尾款金额。
计算模块203，用于根据所述优惠信息和每种预售商品尾款订单进行计算，得到付款金额，以使所述用户根据所述付款金额进行付款。
具体地，所述计算模块203根据每种预售商品尾款订单计算所有预售商品的总待补尾款金额，并根据所述总待补尾款金额、所述优惠信息计算出总的付款金额。通过将多个尾款订单一起结算，使得用户的付款金额满足平台优惠的要求，低货值的商品通过凑单不仅可以容易达到优惠券使用门槛，同时还容易达到包邮门槛，大大提高了用户的购物体验，增强了系统订单数据处理的灵活性和兼容性，同时促进了平台低单价商品和跨品类商品的销售量，极大地降低了供应链成本。
在示例性的实施例中，所述获取模块201，还用于获取每种预售商品尾款订单和每种现货商品的售价金额；所述计算模块203，还用于根据所述优惠信息、每种预售商品尾款订单、所述第二下单数量和所述售价金额进行计算，得到所述付款金额，以使所述用户根据所述付款金额进行付款。
具体地，当所述订单中存在预售商品和和现货商品时，所述获取模块201需要同时获取每种预售商品尾款订单和每种现货商品的售价金额，所述计算模块203结合每种现货商品对应的第二下单数量计算出所述订单的总金额。然后，所述计算模块203将根据所述总金额、所述优惠信息计算出总的付款金额。通过本方法，在提高用户购物体验的同时，极大地降低了仓储操作成本，极大地促进了跨品类商品的销售量。
在示例性的实施例中，所述订单数据处理系统还可以包括生成模块，用于当所述用户付款完成时，删除所述第一父订单和每种预售商品尾款订单或所述第二父订单和所述预售商品尾款订单，并生成支付订单并显示。
具体地，混合订单中无论是否存在现货商品，在检测到用户付款完成时，所述生成模块均需删除对应的父订单，所有预售商品对应的尾款订单(也即子订单)，并生成对应的支付订单。需要说明的是，所述支付订单可以模块化显示现货商品支付信息和预售商品支付信息，其中，所述预售商品支付信息包括所述预售商品种类、所述第一下单数量、定金和补尾款金额，所述现货商品支付信息包括支付信息。由于支付订单使用了优惠券，故，所述支付订单可根据所述预售商品的补尾款金额和现货商品的售价金额的比例，进行对应的优惠减免，并显示减免后的金额。本方法为用户查看各个商品付款信息提供方便，并且极大地提升了用户的购物体验。
在示例性的实施例中，当所述混合订单中不包含有现货商品时，所述订单数据处理系统还可以包括判断模块和删除模块。
所述判断模块，用于当所述第二父订单创建成功时，获取有效付款时间，并判断是否检测到取消付款操作；当超过所述有效付款时间或在所述有效付款时间内检测到取消付款操作时，判断所述补尾款截止期限是否到期。
具体地，若超过所述有效付款时间或在所述有效时间内检测到取消付款操作，则代表用户需要取消所述混合订单。当用户需要取消所述混合订单时，通过补尾款截止期限的判断，在用户仅仅需要取消现货商品的购买的情况下，不会因为混合订单的取消而影响用户已付定金的预售商品订单，为用户的购买提供极大的便利和购物体验，同时保障用户的合法权益。
所述删除模块，用于当所述补尾款截止期限未到期时，则删除所述第二父订单和所述第二关联关系；若所述补尾款截止期限到期时，则删除所述第二父订单、所述预售商品尾款订单和所述第二关联关系。
具体地，若所有的预售商品的补尾款截止期限均未到期，则所述删除模块仅仅删除第一父订单和第一父订单与所有子订单之间的关联关系。若其中一个预售商品的补尾款截止期限到期，则所述删除模块删除第一父订单、第一父订单和所有子订单之间的关联关系以及到期的预售商品尾款订单。在所述第一父订单删除的同时，还根据对应预售商品的第一下单数量将对应的第一实库库存加上所述第一下单数量(也即将所述预售商品归还对应的实库库存)，同时释放所述优惠券信息和包邮信息。
在示例性的实施例中，当混合订单中存在现货商品时，在删除第二父订单和第二父订单与所有子订单之间的关联关系的同时，还需根据对应现货商品的第二下单数量将对应的可售库存和第二实库库存加上所述第二下单数量(也即将所述现货商品归还对应的可售库存和实库库存)。本方法通过释放库存、优惠券信息和包邮信息的方式，在保障用户购物体验的同时，极大地降低了计算机内存占有率，提高计算机的处理性能。
本实施例还提供一种计算机设备，如可以执行程序的智能手机、平板电脑、笔记本电脑、台式计算机、机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。如图12所示，本实施例的计算机设备30至少包括但不限于：可通过系统总线相互通信连接的存储器301、处理器302。需要指出的是，图12仅示出了具有组件301-302的计算机设备30，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。
本实施例中，存储器301(即可读存储介质)包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器301可以是计算机设备30的内部存储单元，例如该计算机设备30的硬盘或内存。在另一些实施例中，存储器301也可以是计算机设备30的外部存储设备，例如该计算机设备30上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。当然，存储器301还可以既包括计算机设备30的内部存储单元也包括其外部存储设备。在本实施例中，存储器301通常用于存储安装于计算机设备30的操作系统和各类应用软件，例如上述实施例的订单数据处理系统的程序代码等。此外，存储器301还可以用于暂时地存储已经输出或者将要输出的各类数据。
处理器302在一些实施例中可以是中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器302通常用于控制计算机设备30的总体操作。
具体的，在本实施例中，处理器302用于执行处理器302中存储的订单数据处理方法的程序，所述订单数据处理方法的程序被执行时实现如下步骤：
获取用户下单时的商品信息和优惠信息；
根据所述商品信息创建对应的订单，并确定所述订单的订单类型，其中，所述订单类型包括混合订单和常规订单；
当所述订单为混合订单且所述订单中不包括现货商品时，获取每种预售商品尾款订单，其中每种预售商品尾款订单包括第一下单数量和待补尾款金额；
根据所述优惠信息和每种预售商品尾款订单进行计算，得到付款金额，以使所述用户根据所述付款金额进行付款。
上述方法步骤的具体实施例过程可参见上述实施例，本实施例在此不再重复赘述。
本实施例还提供一种计算机可读存储介质，如闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘、服务器、App应用商城等等，其上存储有计算机程序，所述计算机程序被处理器执行时实现如下方法步骤：
获取用户下单时的商品信息和优惠信息；
根据所述商品信息创建对应的订单，并确定所述订单的订单类型，其中，所述订单类型包括混合订单和常规订单；
当所述订单为混合订单且所述订单中不包括现货商品时，获取每种预售商品尾款订单，其中每种预售商品尾款订单包括第一下单数量和待补尾款金额；
根据所述优惠信息和每种预售商品尾款订单进行计算，得到付款金额，以使所述用户根据所述付款金额进行付款。
上述方法步骤的具体实施例过程可参见上述实施例，本实施例在此不再重复赘述。
本实施例提供的订单数据处理方法、系统、计算机设备及可读存储介质，判断用户的订单是否为混合订单，当为混合订单且所述订单中不包括现货商品时，将所有预售商品的尾款订单中的待付尾款金额一起计算，并结合优惠信息计算优惠价格，得到付款金额，以使所述用户根据所述付款金额进行付款。本发明通过将多个尾款订单一起结算，使得用户的付款金额满足平台优惠的要求，极大地提高了用户的购物体验，促进了用户的单次消费(也即客单价)，增强了系统订单数据处理的灵活性和兼容性，同时促进了平台的低单价商品和跨品类商品的销售量，极大地降低了供应链成本。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。
以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种订单数据处理方法，其特征在于，所述方法包括：
获取用户下单时的商品信息和优惠信息；
根据所述商品信息创建对应的订单，并确定所述订单的订单类型，其中，所述订单类型包括混合订单和常规订单；
当所述订单为混合订单且所述订单中不包括现货商品时，获取每种预售商品尾款订单，其中每种预售商品尾款订单包括第一下单数量和待补尾款金额；
根据所述优惠信息和每种预售商品尾款订单进行计算，得到付款金额，以使所述用户根据所述付款金额进行付款。
2.如权利要求1所述的订单数据处理方法，其特征在于，所述根据所述商品信息确定所述订单的类型，包括：
若所述商品信息中包括多种预售商品或至少一种预售商品和至少一种现货商品的组合时，则确定所述订单为所述混合订单；
若所述商品信息中仅仅包括一种预售商品或至少一种现货商品时，则确定所述订单为常规订单。
3.如权利要求1所述的订单数据处理方法，其特征在于，当所述订单为所述混合订单且不包括所述现货商品时，所述根据所述商品信息创建对应的订单，包括：
根据所述商品信息判断每种预售商品是否处于补尾款状态；
当每种预售商品均处于补尾款状态时，从数据库获取每种预售商品对应的第一实库库存；
当所述第一实库库存均大于或等于所述第一下单数量时，创建第一父订单，并建立所述第一父订单与每种预售商品尾款订单之间的第一关联关系。
4.如权利要求1所述的订单数据处理方法，其特征在于，当所述订单为所述混合订单且所述订单中包括所述现货商品时，所述根据所述商品信息创建对应的订单，包括：
根据所述商品信息判断所述预售商品是否处于补尾款状态；
当所述预售商品处于补尾款状态时，从数据库获取所述预售商品的第一实库库存、所述现货商品的可售库存和第二实库库存，其中，所述现货商品信息包括现货商品种类和第二下单数量；
当所述第一实库库存大于或等于所述第一下单数量且所述可售库存和第二实库库存均大于所述第二下单数量时，根据所述现货商品信息创建第二父订单，并建立所述第二父订单与所述预售商品尾款订单之间的第二关联关系。
5.如权利要求3或4所述的订单数据处理方法，其特征在于，所述根据所述商品信息判断所述预售商品是否处于补尾款状态，包括：
获取所述预售商品的出到货时间并保存；
根据所述出到货时间开启对应的补尾款操作以及补尾款截止期限；
当所述补尾款操作已开启且处于所述补尾款操作截止期限内时，则判断所述预售商品处于所述补尾款状态。
6.如权利要求4所述的订单数据处理方法，其特征在于，所述方法还包括：
获取每种预售商品尾款订单和每种现货商品的售价金额；
根据所述优惠信息、每种预售商品尾款订单、所述第二下单数量和所述售价金额进行计算，得到所述付款金额，以使所述用户根据所述付款金额进行付款。
7.如权利要求3或6所述的订单数据处理方法，其特征在于，所述方法还包括：
当所述用户付款完成时，删除所述第一父订单和每种预售商品尾款订单或所述第二父订单和所述预售商品尾款订单，并生成支付订单并显示。
8.如权利要求6所述的订单数据处理方法，其特征在于，所述方法还包括：
当所述第二父订单创建成功时，获取有效付款时间，并判断是否检测到取消付款操作；
当超过所述有效付款时间或在所述有效付款时间内检测到取消付款操作时，判断所述补尾款截止期限是否到期；
若所述补尾款截止期限未到期，则删除所述第二父订单和所述第二关联关系；
若所述补尾款截止期限到期时，则删除所述第二父订单、所述预售商品尾款订单和所述第二关联关系。
9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的订单数据处理方法的步骤。
10.一种计算机设备，所述计算机设备包括：存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至8中任一项的所述订单数据处理方法的步骤。
CN202010182574.0A 2020-03-16 2020-03-16 订单数据处理方法 Pending CN112418968A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010182574.0A CN112418968A (zh) 2020-03-16 2020-03-16 订单数据处理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010182574.0A CN112418968A (zh) 2020-03-16 2020-03-16 订单数据处理方法

Publications (1)

Publication Number Publication Date
CN112418968A true CN112418968A (zh) 2021-02-26

Family

ID=74844068

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010182574.0A Pending CN112418968A (zh) 2020-03-16 2020-03-16 订单数据处理方法

Country Status (1)

Country Link
CN (1) CN112418968A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113516460A (zh) * 2021-05-10 2021-10-19 上海哔哩哔哩科技有限公司 预付订单处理方法、客户端、服务器及系统

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101136094A (zh) * 2007-09-29 2008-03-05 腾讯科技（深圳）有限公司 一种电子商务交易方法及系统
US20120101885A1 (en) * 2010-10-15 2012-04-26 Kt Corporation Integrated payment method using near field communication and mobile terminal using the same
US20120310757A1 (en) * 2011-06-03 2012-12-06 Lg Electronics Inc. Method for controlling stores and system for the same
CN106485558A (zh) * 2015-08-14 2017-03-08 阿里巴巴集团控股有限公司 商品对象预售信息处理方法及装置
CN107203917A (zh) * 2016-03-17 2017-09-26 阿里巴巴集团控股有限公司 一种业务处理方法、装置及系统
CN107578224A (zh) * 2017-09-13 2018-01-12 深圳前海乘势科技有限公司 多平台聚合支付的方法及装置
CN108038681A (zh) * 2017-12-21 2018-05-15 知而行（上海）营销咨询有限公司 跨商户交易支付信息处理方法
CN108460586A (zh) * 2018-02-10 2018-08-28 深圳壹账通智能科技有限公司 一种聚合支付的金额优惠方法、装置、终端设备及存储介质
CN108564441A (zh) * 2018-04-10 2018-09-21 合肥美的智能科技有限公司 基于无人零售设备的合并结算方法以及合并结算装置和系统
CN109767260A (zh) * 2018-12-15 2019-05-17 深圳壹账通智能科技有限公司 基于一体化支付的账单优惠方法、装置、设备及存储介质

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101136094A (zh) * 2007-09-29 2008-03-05 腾讯科技（深圳）有限公司 一种电子商务交易方法及系统
US20120101885A1 (en) * 2010-10-15 2012-04-26 Kt Corporation Integrated payment method using near field communication and mobile terminal using the same
US20120310757A1 (en) * 2011-06-03 2012-12-06 Lg Electronics Inc. Method for controlling stores and system for the same
CN106485558A (zh) * 2015-08-14 2017-03-08 阿里巴巴集团控股有限公司 商品对象预售信息处理方法及装置
CN107203917A (zh) * 2016-03-17 2017-09-26 阿里巴巴集团控股有限公司 一种业务处理方法、装置及系统
CN107578224A (zh) * 2017-09-13 2018-01-12 深圳前海乘势科技有限公司 多平台聚合支付的方法及装置
CN108038681A (zh) * 2017-12-21 2018-05-15 知而行（上海）营销咨询有限公司 跨商户交易支付信息处理方法
CN108460586A (zh) * 2018-02-10 2018-08-28 深圳壹账通智能科技有限公司 一种聚合支付的金额优惠方法、装置、终端设备及存储介质
CN108564441A (zh) * 2018-04-10 2018-09-21 合肥美的智能科技有限公司 基于无人零售设备的合并结算方法以及合并结算装置和系统
CN109767260A (zh) * 2018-12-15 2019-05-17 深圳壹账通智能科技有限公司 基于一体化支付的账单优惠方法、装置、设备及存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
匿名: ""双11预售尾款可以合并支付吗？"", 《网络杂谈》 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113516460A (zh) * 2021-05-10 2021-10-19 上海哔哩哔哩科技有限公司 预付订单处理方法、客户端、服务器及系统

Similar Documents

Publication Publication Date Title
US20120173308A1 (en) Optimizing package delivery using social networks
US20030204445A1 (en) System and method for supporting anonymous transactions
US20130218723A1 (en) Global shipping platform
US20180308050A1 (en) Purchase assistance system
KR102023090B1 (ko) 유형 및 무형의 물품을 배송하기 위한 서비스를 제공하는 전자 상거래 시스템 및 방법
EP4024315A1 (en) Commodity exchange system, commodity exchange method, and commodity exchange program
CN112215544B (zh) 一种商品二次交易的方法、移动终端和计算机存储介质
CN112418968A (zh) 订单数据处理方法
CN114170010A (zh) 撮合交易方法、装置、电子设备及存储介质
CN116362847B (zh) 一种基于跨境电商数字围网的交易方法及系统
CN111882257A (zh) 收货地址修改方法及装置
CN113379508B (zh) 一种基于空间站的货物转卖方法、系统及存储介质
US8612304B1 (en) Seller to seller transactions
CN111860890A (zh) 一种销售管理方法及设备
KR101703737B1 (ko) 이동 마켓을 이용한 상품 구매 및 수령 방법
JP7264560B1 (ja) 配送料見積装置
CN111260390A (zh) 在线购物方法和系统
CN113379557B (zh) 一种基于空间站的礼物智能匹配方法、系统及储存介质
JP7259256B2 (ja) 商品管理システム、商品管理方法及びプログラム
CN112418878B (zh) 权益业务数据处理方法、装置、设备及存储介质
EP4125017A1 (en) Method and system for message mapping to handle template changes
KR101110306B1 (ko) 상품정보의 온라인 제공방법과 그 방법을 위한 장치
JP2018180824A (ja) 配送管理方法、配送管理サーバ、配送管理サーバプログラム及び配送管理システム
JP5113585B2 (ja) プリペイドカード決済システム、プリペイドカード決済方法、管理装置、および、管理プログラム
US11080645B1 (en) Local rating system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination