KR920007255B1 - Operating method for point of sales terminal - Google Patents

Abstract

The method is for transfering the right of management of sales person and articles to a slave system of a point of sales system when a main system drops, and for transfering to the main system when the main system is reconstructed. The method includes the steps: (A) sending file of sales persons to n arbitrary slave terminal; (B) checking sign off of the slave terminal and master system down; (C) checking the change of sales person; (D) renewing slave file when article information is received at artiole registeration mode and renewing the file of sales person; (E) sending files of sales person to the master system when the master system is not down at sign off state of a slave system, and (F) creating temperary file of sales person when sales person is requested at system down state.

Description

How the Force Terminal Works When the Force System Is Down

1 is a file holding state diagram of a master and a slave terminal of a force system according to the present invention.

2 is a system block diagram to which the present invention is applied.

3 and 4 are flow charts of the present invention.

5 is a file holding state and configuration diagram of a conventional system.

* Explanation of symbols for main parts of the drawings

1: central processing unit 2: ROM

3: RAM 4: Slave Memory

5 input and output processor 6 display unit

7: printer 8: drawer

9: part management planner 10: online board

11: inline board 31: master memory

The present invention relates to a sales management method in a point of sales system, and in particular, a method of managing a clerk management and some parts management in a slave temporarily when the system is down, and updating and restoring to a master when the system is restored. In providing.

Typically, POS systems consist of a master and multiple slave terminals, which are used for merchandise sales and clerk management.

In the prior art, the master and multiple slave terminals were interconnected as shown in FIG. 5 and had both a full clerk file and a single piece of file at the master. The clerk could trade at any terminal in every store, so in order to be able to perform the clerk management at the master terminal, the clerk holds the clerk file as a whole and the clerk enters the password at the slave terminal. At the time of sign-on, a clerk file is brought from the master to the slave terminal, and when the sign-off is performed, the clerk file is retransmitted back to the master. In the case of a single unit, the entire unit was managed by the master, so each slave could be immediately updated at the point of sale. That is, after opening the store and powering on the master and the plurality of slaves (# 1- # n), each of the clerks in the plurality of slaves (# 1- # n) sign on to receive the corresponding store clerk file from the master. The clerk file is used to update the transaction details of each clerk. When a single item is inputted using a scanner or the like, the slave will access the entire single file of the master terminal to update the sales. Then, at the time of closing the store, the clerk file in each slave (# 1- # n) was re-transmitted to the master for total management by the master. However, in the conventional POS system, which repeats the above process, when the communication line between the master and the slave goes down, when the clerk tries to replace the clerk at the slave terminal, the clerk cannot receive the clerk file from the master. Since the single item information was not managed in the master terminal, the single item management was not possible.

Accordingly, an object of the present invention is to provide a method of operating a force terminal that performs clerk management and some part management at an individual slave terminal when the force system is down and updates the master terminal at the time of recovery.

Hereinafter, the present invention will be described with reference to the accompanying drawings.

1 is a file holding state diagram of a master and each slave terminal of a force system according to the present invention, where a represents a master terminal, b represents a slave terminal, c represents a communication line of a force system, and d represents an authorized clerk. Is a clerk file with a personal clerk sales history, f is a single item file, and g is a file flow within the master terminal.

2 is a block diagram of a master or slave terminal to which the present invention is applied, and includes a central processing unit (1) for controlling a system, a ROM (2) for resisting program execution codes, and terminal management such as clerks and department management. A RAM 3 for storing files requiring management, an input / output processor 5 for transmitting and receiving data to and from the central processing unit 1, and a display unit 6 for displaying various data processing states in accordance with commodity transaction activities. ), A printing unit (7) for printing large customer receipts and business storage journals, a drawer (8) for storing cash, an inline communication board (11) for high speed communication of a master-slave terminal, and other The gateway (GW) and the scanner or scale (not shown) to connect to the POS system are both master-slaves and receive and renew some curse-accessible single files from the master. The unit management planner 9, which is a kind of scheduler that generates an interrupt to the central processing unit 1 through the input / output processor 5, and the unit updated every hour by the unit management planner 9 Auxiliary (slave) memory 4 for generating an arbitrary clerk file at the time of file and system down is provided only in the slave terminal, and the master (large or extended) memory 31 for point of sale management and integrated processing is a master terminal. Only equipped with.

3 and 4 are flowcharts of the present invention. FIG. 3 is an operation process of a slave terminal, and FIG. 4 is a recovery operation process of a master terminal.

The present invention will be described in detail based on the above configuration.

In step 3a, the CPU 1 checks whether a password has been input from the user. If it is determined that the test is signed on, the process proceeds to step 3b to receive and store the clerk file and the assignment file from the master.

After storing the clerk file and the assignment file (3c), it is checked whether or not the sign-off state is performed. At this time, if the system is down, check if the clerk is replaced in (3e). If the clerk has not been replaced as a result of the check, go to step (3f) to check the registration of the unit. When the inspection result is registered, the presence or absence of item information is checked in step (3g). At this time, if there is single item information, in step 3h, the single file of the slave memory 4 according to FIG. 2 is updated, and if the single item information is not registered in step 3f or there is no piece information in step 3g, In step), the associated file of the master memory 3 is updated. After performing steps (3h) and (3i), the clerk file that is signed on in step (3j) is updated, and then looped to step (3c).

On the other hand, if it is determined that the sign-off state is performed in step (3c), the process proceeds to step (31) to check whether the system is in the down state. If the system is not in the down state, the process proceeds to step (3k) to transfer the existing clerk file to the master. Then loop to step (3a).

On the other hand, when it is confirmed that the system is in the down state in step (31) or when the cashier is replaced in the step (3e), that is, when the system is down when the sign is off, or when the sign is on, the system is down and when the cashier is replaced, the step proceeds to (3m). The central processing unit (1) checks the clerk assignment file in the ROM (2) to check whether it is an authorized clerk, and checks the state of the flag set and proceeds to step (3m) only at the time of the authorized clerk to generate the clerk file. The existing clerk file is stored in the slave memory 4 and then looped to step (3c). In addition, if the system is not down when the system is not down while the clerk file and the assignment file are received and stored from the master in the sign-on state when the system is not in the down state (3d), the process proceeds to (3o) to check whether the unit management interrupt state. do. If the check result is an interrupted state, in step 3p, information about frequently accessed parts in the slave memory 40 is received from the master and then stored.

After storing the product information and if it is not in the item management interrupt state in step (3o), proceed to step (3q) to check whether the item is registered, and when registering, update the item file of the master in step (3r) and not register. After updating the related file of the master memory 30 in step (3s), the process proceeds to step (3j) to update the point-on file that is signed on as described above, and then loops to step (3c). Next, the system recovery operation will be described. In step 4a, a slave terminal number (hereinafter, referred to as S.S.T.N) to be accessed is set to 1. In step 4b, it is checked whether the S.S.T.N is less than or equal to the number of slave terminals (hereinafter referred to as M.T) connected to the system. If it is determined that S.S.T.N is larger than M.T, the operation is terminated. If it is found to be small, the process proceeds to step 4c to access the slave terminal designated as S.S.T.N. After performing step (4c), it is checked in step (4d) whether two or more clerk files. If the check result indicates that there are two or more clerk files, the process proceeds to step 4c to receive an unsigned clerk file and erase the slave file. It also adds the signed-on clerk files to the master and retransmits them to the slave terminal to update both the master and slave. In step (4d), if there are not two or more clerk files, or after performing step (4e), proceed to step (4f) to add the single file contents and master file contents in the slave terminal and increase the SSTN by one. Loop to step 4b.

As described above, the single-access files that are frequently accessed by terminal are kept in the slave terminal, so the sales history can be updated even when the system is down.For example, when the POS system is down, the clerk file is created by looking at the clerk assignment file initially set in the slave terminal. Therefore, it is possible to manage by clerks and to recover to the master terminal when recovering the system, so that some frequently used parts can be managed as single parts rather than as parts, thereby obtaining more detailed information.

Claims (2)

In a method of operating a POS system consisting of a master terminal having a master memory and a plurality of slave terminals having a slave memory and a component management planner, a clerk file and an assignment file are received from the master terminal upon sign-on at any slave terminal. A first process of storing, a second process of checking whether the system is in a sign-off state or a system down after performing the first process, a third process of checking whether a cashier is replaced when the system is down in a sign-on state, The fourth step is to update the slave file if there is part information according to the registration status, and to update the clerk file that is signed on after updating the relevant file of RAM if there is no part registration status or there is no part information at the time of registration. If the system is not down, another clerk file is sent to the master Process 5 looping to process 1, and if the system is down in the sign-off state or the system is not in the system off state and there is a request for the replacement of the clerk at system down, the authorized clerk creates a temporary clerk file and keeps the existing clerk file. The sixth process of looping, and if it is not in the merchant off state or not in the system down state, if the unit management interrupt state, the frequently accessed unit information of the slave memory is received and stored from the master and the unit management interrupt has not occurred or the unit reception is performed. After the unit registration request, the master updates the unit file. If there is no unit registration request, it updates the file associated with the RAM, updates the clerk file that is signed on, and then loops to the second process. Slave terminal operating method. A method of operating a POS system comprising a master terminal having a master memory and a plurality of slave terminals having a slave memory and a component management planner, the first step of setting a slave terminal number to be accessed and a slave connected to the system A second process of accessing a slave terminal corresponding to the slave terminal number when the number of terminals is smaller than a slave terminal number to be accessed; and a third process of checking whether two or more clerk files are accessed after accessing the corresponding slave terminal; Receiving a clerk file that is not signed on at least two times and erasing the slave file, and the single file contents and master file contents in the slave terminal after the clerk file is less than two or after the fourth process Slave you want to access after adding up And a fifth process of incrementing a terminal number and looping to the second process.

Images