How we taught self-help cash desks
Our company has been engaged in self-service cash registers for about two years, and we have followed this path iteratively. In one of my previous posts, I told you what difficulties arose during our first launches of two stores in Kaliningrad. At the same time, both there and in several subsequent stores, we established cash desks that accept payment only by credit card. This solution had advantages both for us (such a solution was faster to launch) and for stores (they were able to divide the flow of customers according to the type of payment). But we understood that sooner or later we would have to take up the connection of the cash module to the self-service checkout. Everyone who is interested to know how it was, welcome under the cat.
The main complex for accepting cash for cash desks of the Swedish company ITAB, under which we are developing, is the complex of the Japanese company Glory with the pathetic name Cash Infinity 10.
It consists of two separate devices - banknotes and coin acceptors connected to the controller.
')
The coin acceptor is a device with points of input and output of coins, a conveyor, a validator and 8 identical coin boxes. After the coin is accepted, it is delivered to the validator by the conveyor, which determines its denomination and sends it to the corresponding coin box. If the denomination is not determined, the coin is returned through the point of withdrawal of coins. Similarly, any garbage is returned - paper clips, keys. The coins themselves can be safely deposited in a handful - the coin acceptor quite calmly processes a large number of coins of different denominations. Coins operate on both input and output, respectively, the delivery is issued to the buyer by the same coins that previous buyers made to the cashier.
Bill acceptor is arranged differently. A bill is a thin piece of paper, and if it is folded somewhere, then it will not be possible to pick it up, which means it is more difficult to implement the input / output system for bills. More difficult, but possible. To do this, special drums are placed in the bill acceptor: the recognized bill is wound on such a drum and can be removed in the same way for delivery. The only problem is that the space in the device is limited, so there are only 3 reels in it, on which it is logical to install the most popular notes. All other bills (as well as running bills in case of overflow of the corresponding drum) get into the cassette, which the employee at any time can withdraw in closed form and deposit all its contents into the main cash register.
We had to connect to the controller : it combines the work of two independent devices, through its API it receives commands from external systems (in our case from the self-service cash desk) and returns the statuses of the requested operations, as well as its current state. It sounds quite understandable, and at some point I personally even thought that connecting one unit, which was responsible for all the work with cash, should not be much more difficult than connecting a bank terminal. Of course, it was just an illusion, and at the very beginning of our work we faced a number of big tasks:
The tip of the iceberg (and as it turned out later, one of the most understandable tasks) was to create a customer interface for receiving cash. Choosing cash as a payment method transfers devices from sleep mode (IDLE) to cash reception mode (WAIT INTSERTATION), information on all entered face values ​​is transmitted to our cash program.
We faced a difficulty - at the moment when the amount paid was greater than the amount of the check, we could not send a change issue command for the required amount: there is simply no such command in the API. This is done because the processing of the deposited banknote and its transfer to the external system is a long process, which means that at the moment when the external system has learned about the sufficiency of the amount, part of the bills or coins can still be processed. Accordingly, we send the CASH REQUEST command to the controller, which tells the controller that when all the bills have been entered and processed, it will be possible to proceed to issue the change. And the controller itself returns us the WAIT FOR CHANGE event, after which we show the delivery screen.
With coins, everything seems simple: 8 containers, and just 8 coins of value in the course. True, Glory does not accept the penny, as it does not accept large 10-ruble coins. The remaining capacity can either be given under one of the running values, or give it under the excess coins. We chose the second option. The surplus or mixer collects coins of different denominations in case of overflow of their containers. For notes, everything is a little simpler: it was necessary to choose which 3 values ​​to place on the reels. After consulting with a client, we chose banknotes of 50, 100, and 500 rubles. Accordingly, the cash register does not give a change in the thousandth bills.
One of the key questions of customization: at what values ​​to block payment in cash at the self-service checkout? I don’t want to allow a situation where we once again send the CASH REQUEST command to the controller, but it will not be able to issue a change due to the lack of the necessary nominal values. I didn’t want to block the payment much in advance, but I didn’t even want to approach very close to the problem situation. As a result, due to fears and a simpler implementation, we chose a more advanced solution: cash payment is blocked if at least one nominal is no longer able to give a change when you make the next one by value. That is, if the 500-ruble bills on the drum remain less than 9 (that is exactly how many bills will be required to issue change on a small purchase when making a five-thousandth note) or 100-ruble bills will be less than 4, then cash payment will automatically be blocked and the buyer will be notified about it on the start screen and on the screen for choosing payment methods.
In addition, cash payment is automatically blocked when approaching overflow of a cassette with cash or excess coins.
The task of the display system is to notify the store employee of the upcoming problem situation. We have two notification mechanisms: a flashlight above the cashier and the status of cash at the cashier in the interface of the store employee. The logic is this: as soon as the assistant sees that the lamp starts flashing green between purchases at the checkout, you need to check the status of cash. He can look at more detailed information in a mode of work with cash.
In the status indication system, those that do not require attention are displayed in gray, close to the problem state - pink, and critical ones (as a result of which cash payments will be blocked) - red. It seems that the traffic light with green, yellow and red states was asking for it, but in this motley combination it is more difficult to isolate something most significant.
Color depends on the type of container. For example, the overflow of the coin box is bad, because now all the coins will pour in the excess, and its capacity is quite small. Therefore, the 10-ruble coin box is highlighted in pink. Overflow drum opposite - a very good situation, because there is something to give change. Yes, the extra bills will be sent to the cassette, but the capacity of the cassette is sufficient to hold them.
There were a lot of private questions when setting the border: for example, at what volume of a cassette should it be highlighted in pink? After several brainstorming sessions, we set this value to 75 percent. Accordingly, at the same time, the flashlight above the cash register begins to flash. Similar decisions were required to take on all the containers for bills and coins.
The introduction and withdrawal of the listed features of the equipment turned out to be not at all simple tasks. Even in spite of the fact that in all cash decisions of our company, deposit and withdrawal are present, here many of the principles had to be almost completely rethought.
With the introduction of everything as a whole is quite clear: after entering the mode of depositing, the bill and coin acceptors are ready to accept cash. The denominations of all bills and coins made are displayed next to the respective containers. And after everything is entered, the employee must click "Complete the deposit" by conducting this transaction through the fiscal registrar, which will print the deposit document.
There are few features, but they exist: depositing thousands and five thousand bills does not make any sense - these bills will fall into a cassette that cannot be issued to the buyer. So for this situation requires a separate display.
It is clear that most likely the employee will not make such denominations, but there may be another situation: one of the drums overflowed and all the bills from it begin to fall into the cassette. And in this case, it is just very useful - the employee immediately sees that there is no longer any sense to contribute this denomination. The situation is similar with the surplus of coins.
With the withdrawal had to tinker. Withdrawals can be of 4 types (which, in principle, can not be on a regular box office):
For each of them was required to implement different behaviors.
Money from coin boxes are not returned immediately, but after pressing the button “Complete withdrawal”. At the same time, an exemption document is printed.
The choice in the case of withdrawal of the cassette was only at what point to print the document of withdrawal. Initially, we decided to print it at the time of installation of the empty cassette back, but after analyzing the store's processes, we began to print the document immediately after removing the cassette. The reason is that the document remains in the main box office after making money in it. The main cash desk is far from the self-cash cash desks, and the staff had to run 2 times: first with money, then with a document. We simply optimized their work.
There were so many erroneous and borderline situations that it was a bit wrong to single out all this titanic work into just one point. I will cite just a few questions that I had to answer both to developers and testers, and to me as an interface designer.
Well, now it's time to talk about the main thing: the best characteristic of the work done is not its description, but the fact that the result is used and performs its function.
Exactly one month ago we launched an island of self-service from 4 cash desks with a cash acceptance module in one of the shops of the Gallery shopping complex in St. Petersburg.
Without undue modesty, I would say that the launch was a great success. Buyers perceived the novelty with interest. Already in the first week of the self-checkout, a decent percentage of buyers took over. But we are not stopping - there are many ideas in the plans for improving and optimizing the work of cash registers.
It is better to see once, and even better - to try. Come to Petersburg and evaluate our decision.
I wish all the developers to be diligent and attentive to important trifles. Remember that first of all, both iron and the interface should help users.
The main complex for accepting cash for cash desks of the Swedish company ITAB, under which we are developing, is the complex of the Japanese company Glory with the pathetic name Cash Infinity 10.
It consists of two separate devices - banknotes and coin acceptors connected to the controller.
')
The coin acceptor is a device with points of input and output of coins, a conveyor, a validator and 8 identical coin boxes. After the coin is accepted, it is delivered to the validator by the conveyor, which determines its denomination and sends it to the corresponding coin box. If the denomination is not determined, the coin is returned through the point of withdrawal of coins. Similarly, any garbage is returned - paper clips, keys. The coins themselves can be safely deposited in a handful - the coin acceptor quite calmly processes a large number of coins of different denominations. Coins operate on both input and output, respectively, the delivery is issued to the buyer by the same coins that previous buyers made to the cashier.
Bill acceptor is arranged differently. A bill is a thin piece of paper, and if it is folded somewhere, then it will not be possible to pick it up, which means it is more difficult to implement the input / output system for bills. More difficult, but possible. To do this, special drums are placed in the bill acceptor: the recognized bill is wound on such a drum and can be removed in the same way for delivery. The only problem is that the space in the device is limited, so there are only 3 reels in it, on which it is logical to install the most popular notes. All other bills (as well as running bills in case of overflow of the corresponding drum) get into the cassette, which the employee at any time can withdraw in closed form and deposit all its contents into the main cash register.
We had to connect to the controller : it combines the work of two independent devices, through its API it receives commands from external systems (in our case from the self-service cash desk) and returns the statuses of the requested operations, as well as its current state. It sounds quite understandable, and at some point I personally even thought that connecting one unit, which was responsible for all the work with cash, should not be much more difficult than connecting a bank terminal. Of course, it was just an illusion, and at the very beginning of our work we faced a number of big tasks:
1. Buyer interface for payment
The tip of the iceberg (and as it turned out later, one of the most understandable tasks) was to create a customer interface for receiving cash. Choosing cash as a payment method transfers devices from sleep mode (IDLE) to cash reception mode (WAIT INTSERTATION), information on all entered face values ​​is transmitted to our cash program.
We faced a difficulty - at the moment when the amount paid was greater than the amount of the check, we could not send a change issue command for the required amount: there is simply no such command in the API. This is done because the processing of the deposited banknote and its transfer to the external system is a long process, which means that at the moment when the external system has learned about the sufficiency of the amount, part of the bills or coins can still be processed. Accordingly, we send the CASH REQUEST command to the controller, which tells the controller that when all the bills have been entered and processed, it will be possible to proceed to issue the change. And the controller itself returns us the WAIT FOR CHANGE event, after which we show the delivery screen.
2. Setting capacities for all denominations
With coins, everything seems simple: 8 containers, and just 8 coins of value in the course. True, Glory does not accept the penny, as it does not accept large 10-ruble coins. The remaining capacity can either be given under one of the running values, or give it under the excess coins. We chose the second option. The surplus or mixer collects coins of different denominations in case of overflow of their containers. For notes, everything is a little simpler: it was necessary to choose which 3 values ​​to place on the reels. After consulting with a client, we chose banknotes of 50, 100, and 500 rubles. Accordingly, the cash register does not give a change in the thousandth bills.
One of the key questions of customization: at what values ​​to block payment in cash at the self-service checkout? I don’t want to allow a situation where we once again send the CASH REQUEST command to the controller, but it will not be able to issue a change due to the lack of the necessary nominal values. I didn’t want to block the payment much in advance, but I didn’t even want to approach very close to the problem situation. As a result, due to fears and a simpler implementation, we chose a more advanced solution: cash payment is blocked if at least one nominal is no longer able to give a change when you make the next one by value. That is, if the 500-ruble bills on the drum remain less than 9 (that is exactly how many bills will be required to issue change on a small purchase when making a five-thousandth note) or 100-ruble bills will be less than 4, then cash payment will automatically be blocked and the buyer will be notified about it on the start screen and on the screen for choosing payment methods.
In addition, cash payment is automatically blocked when approaching overflow of a cassette with cash or excess coins.
3. Indication of a shortage or excess of bills and coins
The task of the display system is to notify the store employee of the upcoming problem situation. We have two notification mechanisms: a flashlight above the cashier and the status of cash at the cashier in the interface of the store employee. The logic is this: as soon as the assistant sees that the lamp starts flashing green between purchases at the checkout, you need to check the status of cash. He can look at more detailed information in a mode of work with cash.
In the status indication system, those that do not require attention are displayed in gray, close to the problem state - pink, and critical ones (as a result of which cash payments will be blocked) - red. It seems that the traffic light with green, yellow and red states was asking for it, but in this motley combination it is more difficult to isolate something most significant.
Color depends on the type of container. For example, the overflow of the coin box is bad, because now all the coins will pour in the excess, and its capacity is quite small. Therefore, the 10-ruble coin box is highlighted in pink. Overflow drum opposite - a very good situation, because there is something to give change. Yes, the extra bills will be sent to the cassette, but the capacity of the cassette is sufficient to hold them.
There were a lot of private questions when setting the border: for example, at what volume of a cassette should it be highlighted in pink? After several brainstorming sessions, we set this value to 75 percent. Accordingly, at the same time, the flashlight above the cash register begins to flash. Similar decisions were required to take on all the containers for bills and coins.
4. A huge block of work with cash discipline
The introduction and withdrawal of the listed features of the equipment turned out to be not at all simple tasks. Even in spite of the fact that in all cash decisions of our company, deposit and withdrawal are present, here many of the principles had to be almost completely rethought.
With the introduction of everything as a whole is quite clear: after entering the mode of depositing, the bill and coin acceptors are ready to accept cash. The denominations of all bills and coins made are displayed next to the respective containers. And after everything is entered, the employee must click "Complete the deposit" by conducting this transaction through the fiscal registrar, which will print the deposit document.
There are few features, but they exist: depositing thousands and five thousand bills does not make any sense - these bills will fall into a cassette that cannot be issued to the buyer. So for this situation requires a separate display.
It is clear that most likely the employee will not make such denominations, but there may be another situation: one of the drums overflowed and all the bills from it begin to fall into the cassette. And in this case, it is just very useful - the employee immediately sees that there is no longer any sense to contribute this denomination. The situation is similar with the surplus of coins.
With the withdrawal had to tinker. Withdrawals can be of 4 types (which, in principle, can not be on a regular box office):
- withdrawal of coins of a certain value
- seizure of excess coins
- taking notes from the drums
- withdrawal of a cassette with notes
For each of them was required to implement different behaviors.
- When withdrawing coins from one of the coin boxes, the withdrawal amount is a multiple of the nominal value.
- The surplus of coins is withdrawn only as a whole, it is simply not possible to withdraw part of the coins of a certain amount, because all the coins in it are mixed
Money from coin boxes are not returned immediately, but after pressing the button “Complete withdrawal”. At the same time, an exemption document is printed.
- For banknotes, as well as for coins, the withdrawal amount that is a multiple of the nominal value on the drum is selected, but after consultations we decided not to issue this amount through a bill acceptor, but to send it to the cassette. Accordingly, the withdrawal document in this case is not printed, because the money remained on hand.
- When removing the cassette, almost the entire sequence of actions is given by the manufacturer. We send a command to withdraw the cassette, the door that locks it is unlocked in the bill acceptor. The employee opens the door, takes out the tape. He is obliged to insert back an empty cassette, otherwise the controller will return to the initial IDLE state, but it will not return the cassette inventory event. Accordingly, our cash register module will not be able to print a withdrawal document, will not be able to find out the status of the cassette, so in this case we decided to block the payment in cash and ask you to insert an empty cassette. This is reasonable, because he absolutely will not be able to find out what amount remained in the cassette after withdrawal.
The choice in the case of withdrawal of the cassette was only at what point to print the document of withdrawal. Initially, we decided to print it at the time of installation of the empty cassette back, but after analyzing the store's processes, we began to print the document immediately after removing the cassette. The reason is that the document remains in the main box office after making money in it. The main cash desk is far from the self-cash cash desks, and the staff had to run 2 times: first with money, then with a document. We simply optimized their work.
5. Handling erroneous situations
There were so many erroneous and borderline situations that it was a bit wrong to single out all this titanic work into just one point. I will cite just a few questions that I had to answer both to developers and testers, and to me as an interface designer.
- How will the coin jams / jams be handled? How will the cash register behave in customer mode and assistant mode?
- What will happen if, after the assistant has clicked “Complete the deposit”, he will throw some more coins into the receiver?
- Lack of kopecks leaves its mark: what to do in a situation if the total amount turned out to be pennies (for example, if the discount on rounding a check did not work)?
- The controller itself can be far from only in the states IDLE, WAIT INSERTATION and WAIT FOR CHANGE. The states change from each action: there is a COUNTING that turns on at the time of counting the money made, there is a CALCULATING CHANGE AMOUNT - it turns on for a fraction of a second at the time of counting the change, there is a DISPENSING that turns on at any time of issuing money. It goes without saying that the ERROR state contains the details of the error that occurred. And there are exactly 30 such states in total, and in each of them their functions become accessible or inaccessible. All this must not only be programmed, but also tested.
Well, now it's time to talk about the main thing: the best characteristic of the work done is not its description, but the fact that the result is used and performs its function.
Exactly one month ago we launched an island of self-service from 4 cash desks with a cash acceptance module in one of the shops of the Gallery shopping complex in St. Petersburg.
Without undue modesty, I would say that the launch was a great success. Buyers perceived the novelty with interest. Already in the first week of the self-checkout, a decent percentage of buyers took over. But we are not stopping - there are many ideas in the plans for improving and optimizing the work of cash registers.
It is better to see once, and even better - to try. Come to Petersburg and evaluate our decision.
I wish all the developers to be diligent and attentive to important trifles. Remember that first of all, both iron and the interface should help users.
Source: https://habr.com/ru/post/258889/
All Articles