WO2021051775A1 - 基于多人点单的订单管理方法及*** - Google Patents

基于多人点单的订单管理方法及*** Download PDF

Info

Publication number
WO2021051775A1
WO2021051775A1 PCT/CN2020/082158 CN2020082158W WO2021051775A1 WO 2021051775 A1 WO2021051775 A1 WO 2021051775A1 CN 2020082158 W CN2020082158 W CN 2020082158W WO 2021051775 A1 WO2021051775 A1 WO 2021051775A1
Authority
WO
WIPO (PCT)
Prior art keywords
order
payment
user
business
data record
Prior art date
Application number
PCT/CN2020/082158
Other languages
English (en)
French (fr)
Inventor
韩丰磊
Original Assignee
口碑(上海)信息技术有限公司
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 口碑(上海)信息技术有限公司 filed Critical 口碑(上海)信息技术有限公司
Priority to US17/760,763 priority Critical patent/US20220343398A1/en
Publication of WO2021051775A1 publication Critical patent/WO2021051775A1/zh

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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • 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
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/12—Hotels or restaurants

Definitions

  • the present disclosure relates to the field of electronic information, and in particular to an order management method and system based on multi-person ordering.
  • a system for everyone to order meals is disclosed.
  • the system is first logged in by the initiator. After entering the system, the initiator searches for restaurant information and selects the restaurant. , And then the initiator initiates an order and selects a member group chat to invite friends to order together. Through the member group chat function, the demand for multiple people to order meals at the same time is realized.
  • the inventor found that the above-mentioned methods in the prior art have at least the following defects: in the above-mentioned methods, although multiple users can participate in ordering, for the order backstage, only The order is recognized based on the information of the order initiator, and the order cannot be recognized based on the information of other order users. Correspondingly, only the order initiator has the authority to pay and manage the order, and other users participating in the order do not have the authority to manage the order, which causes inconvenience in order management in the multi-person ordering scenario.
  • the present disclosure is proposed to provide an order management method and system based on multi-person ordering that overcomes the above-mentioned problems or at least partially solves the above-mentioned problems.
  • an order management method based on multi-person ordering including:
  • the order data record is created according to the service device identification and user identification included in each order service request received;
  • the order payment data is respectively added to the user history payment record corresponding to each user identification; among them, the order identification code of the order data record contains the business equipment identification and Multiple user IDs associated with service device IDs;
  • an order management method based on multi-person ordering including:
  • the receiving server generates user historical payment records based on the order data record containing the user identification in the order identification code
  • an order management system based on multi-person ordering including:
  • the obtaining module is adapted to obtain the order payment data corresponding to the pre-created order data record; wherein, the order data record is created according to the service device identification and user identification contained in each received order service request;
  • the payment record adding module is adapted to add the order payment data to the user history payment record corresponding to each user identification according to the user identification contained in the order identification code of the order data record; among them, the order identification of the order data record
  • the code contains the service device identification and multiple user identifications associated with the service device identification;
  • the sending module is adapted to send the user historical payment records corresponding to each user identifier to the user terminal corresponding to each user identifier, so that each user terminal can manage the order according to the order payment data contained in the user historical payment record. Entry management order data records.
  • an order management terminal based on multi-person ordering including:
  • the query module is adapted to send an order query request containing the user ID to the server;
  • the receiving module is adapted to receive the user historical payment records generated by the server according to the order data record containing the user identification in the order identification code;
  • the display module is adapted to display the user's historical payment records to perform order management according to the user's historical payment records.
  • an electronic device including: a processor, a memory, a communication interface, and a communication bus.
  • the processor, the memory, and the communication interface communicate with each other through the communication bus;
  • the memory is used to store at least one executable instruction, and the executable instruction causes the processor to perform operations corresponding to the above-mentioned order management method based on multi-person ordering.
  • non-volatile computer-readable storage medium stores at least one executable instruction, and the executable instruction causes a processor to execute as described above The corresponding operation of the order management method based on multi-person ordering.
  • a computer program product includes a computer program stored on a non-volatile computer storage medium.
  • the order management method and system based on multi-person ordering provided by the present disclosure, after obtaining the order payment data corresponding to the pre-created order data record, according to each user identification contained in the order identification code of the order data record, respectively The order payment data is added to the user historical payment record corresponding to each user identification, so that each user terminal can manage the order data record according to the order management portal associated with the order payment data contained in the user historical payment record.
  • the order identification code of the order data record contains the service device ID and multiple user IDs associated with the service device ID.
  • an order can be uniquely identified based on the service device ID, and according to The multiple user IDs associated with the service device ID enable each user's historical payment record to include corresponding order payment data, thereby ensuring that each ordering user has the authority to manage the order, which improves the flexibility of order management.
  • FIG. 1 shows a flowchart of an order management method based on multi-person ordering provided by Embodiment 1 of the present disclosure
  • FIG. 2 shows a flowchart of an order management method based on multi-person ordering provided by the second embodiment of the present disclosure
  • FIG. 3 shows a structural diagram of an order management system based on multi-person ordering provided by the third embodiment of the present disclosure
  • FIG. 4 shows a schematic structural diagram of an electronic device according to the fifth embodiment of the present disclosure.
  • Fig. 1 shows a flow chart of an order management method based on multi-person ordering provided by Embodiment 1 of the present disclosure. As shown in Figure 1, the method includes:
  • Step S110 Obtain the order payment data corresponding to the pre-created order data record; where the order data record is created according to the service device identification and the user identification included in each received order service request.
  • order data record is used to record the relevant information of each business link of an order from the start of the order operation to the completion of the order payment.
  • Order payment data refers to the data related to the payment process generated after the order payment corresponding to the order data record is completed, including the payment user, payment amount, payment method, payment time, business item details, etc.
  • an order data record corresponding to the service equipment identifier is created in advance according to the service equipment identification and user identification contained in each received order service request; wherein the order identification code of the order data record contains the service equipment identification And multiple user IDs associated with the service device ID.
  • the order service request is used to implement the order operation, which can be sent in various ways such as scanning codes.
  • the order service request includes the service device ID and the user ID.
  • the business equipment identification refers to the identification of the business equipment used to provide this business service.
  • the business equipment can be an electronic device, or can be various types of equipment such as a business desk and a business room.
  • User ID refers to the ID of the user who sent this order service request, such as the user account.
  • multiple user identifiers corresponding to the same service device identifier are associated together, and then the corresponding order data record is established.
  • the record can be identified by the service device identification.
  • Step S120 According to each user identifier contained in the order identification code of the order data record, the order payment data is respectively added to the user history payment record corresponding to each user identifier; wherein, the order identification code of the order data record contains business The device ID and multiple user IDs associated with the service device ID.
  • each user identification included in the order identification code of the order data record is queried, and the order payment data is respectively added to the user historical payment record corresponding to each user identification.
  • Each user corresponds to a historical payment record of the user, and the historical payment record of the user is used to describe the payment record of the user in the historical period.
  • Each payment record is used to describe the payment details of an order.
  • Each user can query each order that has been paid through the user's historical payment record.
  • Step S130 Send the user historical payment record corresponding to each user identifier to the user terminal corresponding to each user identifier, so that each user terminal can manage the order management portal associated with the order payment data contained in the user historical payment record Order data record.
  • the user history payment records received by each user terminal include an order management entry associated with the order payment data, and the order data record corresponding to the order payment data can be managed through the order management entry.
  • the order management portal may be a query portal, a refund portal, an evaluation portal, and other portals, which are not limited in the present disclosure.
  • the order identification code of the order data record contains the service device ID and multiple user IDs associated with the service device ID. Accordingly, an order can be uniquely identified based on the service device ID, and according to The multiple user IDs associated with the service device ID enable each user's historical payment record to include corresponding order payment data, thereby ensuring that each ordering user has the authority to manage the order, which improves the flexibility of order management.
  • Fig. 2 shows a flowchart of an order management method based on multi-person ordering provided by the second embodiment of the present disclosure. As shown in Figure 2, the method includes:
  • Step S200 Create an order data record corresponding to the service device ID according to the service device ID and user ID contained in each received order service request; wherein, the order ID code of the order data record includes the service device ID and Multiple user IDs associated with service device IDs.
  • the service device identification and user identification included in the order service request received this time are obtained, and it is determined whether there is any information related to the service device identification in the preset billing data table. If it is, obtain the created order data record corresponding to the business equipment ID and the effective billing ID, and add the user ID contained in the order service request received this time to the order data record In the order identification code; if not, generate a valid billing identification associated with the business equipment identification and store the business equipment identification and effective billing identification in the billing data table in association with the business equipment identification and effective billing identification
  • the corresponding order data record, and the order identification code of the order data record contains the service equipment identification, the effective billing identification, and the user identification included in the order service request received this time.
  • the order service request is used to implement the order operation, which can be sent in various ways such as scanning codes.
  • an information code in the form of a QR code or the like is set on the service device, and the QR code contains the service device identifier.
  • the order service request is a QR code-based scanning point Single request.
  • the order service request includes the service device identification and the user identification.
  • the business equipment identification refers to the identification of the business equipment used to provide this business service.
  • the business equipment can be an electronic device, or can be various types of equipment such as a business desk and a business room.
  • User ID refers to the ID of the user who sent this order service request, such as the user account.
  • each time an order service request is received it is determined whether the corresponding service device has executed the billing process according to the service device identifier contained therein.
  • the billing processing refers to: an existing business user has performed an order operation for the business device, that is, the business device has changed from an idle state to a non-idle state. Specifically, the judgment is made based on whether there is a valid billing identifier associated with the service device identifier in the preset billing data table.
  • the billing data table is used to store the valid billing identifiers corresponding to the identifiers of each service device, and the valid billing identifiers can identify that each service device is in an idle or non-idle state.
  • the billing data table is used to store billing flow data. Accordingly, according to the billing flow data record, the billing serial number associated with the service device identifier is generated, and the billing serial number is used as the valid billing identification. Since the billing serial number contains time stamp information, it can accurately identify whether a business device is currently idle.
  • the created order data record corresponding to the service equipment ID and the valid billing ID is obtained, and the user ID contained in the order service request received this time is added to the order ID code of the order data record. In this way, the number of service users associated with the service device identifier can be expanded, so that the order data record corresponding to the service device identifier contains the user identifiers of multiple service users.
  • the order identification code created in the present disclosure includes: a first field for storing business device identification, a second field for storing valid billing identification, and a third field for storing user identification; among them,
  • the third field further includes a plurality of subfields respectively corresponding to different user IDs, and each user ID corresponds to each received order service request.
  • multiple order users can be associated according to the service device identifier, thereby creating an order data record based on the service device identifier.
  • an order data record is used to store the business records of each business link of an order from creation to payment.
  • Step S210 Perform a multi-person ordering operation according to the created order data record.
  • the service item data associated with the service device ID is pushed to the user terminal corresponding to the user ID contained in the order service request received this time, so that the user terminal triggers the service item data after receiving the order service request.
  • the business item included in the business item addition request is added to the business item field included in the order data record. That is, according to the received business item addition request triggered for the order data record, the business item corresponding to the business item addition request is added to the business item field included in the order data record.
  • the business item field is used to record the name and quantity of each business item corresponding to the order data record, so as to provide the user with business services based on the business item field.
  • the business item data may be meal data of a restaurant for the user to choose. It can be seen that, whenever an order service request is received, based on the service device identifier contained in the order service request, the service item data corresponding to the service device identifier is pushed to the corresponding order user, which can be specifically passed Query a preset business item database, which is used to store the mapping relationship between each business device and its corresponding business item.
  • a preset business item database which is used to store the mapping relationship between each business device and its corresponding business item.
  • the backend server when the backend server receives the business item addition request, it determines the order data record corresponding to the business item addition request according to the business device identifier contained therein, and then records the business item in the business item addition request to the order In the business item field of the data record. It can be seen that multiple different business users can trigger a business item addition request for the same business device. Accordingly, the background server summarizes the business items in the business item addition request triggered by different business users for the same business device to the corresponding In the business item field of the order data record, so as to achieve the effect of multiple people ordering at the same time.
  • Step S220 When an order submission request triggered for the order data record is received, a payment order corresponding to the order data record is generated.
  • any one of the multiple ordering users initiates an order submission request.
  • the payment order corresponding to the order data record is generated according to each business item added in the business item field contained in the order data record.
  • the order amount is determined according to the number of each business item added in the business item field and the business resource cost corresponding to the business item.
  • the service item addition request triggered for the order data record includes a plurality of service item addition requests respectively sent by the user terminal corresponding to each user identifier contained in the order identification code of the order data record.
  • the order data record is used to store the business records of each business link such as the creation of an order, the addition of business items, and the payment. That is: the order data record is used to centrally store the information of each business link and each business level of the order to fully describe the status of an order.
  • the payment order is an order dedicated to fulfilling the payment function derived from the order data record.
  • the payment order and its corresponding order data record are associated with the order identification code. Since the payment order is independent of the order data record and can be copied into multiple copies, the present disclosure realizes the effect that multiple users have the authority to pay by separating the order data record from the payment order.
  • Step S230 Push the payment order to each user terminal corresponding to the user identification included in the order identification code of the order data record for the user terminal to make payment.
  • the payment process can be realized in at least two of the following two ways:
  • one of multiple users independently completes the order payment. Specifically, according to the number of user identifications contained in the order identification code recorded in the order data, the payment order is copied into multiple copies, and each copied payment order is pushed to each order identification code recorded in the order data.
  • each user identifier contained in the order identification code of the order data record is queried. According to the query result, the payment order is respectively pushed to the user terminal corresponding to each user identification included in the order identification code of the order data record.
  • the payment order is used to realize the order payment function, which contains information such as the details of the business item to be paid, the payment amount, and the payment entry element.
  • This method enables each user who participates in the order to receive the corresponding payment order.
  • each order user who receives a payment order can trigger a payment request for the received payment order.
  • the payment request can be triggered through the payment entry element included in the payment order.
  • the background server pays for the payment order according to the received payment request triggered for the payment order.
  • the paying user matches the order to be paid: determine whether the user ID and the payment order included in the received payment request for the payment order Whether the order identification code of the corresponding order data record matches; if so, the payment order is paid according to the payment request. For example, when the user identification contained in the received payment request for a payment order matches one of the multiple user identifications stored in the order identification code of the order data record corresponding to the payment order, it indicates that the paying user and the payment order Match, so as to make a payment; otherwise, it means that the paying user does not match the payment order, and prompts the user to verify the payment order.
  • the payment order is specifically realized in the following way: when the payment request triggered for the payment order is received, according to the order data corresponding to the payment order.
  • the business status field contained in the record determines whether the payment order corresponding to the order data record has been paid; if not, the payment order is paid according to the received payment request triggered by the payment order, and the payment is updated and paid according to the payment result
  • the business status field contained in the order data record corresponding to the order if it is, the payment request is rejected, and the payment notification is pushed to the user terminal corresponding to the payment request.
  • the order data record further contains a business status field, which is used to indicate whether the business resource corresponding to the order has been received. Accordingly, by querying the value of the business status field, repeated payments can be prevented, thereby ensuring Only one user among multiple users can successfully pay. Through the above method, any one of the multiple order users can complete the order payment process.
  • a notification message containing the amount to be paid can be automatically sent to the remaining unpaid users to guide the remaining unpaid users to complete the payment, and then transfer the payment amount of each unpaid user to the paid user In order to achieve the purpose of apportioning business resources among various ordering users.
  • This method is especially suitable for business scenarios where multiple people order meals.
  • the payment order is split into multiple payment sub-orders, and the sum of the order amount of each payment sub-order matches the order amount of the payment order;
  • Each payment sub-order is pushed to the user terminal corresponding to each user identifier contained in the order identification code of the order data record; the payment order is paid according to the received payment request triggered for the payment order.
  • This method can split the payment order into multiple payment sub-orders for multiple ordering users to pay separately, thereby facilitating multiple ordering users to share the cost of business resources. During the specific splitting, it can be achieved in a variety of ways, which is not limited in the present disclosure.
  • the payment order is split into N payment sub-orders, and the order amount of each payment sub-order is equal ;
  • N is a natural number. For example, if the total amount of the payment order is 100 and N is 4, then the amount of each payment sub-order after the split is 25.
  • the second splitting method when the number of user IDs contained in the order identification code of the order data record is N, for each user ID contained in the order identification code of the order data record, the user ID is obtained.
  • Corresponding user attribute information select M user identifiers from the N user identifiers as the user identifier of the target payment user; split the payment order into M corresponding to each target payment
  • the payment sub-order of the user according to the user attribute information of each target payment user, determines the order amount of the payment sub-order corresponding to each target payment user, and records each target payment user and the sub-order of the corresponding payment sub-order in the order data record Correspondence between the logo and the order amount.
  • N and M are natural numbers, and M is less than or equal to N.
  • the user attribute information includes: order record information, historical payment information, user level information, etc.
  • users with order times greater than the preset order threshold, historical payment amount greater than the preset payment amount, and/or user level higher than the preset level can be selected as target payment users user.
  • the order amount of the payment sub-order corresponding to each target payment user can also be determined according to user attribute information. For example, the order amount of the payment sub-order corresponding to a user with a higher historical payment amount is higher than that of a lower historical payment amount. The order amount of the payment sub-order corresponding to the user.
  • the payment order is split into multiple payment sub-orders, only when each payment sub-order is paid, the corresponding payment order is in the paid state.
  • the order data record further includes a business status field, which is used to indicate whether the business resource corresponding to the order has arrived. Accordingly, by querying the value of the business status field, the phenomenon of repeated order payment can be prevented, and Can quickly determine whether the order has been paid.
  • the business status field of the order data record may further include a plurality of sub-fields respectively corresponding to each payment sub-order for recording whether the corresponding payment sub-order has been paid.
  • Step S240 When the payment request triggered for the payment order is received, the order payment data corresponding to the order data record is generated according to the user identification included in the payment request.
  • the payment process is completed according to the payment request, and the order payment data corresponding to the order data record is generated according to the user identification included in the payment request.
  • the payment request corresponds to the request of the entire payment order. Accordingly, the order payment data is used to record the user identification of the user who paid the order and the total payment order. Information such as amount and payment time.
  • the payment request triggered for the payment order includes multiple sub-order payment requests respectively corresponding to different payment sub-orders.
  • the payment completion status of the payment sub-order records the sub-order payment data corresponding to the payment sub-order, and accordingly, the order payment data corresponding to the order data record includes : Sub-order payment data corresponding to each payment sub-order.
  • Step S250 Obtain the order payment data corresponding to the order data record, and add the order payment data to the user historical payment records corresponding to each user identifier according to each user identifier contained in the order identification code of the order data record.
  • the order payment data is directly copied into multiple copies, and they are respectively added to the user historical payment records corresponding to each user identification.
  • the order payment data containing the payment data of each sub-order can be copied into multiple copies and added to the user history payment records corresponding to each user ID, so that each order Users can view the payment amount of each user.
  • each sub-order payment data can also be added to the user history payment record of the ordering user corresponding to the sub-order payment data, and the present disclosure does not limit the specific implementation manner.
  • Step S260 Send the user historical payment record corresponding to each user identifier to the user terminal corresponding to each user identifier, so that each user terminal can manage the order management portal associated with the order payment data contained in the user historical payment record Order data record.
  • each user corresponds to a user historical payment record to record the user's historical payment situation. Accordingly, each user can determine each order payment data within a preset historical period by querying his own user historical payment record.
  • Each order payment data corresponds to an order, and each order payment data has an associated order management entry for the user to manage the order.
  • order management portals associated with the order payment data, for example, including: business item query portals, business resource management portals, business status query portals, and/or business evaluation portals.
  • the order data record further includes: a business item field used to store each business item contained in the order data record, a business resource field used to store business resource information of the order data record, and a business resource field used to store the order data record.
  • the business status field of the status information; the business item query entry is used to query based on the business item field contained in the order data record, and the business resource management entry is used to manage the business resource field contained in the order data record, and the business status query The entry is used to query based on the business status field contained in the order data record.
  • the business item query portal is used to query multiple business items contained in the order data record.
  • the multiple business items contained in the order data record are the various meals selected by the user when ordering. item.
  • the business resource management portal is used to query and manage the business resources corresponding to the order data record.
  • the business resource mainly refers to the order payment amount. Accordingly, the business resource management portal can not only query the order The payment amount can also be used to initiate refunds for the order.
  • the business status query portal can query the logistics status and delivery status of the items corresponding to the order.
  • the order pre-paid refers to: After receiving the order submission request, generate a corresponding business order according to the order submission request, and push the business order to the service provider, so that the service provider can provide business services according to the business order.
  • Post-order payment refers to: after receiving the order submission request, generate a payment order corresponding to the order data record, and only generate the corresponding business order when the status of the payment order is detected to be updated to paid, and the business order Push to the service provider so that the service provider can provide business services based on business orders.
  • the order can be identified by the service device identifier, thereby facilitating the association of multiple order users corresponding to the same service device identifier.
  • the order identification code in this embodiment includes at least the service equipment identification and the user identifications of multiple order users associated with the service equipment identification.
  • the payment order generated according to the order data record also contains the order identification code, and
  • the payment request triggered for the payment order also includes the order identification code of the order data record corresponding to the payment order to be paid. It can be seen that the order identification code in this embodiment runs through each business link of the order. Therefore, through the business equipment identification and multiple user identifications recorded in the order identification code, it can be ensured that multiple users can target the order.
  • the order is paid.
  • the present disclosure can push the payment order to each ordering user respectively, so that each ordering user has the authority to pay.
  • the present disclosure can spread the payment order into multiple copies and provide them to each ordering user separately, so that each ordering user can follow the order payment data contained in the user's historical payment record.
  • the order management portal manages order data records. Among them, the order management portal can also include multiple types such as evaluation portals, consumption record portals and query portals.
  • another embodiment of the present disclosure also provides an order management method based on multi-person ordering, which is applied to the user terminal side, including:
  • Step 1 Send an order query request containing the user ID to the server.
  • Step 2 Receive the user historical payment record generated by the server according to the order data record containing the user identification in the order identification code.
  • Step 3 Display the user's historical payment records to manage orders based on the user's historical payment records.
  • the user historical payment record includes: order payment data corresponding to the order data record containing the user identification in the order identification code; then the displayed user historical payment record includes:
  • the order management portal used to manage the order payment data on the payment record query page it further includes:
  • the order management portal used to manage the order payment data includes: a business item query portal, a business resource management portal, a business status query portal, and/or a business evaluation portal.
  • the order data record further includes: a business item field used to store each business item contained in the order data record, a business resource field used to store business resource information of the order data record, and a business resource field used to store the order data record.
  • the business status field of the business status information; the business item query entry is used to query based on the business item field contained in the order data record, and the business resource management entry is used to manage the business resource field contained in the order data record, and the business status The query entry is used to query based on the business status field contained in the order data record.
  • the order identification code of the order data record includes a service device ID and multiple user IDs associated with the service device ID.
  • the method before sending the order query request containing the user ID to the server, the method further includes:
  • the payment order contains a payment entry for each user who receives the payment order to make payment; and, the order payment data of the user's historical payment record It further contains the payment user identification.
  • the user terminal corresponding to each user identification contained in the order identification code will receive the payment order and have the authority to make the payment.
  • the server The payment user identification will be recorded, and then the payment user identification will be included in the order payment data. Accordingly, the user corresponding to each user identification contained in the order identification code can query the order in their historical payment records, and The paying user who can view the order.
  • FIG. 3 shows a schematic structural diagram of an order management system based on multi-person ordering provided by Embodiment 3 of the present disclosure, and the system includes:
  • the obtaining module 31 is adapted to obtain the order payment data corresponding to the pre-created order data record; wherein the order data record is created according to the service equipment identification and the user identification contained in each received order service request;
  • the payment record adding module 32 is adapted to add the order payment data to the user history payment records corresponding to each user identification according to each user identification contained in the order identification code recorded in the order data; where the order data recorded in the order data
  • the identification code includes a service device ID and multiple user IDs associated with the service device ID;
  • the sending module 33 is adapted to send the user history payment records corresponding to each user identification to the user terminal corresponding to each user identification, so that each user terminal can use the order payment data associated with the order contained in the user history payment record.
  • the management portal manages order data records.
  • the payment record adding module is specifically adapted to:
  • Each copy of the order payment data is respectively added to the user history payment record corresponding to each user identification; where N is a natural number.
  • the order management portal associated with the order payment data includes:
  • Business item query entry business resource management entry, business status query entry, and/or business evaluation entry.
  • the order data record further includes:
  • the business resource field used to store the business resource information of the order data record
  • the business state field used to store the business state information of the order data record
  • the business item query entry is used to query based on the business item field contained in the order data record
  • the business resource management entry is used to manage the business resource field contained in the order data record
  • the business status query entry is used to record based on the order data.
  • system further includes:
  • the order generation module is suitable for obtaining the business equipment identification and user identification contained in the order business request received this time whenever an order business request is received, and judging whether there is a business equipment in the preset billing data table. Identify the valid billing identification associated with the identification;
  • the order identification code of the order data record contains the service equipment identification, the effective billing identification, and the user identification included in the order service request received this time.
  • the order generation module is further adapted to:
  • the business item corresponding to the business item addition request is added to the business item field contained in the order data record;
  • a payment order corresponding to the order data record is generated according to each business item added in the business item field included in the order data record.
  • the service item addition request triggered by the order data record includes: a plurality of service item addition requests sent by the user terminal corresponding to each user identifier contained in a plurality of order identification codes respectively recorded by the order data.
  • the acquisition module is specifically adapted to:
  • the order payment data corresponding to the order data record is generated according to the user identification included in the payment request.
  • the order service request includes: a QR code-based scanning order request, and the QR code includes the service device identifier.
  • the terminal can be various electronic devices such as mobile phones, and specifically includes:
  • the query module is adapted to send an order query request containing the user ID to the server;
  • the receiving module is adapted to receive the user historical payment records generated by the server according to the order data record containing the user identification in the order identification code;
  • the display module is adapted to display the user's historical payment records to perform order management according to the user's historical payment records.
  • the user history payment record includes: order payment data corresponding to the order data record containing the user identification in the order identification code; then the display module is specifically adapted to:
  • the display module is further adapted to:
  • the order management portal used to manage the order payment data includes: a business item query portal, a business resource management portal, a business status query portal, and/or a business evaluation portal.
  • the order data record further includes: a business item field used to store each business item contained in the order data record, a business resource field used to store business resource information of the order data record, and a business resource field used to store the order data record.
  • the business status field of the business status information is not limited to:
  • the business item query entry is used to query based on the business item field contained in the order data record
  • the business resource management entry is used to manage the business resource field contained in the order data record
  • the business status query entry is used to record based on the order data.
  • the device further includes:
  • the order module is suitable for sending an order service request including a service device ID and a user ID, so that the server can create a service device ID corresponding to the service device ID according to the service device ID and user ID contained in each received order service request Order data record; where the order identification code of the order data record contains a service device ID and multiple user IDs associated with the service device ID.
  • the order module is further adapted to:
  • the cloud server Receiving the payment order corresponding to the pre-created order data record sent by the cloud server; wherein the payment order includes a payment entry for each user who receives the payment order to make payment;
  • order payment data of the user's historical payment record further includes the payment user identification.
  • the fourth embodiment of the present disclosure provides a non-volatile computer-readable storage medium.
  • the non-volatile computer-readable storage medium stores at least one executable instruction.
  • the computer-executable instruction can execute any of the foregoing method embodiments.
  • An order management method based on multi-person ordering.
  • the executable instructions may be specifically used to make the processor execute the corresponding operations in the foregoing method embodiments.
  • FIG. 4 shows a schematic structural diagram of an electronic device according to the fifth embodiment of the present disclosure, and the specific embodiment of the present disclosure does not limit the specific implementation of the electronic device.
  • the electronic device may include: a processor (processor) 402, a communication interface (Communications Interface) 406, a memory (memory) 404, and a communication bus 408.
  • processor processor
  • Communication interface Communication Interface
  • memory memory
  • communication bus 408 a communication bus
  • the processor 402, the communication interface 406, and the memory 404 communicate with each other through the communication bus 408.
  • the communication interface 406 is used to communicate with other devices such as network elements such as clients or other servers.
  • the processor 402 is configured to execute the program 410, and specifically can execute the relevant steps in the above-mentioned embodiment of the order management method based on multi-person ordering.
  • the program 410 may include program code, and the program code includes computer operation instructions.
  • the processor 402 may be a central processing unit CPU, or an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present disclosure.
  • the one or more processors included in the electronic device may be the same type of processor, such as one or more CPUs, or different types of processors, such as one or more CPUs and one or more ASICs.
  • the memory 404 is used to store the program 410.
  • the memory 404 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), for example, at least one disk memory.
  • the program 510 may be specifically used to enable the processor 502 to perform corresponding operations in the foregoing method embodiments.
  • modules or units or components in the embodiments can be combined into one module or unit or component, and in addition, they can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and/or processes or units are mutually exclusive, any combination can be used to compare all the features disclosed in this specification (including the accompanying claims, abstract and drawings) and any method or methods disclosed in this manner or All the processes or units of the equipment are combined. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.
  • the various component embodiments of the present disclosure may be implemented by hardware, or by software modules running on one or more processors, or by a combination of them.
  • a microprocessor or a digital signal processor (DSP) may be used in practice to implement some or all of the functions of some or all of the components in the voice input information-based lottery system according to the embodiments of the present disclosure.
  • DSP digital signal processor
  • the present disclosure can also be implemented as a device or device program (for example, a computer program and a computer program product) for executing part or all of the methods described herein.
  • Such a program for realizing the present disclosure may be stored on a computer-readable medium, or may have the form of one or more signals.
  • Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Tourism & Hospitality (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种基于多人点单的订单管理方法及***，涉及电子信息领域。该订单管理方法包括：获取与订单数据记录相对应的订单支付数据；其中，订单数据记录根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建；根据订单数据记录的订单标识码中包含的各个用户标识，分别将订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，订单数据记录的订单标识码中包含业务设备标识及其关联的多个用户标识；将各个用户历史支付记录发送至各个用户终端，以供用户终端管理订单数据记录。

Description

基于多人点单的订单管理方法及***
相关申请的交叉参考
本申请要求于2019年9月16日提交中国专利局、申请号为201910872699.3、名称为“基于多人点单的订单管理方法及***”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本公开涉及电子信息领域，具体涉及一种基于多人点单的订单管理方法及***。
背景技术
目前，很多业务都可以通过互联网进行电子点单操作，从而省去了人工点单的繁琐不便。在多数业务场景中，业务使用者为个人，相应地，只需由单一用户执行点单操作即可。但是，在有些业务场景中，业务使用者为多人，例如，多人共同使用一组业务，此时，多个业务使用者都希望参与点单操作，但是，传统的业务架构仅支持单一用户的点单操作，并不支持多个用户之间的协同点单操作。
为了解决上述问题，在申请号为2015100461021的专利申请中，公开了一种人人参与点餐的大家点餐***，该***首先由发起人进行登录，进入***后发起人搜索餐厅信息并选择餐厅，然后发起人发起点餐，并选择会员群聊，从而邀请好友一起点餐。通过会员群聊功能实现了多人同时点餐的需求。
但是，发明人在实现本公开的过程中发现，现有技术中的上述方式至少存在如下缺陷：在上述方式中，虽然多个用户都能够参与点单，但是，对于订单后台而言，只能根据订单发起人的信息识别订单，无法根据其他点单用户的信息识别订单。相应地，只有订单发起人有权限支付订单并针对订单进行管理，其他参与点单的用户则没有权限管理订单，导致多人点单场景中的订单管理不便。
发明内容
鉴于上述问题，提出了本公开以便提供一种克服上述问题或者至少部分地解决上述问题的一种基于多人点单的订单管理方法及***。
根据本公开的一个方面，提供了一种基于多人点单的订单管理方法，包括：
获取与预先创建的订单数据记录相对应的订单支付数据；其中，订单数据记录根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建；
根据订单数据记录的订单标识码中包含的各个用户标识，分别将订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识；
将与各个用户标识相对应的用户历史支付记录发送至各个用户标识所对应的用户终端，以供各个用户终端根据用户历史支付记录中包含的与订单支付数据相关联的订单管理入口管理订单数据记录。
根据本公开的再一方面，提供了一种基于多人点单的订单管理方法，包括：
向服务器发送包含用户标识的订单查询请求；
接收服务器根据订单标识码中包含用户标识的订单数据记录生成的用户历史支付记录；
显示用户历史支付记录，以根据用户历史支付记录进行订单管理。
根据本公开的再一方面，提供了一种基于多人点单的订单管理***，包括：
获取模块，适于获取与预先创建的订单数据记录相对应的订单支付数据；其中，订单数据记录根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建；
支付记录添加模块，适于根据订单数据记录的订单标识码中包含的各个用户标识，分别将订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识；
发送模块，适于将与各个用户标识相对应的用户历史支付记录发送至各个用户标识所对应的用户终端，以供各个用户终端根据用户历史支付记录中包含的与订单支付数据相关联的订单管理入口管理订单数据记录。
根据本公开的再一方面，提供了一种基于多人点单的订单管理终端，包括：
查询模块，适于向服务器发送包含用户标识的订单查询请求；
接收模块，适于接收服务器根据订单标识码中包含用户标识的订单数据记录生成的用户历史支付记录；
显示模块，适于显示用户历史支付记录，以根据用户历史支付记录进行订单管理。
根据本公开的再一方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；
存储器用于存放至少一可执行指令，可执行指令使处理器执行如上述的基于多人点单的订单管理方法对应的操作。
依据本公开的再一方面，提供了一种非易失性计算机可读存储介质，该非易失性计算机可读存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述的基于多人点单的订单管理方法对应的操作。
根据本公开的再又一方面，提供了一种计算机程序产品，该计算机程序产品包括存储在非易失性计算机存储介质上的计算机程序。
在本公开提供的基于多人点单的订单管理方法及***中，获取到预先创建的订单数据记录相对应的订单支付数据后，根据订单数据记录的订单标识码中包含的各个用户标识，分别将订单支付数据添加至与各个用户标识相对应的用户历史支付记录中，以使各个用户终端都能够根据用户历史支付记录中包含的与订单支付数据相关联的订单管理入口管理订单数据记录。由此可见，在上述方式中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识，相应地，能够基于业务设备标识唯一识别一笔订单，并根据与该业务设备标识相关联的多个用户标识使各个用户的历史支付记录中都包含对应的订单支付数据，从而确保各个点单用户都有权限管理该笔订单，提升了订单管理的灵活性。
上述说明仅是本公开技术方案的概述，为了能够更清楚了解本公开的技术手段，而可依照说明书的内容予以实施，并且为了让本公开的上述和其它目的、特征和优点能够更明 显易懂，以下特举本公开的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本公开的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了本公开实施例一提供的一种基于多人点单的订单管理方法的流程图；
图2示出了本公开实施例二提供的一种基于多人点单的订单管理方法的流程图；
图3示出了本公开实施例三提供的一种基于多人点单的订单管理***的结构图；
图4示出了本公开实施例五提供的一种电子设备的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
实施例一
图1示出了本公开实施例一提供的一种基于多人点单的订单管理方法的流程图。如图1所示，该方法包括：
步骤S110：获取与预先创建的订单数据记录相对应的订单支付数据；其中，订单数据记录根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建。
其中，订单数据记录用于记录一笔订单从启动点单操作直到点单支付完成的各个业务环节的相关信息。订单支付数据是指：订单数据记录所对应的订单支付完成后产生的与支付过程相关的数据，具体包括支付用户、支付数额、支付方式、支付时间、业务项明细等。
具体地，预先根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识，创建与业务设备标识相对应的订单数据记录；其中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识。其中，点单业务请求用于实现点单操作，具体可通过扫码等多种方式发送。点单业务请求中包含业务设备标识以及用户标识。其中，业务设备标识是指：用于提供本次业务服务的业务设备的标识，该业务设备可以是电子设备，也可以是业务桌、业务室等各类设备。用户标识是指：发送本次点单业务请求的用户的标识，如用户账号等。在本实施例中，基于各次接收到的点单业务请求中包含的业务设备标识，将对应于同一业务设备标识的多个用户标识关联在一起，进而建立对应的订单数据记录，该订单数据记录能够通过业务设备标识进行识别。
步骤S120：根据订单数据记录的订单标识码中包含的各个用户标识，分别将订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识。
具体地，查询订单数据记录的订单标识码中包含的各个用户标识，将订单支付数据分别添加至与各个用户标识相对应的用户历史支付记录中。其中，每个用户对应于一份用户 历史支付记录，该用户历史支付记录用于描述该用户在历史时段内的支付记录。每一条支付记录用于描述一笔订单的支付明细。各个用户通过用户历史支付记录能够查询已支付的各个订单。
步骤S130：将与各个用户标识相对应的用户历史支付记录发送至各个用户标识所对应的用户终端，以供各个用户终端根据用户历史支付记录中包含的与订单支付数据相关联的订单管理入口管理订单数据记录。
其中，各个用户终端接收到的用户历史支付记录中包含与订单支付数据相关联的订单管理入口，通过该订单管理入口能够针对订单支付数据所对应的订单数据记录进行管理。其中，该订单管理入口可以是查询入口、退款入口、评价入口等多种入口，本公开对此不做限定。
由此可见，在上述方式中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识，相应地，能够基于业务设备标识唯一识别一笔订单，并根据与该业务设备标识相关联的多个用户标识使各个用户的历史支付记录中都包含对应的订单支付数据，从而确保各个点单用户都有权限管理该笔订单，提升了订单管理的灵活性。
实施例二、
图2示出了本公开实施例二提供的一种基于多人点单的订单管理方法的流程图。如图2所示，该方法包括：
步骤S200：根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识，创建与业务设备标识相对应的订单数据记录；其中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识。
具体地，每当接收到点单业务请求时，获取本次接收到的点单业务请求中包含的业务设备标识以及用户标识，判断预设的开单数据表中是否存在与该业务设备标识相关联的有效开单标识；若是，获取已创建的与该业务设备标识以及有效开单标识相对应的订单数据记录，将本次接收到的点单业务请求中包含的用户标识添加到订单数据记录的订单标识码中；若否，生成与业务设备标识相关联的有效开单标识并将业务设备标识以及有效开单标识关联存储到开单数据表中，创建与业务设备标识以及有效开单标识相对应的订单数据记录，且订单数据记录的订单标识码中包含业务设备标识、有效开单标识以及本次接收到的点单业务请求中包含的用户标识。其中，点单业务请求用于实现点单操作，具体可通过扫码等多种方式发送。例如，在一个具体示例中，业务设备上设置有二维码等形式的信息码，且该二维码中包含业务设备标识，相应地，该点单业务请求为基于二维码的扫码点单请求。具体地，点单业务请求中包含业务设备标识以及用户标识。其中，业务设备标识是指：用于提供本次业务服务的业务设备的标识，该业务设备可以是电子设备，也可以是业务桌、业务室等各类设备。用户标识是指：发送本次点单业务请求的用户的标识，如用户账号等。
具体实施时，每当接收到点单业务请求时，根据其中包含的业务设备标识判断对应的业务设备是否已执行开单处理。其中，开单处理是指：已有业务用户针对该业务设备进行了点单操作，即：该业务设备已从空闲状态转为非空闲状态。具体地，通过预设的开单数据表中是否存在与该业务设备标识相关联的有效开单标识进行判断。其中，开单数据表用于存储与各个业务设备标识相对应的有效开单标识，通过有效开单标识能够识别各个业务设备处于空闲或非空闲状态。具体地，开单数据表用于存储开单流水数据，相应地，根据开单流水数据记录，生成与业务设备标识相关联的开单流水号，将开单流水号作为有效开 单标识。由于开单流水号包含时间戳信息，因此，能够准确标识一台业务设备当前是否空闲。
当开单数据表中存在与该业务设备标识相关联的有效开单标识时，说明对应的业务设备当前处于非空闲状态，因此，已经有业务用户针对该业务设备执行了开单处理。相应地，获取已创建的与该业务设备标识以及有效开单标识相对应的订单数据记录，将本次接收到的点单业务请求中包含的用户标识添加到订单数据记录的订单标识码中。通过该方式，能够扩充该业务设备标识所关联的业务用户的数量，从而使该业务设备标识所对应的订单数据记录中包含多个业务用户的用户标识。
当开单数据表中不存在与该业务设备标识相关联的有效开单标识时，说明对应的业务设备当前处于空闲状态，需要执行开单处理。相应地，生成与业务设备标识相关联的有效开单标识并将业务设备标识以及有效开单标识关联存储到开单数据表中，以实现针对该业务设备的开单处理，从而标识该业务设备已处于非空闲状态。接下来，创建与业务设备标识以及有效开单标识相对应的订单数据记录，且该订单数据记录的订单标识码中包含业务设备标识、有效开单标识以及本次接收到的点单业务请求中包含的用户标识。
由此可见，本公开中创建的订单标识码包括：用于存储业务设备标识的第一字段、用于存储有效开单标识的第二字段、以及用于存储用户标识的第三字段；其中，第三字段中进一步包括多个分别对应于不同的用户标识的子字段，各个用户标识分别对应于各次接收到的点单业务请求。通过上述方式能够根据业务设备标识关联多个点单用户，从而基于业务设备标识创建订单数据记录。其中，一条订单数据记录用于存储一笔订单从创建到支付的各个业务环节的业务记录。
步骤S210：根据已创建的订单数据记录进行多人点单操作。
具体地，将与该业务设备标识相关联的业务项数据推送给与本次接收到的点单业务请求中包含的用户标识相对应的用户终端，以便在接收到用户终端针对业务项数据触发的业务项添加请求时，将业务项添加请求中包含的业务项添加到订单数据记录中包含的业务项字段中。即：根据接收到的针对订单数据记录触发的业务项添加请求，向订单数据记录中包含的业务项字段中添加与业务项添加请求相对应的业务项。该业务项字段用于记录该订单数据记录所对应的各个业务项的名称和数量，以便基于该业务项字段为用户提供业务服务。其中，当业务设备为业务桌(如餐桌)时，业务项数据可以为餐厅的餐品数据，以供用户选择。由此可见，每当接收到一个点单业务请求后，基于该点单业务请求中包含的业务设备标识，向对应的点单用户推送与该业务设备标识相对应的业务项数据，具体可通过查询预设的业务项数据库实现，该业务项数据库用于存储各个业务设备与其对应的业务项之间的映射关系。通过上述方式，使同一业务设备所对应的多个扫码点单用户能够基于业务项数据进行点单操作。相应地，后台服务器接收到业务项添加请求时，根据其中包含的业务设备标识，确定与该业务项添加请求相对应的订单数据记录，进而将该业务项添加请求中的业务项记录到该订单数据记录的业务项字段中。由此可见，多个不同的业务用户能够针对同一个业务设备触发业务项添加请求，相应地，后台服务器将不同的业务用户针对同一个业务设备触发的业务项添加请求中的业务项汇总至对应的订单数据记录的业务项字段中，从而实现多人同时点单的效果。
步骤S220：当接收到针对订单数据记录触发的订单提交请求时，生成与订单数据记录相对应的支付订单。
具体地，当点单过程结束后，由多个点单用户中的任一用户发起订单提交请求。相应 地，当接收到针对订单数据记录触发的订单提交请求时，根据订单数据记录中包含的业务项字段中已添加的各个业务项，生成与订单数据记录相对应的支付订单，该支付订单的订单数额根据业务项字段中已添加的各个业务项的数量以及业务项对应的业务资源代价确定。其中，针对订单数据记录触发的业务项添加请求包括多个分别由订单数据记录的订单标识码中包含的各个用户标识所对应的用户终端发送的业务项添加请求。
由此可见，在本实施例中，订单数据记录用于存储一笔订单的创建、业务项添加、支付等各个业务环节的业务记录。即：订单数据记录用于集中存储订单的各个业务环节、各个业务层面的信息，以全面描述一笔订单的状态。而支付订单则是由订单数据记录衍生而来的专用于实现支付功能的订单。支付订单与其对应的订单数据记录通过订单标识码进行关联。由于支付订单独立于订单数据记录且可复制为多份，因此，本公开通过订单数据记录与支付订单相分离的方式实现了多用户均有权限支付的效果。
步骤S230：将支付订单推送给各个与订单数据记录的订单标识码中包含的用户标识相对应的用户终端，以供用户终端进行支付。
具体实施时，可通过如下两种方式中的至少两种实现支付过程：
在第一种支付方式中，由多个用户中的一个用户独立完成订单支付。具体地，根据订单数据记录的订单标识码中包含的用户标识的数量，将支付订单复制为多份，并将复制后的各份支付订单分别推送至各个与订单数据记录的订单标识码中包含的用户标识相对应的用户终端；根据接收到的针对支付订单触发的支付请求，对支付订单进行支付。具体地，为了便于实现多用户支付的效果，在生成与订单数据记录相对应的支付订单后，查询订单数据记录的订单标识码中包含的各个用户标识。根据查询结果，将支付订单分别推送至与订单数据记录的订单标识码中包含的各个用户标识相对应的用户终端。其中，支付订单用于实现订单支付功能，其中包含待支付的业务项明细、支付数额、支付入口元素等信息。该方式能够使每个参与点单的用户都能接收到对应的支付订单。其中，每个接收到支付订单的点单用户，都能够针对接收到的支付订单触发支付请求。例如，可通过支付订单中包含的支付入口元素触发该支付请求。相应地，后台服务器根据接收到的针对支付订单触发的支付请求，对支付订单进行支付。具体地，为了防止点单用户误支付邻桌订单，在本步骤中，需要校验支付用户与待支付订单是否匹配：判断接收到的针对于支付订单的支付请求中包含的用户标识与支付订单相对应的订单数据记录的订单标识码是否匹配；若是，根据支付请求对支付订单进行支付。例如，当接收到的针对于支付订单的支付请求中包含的用户标识与支付订单相对应的订单数据记录的订单标识码中存储的多个用户标识中的一个匹配时，说明支付用户与支付订单匹配，从而进行支付；反之，说明支付用户与支付订单不匹配，提示用户核对待支付订单。另外，由于多个点单用户中的任一用户都能够支付订单，因此，为了防止重复支付的现象发生，需要进行冲突检测。相应地，在根据接收到的针对支付订单触发的支付请求，对支付订单进行支付时，具体通过以下方式实现：当接收到针对支付订单触发的支付请求时，根据与支付订单相对应的订单数据记录中包含的业务状态字段，判断与订单数据记录相对应的支付订单是否已支付；若否，根据接收到的针对支付订单触发的支付请求，对支付订单进行支付，并根据支付结果更新与支付订单相对应的订单数据记录中包含的业务状态字段；若是，则拒绝该支付请求，并向支付请求对应的用户终端推送已支付通知。其中，订单数据记录中进一步包含业务状态字段，该字段用于指示该笔订单所对应的业务资源是否到账，相应地，通过查询该业务状态字段的取值能够防止重复支付现象发生，从而确保多个用户中只有一个用户能够支付成功。通过上述方式，即可由多个点单用户中的任一用户完成订单支付过程。另外，考虑到多个点单用户可 能需要针对该笔订单所对应的业务资源进行分摊操作，因此，为了便于多个点单用户之间分摊业务资源，在根据接收到的针对支付订单触发的支付请求，对支付订单进行支付时，根据支付请求中包含的用户标识，确定与支付订单相对应的已支付用户；根据与支付请求相对应的订单数据记录的订单标识码，确定与支付订单相对应的至少一个未支付用户；根据支付订单的订单数额数据以及未支付用户的数量，确定各个未支付用户所对应的待支付数额；向各个未支付用户发送包含待支付数额的支付通知消息，并在接收到各个未支付用户针对支付通知消息触发的支付请求时，根据该支付请求更新与已支付用户的用户账户相对应的账户数据。由此可见，通过上述方式，能够自动向其余的未支付用户发送包含待支付数额的通知消息，以引导其余未支付用户完成支付，进而将各个未支付用户的支付数额都转存至已支付用户的用户账户中，从而实现在各个点单用户之间分摊业务资源的目的。该方式尤其适用于多人点餐的业务场景中。
在第二种支付方式中，由多个用户协同完成订单支付。具体地，根据订单数据记录的订单标识码中包含的用户标识的数量，将支付订单拆分为多个支付子订单，各个支付子订单的订单数额的总和与支付订单的订单数额匹配；分别将各个支付子订单推送至与订单数据记录的订单标识码中包含的各个用户标识相对应的用户终端；根据接收到的针对支付订单触发的支付请求，对支付订单进行支付。该方式能够将支付订单拆分为多个支付子订单，以供多个点单用户分别支付，从而便于多个点单用户分摊业务资源代价。具体拆分时，可通过多种方式实现，本公开对此不做限定。在第一种拆分方式中，当订单数据记录的订单标识码中包含的用户标识的数量为N个时，将支付订单拆分为N个支付子订单，且各个支付子订单的订单数额相等；其中，N为自然数。例如，假设支付订单的总数额为100，N为4，则拆分后的每个支付子订单的数额为25。在第二种拆分方式中，当订单数据记录的订单标识码中包含的用户标识的数量为N个时，针对订单数据记录的订单标识码中包含的每个用户标识，获取该用户标识所对应的用户属性信息，根据各个用户标识所对应的用户属性信息，从N个用户标识中选择M个用户标识作为目标支付用户的用户标识；将支付订单拆分为M个分别对应于各个目标支付用户的支付子订单，根据各个目标支付用户的用户属性信息确定各个目标支付用户所对应的支付子订单的订单数额，在订单数据记录中记录各个目标支付用户及其对应的支付子订单的子订单标识以及订单数额之间的对应关系。其中，N和M为自然数，且M小于或等于N。其中，用户属性信息包括：点单记录信息、历史支付信息、用户等级信息等。相应地，根据用户属性信息筛选目标支付用户时，可以将点单次数大于预设点单阈值、历史支付数额大于预设支付数额、和/或用户等级高于预设等级的用户筛选为目标支付用户。另外，各个目标支付用户所对应的支付子订单的订单数额也可以根据用户属性信息确定，例如，使历史支付数额较高的用户所对应的支付子订单的订单数额高于历史支付数额较低的用户所对应的支付子订单的订单数额。另外，由于支付订单被拆分为多个支付子订单，因此，只有当各个支付子订单均支付完毕时，其对应的支付订单才处于已支付状态。相应地，根据接收到的针对各个支付子订单触发的子订单支付请求对各个子订单进行支付之后，进一步包括：获取支付订单所对应的各个支付子订单的支付状态；判断是否存在支付状态为未支付的支付子订单；若否，确定支付订单的支付状态为已支付，并更新与支付订单相对应的订单数据记录中包含的业务状态字段。其中，订单数据记录中进一步包含业务状态字段，该字段用于指示该笔订单所对应的业务资源是否到账，相应地，通过查询该业务状态字段的取值能够防止重复订单支付现象发生，且能够快速确定订单是否已支付。具体地，订单数据记录的业务状态字段中可以进一步包括多个分别对应于各个支付子订单的子字段，用于记录对应的支付子订单是否已支付。
步骤S240：当接收到针对支付订单触发的支付请求时，根据支付请求中包含的用户标 识生成与订单数据记录相对应的订单支付数据。
具体地，在接收到针对支付订单触发的支付请求时，根据该支付请求完成支付过程，并根据支付请求中包含的用户标识生成与订单数据记录相对应的订单支付数据。
在上述的第一种支付方式中，由一个用户独立完成订单支付，因此，支付请求是对应于整个支付订单的请求，相应地，订单支付数据用于记录订单支付用户的用户标识、支付订单总数额、支付时间等信息。
在上述的第二种支付方式中，由多个用户协同完成订单支付，因此，针对支付订单触发的支付请求包括多个分别对应于不同的支付子订单的子订单支付请求。相应地，每当接收到一个子订单支付请求时，针对支付子订单的支付完成情况记录与该支付子订单相对应的子订单支付数据，相应地，与订单数据记录相对应的订单支付数据包括：分别对应于各个支付子订单的子订单支付数据。
步骤S250：获取与订单数据记录相对应的订单支付数据，根据订单数据记录的订单标识码中包含的各个用户标识，分别将订单支付数据添加至与各个用户标识相对应的用户历史支付记录中。
具体实施时，获取订单数据记录的订单标识码中包含的N个用户标识，将订单支付数据复制为N份；分别将复制后的各份订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，N为自然数。
其中，在上述的第一种支付方式中，直接将订单支付数据复制为多份，并分别添加至与各个用户标识相对应的用户历史支付记录中即可。在上述的第二种支付方式中，可以将包含各个子订单支付数据的订单支付数据复制为多份，并分别添加至与各个用户标识相对应的用户历史支付记录中，以使每个点单用户都能查看各个用户的支付数额。或者，也可以分别将各个子订单支付数据添加至与该子订单支付数据相对应的点单用户的用户历史支付记录中，本公开对具体实现方式不做限定。
步骤S260：将与各个用户标识相对应的用户历史支付记录发送至各个用户标识所对应的用户终端，以供各个用户终端根据用户历史支付记录中包含的与订单支付数据相关联的订单管理入口管理订单数据记录。
其中，每个用户对应于一份用户历史支付记录，以记录该用户的历史支付情况，相应地，各个用户通过查询自身的用户历史支付记录，能够确定预设历史时段内的各个订单支付数据，每个订单支付数据对应于一笔订单，且每个订单支付数据具有关联的订单管理入口，以供用户管理该订单。
其中，订单支付数据关联的订单管理入口的种类和数量可以为多个，例如，包括：业务项查询入口、业务资源管理入口、业务状态查询入口、和/或业务评价入口。相应地，订单数据记录中进一步包括：用于存储订单数据记录中包含的各个业务项的业务项字段、用于存储订单数据记录的业务资源信息的业务资源字段、用于存储订单数据记录的业务状态信息的业务状态字段；则业务项查询入口用于根据订单数据记录中包含的业务项字段进行查询、业务资源管理入口用于根据订单数据记录中包含的业务资源字段进行管理、且业务状态查询入口用于根据订单数据记录中包含的业务状态字段进行查询。具体地，业务项查询入口用于查询订单数据记录所包含的多个业务项，例如，对于点餐业务而言，订单数据记录所包含的多个业务项为用户点单时选择的各个餐品项。业务资源管理入口用于查询、管理订单数据记录所对应的业务资源，例如，对于点餐业务而言，业务资源主要是指订单支付金额，相应地，业务资源管理入口不仅能够查询该笔订单的支付金额，还能够针对该 笔订单发起退款等操作。业务状态查询入口可以查询订单所对应的物品物流状态、配送状态等。
另外，本公开中的方式可应用于点单先付以及点单后付等不同场景中。其中，点单先付是指：接收到订单提交请求后，根据订单提交请求生成对应的业务订单，并将业务订单推送至业务提供端，以供业务提供端根据业务订单提供业务服务。点单后付是指：接收到订单提交请求后，生成与订单数据记录相对应的支付订单，并只有在检测到支付订单的状态更新为已支付时才生成对应的业务订单，并将业务订单推送至业务提供端，以供业务提供端根据业务订单提供业务服务。
由此可见，在本公开提供的上述方式中，能够通过业务设备标识来识别订单，从而便于将同一业务设备标识所对应的多个点单用户进行关联。本实施例的订单标识码中至少包含业务设备标识以及由该业务设备标识进行关联的多个点单用户的用户标识，相应地，根据订单数据记录生成的支付订单中也包含订单标识码，且针对支付订单触发的支付请求中也包含待支付的支付订单对应的订单数据记录的订单标识码。由此可见，本实施例中的订单标识码贯穿于该笔订单的各个业务环节，因此，通过订单标识码中记录的业务设备标识以及多个用户标识，能够确保多个用户都能够针对该笔订单进行支付。另外，本公开能够将支付订单分别推送至各个点单用户，以使各个点单用户都有权限支付。在此基础上，本公开能够将支付订单扩散为多份，并分别提供给每个点单用户，以使每个点单用户都能够根据用户历史支付记录中包含的与订单支付数据相关联的订单管理入口管理订单数据记录。其中，订单管理入口还可以包括评价入口、消费记录出查询入口等多种类型。
另外，本公开又一实施例还提供了一种基于多人点单的订单管理方法，应用于用户终端侧，包括：
步骤一：向服务器发送包含用户标识的订单查询请求。
步骤二：接收服务器根据订单标识码中包含用户标识的订单数据记录生成的用户历史支付记录。
步骤三：显示用户历史支付记录，以根据用户历史支付记录进行订单管理。
可选地，用户历史支付记录包括：与订单标识码中包含用户标识的订单数据记录相对应的订单支付数据；则显示用户历史支付记录包括：
将用户历史支付记录中包含的订单支付数据以及用于管理订单支付数据的订单管理入口显示在支付记录查询页面中。
可选地，将用户历史支付记录中包含的订单支付数据以及用于管理订单支付数据的订单管理入口显示在支付记录查询页面中之后，进一步包括：
接收通过订单管理入口触发的订单管理请求，根据接收到的订单管理请求管理订单；
其中，用于管理订单支付数据的订单管理入口包括：业务项查询入口、业务资源管理入口、业务状态查询入口、和/或业务评价入口。
可选地，订单数据记录中进一步包括：用于存储订单数据记录中包含的各个业务项的业务项字段、用于存储订单数据记录的业务资源信息的业务资源字段、用于存储订单数据记录的业务状态信息的业务状态字段；则业务项查询入口用于根据订单数据记录中包含的业务项字段进行查询、业务资源管理入口用于根据订单数据记录中包含的业务资源字段进行管理、且业务状态查询入口用于根据订单数据记录中包含的业务状态字段进行查询。
可选地，该方法执行之前，进一步包括：
发送包含业务设备标识以及用户标识的点单业务请求，以供服务器根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建与业务设备标识相对应的订单数据记录；其中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识。
可选地，向服务器发送包含用户标识的订单查询请求之前，进一步包括：
接收云服务器发送的与预先创建的订单数据记录相对应的支付订单；其中，支付订单中包含支付入口，以供接收到该支付订单的各个用户进行支付；并且，用户历史支付记录的订单支付数据中进一步包含支付用户标识。由此可见，在本实施例中，订单标识码中包含的各个用户标识所对应的用户终端均会接收到支付订单，都有权限进行支付，当其中的一个或多个用户完成支付后，服务器会记录支付用户标识，进而将该支付用户标识包含在订单支付数据中，相应地，订单标识码中包含的各个用户标识所对应的用户都能够在其历史支付记录中查询到该笔订单，并能够查看该订单的支付用户。
实施例三
图3示出了本公开实施例三提供的一种基于多人点单的订单管理***的结构示意图，该***包括：
获取模块31，适于获取与预先创建的订单数据记录相对应的订单支付数据；其中，订单数据记录根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建；
支付记录添加模块32，适于根据订单数据记录的订单标识码中包含的各个用户标识，分别将订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识；
发送模块33，适于将与各个用户标识相对应的用户历史支付记录发送至各个用户标识所对应的用户终端，以供各个用户终端根据用户历史支付记录中包含的与订单支付数据相关联的订单管理入口管理订单数据记录。
可选地，支付记录添加模块具体适于：
获取订单数据记录的订单标识码中包含的N个用户标识，将订单支付数据复制为N份；
分别将复制后的各份订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，N为自然数。
可选地，与订单支付数据相关联的订单管理入口包括：
业务项查询入口、业务资源管理入口、业务状态查询入口、和/或业务评价入口。
可选地，订单数据记录中进一步包括：
用于存储订单数据记录中包含的各个业务项的业务项字段、用于存储订单数据记录的业务资源信息的业务资源字段、用于存储订单数据记录的业务状态信息的业务状态字段；
则业务项查询入口用于根据订单数据记录中包含的业务项字段进行查询、业务资源管理入口用于根据订单数据记录中包含的业务资源字段进行管理、且业务状态查询入口用于根据订单数据记录中包含的业务状态字段进行查询。
可选地，该***进一步包括：
订单生成模块，适于每当接收到点单业务请求时，获取本次接收到的点单业务请求中包含的业务设备标识以及用户标识，判断预设的开单数据表中是否存在与业务设备标识相关联的有效开单标识；
若是，获取已创建的与业务设备标识以及有效开单标识相对应的订单数据记录，将本次接收到的点单业务请求中包含的用户标识添加到订单数据记录的订单标识码中；
若否，生成与业务设备标识相关联的有效开单标识并将业务设备标识以及有效开单标识关联存储到开单数据表中，创建与业务设备标识以及有效开单标识相对应的订单数据记录，且订单数据记录的订单标识码中包含业务设备标识、有效开单标识以及本次接收到的点单业务请求中包含的用户标识。
可选地，订单生成模块进一步适于：
根据接收到的针对订单数据记录触发的业务项添加请求，向订单数据记录中包含的业务项字段中添加与业务项添加请求相对应的业务项；
当接收到针对订单数据记录触发的订单提交请求时，根据订单数据记录中包含的业务项字段中已添加的各个业务项，生成与订单数据记录相对应的支付订单。
可选地，针对订单数据记录触发的业务项添加请求包括：多个分别由订单数据记录的订单标识码中包含各个用户标识所对应的用户终端发送的业务项添加请求。
可选地，获取模块具体适于：
当接收到针对支付订单触发的支付请求时，根据支付请求中包含的用户标识生成与订单数据记录相对应的订单支付数据。
可选地，点单业务请求包括：基于二维码的扫码点单请求，且二维码中包含业务设备标识。
关于上述各个模块的具体结构和工作原理可参照方法实施例中相应部分的描述，此处不再赘述。
另外，本公开又一实施例还提供了一种基于多人点单的订单管理终端，该终端可以为手机等各类电子设备，具体包括：
查询模块，适于向服务器发送包含用户标识的订单查询请求；
接收模块，适于接收服务器根据订单标识码中包含用户标识的订单数据记录生成的用户历史支付记录；
显示模块，适于显示用户历史支付记录，以根据用户历史支付记录进行订单管理。
可选地，用户历史支付记录包括：与订单标识码中包含用户标识的订单数据记录相对应的订单支付数据；则显示模块具体适于：
将用户历史支付记录中包含的订单支付数据以及用于管理订单支付数据的订单管理入口显示在支付记录查询页面中。
可选地，显示模块进一步适于：
接收通过订单管理入口触发的订单管理请求，根据接收到的订单管理请求管理订单；
其中，用于管理订单支付数据的订单管理入口包括：业务项查询入口、业务资源管理入口、业务状态查询入口、和/或业务评价入口。
可选地，订单数据记录中进一步包括：用于存储订单数据记录中包含的各个业务项的业务项字段、用于存储订单数据记录的业务资源信息的业务资源字段、用于存储订单数据记录的业务状态信息的业务状态字段；
则业务项查询入口用于根据订单数据记录中包含的业务项字段进行查询、业务资源管 理入口用于根据订单数据记录中包含的业务资源字段进行管理、且业务状态查询入口用于根据订单数据记录中包含的业务状态字段进行查询。
可选地，该装置进一步包括：
点单模块，适于发送包含业务设备标识以及用户标识的点单业务请求，以供服务器根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建与业务设备标识相对应的订单数据记录；其中，订单数据记录的订单标识码中包含业务设备标识以及与业务设备标识相关联的多个用户标识。
可选地，点单模块进一步适于：
接收云服务器发送的与预先创建的订单数据记录相对应的支付订单；其中，支付订单中包含支付入口，以供接收到该支付订单的各个用户进行支付；
并且，用户历史支付记录的订单支付数据中进一步包含支付用户标识。
实施例四
本公开实施例四提供了一种非易失性计算机可读存储介质，该非易失性计算机可读存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的基于多人点单的订单管理方法。可执行指令具体可以用于使得处理器执行上述方法实施例中对应的各个操作。
实施例五
图4示出了根据本公开实施例五的一种电子设备的结构示意图，本公开具体实施例并不对电子设备的具体实现做限定。
如图4所示，该电子设备可以包括：处理器(processor)402、通信接口(Communications Interface)406、存储器(memory)404、以及通信总线408。
其中：
处理器402、通信接口406、以及存储器404通过通信总线408完成相互间的通信。
通信接口406，用于与其它设备比如客户端或其它服务器等的网元通信。
处理器402，用于执行程序410，具体可以执行上述基于多人点单的订单管理方法实施例中的相关步骤。
具体地，程序410可以包括程序代码，该程序代码包括计算机操作指令。
处理器402可能是中央处理器CPU，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本公开实施例的一个或多个集成电路。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。
存储器404，用于存放程序410。存储器404可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
程序510具体可以用于使得处理器502执行上述方法实施例中对应的各个操作。
在此提供的算法和显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述，构造这类***所要求的结构是显而易见的。此外，本公开也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本公开的内容，并且上面对特定语言所做的描述是为了披露本公开 的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本公开的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个公开方面中的一个或多个，在上面对本公开的示例性实施例的描述中，本公开的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本公开要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，公开方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本公开的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本公开的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本公开的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本公开实施例的基于语音输入信息的抽奖***中的一些或者全部部件的一些或者全部功能。本公开还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本公开的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本公开进行说明而不是对本公开进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本公开可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (36)

  1. 一种基于多人点单的订单管理方法，包括：
    获取与预先创建的订单数据记录相对应的订单支付数据；其中，所述订单数据记录根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建；
    根据所述订单数据记录的订单标识码中包含的各个用户标识，分别将所述订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，所述订单数据记录的订单标识码中包含所述业务设备标识以及与所述业务设备标识相关联的多个用户标识；
    将与各个用户标识相对应的用户历史支付记录发送至各个用户标识所对应的用户终端，以供各个用户终端根据所述用户历史支付记录中包含的与所述订单支付数据相关联的订单管理入口管理所述订单数据记录。
  2. 根据权利要求1所述的方法，其中，所述根据所述订单数据记录的订单标识码中包含的各个用户标识，分别将所述订单支付数据添加至与各个用户标识相对应的用户历史支付记录中包括：
    获取所述订单数据记录的订单标识码中包含的N个用户标识，将所述订单支付数据复制为N份；
    分别将复制后的各份订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，N为自然数。
  3. 根据权利要求1或2所述的方法，其中，所述与所述订单支付数据相关联的订单管理入口包括：
    业务项查询入口、业务资源管理入口、业务状态查询入口、和/或业务评价入口。
  4. 根据权利要求3所述的方法，其中，所述订单数据记录中进一步包括：
    用于存储所述订单数据记录中包含的各个业务项的业务项字段、用于存储所述订单数据记录的业务资源信息的业务资源字段、用于存储所述订单数据记录的业务状态信息的业务状态字段；
    则所述业务项查询入口用于根据所述订单数据记录中包含的业务项字段进行查询、所述业务资源管理入口用于根据所述订单数据记录中包含的业务资源字段进行管理、且所述业务状态查询入口用于根据所述订单数据记录中包含的业务状态字段进行查询。
  5. 根据权利要求1所述的方法，其中，所述方法执行之前，进一步包括：
    每当接收到点单业务请求时，获取本次接收到的点单业务请求中包含的业务设备标识以及用户标识，判断预设的开单数据表中是否存在与所述业务设备标识相关联的有效开单标识；
    若是，获取已创建的与所述业务设备标识以及所述有效开单标识相对应的订单数据记录，将所述本次接收到的点单业务请求中包含的用户标识添加到所述订单数据记录的订单标识码中；
    若否，生成与所述业务设备标识相关联的有效开单标识并将所述业务设备标识以及所述有效开单标识关联存储到所述开单数据表中，创建与所述业务设备标识以及所述有效开单标识相对应的订单数据记录，且所述订单数据记录的订单标识码中包含所述业务设备标识、所述有效开单标识以及本次接收到的点单业务请求中包含的用户标识。
  6. 根据权利要求1所述的方法，其中，所述获取与预先创建的订单数据记录相对应的订单支付数据之前，进一步包括：
    根据接收到的针对所述订单数据记录触发的业务项添加请求，向所述订单数据记录中包含的业务项字段中添加与所述业务项添加请求相对应的业务项；
    当接收到针对所述订单数据记录触发的订单提交请求时，根据所述订单数据记录中包含的业务项字段中已添加的各个业务项，生成与所述订单数据记录相对应的支付订单。
  7. 根据权利要求6所述的方法，其中，所述针对所述订单数据记录触发的业务项添加请求包括：多个分别由所述订单数据记录的订单标识码中包含各个用户标识所对应的用户终端发送的业务项添加请求。
  8. 根据权利要求6所述的方法，其中，所述获取与预先创建的订单数据记录相对应的订单支付数据包括：
    当接收到针对所述支付订单触发的支付请求时，根据所述支付请求中包含的用户标识生成与所述订单数据记录相对应的订单支付数据。
  9. 根据权利要求1所述的方法，其中，所述点单业务请求包括：基于二维码的扫码点单请求，且所述二维码中包含业务设备标识。
  10. 一种基于多人点单的订单管理方法，包括：
    向服务器发送包含用户标识的订单查询请求；
    接收服务器根据订单标识码中包含所述用户标识的订单数据记录生成的用户历史支付记录；
    显示所述用户历史支付记录，以根据所述用户历史支付记录进行订单管理。
  11. 根据权利要求10所述的方法，其中，所述用户历史支付记录包括：与订单标识码中包含所述用户标识的订单数据记录相对应的订单支付数据；则所述显示所述用户历史支付记录包括：
    将所述用户历史支付记录中包含的订单支付数据以及用于管理所述订单支付数据的订单管理入口显示在支付记录查询页面中。
  12. 根据权利要求11所述的方法，其中，所述将所述用户历史支付记录中包含的订单支付数据以及用于管理所述订单支付数据的订单管理入口显示在支付记录查询页面中之后，进一步包括：
    接收通过所述订单管理入口触发的订单管理请求，根据接收到的订单管理请求管理订单；
    其中，所述用于管理所述订单支付数据的订单管理入口包括：业务项查询入口、业务资源管理入口、业务状态查询入口、和/或业务评价入口。
  13. 根据权利要求12所述的方法，其中，所述订单数据记录中进一步包括：用于存储所述订单数据记录中包含的各个业务项的业务项字段、用于存储所述订单数据记录的业务资源信息的业务资源字段、用于存储所述订单数据记录的业务状态信息的业务状态字段；
    则所述业务项查询入口用于根据所述订单数据记录中包含的业务项字段进行查询、所述业务资源管理入口用于根据所述订单数据记录中包含的业务资源字段进行管理、且所述业务状态查询入口用于根据所述订单数据记录中包含的业务状态字段进行查询。
  14. 根据权利要求10-13任一所述的方法，其中，所述方法执行之前，进一步包括：
    发送包含业务设备标识以及用户标识的点单业务请求，以供服务器根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建与业务设备标识相对应的订单数据记录；其中，订单数据记录的订单标识码中包含业务设备标识以及与所述业务设备标识相关联的多个用户标识。
  15. 根据权利要求10-14任一所述的方法，其中，所述向服务器发送包含用户标识的订单查询请求之前，进一步包括：
    接收云服务器发送的与预先创建的订单数据记录相对应的支付订单；其中，所述支付订单中包含支付入口，以供接收到该支付订单的各个用户进行支付；
    并且，所述用户历史支付记录的订单支付数据中进一步包含支付用户标识。
  16. 一种基于多人点单的订单管理***，包括：
    获取模块，适于获取与预先创建的订单数据记录相对应的订单支付数据；其中，所述订单数据记录根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建；
    支付记录添加模块，适于根据所述订单数据记录的订单标识码中包含的各个用户标识，分别将所述订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，所述订单数据记录的订单标识码中包含所述业务设备标识以及与所述业务设备标识相关联的多个用户标识；
    发送模块，适于将与各个用户标识相对应的用户历史支付记录发送至各个用户标识所对应的用户终端，以供各个用户终端根据所述用户历史支付记录中包含的与所述订单支付数据相关联的订单管理入口管理所述订单数据记录。
  17. 根据权利要求16所述的***，其中，所述支付记录添加模块具体适于：
    获取所述订单数据记录的订单标识码中包含的N个用户标识，将所述订单支付数据复制为N份；
    分别将复制后的各份订单支付数据添加至与各个用户标识相对应的用户历史支付记录中；其中，N为自然数。
  18. 根据权利要求16或17所述的***，其中，所述与所述订单支付数据相关联的订单管理入口包括：
    业务项查询入口、业务资源管理入口、业务状态查询入口、和/或业务评价入口。
  19. 根据权利要求18所述的***，其中，所述订单数据记录中进一步包括：
    用于存储所述订单数据记录中包含的各个业务项的业务项字段、用于存储所述订单数据记录的业务资源信息的业务资源字段、用于存储所述订单数据记录的业务状态信息的业务状态字段；
    则所述业务项查询入口用于根据所述订单数据记录中包含的业务项字段进行查询、所述业务资源管理入口用于根据所述订单数据记录中包含的业务资源字段进行管理、且所述业务状态查询入口用于根据所述订单数据记录中包含的业务状态字段进行查询。
  20. 根据权利要求16所述的***，其中，所述***进一步包括：
    订单生成模块，适于每当接收到点单业务请求时，获取本次接收到的点单业务请求中包含的业务设备标识以及用户标识，判断预设的开单数据表中是否存在与所述业务设备标识相关联的有效开单标识；
    若是，获取已创建的与所述业务设备标识以及所述有效开单标识相对应的订单数据记录，将所述本次接收到的点单业务请求中包含的用户标识添加到所述订单数据记录的订单标识码中；
    若否，生成与所述业务设备标识相关联的有效开单标识并将所述业务设备标识以及所述有效开单标识关联存储到所述开单数据表中，创建与所述业务设备标识以及所述有效开单标识相对应的订单数据记录，且所述订单数据记录的订单标识码中包含所述业务设备标识、所述有效开单标识以及本次接收到的点单业务请求中包含的用户标识。
  21. 根据权利要求16所述的***，其中，所述订单生成模块进一步适于：
    根据接收到的针对所述订单数据记录触发的业务项添加请求，向所述订单数据记录中包含的业务项字段中添加与所述业务项添加请求相对应的业务项；
    当接收到针对所述订单数据记录触发的订单提交请求时，根据所述订单数据记录中包含的业务项字段中已添加的各个业务项，生成与所述订单数据记录相对应的支付订单。
  22. 根据权利要求21所述的***，其中，所述针对所述订单数据记录触发的业务项添加请求包括：多个分别由所述订单数据记录的订单标识码中包含各个用户标识所对应的用户终端发送的业务项添加请求。
  23. 根据权利要求21所述的***，其中，所述获取模块具体适于：
    当接收到针对所述支付订单触发的支付请求时，根据所述支付请求中包含的用户标识生成与所述订单数据记录相对应的订单支付数据。
  24. 根据权利要求16所述的***，其中，所述点单业务请求包括：基于二维码的扫码点单请求，且所述二维码中包含业务设备标识。
  25. 一种基于多人点单的订单管理终端，包括：
    查询模块，适于向服务器发送包含用户标识的订单查询请求；
    接收模块，适于接收服务器根据订单标识码中包含所述用户标识的订单数据记录生成的用户历史支付记录；
    显示模块，适于显示所述用户历史支付记录，以根据所述用户历史支付 记录进行订单管理。
  26. 根据权利要求25所述的终端，其中，所述用户历史支付记录包括：与订单标识码中包含所述用户标识的订单数据记录相对应的订单支付数据；则所述显示模块具体适于：
    将所述用户历史支付记录中包含的订单支付数据以及用于管理所述订单支付数据的订单管理入口显示在支付记录查询页面中。
  27. 根据权利要求26所述的终端，其中，显示模块进一步适于：
    接收通过所述订单管理入口触发的订单管理请求，根据接收到的订单管理请求管理订单；
    其中，所述用于管理所述订单支付数据的订单管理入口包括：业务项查询入口、业务资源管理入口、业务状态查询入口、和/或业务评价入口。
  28. 根据权利要求27所述的终端，其中，所述订单数据记录中进一步包括：用于存储所述订单数据记录中包含的各个业务项的业务项字段、用于存储所述订单数据记录的业务资源信息的业务资源字段、用于存储所述订单数据记录的业务状态信息的业务状态字段；
    则所述业务项查询入口用于根据所述订单数据记录中包含的业务项字段进行查询、所述业务资源管理入口用于根据所述订单数据记录中包含的业务资源字段进行管理、且所述业务状态查询入口用于根据所述订单数据记录中包含的业务状态字段进行查询。
  29. 根据权利要求25-28任一所述的终端，其中，所述装置进一步包括：
    点单模块，适于发送包含业务设备标识以及用户标识的点单业务请求，以供服务器根据各次接收到的点单业务请求中包含的业务设备标识以及用户标识创建与业务设备标识相对应的订单数据记录；其中，订单数据记录的订单标识码中包含业务设备标识以及与所述业务设备标识相关联的多个用户标识。
  30. 根据权利要求25-29任一所述的终端，其中，所述点单模块进一步适于：
    接收云服务器发送的与预先创建的订单数据记录相对应的支付订单；其中，所述支付订单中包含支付入口，以供接收到该支付订单的各个用户进行支付；
    并且，所述用户历史支付记录的订单支付数据中进一步包含支付用户标识。
  31. 一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；
    所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-9中任一项所述的基于多人点单的订单管理方法对应的操作。
  32. 一种非易失性计算机可读存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-9中任一项所述的基于多人点单的订单管理方法对应的操作。
  33. 一种计算机程序产品，其中，所述计算机程序产品包括存储在非易失性计算机存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被处理器执行时，使所述处理器执行如权利要求1-9中任一项所述的基于多人点单的订单管理方法对应的操作。
  34. 一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；
    所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求10-15所述的基于多人点单的订单管理方法对应的操作。
  35. 一种非易失性计算机可读存储介质，所述非易失性计算机可读存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求10-15所述的基于多人点单的订单管理方法对应的操作。
  36. 一种计算机程序产品，其中，所述计算机程序产品包括存储在非易失性计算机存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被处理器执行时，使所述处理器执行如权利要求10-15所述的基于多人点单的订单管理方法对应的操作。
PCT/CN2020/082158 2019-09-16 2020-03-30 基于多人点单的订单管理方法及*** WO2021051775A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/760,763 US20220343398A1 (en) 2019-09-16 2020-03-30 Order management methods, system, terminal and electronic device based on multi-person ordering

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910872699.3A CN110738479B (zh) 2019-09-16 2019-09-16 基于多人点单的订单管理方法及***
CN201910872699.3 2019-09-16

Publications (1)

Publication Number Publication Date
WO2021051775A1 true WO2021051775A1 (zh) 2021-03-25

Family

ID=69267977

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/082158 WO2021051775A1 (zh) 2019-09-16 2020-03-30 基于多人点单的订单管理方法及***

Country Status (3)

Country Link
US (1) US20220343398A1 (zh)
CN (2) CN110738479B (zh)
WO (1) WO2021051775A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110738479B (zh) * 2019-09-16 2021-02-23 口碑(上海)信息技术有限公司 基于多人点单的订单管理方法及***
CN111275425B (zh) * 2020-02-26 2021-06-11 口碑(上海)信息技术有限公司 订单支付方法及装置、***、电子设备、存储介质
CN111461834B (zh) * 2020-03-31 2023-06-20 时时同云科技(成都)有限责任公司 订单处理方法、装置及订单展示方法、装置
CN111160998B (zh) * 2020-04-02 2021-04-30 支付宝(杭州)信息技术有限公司 基于区块链的点评数据处理方法、装置及点评***
CN111708757B (zh) * 2020-05-29 2023-07-07 口碑(上海)信息技术有限公司 数据资源处理方法、装置和***，存储介质和电子设备
CN111652609A (zh) * 2020-05-31 2020-09-11 四川亨通网智科技有限公司 一种多人账单结算***
CN111951091B (zh) * 2020-08-13 2023-12-29 金蝶软件（中国）有限公司 一种交易流水对账方法、***及相关设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002056248A (ja) * 2000-08-07 2002-02-20 Nec Corp 注文集約システムおよび注文集約・個別購入システム
CN102117520A (zh) * 2009-12-31 2011-07-06 亿阳信通股份有限公司 基于ic卡的支付方法、管理装置、服务器及移动终端
CN108053301A (zh) * 2018-01-22 2018-05-18 杭州迪火科技有限公司 多人协同下单***和多人协同下单方法
CN108876549A (zh) * 2018-06-26 2018-11-23 北京云迹科技有限公司 一种订单的处理方法和服务器
CN109739890A (zh) * 2018-12-29 2019-05-10 浙江口碑网络技术有限公司 数据处理方法、装置及设备
CN110738479A (zh) * 2019-09-16 2020-01-31 口碑(上海)信息技术有限公司 基于多人点单的订单管理方法及***

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110119189A1 (en) * 2009-11-18 2011-05-19 American Express Travel Related Services Company, Inc. Data processing framework
US20110320349A1 (en) * 2010-06-28 2011-12-29 Leslie Olsen Rental property payment system
KR101407398B1 (ko) * 2012-04-19 2014-06-20 안종오 스마트 단말을 이용한 하이브리드 전자상거래 제공방법 및 이를 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체
CN104978697A (zh) * 2015-06-24 2015-10-14 西南石油大学 一种基于二维码的协同智能点餐方法与***
CN104992357A (zh) * 2015-07-10 2015-10-21 拉扎斯网络科技（上海）有限公司 一种拼单方法和装置
CN106096940A (zh) * 2016-06-03 2016-11-09 乐视控股（北京）有限公司 一种支付方法和装置
CN111523971A (zh) * 2016-08-19 2020-08-11 北京三快在线科技有限公司 一种购买操作共享方法及装置
CN107358421A (zh) * 2017-02-23 2017-11-17 美味不用等（上海）信息科技股份有限公司 支付方法、支付装置、终端设备和服务器
CN107909442B (zh) * 2017-11-22 2021-08-03 北京新弘宝科技有限公司 一种多人群组用餐绑定和解除***、方法及智能餐桌
CN109711923A (zh) * 2018-11-14 2019-05-03 浙江口碑网络技术有限公司 点餐信息的处理方法、装置及***
CN109657827B (zh) * 2018-12-19 2020-07-17 口碑(上海)信息技术有限公司 基于资源状态的服务预约方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002056248A (ja) * 2000-08-07 2002-02-20 Nec Corp 注文集約システムおよび注文集約・個別購入システム
CN102117520A (zh) * 2009-12-31 2011-07-06 亿阳信通股份有限公司 基于ic卡的支付方法、管理装置、服务器及移动终端
CN108053301A (zh) * 2018-01-22 2018-05-18 杭州迪火科技有限公司 多人协同下单***和多人协同下单方法
CN108876549A (zh) * 2018-06-26 2018-11-23 北京云迹科技有限公司 一种订单的处理方法和服务器
CN109739890A (zh) * 2018-12-29 2019-05-10 浙江口碑网络技术有限公司 数据处理方法、装置及设备
CN110738479A (zh) * 2019-09-16 2020-01-31 口碑(上海)信息技术有限公司 基于多人点单的订单管理方法及***

Also Published As

Publication number Publication date
CN110738479B (zh) 2021-02-23
CN110738479A (zh) 2020-01-31
CN113011865B (zh) 2024-01-02
CN113011865A (zh) 2021-06-22
US20220343398A1 (en) 2022-10-27

Similar Documents

Publication Publication Date Title
WO2021051775A1 (zh) 基于多人点单的订单管理方法及***
US10326715B2 (en) System and method for updating information in an instant messaging application
CN104618226B (zh) 一种信息处理方法、客户端和服务器
WO2017129083A1 (zh) 消息处理方法、装置、***和计算机存储介质
CN111667349B (zh) 基于社交应用的拼单方法、客户端、服务器及***
CN110728505A (zh) 基于多人点单的支付方法、服务器、客户端及***
CN110689334A (zh) 基于多人点单的支付方法、服务器、客户端及***
CN107370780B (zh) 基于互联网的媒体推送方法、装置和***
CN109152061B (zh) 通道调配方法、装置、服务器及存储介质
CN105897704B (zh) 权限添加、权限添加请求的方法、装置和***
TWI706329B (zh) 圖形碼產生方法、資源發送及接收方法、裝置及電子設備
CN110022259B (zh) 消息到达率确定方法、装置、数据统计服务器及存储介质
WO2016127792A1 (zh) 用户事件的响应方法及装置
CN111798013B (zh) 会议预约的处理方法和装置
CN113364853A (zh) 一种业务服务***、业务请求方法及网关设备
US20160307237A1 (en) Accessing Advertised Application States From A Current Application State
WO2014176896A1 (en) System and method for updating information in an instant messaging application
US20120330914A1 (en) Server, inter-business enterprise information control method and computer program
CN108122124B (zh) 信息推送方法、平台及***
CN110706070A (zh) 多人点单方法、服务器、客户端及***
CN109408755A (zh) 数据处理方法、装置、终端设备及计算机存储介质
US20180034866A1 (en) Method and apparatus of providing chatrooms for consultation
WO2017124944A1 (zh) 业务处理方法和装置
WO2022001747A1 (zh) 拼单方法及装置
CN110930163A (zh) 一种房源委托业务的实现方法、***及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20864903

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20864903

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 20864903

Country of ref document: EP

Kind code of ref document: A1