How to and how not to automate trade

My heart bleeds when I read an article and even more so - comments to it. One mention of 1C environment moguls as a solution for automating the pharmacy network is worth something. Dear habratovarischi, 1C Trade Management In Principle is not suitable for trading in the pharmaceutical business! And noteworthy attempts of his beloved daughter 1C in the field of adaptation. Retails still do not completely solve the main problems of this system. And under this condition, this decision does not have the right to cost such money for which it is sold.
My opinion is just an opinion accumulated in the course of many years of work among pharmaceutical trading enterprises, both retail and wholesale. But since I mentioned that article, it will become clear to my acquaintance that it’s still a matter of the retail part.
So, I will try to explain why my heart is bleeding. In a sense, this post is conceived as a set of recommendations to the author of the article, until completely unjustified money is wasted.
Who cares - welcome under cat. I warn you: not a single picture and a lot of letters.

Equipment and other stuff

Immediately make a reservation: in no case shall I set a goal to correct already done or advise. To begin with at least the fact that in Moscow there have never been any problems with the choice of equipment for reasons of protection by some manufacturers of fiscal technology with local tax authorities. Therefore, at all pharmacies there is a rather standard set of equipment for small Moscow retailers:
')

• Sistemnik on workplaces - standard Win PC under control of XP Prof
• The specifics of working with medications, as already noted, implies extensive lists and many additional parameters, so most often standard trading monitors for 13-inch are not enough, almost everywhere is 17-inch. The exception is the acceptance of goods, where it is enough to press two and a half buttons and see a list of invoices
• Label printer (one per point) - Godex BZB2. Below I will explain why labels in general
• Standard document printer, there are variations of the sea, the main thing is to be compatible with the OS and properly print documentation
• Barcode scanner (CC) using the simplest Zebex or Cipher - there is no point in taking the rolled-up ones. And even more so every time I insist that the scanners are with a USB interface - in order to avoid unnecessary hemorrhoids with COM ports. It can not be avoided, because the fiscal technique and the display of the buyer, but at least on the scanner - it is possible.
• Customer display is worth Firich-2029. Simple, and it is enough.
• Network everywhere is wired on standard D-Link switches, I see no reason to dwell on this.

Money counters, money checking equipment, air conditioners and heaters are, as you understand, outside the sphere of activity of a competently organized IT department, so it makes no sense to describe them.
It is necessary to have a bespereboynik on a server machine, database backups, protection against viruses on all computers ... Well, it’s not for me, dear habrayusers, to teach the simplest rules for safe sex safe operation of a geographically separate unit.

Data-flow and responsibility of units

In conditions when remote outlets become more than 3-5, control of pricing, procurement and many other operations already makes sense to centralize in the "office". In our case, the office itself does not trade, it is the center of responsibility for document flow, pricing, and distribution of goods. And this is justified, because the outlet must trade, “beat the proceeds”, and not issue documents. People who are at the checkout and earn real money should pay as little attention as possible to the back office, and as much as possible to the buyer. Remember this condition, it will still be mentioned.
In the meantime, it means that the above-mentioned load is transferred to the unit designed for this. The analysis of the residuals is transferred there (not yet in my cases, unfortunately) and, as a result, the centralized order, taking into account the season and market needs (masks and diffusers, we all remember?) invoices are still required to come with the goods to the point of sale, but we then forward them to the “office”).

So, the consignment note came to the office (delay for 1-2 days), pricing was carried out at purchase prices and legal requirements (1 more working day), data on retail prices are sent to a retail outlet (1-2 more days). Total offline version of the work we have a delay in sales for 3-5 days from the receipt of the goods.

And in our, really existing version of automation, we have a sales start about 1-2 hours after it arrived. And this is the industry standard for today. This is achieved as follows:
Most importantly: in the pharmaceutical business, no one has been working with paper documents for a long time. Every self-respecting supplier has channels for delivering information about the contents of documents to the buyer. Most often, this is an electronic ordering program, which includes the ability to deliver so-called Electronic Consignment Notes (EN). This is not an electronic document in my understanding: it is not protected from copying, is not encrypted, does not constitute a legally authentic document. This EN - information about the content of the paper document. But it is usually enough to conduct all non-paper data procedures: the assimilation of information into the accounting system, the processing of this data (read the pricing procedure and distribution by outlets).

• By the way, here is the first disadvantage of ANY trading system in the pharmacy chain: the load of EN in commercial and provided systems is most often configured only for a limited set of suppliers. For the rest - pay the developer or understand and customize yourself, if at all there is such an opportunity. Anticipating the question, I immediately chop off: there is no EN standard. There are attempts to create one, but they stumble upon many features of the circulation of drugs and non-drugs traded in pharmacies.
• And here is the second drawback, again, of ANY trading system in the pharmacy chain. The disadvantage is basic and insurmountable without frills or financial injections. This is the lack of a publicly available and comprehensive assortment of pharmacies CLASSIFIER drugs and non-drugs. It would seem, what is simpler - you take Vidal or the Register of Medicinal Products, forcing all suppliers (have you not yet panicked?) To bring the presentation of your assortment to this list - and voila. It remains only to understand who will be doing this, how to replenish it and update it (radar is released once a quarter - and catastrophically does not have time for the release of new drugs, and I’m not talking about the presence of non-drugs in it). From here, the main time spent by the operator or manager who works on the acceptance of the goods is taken: he must match the supplier’s names with the names in the database. Zapaptekami, which did not remove this load, will not allow to lie - it takes from 2 to 6 hours a day, depending on the turnover of the pharmacy. The task is facilitated, of course, by storing such “bindings” in the database, but all the time new suppliers appear, new drugs and, most sadly, non-drugs. In my practice I even saw a system that did not support any stored bindings other than the direct coincidence of names. And with all of this, we remember that the employees of the outlet should “beat the proceeds”, and not the task of comparing classifiers.

Next on the data-flow - data transmission channels of the public network. We have data transmitted in unencrypted packets through a dedicated FTP server. No “internal network”, VPN or other perversions are needed. Who cares about encryption and security of packages - you can encrypt, our system, for example, allows you to add processing of sent and received file packages in any way you like.
Why not VPN? It makes no sense. You can encrypt data before transmission and after transmission to decrypt, and the stability of the VPN in our networks is a very big question. Specifically, I observe numerous problems in the field of data exchange between the office and retail outlets in one friendly pharmacy chain, because of the use of VPN.

By the way, such a nuance immediately follows from the described work scheme: for the sales rate characteristic of pharmacies, it is practically unacceptable to use trade by the barcode (HQ) of the manufacturer. Not only do some products, in principle, do not have them (when did you last see a Russian-made night pot with factory HQ? And a bottle or baby pacifier? And this is all the assortment of a standard pharmacy, and this is not all positions that do not have a factory HQ ). Not only that not for every HQ you can find a description of the goods in the Yuniskan database. Not only is this information not always reliable (and sour cream instead of panadol was obtained, and much more). Well, in the load: which barcode is considered a barcode of a product, if there are three of them on the package? And all in different formats. And also in the load: where (as in the situation with the classifier of goods) take the table of conformity headquarters-name. And from this name still get an indication of the commodity position in our nomenclature database.
In the days of wild youth, I spent 7 (SEVEN) days on the introduction of an automation system in a pharmacy by factory SKS instead of 1 day! In terms of the proceeds of the pharmacy, it was about 350 thousand. P. And nobody considered the payment for the work of employees, who were involved in the process by the entire available staff - about 8 people daily.
Then, the problem of the absence of bindings of factory SKs to commodity items worked (the radar does not contain all the information, and there is no parapharmacy in it, not to mention cosmetics). And then, with a delay, the problem of the absence of bindings of the nomenclature classifiers of suppliers to ours worked. This is when the flow of goods in the normal mode. For without existing bindings, the manager at the acceptance is forced to do them independently. And this procedure is not pleasant - to delve into the details of dosages, the amount in the package, manufacturers.

How is this solved?

Well, the factory SKS is solved very simply: due to the number of problems supplied by the factory SKS, they should not be used. At all. Use only their own "technical" CC. Virtually any modern commercial retail pharma system includes a label display subsystem with service HQs. Remember, we have a label printer at every outlet - that's what we need it for. At least 300 labels are printed per day, so one-off printing options are not suitable. Therefore, the minimum solution for small and medium business is used - BZB2. I will not argue that this is the optimal solution: it has both disadvantages and advantages. But in the caring hands of our operators on acceptance in pharmacies, these printers are not naughty and behave decently.
And once the problem of identification of goods on the parishes of current parishes is solved, the only thing left is the question of the initial implementation of the automation system (this is when you need to take a complete inventory of the goods and shade the entire current range of pharmacies, this is a separate story and a separate article) supplier in the office.
And here is the question of linking the supplier’s classifier to ours - this, as I already wrote, is the headache of any retail pharmacy automation system. There are several options:

• Use priority supplier and its classifier. The problem does not completely solve, but at least makes it not global and surmountable. Most often, this option is offered as a free bonus when using retail automation systems developed by large pharmaceutical business players - they immediately offer their own classifier and other trifles, sometimes even give the program for free. In exchange for the minimum guaranteed turnover and priority supplier status. I consider this approach non-optimal, because, in addition to the doubtfulness of the economic benefits, you won’t wait for the import models of other suppliers, and the ability to customize these layouts is usually very limited or completely absent. And rarely, such automation systems developed in the IT department of such a company as a by-product are truly convenient and 100% satisfying all requirements for data processing speed, reliability of data exchange, completeness of the reporting subsystem and scalability. And perfection on demand or a system of bug fixes - what can I say, even if some commercial systems sin with their absence.
• Use the radar or Vidal and build up a set of classifier bindings with different tricks (use the set of factory SKS that both the radar and the supplier have; then use the efforts of the “office” supply department - let them sweat tied. There are other options, but again, topic of a whole separate article). The path is costly but reliable. Deprived of the danger of "hooking up" on the program, deliveries in volume and other services of a priority supplier.
• The way, which is offered by the right developers of specialized software for pharmacy chains: its own classifier, licked by years of work of trusted working pharmacies, with bindings for the main suppliers. Only one problem: this classifier is usually not “tied” now to the classifiers of other automation systems used in the company. For example, 1C accounting systems in accounting. Or if, God forbid, the company uses several trade automation systems. But even with all this, this way seems to me the most optimal.

Automation software

And now, when you, patient and persistent hacking readers, already have an idea about the basic specifics of farm trading, we can discuss the most interesting: software for trade automation.
Immediately mark my position: I like the system, which I will call only in a private setting, so as not to be accused of advertising. And which I now consider on the Russian market as optimal in terms of price and quality. Moreover, I consider it very inexpensive, provided that the functionality available for this money is very broad and meets all the needs of almost any network - from one to 20, 200 pharmacies. I see no fundamental problems with a large number of outlets, the system scales very well.

Historically, now this system is almost not used, and I have experience in using several others, and therefore I have the opportunity to assess the fundamental flaws that are practically in ANY of them.
So, based on everything that is written above, which is often lacking in current systems:

• Reliability of data exchange between the office and retail outlets. At this point, how lucky it is: either the packets are unique and cannot be re-formed, which is unacceptable with probable losses, or the packets are not hashed, which leads to duplication of information in the receiver base. In general, there were a lot of different stocks on the exchange. And the system should allow sending the same thing as many times as well as uniquely identifying the packets as duplicate if cho.
• Flexibility in the choice of data exchange between departments. Well, is not it idiotic - to limit the possibility of sending packets laying out files in the daddy via VPN? And then complain that “your Internet is bad, so the connection breaks all the time”. Or limit by email.
• No matter how sad it is, but usability and minimalism in the user interface. The pharmacist is a girl of 20, who was taught to hammer at the box office. Or at best, it worked in some other sales system. Any new location of bats and buttons on the screen is a disaster. And even more so the new sequence of actions in the sale. When to “chiknut” a discount card, when - SK retirement discounts, what to press and when, to finally knock out a check. And if you use a discount card - no longer press. Or click? So, most of the automation systems that I saw, sin that the interface of the cashier is not usable at all.
• The absence of overt hops in the minds of developers. The use of COM-scanners SK is something. For some reason, all 1C solutions prefer this option (or scanners in the keyboard break), put some special drivers. Or at all they set themselves in the advantage that the drivers of these devices come with the accounting system. When USB scanners have long existed that work as a HID-compatible input device and just replace the keyboard input from the keyboard.
• And again usability. The main share of the supply manager’s time is spent binding the classifiers of suppliers' goods to our classifier. So make it better, faster, more intuitive! I have not seen a single system that would adequately work with this task. The maximum amount of developers is enough is a filter of the local classifier by the first few letters of the name. I believe that this is not optimal and time can be spent on developing a matching system using more flexible algorithms.
• Competent client-server work. Stone in the garden of a very large supplier. Comrades, the time when the data was stored in the local memory in the program at the current moment is long gone! The client station should be, if not a thin client, then certainly not a data processing center!
• Supports free OS. Here, in general, gluteus maximus. Only one of the companies I know develops (and it seems to me, only under the pressure of my inquisitive inquiries from two years ago) an interface under Linux. Understandably, the main thing is not the interface (the win-version of the client part perfectly plows under Suse + Wine), but the interface with the equipment. But then you and the software developers!
• Competent interfacing with other accounting systems. Probably, only the decision from Rarusa does not suffer from the lack of such, because it in itself is already a monster with the included accounting subsystem. But the rest should be at least more open to import data. And then one by one the systems pass through my hands, and each time the same problem: often even the developers themselves are not sure enough in which places the data is stored in the database and how to pick it out for accounting. And the opportunity to export data “for accounting”, as a rule, is a rather pitiful sight. Even in my favorite @@@.
• Sustainable work in unstable conditions. This is sad when a DBMS is used, which does not allow tuning (or would be better implying its default) operation mode designed for quick start without data loss in case of power failures, local network operation, and RAID array operation under the base files. This greatly increases the instability of the outlets and the company's costs for specialists in data recovery and support (if for example you need to fix the jambs that arise in the credentials for such failures).

This is all to the fact that automating a trading network from several outlets is not worth it in a hurry and anyhow. Look at the prices, the terms of service. Do not get fooled by the name and beautiful interface - the cashier does not need beauty, but speed and convenience. Yes, even if it is textual (and there are such in the market), the main thing is that it should not fail. The cashier earns money, he does not have to rummage through the settings and fight the interface.