Matching system How we invented the bicycle

    We continue to talk about how we improve the life not only of our clients and partners, but also of the company's employees. It will be a question of introduction of the coordination system. Consciously did not indicate the agreement of “what”, since in the future it will become clear that, purely theoretically, the agreement of “everything”.

    Reflections on the approval system

    Initially, in our company, as in many others in which I had to work, and also in which I was a “guest” or simply heard from my acquaintances, agreement negotiation was carried out (and at the time of writing this article is still being conducted) mail. Naturally, this suits companies with a small number of personnel and counterparties. There is no special need to invent and implement systems due to the signing of one or two contracts per month (or even a year) with the sole director-general on signing the decision. A similar situation was observed with the payment of bills. Every employee who interacts with counterparties and who needs to pay something, requests an invoice and sends it to the accounting department by mail with a request to “pay”. Wherein, accounting does not always pay bills without prior approval of payment with the immediate supervisor of the employee and / or company management. Under certain conditions, the chain of approvals can be “shortened” or, on the contrary, “lengthened”.

    So far there are not many employees and everyone knows all his colleagues, who is who and who is who the head - there are no special problems. In the manual mode and under certain conditions, requests for payment are coordinated in the correspondence mode and paid (or rejected). But our company is growing and from a certain point we crossed that invisible line, after which we need to think about automating these processes and the need to introduce something new.

    Our Wishlist

    We had our minimum system requirements:

    • User-friendly interface and highly desirable web-oriented (without the need to install clients)
    • Customization flexibility
    • Though we are not clinical, but paranoid. Therefore, the services in which confidential information may appear, we want to keep in our closed perimeter

    Initially, we analyzed the products of the “electronic document management system” family on the market. We looked at the well-known systems: 1С: Document circulation, “BUSINESS”, “TEZIS”. Also looked at the systems that were made to order for other companies, as well as new items such as Allware.

    I can not say that the systems are bad. In fact, almost all systems allow us to perform our basic “wishes” and even more than we need. But, as usual, the devil is in the details.

    First of all - the interface. We are not accustomed to using the interface in the style of "1C". We need a simple, intuitive interface in which we will perform a minimum of actions to obtain the maximum result (and who does not want to?).
    In the second place - the price (paid at once and then the cost of ownership of the product as a whole). We do not need everything in systems that are offered out of the box. But at the same time you have to pay immediately for everything. And since now many people are switching to a subscription system, they have to pay constantly and the amount, as usual, depends on a variety of conditions (number of users / connections, ability to work in the cloud, additional options, modules, etc.). And to “jump off” from the system, if suddenly the price stopped arranging - it is problematic.
    Thirdly, there is no possibility to “manage” your “Wishlist”.


    I will not write for a long time how and why in the end we stopped at the decision to “invent a bicycle” and write our electronic document management system. The decision is made - you need to do. We have already gone through the illness of trying to sell a product without requirements, so the process of writing TK and its coordination initially started. Fortunately, we had examples of implementations before our eyes, so the formation was rather painless.

    The only thing we had to break the spears was in the process of developing the architecture not to be tempted to satisfy the requirements “as is”, to the detriment of flexibility and further ease of use. The temptation was great, especially for the main customer, since the period of implementation and implementation would be reduced by 2 times. But we managed to convince both the leadership and ourselves that “it is better to lose a day, then fly in 5 minutes”. And I think that we made the right choice.
    It is better to lose a day, then fly for 5 minutes.
    The “standard” stack - .Net Core 2 and EntityFramework, Angular 4, MS SQL, as we have a fairly large background in the application of tools and technologies. Although the DBMS is of no special importance for us, for obvious reasons. If necessary, move on to what we want.
    The result was a product that meets important requirements for us:

    • One workflow - different negotiation participants (linked to the next item)
    • Conditions for skipping the approval stage for specified conditions (any field in the application can be added to the condition with a specified check and, based on the validity of the condition, the need to move to the next approval step or its “omission” is determined)
    • Our “proprietary” interface

    Were also worked out and implemented such convenient and useful features as:

    • Setting the default values ​​of reference books (both user and system). The user directory is an entity that allows you to define elements yourself by the user. Created items will be available only to him. In this case, the administrator of the system can add common elements to such a reference book, which will be accessible to all users
    • Determination of the most frequently used elements of directories for each user and the formation of lists in the interface based on this statistics (sorting)
    • Fully customizable admin schemes (structure and properties of fields to fill in) and presentation (arrangement of elements in the form) of each type of request for approval
    • Flexible ACL
    • Customizable search by each user for different sets of parameters. Parameters can be any properties of application templates with the ability to select a condition that must be imposed on this field during filtering. In this case, you can create as many sets for filtering. Convenient for quick search in different cuts.
    • Checking the validity of the entered values ​​based on a given template for a specific field of the application

    Of course, there was no “curiosity”. First of all, we are talking about configuring workflow. We initially decided that we needed the ability to configure a business process tree. So that from one point (stage) of coordination it was possible to go on different branches, depending on the choice of the user (the coordinator). Logical and flexible. But already after we implemented this feature, and launched the system in production, it seemed to us that, in fact, we should not give the user the right to choose (think about). For him, everything should happen at the level of “Reconcile”, “Refuse”. Otherwise, we will not be able to deviate from the principle that the employee understands the subtleties of interaction in the company. And to meet this condition vorkflou must be linear .
    Of course, there was no “curiosity”.
    As a result, we found a compromise - the architecture of the solution and the implementation of the workflow were left tree-like, while the use from the point of view of configuration was fixed at the level of “agreement”. And rightly so. Since now, when analyzing the tasks associated with the launch of new types of approvals, it became clear that at some stages, for specific types of applications, we need to provide an opportunity for the coordinator to choose various actions.

    Now a little about our “know-how” (at least we believe in it). To achieve linearity and, at the same time, the ability to use one workflow for one approval scheme (under the scheme I mean entities that require engagement and the order of different roles — an agreement, an invoice for payment, etc.), we have thought out and implemented the conditions mechanism skip the next stage (s) coordination. In forming the conditions, we can use any essence of the approval card and compare it with “something”.

    For example, we have the following entities: Initiator, Amount, Currency, Counterparty. And we need to, with an amount less than 100,000 rubles. did not pass approval through employee A, in case of currency payments, necessarily connected to coordination B, and if the initiator is employee C, additional coordination is required for employee D. In this case, by employees we mean both individuals and a specific group. To implement these points, we add all the points of agreement “in line”. Ie: Initiator-> A-> B-> D-> ...

    Next, conditions are formed on the “skip” of the transition to each of the matching points. For example, the Transition Initiator-> A configures the condition “Amount <100,000”, on (Initiator) A-> B - Currency = “Ruble”, (Initiator, A, B) -> D - Initiator! = C.

    Why are brackets shown in transitions? Because conditions can be fulfilled in a complex and “under the hood”, if we form a condition for the transition to the coordination point, we automatically generate another system transition that “bypasses” this point (this is where our tree-like architecture of the workflow helped us and there was nothing “Crutch”).

    Well, a little tar in a barrel of honey. We did not reach out to the implementation of a configurable notification management mechanism. Although initially it was laid in the architecture of the project. As usual, to speed up the launch process, we had to “temporarily hard-code” a bit, and at the moment this hardcode remained. And the idea was to create a mechanism similar to jira, which allows you to create your own notification scheme in which you can set triggers (events) and associate them with groups or specific employees and be able to “bind” it to any type of application.
    To speed up the launch process, I had to “temporarily cheat” a little.


    Some interfaces of our system, so that there is an understanding of what was discussed at all



    The first thing that the user of the system sees when it is opened (if you do not take into account the authentication process) is a dashboard. It displays only active (incomplete) matching. In this case, applications are divided into 2 segments:

    • Applications that require user approval (I am a performer)
    • Applications that were initiated by the user (I am the author)

    Creating a new application

    Create application

    The interface for creating a new application can have an idea (the number and arrangement of elements) absolutely any. Here is a simple interface that demonstrates the ability to enter numbers, a choice from the list, a flag (check-box), date, attachments.
    The only thing you can pay attention to is the “Create more” option. When it is activated, after creating the current application, we are not in the dashboard or in the card of the application just created, but the form for creating a new application of the same type as the one that was just created opens immediately. It was implemented at the request of our employees, who have to create similar applications in batches.

    Approval stage

    Approval stage

    This interface is not much different from the application creation form. But it has a number of fundamental functional features:

    1. Instead of creating buttons, there are buttons, clicks on which transfer the application to one of the states of the business process. In the degenerate case, as I wrote above, this is “Reject” and “Reconcile”
    2. Attachments, comments and a new entity log (action history) are in separate tabs.
    3. By default, all fields of the application, except for the comment, are inaccessible for editing. At the same time, we have laid down the functionality that allows us to provide at any particular approval step the possibility to correct only a given set of fields.
    4. If you are the initiator of the application (you can always enter the approval card), and you have the option “Create a duplicate”, when you click on it, the application creation form opens, the field values ​​of which (with the exception of attachments) duplicate the field values ​​of the current application.

    If you look closely, you can see an orange element in front of the field for selecting a Counterparty with a plus inside. This is the personal directory management functionality. Clicking on this item opens the form for adding a reference item.

    Since in this case it is the Counterparty, the reference element we have contains two requisites - Name and TIN. After creation, the user can immediately select this item from the drop-down list.


    In the search for applications, a set of properties is displayed at the top, the values ​​of which need to be sampled. Sets are configured by each user to fit their needs with the ability to quickly switch between them.

    Business Process Administration

    As part of business process management, we can create any number of route points and specify transitions. The result is a transition graph. And for each coordination point we can specify:

    • Who is coordinating at this point
    • Permissions to perform actions at a given point in the route
    • Conditions for skipping this point (approval stage)


    In the “Matching” tab you can add groups to which users can add to the approval process at this point in the business process.

    Permissions for actions

    Permissions can be a little more detailed. To limit the actions of coordinating, associated with changes in the values ​​of fields (entities) in the application, a permission mechanism is introduced. At the moment we have entered 4 permissions:

    • Attachment Download
    • View attachments
    • Commenting
    • Change of field values

    If with the first three everything is more or less clear, then permission to change the available fields should be commented. By default, the coordinators cannot change any field values ​​in the application. Only view mode is available. In case it is necessary to allow changing specific fields of an application at a specific point of agreement, this option is activated and only those values ​​can be selected from the list of fields of the application.

    Although it is a little far-fetched, but for example, this may be necessary if you have a separate position “checker of the correctness of filling the amount”, then give him the opportunity to change only the amount in the application and nothing more.

    Pass conditions

    Pass conditions I described above. Functionality is needed to form a single linear business process for all users of the system, and at the same time to carry out the movement of the application along the route in different ways, depending on the given condition and without user intervention.

    A setting is prepared on the screenshot that will allow you to skip this waypoint if the initiator is in certain groups and the Currency is equivalent to the Russian ruble.

    Instead of conclusion

    Currently, our company has only one type of coordination. But with the flexibility of customization that is incorporated in the system, we have the tools to configure any application card, where you can specify any number of fields, any presentation of the application card and any route matching with various conditions.

    The only thing that is required is to work the analyst on collecting the requirements and then transfer them to the system via the administration interface. What we are doing now.

    The product is alive, periodically we make changes at the request of our employees, as a result of which its power and usability is growing, and the implemented functions fulfill the task that our business faces, and we can always say with confidence that the requested functionality will be implemented in case if at all possible.

    Also popular now: