How we connect new deliveries
Over the past few months, we at Avtomakon have integrated VkusVill with two large Russian partners. For us, this was the first experience of integration with such large companies. But interestingly, the integration experience was also new to the partners. I would like to share the details of this bilateral process.
How it works
When carrying out integration, we prefer to work on the basis of a pool model: partners provide us with an API by which we run as a server, and upon request give them the necessary information. For example, catalogs of goods and outlets, current balances. This is the minimum set of necessary information that partners need in order to form an order on their side and transfer it to us.
Some partners additionally insist on some additional nuances, for example, receiving web cookies. Often we can meet them halfway: our advantage is that we are quite flexible and have a lot of freedom of action, so making some changes on our side is much easier than on the side of a big partner. But in all such situations, we first of all take into account the wishes of the business, which sets us the tasks of integration.
Then the PHP programmer writes methods, starting with authorization. As a rule, we work according to the standard scenario. For the integration to work, we need to exchange certain segments of information, which I have already mentioned. Then we synchronize with the status partner. If we work on the partner’s API, it is natural that our internal statuses do not coincide with the order statuses that are accepted on that side. For such cases, we write a status mapping table and test it.
At first, tests are conducted without the participation of stores. We create an order directly in the partner’s systems and see in what form it is with us, and in what form it is with the partner. Then we choose one store for testing, but in this situation, orders are still generated artificially. Then we transfer this store to a full-fledged work with a partner, and he begins to accept live orders. In the end, we are gradually scaling up to stores within the city and regions.
Our task is to conduct the partner’s order through the handle – method, and give all the information to our common database. If we talk about the stack, then we write the methods in PHP, and then a large SQL database is used. These methods interact with root procedures written in SQL, which already create orders and stuff.
Integration with external partners – pitfalls
At the moment we have carried out integration with marketplaces, food delivery services from restaurants and, in fact, couriers – taxi services.
In general, the process of transferring an order through Delivery Club and another ready-made food delivery service looks like this. The user opens the partner’s application, sees that there is a delivery from VkusVilla, and happily starts placing an order. When the user has formed a cart, the partner sends it to us, the store processes it and returns the already changed cart back. And then the finished order waits for the partner’s courier and goes with him to the person who issued it. At the same time, the stores serve all orders on a first-come, first-served basis, no matter where they come from – from partners or from the VkusVill application and website.
At first glance, nothing complicated, but. It is impossible not to take into account the fact that buyers order from grocery stores not only piece goods, but also weight ones. For us, weight goods are a fairly large assortment sector, it is very important that we have the opportunity to deliver it to customers. But in the process of organizing work with companies that have always delivered only ready-made food, but not food at all, we faced some restrictions.
The partner is usually reluctant to change the order, and in a situation with bulk goods this is inevitable: history knows very few cases when when weighing oranges it is possible to hit the bull’s-eye and put exactly 600 grams of these oranges in the bag. No more, no less.
Penny ruble round
When working with weighted goods, it is impossible to avoid the use of quanta. Quantum is the average weight of a weight item. If we are talking, for example, about pineapples or chicken, in these cases the quantum is determined on the basis of the average weight of a certain quantity of goods. Knowledge about such a quantum comes with experience: if you trade in chicken for six months, you will find out that its average weight is 900 grams, for pineapples – 1200 grams.
For bulk goods that are usually not purchased individually, for example, apples, the quantum is calculated from the average weight of one package, which the buyer usually takes. So in VkusVill stores one apple quantum is equal to 600 grams.
When we agreed with one of the delivery services to work with bulk goods, it was decided that they would accept the price per quantum from us. And here another problem awaited us: the price for one quantum never turns out to be round – there will certainly be a penny. And partners don’t work with pennies.
Therefore, we decided to give the partner a whole quantum, and he will multiply it by the number of quanta and round it off. But double rounding, going around in a circle, gives us a discrepancy, and sometimes even not just in pennies, but already in rubles. Then we offered to accept our prices by order, because at the checkout, in any case, the formula “quantity x price = amount” must be observed, regardless of where and to whom we transfer prices for quanta. And this is what our team is working on now.
From a technical point of view, the subtle point of integration was the parsing time of the directory. We have more than a thousand stores, each of which has its own product matrix. And the process of obtaining a catalog by a partner in the context of all stores takes a long time. Now we are working on this direction and are introducing data caching mechanisms in order to exchange only changes.
The first time after the launch, we also had difficulties due to the human factor. Our pickers could put lingonberry instead of cranberry juice, the order went to the partner, but he could not accept it, because this fruit drink was not in the original order. The guys who are dealing with the front helped us to cope with this problem: they banned the replacement of goods for certain partners right at the checkout.
In general, we can say that we have got full integration with the two largest services. Yes, there is something to work on, but the main functionality – receiving and delivering an order – works quite successfully.
Other integrations
One of the main goals of our common work is the most efficient delivery of goods, more precisely, minimizing the life of an order from the moment the basket is filled in the application until the moment the order is at the client’s door. Therefore, we integrated not only with partners-marketplaces, but also with delivery services – Gett, Yandex Taxi, as well as the Net Fi service.
Here it is important for us to determine the possibility of walking or car delivery, depending on two important criteria: distance and weight of the order. For example, there is a competition for delivery services to which we can place an order. This can be either our internal delivery service or an external one. And here you can configure it depending on the priority of one service over others, or in the context of stores and other things.
Naturally, it does not happen that two completely different systems fit into each other’s grooves like clockwork. For example, there was a question about the format of addresses. Someone definitely needs the entrance, apartment and floor to stand out separately, while someone just needs to indicate all this in the comments. Again, authorization and personal account for each service works differently.
And as a rule, the API does not always describe all possible cases that may occur during industrial operation. Therefore, we have a full backlog, but there are no problems for which a solution is not found.
Command
As always, there are people behind any process. We at Avtomakon believe that three people will be enough to implement the direct technical part of integration with an external partner: an analyst, a PHP specialist who writes authentication with a partner and all methods, processes partner requests, etc., and a SQL programmer, who puts the received information into the required tables and also at the request of the partner, translated through PHP into the root procedure, returns the necessary information to him. Actually, this is the composition we work with.
Sometimes situations arise in which we need the help of colleagues. Then we can hire a specialist from the area in which we have a gag. This exchange works both ways and helps us achieve results faster.
We work on Agile: three times a week we hold morning stand-ups on tasks and their statuses, defining their priorities, hold meetings with customers and retrospectives with teams. In general, all the classic set that this methodology implies, we tried not to invent something of our own and not to rewrite Agile for themselves …
Integration with external partners is just the tip of the iceberg. There is also integration with contractors, suppliers, our website and mobile application. Now we are moving along the path of distributing information between databases, and integration within the company has also become in demand. We have 13-14 people involved in this whole process, plus people from the e-commerce department who set tasks for us. And we, in turn, choose the methods of their implementation.
At the same time, it is impossible to say that the integration process is the work of one, albeit large, team. Behind the work of the entire system as a whole, there are many teams responsible for the front, system architecture, the structure of our internal documents and other important things.
Do not forget about the admin panel, where you can view any order, the time of its creation, trace its path and find out the service that will deliver this order. Also, through the admin panel, we transmit information about the taxi: car number, the name of the taxi driver, etc.
What else
Integration with external partners is a complex process, largely because not everything here depends on the developer. Partners are two big businesses, and in order to make any changes to the process, you need to put a lot of effort on all parties. Yes, working with bulk goods is still far from ideal and needs improvement. But the integrations have already been carried out, we are developing them and orders are coming to our clients. And I really hope most of them are happy.
In parallel, we are developing a completely new direction for us, which we consider promising.
Here we have an impressive range of tasks. Designing catalogs and placing data in a situation where we ourselves act as a marketplace that accepts goods, and give information about ourselves to third-party partners. There are powerful streams of data that need to be properly managed.
Globally, for VkusVilla, the priority task now is to optimize the delivery mechanisms for goods to the end customer. Our team is also involved in this process and is working on a geomodule that determines the most optimal route and delivery method for the shopping cart depending on the assortment.
This is a huge block of tasks, which includes working with coordinates, and optimizing routes, accounting for city traffic and calculating the optimal load on the delivery service. Which also need to be improved.
What other inner work would you like to read about?
