The story of how we made a product for integration with goods on 1C and couldn’t stop

Developing and launching a new product is always a risk. Will come in, will not go. It all depends on the capabilities (people, money), competencies, experience, and in general understanding, why do all this. Even the most detailed strategy can ultimately fail. The main thing is to understand what the real benefits of the product are, then the development process will go more confidently.

With this approach, in 2019 we came to the development of a turnkey solution for automating trading on marketplaces – RDV Market. Made it on the immortal 1C system. We know her inside and out, and we are convinced that from a business point of view, this is the most suitable option for launching a new project. But more on that later. For now, we’ll tell you how it all began and what it eventually led to. They drove.

What was at the very beginning

We started work in 2018. We were invited to integrate goods with the M. Video store. The work on the process began by building the OMS (order management system) architecture together with the developers and analysts of goods.

Our team acted as business consultants. We prescribed the technical specification for the customer’s project team, built an algorithm of actions, what should work and how. On the M.Video side, specialists were engaged in the preparation and uploading of product offers (feeds), and the orders themselves were received through API goods.

Of course, there were bugs. In the process of combat testing of the integration, we noticed that part of the orders systematically did not reach the marketplace, and the final payments did not reach the store. To understand the cause of the failure, we made adjustments to the OMS and modified the billing system together with the project analysts. As a result, the mistakes were fixed, and the workflow went more or less productive. But still, most of the operations had to be done manually, constantly rechecking each order so that the correct data was transmitted.

As a result, we came to the understanding that it is impossible to work in such a mode. It was necessary to move away from disparate business processes and manual intervention. Then the idea of ​​a ready-made solution appeared that would allow you to quickly bring the seller to the site, automating most of the work processes.

Why 1C?

So, M. Video was selling through goods, and we were closely dealing with the issue of packaging integration into a separate automated system. We didn’t think for a long time what we were going to do – we knew 1C what capabilities it had, so the solution was written down on it. She has very tangible advantages.

First, most companies work with typical configurations. Thus, it will be easier for them to start working with our solution, since everything will take place in their usual “habitat”. All operations in the general 1C window!

Secondly, the system is reliable. Its load level is sufficient for the work of large companies with the number of users> 1000. In 1C, you can easily organize and scale processes to suit the needs of the company.

Another important point, in addition to technical equipment, is that 1C operates in terms of business objects. This is only a plus for building workflows with marketplaces.

Yes, the interface itself cannot be called attractive. Do not expect cool screenshots from us 🙂 Here 1C does not change itself. But for us in this case, the most important thing is the system’s capabilities, its adaptability and flexibility.

Started work on RDV Market

We had a clear goal – to get a solution that is embedded in 1C and automates the trading processes on the marketplace. It’s simple.

What they were doing.

Step 1… We collected feedback from sellers of goods, who works on what accounting system. To do this, we made a mailing list in the database and found out that most of them have installed:

  • 1C: ERP;

  • 1C: Integrated automation;

  • 1C: Trade Management.

There was also 1C UNF (management of a small company), but since it has few functions for advanced automation of warehouse processes, they decided not to consider it yet. But, perhaps, we will come up with something with this configuration.

Step 2. We began to work out the functionality and roadmap of the first version of the product. The sprint version of development management was taken as a basis, with which we experimented on goods. And somewhere during the first half of the year the first release of the system was released.

The functionality of the first version included automatic unloading of the product range into the catalog (YML). Since, using the example of goods, we realized that with an increase in the number of goods, manual work with unloading is ineffective, a waste of time.

The plans were to launch 2 versions of the product. We took the idea of ​​1C about PROF AND CORP. Actually, the differences were appropriate – the CORP had broader functionality.

In addition to automatic unloading of feeds, in the first release of the program for PROF, automatic confirmation of orders was implemented. Before that, the seller could only manually go through all the orders. Yes, if he has only 10 of them, then there is no problem. But these are rare.

Also, in the first version, we came close to the implementation of functionality for automating the process of order picking and accounting for the shipment of goods.

The problem of delaying goods in the warehouse is quite common. If the shipment deadlines are violated, the seller’s account is blocked, respectively, the sales process is slowed down, and the company incurs losses. It was important for us to ensure that such situations were minimized, so we set up a single place of picking and shipment (storekeeper APM), thereby saving time for picking and sending orders.

What did you work on next, simultaneously closing bugs

Despite the fact that the first version at the initial stage solved some of the problems with manual intervention, mistakes and misunderstanding of “how to do it”, “is it necessary at all” naturally arose.

We understood that it was the seller who would work with the solution, not the developer or analyst. Therefore, we tried to simplify any processes as much as possible. A convenient system with a clear structure should have turned out: creating and loading a product feed, automatically receiving and confirming an order, sending for picking and shipping, further delivery of goods to the client and accounting for payment transactions and closing documents.

New bugs appeared during the workflow. For example, it took a long time to saw the financial module. Control of settlements was initially rather superficial, and a lot of things had to be done by hand. We wanted to link all financial transactions on marketplaces, so that the user can see in one place full information on payments made, sent certificates, and also make changes in a couple of clicks.

In addition, a large pool of work was done on the development of the functionality for updating the residues. We put it in the release for the future immediately after the end of the first integration with goods. We understood that there would be leftovers in warehouses and they needed to be sold.

The issue of working with the leftovers was quite acute. Let’s look at a simple example. The store sent 5 items ordered by customers to the storefront. But at this time 2 of the sent goods were already sold offline. Due to the fact that no one updated the leftovers on the marketplace showcase (only approximate data was displayed in the system), 5 products were sold from the marketplace, but in fact 3 products were processed, that is, the rest of the orders had to be canceled. And with this it is impossible to part.

An increase in order cancellations has a negative impact on the store’s operations, as account blocking may occur (as with shifts in the shipment date of orders). To date, the current version of RDV Market implements automatic updating of balances, which allows you to reduce or minimize the percentage of cancellations, without bringing it to a critical moment.

In the process of working on the project, an idea came up about the possibility of loading info models for a product range (characteristics). We wanted to create information models in 1C for each marketplace for all categories of goods, so that sellers could quickly prepare their catalogs and transfer them with a minimum of errors (ideally without) to the marketplace. But here, not everything is so simple with obtaining such content, so the idea is still hanging – we put it in the plan for the near future.

Not goods alone: ​​who we work with now

Goods has evolved, attracting more and more sellers. And we moved on – we wanted to partner with other popular marketplaces. Wildberries, Ozon and Beru (now Yandex.Market) were already active on the market. We started with the latter. And they started quite insolently confidently, immediately posting information about integration with Beru on your website. Although at that time there was no formal partnership yet. But since their API was publicly available, we managed to test everything and set up a full-fledged integration with the marketplace.

Then we were noticed by Wildberries, who came to us when they sold only according to the FBO model (sale from the marketplace warehouse). Not so long ago, there was a breakthrough on WB – it earned under the FBS scheme (sale from the seller’s warehouse). Here you can see how we set up work according to the new scheme in 1C.

A little later, Ozon joined us – a marketplace with a complex reserve system. The site works in such a way that the goods are reserved as soon as the buyer places an order. Let’s say the client entered the card details incorrectly, in order to correct everything and pay for the purchase, he is given 30 minutes.

Everything seems to be ok. But the fact is that if the seller works with several sales channels when the season is high in demand, and let’s say there are not so many leftovers in the warehouse, then with the flow of orders, the marketplace manager can send this order to another customer. And there will be a cancellation. We have set up the system so that such losses can be avoided – the history of reserves is saved online, they are formed before the order is created, and the seller does not exceed the cancellation threshold.

We work with Wildberries, Ozon, Ya.Market, goods, and recently connected AliExpress
We work with Wildberries, Ozon, Ya.Market, goods, and recently connected AliExpress

Click hereto find out in more detail what and how it works in RDV Market.


What’s next? There are many ideas. For example, we want to launch a solution by one click on a button to reduce the number of steps in the settings. We are also looking towards the implementation of a mobile application and product rebranding.

In general, we are working.

We are ready to answer your questions, tell you more about the functionality – welcome to RDV Market!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *