JP2023126581A - Commodity sales data processing system, commodity sales data processing method, settlement device, and program - Google Patents

Abstract

To efficiently correct a registered commodity.SOLUTION: A commodity sales data processing device operable by a customer, includes: change reception means for receiving a change in commodity information indicating a commodity registered in one transaction from the customer; approval input means for receiving an approval result by a clerk for the change in the commodity information received by the change reception means; and commodity information change means for changing the commodity information when the approval result is input from the approval input means.SELECTED DRAWING: Figure 26

Description

The present invention relates to a product sales data processing device, a registration device, a payment device, a product sales data processing system, a product sales data processing method, and a program.

Stores such as convenience stores and supermarkets are equipped with product sales data processing devices (for example, POS registers) for registering products. In recent years, product sales data processing devices that allow customers to register products themselves and make payments have become popular. In such a product sales data processing device, if a customer registers a product by mistake, corrections (changes) are made.

A related technology is an order registration processing device used in restaurants, etc. When a customer inputs an instruction to check room availability, it queries a server about the usage status of the guest room and receives the usage status of the guest room from the server. An order registration processing device has been proposed that displays (for example, see Patent Document 1).

Japanese Patent Application Publication No. 2016-045782

However, when correcting a registered product, the correction operation is performed by a store clerk, for example, from the perspective of fraud prevention. Therefore, if there is a correction, the customer must call the store clerk and wait for the clerk to complete the correction operation, which may waste time. Furthermore, for the store clerk, for example, it may take time to perform a correction operation, which may interfere with other tasks, resulting in a decrease in work efficiency. For this reason, the conventional technology has a problem in that it may not be possible to efficiently correct registered products.

The present invention has been made in view of the above circumstances, and its purpose is to provide a technology that can efficiently correct registered products.

In order to solve the above-mentioned problems, a product sales data processing device that is one aspect of the present invention includes a customer-side operation means that can be operated by the customer, and a customer-side operation means that can be operated by the customer. a change reception means for accepting changes in product information indicating products registered in one transaction from a customer by accepting an operation on the means; an identification information input means for inputting identification information for identifying a store clerk; and an identification information inputting means for inputting identification information for identifying a store clerk; a clerk specifying means for specifying a clerk using the identification information inputted by the input means; and a change accepting means for accepting an operation on the customer side operation means when the clerk is identified by the clerk specifying means. an approval input means for inputting an approval result by a store clerk regarding the change of the product information accepted by the product information; and a product information change means for changing the product information by inputting the approval result by the approval input means. This is a product sales data processing device characterized by comprising:

According to the above configuration, it is possible to efficiently correct (change) registered products.

The above-mentioned product sales data processing device includes mode setting means for setting one of a plurality of modes, and the approval input means is configured to input information to the customer when a predetermined mode is set by the mode setting means. The approval result may be input by accepting an operation on the side operation means.

According to the above configuration, registered products can be corrected efficiently.

In order to solve the above-mentioned problems, another aspect of the present invention is a program that causes a computer to function as a product sales data processing device that is equipped with a customer-side operation section that can be operated by a customer. , a change reception means for receiving a change in product information indicating a product registered in one transaction from a customer by receiving an operation on the customer-side operation unit; and an identification information input means for inputting identification information for identifying a store clerk. , a clerk identifying means for identifying a store clerk using the identification information inputted by the identification information input means, and accepting an operation on the customer side operation unit when the clerk is identified by the clerk identifying means, Approval input means for inputting an approval result by a store clerk regarding the change in the product information accepted by the change reception means; and product information change means for changing the product information by inputting the approval result by the approval input means. This is a program that is characterized by functioning as .

According to the above configuration, registered products can be corrected efficiently.

In the product sales data processing device system, the payment device transmits change information indicating a change in the product information received from a customer to the registration device, and the registration device receives the change information from the payment device. Accordingly, the approval result may be input.

According to the above configuration, registered products can be corrected efficiently.

In the above product sales data processing device system, the registration device and the settlement device both set one of a plurality of modes, and when the settlement device sets a predetermined mode, the change information may be transmitted to the registration device, and the registration device may input the approval result by receiving the change information from the payment device when a mode different from the predetermined mode is set.

According to the above configuration, registered products can be corrected efficiently.

In order to solve the above-mentioned problems, another aspect of the present invention is a program that causes a computer to function as a product sales data processing device that can be operated by a customer, and which displays products registered in one transaction. a change reception means for accepting changes in product information from a customer; an approval input means for inputting an approval result by a store clerk for the change in the product information accepted by the change reception means; the approval result being input by the approval input means; This program is characterized in that it functions as a product information changing means for changing the product information.

As described above, according to the present invention, registered products can be corrected efficiently.

1 is a network configuration diagram of a POS system according to Embodiment 1 of the present invention. FIG. It is a diagram showing an example of installation of POS terminals. FIG. 2 is a diagram showing an example of the appearance of a POS terminal. It is a diagram showing an example of the configuration of a POS terminal. FIG. 2 is a diagram illustrating an outline of the operation mode of a POS terminal. FIG. 3 is a diagram illustrating switching of the operation mode of a POS terminal. FIG. 3 is a schematic diagram illustrating an outline of operation in normal mode. 3 is a flowchart illustrating an outline of operation in normal mode. FIG. 3 is a schematic diagram illustrating an outline of operation in normal mode. 3 is a flowchart illustrating an outline of the operation in normal mode. FIG. 2 is a schematic diagram illustrating an outline of operation in full self mode. 3 is a flowchart illustrating an outline of operation in full self mode. FIG. 2 is a schematic diagram illustrating an outline of operation in double scan mode. 3 is a flowchart illustrating an outline of operation in double scan mode. This is an example of a display on a POS terminal in full self mode. This is an example of a display on a POS terminal in full self mode. This is an example of a display on the POS terminal 20 in normal mode. This is an example of a display on the POS terminal 20 in normal mode. This is an example of a display on the POS terminal 20 in normal mode. This is an example of a display on the POS terminal 20 in normal mode. This is an example of a display on the POS terminal 20 in normal mode. This is an example of a display on the POS terminal 20 in normal mode. It is an explanatory diagram showing an outline of advertisement display in full self mode. It is an explanatory diagram showing an example of an advertisement information table. FIG. 7 is an explanatory diagram showing an example of screen transition when correcting a registered product in full self-mode. FIG. 7 is an explanatory diagram showing an example of screen transition when correcting a registered product in full self-mode. FIG. 7 is an explanatory diagram showing an example of screen transition when correcting a registered product in full self-mode. It is an explanatory view showing another example of a screen when correcting a product in full self mode. 3 is a flowchart illustrating an example of product registration processing in full self-mode performed by the POS terminal 20. FIG. 7 is a flowchart illustrating an example of product correction processing performed by the POS terminal 20 in full self-mode. It is an explanatory diagram showing an example of the transition of the screen on the customer side when correcting a product in the semi-self mode. It is an explanatory diagram showing an example of the transition of the screen on the customer side when correcting a product in the semi-self mode. FIG. 6 is an explanatory diagram showing an example of the screen transition of the clerk-side display unit 210 of the upstream POS terminal 20 when correcting a product. It is an explanatory view showing another example of a screen when correcting a product in semi-self mode. It is an explanatory view showing another example of a screen when correcting a product in semi-self mode. It is an explanatory view showing another example of a screen when correcting a product in semi-self mode. It is a flow chart showing an example of payment processing in semi-self mode performed by the downstream POS terminal 20 (payment device). 12 is a flowchart illustrating an example of a process performed by an upstream POS terminal 20 (registration device) when an approval request is received. It is a block diagram of the network which shows the shopping system based on Embodiment 2 of this invention. 3 is an explanatory diagram showing an example of various information managed by a cloud server 300. FIG. FIG. 3 is a sequence diagram showing the flow of processing of the shopping system according to the second embodiment. FIG. 7 is an explanatory diagram showing an example of screen transition when accepting product cancellation in Embodiment 2. FIG. FIG. 7 is an explanatory diagram showing an example of screen transition when accepting a change in the quantity of products in Embodiment 2; FIG. 7 is an explanatory diagram showing an example of a payment screen according to the second embodiment.

(Embodiment 1)
FIG. 1 is a network configuration diagram of a POS (Point Of Sales) system according to Embodiment 1 of the present invention. The POS system 1 shown in FIG. Connected for communication. Hereinafter, the POS terminals 20-1, 20-2, and 20-3 will be collectively referred to as the POS terminal 20 unless otherwise distinguished. Note that the POS system 1 may further include a monitoring terminal (not shown) that displays the status (operation mode, processing status, etc.) of the POS terminal 20 and controls the POS terminal 20.

The POS system 1 can be introduced into various stores (convenience stores, supermarkets, etc.).

FIG. 2 is a diagram showing an example of installation of the POS terminal 20. As shown in FIG. FIG. 2A is a perspective view of the POS terminal 20 and the like as viewed from the customer side. FIG. 2(B) is a perspective view of the POS terminal 20 and the like as viewed from the store clerk's side. As shown in FIG. 2(A), a counter is placed on the right side of the POS terminal 20 when viewed from the customer side.

FIG. 3 is a diagram showing an example of the appearance of the POS terminal 20. As shown in FIG. FIG. 3(A) is a perspective view of the POS terminal 20 viewed from the customer side. FIG. 3(B) is a perspective view of the POS terminal 20 viewed from the store clerk side. FIG. 4 is a diagram showing a configuration example of the POS terminal 20. As shown in FIG. In FIGS. 3 and 4, the same parts are denoted by the same reference numerals.

Hereinafter, a configuration example of the POS terminal 20 shown in FIG. 4 will be described with reference to FIG. 3. The POS terminal 20 includes a CPU 201, a ROM 202, a RAM 203, a hard disk 204, a customer side display section 205, a customer side scanner section 206, a card payment section 208, a change machine 209, a clerk side display section 210, It includes a key operation section 211, a clerk side scanner section 212, a printing section 213, an audio output section 214, and a communication section 215. These can communicate with each other via a bus. Note that the symbols 211a, 211b, and 211c will be described later.

The CPU 201 is a central processing unit, and controls the operation of the POS terminal 20 by reading and executing programs stored in the ROM 202 .
The ROM 202 is a read-only memory and stores various information used by the CPU 201 including programs.

RAM 203 is a read/write memory and stores various information. For example, the RAM 203 stores information acquired from outside (for example, a product master acquired from the store controller 10), information generated during processing (for example, registration information (registration data) generated in a registration process for registering a product, purchase (Settlement information, etc. generated in the settlement process of settling (settlement) products) is stored.

Hard disk 204 stores various information. For example, instead of the ROM 202, the hard disk 204 may store programs executed by the CPU 201. Further, instead of the RAM 203, information acquired from the outside or information generated during processing may be stored.

The customer-side display unit 205 is a touch display for customers, and displays various information to the customer and receives various inputs from the customer.
The customer-side scanner unit 206 is a scanner unit for customers, and optically reads various information. For example, the customer side scanner unit 206 optically scans barcodes attached to products (product codes, etc.) and codes (barcodes, two-dimensional codes, etc.) printed on checkout tickets (registered trademarks). read. In addition to the above, the customer side scanner unit 206 also scans codes (barcodes, 2 (dimensional code, etc.) may also be read. Note that although the customer-side scanner unit 206 is used when a customer registers a product, the customer may register the product using other methods. For example, if a preset key (button for ordering a product) corresponding to a product is displayed on the customer side display section 205, the customer may operate (press) the preset key to register the product.

The card payment unit 208 is a payment mechanism using various cards (credit cards, prepaid cards such as transportation cards, point cards, etc.). The card payment section 208 includes a card recognition section (reading section), a display section, and an operation section. The card recognition unit magnetically or electrically reads information on various cards. The read information is used for payment (settlement) of purchased products. In addition, when using the recognized information for payment (settlement) of the purchased product (in other words, in the case of credit card payment, prepaid card payment, prepaid card payment, the card recognition unit uses the points held by the point card. In addition to cases where the recognized information is not used for payment (settlement) of the purchased product (e.g., when giving benefits by presenting a credit card, when giving points to a point card) etc.) may also recognize various cards. Note that although the card payment unit 208 of this embodiment includes a card recognition unit (reading unit), a display unit, and an operation unit, the card payment unit 208 may include at least a card recognition unit. Further, the card recognition unit of this embodiment is compatible with contact cards (IC cards, magnetic cards), but instead of or in addition to contact cards, it can be used with non-contact cards (IC cards). It may correspond to.

The change machine 209 (cash payment unit) is a cash payment mechanism, has an inlet for bills and coins, and an outlet for bills and coins, calculates the amount inserted into the inlet, and compares the input amount with the purchase amount. The difference in change amount is calculated and the change is discharged from the discharge port. The change machine 209 faces the customer and is operated by the customer. Note that when banknotes or coins are inserted into the input slot, they are detected by a sensor (detection of insertion, detection of number of coins for each denomination, etc.). The card payment unit 208 and the change machine 209 form a payment unit.

The clerk-side display unit 210 is a touch display for the clerk, and displays various information to the clerk and receives various inputs from the clerk.
The key operation unit 211 is composed of various keys (hardware keys, buttons), and receives various inputs from the store clerk.
The clerk side scanner section 212 is a scanner section for the clerk, and optically reads various information. For example, the clerk-side scanner unit 212 optically reads a barcode attached to a product or a clerk code attached to a clerk's name tag. In addition to the above, the clerk-side scanner unit 212 may read codes printed on checkout tickets, gift certificates, and various cards.

Note that although the clerk-side scanner section 212 is used when a store clerk registers a product, the store clerk may register the product using other methods. For example, if a key corresponding to a product (for example, a key corresponding to a sports newspaper, etc.) is arranged on the key operation unit 211, a store clerk may operate (press) the key and register the product. good. Further, when a preset key corresponding to a product is displayed on the store clerk side display section 210, the store clerk may operate the preset key to register the product.

The printing unit 213 prints and issues various media (receipts, billing tickets, etc.). The printing unit 213 can rotate freely (the direction of the media issuing port) from the clerk side to the customer side and from the customer side to the clerk side. The orientation of the printing unit 213 may be changed manually, or may be automatically changed (mechanically controlled, etc.), for example, based on switching of the operation mode (details will be described later). Note that a sensor or the like may be used to detect whether the printing unit 213 is oriented correctly or incorrectly. Note that switching the operating mode is also referred to as shifting the operating mode.

The audio output unit 214 outputs audio. For example, the audio output unit 214 outputs audio guidance and the like.
The communication unit 215 transmits and receives information to and from other terminals (other POS terminals 20, store controllers 10).

(Summary of each operation mode)
Next, the operation mode of the POS terminal 20 will be explained. POS terminal 20 has multiple operation modes. This operation mode is the operation mode during normal business operations (operation mode related to registration processing and payment processing), and is the aggregation mode for aggregating and inquiring sales and balances, and the operation mode for store clerks, maintenance personnel, etc. to perform setting work and maintenance work. It does not include maintenance mode when training is performed, training mode when new employees are training, etc.

FIG. 5 is a diagram schematically explaining the operation mode of the POS terminal 20. As shown in FIG. The POS terminal 20 has, for example, three types of operation modes (normal mode (standard mode), full self mode, and semi-self mode (accounting only mode)) shown in FIG. 5(A). Further, the POS terminal 20 may have a normal mode (restricted mode) shown in FIG. 5(B) instead of or in addition to the normal mode (standard mode) shown in FIG. 5(A). Further, the POS terminal 20 may have a semi-self mode (registration-only mode) shown in FIG. 5(B) instead of or in addition to the normal mode (standard mode) shown in FIG. 5(A). Further, the POS terminal 20 may have a semi-self mode (registration only mode) shown in FIG. 5(B) instead of or in addition to the semi-self mode (accounting only mode) shown in FIG. 5(A).

In FIG. 5(A), the columns indicate each operation mode, and the rows indicate each function (“Product registration (staff side)”, “Product registration (customer side)”, “Money insertion”, ..., “Customer side”). "Reading of Account Tickets"). The same applies to FIG. 5(B) (however, illustration of each function is omitted in FIG. 5(B)).

In Fig. 5(A) (same as Fig. 5(B)), the "〇" in the column specified by the column and row indicates that the function of the corresponding row is enabled in the operation mode of the corresponding column. . For example, "〇" in the column specified by the column "Normal mode (Standard mode)" and the row "Product registration (Staff side)" indicates that product registration (Staff side) is valid in the normal mode (Standard mode). It shows that. Further, a "-" in a column specified from a column and a row indicates that the function of the row is disabled in the operation mode of the column. For example, a "-" in the column specified from the column "Normal Mode" and the row "Product Registration (Customer Side)" indicates that product registration (Customer Side) is disabled in the normal mode.

(Explanation of each function)
The outline of each function shown in FIG. 5(A) will be explained below.

(Product registration (staff side))
"Product registration (store clerk side)" is a function for registering purchased products on the clerk side (clerk side scanner section 212, clerk side display section 210, key operation section 211). In other words, this is a function that executes the registration process of the purchased product by the store clerk's operations (scanning by the store clerk's scanner section 212, touching the store clerk's display section 210, operating the key operation section 211).

(Product registration (customer side))
"Product registration (customer side)" is a function for registering purchased products on the customer side (customer side scanner section 206, customer side display section 205). In other words, this is a function that executes the registration process of the purchased product by the customer's operation (scanning by the customer side scanner unit 206, touching the customer side display unit 205).

(Inserting money)
"Money insertion" is a function that accepts the insertion of money (banknotes, coins). In other words, it is a function that accepts a payment operation using cash (insertion of money into the change machine 209).

(Sending registration information to other terminals)
"Sending registration information to another terminal" is to send the registration information generated in the registration process to another terminal (another terminal that can execute the payment process, for example, another POS terminal 20) (directly to the other terminal). This is a function to send the information, or indirectly send it to another terminal via the store controller 10, a monitoring terminal, etc. (hereinafter the same).

(Issuance of accounting ticket)
"Issuance of accounting ticket" is a function of encoding the registration information generated in the registration process and issuing a printed medium (accounting ticket).

(Receiving registration information from other terminals)
"Receiving registration information from another terminal" means receiving registration information generated in the registration process of another terminal (directly from another terminal, or indirectly via the store controller 10, monitoring terminal, etc.). This is a function to receive data from other terminals (hereinafter the same). Note that the terminal that has received the registration information from another terminal executes the payment process based on the registration information.

(Reading the bill)
"Reading a bill" is a function of reading a bill (specifically, a code printed on a bill or coded information). Note that the terminal that reads the bill issued by another terminal executes the payment process based on the registration information obtained by reading the bill.

(Explanation of each operation mode)
Next, the outline of each operation mode shown in FIGS. 5(A) and 5(B) will be explained.

(Normal mode (standard mode))
As shown in FIG. 5A, the normal mode (standard mode) is an operation mode in which product registration (on the clerk's side) is set to valid "0" and product registration (on the customer's side) is set to disabled as "-". In other words, the normal mode (standard mode) is an operation mode in which the registration process is not executed on the customer's side but on the clerk's side.

In addition, in the normal mode (standard mode), as shown in Figure 5 (A), all functions such as inserting money, sending registered information to other terminals, and issuing accounting tickets are set to "〇". This is the operating mode. That is, in the normal mode (standard mode), the checkout process after the registration process on the clerk's side can be executed by the own terminal or can be executed by another terminal. Specifically, in the normal mode (standard mode), the payment process is executed on the own terminal by accepting the insertion of money into the change machine 209, and the payment process is executed on the own terminal by sending registration information to another terminal (or the payment ticket is sent to the other terminal). (issuing) to have another terminal execute the payment process.

Further, the normal mode (standard mode) is an operation mode in which reception of registration information from other terminals and reading of billing tickets are both enabled as shown in FIG. 5(A). That is, in the normal mode (standard mode), payment processing can be executed based on registration information generated at another terminal. Note that the payment process after receiving the registration information (or after reading the bill) may be executed in the semi-self mode shown in FIG. 5(A). In other words, if registration information is received (or a checkout ticket is read) while in normal mode (standard mode), normal mode (standard mode) automatically changes to semi-self mode (accounting only mode). The payment process may be executed in semi-self mode (accounting only mode). In addition, if you move to semi-self mode (accounting only mode) and execute payment processing, the semi-self mode (accounting only mode) will automatically change to normal mode (standard mode) (permission may be requested from the store staff). You may transition (return) or remain in semi-self mode (accounting only mode).

In addition, in the normal mode (standard mode), at least one of receiving registration information from another terminal and reading a bill may be set to "-".

(Full self mode)
As shown in FIG. 5A, the full self mode is an operation mode in which product registration (on the customer side) is enabled. In other words, the full self mode is an operation mode that assumes registration processing on the customer side. However, in full self-mode, product registration (on the store clerk's side) is also valid. In other words, the full self mode is an operation mode that assumes registration processing on the customer's side and also allows registration processing on the clerk's side. Note that a state in which registration processing is performed on both the customer side and the clerk side is sometimes referred to as double scan mode.

In the example shown in Figure 5 (A), in full self mode, product registration (on the clerk's side) is set to valid "〇", but in full self mode, product registration (on the clerk's side) is set to disabled as "-". Good too.

In addition, as shown in Figure 5 (A), the full self mode is an operation mode in which the insertion of money is enabled with "〇" and the transmission of registration information to other terminals and the issuance of accounting tickets are disabled with "-". It is. In other words, the full self mode is an operation mode that assumes payment processing at the terminal.

In addition, as shown in Figure 5 (A), in full self mode, as in normal mode (standard mode), receiving registration information from other terminals and reading billing tickets are both enabled. This is the operating mode. That is, like the normal mode (standard mode), in the full self mode, payment processing can be executed based on registration information generated at another terminal. Note that the payment process after receiving the registration information (or after reading the bill) may be executed in the semi-self mode shown in FIG. 5(A). In other words, if registration information is received (or a checkout ticket is read) while in full-self mode, the mode automatically shifts from full-self mode to semi-self mode (accounting-only mode), and The payment process may also be executed in a special mode (dedicated mode). In addition, if you execute the payment process by transitioning to semi-self mode (accounting only mode), you may automatically transition (return) from semi-self mode (accounting only mode) to full self-mode, or You may leave it in accounting-only mode).

(Semi-self mode (accounting only mode))
In the semi-self mode (accounting only mode), as shown in Figure 5 (A), receiving registration information from other terminals, reading billing tickets, and inserting money are enabled, and product registration (clerk side) is enabled. This is an operation mode in which product registration and product registration (on the customer side) are disabled as "-". In other words, the semi-self mode (accounting-only mode) is an operation mode in which the own terminal does not perform the registration process, and only performs the payment process based on the registration information generated at the other terminal. In addition, since the semi-self mode (accounting only mode) is an operation mode in which registration processing is not executed (registration information is not generated), the transmission of registration information to other terminals is also not possible, as shown in FIG. 5(A). Issuance of accounting tickets is also marked as invalid.

(Normal mode (limited mode))
As shown in Figure 5 (B), the normal mode (restricted mode) is used to send registered information to other terminals and issue check tickets, which was set to valid in the normal mode (standard mode) of Figure 5 (A). and is set to "-" to indicate that it is invalid. In other words, the normal mode (restricted mode) is an operation mode in which the function of causing another terminal to execute payment processing, which is permitted in the normal mode (standard mode), is restricted.

(Semi-self mode (registration only mode))
In the semi-self mode (registration only mode), as shown in Figure 5 (B), product registration (on the clerk's side), transmission of registration information to other terminals, and issuance of checkout tickets are enabled, and product registration ( (Customer side), inserting money, receiving registration information from other terminals, and reading billing tickets are disabled in this operation mode. In other words, the semi-self mode (registration only mode) is an operation mode in which the own terminal exclusively executes the registration process and causes another terminal to execute the payment process. Note that in the semi-self mode (registration only mode), product registration (customer side) is set to invalid because it is assumed that the registration operation is performed by a store clerk.

(About enabling and disabling functions)
In addition, in the above description, the POS terminal 20 performs various functions provided by the POS terminal 20 itself (product registration (staff side), product registration (customer side), money insertion, . . , reading the bill), it was explained that the difference is whether it is valid "〇" or invalid "-". In other words, in the above, the POS terminal 20 originally performs all the functions (product registration (staff side), product registration (customer side), inserting money, ..., reading the bill as shown in FIG. 5A). (For example, as shown in FIG. 5A, when the POS terminal 20 is in normal mode (standard mode), some functions are disabled depending on the operation mode.) Registration (customer side) is disabled (-), and when in full self-mode, sending registration information to other terminals and issuance of billing tickets are disabled (-).

However, the POS terminal 20 only needs to have different executable functions depending on the operation mode, and the POS terminal 20 does not necessarily have all the functions originally, but some of the functions are disabled depending on the operation mode. It is not necessary to have such a configuration. For example, the POS terminal 20 does not have all the functions (programs for realizing the functions) from the beginning, but depending on the operation mode (for example, when switching the operation mode), Obtain and execute a program to realize the function (function corresponding to the function marked as enabled in Figure 5) from the outside (for example, store controller 10, monitoring terminal, server outside the store (cloud, etc.)) In addition, if there is a program to realize a function that is not necessary for the operation mode (a function corresponding to the function marked as disabled in Figure 5) (if it is retained), the program is It may be in an unexecutable state (for example, it may be erased). Note that after a program for realizing an unnecessary function is rendered unexecutable, a program for realizing a necessary function may be acquired and made executable. For example, when switching the operation mode, the POS terminal 20 first makes all programs unexecutable, regardless of the destination operation mode, and then executes The program may also be obtained from an external source and placed in an executable state. In other words, depending on the operation mode, the configuration of the POS terminal 20 may be such that some of the various functions originally provided are disabled, or depending on the operation mode, some of the various functions originally provided may be disabled. It is also possible to provide only appropriate functions.

Above, we have explained the normal mode (standard mode), full self mode, semi-self mode (accounting only mode) in Figure 5 (A), and the normal mode (restricted mode) and semi-self mode (registration only mode) in Figure 5 (B). However, the following description will focus on the normal mode (standard mode), full self-mode, and semi-self mode (accounting-only mode) shown in FIG. 5(A). Note that in the following description, the normal mode (standard mode) may be simply referred to as normal mode. Further, the semi-self mode (accounting only mode) may be simply referred to as the semi-self mode.

(Switching (transition) of operation mode)
Next, switching (transition) of the operation mode of the POS terminal 20 will be explained. Basically, the operation mode of the POS terminal 20 is switched according to an explicit mode switching operation (also referred to as a mode transition operation, which will be described in detail later) by a store clerk. Furthermore, the operation mode of the POS terminal 20 may be switched in accordance with an operation different from the mode switching operation (for example, reading a clerk code, etc.).

Furthermore, the operation mode of the POS terminal 20 may be switched without being operated by a store clerk. Specifically, the operation mode of the POS terminal 20 may be switched in accordance with a mode switching command (mode switching instruction) from another terminal (POS terminal 20, monitoring terminal, mobile terminal, etc.). Further, the operation mode of the POS terminal 20 may be switched according to temporal conditions (for example, the elapsed time since the last operation, a fixed time according to a schedule, etc.). Furthermore, the operation mode of the POS terminal 20 may be switched at the start of processing (for example, at the start of payment processing based on received registration information, at the start of payment processing based on a bill, etc.). Furthermore, the POS terminal 20 may be configured to switch its operating mode at the end of the process (for example, at the end of the payment process based on the received registration information, or at the end of the payment process based on the bill).

FIG. 6 is a diagram illustrating switching of the operation mode of the POS terminal 20. The left side of FIG. 6 shows the combination of operation modes before and after switching (operation mode before switching→operation mode after switching), and the right side shows conditions (an example) for switching the operation modes. For example, the row a indicates that examples of conditions for switching the operating mode from the normal mode to the full self mode include a mode switching operation, a mode switching command, and a predetermined period of time (non-use). In other words, when the operating mode is normal mode, if there is a mode switching operation, a mode switching command, a predetermined period of time elapsed (non-use), etc., the operating mode will switch from normal mode to full self mode. It shows. Note that details of the mode switching operation will be described later.

(Normal mode → Full self mode)
As shown in a, when in the normal mode, for example, a mode switching operation, a mode switching command (a mode switching command specifying full self mode as the destination operation mode, etc.), a predetermined time elapsed (a predetermined time elapsed), etc. (not in use), the operating mode switches from normal mode to full self mode.

(Normal mode → Semi-self mode (accounting only mode))
As shown in b, when in normal mode, for example, a mode switching operation, a mode switching command (a mode switching command that specifies semi-self mode (accounting only mode) as the destination operation mode, etc.), etc. In this case, the operation mode is switched from normal mode to semi-self mode (accounting only mode). Furthermore, while in normal mode, the operating mode may be switched from normal mode to semi-self mode (accounting-only mode) when registration information is received from another terminal or when a checkout ticket is read, for example. .

(Full self mode → normal mode)
As shown in c, if, for example, there is a mode switching operation or a mode switching command (such as a mode switching command that specifies the normal mode as the destination operation mode) while in the full self mode, The operating mode switches from full self mode to normal mode.

(Full self mode → Semi self mode (accounting only mode))
As shown in d, when in full self mode, for example, there is a mode switching operation, a mode switching command (a mode switching command that specifies semi-self mode (accounting only mode) as the destination operation mode, etc.), etc. In this case, the operation mode switches from full self mode to semi self mode (accounting only mode). In addition, when in full self mode, for example, if registration information is received from another terminal or a checkout ticket is read, the operating mode will be switched from full self mode to semi self mode (accounting only mode). Good too.

(Full self mode → double scan mode)
As shown in e, if, for example, a clerk code is read while in the full self mode, the operation mode is switched from the full self mode to the double scan mode. Note that the double scan mode is an aspect of the full self mode (a state in which the function of product registration (on the staff side) is used in addition to the function of product registration (on the customer side); see FIG. 5(A)).

Note that if a clerk code is read while in full self mode, the operation mode may always switch to double scan mode regardless of the product registration state, or the operation mode may be changed to double scan mode regardless of the product registration state. It may be possible to switch to a different operation mode depending on the situation. For example, if a store employee code is read while the product has not yet been registered (in other words, the product has not been registered by the customer), the system will switch from full self mode to normal mode, and If a clerk code is read while a product is being registered (in other words, if the product is being registered by a customer), the system will switch from full self mode to double scan mode. good.

(Semi-self mode (accounting only mode) → normal mode)
As shown in f, when in semi-self mode (accounting only mode), for example, a mode switching operation, a mode switching command (a mode switching command, etc. in which normal mode is specified as the destination operation mode), etc. In this case, the operation mode is switched from semi-self mode (accounting only mode) to normal mode. In addition, when in semi-self mode (accounting only mode), for example, if payment processing (for example, payment processing based on received registration information, payment processing based on checkout ticket) is completed, semi-self mode (accounting only mode) ) to the normal mode.

(Semi-self mode (accounting only mode) → Full self-mode)
As shown in g, when in semi-self mode (accounting only mode), for example, there is a mode switching operation, a mode switching command (a mode switching command that specifies full self mode as the destination operation mode, etc.), etc. In this case, the operation mode switches from semi-self mode (accounting only mode) to full self-mode. In addition, when in semi-self mode (accounting only mode), for example, if payment processing (for example, payment processing based on received registration information, payment processing based on checkout ticket) is completed, semi-self mode (accounting only mode) ) to full self mode.

Note that the mode switching operation may be any operation that specifies the destination operation mode according to the operation. For example, when providing (or displaying) buttons for different destinations, the operation mode may be switched to each destination in response to a mode switching operation by pressing each button. Further, in the case of providing (or displaying) one button whose destination changes each time the button is pressed, the operation mode may be changed each time the button is pressed to switch the mode.

Note that a button for selecting the destination operation mode and a button for determining the transition to the operation mode selected by the button may be separately provided (or displayed).

(Transition of operation mode by mode switching operation)
Next, a description will be given of the transition of the operation mode by the mode switching operation. The operating mode of the POS terminal 20 is switched according to an explicit mode switching operation by a store clerk (see FIG. 6). Specifically, the operation mode is switched according to the operation of the mode switching button 211a (see FIG. 3(B)) arranged at the top and rightmost end of the key operation unit 211.

Note that since the mode switching button 211a is arranged at the corner of the key operation section 211, it is possible to reduce operational errors when switching the operating mode, and it is also possible to easily switch the operating mode. In other words, when the mode switching button 211a is located at the corner of the key operation unit 211, compared to the case where the mode switching button 211a is located near the center of the key operation unit 211, for example, the mode switching button 211a that is the operation target is Since the number of adjacent buttons is small, it is difficult to make operational errors such as operating other buttons in a hurry, and the position of the mode switching button 211a to be operated can be instantly identified, allowing stress-free mode switching operations. It can be performed.

Furthermore, since the mode switching button 211a is arranged at the upper right corner of the key operation unit 211 (the uppermost and rightmost corner), the mode switching operation can be performed not only when the clerk is on the clerk's side but also when the customer is on the customer's side. You will be able to do this. In other words, the clerk on the customer's side usually cannot visually recognize each button on the key operation section 211, but when it comes to the mode switching button 211a located at the upper right corner of the key operation section 211, the clerk on the customer's side reaches out and gropes. Since the mode switching button 211a to be operated can be easily recognized only by the touch of the hand, the clerk on the customer's side can perform the mode switching operation without moving to the clerk's side.

Note that in this embodiment, the mode switching button 211a is placed at the upper right corner of the key operation unit 211, but if it is in a position that can be recognized only by groping (a position that can be recognized relatively easily), the mode switching button 211a can be changed to The switching button 211a may be arranged at a position other than the upper right corner of the key operation section 211. Additionally, instead of or in addition to arranging the mode switching button 211a in a position that can be recognized only by groping (for example, in the upper right corner), it is possible to distinguish it from other buttons even from the customer's perspective. A mode switching button 211a may be formed on the screen. For example, the size of the mode switching button 211a may be made different from the size of other buttons to the extent that it can be distinguished by groping, or the shape of the mode switching button 211a may be made different from the shape of the other buttons. The height of the mode switching button 211a may be different from the height of other buttons (for example, the mode switching button 211a may be made to protrude more than the other buttons). ), the feel of all or part of the surface of the mode switching button 211a (the surface that the hand touches) may be made different from that of other buttons (for example, only the surface of the mode switching button 211a may be made rough or bumpy). It may be a tactile function, or a protrusion or depression may be provided only on the surface of the mode switching button 211a).

Note that in this embodiment, the mode switching button 211a is arranged on the key operation section 211 in consideration of various advantages as described above, but instead of arranging the mode switching button 211a on the key operation section 211 Alternatively, in addition, a mode switching button (not shown) may be arranged on the screen displayed on the clerk side display section 210.

(Operation of each operation mode)
FIG. 7 is a schematic diagram illustrating an outline of the operation in the normal mode. Specifically, FIG. 7 is a schematic diagram showing the flow of processing and the actions of people (clerks, customers) when payment processing is executed on the own terminal in the normal mode. FIG. 8 is a flowchart outlining the operation in normal mode. Specifically, FIG. 8 is a flowchart illustrating an outline of the operation when the terminal executes payment processing in the normal mode.

In the normal mode (the same applies whether the payment process is executed on the own terminal or when the payment process is executed on another terminal), the store clerk scans the customer's purchased products on the store clerk's side (the clerk's scanner section 212, the clerk's display section 210, The key operation unit 211) is used to register (upper row of FIG. 7). In other words, the POS terminal 20 executes the registration process for the purchased product (in the upper row of FIG. ).

When the registration process by the store clerk is completed, the customer checks the total amount of purchased items on the store clerk side display section 210, inserts money (cash) into the change machine 209, or operates the card payment section 208 to make payment. (Bottom row of Figure 7). That is, the POS terminal 20 executes the payment processing in response to the customer's operations (insertion of cash into the change machine 209, operation of the card payment unit 208) (lower part of FIG. 7).

That is, when performing the payment process on the own terminal in the normal mode, as shown in FIG. 8, the store clerk first scans the product (step S10: YES) and registers the product (step S11). After pressing the subtotal key (for example, the subtotal key displayed on the clerk side display section 210 or the subtotal key arranged on the key operation section 211) (step S30: YES), the customer side, for example, presses the change machine 209. The payment is made (step S50), and the process is completed. Note that the subtotal key in step S30 is an operation key for completing the registration process, and may also be referred to as a subtotal button, registration completion key, registration completion button, checkout key, checkout button, etc.

Note that the customer may wait until the clerk completes the registration process (until the total amount is determined), or may insert cash into the change machine 209 before the registration process is completed. In other words, the POS terminal 20 can accept deposits during the registration process (upper row of FIG. 7).

Additionally, the customer may select a payment method (also referred to as payment type, payment method, or payment type) before the registration process is completed. That is, the POS terminal 20 can accept the selection of a payment method during the registration process.

Further, the clerk may wait until the customer completes payment (until the customer takes the change or receipt), or may register the purchased items of the next customer. In other words, the POS terminal 20 can register the purchased products of the next customer during the payment process (lower row of FIG. 7). Further, the clerk may be absent while the customer is making payment (lower row of FIG. 7). In other words, you may finish serving the customer while the customer is making payment.

In addition, when there is change, the POS terminal 20 controls the payout of change and change tags by the change machine 209 in order to prevent forgetting to take change, and uses a sensor etc. to detect when the customer has removed the change and change tags. After this recognition, issuing of a receipt by the printing unit 213 may be controlled. The same applies to other operation modes.

FIG. 9 is a schematic diagram illustrating an outline of the operation in the normal mode. Specifically, FIG. 9 is a schematic diagram showing the flow of processing and the actions of people (clerks, customers) when having another terminal execute payment processing in the normal mode (standard mode). FIG. 10 is a flowchart illustrating an outline of the operation in the normal mode. Specifically, FIG. 10(A) is a flowchart illustrating an outline of the operation when causing another terminal to execute payment processing in normal mode (standard mode). Note that FIG. 10(B) is a flowchart showing the basic flow of operations in other terminals (other devices) in FIG. 10(A).

In the normal mode (the same applies whether the payment process is executed on the own terminal or when the payment process is executed on another terminal), the store clerk scans the customer's purchased products on the store clerk's side (the clerk's scanner section 212, the clerk's display section 210, The key operation unit 211) is used to register (upper row of FIG. 9). In other words, the POS terminal 20 (POS terminal 20-1 in the example of FIG. 9) performs the registration process of the purchased product through the operations of the clerk (operation of the clerk's scanner section 212, clerk's display section 210, key operation section 211, etc.). (upper row of Figure 9).

When the registration process by the store clerk is completed, the customer moves to another POS terminal 20 (POS terminal 20-2 in the example of FIG. 9), checks the total amount of purchased items on the store clerk side display section 210, and then presses the change machine. 209, or operate the card payment section 208 to settle the payment (lower row of FIG. 9). In other words, the other POS terminals 20 execute payment processing based on the customer's operations (insertion of money into the change machine 209, operation of the card payment section 208) (lower part of FIG. 9).

Note that the other POS terminal 20 (POS terminal 20-2) is supplied with information necessary for payment processing (registration information generated at the POS terminal 20-1, etc.).

Note that the store clerk specifies, at the POS terminal 20-1, which POS terminal 20 (in the example of FIG. 9, either the POS terminal 20-2 or the POS terminal 20-3) is to execute the payment process. Alternatively, the clerk issues a medium (ticket) at the POS terminal 20-1 to be read by the POS terminal 20 (in the example of FIG. 9, POS terminal 20-2 or POS terminal 20-3) that executes the payment process. It's okay.

In other words, when having another terminal execute the payment process in the normal mode, as shown in FIG. ). After the subtotal key (for example, the subtotal key displayed on the clerk side display section 210 or the subtotal key arranged on the key operation section 211) is pressed (step S30: YES), for example, a checkout process is executed, etc. When the POS terminal 20 is specified (step S31: YES), registration information is sent to the specified POS terminal 20 (step S32), and the registration side processing is completed.

Incidentally, after specifying another terminal, the clerk can register the purchased product of the next customer (lower row of FIG. 9). Further, the clerk may be absent after specifying another terminal (lower row of FIG. 9).

Further, in the example shown in FIG. 10(A), another POS terminal 20 is specified after pressing the subtotal key, but another POS terminal 20 may be specified without pressing the subtotal key. . For example, a subtotal key and a key for specifying another POS terminal 20 may be arranged on the registration screen (a key for issuing a bill may also be arranged), and a key for specifying a POS terminal 20 may be arranged. The registration information may be transmitted when the key is pressed. In the mode of specifying another POS terminal 20 without pressing the subtotal key, it is not necessary to press the subtotal key after pressing the key for specifying another POS terminal 20.

Further, although omitted in the example shown in FIG. 10(A), a bill may be issued to be read at another POS terminal 20, and the other POS terminal 20 may execute the payment process. Note that the key for issuing the bill may be pressed after the subtotal key is pressed, or may be pressed before the subtotal key is pressed. In the mode in which the key for issuing a bill is pressed before pressing the subtotal key, it is not necessary to press the subtotal key after pressing the key for issuing a bill.

Note that the other POS terminal 20 (POS terminal 20-2 in the example of FIG. 9) that has received the registration information enters the semi-self mode after receiving the registration information (step S40: YES), as shown in FIG. 10(B). (accounting only mode), it shifts (switches) to semi-self mode (accounting only mode). That is, if the current operation mode (at the time of receiving registration information) is the full-self mode (step S41: YES), the transition is made from the full-self mode to the semi-self mode (accounting only mode) (step S42), and the current operation mode is changed to If it is the normal mode (step S43: YES), the normal mode is shifted to the semi-self mode (accounting only mode) (step S42). Then, on the customer side, payment is made using the change machine 209, for example (step S50), and the processing on the payment side is completed.

In the example shown in FIG. 10(B), the other POS terminal 20 that has received the registration information shifts to the semi-self mode (accounting only mode) if it is not in the semi-self mode (accounting only mode) after receiving the registration information. However, there is no need to shift to semi-self mode (accounting only mode). In other words, since the payment process is possible even in the normal mode or the full self-mode (see FIG. 5), the payment process may be executed in the normal mode or the full self-mode.

As mentioned above, the normal mode (standard mode) is a function in which the store clerk executes the registration process and then the customer of the own terminal executes the payment process using the registration information generated in the registration process (Figure 7 , see FIG. 8), and a function to send the registration information generated in the registration process to another terminal (another terminal that can execute the payment process; for example, another POS terminal 20) and cause the other terminal to execute the payment process. (See Figures 9 and 10) and the registration information (or information for acquiring the registration information) generated in the registration process is converted into a code (barcode, two-dimensional code, etc.) and printed to issue a payment ticket. This includes a function that causes the other terminal to execute payment processing.

On the other hand, the normal mode (restricted mode) is one of the functions of the normal mode (standard mode) described above, as shown in FIG. A function that allows the terminal to execute the payment process, and a payment ticket that is encoded and printed with the registration information generated in the registration process (or information for acquiring the registration information) is issued, and the payment process is sent to the other terminal. This mode limits the functions that can be executed.

In addition, among the functions of the normal mode (standard mode) described above, there is a function that sends the registration information generated in the registration process to another terminal and causes the other terminal to execute the payment process, and a function that causes the registration information generated in the registration process ( The function of issuing a checkout ticket that is encoded and printed (or information for acquiring the registration information) and having the other terminal execute the payment process is also a function of the semi-self mode (registration-only mode). In other words, the semi-self mode can be classified into the registration-only mode and the accounting-only mode, but in the semi-self mode (registration-only mode), as shown in FIG. 5(B), the registration information generated in the registration process is A function that sends data to a terminal and causes another terminal to execute payment processing, and issues a checkout ticket that is encoded and printed with the registration information generated in the registration process (or information for acquiring the registration information). This includes a function that causes the other terminal to execute payment processing. In other words, the semi-self mode (registration only mode) is one of the functions of the normal mode (standard mode) described above, in which the clerk executes the registration process and then uses the registration information generated in the registration process to operate the own terminal. This is a mode in which the ability to perform payment processing on the customer side is restricted. In other words, the semi-self mode (registration only mode) is an operation mode in which registration processing is executed exclusively.

As shown in Figure 5 (A), the semi-self mode (accounting only mode) has the function of receiving registration information generated in the registration process on another terminal and executing the payment process, and the function of receiving the registration information generated in the registration process on another terminal and executing the payment process. Includes a function to read Tao bills and perform payment processing. In other words, the semi-self mode (accounting only mode) is an operation mode in which payment processing is executed exclusively.

FIG. 11 is a schematic diagram illustrating an outline of the operation in full self mode. FIG. 12 is a flowchart outlining the operation in full self mode.

In the full self mode, the customer registers his or her purchased products on the customer side (customer side scanner unit 206, customer side display unit 205) (upper row of FIG. 11). In other words, the POS terminal 20 executes the registration process of the purchased product in response to the customer's operation (scanning by the customer side scanner unit 206, touching the customer side display unit 205) (upper row of FIG. 11).

When the registration process is completed, the customer confirms the total amount of purchased items on the customer side display section 205, inserts cash into the change machine 209, or operates the card payment section 208 to make payment (see the bottom row of Fig. 11). ). In other words, the POS terminal 20 executes the payment process based on the customer's operations (insertion of cash into the change machine 209, operation of the card payment unit 208) (lower part of FIG. 11).

That is, in the case of full self-mode, as shown in FIG. 12, the customer side scans the product (step S20: YES) and registers the product (step S21). After pressing the registration completion key (for example, the registration completion key displayed on the customer side display section 205) (step S40: YES), the customer side performs payment using the change machine 209 (step S50), and processes. is completed. Note that the registration completion key related to step S40 is an operation key for completing the registration process, and may also be referred to as a registration completion button, subtotal key, subtotal button, checkout key, checkout button, etc.

In addition, in the full self mode, as shown in FIG. 11, the customer side executes the registration process and the payment process, but this does not mean that the clerk side cannot do anything. In other words, even when the POS terminal 20 is operating in full self-mode, the store clerk can, for example, scan the product (double scan mode) or the store clerk can display various information. Is possible.

FIG. 13 is a schematic diagram illustrating the outline of the operation in double scan mode. FIG. 14 is a flowchart outlining the operation in double scan mode. Note that the double scan mode is one aspect of the full self mode, but in FIGS. 13 and 14, for convenience, both operation modes will be explained separately.

In the full self-mode, the customer registers his or her own purchased products on the customer side (upper row of FIG. 11, upper row of FIG. 13). In other words, the POS terminal 20 executes the registration process of the purchased product according to the customer's operation (upper row in FIG. 11, (upper row in FIG. 13)).

During the registration process by the customer, the store clerk registers the customer's purchased product (middle row in FIG. 13). That is, the POS terminal 20 executes registration processing based on operations by the customer and registration processing based on operations by the store staff (middle row of FIG. 13).

When the registration process is completed, the customer confirms the total amount of purchased items on the customer side display section 205, inserts cash into the change machine 209, or operates the card payment section 208 to make payment (see the bottom row of FIG. 13). ). That is, the POS terminal 20 executes the payment process in response to the customer's operations (insertion of cash into the change machine 209, operation of the card payment unit 208) (lower part of FIG. 13).

That is, when the clerk code is read by the clerk side scanner unit 212 as shown in FIG. 14(A) while executing the registration process in the full self mode (see FIG. 12) (step S110: YES). , the operation mode shifts from full self mode to double scan mode (step S111).

After shifting to the double scan mode, as shown in FIG. 14(B), the product is registered by scanning with the clerk side scanner unit 212 (step S10: YES), the product is registered (step S11), and the customer side scanner unit 206 is scanned (step S10: YES). The product is registered by scanning or the like (step S20: YES) (step S21). A subtotal key (for example, a subtotal key displayed on the clerk side display section 210 or a subtotal key arranged on the key operation section 211, etc.) or a registration completion key (for example, a registration completion key displayed on the customer side display section 205) After pressing the completion key, etc. (step S41: YES), the customer makes payment using, for example, the change machine 209 (step S50), and the process is completed.

Note that in the double scan mode, the clerk may wait until the customer completes payment (until the customer takes the change or receipt), or may register the purchased item for the next customer. In other words, the POS terminal 20 can register the purchased products of the next customer during the payment process (lower row of FIG. 13). Further, the clerk may be absent while the customer is making payment (lower row of FIG. 13). In other words, you may finish serving the customer while the customer is making payment.

As shown in FIG. 14(A), when the clerk code is read in full self mode, the operation mode shifts from full self mode to double scan mode, but reading the clerk code is part of the login operation. It may be one. Further, the operation mode may shift from the full self mode to the double scan mode when another operation (for example, a login operation different from reading the clerk code) is performed in the full self mode. Furthermore, when the store clerk no longer performs any operations in the double scan mode (for example, when a predetermined period of time has elapsed since the last operation), the operation mode may shift from the double scan mode to the full self mode.

(Notification of operation mode)
Each POS terminal 20 may notify its current operating mode. For example, each POS terminal 20 may display its current operating mode on the clerk-side display section 210. Specifically, each POS terminal 20 displays a screen having an operation mode display column of its own terminal on the clerk side display section 210, and displays the current operation mode of its own terminal in the operation mode display column on the screen. It's okay. Additionally, each POS terminal 20 displays a screen on the clerk side display section 210 on which images (for example, button-like images) corresponding to each operation mode are arranged, and the current operation mode of the own terminal is displayed on the screen. An image that does not correspond to the current operation mode may be displayed in a different display manner from that of an image that does not correspond to the current operation mode (for example, in a display manner that is more conspicuous than the display manner of other images). For example, when operating in two operating modes, normal mode and full self-mode, the normal mode image and full self-mode image are always displayed, and when the current operating mode of the own terminal is normal mode, the normal mode image is displayed. The full self mode image may be displayed in a more conspicuous display manner than the full self mode image, and when the current operation mode of the own terminal is the full self mode, the full self mode image may be displayed in a more conspicuous display manner than the normal mode image. . Note that each POS terminal 20 may similarly display its current operating mode on the customer side display section 205 as well.

Further, each POS terminal 20 may notify the current operating mode of another terminal instead of or in addition to the current operating mode of the own terminal. That is, each POS terminal 20 may notify the current operating mode of the other terminal by mutually recognizing the current operating mode of the other terminal. An example of a method in which each POS terminal 20 mutually recognizes the current operation mode of the other terminal is that each POS terminal 20 notifies the other terminal of the operation mode after the transition (the latest operation mode) after changing the operation mode (LAN 11). (via the store controller 10, a monitoring terminal, etc.). Further, each POS terminal 20 may notify the current processing status of the other terminal as well as the current operation mode of the other terminal.

Further, each POS terminal 20 may notify information according to the current operating mode (operating mode, processing status, etc.) of its own terminal. For example, each POS terminal 20 may display various information on the customer side display section 205 when the current operating mode of the terminal is the full self mode, for example, when the terminal is on standby. Further, the POS terminal 20 may broadcast information according to the current operation mode of another terminal, instead of or in addition to the information according to the current operation mode of the own terminal.

In addition, even if the operating mode is switched by a clerk's operation (mode switching operation, clerk code reading, etc.), if the operating mode is switched without a clerk's operation (mode switching command, predetermined period of time, etc.) Even if the situation is due to progress, etc., the operating mode of the own terminal and other terminals is notified.

(Storing information regarding operation mode)
Each POS terminal 20 may store, as information regarding the operation mode, in which operation mode the transaction (processing) was performed. For example, when the POS terminal 20-1 operating in normal mode (standard mode) executes registration processing and settlement processing for a certain transaction, the POS terminal 20-1 that executed the registration processing and settlement processing information (for example, settlement information) (or in association with information about the transaction), information that the registration process and settlement process for the transaction were performed in normal mode (standard mode) (for example, identifying the operating mode) possible information, etc.) may be stored.

Note that each POS terminal 20 may also store information on which terminal the transaction (processing) was performed. In the above example, the POS terminal 20-1 may store information indicating that the registration process and the payment process were executed at the own terminal (POS terminal 20-1) as information regarding the transaction. More specifically, the POS terminal 20-1 stores its own terminal identification information as the identification information (terminal identification information) of the terminal that executed the registration process, and also stores its own terminal identification information as the terminal identification information of the terminal that executed the payment process. Terminal identification information of the terminal may be stored. Alternatively, the POS terminal 20-1 may store the terminal identification information of its own terminal as the terminal identification information of the terminal that executed the entire process (registration process, payment process).

Further, for example, first, the POS terminal 20-1 operating in the normal mode (standard mode) executes registration processing for a certain transaction, and then the POS terminal 20-2 operating in the semi-self mode (accounting only mode) However, when the settlement process is executed for the transaction based on the registered information in the above registration process, the POS terminal 20-2 that executed the settlement process uses the information related to the transaction (for example, settlement information) as (or information that the registration process for the transaction was performed in normal mode (standard mode), as well as information that the settlement process for the transaction was performed in semi-self mode (accounting-only mode). Information may also be stored. Further, in addition to the above, the POS terminal 20-1 that executed the registration process may also store information indicating that the registration process regarding the transaction was performed in a normal mode (standard mode).

In the above example, the POS terminal 20-2 that executed the payment process stores information that the registration process was executed at another terminal (POS terminal 20-1) as transaction information, and stores the information that the registration process was executed at the other terminal (POS terminal 20-1). Information indicating that the payment process was executed at the terminal 20-2) may be stored. More specifically, the POS terminal 20-2 stores the terminal identification information of another terminal (POS terminal 20-1) as the information (terminal identification information) of the terminal that executed the registration process, and also stores the terminal identification information of the other terminal (POS terminal 20-1) as the information (terminal identification information) of the terminal that executed the registration process. The terminal identification information of the own terminal (POS terminal 20-2) may be stored as the terminal identification information of the terminal. In the above example, the POS terminal 20-2 that executes the payment process receives the terminal identification information and operation mode (specifically, normal mode) of the POS terminal 20-1 that executed the registration process. It is sufficient if the identifying information can be obtained. For example, information identifying the terminal identification information and operation mode of the POS terminal 20-1 is supplied from the POS terminal 20-1 side to the POS terminal 20-2 side (for example, sending and receiving information as registration information, It suffices if the system is supplied via the network.

Furthermore, each POS terminal 20 may store information regarding the transition (switching) of the operation mode as information regarding the operation mode. For example, when the operation mode of the POS terminal 20-1 transitions from one operation mode to another, the POS terminal 20-1 determines the operation mode transition time and the operation mode to which it transitioned. information (for example, information that allows identification of the operation mode after the transition) may be stored. In addition, the POS terminal 20-1 also provides information on which operation mode it has transitioned from to which operation mode (for example, information that allows identification of the operation mode before transition, information on the operation mode after transition, as well as the time of transition of the operation mode). information that can identify the user) may also be stored.

Note that each POS terminal 20 will not be able to change its operating mode even if the operation mode is switched by an operation by a store clerk (by mode switching operation, reading a clerk code, etc.), or if the operation mode is switched without any operation by a store clerk ( (in the case of a mode switching command, the passage of a predetermined time, etc.), information regarding the transition of the operation mode may be stored. In the above case, each POS terminal 20 stores information on the basis of which the operation mode was changed (for example, information indicating that the operation mode was changed due to an operation by a store clerk with the clerk code "XXX", terminal identification information "XXX" It may also be possible to store a message that the operation mode has been changed by a mode switching command from the POS terminal 20 (e.g. "x").

Note that instead of or in addition to the POS terminal 20, the store controller 10, the monitoring terminal, or the like may store information regarding the operation mode.

Further, the information regarding the operation mode stored as described above may be output (displayed, transmitted, printed, etc.) as necessary. For example, the POS terminal 20 may include information on the receipt output in the full self-mode that indicates that the process (registration process, payment process) was performed in the full-self mode (information in a form that only the clerk can recognize, or (Information in a form that can be recognized even on the computer) may also be printed. Receipts output in other operating modes may also be printed in the same manner. Further, for example, the POS terminal 20 (or the monitoring terminal) may display the operation mode at the time of processing. As an example, when a transaction number (information that can identify a transaction) is input on a predetermined search screen, the POS terminal 20 (or monitoring terminal) performs registration processing and settlement processing for the corresponding transaction. For at least one of them, the terminal on which the process was performed (terminal identification information, etc.) and the operation mode (information that allows identification of the operation mode) may be displayed.

In the following description, it is assumed that the POS terminal 20-1 and the POS terminal 20-2 are in normal mode (specifically, normal mode (standard mode)). Further, it is assumed that the POS terminal 20-3 is in full self-mode.

(Display example of POS terminal 20 in full self mode)
15 and 16 are display examples on the POS terminal 20 in full self mode. Specifically, FIG. 15(A), FIG. 15(B), and FIG. 16(A) to FIG. 16(F) all show the table on the customer side display section 205 of the POS terminal 20-3 in full self mode. This is an example.

FIG. 15(A) shows the display contents of the registration start screen before the start of the registration process. In FIG. 15(A), a registration start button BT30 on the right side of the screen is a button for instructing the start of product registration. The customer operates the registration start button BT30 when starting product registration. Buttons BT35 to BT37 at the bottom left of the screen are buttons for switching the display language to English, Chinese, and Korean, respectively.

FIG. 15(B) shows the display contents of the registration screen in a state where the second product (Daifuku mochi) is registered. Note that when the registration start button BT30 is operated on the registration start screen shown in FIG. 15(A), the POS terminal 20-3 displays a registration screen with no products registered yet. For convenience, FIG. 15(B) shows the registration screen after the products (tea, daifuku mochi) have already been registered.

In FIG. 15(B), the image GA01 at the bottom left of the screen shows the state (specifically, the normal mode) of the other terminal (POS terminal 20-1). Image GA02 at the bottom left of the screen shows the state (specifically, the normal mode) of the other terminal (POS terminal 20-2). The checkout button BT32 at the bottom right of the screen is a button for instructing the end of product registration. The customer operates the checkout button BT32 after completing the product registration. The clerk call button BT33 is a button for calling a clerk. The customer operates the clerk call button BT33 when calling the store clerk (for example, when the store clerk's support is required).

Note that the buttons BT35 to BT37 are buttons for switching the display language to English, Chinese, and Korean, respectively, as described above. Moreover, the "vegetable" button BT38 is a button for displaying each vegetable preset key (see FIG. 17).

FIG. 16(A) shows the display contents of the payment screen (payment method selection screen) that is displayed when starting the payment process. For example, when the checkout button BT32 is operated on the registration screen (see FIG. 15(B)), the POS terminal 20-3 displays a payment method selection screen as shown in FIG. 16(A).

FIG. 16(B) shows the display contents of the settlement screen (deposit screen) that is displayed when starting payment in cash. For example, when cash is operated on the payment method selection screen (see FIG. 16(A)), the POS terminal 20-3 displays a deposit screen as shown in FIG. 16(B).

FIG. 16(C) shows the display contents of the settlement screen (deposit screen) that is displayed when determining the deposit amount. For example, the POS terminal 20-3 displays a deposit screen as shown in FIG. 16(C) when cash (deposit) exceeding the payment amount (purchase amount) is deposited.

FIG. 16(D) shows the display contents of the payment screen (change screen) that is displayed when changing is released. For example, when the end (receipt) button BT40 is operated on the deposit screen (FIG. 16(C)), the POS terminal 20-3 displays a change screen as shown in FIG. 16(D).

FIG. 16(E) shows the display contents of the payment screen (receipt screen) that is displayed when change is removed. For example, when change is removed from the outlet of the change machine 209, the POS terminal 20-3 displays a receipt screen as shown in FIG. 16(E). Note that the POS terminal 20 may install a sensor such as a photo sensor near the takeout port, and determine that change has been removed when the sensor recognizes an object (assuming a customer's hand). FIG. 16(F) is a hibernation screen displayed when in hibernation mode (hibernation state).

Note that after displaying the receipt screen (FIG. 16(E)), the POS terminal 20-3 displays a registration start screen (FIG. 15(A)). For example, the POS terminal 20-3 displays a registration start screen after the receipt is removed from the issuing port of the printing unit 213. Note that the POS terminal 20 may include a sensor that can recognize that the receipt has been removed from the issuing port. In addition, if no change is generated, the change screen (Figure 16 (D)) may not be displayed and the deposit screen (Figure 16 (C)) may be transitioned to the receipt screen (Figure 16 (E)). .

(Display example of POS terminal 20 in normal mode)
17 to 22 are display examples on the POS terminal 20 in normal mode. Specifically, FIG. 17(A), FIG. 18(A), FIG. 19(A), FIG. 20(A), FIG. 21(A), and FIG. 22(A) all show normal mode (standard mode). ) is a display example on the clerk side display section 210 of the POS terminal 20-1. 17(B), FIG. 18(B), FIG. 19(B), FIG. 20(B), FIG. 21(B), and FIG. 22(B) all show the POS terminal 20 in normal mode (standard mode). This is an example of a display on the customer side display section 205 of -1.

FIG. 17(A) shows the display contents on the registration screen in the initial state on the clerk side display section 210. In the following explanation, the initial state means, unless otherwise specified, a state in which no processing is in progress, for example, a state in which no products have been registered yet, and no payment has been made yet. (e.g., no payment method has been selected, no cash has been inserted, no gift certificates have been registered, etc.), and no action has been taken regarding the customer (e.g., membership card, etc., has not been read). be.

In FIG. 17A, a tab area T1 at the top right of the screen is a tab corresponding to each display content (display screen). The POS terminal 20-1 can interrupt the registration process for the customer (the reason for the interruption is to return to the store to add purchased items, etc.) and then proceed to the registration process for the next customer. In other words, the POS terminal 20-1 displays a new registration screen for the next customer while retaining (memorizing) the display content (registration content) of the registration screen for the customer, based on the clerk's operation. In the example shown in FIG. 17(A), there is one tab (tab area T1), but the POS terminal 20-1 displays the number of tabs (tab area Regions T1, T2, T3, ...), the registration screen to be enabled (activated) is switched according to the operation (pressing) of the tab.

Information that identifies the tab from other tabs (the number "1" in the example of FIG. 17(A)) is displayed in the tab area T1. Further, the tab area T1 is provided with a display column HR01 for displaying the deposit amount from the customer. Further, although not displayed in the example shown in FIG. 17(A), various information (described later) in addition to the above is displayed in the tab area T1.

Image GA02 at the bottom left of the screen shows the state (specifically, the normal mode) of the other terminal (POS terminal 20-2). Image GA03 at the bottom left of the screen shows the state (specifically, full self mode) of the other terminal (POS terminal 20-3).

FIG. 17(B) shows the display content on the customer side display section 205 in the initial state. That is, when the POS terminal 20-1 displays the registration screen as shown in FIG. 17(A) on the clerk side display section 210, the POS terminal 20-1 displays the registration screen as shown in FIG. 17(B) on the customer side display section 205. A small screen (small window) SG01 is displayed superimposed on the payment screen (deposit screen).

The small screen SG01 allows the customer to select a payment method. The customer selects cash, credit, or electronic money as a payment method on the small screen SG01. If the customer desires cash as the payment method, he or she may insert cash (deposit) before selecting cash as the payment method on the small screen SG01. The POS terminal 20-1 erases the small screen SG01 when any payment method is selected on the small screen SG01. Further, if cash is inserted before the payment method is selected on the small screen SG01, the POS terminal 20-1 processes it as if cash has been selected as the payment method and erases the small screen SG01.

The POS terminal 20-1 displays the registration screen shown in FIG. 17(A) on the clerk side display section 210, and when the clerk registers a can of beer, the clerk side display section 210 displays the registration screen shown in FIG. 18(A). A registration screen like the one shown will be displayed.

In FIG. 18(A), the subtotal button BT10 at the bottom right of the screen is a button for instructing the end of product registration. The store clerk operates (touches) the subtotal button BT10 after completing the product registration.

The 20-2 register button BT12 is a button for specifying the 20-2 register (POS terminal 20-2). The clerk operates the 20-2 checkout button BT12 when specifying the POS terminal 20-2 as the terminal to transmit the registration information. "(Normal)" shown on the 20-2 cash register button BT12 indicates that the operation mode of the POS terminal 20-2 corresponding to the 20-2 cash register button BT12 is the normal mode.

The 20-3 register button BT13 is a button for specifying the 20-3 register (POS terminal 20-3). The clerk operates the 20-3 register button BT13 when specifying the POS terminal 20-3 as the terminal to transmit the registration information. "(Full Self)" shown on the 20-3 cash register button BT13 indicates that the operation mode of the POS terminal 20-3 corresponding to the 20-3 cash register button BT13 is the full self mode.

The checkout button BT15 is a button for causing the printing unit 213 to issue a checkout. The store clerk operates the bill button BT15 to cause the POS terminal 20 that read the bill (the POS terminal 20 that the customer caused the bill to read) to execute the process.

In addition, when comparing the POS terminal 20 in normal mode and the POS terminal 20 in full self-mode as the POS terminal 20 to which registration information is sent, the POS terminal 20 in full self-mode is better than the POS terminal 20 in normal mode. is preferable as the destination for registration information. Since the POS terminal 20 in the normal mode is basically operated by a store clerk (see FIGS. 7 and 8), processing (for example, registration processing, customer service, etc.) continues, and registration Even if you send information, there is a high possibility that it will not be able to be processed immediately, and even if it is vacant (even if there is no staff or customer present), it is generally left open in order to immediately respond to customers who request assistance from staff. On the other hand, with the full self-mode POS terminal 20, if there are no customers, the registration information can be sent and processed immediately, and even if there are customers, it is sufficient to simply process the information in order. This is because such problems are unlikely to occur.

In view of the above, the store clerk is informed as to whether or not the POS terminal 20 is preferable as the destination of the registered information, or which one is more preferable in the case where there are multiple destinations of the registered information. As an example, in FIG. 18A, the outline of the 20-3 checkout button BT13 corresponding to the full-self mode POS terminal 20-3, which is relatively preferable as the destination of registration information, is shown by a solid line, and the destination of registration information is The outline of the 20-2 checkout button BT12 corresponding to the POS terminal 20-2 in the normal mode, which is relatively unfavorable, is indicated by a broken line. Note that the above-mentioned notification by the outline part is just one example, and the store clerk can determine whether or not the POS terminal 20 is the preferred destination for the registered information, or which one is more preferable in the case where there are multiple destinations for the registered information. The notification mode is not limited as long as it can be recognized. For example, if it is relatively undesirable, the background color of the button may be grayed out, or a penalty mark or diagonal line may be added to the entire button. Further, the display size, shape, and display position of the button may be changed depending on whether or not the POS terminal 20 to which the registered information is to be sent is preferable, and the button may contain some information (such as "priority" or "recommended"). You may also attach a badge-like image (such as a badge-like image).

When the POS terminal 20-1 displays a registration screen as shown in FIG. 18(A) on the clerk side display section 210, the POS terminal 20-1 displays a small screen as shown in FIG. 18(B) on the customer side display section 205. Screen SG01 is displayed superimposed on the payment screen (deposit screen). Note that on the payment screen (deposit screen) in Figure 17 (B), the total amount was 0 yen because no product was registered, but on the payment screen (deposit screen) in Figure 18 (B), the canned beer cost 215 yen. is registered, so the total amount is 215.

The POS terminal 20-1 displays the registration screen shown in FIG. 18(A) on the clerk side display section 210, and when the customer inserts 500 yen, the clerk side display section 210 displays the registration screen shown in FIG. 19(A). A registration screen like the one shown will be displayed.

Since the customer has inserted 500 yen, 500 is displayed in the display column HR01 at the top right of the screen in FIG. 19(A). Also, by inserting 500 yen, the payment will be made at the own terminal (POS terminal 20-1), so it will be used when making the payment at other terminals (POS terminal 20-2, POS terminal 20-3). The buttons (20-2 cash register button BT12, 20-3 cash register button BT13, checkout button BT15) are hidden (erased).

When the POS terminal 20-1 is displaying the registration screen as shown in FIG. 19(A) on the clerk side display unit 210, the POS terminal 20-1 displays the payment screen (deposit screen) as shown in FIG. 19(B). It is displayed on the customer side display section 205. Note that the small screen SG01 has been erased because 500 yen has been inserted by the customer.

The POS terminal 20-1 displays the registration screen of FIG. 19(A) on the clerk side display section 210, and the clerk registers the second product (asparagus) and the third product (nori bento). If the customer inserts an additional 500 yen, a registration screen as shown in FIG. 20(A) is displayed on the clerk side display section 210. Since the customer has inserted an additional 500 yen, 1000 is displayed in the display column HR01 at the top right of the screen in FIG. 20(A).

When the POS terminal 20-1 displays the registration screen as shown in FIG. 20(A) on the clerk side display unit 210, the POS terminal 20-1 displays the payment screen (deposit screen) as shown in FIG. 20(B). It is displayed on the customer side display section 205.

When the clerk operates the subtotal button BT10 while the clerk-side display section 210 is displaying the registration screen shown in FIG. 20(A), the POS terminal 20-1 displays the registration screen shown in FIG. ), a small screen (small window) SG02 is displayed superimposed on the registration screen, and a payment screen (deposit screen) as shown in FIG. 21(B) is displayed on the customer side display section 205. The small screen SG02 is for notifying the store clerk of payment-related information (total amount, device deposit amount (deposit amount)).

When the customer operates the end (receipt) button BT40 while the POS terminal 20-1 is displaying the payment screen (deposit screen) shown in FIG. In the section 210, a message screen MG1 is displayed superimposed on the registration screen as shown in FIG. 22(A), and a payment screen (change screen) as shown in FIG. indicate.

The message screen MG1 is for notifying the store clerk about the change. The POS terminal 20-1 erases the message screen MG1 displayed superimposed on the registration screen without any operation by the store clerk (for example, automatically after a predetermined period of time has elapsed). Note that the POS terminal 20-1 may erase the message screen MG1 that is displayed superimposed on the registration screen in response to an operation by the store clerk (such as a touch on the message screen MG1).

Although illustrations from FIG. 22 onward are omitted, the POS terminal 20-1 displays a payment screen similar to that shown in FIG. Display the corresponding message.

In the above explanation, we focus on the overall processing at the POS terminal 20, and assume that no processing is in progress (product not registered, cash not inserted, payment type not selected, gift certificate not registered, customer information not obtained). (state) is referred to as the initial state, but it may also be referred to as the initial state, focusing on a part of the processing. For example, the cash input product registration status (product registered, cash input, payment type not selected, gift certificate not registered, customer information not acquired) is an initial status when focusing on the overall process. However, if we focus only on the state of payment type selection, it can be said that it is in the initial state. Furthermore, if we focus on the two states of product registration and payment type selection, we cannot say that they are initial states, but the two states of payment type selection and gift certificate registration. If we pay attention to this, we can say that this is the initial state.

In the example shown in FIG. 21, when the subtotal key is operated, the POS terminal 20-1 displays the small screen SG02 superimposed on the registration screen (FIG. 21(A)). When the subtotal key is operated, the terminal 20-1 may display a sub-plan screen that displays information etc. displayed on the small screen SG02 instead of (switching) to the registration screen.

(Example of operation mode switching process)
Next, an example of the operation mode switching process of the POS terminal 20 will be described using FIGS. 23 and 24. FIG. 23 is a flowchart showing an example of an operation mode switching process performed by the POS terminal 20 when the mode switching button is pressed. Note that since each POS terminal 20 is provided with a mode switching button, when the mode switching button is pressed on any POS terminal 20, the process shown in FIG. 23 is started. Note that the process shown in the flowchart of FIG. 23 is always started (regularly at very short time intervals) in each POS terminal 20.

Step S201: The POS terminal 20 determines whether the mode switching button 211a has been pressed. If the mode switching button 211a is not pressed, the POS terminal 20 proceeds to step S208. If the mode switching button 211a is pressed, the POS terminal 20 proceeds to step S202.
Step S202: The POS terminal 20 transmits a mode switching command to other POS terminals 20, and proceeds to step S203.

Step S203: The POS terminal 20 determines whether or not its own terminal is processing. The processing referred to here is, for example, product registration processing and payment processing for accepting payment from customers. If the POS terminal 20 is currently processing, the process proceeds to step S204. If the POS terminal 20 is not processing, the process proceeds to step S206.
Step S204: The POS terminal 20 notifies (displays) that the process is in progress, and proceeds to step S205.
Step S205: The POS terminal 20 determines whether the process being executed has ended. The POS terminal 20 waits until the process being executed is finished, and when the process being executed is finished, the process proceeds to step S206.

Step S206: The POS terminal 20 performs mode switching processing, and proceeds to step S207. The mode switching process is a process of switching to a mode different from the current mode, for example, a process of switching to any one of the normal mode, accounting only mode, and full self mode, which are different from the current mode.
Step S207: The POS terminal 20 notifies that the mode switching of its own terminal has been completed, and proceeds to step S208.

Step S208: The POS terminal 20 determines whether or not it has received information indicating that processing is in progress from another POS terminal 20 to which the mode switching command is transmitted. If the POS terminal 20 does not receive information indicating that processing is in progress from another POS terminal 20, the process proceeds to step S210. If the POS terminal 20 receives information indicating that processing is in progress from another POS terminal 20, the process proceeds to step S209.

Step S209: The POS terminal 20 notifies that another POS terminal 20 is processing, and proceeds to step S210.
Step S210: The POS terminal 20 determines whether or not it has received information indicating that mode switching has been completed from another POS terminal 20. If the POS terminal 20 does not receive information indicating that the mode switching has been completed from the other POS terminal 20, the series of processing ends immediately. When the POS terminal 20 receives information indicating that mode switching has been completed from another POS terminal 20, the process proceeds to step S211.
Step S211: The POS terminal 20 notifies that the mode switching of the other POS terminals 20 has been completed, and ends the series of processing.

Next, the mode switching process performed by the POS terminal 20 that has received the mode switching command will be described using FIG. 24. FIG. 24 is a flowchart illustrating an example of an operation mode switching process performed by the POS terminal 20 that has received the mode switching command. The process shown in the flowchart of FIG. 24 is always started (regularly at very short time intervals) in each POS terminal 20.

Step S221: The POS terminal 20 determines whether a mode switching command has been received. If the POS terminal 20 does not receive the mode switching command, the POS terminal 20 immediately ends the series of processing. When the POS terminal 20 receives the mode switching command, the process proceeds to step S222.
Step S222: The POS terminal 20 determines whether or not its own terminal is processing. The processing referred to here is, for example, product registration processing and payment processing for accepting payment from customers. If the POS terminal 20 is currently processing, the process proceeds to step S223. If the POS terminal 20 is not processing, the process proceeds to step S225.

Step S223: The POS terminal 20 transmits to the POS terminal 20 from which the mode switching command was sent that the process is in progress, and proceeds to step S224.
Step S224: The POS terminal 20 determines whether the process being executed has ended. The POS terminal 20 waits until the process being executed is finished, and when the process being executed is finished, the process proceeds to step S225.

Step S225: The POS terminal 20 performs mode switching processing, and proceeds to step S226.
Step S226: The POS terminal 20 transmits information indicating that the mode switching has been completed to the POS terminal 20 that sent the mode switching command, and proceeds to step S227.
Step S227: The POS terminal 20 notifies that the mode switching of its own terminal has been completed, and ends the series of processing.

(Example of screen transition when correcting a product in full self mode) Next, an example of screen transition when correcting a product in full self mode will be described with reference to FIGS. 25 to 27. FIGS. 25 to 27 are explanatory diagrams showing an example of screen transitions when correcting a registered product in the full self mode. In the following description and drawings, the same reference numerals are given to the same contents as those of the screen transition described above, and the description thereof will be omitted.

(A) of FIG. 25 shows that two products, "tea" and "sweet potato", are registered by the customer's operation in the full self-mode. For example, for "tea", the customer registers the product by having the POS terminal 20 read a barcode. Regarding "Sweet Potato", the product is registered when the customer selects an area (button) indicating "Sweet Potato" from among the preset keys. Further, in FIG. 25(A), a guide display 2501 is displayed. A guide display 2501 indicates that a registered product can be corrected by long-pressing the area indicating the product the customer desires to correct (change).

As shown in (A) of FIG. 25, it is assumed that the customer presses and holds the area indicating "Sweet Potato". In other words, assume that the customer performs an operation to correct the product "sweet potato." In this case, the screen changes to the one shown in FIG. 25(B). FIG. 25(B) shows a confirmation screen for whether or not to cancel "Sweet Potato". When the customer selects "Yes" on the confirmation screen, the screen transitions to the screen shown in FIG. 25(C). Note that if the customer selects "No" on the confirmation screen, the screen returns to the screen shown in FIG. 25(A), for example.

(C) of FIG. 25 shows a notification screen informing that the clerk is being called to cancel the "sweet potato" order. In addition, in (C) of Figure 25, the area where "Sweet Potato" is registered is displayed in a different display format (bold, framed, special color) to clearly indicate that the product is subject to correction. etc.) are displayed. As a result, when a store clerk visits the store, he or she can grasp at a glance the product to be corrected. In addition, the product to be corrected becomes clear to the customer.

Here, the timing to call the store clerk may be the timing when "Yes" is pressed (timing after the confirmation screen) shown in (B) of FIG. It may also be the timing when the button is pressed (the timing when the button is pressed for a long time). By calling the store clerk at the timing of a long press, the store clerk can be called quickly. Furthermore, by calling the store clerk at the timing after the confirmation screen, it is possible to prevent the store clerk from being called due to a customer's operational error or from the customer's operational error or misunderstanding. Further, the notification for calling the store clerk is made, for example, on the POS terminal 20 operated or viewed by the store clerk, a mobile terminal owned by the store clerk, a management device, or the like.

(D) of FIG. 26 shows the screen when a store clerk goes to the POS terminal 20 where the correction operation was performed and presses the clerk button. In FIG. 26(D), when the clerk presses the clerk button, the screen changes to the screen shown in FIG. 26(E).

In (E) of FIG. 26, a notification is displayed prompting the clerk to read the clerk code. When a store clerk, for example, causes the POS terminal 20 to read a clerk code attached to his or her name tag, the clerk is authenticated. If the authentication is successful, the screen changes to the one shown in FIG. 26(F). On the other hand, if the authentication fails, for example, an error message is displayed. It should be noted that in addition to displaying the error message, another store clerk may be called. In this case, the other store employee may approve the correction by going to the POS terminal 20 where the correction was performed and performing authentication. Note that the authentication of the store clerk is not limited to the authentication using the store clerk code, but may be biometric authentication such as fingerprint authentication, or authentication by inputting a password.

(F) of FIG. 26 shows a confirmation screen for approval by the store clerk. The store clerk visually confirms (by checking the products in the cart) whether the correction information entered by the customer is correct (whether it is an erroneous operation or registration error), and if it is determined to be correct, a confirmation screen will be displayed. Click "Yes". When the clerk selects "Yes" on the confirmation screen, the screen transitions to the screen shown in FIG. 27(G). On the other hand, if the clerk selects "No" on the confirmation screen, the series of correction operations is canceled and the screen returns to the screen shown in FIG. 25(A), for example. In this case, corrections will not be accepted.

(G) in FIG. 27 shows a notification screen that the correction (cancellation) has been completed. Furthermore, the product (sweet potato) that is the subject of cancellation is not hidden, but is clearly marked as a canceled product by, for example, being marked with a strikethrough line. This allows the customer and the store staff to easily understand that the product has been cancelled. To be more specific, if the canceled item is hidden, when the customer confirms the canceled item, they will have to check whether the item they are purchasing matches the displayed item. You will need to check each item one by one to make sure that the canceled item is not displayed. Such confirmation is troublesome for the customer, especially when a large number of products are to be purchased. In this embodiment, by displaying the canceled products with a strikethrough line, the customer can easily understand the products to be corrected even if there are many registered products.

As shown in FIGS. 25 to 27, in this embodiment, the customer only needs to perform a part of the correction operation and the clerk presses the approval button, which can reduce the customer's waiting time for corrections. This also simplifies the operations for store staff. Therefore, it is possible to efficiently correct registered products.

(About other screen examples when correcting products in full self mode)
Next, another screen example when correcting a product in the full self mode will be described using FIG. 28. FIG. 28 is an explanatory diagram showing another example of the screen when correcting a product in the full self mode. Note that FIG. 28 differs from the screens shown in FIGS. 26 and 27 in that a change in quantity is accepted.

(A) of FIG. 28 shows that two products, "tea" and "sweet potato", are registered by the customer's operation in the full self-mode. As shown in FIG. 28(A), it is assumed that the customer presses and holds the area indicating "tea". In this case, the screen changes to the one shown in FIG. 28(B). FIG. 28B shows a screen for accepting changes in quantity. In FIG. 28B, when the "+" button is pressed, the quantity is added according to the number of times the "+" button is pressed. On the other hand, when the "-" button is pressed, the quantity is subtracted according to the number of times the "-" button is pressed. Note that by setting the quantity to "0", the product can be canceled in the same manner as in FIGS. 27 and 28.

In FIG. 28B, when a change in quantity is accepted, a change button 2801 becomes operable. Here, assume that the change button 2801 is pressed after accepting a change that increases the quantity. In this case, since the increase in quantity is not recognized as a fraudulent act, the increase in quantity is accepted without requiring approval from the store clerk, and the process returns to the registration screen shown in FIG. 28(A).

On the other hand, assume that the change button 2801 is pressed after accepting a change that reduces the quantity. In this case, it is necessary for the clerk to confirm whether the correction is legitimate, and therefore the clerk is called. However, for products registered by scanning barcodes, the quantity cannot be set to "0". Specifically, as shown in FIG. 28(B), when the quantity is "1", the customer presses the "-" button. In this case, the screen changes to the one shown in FIG. 28(C).

(C) of FIG. 28 shows a screen indicating that the registered product cannot be set to "0" by reading the barcode. In the case of products with barcodes attached, erroneous registration can occur where a customer mistakenly reads the barcode twice in a row. Therefore, since the quantity may change from "2" to "1" or from "3" to "2", we will accept corrections to reduce the number to a number excluding "0".

On the other hand, for products with barcodes, since the barcode has been read and it is clear that the product actually exists, changing the quantity to "0" is not expected. For this reason, for products with barcodes, it is highly likely that an operation that changes from "1" to "0" is an erroneous operation, so measures should be taken to prevent such erroneous operations. ing.

Note that even for products with barcodes attached, after registering the product, the customer may wish to cancel the registration due to reasons such as the price being unexpected. In this case, the customer may press the clerk call button to call the clerk, and the clerk may perform the cancellation operation. The cancellation operation by the store clerk is performed by, for example, a list of products displayed by the store clerk who has successfully authenticated using the store clerk code, and the store clerk selects the product to be canceled from the list.

Note that it is up to the store staff to decide whether to accept deletion of the product by pressing the area indicating the product as shown in FIGS. 25 to 27, or to accept a change in quantity as shown in FIG. It may be possible to change the settings. Further, by pressing an area indicating a product, a selection screen may be displayed to allow the customer to select whether to accept deletion of the product or change of quantity.

(An example of the product registration process in full self mode performed by the POS terminal 20)
FIG. 29 is a flowchart illustrating an example of product registration processing performed by the POS terminal 20 in full self-mode.
Step S301: The POS terminal 20 determines whether there is a touch on the clerk side display section 210 (preset key), an operation on the key operation section 211, a scan using the clerk side scanner section 212, etc. The POS terminal 20 stands by if there is no scanning or the like, and proceeds to step S302 if there is any scanning or the like.

Step S302: The POS terminal 20 registers the product and displays it on the clerk side display section 210, and the process proceeds to step S303.
Step S303: The POS terminal 20 determines whether or not the product correction has been accepted. If the POS terminal 20 does not accept the product correction, the process proceeds to step S306. If the POS terminal 20 accepts the correction of the product, the process proceeds to step S304.
Step S304: The POS terminal 20 determines whether the change is an increase in quantity. If the POS terminal 20 determines that the quantity has not increased, that is, if it has determined that the quantity has decreased, the process proceeds to step S305. If the POS terminal 20 determines that the quantity has increased, the process proceeds to step S306.

Step S305: The POS terminal 20 performs a correction process and returns to step S301. Details of the correction process will be described later using FIG. 30.
Step S306: The POS terminal 20 determines whether the subtotal key of the key operation unit 211 has been pressed. If the subtotal key is not pressed, the POS terminal 20 returns to step S301. If the subtotal key is pressed, the POS terminal 20 proceeds to step S307.

Step S307: The POS terminal 20 determines whether or not the product correction has been accepted. If the POS terminal 20 does not accept the product correction, the process proceeds to step S308. If the POS terminal 20 accepts the correction of the product, the process proceeds to step S309.

Step S308: The POS terminal 20 determines whether the payment has been completed. In addition, during payment, the POS terminal 20 displays a small plan screen, receives payment operations such as inputting a deposit or pressing a cash total button, and issues a receipt or the like. Furthermore, upon payment, change may be released according to the deposit or the total amount. If the payment is not completed, the POS terminal 20 returns to step S307. When the payment is completed, the POS terminal 20 ends the series of processing.

Step S309: The POS terminal 20 determines whether the change is an increase in quantity. If the POS terminal 20 determines that the quantity has not increased, that is, if it has determined that the quantity has decreased, the process proceeds to step S310. If the POS terminal 20 determines that the change is an increase in quantity, the process proceeds to step S311.

Step S310: The POS terminal 20 performs a correction process and proceeds to step S311. Details of the correction process will be described later using FIG. 30.
Step S311: The POS terminal 20 performs subtotal change processing to change the subtotal amount, and proceeds to step S308.

(An example of product correction processing performed by the POS terminal 20 in full self-mode)
FIG. 30 is a flowchart illustrating an example of product correction processing performed by the POS terminal 20 in full self-mode. Note that the correction processing shown in FIG. 30 shows details of the processing shown in step S305 and step S310 of FIG. 29. In addition, below, it will be explained as the process of step S305.

Step S321: The POS terminal 20 calls the store clerk to another terminal (another POS terminal 20, a mobile terminal owned by the store clerk, or a management device), and proceeds to step S322. Step S322: The POS terminal 20 determines whether a clerk code has been input. The clerk code may be obtained by, for example, having the clerk read the clerk code attached to the clerk's name tag into the clerk scanner section 212, or by directly inputting the clerk code (number) by operating the key operation section 211. It is input by The POS terminal 20 waits until the clerk code is input, and when the clerk code is input, the process advances to step S323.

Step S323: The POS terminal 20 determines whether or not the clerk has been successfully authenticated using the clerk code. If the POS terminal 20 fails to authenticate the store clerk, the process proceeds to step S324. If the POS terminal 20 succeeds in authenticating the store clerk, the process proceeds to step S325.
Step S324: The POS terminal 20 notifies the error and returns to step S301. Note that in the correction process of step S310 in FIG. 29, the process proceeds to step S311 after the process of step S324.
Step S325: The POS terminal 20 determines whether or not the approval result has been received from the store clerk. The POS terminal 20 waits until it receives the approval result from the store clerk, and upon receiving the approval result, proceeds to step S326.

Step S326: The POS terminal 20 determines whether the received approval result is an approval result that allows correction. If the received approval result does not allow correction, the POS terminal 20 returns to step S301. In this case, no correction will be made. If the received approval result is an approval result that allows correction, the POS terminal 20 proceeds to step S327.
Step S327: The POS terminal 20 corrects the registered product and returns to step S301.

Through the processes shown in FIGS. 29 and 30, when the POS terminal 20 receives a correction from the customer, it can correct the registered information by calling the store clerk and accepting the clerk's approval. As a result, the customer performs some of the operations related to correcting the product information, so it is possible to shorten the customer's waiting time related to the correction. Further, since the store clerk only needs to go to the POS terminal 20 and perform an operation for approval, the store clerk's operations related to changing product information can be simplified.

(Example of screen transition when correcting a product in semi-self mode) Next, an example of screen transition when correcting a product in semi-self mode will be described with reference to FIGS. 31 and 32. In the following, a POS system 1 in which a normal mode POS terminal 20 is placed on the upstream side of the checkout line and a semi-self mode POS terminal 20 is placed on the downstream side of the checkout line will be described as an example. Further, in the following, a case will be described in which, in the POS system 1, after the clerk completes the registration of the product at the upstream POS terminal 20, the customer makes a correction when making payment at the downstream POS terminal 20. Further, below, transitions of the screen of the downstream POS terminal 20 (the screen of the customer side display unit 205) in the POS system will be explained.

FIGS. 31 and 32 are explanatory diagrams showing an example of the transition of the customer's screen when correcting a product in the semi-self mode. (A) of FIG. 31 shows the screen of the customer side display unit 205 when a plurality of types of products are registered at the upstream POS terminal 20 by a clerk's operation and payment is made at the downstream POS terminal 20. In FIG. 31(A), a guide display 3101 is displayed. The guidance display 3101 indicates that the registered product can be corrected by long-pressing the area indicating the product the customer desires to correct.

As shown in FIG. 31(B), it is assumed that the customer presses and holds the area indicating "Sweet Potato". Specifically, for example, suppose that the customer does not know that he has purchased "sweet potato," but "sweet potato" is registered, and the customer performs an operation to correct "sweet potato." In this case, the screen changes to the one shown in FIG. 31(C). (C) of FIG. 31 shows a confirmation screen for whether or not to cancel "Sweet Potato". When the customer selects "Yes" on the confirmation screen, the screen transitions to the screen shown in FIG. 32(D). Note that at this time, the details of the correction and a request for approval of the correction are transmitted from the POS terminal 20 on the downstream side to the POS terminal 20 on the upstream side. In FIG. 31(C), if the customer selects "No" on the confirmation screen, the screen returns to, for example, the screen shown in FIG. 31(A).

(D) in FIG. 32 shows a notification screen informing that in order to cancel "Sweet Potato", the process will wait until approval is received from the clerk (the clerk who registered the product) located at the upstream POS terminal 20. Note that an example of the screen when the store clerk performs approval will be described later using FIG. 33. In addition, in (D) of Figure 32, the area where "Sweet Potato" is registered is displayed in a different display format (bold, framed, special color) to clearly indicate that the product is subject to correction. etc.) are displayed. This makes it clear to the customer which product is subject to correction.

(E) of FIG. 32 shows a notification screen to the effect that the correction (cancellation) has been completed due to the clerk's approval at the upstream POS terminal 20. Furthermore, the product (sweet potato) that is the subject of cancellation is not hidden, but is clearly marked as a canceled product by, for example, being marked with a strikethrough line. Furthermore, if the store clerk's approval is not obtained, that is, if the registration of "Sweet Potato" is not a mistake, the cancellation of "Sweet Potato" will not be accepted.

(An example of the screen transition on the clerk-side display section 210 of the upstream POS terminal 20 when correcting a product)
Next, with reference to FIG. 33, an example of the transition of the screen of the clerk side display section 210 of the upstream POS terminal 20 when correcting a product will be described. FIG. 33 is an explanatory diagram showing an example of the screen transition of the clerk-side display section 210 of the upstream POS terminal 20 when correcting a product. In the explanation of FIG. 33, it is assumed that the upstream POS terminal 20 is in the normal mode, and that the downstream POS terminal 20 has finished registering the product of the customer who is making payment and is registering the product of the next customer. do.

(A) of FIG. 33 shows the screen when registering the next customer's products. The image GA02 at the lower left of the screen in FIG. 33A indicates that the downstream POS terminal 20 (POS terminal 20-2) is in the semi-self mode. Further, the notification image 3301 indicates a warning at the downstream POS terminal 20 indicating that support from a store clerk is required. The notification image 3301 is displayed, for example, when there is a request for approval of correction or a request to call a store clerk from the POS terminal 20 on the downstream side. In (A) of FIG. 33, when the clerk presses the image GA02 or the notification image 3301, the screen changes to the screen shown in (B) of FIG. 33.

FIG. 33(B) shows a confirmation screen for approval by the store clerk. If the clerk can instantly determine that the registration has been made incorrectly by himself or herself, or if the clerk can visually confirm that the registration has been made incorrectly from the clerk's position, the clerk can confirm the registration at the upstream POS terminal 20 (by pressing "Yes"). ). On the other hand, if the clerk cannot confirm whether the registration is incorrect from the upstream POS terminal 20, the clerk moves to the downstream POS terminal 20 and visually checks the correction details. and perform the approval operation. Alternatively, the downstream POS terminal 20 may accept the store clerk's approval. Specifically, the clerk's approval may be received at the downstream POS terminal 20 by displaying a confirmation screen for the clerk's approval on the clerk's side display section 210 of the downstream POS terminal 20 as well. This allows the downstream POS terminal 20 to quickly receive the store clerk's approval. Note that the clerk may return to the upstream POS terminal 20 and receive the clerk's approval at the upstream POS terminal 20.

When the clerk selects "Yes" on the confirmation screen shown in FIG. 33(B), the correction (cancellation) is completed. On the other hand, if the clerk selects "No", the correction will not be accepted. Further, the approval result selected by the clerk is transmitted to the POS terminal 20 on the downstream side. When either "Yes" or "No" is accepted from the store clerk on the confirmation screen, the screen changes to the screen shown in FIG. 33(C), and the next customer's product registration continues.

As shown in FIGS. 31 to 33, in this embodiment, a correction operation is accepted from the customer at the time of payment in the semi-self mode. Here, from the customer's point of view who pays at the POS terminal 20 on the downstream side, it is difficult to talk to the clerk located at the POS terminal 20 on the upstream side because the clerk is registering the next customer's products. Because of this, offering (requesting) corrections can be a mental burden for customers. In this embodiment, the store clerk is not directly requested to make a correction, but the contents of the correction can be notified to the store clerk via the POS terminal 20, so that the mental burden on the customer when making the correction can be reduced.

Further, when performing a series of correction operations, the customer only needs to perform part of the correction operations, and the clerk only has to press an approval button. Therefore, it is possible to shorten the customer's waiting time for corrections, and it is also possible to simplify the operations performed by the store staff. Further, the store clerk can approve the correction while proceeding with the registration of the next customer's product. Therefore, it is possible to efficiently correct registered products.

Note that although FIGS. 31 to 33 describe the case where the customer makes the correction when making payment, the correction is not limited to this, and it is also possible to make the correction while registering the customer's products. Specifically, when a store clerk registers a product at the upstream POS terminal 20, a customer waiting for registration at the POS terminal 20 registers the product displayed on the customer side display section 205 (FIGS. 17 to 22). It is also possible to accept corrections while the store clerk is registering the product by long-pressing the area showing (see (B) in each figure).

(About other screen examples when correcting products in semi-self mode)
Next, other screen examples when correcting a product in the semi-self mode will be explained using FIGS. 34 to 36. FIGS. 34 to 36 are explanatory diagrams showing other screen examples when correcting a product in the semi-self mode. In addition, in FIGS. 34 to 36, among the items indicating the product name, quantity, and price in the display area indicating the product, changes to the item indicated by the long-pressed display area are accepted. 31 to 33.

(A) in each figure of FIGS. 34, 35, and 36 shows the customer-side display section 205 when the product is registered at the upstream POS terminal 20 and the payment is made at the downstream POS terminal 20. The following screen is shown. In (A) of FIG. 34, it is assumed that the customer presses and holds the area showing the product name (the display area showing the characters "tomato") in the area of the product "tomato". In this case, the screen transition is the same as when canceling "Sweet Potato" shown in FIG. 31 (see (C) in FIG. 31, (D), and (E) in FIG. 32).

Further, as shown in FIG. 35(A), it is assumed that the customer presses and holds the area indicating the number of items in the area of the product "tomato". In this case, the screen changes to the one shown in FIG. 35(B). FIG. 35(B) shows a screen for accepting changes in quantity. The explanation when accepting a change in quantity is as explained in FIGS. 28(B) and 28(C). Then, in FIG. 35(B), when the change in quantity is confirmed by obtaining approval from the store clerk, the screen changes to the screen shown in FIG. 35(C).

FIG. 35(C) shows a notification screen that the correction (change in quantity) has been completed. In addition, the quantity and price of the product (tomatoes) before the change are not hidden, but are displayed in a display format different from the normal display format so that the corrected content can be understood. This allows the customer to easily understand that the quantity of the product has been changed.

Further, as shown in FIG. 36(A), it is assumed that the customer presses and holds the area indicating the price in the area of the product "tomato". In this case, the screen changes to the one shown in FIG. 36(B). Here, for products on sale or closeout products, the purchase price recognized by the customer may be different from the selling price registered in the preset key. Therefore, in this embodiment, it is possible to accept changes in the amount from the customer. FIG. 36(B) shows a screen for accepting changes in the amount. FIG. 36(B) shows a screen on which input of an amount can be accepted from the customer using the numeric keypad.

In FIG. 36(B), when a change in amount is accepted, a decision button 3601 becomes operable. When the customer presses the OK button 3601 and obtains approval from the store clerk to confirm the price change, the screen transitions to the screen shown in FIG. 36(C). Note that when the OK button 3601 is pressed, a notification image 3301 (see (A) in FIG. 33) is displayed on the clerk side display section 210 of the upstream POS terminal 20, and the clerk's approval can be accepted. . FIG. 36(C) shows a notification screen that the correction (change in amount) has been completed. Furthermore, the price of the product (tomato) before the change is not hidden, but is displayed so that the corrected content can be understood. This allows the customer to easily understand that the price of the product has been changed.

In FIGS. 34 to 36, an example of correcting a product in semi-self mode has been described, but it is also possible to make corrections in the same way in full self-mode. In other words, in full self mode, when displaying items such as product name, quantity, and price in the display area showing the product, change the item shown in the long-pressed display area. You may accept it.

Note that by pressing the area indicating the product as shown in FIGS. 31 and 32, deletion of the product (including quantity change) is accepted, or deletion of the product is accepted as shown in FIGS. 34 to 36. The store clerk may be able to change the setting of whether or not to accept changes to an item by pressing the area indicating the item. Further, among the plurality of items, it may be possible to change the settings of the items for which corrections can be accepted through an operation by the store clerk. Specifically, for example, among the items indicating product name, quantity, and price, the product name and quantity may be set to accept corrections, but the price may not be subject to corrections. Good too. Furthermore, the objects of correction are not limited to the above-mentioned items, but may include, for example, items to which discount coupons are applied, items to which events such as time sales are applied, and the like.

(An example of payment processing in semi-self mode performed by POS terminal 20)
FIG. 37 is a flowchart showing an example of the payment process in the semi-self mode performed by the downstream POS terminal 20 (payment device). Note that the POS terminal 20 that performs the process shown in FIG. 37 is a POS terminal 20 (also referred to as a "settlement device") located on the downstream side.
Step S341: The POS terminal 20 determines whether registration information has been received from the upstream POS terminal 20. The POS terminal 20 waits until it receives the registration information, and upon receiving the registration information, proceeds to step S342.

Step S342: The POS terminal 20 determines whether or not a correction has been received from the customer. If the POS terminal 20 does not accept the correction from the customer, the process proceeds to step S347. When the POS terminal 20 receives a correction from the customer, the process proceeds to step S343.
Step S343: The POS terminal 20 transmits an approval request to the upstream POS terminal 20 (also referred to as "registration device"), and proceeds to step S344.

Step S344: The POS terminal 20 determines whether or not the approval result has been received from the upstream POS terminal 20. The POS terminal 20 waits until receiving the approval result from the upstream POS terminal 20, and upon receiving the approval result from the upstream POS terminal 20, proceeds to step S345.

Step S345: The POS terminal 20 determines whether the received approval result is an approval result that allows correction. If the received approval result does not allow correction, the POS terminal 20 proceeds to step S347. In this case, no correction will be made. If the received approval result is an approval result that allows correction, the POS terminal 20 proceeds to step S346.

Step S346: The POS terminal 20 receives the regenerated registration information from the upstream POS terminal 20, and proceeds to step S347.
Step S347: The POS terminal 20 determines whether the payment has been completed. If the payment is not completed, the POS terminal 20 returns to step S342. When the payment is completed, the POS terminal 20 ends the series of processing.

Through the above-described process, when the downstream POS terminal 20 (POS terminal 20 in semi-self mode) receives a correction from the customer, it requests approval from the upstream POS terminal 20 and obtains an approval result that allows the correction. If so, you can receive the regenerated registration information. As a result, the customer performs some of the operations related to correcting the product information, so it is possible to shorten the customer's waiting time related to the correction.

(About an example of the process performed when an approval request is received by the upstream POS terminal 20)
FIG. 38 is a flowchart illustrating an example of a process performed by the upstream POS terminal 20 (registration device) when an approval request is received. Note that the process shown in the flowchart of FIG. 38 is always started (regularly at very short time intervals) in the upstream POS terminal 20.

Step S361: The POS terminal 20 determines whether or not it has received an approval request regarding correction of the registered product from the downstream POS terminal 20 (payment device). The POS terminal 20 waits until receiving the approval request, and upon receiving the approval request, proceeds to step S362.

Step S362: The POS terminal 20 notifies the store clerk that the approval request has been received, and proceeds to step S363. For example, the POS terminal 20 notifies the store clerk that the approval request has been received by displaying a notification image 3301 (see (A) in FIG. 33) on the store clerk side display section 210.
Step S363: The POS terminal 20 determines whether or not the approval result (see (B) in FIG. 33) has been received from the store clerk. The POS terminal 20 waits until it receives the approval result from the store clerk, and upon receiving the approval result, proceeds to step S364.

Step S364: The POS terminal 20 transmits the approval result to the downstream POS terminal 20, and proceeds to step S365.
Step S365: The POS terminal 20 determines whether the received approval result is an approval result that allows correction. If the received approval result does not allow correction, the POS terminal 20 ends the series of processes. In this case, no correction will be made. If the received approval result is an approval result that allows correction, the POS terminal 20 proceeds to step S366.

Step S366: The POS terminal 20 regenerates the registration information, and proceeds to step S367.
Step S367: The POS terminal 20 transmits the registration information to the downstream POS terminal 20, and ends the series of processing.

Through the process described above, the upstream POS terminal 20 (POS terminal 20 in normal mode) receives the approval request from the downstream POS terminal 20, accepts the clerk's approval, and sends the received approval result to the downstream side. can be transmitted to the POS terminal 20 of. Further, when an approval result that allows correction is received, the registered information can be regenerated and transmitted to the downstream POS terminal 20. This allows the store clerk to approve the correction of the previous customer's product information even when the next customer's product is registered. Therefore, it is possible to reduce the burden on the clerk when performing approval.

According to the first embodiment described above, the customer performs some of the operations related to changing the product information, and the store clerk only needs to perform the operation for approval, so the store clerk's operations related to changing the product information are It can be simplified. Therefore, it is possible to efficiently change registered products. Thereby, the product information can be suitably changed, and the convenience of the product sales data processing device can be improved.

(Embodiment 2)
Next, a second embodiment of the present invention will be described. In the first embodiment described above, a configuration was described in which the POS terminal 20 performs product registration, product correction, approval of correction, and payment. In the second embodiment, a configuration will be described in which product registration and product correction are accepted by a mobile terminal, and correction approval and payment are performed by a payment device. In the description of the second embodiment, the same components as those of the first embodiment described above are designated by the same reference numerals, and the description thereof will be omitted as appropriate.

FIG. 39 is a network configuration diagram showing a shopping system according to Embodiment 2 of the present invention. In FIG. 39, the shopping system includes a store controller (store computer, management device) 10, a cloud server 300, a payment device 400, and a mobile terminal 500.

The cloud server 300 is a computer device including a CPU, ROM, RAM, communication section, and the like. The payment device 400 is a computer device that includes a CPU, a ROM, a RAM, a communication section, a touch panel, a key operation section, a scanner section, a card payment section, a change machine, a printing section, an audio output section, and the like. Note that the payment device 400 may be a dedicated device for performing payment, or may be a POS terminal 20 by setting the POS terminal 20 of the first embodiment to a semi-self mode. Further, the mobile terminal 500 is a computer device including a CPU, a ROM, a RAM, a communication section, an imaging section (camera), a touch panel, an audio output section, an audio input section, and the like.

The store controller 10 and the payment device 400 are installed in the store and are communicably connected via a LAN 11 (which may be wired or wireless). Further, the store controller, payment device 400, and mobile terminal 500 are each communicably connected to the cloud server 300.

The cloud server 300 manages various information such as information regarding customers, information regarding stores, and information regarding products for each store. Information managed (generated and stored) by the cloud server will be described later using FIG. 40.

The mobile terminal 500 is a terminal device operated by a customer (such as a shopper who is a member of the store), and is, for example, a communication device with a display screen such as a smartphone, a tablet device, or a mobile phone. The mobile terminal 500 is a device that accepts product registration. The mobile terminal 500 has a function of scanning barcodes attached to products and reading product codes in addition to general communication functions and imaging functions (camera). That is, the mobile terminal 500 has a recognition function that recognizes barcodes attached to products.

Note that the recognition function included in the mobile terminal 500 only needs to be capable of reading the product code, and does not need to be able to identify the product from the read product code. In other words, the mobile terminal 500 only needs to be able to read the product code from the barcode when a barcode exists as an object in the captured image captured by the imaging function (image acquired as a through image). .

Furthermore, the mobile terminal 500 captures an image of the product (for example, the surrounding area to which the barcode is attached) and generates a captured image (image data). For example, the mobile terminal 500 generates a captured image by releasing a shutter based on its own judgment. However, the mobile terminal 500 may generate the captured image by releasing the shutter according to the operation of the customer, who is the operator.

Furthermore, the mobile terminal 500 may be equipped with an image recognition technology that extracts feature points from images (through images, captured images) and recognizes imaging targets (objects, etc.). For example, the mobile terminal 500 may identify (estimate) the photographed product using image recognition technology. Specifically, the mobile terminal 500 may use image recognition technology to identify fresh foods such as vegetables and fruits that do not have a barcode attached.

Furthermore, a predetermined application (application software) is installed on the mobile terminal 500. By starting a predetermined application, the mobile terminal 500 can read a product code and register the product corresponding to the read product code (send the product code to the cloud server 300 and register it).

Further, the mobile terminal 500 is, for example, the property of each customer. However, the mobile terminal 500 may be a loan item that a store lends to a customer. Note that the number of mobile terminals 500 (number in operation) changes depending on the number of visitors to the store. In FIG. 39, two mobile terminals 500 are illustrated, but in reality, the number may be tens, hundreds, or more.

The payment device 400 is a device that performs payment for products registered by a customer's registration operation using the mobile terminal 500. Settlement device 400 accepts payments by cash, credit card, prepaid card, etc., for example.

Note that although a plurality of settlement devices 400 are illustrated in FIG. 39, there may be only one settlement device 400. Moreover, one store controller 10 may be installed in one store, or two or more store controllers 10 may be installed in one store.

(Example of information managed by cloud server 300)
Next, an example of information managed by the cloud server 300 will be described. FIG. 40 is an explanatory diagram showing an example of various information managed by the cloud server 300. The cloud server 300 stores various information including (A) customer information, (B) store information, and (C) basket information.

(A) of FIG. 40 shows an example of customer information. Customer information is information for managing individual customers. Specifically, the customer information includes customer identification information, customer name, customer registration date, cancellation information, customer rank, and number of points.

Customer identification information is identification information that uniquely identifies a customer. The customer name is the customer's full name or nickname. The customer registration date is the date and time when customer information was newly registered in the cloud server 300. The cancellation information is information indicating the number of times a registered product was canceled after being registered during shopping. The customer rank is a rank according to the customer's purchase history.

The number of points is the number of points given to the customer for shopping using this application. Note that the number of points may include the number of points for each store. Further, the customer information shown in FIG. 40(A) is an example, and in the second embodiment, it is sufficient to include at least customer identification information. Note that when the cloud server 300 generates customer information for a new customer, it generates customer identification information, customer name, and customer registration date, but since this is before the start of actual transactions (product registration), other information is generated. Information (cancellation information, etc.) is not generated.

(B) of FIG. 40 shows an example of store information. Store information is information for managing each store. Specifically, the store information includes store identification information, a store name, store specific information 1 (two-dimensional code information), and store specific information 2 (location information). The store identification information includes a store (trade name) or company code and a branch code. The store name is the name of the store, and includes, for example, a store name (trade name) or company name, and a branch name.

The store specifying information 1 and 2 is information for specifying the store where the transaction is carried out (the store where the product is bought and sold). The store specific information 1 is, for example, information on a two-dimensional code (QR code (registered trademark), etc.). Store specific information 2 is store location information (GPS information). Note that in the example shown in FIG. 40(B), store identification information and store specific information 1 are stored separately, but since both are information that can uniquely identify a store, at least one of them is stored separately. It may also be used to store information.

(C) of FIG. 40 shows an example of basket information. Basket information is information regarding a customer's purchases at a store. Specifically, the basket information includes basket identification information, transaction start date and time, transaction end date and time, customer identification information, registered product information, and cancellation candidate information. Basket identification information is information for identifying basket information. Specifically, the basket identification information includes store identification information, a date, and a serial number (for example, a serial number for each store and date).

The transaction start date and time is the start date and time of the transaction, for example, the generation date and time of the basket information. Note that the transaction start date and time may be the registration date and time of the first product (the date and time when the registered product information (registered product 1) shown in FIG. 40(C) was stored). Furthermore, the registration date and time of each product may be stored separately.

The transaction end date and time is the end date and time of the transaction, for example, the settlement date and time. The payment date and time may be the payment start date and time or the payment end date and time. The customer identification information is customer identification information that identifies the customer who performs the transaction. Although the cloud server 300 generates basket identification information, transaction start date and time, and customer identification information when generating basket information, since this is before the actual transaction (product registration) starts, other information (transaction end date and time) is generated. (date and time, etc.) are not generated.

Registered product information (total) is information that is updated every time a product is registered. The registered product information (total) includes the number of products (number of products) and subtotal amount. Registered product information (1) is registered information for the first item of product. Registered product information (2) is registered information for the second product item. Note that in the example shown in FIG. 40(C), registered product information for the third and subsequent items is omitted.

Cancellation candidate information (current total) indicates the number of times cancellation of registered products was accepted after the product was registered during the current shopping. Cancellation candidate information (cancellation candidate 1) includes a product code indicating a product to be canceled and the quantity of the product. Although not shown, if the cancellation is actually completed with the approval of the store clerk, cancellation information (not shown) indicating that the cancellation has been completed is stored. Further, the cancellation information is added to the past history and stored in the customer information (A).

Next, the processing flow of the shopping system will be explained using FIG. 41. FIG. 41 is a sequence diagram showing the processing flow of the shopping system according to the second embodiment. Note that FIG. 41 shows the flow of a customer visiting a store, registering a product to purchase using his or her mobile terminal 500, and completing payment for the product using the payment device 400. This is what is shown.

Step S401: First, the mobile terminal 500 acquires information that specifies a store (for example, store specifying information). Here, an example of an acquisition mode of information specifying a store will be described. For example, near the entrance of a store, a two-dimensional code indicating store specific information is displayed. The two-dimensional code may be displayed on a predetermined display device, or may be displayed and output by printing on a medium.

Note that the printed medium is, for example, a paper medium. This paper medium may be pasted near the entrance of the store, or may be distributed to customers at the store. A customer visiting the store uses a mobile terminal 500 to scan the two-dimensional code. Thereby, the mobile terminal 500 can acquire store specific information. Note that the two-dimensional code may include store identification information for identifying the store.

Furthermore, when a predetermined application (application software) is activated in response to an operation by a customer visiting the store, the mobile terminal 500 may display a screen prompting the user to scan a two-dimensional code as an initial screen. Further, when the mobile terminal 500 scans a two-dimensional code in response to an operation by a customer who has visited the store, the mobile terminal 500 starts an application and displays a screen notifying that the mobile terminal 500 is connected to the cloud server 300 as an initial screen. good.

Further, as another example of an acquisition mode of information specifying a store, acquisition of location information can be cited. For example, the mobile terminal 500 acquires location information (GPS information) in response to an operation by a customer visiting the store. This location information is information that replaces store specific information. Note that the mobile terminal 500 acquires location information by starting an application in response to an operation by a customer visiting the store, and displays a screen notifying that the mobile terminal 500 is connected to the cloud server 300 as an initial screen. Good too.

Note that in the cloud server 300, a store is specified according to the location information from the mobile terminal 500, but in this identification, there are cases where a plurality of stores are specified (a case where it is not possible to specify a single store). In this case, the cloud server 300 may transmit information indicating this to the mobile terminal 500. Then, the mobile terminal 500 may display a selection screen for the customer to specify the store, or may notify the customer that the customer is prompted to scan a two-dimensional code indicating store identification information.

The mobile terminal 500 that has acquired the store specific information transmits the acquired store specific information together with the customer identification information to the cloud server 300 as a transaction start request (transmission/reception data D1 in FIG. 40). The customer identification information is, for example, information stored in the cloud server 300 or the mobile terminal 500 when registering a new customer (when installing an application on the mobile terminal 500). Specifically, information such as the name entered in the registration form is attached with customer identification information by the cloud server 300 and is stored in the cloud server 300 and the mobile terminal 500.

Further, when the mobile terminal 500 acquires the store specific information, it may output information regarding services being implemented at the store (information on flyers distributed on that day) and available coupon information on the display screen. For example, information regarding services and coupon information may be transmitted from the cloud server 300 when the mobile terminal 500 requests the cloud server 300 to start a transaction.

Furthermore, the mobile terminal 500 also stores the destination information (the address of the cloud server 30) when registering a new customer (when installing an application on the mobile terminal 500). Note that the two-dimensional code displayed near the entrance of the store may include destination information (the address of the cloud server 300) in addition to the store specific information. The mobile terminal 500 can also access the cloud server 300 by scanning the two-dimensional code and acquiring store specific information as well as destination information.

Step S402: Upon receiving customer identification information and store specific information from the mobile terminal 500 as a transaction start request, the cloud server 300 generates basket information for the transaction. Specifically, the cloud server 300 generates basket identification information, transaction start date and time, and customer identification information (see (C) in FIG. 40). Note that the cloud server 300 does not generate other information (transaction end date and time, etc.) at this timing because it is before the start of the actual transaction (product registration).

Specifically, when the cloud server 300 receives store specific information and customer identification information as a transaction start request from the mobile terminal 500, it refers to the store information (see (B) in FIG. 40) and stores the store identification information. Identify. Note that when the cloud server 300 receives location information from the mobile terminal 500, it refers to the store identification information 2 of the store information and identifies the store identification information corresponding to the location information. Note that if the two-dimensional code includes store identification information, the cloud server 300 can also acquire the store identification information by decoding the received two-dimensional code.

Further, upon receiving a transaction start request (store specific information and customer identification information) from the mobile terminal 500, the cloud server 300 acquires the current date and issues (assigns) a serial number. Further, the cloud server 300 combines the acquired store identification information, the acquired current date, and the issued serial number and stores the combined information as basket identification information. Further, upon receiving a transaction start request from the mobile terminal 500, the cloud server 300 stores the current date and time in the transaction start date and time (generation date and time) in the basket information. Further, upon receiving the transaction start request from the mobile terminal 500, the cloud server 300 stores the customer identification information received from the mobile terminal 500 in the customer identification information in the basket information.

Step S403: When the cloud server 300 generates the basket for the transaction, it generates product registration initial screen information (screen information of the product registration screen that is the initial screen) and transmits it to the mobile terminal 500. Specifically, the cloud server 300 transmits the basket identification information as well as the product registration initial screen information to the mobile terminal 500 (transmission/reception data D2 in FIG. 41).

Step S404: Upon receiving the basket identification information and product registration initial screen information from the cloud server 300, the mobile terminal 500 stores the basket identification information and displays the product registration initial screen on the display unit. The product registration initial screen is, for example, a screen before product registration in FIG. 42(A), and details will be described later.

Step S405: The mobile terminal 500 scans the barcode attached to the product and reads the product code in response to the customer's operation. In FIG. 41, the description will be made assuming that the barcode has been successfully scanned. Upon acquiring the product code, the mobile terminal 500 transmits the acquired product code and basket identification information to the cloud server 300 (see transmission/reception data D3 in FIG. 41).

Step S406: Upon receiving the product code and basket identification information from the mobile terminal 500, the cloud server 300 identifies basket information including the received basket identification information.

Step S407: The cloud server 300 updates the product data included in the specified basket information. Specifically, when the cloud server 300 receives the product code for N items, it stores the product code as the product code of the registered product information (registered product N). Further, the cloud server 300 stores the product code, product name, and price in association with each other as product information (registered product N). In addition, the cloud server 300 updates the cumulative information (cumulative number of items, subtotal amount, etc.) of the registered product information in the specified basket information.

Step S408: When the cloud server 300 updates the product data in the basket, it generates product registration update screen information (screen information of the product registration screen, which is an update screen to which the registered product has been added), and sends it to the mobile terminal 500. do. Specifically, the cloud server 300 transmits the product registration update screen information as well as the basket identification information to the mobile terminal 500 (transmission/reception data D4 in FIG. 41).

Step S409: Upon receiving the basket identification information and product registration update screen information from the cloud server 300, the mobile terminal 500 displays a product registration update screen in which the product is added to the registration screen. The product registration update screen is, for example, the screen shown in FIG. 42(A), and the details will be described later. Note that although illustration is omitted in FIG. 41 for convenience of explanation, the processes in steps S405 to S409 are processes that are repeatedly executed each time a barcode attached to a product is scanned. In other words, the processes from step S405 to step S409 are looped until an accounting instruction is received at step S410, which will be described later.

Step S410: The mobile terminal 500 accepts accounting instructions operated by the customer. The checkout instruction is accepted, for example, by pressing a "checkout button" shown in FIG. 42, which will be described later.

Step S411: Upon receiving the accounting instruction, the mobile terminal 500 generates a two-dimensional code. This two-dimensional code includes information (for example, basket identification information) that is necessary for the payment device 400 to perform payment processing for the product to be purchased. After generating the two-dimensional code, the mobile terminal 500 displays the generated two-dimensional code on the display unit. The two-dimensional code display screen is, for example, the screen shown in FIG. 41(D), and the details will be described later.

Step S412: After registering the product, the customer goes to the location where the payment device 400 is located. The payment device 400 scans (reads) the two-dimensional code displayed on the display section of the mobile terminal 500. Specifically, the code reading section of the payment device 400 (the customer-side scanner section 206 in FIG. 4 when the POS terminal 20 is applied as the payment device 400) reads the display on the mobile terminal 500 in response to operations by the clerk or the customer. Read the two-dimensional code (basket identification information) displayed on the section.

Step S413: When the payment device 400 reads the two-dimensional code displayed on the display section of the mobile terminal 500, it requests the cloud server 300 to calculate the subtotal amount. For example, the payment device 400 transmits a calculation request requesting calculation of a subtotal amount (subcalculation request information) and basket identification information restored from the two-dimensional code to the cloud server 300 (transmission/reception data D5 in FIG. 40). .

Step S414: Upon receiving the basket identification information and subcalculation request information from the payment device 400, the cloud server 300 identifies basket information including the received basket identification information.

Step S415: After identifying the basket information, the cloud server 300 calculates (identifies) the subtotal amount (registered product information (total)) included in the identified basket information. Note that if there is a discount for each product, the subtotal amount may be calculated by calculating the discount amount for each product in step S415.

Step S416: After specifying the subtotal amount, the cloud server 300 transmits subtotal information indicating the specified subtotal amount together with the basket identification information to the payment device 40 (transmission/reception data D6 in FIG. 41).

Step S417: Upon receiving the basket identification information and subtotal information from the cloud server 300, the payment device 400 displays the subtotal amount on the display unit (the customer side display unit 205 in FIG. 4 when the POS terminal 20 is applied as the payment device 400). indicate. The subtotal amount display screen (settlement screen) is, for example, the screen shown in FIG. 44(A), and the details will be described later.

Step S418: After displaying the subtotal amount on the display unit, the payment device 400 executes payment (settlement). Specifically, payment device 400 accepts selection of payment type. Further, when the payment is completed, the payment device 400 issues a receipt and transmits payment completion information to the cloud server 300 together with the basket information. The cloud server 300 then stores the transaction end date and time (settlement date and time) of the basket.

Further, in step S418, the customer selects a payment method for the product payment process on the payment screen. However, the payment method may be registered in advance in the application. If the payment method is registered, the payment device 400 does not need to display a screen for selecting the payment method. Note that even if a payment method is registered, the payment device 400 may display a screen for selecting a payment method.

If the payment method is cash, the deposit is accepted, the amount of change is calculated, and if there is change, the change is released. Further, the payment method may be payment using a gift certificate or payment using points of a point member. It is also possible to use coupons, discount tickets, and the like. Even in this case, the payment device 400 performs payment in the same way as normal payment processing, such as dispensing change and issuing a receipt. Note that if a store clerk is required, such as when collecting a gift certificate at the time of payment, the settlement device 400 calls a store clerk. Specifically, the payment device 400 may call a clerk when a payment method that requires a clerk is selected. Further, the payment device 400 may notify the clerk to guide the clerk to a service counter, a manned POS, or the like when a necessary payment method is selected.

(An example of screen transition when accepting product corrections in Embodiment 2)
Next, an example of the screen transition when accepting correction of a product according to the second embodiment will be described with reference to FIGS. 42 and 43. FIG. 42 is an explanatory diagram showing an example of screen transition when accepting product cancellation in the second embodiment.

In (A) of FIG. 42, two products, "○○ tea" and "○○ bread" are registered by the customer operating the mobile terminal 500 and having the mobile terminal 500 read the product barcode. Show that there is. Note that the screen in FIG. 42(A) is the screen displayed by the process in step 409 in FIG. 41. Note that on the screen before registering a product (product registration initial screen: see step S404 in FIG. 41), the product item is displayed as a blank field. Further, in FIG. 42(A), a guide display 4201 is displayed. A guidance display 4201 indicates that the registered product can be corrected by long-pressing the item field of the product that the customer desires to correct (change). Note that correction operations can be accepted not only by long-pressing the item of the target product; for example, by displaying a "correction button" and pressing the button, the target product is selected. It is also possible to do so.

As shown in (A) of FIG. 42, it is assumed that the area indicating "○○ bread" is pressed and held. In other words, assume that the customer performs an operation to correct the product "○○ bread." In this case, the screen changes to the one shown in FIG. 42(B). (B) of FIG. 42 shows a confirmation screen for confirming whether or not to cancel "○○ bread". If the customer selects "No" on the confirmation screen, the screen returns to the screen shown in FIG. 42(A), for example, and product registration can be accepted again. On the other hand, if the customer selects "Yes" on the confirmation screen, the screen transitions to the screen shown in FIG. 42(C).

Here, a description will be given of the processing performed by the mobile terminal 500 and the cloud server 300 when the customer selects "Yes" on the confirmation screen. When the customer selects "Yes" on the confirmation screen, the mobile terminal 500 transmits information indicating a cancellation request, the product code to be canceled, and basket identification information to the cloud server 300. Upon receiving this information from the mobile terminal 500, the cloud server 300 specifies the basket information (see (C) in FIG. 40) including the received basket identification information.

The cloud server 300 updates the product data included in the specified basket information. Specifically, when the cloud server 300 receives the product code of N items to be canceled, it refers to the registered product information in the specified basket information and selects the product corresponding to the product code (registered product N). is stored as cancellation candidate information. The cancellation candidate information is information in which a product code, product name, and price are associated with each other (see (C) in FIG. 40). Furthermore, since the cancellation has not been completed (approval by the store clerk has not been completed), the cloud server 300 does not update the cumulative information (cumulative number of items, subtotal amount, etc.) of the registered product information. However, since it is assumed that the cancellation will occur after this, you may update the cumulative information (cumulative number of products, subtotal amount, etc.) in the registered product information, or you can update both the updated value and the value that is not updated. may be memorized. Furthermore, by transmitting both the updated value and the non-updated value from the cloud server 300 to the mobile terminal 500, both values may be displayed on the mobile terminal 500.

When the cloud server 300 updates the basket information, it generates product registration update screen information (screen information indicating that cancellation has been accepted) and transmits it to the mobile terminal 500. When the mobile terminal 500 receives the product registration update screen information, it displays the screen shown in FIG. 42(C).

(C) of FIG. 42 shows the screen when the cancellation of the product is accepted. Furthermore, in (C) of FIG. 42, it is displayed that the cancellation of the product has not been confirmed and that the store clerk's approval is required at the time of checkout. Furthermore, the product to be canceled (○○ bread) is not hidden, but is clearly indicated as such by, for example, being marked with a strikethrough line. This allows the customer to easily understand which products are subject to cancellation. After (C) in FIG. 42, when the customer continues shopping and then presses the "checkout button", the screen changes to the screen shown in (D) in FIG. 42.

(D) of FIG. 42 shows a display screen of a two-dimensional code used in the payment process for the product to be purchased. Note that the processing of the mobile terminal 500 when the "checkout button" is pressed is as shown in steps S410 and S411 in FIG. 41. In addition, in (D) of FIG. 42, similarly to (C), "approval required" is displayed indicating that approval from the clerk is required at the time of checkout. When the two-dimensional code shown in FIG. 42(D) is read by the payment device 400, payment processing is performed in the payment device 400.

(About other screen examples when correcting products in Embodiment 2)
FIG. 43 is an explanatory diagram showing an example of screen transition when accepting a change in the quantity of products in the second embodiment. Note that the screen shown in FIG. 43 differs from the screen shown in FIG. 42 in that a change in quantity is accepted.

In (A) of FIG. 43, two products, "○○ tea" and "○○ bread" are registered by the customer operating the mobile terminal 500 and having the mobile terminal 500 read the product barcode. Show that there is. As shown in FIG. 43(A), it is assumed that the customer presses and holds the area indicating "○○ bread". In this case, the screen changes to the one shown in FIG. 43(B). FIG. 43(B) shows a screen for accepting changes in quantity. In FIG. 43B, when the "+" button is pressed, the quantity is added according to the number of times the "+" button is pressed. On the other hand, when the "-" button is pressed, the quantity is subtracted according to the number of times the "-" button is pressed. Note that by setting the quantity to "0", it is also possible to cancel the product in the same way as in FIG.

In FIG. 43B, it is assumed that the enter button 4301 is pressed after accepting a change that increases the quantity. In this case, since the increase in quantity is not recognized as a fraudulent act, the increase in quantity is accepted without requiring approval from the store clerk, and the process returns to the registration screen shown in FIG. 43(A).

On the other hand, assume that the enter button 4301 is pressed after accepting a change that reduces the quantity. In this case, since the clerk needs to confirm whether the correction is legitimate, the clerk's consent is required at the time of checkout. Further, for products registered by having the barcode read, the quantity may not be set to "0". Specifically, as shown in FIG. 43(B), even if the customer presses the "-" button when the quantity is "1", the quantity may not become "0".

Note that even in this case, since the customer may wish to cancel, it is sufficient to set the quantity to "0" and have the clerk perform the cancellation operation at the time of payment. In addition, as shown in FIG. 42 described above, by pressing the area indicating the product, the setting can be changed by the store clerk as to whether to accept the deletion of the product or to accept the change in quantity as shown in FIG. 43. It may be possible to do so. Further, by pressing an area indicating a product, a selection screen may be displayed to allow the customer to select whether to accept deletion of the product or change of quantity.

(About an example of the payment screen in Embodiment 2)
FIG. 44 is an explanatory diagram showing an example of the payment screen according to the second embodiment. (A) of FIG. 44 shows a payment screen displayed when the payment device 400 reads the two-dimensional code (see (D) of FIG. 44) displayed on the mobile terminal 500. Note that the processing when reading the two-dimensional code and displaying the payment screen is as shown in steps S412 to S417 in FIG. 41. On the payment screen in FIG. 44(A), it is displayed that the clerk is currently on call.

Then, when a clerk near the payment device 400 reads the clerk code attached to his or her name tag into the payment device 400, the clerk is authenticated. Note that if a clerk near the payment device 400 has already logged in (for example, if there is a store clerk assigned to the payment device 400), there is no need to perform authentication again.

FIG. 44(B) shows a confirmation screen for approval by the store clerk. The store clerk visually confirms (by checking the products in the cart) whether the correction information entered by the customer is correct (whether it is an erroneous operation or registration error), and if it is determined to be correct, a confirmation screen will be displayed. Click "Yes". When the store clerk selects "Yes" on the confirmation screen, the cancellation of the target product is completed.

The processing by the payment device 400 and the cloud server 300 in this case will be explained. When “Yes” is selected on the confirmation screen, the payment device 400 transmits information indicating this to the cloud server 300. Upon receiving the information from the payment device 400, the cloud server 300 updates the cumulative information (cumulative number of items, subtotal amount, etc.) of the registered product information. Then, the cloud server 300 transmits product registration update screen information including the updated cumulative information to the payment device 400. When the payment device 400 receives the product registration update screen information, it displays the screen shown in FIG. 44(C).

(C) of FIG. 44 shows the product registration update screen in which the correction (cancellation) has been completed and payment can now be made. As shown in FIG. 44(C), the total amount is reduced due to the cancellation of the product compared to FIG. 44(B). Furthermore, the product (○○ bread) that is subject to cancellation is not hidden, but is marked with a strikethrough line, for example. This makes it clear which products have been canceled. Therefore, the customer and the store staff can easily understand that the product has been cancelled.

According to the second embodiment, a customer can cancel or correct a product while registering the product, that is, without waiting until the time of checkout. Therefore, since there is no need to accept cancellations or corrections at the time of payment, it is possible to speed up the payment. Therefore, congestion at the time of payment can be alleviated.

(Modification of Embodiment 2)
Next, a modification of the second embodiment will be described. In the second embodiment described above, a configuration in which a store clerk approves a correction in the payment device 400 has been described. In a modification of the second embodiment, instead of or in addition to such a configuration, a configuration will be described in which a store clerk goes to the customer's location and approves the correction.

In a modified example, it is assumed that the mobile terminal 500 is held not only by the customer but also by a store clerk (one or more store clerks). The mobile terminal 500 carried by the store clerk may be the store clerk's property or may be a loaned item from the store. Further, the mobile terminals 500 owned by store clerks are managed by the cloud server 300 so that each store clerk can be identified. Specifically, the cloud server 300 stores, for example, identification information (clerk) and an address in association with each other for each mobile terminal 500 of each clerk.

Furthermore, the cloud server 300 also manages the sales floors that are handled by store employees. Specifically, the cloud server 300 stores the store clerk's identification information and the store in charge of the store in association with each other, and also stores each product in association with the store. Thereby, the cloud server 300 can identify the sales floor person (the clerk in charge of the sales floor) based on the product. Specifically, the cloud server 300 can identify the sales floor corresponding to the product based on the product, and can further identify the store clerk corresponding to the identified sales floor.

In a modified example, as shown in FIG. 42(B), it is assumed that the customer performs a product cancellation operation. In this case, the customer's mobile terminal 500 transmits information regarding the cancellation (information indicating a request for cancellation, the product code to be canceled, and basket identification information) to the cloud server 300. The cloud server 300 updates the basket information based on the information regarding the cancellation received from the customer's mobile terminal 500 (see (C) in FIG. 40). Further, the cloud server 300 identifies the sales staff from the updated products, and transmits information that the cancellation has been accepted and product information to be canceled to the mobile terminal 500 of the sales staff.

Then, the store clerk goes to the customer who performed the cancellation operation, visually checks the product to be canceled, and if there is no problem, performs an approval operation using the store clerk's mobile terminal 500. When approval is given, the clerk's mobile terminal 500 transmits information indicating this to the cloud server 300. When the cloud server 300 receives the information from the store clerk's mobile terminal 500, the cloud server 300 updates the cumulative information (cumulative number of items, subtotal amount, etc.) of the registered product information. This allows the cancellation to be completed without waiting until the time of payment.

Furthermore, in the above description, when the mobile terminal 500 receives a cancellation, the cloud server 300 transmits information indicating that the cancellation has been accepted to the mobile terminal 500 of the person in charge of the sales floor. Instead of or in addition to this configuration, it is also possible to configure the information to be transmitted to the mobile terminal 500 of a store clerk near the customer who performed the cancellation operation. However, position information is used for such a configuration.

Specifically, when the customer performs a product cancellation operation, the customer's mobile terminal 500 stores the information indicating the cancellation request, the product code to be canceled, and the basket identification information, as well as the mobile terminal 500. The location information of the terminal 500 is also transmitted to the cloud server 300. The position information is, for example, information for specifying a position within a store. For example, the mobile terminal 500 uses the detection results of various sensors placed in the store, the signal and radio field strength of the wireless LAN located in the store, the detection results of various sensors built into the mobile terminal 500, etc. , location information can be obtained.

Further, the cloud server 300 manages location information of store employees. Specifically, the store clerk's mobile terminal 500 sequentially transmits its own location information to the cloud server 300. Upon receiving the store clerk's location information, the cloud server 300 updates the location information in association with the store clerk's identification information. When the cloud server 300 receives information regarding cancellation including the location information of the customer's mobile terminal 500 from the customer's mobile terminal 500, the cloud server 300 cancels the cancellation based on the location information and the stored store clerk's location information. Information indicating that the cancellation has been accepted is transmitted to the mobile terminal 500 of a nearby clerk. Thereby, a store clerk who is near the customer who performed the cancellation operation can be quickly dispatched to the customer. Even in this case, the cancellation can be completed without waiting until the time of payment.

Furthermore, in the above description, a configuration has been described in which the store clerk uses the store clerk's mobile terminal 500 to approve the cancellation, but it is also possible to approve the cancellation using the customer's mobile terminal 500. Specifically, when the cloud server 300 receives information regarding cancellation from the customer's mobile terminal 500, it issues a password (information that only the clerk can know) for accepting cancellation approval, and the issued password is passed to the clerk. Send to mobile terminal 500.

The store clerk goes to the customer who performed the cancellation operation, visually confirms the product to be canceled, and if there is no problem, inputs the password from a predetermined screen on the customer's mobile terminal 500. The entered password is transmitted from the customer's mobile terminal 500 to the cloud server 300, and is used to determine whether it matches the password issued by the cloud server 300. If the cloud server 300 determines that there is a match in the determination, it approves the cancellation. Then, the cloud server 300 updates the cumulative information (cumulative number of products, subtotal amount, etc.) of the registered product information, and transmits product registration update screen information including the updated cumulative information to the customer's mobile terminal 500. Even in this case, the cancellation can be completed without waiting until the time of payment.

According to the above-described modification, it is not necessary to approve cancellation at the time of payment, so that payment can be made more quickly. Therefore, it is possible to further reduce congestion at the time of payment.

Additional notes are disclosed below.

(Additional note 1)
In a product sales data processing device that can be operated by a customer, a change reception means receives from a customer a change in product information indicating a product registered in one transaction, and a store clerk accepts a change in the product information accepted by the change reception means. Product sales data processing characterized by comprising: an approval input means for inputting an approval result by the approval input means; and a product information changing means for changing the product information by inputting the approval result by the approval input means. Device.

I would like to add some additional information regarding Appendix 1. One transaction is, for example, a transaction from the start of product registration through a customer's operation until the completion of payment. Product information is, for example, registration information. The change acceptance means accepts changes to product information from the customer at any time from the start of product registration to the completion of payment; for example, before pressing the subtotal key during product registration. It may be the timing, or the timing after pressing the subtotal key when the product registration is completed.

The product sales data processing device (POS terminal 20) calls a store clerk when the change is accepted by the change accepting means. A call to the store clerk is made at the POS terminal 20 where the store clerk is located, a mobile terminal owned by the store clerk, or a management device.

The approval input means inputs the approval result by the clerk who received the call. The mode of input by the approval input means may be, for example, by directly accepting the operation of the store clerk, or by receiving it from another terminal (another POS terminal 20, a mobile terminal owned by the store clerk, or a management device). . By inputting the approval result, the product information changing means changes the product information.

According to Addendum 1, since the customer performs some of the operations related to changing product information, and the store clerk only needs to perform the operation for approval, the store clerk's operations related to changing product information are simplified. be able to. Furthermore, it is possible to shorten the waiting time for customers regarding changes. Therefore, it is possible to efficiently change registered products. In addition, since customers can request changes without verbally, for example, customers who are concerned about further congestion due to changes when the situation is crowded, or customers who feel embarrassed about changes, etc. Mental burden can be reduced. As a result, according to Supplementary Note 1, the product information can be suitably changed, and the convenience of the product sales data processing device can be improved.

(Additional note 2)
The apparatus further includes operation display means for displaying the product information in different display areas for each product, and the change reception means accepts from a customer one of the display areas displayed by the operation display means. The product sales data processing device according to appendix 1, wherein the product sales data processing device receives a change in the product information indicated by the received display area.

Specifically, appendix 2 states that, for example, by long-pressing the display area indicating the product that the customer desires to change, changes to the product information are accepted (see (A) in FIG. 25). Additionally, appendix 2 includes the content that, among the items indicating the product name, quantity, and price in the display area indicating the product, changes to the item indicated by the long-pressed display area are accepted (Figs. 34 to 34). 36). Thereby, the customer can specify the product to be changed simply by pressing the change target displayed on the display screen. Further, the customer can, for example, specify the product to be changed with a single operation. Thereby, product information can be changed efficiently.

However, the change accepting means may display a button indicating that a change is to be made, and when the button is pressed, the customer may accept the product or item that the customer desires to change. That is, changes to product information may be accepted through multiple operations.

(Additional note 3)
The store further includes a clerk-side operation section that can be operated by a clerk and a customer-side operation section that can be operated by a customer, and the approval input means inputs the approval result in response to an operation on the clerk-side operation section. The product sales data processing device according to appendix 1 or 2, characterized in that:

Supplementary note 3 states that, for example, in the POS terminal 20 that includes the clerk-side display section 210 and the customer-side display section 205, the clerk's approval is accepted by operating the clerk-side display section 210. Further, for example, it is possible to accept changes from the customer by operating the customer side display section 205. Thereby, when a store clerk is registering a product on the store clerk side display section 210 or when a change in product information is received from a customer after registering the product, the store clerk can approve it on the spot. Therefore, it is possible to reduce the burden on the clerk when performing approval. Thereby, the product information can be changed efficiently, and the usability of the product sales data processing device can be improved.

(Additional note 4)
A customer-side operation means that can be operated by a customer, an identification information input means for inputting identification information for identifying a store clerk, and a store employee identification means for identifying the store clerk using the identification information input by the identification information input means. Supplementary Notes 1 to 3, characterized in that the approval input means inputs the approval result by accepting an operation on the customer-side operation means when a store clerk is specified by the store clerk specifying means. A product sales data processing device according to any one of the above.

The customer-side operation means in Appendix 4 is a display unit that accepts changes in product information from the customer, and is, for example, the customer-side display unit 205 in the POS terminal 20 or the display unit of a payment device that does not have a product registration function. Specifically, appendix 4 states that when a change is received from a customer, a store clerk goes to the terminal where the change was accepted, and if the clerk's authentication is successful, approval is received from the store clerk. As a result, the store clerk's approval can be accepted on the screen where changes in product information are accepted from the customer, so that the change operation and the approval operation can be performed consecutively. Therefore, it is easy for customers and store staff to understand the details of the change and the fact that it has been changed, and it is possible to prevent misunderstandings and erroneous operations related to the change. Therefore, product information can be changed efficiently.

(Appendix 5)
A mode setting means for setting one of a plurality of modes is provided, and the approval input means accepts an operation on the customer side operation means when a predetermined mode is set by the mode setting means. The product sales data processing device according to appendix 4, wherein the approval result is inputted.

Specifically, appendix 5 states that when the full self mode is set, the store clerk's approval is accepted by operating the customer side display section 205. Thereby, in the full self-mode, the customer-side display section 205 can accept registration of product information and changes in product information from the customer, as well as approval from the store staff. Therefore, in the full self mode, the change operation and the approval operation can be performed continuously on the customer side display section 205. Therefore, product information can be changed efficiently.

(Appendix 6)
Any one of Supplementary Notes 1 to 5, wherein the change accepting means accepts a change to a predetermined quantity for the quantity of the product indicated by the product information when the product information is registered in a predetermined registration mode. The product sales data processing device described in one item.

The predetermined registration mode in Appendix 6 is, for example, a registration mode by reading a barcode. Further, the predetermined quantity is, for example, a quantity excluding "0". Specifically, appendix 6 states that when product information is registered by reading a barcode, changes to the quantity of the product to a quantity other than "0" are accepted. In other words, if product information is registered by reading a barcode, changes to the quantity of the product to "0" will not be accepted.

This is because for products with barcodes, since the barcode has been read and it is clear that the product actually exists, changing the quantity to "0" is not expected. For this reason, a change to set the quantity to "0" is highly likely to be an erroneous operation, so it is not accepted. According to Appendix 6, erroneous operations related to quantity changes can be prevented, and product information can be changed efficiently.

(Appendix 7)
A product sales data processing system comprising a registration device that registers product information indicating a product, and a payment device that performs payment, wherein the payment device registers the product information registered by the registration device in one transaction. A change is received from a customer, the registration device inputs an approval result by a store clerk regarding the change of the product information accepted by the payment device, and the product information is changed by inputting the approval result. Features: Product sales data processing system.

The registration device in appendix 7 is, for example, a normal mode POS terminal 20 disposed on the upstream side, and registers product information through operation by a store clerk. Note that the registration device only needs to have the function of registering product information; in other words, it does not have to have the function of registering product information by the customer's operation or the function of making payment by the customer's operation. good. Further, the payment device in Appendix 7 is, for example, a semi-self-mode POS terminal 20 disposed on the downstream side, and performs payment by a customer's operation. It should be noted that the payment device only needs to have a function of performing payment by a customer's operation; in other words, it does not need to have a function of registering product information. Further, a plurality of payment devices may be installed corresponding to one registration device.

Upon receiving a change in product information from a customer, the payment device requests the registration device to approve the change. Note that the payment device may only request the registration device to approve the change and not transmit the details of the change. When the registration device receives an approval request from the payment device, the registration device accepts approval from the store clerk regarding changes in product information. For example, the registration device may receive only an approval request from the payment device and display only an approval button for accepting approval. In this case, the clerk can press the approval button by visually confirming the details of the customer's changes on the payment device.

According to Appendix 7, since the customer performs some of the operations related to changing product information on the checkout device, and because the store clerk only needs to perform the approval operation on the registration device, the store clerk changes the product information. The operation can be simplified. Furthermore, it is possible to shorten the waiting time for customers who perform change operations on the payment device. Therefore, it is possible to efficiently change registered products. Thereby, according to appendix 7, it is possible to suitably change product information, and the convenience of the product sales data processing system can be improved.

(Appendix 8)
The payment device transmits change information indicating a change in the product information received from the customer to the registration device, and the registration device inputs the approval result by receiving the change information from the payment device. , the product sales data processing system according to appendix 7.

Specifically, Appendix 8 states that when the payment device receives a change in product information from a customer, it transmits the change information (including the details of the change and an approval request) to the registration device, and the registration device receives the change information from the payment device. By receiving the message, the store clerk's approval is accepted. This allows the clerk to grasp the details of the change on the payment device. Therefore, when a store clerk is registering a product in the registration device or when a change in product information is received from a customer after registering the product, the store clerk can approve it on the spot. This makes it possible to reduce the burden on store staff when performing approval. Therefore, the product information can be changed efficiently, and the convenience of the product sales data processing system can be improved.

(Appendix 9)
The registration device and the payment device both set one of a plurality of modes, and when the payment device sets a predetermined mode, the payment device transmits the change information to the registration device, and the payment device transmits the change information to the registration device. The product sale according to appendix 8, wherein the registration device inputs the approval result by receiving the change information from the payment device when a mode different from the predetermined mode is set. Data processing system.

Addendum 9 specifies that when the payment device (downstream POS terminal 20) sets the full self mode, change information is sent to the registration device, and the registration device (upstream POS terminal 20) , when the normal mode is set, change information is received from the payment device. Product information can be changed according to the mode set in each POS terminal 20 in the POS system 1. Therefore, it is possible to efficiently change product information in full self-mode.

(Appendix 10)
A program that causes a computer to function as a product sales data processing device that can be operated by a customer, the change receiving means accepting changes from the customer to product information indicating a product registered in one transaction, and the change receiving means accepting changes. It is characterized by functioning as an approval input means for inputting an approval result by a store clerk regarding a change in the product information, and a product information changing means for changing the product information by inputting the approval result by the approval input means. program to do.

Note that a program for realizing the POS system 1 and POS terminal 20 described above may be recorded on a computer-readable recording medium, and the program may be read and executed by the computer system. Note that the "computer system" herein includes hardware such as an OS and peripheral devices. Furthermore, the term "computer-readable recording medium" refers to portable media such as flexible disks, magneto-optical disks, ROMs, and CD-ROMs, and storage devices such as hard disks built into computer systems. Furthermore, "computer-readable recording medium" refers to volatile memory (RAM) inside a computer system that serves as a server or client when a program is transmitted via a network such as the Internet or a communication line such as a telephone line. This also includes programs that are retained for a certain period of time. Further, the program may be transmitted from a computer system storing the program in a storage device or the like to another computer system via a transmission medium or by a transmission wave in a transmission medium. Here, the "transmission medium" that transmits the program refers to a medium that has a function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. Moreover, the above-mentioned program may be for realizing a part of the above-mentioned functions. Furthermore, it may be a so-called difference file (difference program) that can realize the above-described functions in combination with a program already recorded in the computer system.

1...POS system 10...Store controller 20...POS terminal 201...CPU
202...ROM
203...RAM
204...Hard disk 205...Customer side display section 206...Customer side scanner section 208...Card payment section 209...Change machine 210...Staff side display section 211...Key operation section 212...Staff side scanner section 213...Printing section 214...Audio output section 215...Communication Department

The present invention relates to a product sales data processing system, a product sales data processing method, a payment device, and a program.

In order to solve the above-mentioned problems, a product sales data processing system , which is an aspect of the present invention , includes a terminal device carried by a customer for registering products, and a payment system for paying for the products registered by the terminal device. In the product sales data processing system including a product sales data processing system, the terminal device includes a change reception means for receiving a change in product information indicating a product registered in one transaction from a customer by receiving an operation from the customer ; The payment device includes, in the payment, an approval input means for inputting an approval result by a store clerk regarding the change of the product information accepted by the change acceptance means; and an approval result inputted by the approval input means. This is a product sales data processing system characterized by comprising: product information changing means for changing product information.

In order to solve the above-mentioned problems, a product sales data processing method, which is another aspect of the present invention, includes a terminal device held by a customer for registering products, and a terminal device for paying for the products registered by the terminal device. A product sales data processing method of a product sales data processing system including a payment device, wherein the terminal device allows the customer to change product information indicating products registered in one transaction by accepting an operation from the customer. In the payment process, the payment device executes an approval input step of inputting an approval result by the store clerk regarding the change in the product information accepted in the change reception step, and a change acceptance step in which the payment device receives the changes from the store clerk. This product sales data processing method is characterized in that a process including a product information changing step of changing the product information in response to an input of an approval result is executed.

In order to solve the above-mentioned problems, a payment device according to another aspect of the present invention includes a terminal device carried by a customer to register products, and a payment device to perform payment for products registered by the terminal device. In a payment device of a product sales data processing system including: a change in product information indicating a product registered in one transaction in the payment process, the product information is changed in response to an operation from a customer by the terminal device; an approval input means for inputting an approval result by a store clerk;
The payment device is characterized by comprising: a product information changing unit that changes the product information by inputting the approval result by the approval input unit.

In order to solve the above-mentioned problems, a program according to another aspect of the present invention includes a terminal device carried by a customer for registering products, and a payment device for paying for the products registered by the terminal device. A program that causes a computer to function as a payment device for a product sales data processing system that includes a product sales data processing system, wherein the computer is used to change product information indicating products registered in one transaction, and in which the terminal device receives an operation from a customer. Functioning as an approval input means for inputting an approval result by a store clerk regarding the received change of the product information, and a product information change means for changing the product information by inputting the approval result by the approval input means. This is a program featuring the following.

Claims (19)

In a product sales data processing device that can be operated by a customer,
a customer-side operation means that can be operated by the customer;
a change reception means for accepting a change in product information indicating a product registered in one transaction from a customer by accepting an operation on the customer side operation means;
identification information input means for inputting identification information for identifying a store clerk;
a clerk identifying means for identifying a clerk using the identification information input by the identification information input means;
Approval input means for inputting an approval result by the store clerk for the change in the product information accepted by the change reception means by accepting an operation on the customer side operation means when the store clerk is identified by the store clerk identification means; and,
Product information changing means for changing the product information by inputting the approval result by the approval inputting means;
A product sales data processing device comprising: comprising mode setting means for setting one of a plurality of modes;
The approval input means inputs the approval result by accepting an operation on the customer-side operation means when a predetermined mode is set by the mode setting means.
The product sales data processing device according to claim 1. A product sales data processing system comprising a registration device for registering product information indicating products, and a payment device for performing payment, the system comprising:
The payment device is
receiving from a customer a change in the product information registered by the registration device in one transaction;
The registration device includes:
inputting an approval result by a store clerk regarding the change in the product information accepted by the payment device;
changing the product information by inputting the approval result;
A product sales data processing system characterized by: The payment device transmits change information indicating a change in the product information received from the customer to the registration device,
the registration device inputs the approval result by receiving the change information from the payment device;
4. The product sales data processing system according to claim 3. The registration device and the payment device both set one of a plurality of modes,
The payment device transmits the change information to the registration device when a predetermined mode is set;
The registration device inputs the approval result by receiving the change information from the payment device when a mode different from the predetermined mode is set.
5. The product sales data processing system according to claim 4. A program that causes a computer to function as a product sales data processing device equipped with a customer-side operation unit that can be operated by a customer,
The computer,
a change reception means for receiving a change in product information indicating a product registered in one transaction from a customer by receiving an operation on the customer side operation unit;
identification information input means for inputting identification information for identifying a store clerk;
a clerk identifying means for identifying a clerk using the identification information input by the identification information input means;
Approval input means for inputting an approval result by the store clerk for the change in the product information accepted by the change reception means by accepting an operation on the customer side operation unit when the store clerk is identified by the store clerk identification means; ,
product information changing means for changing the product information by inputting the approval result by the approval inputting means;
A program characterized by functioning as The computer,
Function as a mode setting means to set one of multiple modes,
The approval input unit inputs the approval result by accepting an operation on the customer side operation unit when a predetermined mode is set by the mode setting unit.
7. The program according to claim 6. A product sales data processing device equipped with a customer-side operation unit that can be operated by customers.
a change reception step of accepting a change in product information indicating a product registered in one transaction from a customer by accepting an operation on the customer side operation unit;
an identification information input step of inputting identification information for identifying the store clerk;
a clerk identification step of identifying the clerk using the identification information input in the identification information input step;
an approval input step of inputting an approval result by the store clerk for the change in the product information received in the change acceptance step by accepting an operation on the customer-side operation unit when the store clerk is identified in the store clerk identification step; ,
a product information changing step of changing the product information by inputting the approval result in the approval input step;
Product sales data processing method that performs processing including. The product sales data processing device
Execute a mode setting step to set one of multiple modes,
In the approval input step, when a predetermined mode is set in the mode setting step, the approval result is input by accepting an operation on the customer side operation unit.
9. The product sales data processing method according to claim 8. A program that causes a computer to function as a product sales data processing system comprising a registration device that registers product information indicating products and a payment device that performs payment, the program comprising:
In the computer of the payment device,
receiving from a customer a change in the product information registered by the registration device in one transaction;
execute the process,
on the computer of the registration device;
inputting an approval result by a store clerk regarding the change in the product information accepted by the payment device;
changing the product information by inputting the approval result;
A program characterized by executing processing. transmitting, to the computer of the payment device, change information indicating a change in the product information received from the customer to the registration device;
execute the process,
inputting the approval result into the computer of the registration device by receiving the change information from the payment device;
11. The program according to claim 10, which causes the program to execute a process. setting one of a plurality of modes in both the computer of the registration device and the computer of the payment device;
execute the process,
transmitting the change information to the registration device when a predetermined mode is set in the computer of the payment device;
execute the process,
inputting the approval result by receiving the change information from the computer of the payment device when a mode different from the predetermined mode is set on the computer of the registration device;
12. The program according to claim 11, which causes the program to execute a process. A product sales data processing method for a product sales data processing system comprising a registration device for registering product information indicating products and a payment device for performing payment, the method comprising:
The payment device is
executing a process of accepting from a customer a change in the product information registered by the registration device in one transaction;
The registration device,
inputting an approval result by a store clerk regarding the change in the product information accepted by the payment device;
changing the product information by inputting the approval result;
A product sales data processing method characterized by executing processing. The payment device executes a process of transmitting change information indicating a change in the product information received from the customer to the registration device,
14. The product sales data processing method according to claim 13, wherein the registration device executes processing for inputting the approval result by receiving the change information from the payment device. The registration device and the payment device both execute processing for setting one of a plurality of modes,
When the payment device sets a predetermined mode, the payment device executes a process of transmitting the change information to the registration device,
Claim 14, wherein when the registration device sets a mode different from the predetermined mode, the registration device executes a process of inputting the approval result by receiving the change information from the payment device. Product sales data processing method described in . The above-mentioned registration of a product sales data processing system includes a registration device that registers product information indicating a product, and a payment device that performs payment and receives changes from a customer to the product information registered by the registration device in one transaction. A device,
The registration device includes:
inputting an approval result by a store clerk regarding the change in the product information accepted by the payment device;
changing the product information by inputting the approval result;
A registration device characterized by: The registration device includes a registration device that registers product information indicating a product, and a payment device that performs payment, and the registration device inputs an approval result by a store clerk regarding the change in the product information accepted by the payment device, and inputs the approval result. The payment device of the product sales data processing system changes the product information by inputting a
The payment device is
receiving from a customer a change in the product information registered by the registration device in one transaction;
A payment device characterized by: The above-mentioned registration of a product sales data processing system includes a registration device that registers product information indicating a product, and a payment device that performs payment and receives changes from a customer to the product information registered by the registration device in one transaction. A program that causes a computer to function as a device,
to the computer;
inputting an approval result by a store clerk regarding the change in the product information accepted by the payment device;
changing the product information by inputting the approval result;
A program characterized by executing processing. The registration device includes a registration device that registers product information indicating a product, and a payment device that performs payment, and the registration device inputs an approval result by a store clerk regarding the change in the product information accepted by the payment device, and inputs the approval result. A program that causes a computer to function as the payment device of a product sales data processing system that changes the product information by inputting the information, the program comprising:
receiving from a customer a change in the product information registered by the registration device in one transaction;
A program characterized by executing processing.

Images