How we started registering cash desks for our clients
According to the amendments to 54-FZ, since July of this year, almost all commercial enterprises are obliged to use online cash registers that transmit data via the Internet to the tax service. In order to acquire such a device, you will have to buy a cash register and a fiscal storage device, sign a contract and pay for the services of a fiscal data operator, register with two personal accounts of the FTS and CRF, enter details into the cash register, and receive a paper registration report. Well, you will also need an electronic digital signature, otherwise you will have to come to the FTS and personally stand in a queue.
We decided to save our customers from all this horror by making a service that automatically registers everything almost in one click. About this now and tell.
You already understood that registering a ticket office is a tedious multistage quest, but this is not the only problem. At each stage, a zoo of interfaces awaits, the forms of which will have to be filled in manually with registration data for each cash desk, as well as a full set of relevant bugs (separate hello tax requirements for using IE browsers, Yandex Browser or Satellite). Hundreds of opportunities to make mistakes, spoil the procedure and start over. And if you install 5-10 cash registers, the chance of error when entering the same details grows significantly. Not to mention the unproductive wasting of time and finding out why the personal tax office refuses to accept the token that “swallowed” perfectly just yesterday.
And when we felt the brunt of the above described tragedy, we decided to take on the development.
Several parties are involved in the registration of the cashier at once. This is the tax service (FTS), the OFD is the operator of fiscal data, through which the cash departments interact with the tax authority, a certificate authority, issuing electronic signatures and, as a rule, a little confused entrepreneur who is lost in the bureaucratic twists and turns. We wanted to intervene in their relationship, so much so that we could take on all the difficulties.
Conventionally, the procedure is divided into two stages:
Registration of the cash register - the data of the specific apparatus are sent to the FTS, and in response comes the registration number.
Fiscalization - activation of the cash desk using the registration number of the car assigned by the FTS.
First of all, we went to our partners to work with them on the first stage.
We are not the first to think about automating registration. Many said that they were doing something in this area, that the development was in progress, but no one had a ready-made external interface. One of the operators of fiscal data was provided by the API - almost ready to interact with the tax.
At that time, a total of about 80 test applications were sent using the protocol. We believed that the interface would soon work at full capacity, and began to implement and test on "stubs".
Going out on the prod, we realized that our tests and the real application are different, like day and night. The “stubs” that we received from the CRF included only the success mock, reproduced the successful scenario. In fact, to achieve the very “success” was not easy.
The hits were: applications on the side of the partners, unworked for several days, lack of feedback from the FTS and CRF, signature errors and our favorite “unknown error”. The FTS protocol turned out to be poorly documented and, often, responded with unspecified failures, for which it is not clear what caused them. There is still no clear specification. So the first time we tested the protocol, and, together with the CRF, we made decisions on how to respond to certain responses of the FTS in specific cases.
While part of the team was studying the behavior of the FTS systems in practice, the work did not stand still. In parallel, we arranged negotiations with the manufacturers of cash registers, suggested that they implement data exchange from us to their platform, from platform to cash register and in the reverse order for setting up automatic fiscalization of cash registers.
We selected a pair of universal monoblock solutions. Cashier Evotor with touch screens and Drimkas - for those of the customers that are accustomed to the good old buttons and consider additional functionality redundant. Different models: with and without a scanner.
If the OPD had its own API in readiness, then for the cash contractors it had to be developed from scratch. Otherwise it is impossible to make all registration data to the cashier automatically, without manual input.
The colleagues achieved success by setting up interaction through their platform, and soon they were ready: an API for opening a client’s personal account and a proprietary protocol for managing the cash register.
Our suppliers were the first to set up automatic filing of registration information at the box office. And soon the API will make it easy to deregister and re-register cash.
Now, when we are negotiating with other cash vendors, one of the key requirements is the support of this interface.
After we learned how to work with the FTS and implemented an API for transferring registration data to the cash register with vendors, it was time to link it all into a single system and establish a registration procedure.
This is the task of choosing the right architecture, which would allow controlling the asynchronous registration of the cash register both at the CRF, at the Federal Tax Service, and at the vendor. Since they respond to requests with a delay, the process is extended over time and has a large number of integrations with external systems. Because of this, we had to write two applications in Java.
The Job service communicates directly with the CRF and the box office system. For example, we send customer data to the CRF and expect to receive a registration number in response.
Job service polls the status of the application at regular intervals. He asks and asks again until the result is answered. The registration number is saved, Job transfers the application to the next stage and fiscalization begins.
If at first we were closely watching the passage of applications and manually studied every error that the system gave, now the process is automated.
We immediately determine the cause of the error. And in case of massive problems, monitoring systems have been set up, which fix anomalies indicating major failures at the FTS or CRF. The client learns about the problems in a single case: if, in response to a request, we receive a specific reject, a reasoned refusal to register.
The second application, CashReg, is a processing system where a status model is maintained, represented in a relational form.
It was developed on the basis of the API provided by vendors and the CRF, and included all possible transitions for each class participating in the registration process. The status model allows you to avoid internal errors and eliminate deviations from the standard algorithm for processing the application.
So, if an application is in one status for too long, for example, it does not receive a registration number for several hours, or the CRF will indicate an incorrect stage or status of the application in the response, CashReg reports an error.
Of course, to control the procedure needed admin panel. She works with the group of support for trade decisions, serving and accompanying cash registers during registration. Now only two employees are engaged in this, but their working interface is not complicated, and the process of preparing the cash desk, thanks to the refusal of manual data entry, is simple. So, we can quickly and easily scale the department.
All three components of the registration system do not imply high loads, because they are deployed in virtual environments.
All this required that the client, leaving a request in his personal account, in a few days put the activated cash desk at the counter ready for work.
From the point of view of internal cuisine, the magic of auto-registration looks a bit more complicated. By leaving an application in your account, the client gives us legal consent to issue an electronic signature and complete the entire procedure on his behalf.
Information about the company, registration data for a specific store and signer (for example, the general director) is extracted from the banking databases. They are updated in SPARK, pass scoring and enter the master system at the cash registers.
Then a request is formed in CASHREG. It is displayed as a new task in the admin panel of an employee from the trade decision support group. He sees what kind of cash and fiscal storage the customer needs. An employee finds the required device in stock, selects a fiscal drive, bar-codes their serial numbers and confirms the application. So specific devices are attached to it that will be delivered to the client. At this moment, a request is sent to the CRF: “create an application for registering such and such a cash register for such a company”.
The file sent by the CRF in response is certified by an electronic signature and, using the CRF API, sent to the tax authorities. There the checkout is assigned a registration number.
Now the full package of documents at the box office goes to the manufacturer of the cash register (yes, they are also involved here). In parallel, the task appears in the admin panel - fiscalize the very cashier. This means that the employee simply includes the cashier. The vendor's system “sees” that the device has contacted, and loads into its memory all the necessary registration data automatically. Errors during manual entry are excluded, the same details fall into the FTS, and the cashier.
The cashier prints a registration report - something for which everything was started. The fiscal data from the report: date of printing, signature, fiscal sign, serve as confirmation that the box office is ready to work. These details are sent to the CRF again.
Immediately after the CRF generates a registration report, we sign it for the client, and the ready box office leaves with a courier.
The CRF has yet to prepare a registration card, but it can be not waited. It will be available in electronic form in the client’s personal account in two or three days.
To implement this project, about twenty employees from the entire bank and many more specialists from our partners, CRF and cash vendors distracted themselves from the usual tasks, but their efforts were not in vain.
The average time to get a registration number, with the exception of the most negative cases, is three hours. In general, the whole procedure takes 5-6 hours. 90% of registrations succeed. About 1000 applications have already been processed.
In general, as you understand, we in our company love similar cases that can seriously simplify the life of a huge number of people. Solving such problems you feel that you are doing something really useful.
PS If you are interested, you can read how we filed our ATM. And along with the data exchange protocols.
We decided to save our customers from all this horror by making a service that automatically registers everything almost in one click. About this now and tell.
Why do we need it
You already understood that registering a ticket office is a tedious multistage quest, but this is not the only problem. At each stage, a zoo of interfaces awaits, the forms of which will have to be filled in manually with registration data for each cash desk, as well as a full set of relevant bugs (separate hello tax requirements for using IE browsers, Yandex Browser or Satellite). Hundreds of opportunities to make mistakes, spoil the procedure and start over. And if you install 5-10 cash registers, the chance of error when entering the same details grows significantly. Not to mention the unproductive wasting of time and finding out why the personal tax office refuses to accept the token that “swallowed” perfectly just yesterday.
And when we felt the brunt of the above described tragedy, we decided to take on the development.
Stages of registration
Several parties are involved in the registration of the cashier at once. This is the tax service (FTS), the OFD is the operator of fiscal data, through which the cash departments interact with the tax authority, a certificate authority, issuing electronic signatures and, as a rule, a little confused entrepreneur who is lost in the bureaucratic twists and turns. We wanted to intervene in their relationship, so much so that we could take on all the difficulties.
Conventionally, the procedure is divided into two stages:
Registration of the cash register - the data of the specific apparatus are sent to the FTS, and in response comes the registration number.
Fiscalization - activation of the cash desk using the registration number of the car assigned by the FTS.
First of all, we went to our partners to work with them on the first stage.
API for FTS
We are not the first to think about automating registration. Many said that they were doing something in this area, that the development was in progress, but no one had a ready-made external interface. One of the operators of fiscal data was provided by the API - almost ready to interact with the tax.
At that time, a total of about 80 test applications were sent using the protocol. We believed that the interface would soon work at full capacity, and began to implement and test on "stubs".
Going out on the prod, we realized that our tests and the real application are different, like day and night. The “stubs” that we received from the CRF included only the success mock, reproduced the successful scenario. In fact, to achieve the very “success” was not easy.
The hits were: applications on the side of the partners, unworked for several days, lack of feedback from the FTS and CRF, signature errors and our favorite “unknown error”. The FTS protocol turned out to be poorly documented and, often, responded with unspecified failures, for which it is not clear what caused them. There is still no clear specification. So the first time we tested the protocol, and, together with the CRF, we made decisions on how to respond to certain responses of the FTS in specific cases.
Cash API
While part of the team was studying the behavior of the FTS systems in practice, the work did not stand still. In parallel, we arranged negotiations with the manufacturers of cash registers, suggested that they implement data exchange from us to their platform, from platform to cash register and in the reverse order for setting up automatic fiscalization of cash registers.
We selected a pair of universal monoblock solutions. Cashier Evotor with touch screens and Drimkas - for those of the customers that are accustomed to the good old buttons and consider additional functionality redundant. Different models: with and without a scanner.
If the OPD had its own API in readiness, then for the cash contractors it had to be developed from scratch. Otherwise it is impossible to make all registration data to the cashier automatically, without manual input.
The colleagues achieved success by setting up interaction through their platform, and soon they were ready: an API for opening a client’s personal account and a proprietary protocol for managing the cash register.
Our suppliers were the first to set up automatic filing of registration information at the box office. And soon the API will make it easy to deregister and re-register cash.
Now, when we are negotiating with other cash vendors, one of the key requirements is the support of this interface.
Anatomy of autoregistration
After we learned how to work with the FTS and implemented an API for transferring registration data to the cash register with vendors, it was time to link it all into a single system and establish a registration procedure.
This is the task of choosing the right architecture, which would allow controlling the asynchronous registration of the cash register both at the CRF, at the Federal Tax Service, and at the vendor. Since they respond to requests with a delay, the process is extended over time and has a large number of integrations with external systems. Because of this, we had to write two applications in Java.
The Job service communicates directly with the CRF and the box office system. For example, we send customer data to the CRF and expect to receive a registration number in response.
Job service polls the status of the application at regular intervals. He asks and asks again until the result is answered. The registration number is saved, Job transfers the application to the next stage and fiscalization begins.
If at first we were closely watching the passage of applications and manually studied every error that the system gave, now the process is automated.
We immediately determine the cause of the error. And in case of massive problems, monitoring systems have been set up, which fix anomalies indicating major failures at the FTS or CRF. The client learns about the problems in a single case: if, in response to a request, we receive a specific reject, a reasoned refusal to register.
The second application, CashReg, is a processing system where a status model is maintained, represented in a relational form.
It was developed on the basis of the API provided by vendors and the CRF, and included all possible transitions for each class participating in the registration process. The status model allows you to avoid internal errors and eliminate deviations from the standard algorithm for processing the application.
So, if an application is in one status for too long, for example, it does not receive a registration number for several hours, or the CRF will indicate an incorrect stage or status of the application in the response, CashReg reports an error.
Of course, to control the procedure needed admin panel. She works with the group of support for trade decisions, serving and accompanying cash registers during registration. Now only two employees are engaged in this, but their working interface is not complicated, and the process of preparing the cash desk, thanks to the refusal of manual data entry, is simple. So, we can quickly and easily scale the department.
All three components of the registration system do not imply high loads, because they are deployed in virtual environments.
How is the application processing
All this required that the client, leaving a request in his personal account, in a few days put the activated cash desk at the counter ready for work.
From the point of view of internal cuisine, the magic of auto-registration looks a bit more complicated. By leaving an application in your account, the client gives us legal consent to issue an electronic signature and complete the entire procedure on his behalf.
Information about the company, registration data for a specific store and signer (for example, the general director) is extracted from the banking databases. They are updated in SPARK, pass scoring and enter the master system at the cash registers.
Then a request is formed in CASHREG. It is displayed as a new task in the admin panel of an employee from the trade decision support group. He sees what kind of cash and fiscal storage the customer needs. An employee finds the required device in stock, selects a fiscal drive, bar-codes their serial numbers and confirms the application. So specific devices are attached to it that will be delivered to the client. At this moment, a request is sent to the CRF: “create an application for registering such and such a cash register for such a company”.
The file sent by the CRF in response is certified by an electronic signature and, using the CRF API, sent to the tax authorities. There the checkout is assigned a registration number.
Now the full package of documents at the box office goes to the manufacturer of the cash register (yes, they are also involved here). In parallel, the task appears in the admin panel - fiscalize the very cashier. This means that the employee simply includes the cashier. The vendor's system “sees” that the device has contacted, and loads into its memory all the necessary registration data automatically. Errors during manual entry are excluded, the same details fall into the FTS, and the cashier.
The cashier prints a registration report - something for which everything was started. The fiscal data from the report: date of printing, signature, fiscal sign, serve as confirmation that the box office is ready to work. These details are sent to the CRF again.
Immediately after the CRF generates a registration report, we sign it for the client, and the ready box office leaves with a courier.
The CRF has yet to prepare a registration card, but it can be not waited. It will be available in electronic form in the client’s personal account in two or three days.
Conclusion
To implement this project, about twenty employees from the entire bank and many more specialists from our partners, CRF and cash vendors distracted themselves from the usual tasks, but their efforts were not in vain.
The average time to get a registration number, with the exception of the most negative cases, is three hours. In general, the whole procedure takes 5-6 hours. 90% of registrations succeed. About 1000 applications have already been processed.
In general, as you understand, we in our company love similar cases that can seriously simplify the life of a huge number of people. Solving such problems you feel that you are doing something really useful.
PS If you are interested, you can read how we filed our ATM. And along with the data exchange protocols.