How to and how not to automate trade

    My heart bleeds when I read an article, and even more so - comments on it. One mention of the tycoons of the 1C environment as a solution for automating the activities of the pharmacy chain is worth it. Dear habratovarischi, 1C Trade Management IN PRINCIPLE is not adapted for trading in the pharmaceutical business! And the attempts of the beloved daughter of 1C that deserve attention in the field of adaptation of the Retail still do not completely solve the main problems of this system. And under this condition, this decision has no right to cost the kind of money for which it is sold.
    My opinion is just the opinion accumulated in the course of many years of work in the environment of pharmaceutical trading enterprises, both retail and wholesale. But since I mentioned that article, it will become clear to someone familiar with it that it will still be about the retail part.
    So, I’ll 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 to cat. I warn you: not a single picture and a lot of letters.

    Equipment and other trifles

    Immediately make a reservation: in no case do I set the goal of correcting what has already been done or advising. To start with the fact that in Moscow there have never been problems with the choice of equipment for the reasons of protection of some manufacturers of fiscal equipment by local tax authorities. Therefore, at all pharmacies there is a fairly standard set of equipment for small Moscow retail enterprises:

    • Systematics in the workplace - standard Win PC running XP Prof
    • The specifics of working with medications, as has already been correctly noted, implies extensive lists and many additional parameters, so most often there are not enough standard 13-inch trading monitors, 17-inch ones are almost everywhere. The exception is the acceptance of goods, where it is enough to press two and a half buttons and see the list of invoices
    • Label printer (one per dot) - Godex BZB2. Below I will explain why the labels
    • A standard document printer, there are variations of the sea, the main thing is to be compatible with the OS and correctly print the documentation
    • Barcode scanner (HQ) we use the simplest Zebex or Cipher - there are no sense to take the screwed ones. And even more so every time I insist that the scanners be with a USB interface - in order to avoid unnecessary hemorrhoids with COM ports. It cannot be avoided at all, because the fiscal technique and the customer’s display, but at least on the scanner, are possible.
    • Customer display costs Firich-2029. Simple, and enough of it.
    • The network is everywhere wired on standard D-Link switches, I see no reason to focus on this.

    Banknote counters, money checking equipment, air conditioners, and heaters are, as you know, outside the scope of a well-organized IT department, so it makes no sense to describe them.
    Necessarily an uninterrupted operation on the server machine, backups of databases, virus protection on all computers ... Well, it’s not for me, dear Habrausers, to teach the simplest rules of safe sex for safe work of a geographically separate unit.

    Data-flow and unit responsibility

    In conditions when there are more than 3-5 remote outlets, it makes sense to centralize pricing, purchasing and many other operations in the “office”. In our case, the office itself does not trade, it is the center of responsibility for document management, pricing, distribution of goods. And this is justified, because the outlet must trade, “beat revenue,” and not draw up documents. People who are at the checkout and earn real money should pay as little attention 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 load mentioned above is transferred to the unit designed for this. There (unfortunately, not yet in my cases) the analysis of the balances is transferred and, as a result, a centralized order taking into account the season and market needs (do you remember all the masks and respirators?) And in the same division there is the whole paper workflow, as far as possible ( the waybills are obliged to come with the goods to the point of sale. But we then forward them to the "office").

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

    And in our really existing version of automation, we have a start of sale approximately 1-2 hours after he arrived. And this is the industry standard today. This is achieved as follows:
    Most importantly: in the pharmaceutical business, no one has long been working with paper documents. Each 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 the so-called Electronic Invoices. This is not an electronic document in my understanding: it is not protected from copying, is not encrypted, is not a legally reliable document. This EN is information about the content of a paper document. But it is usually enough to carry out all paperless procedures with data: the assimilation of information into accounting systems, the processing of these data (read the pricing procedure and distribution by retail outlets).
    • By the way, here is the first drawback of ANY trading system in the pharmacy network: loading EH in commercial and provided systems is most often configured only for a limited set of suppliers. For the rest, pay the developer or sort it out and configure it yourself, if at all. Anticipating the question, I’ll chop off right away: there is no standard EN. There are attempts to create one, but they come across many features of the turnover of drugs and non-drugs traded in pharmacies.
    • And here is the second drawback, again, of ANY trading system in the pharmacy network. The disadvantage is basic and insurmountable without frills or financial injections. This is the lack of a generally accessible and comprehensive range of pharmacies. CLASSIFIER drugs and non-drugs. It would seem that it’s easier - you take Vidal or the Register of Medicines, force all suppliers (have not panic yet?) To bring your assertion to this list - and voila. It remains only to understand who will do this, how to replenish and update it (the radar is issued once a quarter - and catastrophically does not keep pace with the release of new drugs, and I am completely silent about the presence of non-drugs in it). From here, the main time taken by the operator or manager who works on the acceptance of the goods is taken: he must compare the names of the supplier with the names in the database. The pharmacies that didn’t remove this load will not be allowed to lie - it takes from 2 to 6 hours a day, depending on the turnover of the pharmacy. The task is made easier, of course, by storing such “bindings” in the database, but after all, new suppliers, new drugs, and, most sadly, non-drugs, appear all the time. In my practice, I even saw a system that did not support any stored bindings except for direct coincidence of names. And with all this, we remember that the employees of the outlet should “beat the revenue”, and not be engaged in the task of comparing classifiers. Non-drugs. In my practice, I even saw a system that did not support any stored bindings except for direct coincidence of names. And with all this, we remember that the employees of the outlet should “beat the revenue”, and not be engaged in the task of comparing classifiers. Non-drugs. In my practice, I even saw a system that did not support any stored bindings except for direct coincidence of names. And with all this, we remember that the employees of the outlet should “beat the revenue”, and not be engaged in the task of comparing classifiers.

    Further along the data-flow - data transmission over the channels of a public network. Our data is transmitted in unencrypted packets through a dedicated FTP server. No "internal network", VPN and other perverts are needed. Anyone who cares about encryption and packet security can be encrypted, our system, for example, allows you to add processing of sent and received file packets in any necessary way.
    Why not a VPN? It makes no sense. Data can be encrypted before transmission and after transmission, and the stability of the VPN in our networks is a very big question. Specifically, I am now witnessing numerous problems in the field of data exchange between the office and retail outlets in one friendly pharmacy network, because a VPN is used.

    By the way, the following nuance immediately follows from the described scheme of work: for the speed of sales characteristic of pharmacies, it is almost unacceptable to use bar code (ШК) trade from the manufacturer. Not only that, some products, in principle, do not have them (when was the last time you saw a Russian-made night pot with a factory barcode? And a bottle or a baby pacifier? And this is all the assortment of a standard pharmacy, and this is far from all items that do not have a factory barcode ) Not only that, far from every HQ you can find a description of the goods in the Uniscan database. Not only is this information not always reliable (and sour cream was received instead of panadol, and much more). Well, and to the load: which barcode is considered a product barcode if there are three of them on the package? And all in different formats. And also to the load: where (as in the situation with the classifier of goods) take the table of correspondence ShK-name. And from this name you still get an indication of the commodity position in our stock list.
    In the days of wild youth, I ditched 7 (SEVEN) days instead of 1 day to introduce an automation system in a pharmacy at a factory bar. In terms of the proceeds of that pharmacy, this happened at about 350 thousand rubles. And this was still no one considered the payment for the work of employees who were involved in the process of the entire available staff - about 8 people daily.
    Then the problem of the absence of factory HQ bindings 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 nomenclature classifiers of suppliers to ours worked. This is when the stream of goods arrived in the normal mode. For without the existing bindings, the acceptance manager is forced to do them on their own. And this is not a pleasant procedure - to delve into the details of dosages, quantities in packaging, manufacturers.

    How is this solved?

    Well, with factory HQs it is solved very simply: in connection with so many problems posed by factory HQs, they should not be used. At all. Use only your own "technical" barcode. Almost any modern commercial system of retail pharmaceutical trade includes a subsystem for displaying labels with service bar codes. Remember, we have a label printer at every point of sale - that's why we need it. Labels per day print at least 300, so options for one-time printing are not suitable. Therefore, the minimum solution for small and medium-sized businesses 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 at the reception in pharmacies, these printers are not capricious and behave with dignity.
    And once the problem of identifying the current arrivals at the places of goods is solved, the only question remains of the initial implementation of the automation system (this is when you need to conduct a complete inventory of the goods and “shade” the entire pharmacy assortment, this is a separate story and a separate article) and the issue of linking the goods freshly received from vendor in the office.
    And so the question of binding the supplier’s classifier to ours is, as I already wrote, the headache of any automation system for retail pharmaceutical trade. There are several options:
    • Use a priority provider and its classifier. It does not completely solve the problem, 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 classifier and other little things, sometimes even give a program for free. In exchange for a minimum guaranteed turnover and priority supplier status. I think this approach is not optimal, because, in addition to the dubiousness of economic benefits, you will not get from them models of import of power supply from other suppliers, and the ability to configure these models yourself 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 the requirements for data processing speed, reliability of data exchange, completeness of the reporting subsystem and scalability. And improvements upon request or a bugfix system - what can I say, even if some commercial systems sin by their absence.
    • Use a radar or Vidal and develop a set of classifier bindings with different tricks (use a set of factory bar codes that are available both in the radar and the supplier; then use the efforts of the office supply department - let them sweat to tie. There are still options, but this, again, topic of a whole separate article). The path is costly but reliable. There is no danger of "getting hooked" on the program, volume deliveries and other services of the priority supplier.
    • The way that the right developers of specialized software for pharmacy chains offer: their own classifier, licked by years of work of trusted work pharmacies, with bindings to the main suppliers. Only one problem: such a 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 trading automation systems. But with all this, this way seems to me the most optimal.

    Automation software

    And now, when you, patient and persistent habractor, already have an idea of ​​the main specifics of farm trade, we can discuss the most interesting: software for trade automation.
    I’ll immediately outline 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 in the Russian market to be optimal in terms of price and quality. Moreover, I consider it very inexpensive, provided that the functionality available for this money is very wide and satisfies all the needs of almost any network - from one to 20, 200 pharmacies. I don’t see fundamental problems with a large number of outlets, the system scales very well.

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

    • Reliability of data exchange between office and retail outlets. Here's how lucky: either the packages are unique and cannot be re-formed, which is unacceptable with possible losses, or the packages are not hashed, which leads to duplication of information in the destination database. In general, there were a great many different jambs on the exchange. And the system should allow to send the same thing many times, and unambiguously identify packets as duplicate if cho.
    • Flexibility in choosing a way to exchange data between departments. Well, is it not idiocy to limit the ability to forward packets by uploading files to daddy via VPN? And then another complain that "your Internet is bad, so the connection is disconnected all the time." Or limit to email.
    • It is sad, but usability and minimalism in the user interface. A pharmacist is a girl of about 20 who was taught to peck at the checkout. Or at best, she worked in some other selling system. Any new arrangement of windows and buttons on the screen is a disaster. And even more so, a new sequence of actions when selling. When to “discount” a discount card, when - HK pension discounts, what and when to click, 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 with the fact that the cashier’s interface is completely non-usable.
    • The lack of explicit jumps in the minds of developers. Using COM barcode scanners is something. For some reason, all 1Clear solutions prefer this particular option (or scanners in keyboard break), install some special drivers. Or they even take advantage of the fact that the drivers of these devices come with the accounting system. When USB scanners already exist for a long time, working as a HID-compatible input device and elementarily replacing the input of the barcode from the keyboard.
    • And usability again. The bulk of the time the supply manager spends on linking the classifiers of supplier 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 that developers can do is filter the local classifier by the first few letters of the name. I believe that this is not optimal and you can spend time developing a matching search system using more flexible algorithms.
    • Competent client-server work. Stone in the garden of one very large supplier. Comrades, the time when data was stored in the local memory in the program at the current moment is long gone! A client station should be, if not a thin client, then certainly not a data center!
    • Support for free OS. Here is generally gluteus maximus. Only one of the companies I know is developing (and it seems to me, only under the pressure of my inquisitive questions two years ago) an interface for Linux. Of course, the main thing is not the interface (the win-version of the client part plows perfectly under Suse + Wine), but the interface with the equipment. But you and software developers are for that!
    • Competent pairing with other accounting systems. Probably, only the solution from Rarus does not suffer from the absence of one, because it in itself is already a monster with the accounting subsystem turned on. But the rest should at least be more open to import data. And then, one after another, the systems go through my hands, and each time the same problem: often even the developers themselves do not quite confidently know in which places of the database what data is stored and how to pick it out for accounting. And the provided data export capabilities “for accounting”, as a rule, are a rather miserable sight. Even at my beloved @@@.
    • Sustainable operation in unstable conditions. This is sad when a DBMS is used that does not allow the configuration (and it would be better if it implies a default) of an operating mode designed to run quickly without data loss during power outages, in the local network, in the operation of the RAID array under the database files. This greatly increases the instability of the outlets and the company's costs for data recovery specialists, support (if for example you need to fix the jambs that occur in the credentials in case of such failures).

    This is all to the fact that automating a distribution network from several outlets is not worth the haste and anyhow. Look at the prices, the terms of service. Do not be 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 ones on the market), the main thing is that it does not give failures. The cashier makes money, he should not rummage through the settings and fight with the interface.

    Also popular now: