We continue to improve the inventory management in JoinPAY. In our latest release, we have added the ability to assign cashiers to specific outlets. It's handy you need to segment your salespeople by assigning them to specific outlets. For example:
1.There is a network of coffee shops in three different cities. Employees within the same city can move linearly across coffee shops. Today he works in one, tomorrow in the other. Accordingly, it makes no sense to reflect the list of all employees of the company at the opening of the shift.
2.Since we have an omni-channel platform, merchants have completely different businesses within the same platform. It makes sense to segment here, too.
In the form of adding/editing an employee, you can specify the affiliation to the outlets, or put a checkbox to ensure that the information was loaded to all outlets.
A new update to the service has added the functionality of custom sorting in product categories. What does it mean? By selecting any category in the merchandiser, you can drag and drop items to the most convenient position for your employees. This feature allows for the most popular items to be easily placed at the top for quick access, while less frequently sold items can be moved down the list for better organization.
We will also add a download button for all products in the category at once to make it easier to work with the custom sorting. You do not have to switch through internal category pages to change the order in which products are displayed. Important note! Sorting will not work if you select the «All Categories» category.
Also in this update we have changed the parameters of displaying products in categories. When displaying category products (e.g. drinks), products of subcategories (coffee, tea, lemonade) will not be displayed.
We are continually striving to improve our JoinPAY product pipeline. When we started this project, the development team was quite small and it wasn't very difficult to keep track of the code.
During the initial stages of this project, our development team was relatively small, and thus it was easier to keep track of the code. One useful addition we made was implementing code linting as a step in the Gitlab CI Pipeline. Our development leads can finally exhale and no longer be distracted by the minutiae in the review, but focus on the code itself.
Once the Docker images have been prepared, we initiate the code linting process by running pylint with black. Only after successful linting does the pipelining continue. And, for more convenience, information about the status of the Pipeline is displayed in our Telegram bot.
Our platform employs multiple analytical tools to display a range of financial indicators for our clients. One such tool is the company dashboard, which showcases a variety of parameters such as revenue, average check, and distribution of payment methods, among others. However, a static dashboard can be incredibly dull and ineffective.
So we have introduced dynamic features that allow for the display of various dashboard elements at different times. Now our clients can view statistics for various timeframes such as the day, week, month, previous years, as well as any arbitrary interval of time they choose. By providing such a comprehensive view of their performance, our clients can make more informed decisions and adjust their strategies accordingly, leading to more effective business operations.
Given that JoinPAY processes tens of thousands of financial transactions every day, and serves socially significant industries (for example, public transport), we have no right to be down. Of course, we have offline modes of terminal equipment operation everywhere with subsequent cumulative upload to the host, but the fewer such switches there are, the better.
Therefore, the task was to get a cluster that survives the loss of any server, or even several servers, and can put servers into operation after accidents automatically. There were different approaches and synthetic tests, but we stopped at the PostgreSQL+Patroni+Haproxy+etcd bundle.
When simulating the master node getting down, switching takes 4-6 seconds in our case and occurs automatically. The node status is checked at an interval of 1 second, 3 unsuccessful responses are required to bring the server down (code 500), 2 successful responses are required to switch the server back up (code 200).
Just recently, we came across such a cool thing as Conventional Commits.
I do not know where it has been all this time! Now we use it in our projects! Of course, we had a decent conventional commit before, but now we have a little more order in the projects.
If anyone needs to know why, here is the information: https://www.conventionalcommits.org/en/v1.0.0/#why-use-conventional-commits
Nevertheless, the biggest advantage for us is that there is no need now to fill in the changelog manually, because our developers dislike doing this from the bottom of their hearts. And when expanding the team, it is much easier when there is some convention to adhere to.
Dashboards surprise nobody. They are available in almost any service. We also had them, but they were with a unified data set for all types of businesses. And we serve very different businesses.
Now the dashboard has become fully customized for the type of business, and the merchant himself can connect the necessary data set and create his own dashboard preset.
In the further development of dashboards, it will be possible to customize the widgets themselves, selecting data for any period, as well as viewing more detailed data sets.
We recently updated our backend, which resulted in major advantages. Of course, migration problems were unavoidable, but they were not too complicated and we solved them with a couple of commits.
The main advantage that we got is support for asynchronous programming.
Although some parts of the code are still synchronous, soon we will also rewrite them in accordance with the new approach.
In general, even without a full migration, the framework has already shown a significant increase in the speed of work!
We have accelerated dramatically in the development of the entire JoinPAY platform and its individual parts. Today, our ESLIP receipt repository has started saving fiscal receipts. It does not matter whether it is cloud fiscalization or directly at the checkout. The Salyut-12F cash register in the SDK has the ability to transfer all the necessary fiscal features.
The signs are transmitted to the platform and settle in the desired receipt, and then we pull the API of the Federal Tax Service and form a full-fledged cash receipt. Thus, in eslip, for each transaction, information with bank slip details and a fiscal receipt is provided.
We continue to improve the JoinPAY products. This week, it is the Salyut-12f cash register's turn.
As you probably already know, our cash register software is universal, and has several configurations for different types of businesses. As the functionality of the cash register grew, the user menu also grew. Now we have come to the moment when not all the items simply fit on the screen. In addition, the visual style of the menu had a lot of room for improvement.
Now everything has changed for the better. We have separated all the navigation on a separate screen, and divided it into logical sections so that our customers can quickly find the necessary functions or sections. A three-word summary: it became convenient.
Not forgetting about the UX, we rolled out a cool softpos update. In the new version, we have updated the user menus so that merchants can find the necessary functions even faster. In addition, a shopping cart has appeared in the catalog, which shows the total amount and the number of selected products.
Now it is easy to make a full-fledged cash register (in accordance with Federal Law 54-FZ), you need to click "select BT-printer" in the menu and select an available fiscal printer in the menu that appears.
The task is to make softpos easy in terms of onboarding for customers both when connecting acquiring and Faster Payments System, as well as the fiscal part. The reference point is not more expensive than 10 thousand rubles for the launch (you do not need to buy smart cash registers, pay for commodity accounting functions and loyalty). Everything is out of the box.
Now our softpos supports fiscalization via Bluetooth of all devices of the ISKRA factory.
Moreover, another trick is that in a restaurant (as an example), you can put one such printer and "set" all the softpos on it. That is, each waiter immediately fiscalizes transactions at the table.
In the nearest future, the ISKRA factory will release a PRIM-05 fiscal printer. Thus, it will be the cheapest and at the same time one of the most technologically advanced solutions in the market that ensures compliance with Federal Law No. 54-FZ.
High reliability and speed of operation, as well as low price and cost of ownership, are the major advantages of PRIM-05. At the same time, you can buy a battery pack for it at any time and it will become autonomous.