Geekly Articles each Day
📜 ⬆️ ⬇️

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 because of 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 contractors and who needs to pay something, requests an invoice and sends by mail to the accounting department with a request to “pay”. At the same time, the accounting department does not always pay bills without prior approval of payment with the employee’s immediate supervisor and / or company management. Under certain conditions, the chain of approvals can be “shortened” or, on the contrary, “lengthened”.

While 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:


Initially, we analyzed the products of the “electronic document management system” family that are 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?).
Secondly, the price (paid in one step 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 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”.

Implementation


I won’t describe 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 the 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 implementation and implementation period 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, since 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:


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


Of course, there was no “curiosity”. First of all we are talking about configuring vorkflou. We initially decided that we needed the ability to configure the business process tree. So that from one point (stage) of coordination it would be 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 it was not necessary to 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 related to the launch of new types of approvals, it became clear that at some stages, for specific types of requests, 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 use one workflow for one approval scheme (under the scheme I mean entities that require engagement and the order of different roles — agreement, 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 (it was here that our tree-like architecture of the workflow helped us and there was nothing “Crutch”).

Well, a little fly in the 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.

Interfaces


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

Dashboard


dashboard


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:


Create 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 that has just been 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 applications of the same type 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 described 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 go to 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 (except for 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.

Search




In the search for applications, a set of properties is displayed at the top, the values ​​of which need to be sampled. Sets are configurable 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:


Matching



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:


If with the first three everything is more or less clear, then the 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, whose values ​​can be changed by the coordinating one.

Although a bit 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 participation.

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 grows, 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.

Source: https://habr.com/ru/post/426707/

More articles:


All Articles