CN113902474A - 一种信息处理方法、装置、设备及计算机可读存储介质 - Google Patents

一种信息处理方法、装置、设备及计算机可读存储介质 Download PDF

Info

Publication number
CN113902474A
CN113902474A CN202111173144.3A CN202111173144A CN113902474A CN 113902474 A CN113902474 A CN 113902474A CN 202111173144 A CN202111173144 A CN 202111173144A CN 113902474 A CN113902474 A CN 113902474A
Authority
CN
China
Prior art keywords
traded
purchase
purchase limit
determining
limit
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
CN202111173144.3A
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.)
Beijing Jingdong Century Trading Co Ltd
Beijing Wodong Tianjun Information Technology Co Ltd
Original Assignee
Beijing Jingdong Century Trading Co Ltd
Beijing Wodong Tianjun Information 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 Beijing Jingdong Century Trading Co Ltd, Beijing Wodong Tianjun Information Technology Co Ltd filed Critical Beijing Jingdong Century Trading Co Ltd
Priority to CN202111173144.3A priority Critical patent/CN113902474A/zh
Publication of CN113902474A publication Critical patent/CN113902474A/zh
Priority to PCT/CN2022/107696 priority patent/WO2023056771A1/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/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • 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
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against 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
    • 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

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请提供一种信息处理方法、装置、设备及计算机可读存储介质，包括：接收第一终端发送的用于生成订单的第一请求，第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量，订购方为门店用户；根据第一标识和第二标识确定待交易对象的状态；当待交易对象的状态为限购状态时，根据第一标识和第二标识对待交易数量的合法性进行校验，得到校验结果；当校验结果为待交易数量合法时，确定并发送第一响应至第一终端，第一响应中携带有基于第一请求生成的待支付的订单信息。如此，实现针对门店用户的限购，通过区分个人用户的限购和门店用户的限购，能够提升特卖活动的转化率，且能够提高用户的满意度。

Description

一种信息处理方法、装置、设备及计算机可读存储介质
技术领域
本申请涉及数据处理技术领域，涉及但不限于一种信息处理方法、装置、设备及计算机可读存储介质。
背景技术
随着网上购物平台的兴起，越来越多的用户选择网上购物方式进行商品购买。线上平台，各商家为了吸引流量，常采用特卖活动的方式吸引顾客。由于价格便宜或者商品稀有，往往特卖商品有数量限制，相关技术中对特定商品设置的限购机制，限制用户在规定时间内对特卖商品的购买数量，在规定时间内无法购买超过购买数量的特卖商品。相关技术中限购粒度仅限于用户，针对用户的限购规则，无法适用于具有级别区分的门店的限购。
发明内容
有鉴于此，本申请实施例提供一种信息处理方法、装置、设备及计算机可读存储介质。
本申请实施例的技术方案是这样实现的：
本申请实施例提供一种信息处理方法，所述方法包括：
接收第一终端发送的用于生成订单的第一请求，所述第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量，所述订购方为门店用户；
根据所述第一标识和所述第二标识确定所述待交易对象的状态，所述待交易对象的状态包括限购状态和正常状态；
当所述待交易对象的状态为限购状态时，根据所述第一标识和所述第二标识对所述待交易数量的合法性进行校验，得到校验结果；
当所述校验结果为所述待交易数量合法时，确定并发送第一响应至所述第一终端，所述第一响应中携带有基于所述第一请求生成的待支付的订单信息。
在一些实施例中，所述根据所述第一标识和所述第二标识确定所述待交易对象的状态，包括：
根据所述第一标识和所述第二标识，确定所述待交易对象的限购条件，所述限购条件至少包括限购时段和限购数量；
获取接收到所述第一请求的时刻；
当接收到所述第一请求的时刻在所述限购时段内，将所述待交易对象的状态确定为限购状态；
当接收到所述第一请求的时刻不在所述限购时段内，将所述待交易对象的状态确定为正常状态。
在一些实施例中，所述根据所述第一标识和所述第二标识，确定所述待交易对象的限购条件，包括：
根据所述第二标识，获取所述待交易对象的限购配置信息，所述限购配置信息为销售方在第二终端的配置界面上输入的信息；
根据所述限购配置信息，生成所述待交易对象的限购规则，所述限购规则包括至少一个限购类型、各限购类型的限购时段和各限购类型的限购总量；
根据所述第一标识，确定所述订购方所属的至少一个目标限购类型；
根据各个目标限购类型的限购时段和限购总量，确定所述待交易对象针对所述订购方的限购条件。
在一些实施例中，所述根据所述第一标识和所述第二标识对所述待交易数量的合法性进行校验，得到校验结果，包括：
根据所述第一标识和所述待交易对象的限购条件，确定所述订购方的限购数量；
根据所述第一标识和所述第二标识，查询所述待交易对象的历史交易记录，获取所述订购方在所述限购时段内的历史交易数量；
根据所述限购数量和所述历史交易数量，确定剩余限购数量；
基于所述剩余限购数量，对所述待交易数量的合法性进行校验，得到校验结果。
在一些实施例中，所述基于所述剩余限购数量，对所述待交易数量的合法性进行校验，得到校验结果，包括：
判断所述待交易数量是否小于或等于所述剩余限购数量；
当所述待交易数量小于或等于所述剩余限购数量时，获取所述待交易对象的剩余库存量；
判断所述待交易数量是否小于或等于所述剩余库存量；
当所述待交易数量小于或等于所述剩余库存量时，将所述校验结果确定为所述待交易数量合法；
当所述待交易数量大于所述剩余限购数量，或所述待交易数量大于所述剩余库存量时，将所述校验结果确定为待交易数量不合法。
在一些实施例中，所述方法还包括：
接收所述第一终端发送的用于支付订单的第二请求，所述第二请求中携带有支付金额、支付时间和所述订单信息包括的订单号；
基于所述待支付的订单信息对所述支付金额进行验证，得到第一验证结果；
在所述第一验证结果表征验证通过时，确定并发送第二响应至所述第一终端，所述第二响应中携带有表征交易成功的提示信息；
对所述剩余限购数量进行更新，得到更新后的剩余限购数量。
在一些实施例中，所述方法还包括：
接收所述第一终端发送的用于退回所述待交易对象的第三请求，所述第三请求中携带有待退回的订单信息；
基于已支付的订单信息对所述待退回的订单信息进行验证，得到第二验证结果；
在所述第二验证结果表征验证通过时，确定并发送第三响应至所述第一终端，所述第三响应中携带有表征退回成功的提示信息；
对所述更新后的剩余限购数量进行更新，得到再次更新后的剩余限购数量。本申请实施例提供一种信息处理装置，所述装置包括：
第一接收模块，用于接收第一终端发送的用于生成订单的第一请求，所述第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量，所述订购方为门店用户；
第一确定模块，用于根据所述第一标识和所述第二标识确定所述待交易对象的状态，所述待交易对象的状态包括限购状态和正常状态；
校验模块，用于当所述待交易对象的状态为限购状态时，根据所述第一标识和所述第二标识对所述待交易数量的合法性进行校验，得到校验结果；
第二确定模块，用于当所述校验结果为所述待交易数量合法时，确定第一响应，所述第一响应中携带有基于所述第一请求生成的待支付的订单信息；
第一发送模块，用于发送所述第一响应至所述第一终端。
本申请实施例提供一种信息处理设备，包括：
处理器；以及
存储器，用于存储可在所述处理器上运行的计算机程序；
其中，所述计算机程序被处理器执行时实现上述信息处理方法的步骤。
本申请实施例提供一种计算机可读存储介质，存储有计算机可执行指令，所述计算机可执行指令配置为执行上述信息处理方法的步骤。
本申请实施例提供一种信息处理方法、装置、设备及计算机可读存储介质，其中，所述方法包括：接收第一终端发送的用于生成订单的第一请求，所述第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量，所述订购方为门店用户；根据所述第一标识和所述第二标识确定所述待交易对象的状态，所述待交易对象的状态包括限购状态和正常状态；当所述待交易对象的状态为限购状态时，根据所述第一标识和所述第二标识对所述待交易数量的合法性进行校验，得到校验结果；当所述校验结果为所述待交易数量合法时，确定并发送第一响应至所述第一终端，所述第一响应中携带有基于所述第一请求生成的待支付的订单信息。如此，实现针对门店用户的限购，通过区分个人用户的限购和门店用户的限购，能够提升特卖活动的转化率，且能够提高用户的满意度。
附图说明
在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。
图1为本申请实施例提供的信息处理方法的一种实现流程示意图；
图2为本申请实施例提供的信息处理方法的另一种实现流程示意图；
图3为本申请实施例提供的限购方法包括的各过程的流程示意图；
图4为本申请实施例提供的设置限购规则的流程示意图；
图5为本申请实施例提供的查询限购数量的流程示意图；
图6为本申请实施例提供的扣减限购数量的流程示意图；
图7为本申请实施例提供的回退限购数量的流程示意图；
图8为本申请实施例提供的信息处理装置的组成结构示意图；
图9为本申请实施例提供的信息处理设备的组成结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。
1)门店用户：在线上购物时，若订购方为店铺，则将该订购方称为门店用户；与之相对的，若订购方为个人，则将该订购方称为个人用户。
2)门店组：在某一维度具有相同标识的门店的组合，例如，在部门、项目、标签等不同维度对多个具有相同标识的门店的组合，如：按销售类型维度进行部门划分，将销售衣服的门店作为第一部门，将销售鞋的门店作为第二部门；又如：按地区维度进行项目划分，将A省的门店作为第一项目，将B省的门店作为第二项目；再如，按销售量维度进行标签划分，将销售量大于第一阈值的门店作为第一标签，将销售量大于第二阈值且不大于第一阈值的门店作为第二标签。
3)远程字典服务(Remote Dictionary Server，Redis)，一个开源、内存存储的数据结构服务器，可用作数据库、高速缓存和消息队列代理。它支持字符串、哈希表、列表、集合、有序集合、位图、HyperLogLong等数据类型。
4)乐观锁，是相对悲观锁而言的，乐观锁假设数据一般情况不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。乐观锁适用于读多写少的场景，这样可以提高程序的吞吐量。
本申请实施例提供一种应用于交易系统的信息处理方法。本申请实施例提供的方法可以通过计算机程序来实现，该计算机程序在执行的时候，完成本申请实施例提供的信息处理方法中各个步骤。在一些实施例中，该计算机程序可以信息处理设备中的处理器执行。图1为本申请实施例提供的信息处理方法的一种实现流程示意图，如图1所示，该信息处理方法包括以下步骤：
步骤S101，接收第一终端发送的用于生成订单的第一请求。
这里，步骤S101接收第一请求可以是由服务端实现的。该服务端可以为交易服务器，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、大数据以及人工智能平台等基础云计算服务的云服务器。这里的第一终端指订购方持有的终端，该终端可以是笔记本电脑，平板电脑，台式计算机，智能手机，等等。终端以及服务端可以通过有线或无线通信方式进行直接或间接地连接。
相关技术中的限购规则只能应用于普通用户，无法适用于门店用户，本申请实施例提供的方法用于解决门店用户的限购问题。本申请实施例中的订购方为门店用户。线下门店库存不足需要采购某一商品时，即订购方需要订购待交易对象时，在自身持有的第一终端上的采购界面中，选择出待交易对象，并输入待交易数量，第一终端根据用户选择和输入的信息，生成用于生成订单的第一请求，该第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量。
步骤S102，根据第一标识和第二标识确定待交易对象的状态。
该待交易对象的状态包括限购状态和正常状态。当门店用户在交易系统上订购的待交易对象，被销售方设置了有关该订购方的限购配置信息时，该待交易对象的状态为限购状态；当门店用户在交易系统上订购的待交易对象，未被销售方设置限购配置信息，或者被销售方设置了限购配置信息，但设置的限购配置信息与该订购方无关(如设置关于普通用户或其他订购方的限购配置信息)，此时，该待交易对象的状态为正常状态。
根据第一标识和第二标识确定待交易对象的状态后，判断待交易对象的状态是否为限购状态，若为限购状态，进入步骤S103；若不为限购状态，即待交易对象的状态为正常状态，在不限购的情况下订购方可以正常地订购待交易对象。
步骤S103，当待交易对象的状态为限购状态时，根据第一标识和第二标识对待交易数量的合法性进行校验，得到校验结果。
待交易对象的状态为限购状态，此时订购方订购的数量(即待交易数量)不能大于允许该订购方订购的最大数量。对该待交易数量的合法性进行校验，当待交易数量小于或等于允许该订购方订购的最大数量时，得到的校验结果为待交易数量合法，此时进入步骤S104；当待交易数量大于允许该订购方订购的最大数量时，得到的校验结果为待交易数量不合法，此时不能成功的生成订单。
步骤S104，当校验结果为待交易数量合法时，确定并发送第一响应至第一终端。
该第一响应中携带有基于第一请求生成的待支付的订单信息，第一终端接收到第一响应后，显示待支付的订单信息，以使订购方基于待支付的订单信息完成支付。
本申请实施例提供的信息处理方法，服务端接收第一终端发送的用于生成订单的第一请求，该第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量，该订购方为门店用户；根据第一标识和第二标识确定待交易对象的状态，该待交易对象的状态包括限购状态和正常状态；当待交易对象的状态为限购状态时，根据第一标识和第二标识对待交易数量的合法性进行校验，得到校验结果；当校验结果为待交易数量合法时，确定并发送第一响应至第一终端，该第一响应中携带有基于第一请求生成的待支付的订单信息，实现针对门店用户的限购，通过区分个人用户的限购和门店用户的限购，能够提升特卖活动的转化率，且能够提高用户的满意度。
在一些实施例中，图1所示实施例中步骤S102“根据第一标识和第二标识确定待交易对象的状态”可以通过以下步骤来实现：
步骤S1021，根据第一标识和第二标识，确定待交易对象的限购条件。
这里，限购条件至少包括限购时段和限购数量。限购时段即在该时段内，该待交易对象是限购的，每个门店用户最多只能购买限购总量的待交易对象。限购数量指限购时段内，剩余可购买限购数量的待交易对象，等于限购总量减去限购时段内已购买数量。
本申请实施例中，可以先根据第二标识，确定出待交易对象的限购规则，然后根据第一标识和限购规则，确定待交易对象针对第一标识所对应的门店用户的限购条件。在实际实现时，确定待交易对象的限购条件时，可以实现为以下步骤：
步骤S10211，根据第二标识，获取待交易对象的限购配置信息。
该限购配置信息为销售方在第二终端的配置界面上输入的信息。该限购配置信息，可以从服务端自身的存储空间获取，也可以从其他服务端的存储空间获取，还可以在需要时实时地从第二终端的存储空间获取。
销售方可能由于库存较少、库存积压，或者想要提高交易量等情况限购某个商品时，在自身持有的第二终端上呈现的配置界面上输入限购配置信息。该限购配置信息至少包括用于配置限购时段的信息、用于配置限购对象的信息和用于配置各种限购对象的限购总量的信息。
该限购时段是未来的某一时间段。该限购对象可以包括个人用户对象和门店用户对象中至少一种，当限购对象仅包括个人用户对象时，对订购方来说，待交易对象(即商品)的状态为不限购的正常状态。限购对象的限购总量，是指允许该限购对象在该限购时段购买的最大量。
在一些实施例中，限购配置信息还可以包括用于配置限购价格的信息，当销售方希望增加成交量时，限购价格可以小于正常价格，当销售方希望减少成交量时，限购价格可以大于正常价格。
在一些实施例中，当限购对象包括门店用户时，限购配置信息还可以包括用于配置限购类型的限购总量的信息，这里限购类型包括门店限购、部门限购、项目限购和标签限购等不同维度的门店组合的限购。
步骤S10212，根据限购配置信息，生成待交易对象的限购规则。
本申请实施例中，订购方为门店用户，该限购规则包括至少一个限购类型、各限购类型的限购时段和各限购类型的限购总量。根据限购配置信息包括的用于配置限购时段的信息、用于配置限购对象的信息、用于配置各种限购对象的限购总量的信息和用于配置限购类型的限购总量的信息，生成待交易对象的限购规则。
举例说明，销售方在第二终端输入某商品(待交易对象)的限购配置信息，服务端根据限购配置信息，生成待交易对象的限购规则包括：部门a限购，限购时段2021年8月8日00:00:00-23:59:59，限购总量1000个；项目1限购，限购时段2021年8月8日10:00:00-12:00:00，限购总量200个；标签aa限购，限购时段2021年8月8日12:00:00-14:00:00，限购总量50个；门店1)限购，限购时段2021年8月8日10:00:00-12:00:00，限购总量20个。
步骤S10213，根据第一标识，确定订购方所属的至少一个目标限购类型。
每种限购类型包括具有相同标签的门店用户，根据第一标识，确定订购方所属的目标限购类型，如订购方门店用户A，查询数据库，该门店用户A属于部门a，也属于项目1，则其目标限购类型包括门店A限购、部门a限购和项目1限购。
步骤S10214，根据各个目标限购类型的限购时段和限购总量，确定待交易对象针对订购方的限购条件。
本申请实施例中，订购方门店用户A对应的多个目标限购类型，根据各个目标限购类型的限购时段和限购总量，确定该待交易对象针对该门店用户A的限购条件。该限购条件包括限购时段和限购数量。
步骤S1022，获取接收到第一请求的时刻。
门店用户在第一终端上选购待交易对象，设置待交易数量(即准备购买的数量)后点击“提交订单”的按键，第一终端响应于提交订单的点击操作，至少根据门店用户的标识(第一标识)、待交易对象的标识(第二标识)和待交易数量生成用于生成订单的第一请求，并将第一请求发送至服务端。服务端接收到第一请求后，记录接收到第一请求的时刻，并对第一请求进行解析，至少得到第一请求携带的第一标识、第二标识和待交易数量。
本申请实施例中，忽略网络传输的耗时，认为接收到第一请求的时刻即为第一终端发送第一请求的时刻。
步骤S1023，判断接收到第一请求的时刻是否在限购时段内。
当接收到第一请求的时刻在限购时段内，即门店用户在待交易对象的限购时段内提交订单，此时待交易对象对门店用户是限购的，进入步骤S1024；当接收到第一请求的时刻不在限购时段内，即门店用户在待交易对象的非限购时段内提交订单，此时待交易对象对门店用户是不限购的，进入步骤S1025。
假设接收到第一请求的时刻为2021年8月8日01:00:00，该时刻在限购时段2021年8月8日00:00:00-23:59:59内，因此将待交易对象的状态确定为限购状态；假设接收到第一请求的时刻为2021年8月7日01:00:00，该时刻不在限购时段2021年8月8日00:00:00-23:59:59内，因此将待交易对象的状态确定为正常状态。
步骤S1024，将待交易对象的状态确定为限购状态。
步骤S1025，将待交易对象的状态确定为正常状态。
本申请实施例中，根据第一标识和第二标识确定待交易对象的状态，当待交易对象的状态为限购状态时，表明待交易对象针对该门店用户限购，最多能购买限购数量的待交易对象，当待交易对象的状态为正常状态时，表明待交易对象针对该门店用户不限购，可购买任意数量的待交易对象。
在一些实施例中，当待交易对象的状态为正常状态时，对订购方不限购，根据待交易数量直接生成订单即可。当待交易对象的状态为限购状态时，需要对待交易数量进行校验，在一种实现方式中，图1所示实施例中步骤S103中“根据第一标识和第二标识对待交易数量的合法性进行校验，得到校验结果”可以通过以下步骤来实现：
步骤S1031，根据第一标识和待交易对象的限购条件，确定订购方的限购数量。
销售方在设置限购配置信息时，可以针对同一个待交易对象、不同标识的门店用户设置不同的限购条件。根据第一标识和待交易对象的限购条件，确定该第一标识对应的订购方的限购数量。
如部门a在2021年8月8日00:00:00-23:59:59内限购总量为1000个，项目1在10:00:00-12:00:00限购总量200个，门店用户A在10:00:00-12:00:00内限购总量20个。当接收到第一请求的时刻为2021年8月8日01:00:00，此时订购方的限购数量为1000个；当接收到第一请求的时刻为2021年8月8日11:00:00，此时订购方的限购数量为20个。当多个目标限购类型的限购时段重合时，在重合时间段内订购方的限购数量为限购总量最少的目标限购类型的限购总量。
步骤S1032，根据第一标识和第二标识，查询待交易对象的历史交易记录，获取订购方在限购时段内的历史交易数量。
根据第二标识，确定目标限购类型对应的所有订购方在限购时段内的历史交易数量，根据所有订购方在限购时段内的历史交易数量，以及步骤S1031中确定的第一标识对应的订购方的限购数量，确定出该订购方在限购时段内的历史交易数量。
步骤S1033，根据限购数量和历史交易数量，确定剩余限购数量。
仍以上述接收到第一请求的时刻为2021年8月8日11:00:00，订购方的限购数量为20个进行举例说明。门店用户A所属部门a在2021年8月8日00:00:00-23:59:59内限购总量为1000个，该部门a中其他门店用户在2021年8月8日00:00:00-10:59:59内已交易990个；当门店用户A之前未订购该待交易对象，针对门店用户A来说，其限购数量为20个，根据历史交易数量，确定该门店用户A在该限购时段最多可订购10个，如此，得到剩余限购数量为10个；当门店用户A在10点之前已订购该待交易对象30个，由于之前订购的30个不在当前限购时段内，针对门店用户A来说，其限购数量仍为20个，根据历史交易数量，确定该门店用户A在该限购时段最多可订购10个，如此，得到剩余限购数量为10个；当门店用户A在9点至10点之间已订购15个，在当前限购时段内，针对门店用户A来说，其限购数量为20-15＝5个，根据历史交易数量，确定该门店用户A在该限购时段最多可订购10个，如此，得到剩余限购数量为5个。
步骤S1034，基于剩余限购数量，对待交易数量的合法性进行校验，得到校验结果。
在一种实现方式中，对待交易数量的合法性进行校验时，可以实现为：判断待交易数量是否小于或等于剩余限购数量；当待交易数量小于或等于剩余限购数量时，将校验结果确定为待交易数量合法；当待交易数量大于剩余库存量时，将校验结果确定为待交易数量不合法。比较待交易数量和剩余限购数量，当待交易数量小于或等于剩余限购数量时，确定校验结果为待交易数量合法，此时确定可以成功的生成订单，进入步骤S104；当待交易数量大于剩余限购数量时，确定校验结果为待交易数量不合法，此时确定无法成功地生成对应数量的订单，可以向第一终端发送提示消息，该提示消息携带有生成订单失败的信息。在一些实现方式中，该提示消息还可以携带失败原因，如该提示消息携带有待交易数量超出剩余限购数量的信息。
在上述实现方式的基础上，还可以在剩余限购数量大于或等于待交易数量时，进一步判断库存是否足量，此时，对待交易数量的合法性进行校验可以实现为：判断待交易数量是否小于或等于剩余限购数量；当待交易数量小于或等于剩余限购数量时，获取待交易对象的剩余库存量；判断待交易数量是否小于或等于剩余库存量；当待交易数量小于或等于剩余库存量时，将校验结果确定为待交易数量合法；当待交易数量大于剩余限购数量，或待交易数量大于剩余库存量时，将校验结果确定为待交易数量不合法。比较待交易数量和剩余限购数量的大小，当待交易数量小于或等于剩余限购数量时，比较待交易数量和剩余库存量的大小，当待交易数量小于或等于剩余库存量时，确定校验结果为待交易数量合法，此时确定可以成功的生成订单，进入步骤S104；当待交易数量大于剩余限购数量，或者待交易数量大于剩余库存量时，确定校验结果为待交易数量不合法，此时确定无法成功地生成对应数量的订单，可以向第一终端发送提示消息，该提示消息携带有生成订单失败的信息。在一些实现方式中，该提示消息还可以携带失败原因，如该提示消息携带有待交易数量超出剩余限购数量或者待交易数量超出剩余库存量的信息。
本申请实施例中，通过确定订购方的限购数量，结合该订购方在限购时段内的历史交易数量，以及该订购方所属目标限购类型的历史交易数量，确定该订购方的剩余限购数量，通过比较待交易数量与剩余限购数量，实现对待交易数量的合法性的校验。
在图1所示实施例的基础上，本申请实施例再提供一种应用于交易系统的方法，图2为本申请实施例提供的信息处理方法的另一种实现流程示意图，如图2所示，该方法包括以下步骤：
步骤S201，接收第一终端发送的用于生成订单的第一请求。
该第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量。
本申请实施例中，步骤S201、步骤S202的实现方式分别参见图1所示实施例中步骤S101、步骤S102中对应的描述。
步骤S202，根据第一标识和第二标识确定待交易对象的状态。
该待交易对象的状态包括限购状态和正常状态。
步骤S203，判断待交易对象的状态是否为限购状态。
根据第一标识和第二标识确定待交易对象的状态后，判断待交易对象的状态是否为限购状态，若为限购状态，进入步骤S204；若不为限购状态，即待交易对象的状态为正常状态，在不限购的情况下订购方可以正常地订购待交易对象，此时进入步骤S206。
步骤S204，根据第一标识和第二标识对待交易数量的合法性进行校验，得到校验结果。
待交易对象的状态为限购状态，此时订购方订购的待交易数量不能大于允许该订购方订购的最大数量。对该待交易数量的合法性进行校验，得到校验结果，该校验结果表征为待交易数量合法或不合法。
步骤S205，判断校验结果是否为待交易数量合法。
当校验结果为待交易数量合法时，认为待交易数量小于或等于允许该订购方订购的最大数量，此时进入步骤S206；当校验结果为待交易数据不合法时，认为待交易数量大于允许该订购方订购的最大数量，此时不能成功的生成订单，进入步骤S212。
步骤S206，确定并发送第一响应至第一终端。
该第一响应中携带有基于第一请求生成的待支付的订单信息，第一终端接收到第一响应后，显示待支付的订单信息，以使订购方基于待支付的订单信息完成支付。
第一终端接收到第一响应后，呈现待支付的订单信息，订购方基于待支付的订单信息进行支付，支付待支付金额后，第一终端根据支付金额、支付时间和订单信息生成用于支付订单的第二请求，并将该第二请求发送至服务端。
步骤S207，接收第一终端发送的用于支付订单的第二请求。
该第二请求中携带有支付金额、支付时间和订单信息包括的订单号。
步骤S208，基于待支付的订单信息对支付金额进行验证，得到第一验证结果。
服务端接收到该第二请求后，根据订单号对生成订单的信息和第二请求携带的支付订单的信息进行验证。若生成订单的信息和支付订单的信息一致，表明支付无误，得到验证通过的第一验证结果；若生成订单的信息和支付订单的信息不一致，表明支付有误，得到验证不通过的第一验证结果。
步骤S209，判断第一验证结果是否表征验证通过。
当第一验证结果表征验证通过时，确定支付成功，进入步骤S210；当第一验证结果表征验证不通过时，确定支付失败，进入步骤S213。
步骤S210，确定并发送第二响应至第一终端。
该第二响应中携带有表征交易成功的提示信息。
步骤S211，对剩余限购数量进行更新，得到更新后的剩余限购数量。
当交易成功时，将原剩余限购数量减去待交易数量，得到更新后的剩余限购数量。这里，对剩余限购数量进行更新，进一步的，可以继续对数据库中该交易对象的剩余库存量进行更新，以确保Redis缓存与数据库中数据的一致性。
步骤S212，确定并发送第一提示消息至第一终端。
该第一提示消息至少携带有生成订单失败的信息，还可以携带有生成失败原因，如该第一提示消息携带有待交易数量超出剩余限购数量的信息。
步骤S213，确定并发送第二提示消息至第一终端。
该第二提示消息至少携带有支付订单失败的信息，还可以携带有支付失败的原因，如支付超时、支付金额不正确等。
本申请实施例提供的方法，服务端在生成订单后，门店用户在第一终端上对订单进行支付，服务端继续对用于支付订单的第二请求进行验证，验证通过时确定支付成功，将支付成功的结果发送至第一终端，从而完成待交易对象的限购交易，实现针对门店用户的限购，区分个人用户的限购和门店用户的限购，能够提升特卖活动的转化率，且能够提高用户的满意度。
在一些实施例中，订购方支付成功后，可能由于各种原因退定，退定成功之后，对剩余限购数量再次进行更新。基于此，在上述步骤S212之前，上述方法还可以包括以下步骤：
步骤S21，接收第一终端发送的用于退回待交易对象的第三请求。
该第三请求中携带有待退回的订单信息，该订单信息至少包括订单号。
步骤S22，基于已支付的订单信息对待退回的订单信息进行验证，得到第二验证结果。
服务端接收到该第三请求后，根据订单信息在历史交易订单中查找该订单，若查找到该订单，将第二验证结果确定为验证通过；当在历史交易订单中未查找到该订单，或者查找到的订单与待退回的订单不完全一致(如交易对象的待退回数量大于已交易数量)时，将第二验证结果确定为验证不通过。本申请实施例中，历史交易订单可以从交易日志中获取。
在另一些实施例中，对待退回的订单信息进行验证，不仅验证上述的订单信息，还可以对订购方的退回资格进行验证。此时限购配置信息还可以包括订单期限，交易成功后根据订单期限为每一已交易订单设置退回期限。服务端接收到第三请求后，根据订单信息在历史交易订单中查找该订单，若查找到该订单，获取接收到第三请求的时刻，判断接收到第三请求的时刻是否在待退回订单的退回期限内，当接收到第三请求的时刻在待退回订单的退回期限内时，将第二验证结果确定为验证通过；当在历史交易订单中未查找到该订单，或者查找到的订单与待退回的订单不完全一致，又或者接收到第三请求的时刻超出待退回订单的退回期限时，将第二验证结果确定为验证不通过。
步骤S23，判断第二验证结果是否表征验证通过。
当第二验证结果表征验证通过时，确定验证成功，进入步骤S24；当第二验证结果表征验证不通过时，确定验证失败，进入步骤S26。
步骤S24，对待退回的订单信息进行退回处理，确定并发送第三响应至第一终端。
该第三响应中携带有表征退回成功的提示信息。
步骤S25，对更新后的剩余限购数量进行更新，得到再次更新后的剩余限购数量。
当退回成功时，将步骤S211得到的更新后的剩余限购数量加上退回的交易数量，得到再次更新后的剩余限购数量。该退回的交易数量是根据待退回订单信息确定的。这里，对剩余限购数量进行更新，进一步的，可以继续对数据库中该交易对象的剩余库存量进行更新，以确保Redis缓存与数据库中数据的一致性。
步骤S26，确定并发送第四响应至第一终端。
该第四响应中至少携带有退回订单失败的信息，还可以携带有退回失败的原因，如订单有误等。
本申请实施例提供的方法，当门店用户退回订单时，对待退回订单进行验证，验证通过后进行退回，并更新剩余限购数量，从而完成已交易订单的退回处理，提高用户的满意度。
下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。
线上平台，各商家为了吸引流量，常采用特卖活动的方式吸引顾客。由于价格便宜或者商品稀有，往往特卖商品有数量限制，相关技术中主要是对特定商品设置有效的限购机制，限制个人用户在规定时间内对商品的购买数量，超过购买数量的个人用户无法再次购买。该限购机制，仅适用于独立的个人用户，存在缺陷1)无法对门店用户(toB，toBusiness)模式下，以门店维度限购，规定门店用户可采买的数量；2)无门店组概念，无法以门店组进行限购，规定门店组下各门店用户可采买商品数量；3)无法对指定门店组或者门店用户，设置采买总量，提供抢购功能。可见，现有的面向个人用户的限购机制，不适用于toB的限购。
针对上述问题，本申请实施例提供一种toB模式下的限购方法，针对门店用户建立限购规则，能够应用于线下门店的限购。本申请实施例建立的限购规则，主要包括：
1)门店限购：在规定时间内，设置的限购门店，可采买规定数量内的商品，非限购门店不可购买或购买数量不加限定；
2)门店组限购：在规定时间内，设置的门店组门店，可采买规定数量内的商品，非限购门店不可购买；
3)限购总量：在规定时间内，所有门店采买商品的数量之和，小于或等于限购总量；
4)门店组+总量限购：在规定时间内，设置的门店组门店，可采买规定数量内的商品，并且门店组下的门店对商品的采买之和，小于或等于设置的限购总量，非限购门店不可购买。
本申请实施例提供的限购方法的主要创新点包括：1)提供了3种限购规则：门店限购、门店组限购和总量限购；2)支持高并发下单，限购数量正常扣减；3)可支持不同限购规则的组合，如：门店组+总量限购、门店限购+总量限购；4)支持多种限购对象，如门店限购、部门限购、项目限购、标签限购。
图3为本申请实施例提供的限购方法包括的各过程的流程示意图，如图3所示，该限购方法主要包括限购新建、限购查询、限购扣减和限购回退，限购新建即根据销售方输入的限购配置信息新增限购的交易对象；限购查询主要是查询已建立的限购规则，在交易时根据查询结果对订单信息进行验证；限购扣减发生在交易成功后，根据成功交易的订单信息对限购数量和库存量进行更新；限购回退即退回订单。下面对各过程进行详细说明。
1、限购规则的设置
该模块业务功能包含单个新增、批量新增、限购停用。其编码实现包含设置数据校验、限购活动规则构建、数据存储。图4为本申请实施例提供的设置限购规则的流程示意图，如图4所示，限购规则的设置主要有以下几个步骤：
步骤41，数据校验：限购时间、限购门店组、商品有效性、限购活动审核状态，校验异常提示用户。
步骤42，限购活动构建：限购种类有门店限购、总量限购。这两种限购规则可单独使用，也可组合使用。其限购种类也可生效在门店组，门店组可以是门店、项目、部门、标签。
步骤43，限购活动冲突处理：设置的商品已有限购活动，并且限购冲突，停用旧限购规则。
步骤44，数据存储：将限购活动数据存入数据库，并将限购数据存入缓存。如有总量限购，单独存一份总量限购缓存，提供给门店抢购用，防止流量直接打到数据库上。
2、限购数量查询
该模块主要提供限购数量查询服务。图5为本申请实施例提供的查询限购数量的流程示意图，如图5所示，限购数量查询主要有以下几个步骤：
步骤51，查询限购基础信息：根据门店编号和商品查询限购基础信息，根据基础信息看命中那种限购活动。
步骤52，查询限购活动：通过查询限购基本信息后，得到该商品设置了几种限购规则。获取门店限购数，总量限购数，首先都通过缓存获取，缓存获取失败后再查询数据库。
步骤53，计算最优限购规则：如果有多个限购规则同时生效，限购数量最小的规则为最优。
3、限购数量扣减
该模块主要是下单限购数量扣减功能，其核心在于多门店同时抢占同一限购资源，使用Redis+数据库乐观锁，防止超卖。扣减成功记录订单和限购信息。图6为本申请实施例提供的扣减限购数量的流程示意图，如图6所示，限购数量扣减主要有以下几个步骤：
步骤61，限购基础信息查询：先根据商品编号和门店编号，查询出该商品设置的限购。
步骤62，判断是否满足限购资格：获取缓存里的限购数量，判断剩余资源，是否满足门店下单的商品数量。
步骤63，扣减限购资源：先使用Redis扣减，Redis扣减成功，再扣减数据库，如果数据库扣减失败，回滚Redis。
大批量门店同时抢购一个商品，直接使用数据库，性能无法满足此业务。例：10万个门店，抢购两件商品。Redis特性，线程安全，更新性能强。Redis漏斗式筛选之后，只有两家抢到资格的门店，会更新数据库，并对数据库加乐观锁，做最后一关。可防止超卖。
步骤64，记录限购扣减记录：对扣减成功的限购活动，记录对应的订单信息，作为订单回退，限购资格回退的凭证。
4、限购数量回退
该模块主要功能，门店退单后，如果之前占用过限购资源，将占用的限购资源释放。图7为本申请实施例提供的回退限购数量的流程示意图，如图7所示，限购数量回退主要有以下几个步骤：
步骤71，退单入参校验：根据订单编号、商品编号、退单数量、门店编号，入参，能查出之前是否占用过限购资源。
步骤72，回退限购资源是否有效：根据下单时记录的限购下单日志，可判断出此次待回退的限购资源是否有效。如果待回退的限购资源小于或等于下单占用的限购资源，有效，进行回退；否则无效。是否重复回退。
步骤73，更新数据：将回退的限购资源同步到数据库和Redis。
步骤74，记录回退日志：将回退成功的限购记录，记录到限购日志中，给判断重复回退提供校验数据。
本本申请实施例提供了一种toB模式下，对门店的限购方案，该限购方案支持门店组限购；该方案提供门店限购、总量限购两种限购规则，且支持门店限购、总量限购规则灵活组合使用。
基于前述的实施例，本申请实施例提供一种信息处理装置，该装置包括的各模块、以及各模块包括的各单元，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU，Central ProcessingUnit)、微处理器(MPU，Microprocessor Unit)、数字信号处理器(DSP，Digital SignalProcessing)或现场可编程门阵列(FPGA，Field Programmable Gate Array)等。
本申请实施例再提供一种应用于交易系统信息处理装置，图8为本申请实施例提供的信息处理装置的组成结构示意图，如图8所示，所述信息处理装置800包括：
第一接收模块801，用于接收第一终端发送的用于生成订单的第一请求，所述第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量，所述订购方为门店用户；
第一确定模块802，用于根据所述第一标识和所述第二标识确定所述待交易对象的状态，所述待交易对象的状态包括限购状态和正常状态；
校验模块803，用于当所述待交易对象的状态为限购状态时，根据所述第一标识和所述第二标识对所述待交易数量的合法性进行校验，得到校验结果；
第二确定模块804，用于当所述校验结果为所述待交易数量合法时，确定第一响应，所述第一响应中携带有基于所述第一请求生成的待支付的订单信息；
第一发送模块805，用于发送所述第一响应至所述第一终端。
在一些实施例中，所述第一确定模块802，还用于：
根据所述第一标识和所述第二标识，确定所述待交易对象的限购条件，所述限购条件至少包括限购时段和限购数量；获取接收到所述第一请求的时刻；当接收到所述第一请求的时刻在所述限购时段内，将所述待交易对象的状态确定为限购状态；当接收到所述第一请求的时刻不在所述限购时段内，将所述待交易对象的状态确定为正常状态。
在一些实施例中，所述第一确定模块802，还用于：
根据所述第二标识，获取所述待交易对象的限购配置信息，所述限购配置信息为销售方在第二终端的配置界面上输入的信息；根据所述限购配置信息，生成所述待交易对象的限购规则，所述限购规则包括至少一个限购类型、各限购类型的限购时段和各限购类型的限购总量；根据所述第一标识，确定所述订购方所属的至少一个目标限购类型；根据各个目标限购类型的限购时段和限购总量，确定所述待交易对象针对所述订购方的限购条件。
在一些实施例中，所述校验模块803，还用于：
根据所述第一标识和所述待交易对象的限购条件，确定所述订购方的限购数量；根据所述第一标识和所述第二标识，查询所述待交易对象的历史交易记录，获取所述订购方在所述限购时段内的历史交易数量；根据所述限购数量和所述历史交易数量，确定剩余限购数量；基于所述剩余限购数量，对所述待交易数量的合法性进行校验，得到校验结果。
在一些实施例中，所述校验模块803，还用于：
判断所述待交易数量是否小于或等于所述剩余限购数量；当所述待交易数量小于或等于所述剩余限购数量时，获取所述待交易对象的剩余库存量；判断所述待交易数量是否小于或等于所述剩余库存量；当所述待交易数量小于或等于所述剩余库存量时，将所述校验结果确定为所述待交易数量合法；当所述待交易数量大于所述剩余限购数量，或所述待交易数量大于所述剩余库存量时，将所述校验结果确定为待交易数量不合法。
在一些实施例中，所述信息处理装置800还可以包括：
第二接收模块，用于接收所述第一终端发送的用于支付订单的第二请求，所述第二请求中携带有支付金额、支付时间和所述订单信息包括的订单号；
第一验证模块，用于基于所述待支付的订单信息对所述支付金额进行验证，得到第一验证结果；
第三确定模块，用于在所述第一验证结果表征验证通过时，确定第二响应，所述第二响应中携带有表征交易成功的提示信息；
第二发送模块，用于发送所述第二响应至所述第一终端；
第一更新模块，用于对所述剩余限购数量进行更新，得到更新后的剩余限购数量。
在一些实施例中，所述信息处理装置800还可以包括：
第三接收模块，用于接收所述第一终端发送的用于退回所述待交易对象的第三请求，所述第三请求中携带有待退回的订单信息；
第二验证模块，用于基于已支付的订单信息对所述待退回的订单信息进行验证，得到第二验证结果；
第四确定模块，用于在所述第二验证结果表征验证通过时，确定第三响应，所述第三响应中携带有表征退回成功的提示信息；
第三发送模块，用于发送所述第三响应至所述第一终端；
第二更新模块，用于对所述更新后的剩余限购数量进行更新，得到再次更新后的剩余限购数量。
这里需要指出的是：以上信息处理装置实施例项的描述，与上述方法描述是类似的，具有同方法实施例相同的有益效果。对于本申请信息处理装置实施例中未披露的技术细节，本领域的技术人员请参照本申请方法实施例的描述而理解。
需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read OnlyMemory)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。
相应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述实施例中提供的信息处理方法中的步骤。
本申请实施例提供一种信息处理设备，图9为本申请实施例提供的信息处理设备的组成结构示意图，根据图9示出的信息处理设备900的示例性结构，可以预见信息处理设备900的其他的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。
图9所示的信息处理设备900包括：一个处理器901、至少一个通信总线902、用户接口903、至少一个外部通信接口904和存储器905。其中，通信总线902配置为实现这些组件之间的连接通信。其中，用户接口903可以包括显示屏，外部通信接口904可以包括标准的有线接口和无线接口。其中，所述处理器901配置为执行存储器中存储的信息处理方法的程序，以实现上述实施例提供的信息处理方法中的步骤。
以上信息处理设备和存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请信息处理设备和存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台设备执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种信息处理方法，其特征在于，所述方法包括：
接收第一终端发送的用于生成订单的第一请求，所述第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量，所述订购方为门店用户；
根据所述第一标识和所述第二标识确定所述待交易对象的状态，所述待交易对象的状态包括限购状态和正常状态；
当所述待交易对象的状态为限购状态时，根据所述第一标识和所述第二标识对所述待交易数量的合法性进行校验，得到校验结果；
当所述校验结果为所述待交易数量合法时，确定并发送第一响应至所述第一终端，所述第一响应中携带有基于所述第一请求生成的待支付的订单信息。
2.根据权利要求1所述的方法，其特征在于，所述根据所述第一标识和所述第二标识确定所述待交易对象的状态，包括：
根据所述第一标识和所述第二标识，确定所述待交易对象的限购条件，所述限购条件至少包括限购时段和限购数量；
获取接收到所述第一请求的时刻；
当接收到所述第一请求的时刻在所述限购时段内，将所述待交易对象的状态确定为限购状态；
当接收到所述第一请求的时刻不在所述限购时段内，将所述待交易对象的状态确定为正常状态。
3.根据权利要求2所述的方法，其特征在于，所述根据所述第一标识和所述第二标识，确定所述待交易对象的限购条件，包括：
根据所述第二标识，获取所述待交易对象的限购配置信息，所述限购配置信息为销售方在第二终端的配置界面上输入的信息；
根据所述限购配置信息，生成所述待交易对象的限购规则，所述限购规则包括至少一个限购类型、各限购类型的限购时段和各限购类型的限购总量；
根据所述第一标识，确定所述订购方所属的至少一个目标限购类型；
根据各个目标限购类型的限购时段和限购总量，确定所述待交易对象针对所述订购方的限购条件。
4.根据权利要求2所述的方法，其特征在于，所述根据所述第一标识和所述第二标识对所述待交易数量的合法性进行校验，得到校验结果，包括：
根据所述第一标识和所述待交易对象的限购条件，确定所述订购方的限购数量；
根据所述第一标识和所述第二标识，查询所述待交易对象的历史交易记录，获取所述订购方在所述限购时段内的历史交易数量；
根据所述限购数量和所述历史交易数量，确定剩余限购数量；
基于所述剩余限购数量，对所述待交易数量的合法性进行校验，得到校验结果。
5.根据权利要求4所述的方法，其特征在于，所述基于所述剩余限购数量，对所述待交易数量的合法性进行校验，得到校验结果，包括：
判断所述待交易数量是否小于或等于所述剩余限购数量；
当所述待交易数量小于或等于所述剩余限购数量时，获取所述待交易对象的剩余库存量；
判断所述待交易数量是否小于或等于所述剩余库存量；
当所述待交易数量小于或等于所述剩余库存量时，将所述校验结果确定为所述待交易数量合法；
当所述待交易数量大于所述剩余限购数量，或所述待交易数量大于所述剩余库存量时，将所述校验结果确定为待交易数量不合法。
6.根据权利要求5所述的方法，其特征在于，所述方法还包括：
接收所述第一终端发送的用于支付订单的第二请求，所述第二请求中携带有支付金额、支付时间和所述订单信息包括的订单号；
基于所述待支付的订单信息对所述支付金额进行验证，得到第一验证结果；
在所述第一验证结果表征验证通过时，确定并发送第二响应至所述第一终端，所述第二响应中携带有表征交易成功的提示信息；
对所述剩余限购数量进行更新，得到更新后的剩余限购数量。
7.根据权利要求6所述的方法，其特征在于，所述方法还包括：
接收所述第一终端发送的用于退回所述待交易对象的第三请求，所述第三请求中携带有待退回的订单信息；
基于已支付的订单信息对所述待退回的订单信息进行验证，得到第二验证结果；
在所述第二验证结果表征验证通过时，确定并发送第三响应至所述第一终端，所述第三响应中携带有表征退回成功的提示信息；
对所述更新后的剩余限购数量进行更新，得到再次更新后的剩余限购数量。
8.一种信息处理装置，其特征在于，所述装置包括：
第一接收模块，用于接收第一终端发送的用于生成订单的第一请求，所述第一请求中携带有订购方的第一标识、待交易对象的第二标识和待交易数量，所述订购方为门店用户；
第一确定模块，用于根据所述第一标识和所述第二标识确定所述待交易对象的状态，所述待交易对象的状态包括限购状态和正常状态；
校验模块，用于当所述待交易对象的状态为限购状态时，根据所述第一标识和所述第二标识对所述待交易数量的合法性进行校验，得到校验结果；
第二确定模块，用于当所述校验结果为所述待交易数量合法时，确定第一响应，所述第一响应中携带有基于所述第一请求生成的待支付的订单信息；
第一发送模块，用于发送所述第一响应至所述第一终端。
9.一种信息处理设备，其特征在于，包括：
处理器；以及
存储器，用于存储可在所述处理器上运行的计算机程序；
其中，所述计算机程序被处理器执行时实现权利要求1至7任一项所述方法的步骤。
10.一种计算机可读存储介质，其特征在于，存储有计算机可执行指令，所述计算机可执行指令配置为执行权利要求1至7任一项所述方法的步骤。
CN202111173144.3A 2021-10-08 2021-10-08 一种信息处理方法、装置、设备及计算机可读存储介质 Pending CN113902474A (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202111173144.3A CN113902474A (zh) 2021-10-08 2021-10-08 一种信息处理方法、装置、设备及计算机可读存储介质
PCT/CN2022/107696 WO2023056771A1 (zh) 2021-10-08 2022-07-25 一种信息处理方法、装置、设备及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111173144.3A CN113902474A (zh) 2021-10-08 2021-10-08 一种信息处理方法、装置、设备及计算机可读存储介质

Publications (1)

Publication Number Publication Date
CN113902474A true CN113902474A (zh) 2022-01-07

Family

ID=79190769

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111173144.3A Pending CN113902474A (zh) 2021-10-08 2021-10-08 一种信息处理方法、装置、设备及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN113902474A (zh)
WO (1) WO2023056771A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023056771A1 (zh) * 2021-10-08 2023-04-13 北京沃东天骏信息技术有限公司 一种信息处理方法、装置、设备及计算机可读存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116361016B (zh) * 2023-06-01 2023-10-13 天翼云科技有限公司 一种网络控制器消息处理方法、系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106651527A (zh) * 2016-12-29 2017-05-10 江西博瑞彤芸科技有限公司 多进程的订单信息处理方法
CN109214866A (zh) * 2018-08-31 2019-01-15 深圳春沐源控股有限公司 商品优惠促销管理方法及装置、计算机设备、存储介质
CN112132650A (zh) * 2020-09-02 2020-12-25 绿瘦健康产业集团有限公司 一种在线购物校验方法、装置、介质及终端设备
CN112801641A (zh) * 2021-02-05 2021-05-14 广州聚汇信息技术有限公司 支付网关限购控制方法及其装置、设备与介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001306895A (ja) * 2000-04-21 2001-11-02 Nec Corp 宅配サービスシステム
JP5974712B2 (ja) * 2012-07-31 2016-08-23 キヤノンマーケティングジャパン株式会社 情報処理装置、情報処理方法、プログラム
CN107424041A (zh) * 2017-05-25 2017-12-01 周睿 农产品联产分销与联展联销电商平台
CN107230034A (zh) * 2017-06-28 2017-10-03 北京惠赢天下网络技术有限公司 一种关联下单方法及装置
CN110070323A (zh) * 2019-03-25 2019-07-30 北京蒙成科技有限公司 一种库存扣减方法、装置及订单服务器
CN113902474A (zh) * 2021-10-08 2022-01-07 北京沃东天骏信息技术有限公司 一种信息处理方法、装置、设备及计算机可读存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106651527A (zh) * 2016-12-29 2017-05-10 江西博瑞彤芸科技有限公司 多进程的订单信息处理方法
CN109214866A (zh) * 2018-08-31 2019-01-15 深圳春沐源控股有限公司 商品优惠促销管理方法及装置、计算机设备、存储介质
CN112132650A (zh) * 2020-09-02 2020-12-25 绿瘦健康产业集团有限公司 一种在线购物校验方法、装置、介质及终端设备
CN112801641A (zh) * 2021-02-05 2021-05-14 广州聚汇信息技术有限公司 支付网关限购控制方法及其装置、设备与介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023056771A1 (zh) * 2021-10-08 2023-04-13 北京沃东天骏信息技术有限公司 一种信息处理方法、装置、设备及计算机可读存储介质

Also Published As

Publication number Publication date
WO2023056771A1 (zh) 2023-04-13

Similar Documents

Publication Publication Date Title
US20200151683A1 (en) Processing network architecture with companion database
US11430048B2 (en) Optimistic product order reservation system and method
US8135642B1 (en) Resilient messaging system and method
WO2023056771A1 (zh) 一种信息处理方法、装置、设备及计算机可读存储介质
US11907985B2 (en) Network, method, and non-transitory computer-readable medium for certification of vendors using distributed ledger technology
CN113312527B (zh) 采购数据处理方法、装置、计算机设备和存储介质
CN111353841B (zh) 单据数据处理方法、装置及系统
CN110766514A (zh) 用于电商平台的最优货源筛选方法及装置
CN115705560B (zh) 用于处理模板改变的消息映射方法和系统
CN106651527A (zh) 多进程的订单信息处理方法
US20240127316A1 (en) Order management systems and methods
CN111091439A (zh) 订单关联营销活动实现方法、系统、设备及存储介质
CN112990871A (zh) 一种单据处理方法及相关设备
US20140244484A1 (en) Network computing environment collection and notification of point of sale information
US20160275535A1 (en) Centralized system for progressive price management
CN115760300A (zh) 一种基于标签管理销售品的实现方法及系统
US20140244432A1 (en) E-Commerce System with Personal Price Points
CN114022064A (zh) 一种基于交易链路的关联交易订单管理方法、装置及设备
Lee et al. Design an online shopping store based on opencart
CN104899715B (zh) 一种信息处理方法、客户端及信息处理平台
CN110717810A (zh) 实时交易方法、装置、设备及计算机可读存储介质
US20020198783A1 (en) Business method for credit card email alerts
CN118735643A (zh) 单据处理方法、装置、计算机设备、可读存储介质和程序产品
CN118761695A (zh) 处理订单数据的方法、装置、电子设备和计算机可读介质
CN117827843A (zh) 索引路由方法及其装置、设备、介质

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