Development of a B2B wholesale store of medicines and proper integration into the customer’s ecosystem

B2B wholesalers are a separate well-established type of web projects, but very heterogeneous. Each such site is unique and requires an individual approach. INTERVOLGA’s experience allows us to boldly undertake such projects. This article is about a B2B platform developed by us for wholesale orders of medicines for a large pharmaceutical company (hereinafter “FC”).


FC has been developing the Russian pharmaceutical market since 2002. The company cooperates with pharmaceutical distributors, wholesalers, large regional pharmacy chains in 82 regions of Russia. The company cooperates with 48,000 pharmacies and pharmacy chains. The company has 45 sales offices and about 1,500 employees.


The goal of the new project is to simplify the procedure for ordering medicines from FC for pharmacies. At the same time, the opportunity to develop the project to a marketplace was kept in mind in order to present the products of different distributors, but to highlight the priority products in design and functionally. For example, before placing an order, offer the buyer to select the drugs from his basket with analogues from “FC”.

Internal automation and digitalization of FC is at a high level and is developing: in recent years, we have jointly created and developed projects for FC, the Single Authorization Cabinet (ESA) and the Claims Cabinet. The new project was supposed to organically fit into this ecosystem (authorization through ESA, seamless transition between all sites).

Development of

We started working with technical specifications, layouts and design. In parallel with INTERVOLGA, FC had another contractor for the development of an accounting system (CS), which played the role of an “integration bus” (when developing a complex website without it anywhere), which wrote its own (independent) technical specification, but there was also a significant integration part between Bitrix and US.

This stage took us 4 months. An urgent question: was it possible to cope faster, without technical specifications and work on agile? Perhaps yes. There were all the conditions for this: the team (and the customer is its active participant), atmosphere, dialogue and tools. But in 2019, it seemed too risky for the pharmaceutical industry. “Well, how is it possible without technical specification?” – a question that still haunts many CEOs, despite the scattering of positive examples of agile development of large web projects (and examples of waterfall development when they did not hit the deadline / budget).

Further development took six months with interruptions: in parallel with the B2B platform, the creation of the Unified Authorization Cabinet was going on, without which we could not start.

From a development point of view, this project turned out to be interesting with the following features:

  • many integrations;

  • hybrid technology React + 1C Bitrix;

  • increased control of data from the control system;

  • personal prices;

  • customization of the site’s appearance for each user.


In this project, a site based on 1C-Bitrix is ​​integrated with 3 systems:

  1. Intermediate database based on MSSQL (hereinafter PBD) with data on pharmacy chains and consignees. This PBG is built on the basis of data filled in manually by pharmacy employees – as a result, there are a lot of typos, confused fields and errors. For example, a pharmacy with a TIN equal to “DON’T KNOW” can easily be caught, and five numbers separated by commas could be entered in the “Phone” field.

  2. Unified Authorization Cabinet (hereinafter ESA). The customer has many partners with different levels of access and only this separate service knows everything about everyone. If you want to enter your B2B personal account, first go to ESA. This two-level structure has a downside, a useful side – if you are actively working with other FC projects, the entrance to your B2B personal account will happen automatically (in the style of Google).

  3. An accounting system based on Spring (hereinafter referred to as Spring), which “manages” goods, prices and balances. It is Spring that plays the role of an integration bus, collecting data from different accounting systems of all suppliers, unifying it for the site and sending back orders.

The general scheme of integration is shown in the diagram below.

Our other team on the previous project for FC was already familiar with the structure of the PBB, the transfer of experience and code between the developers went smoothly 🙂

At the time of the start of the development of the project, ESA was only in the project. In a project that did not even have a technical specification, so we had to bypass the issue of user authorization in a roundabout way, so as not to redo the work later. After the release of ESA, three days later (we almost did not have to change anything on the site), end-to-end authorization started working on the B2B platform.

Spring already had a basic REST API, it was modified for us (another contractor was engaged in the accounting system). OK accessed the API in two cases: on a schedule (full times a day, partial times an hour) and on request (clarified balances and prices before placing an order, requested current price lists when the user entered the site).

Hybrid site React + 1C-Bitrix

In this project, we “made friends” of BUS and react-components (even before it became mainstream). React was needed on the main page in the product table.

The requirements for this table were really tricky:

  • On mobile devices, it should turn into a list of cards

  • It can be filtered, sorted, there should be page-by-page navigation – but it is everywhere

  • It should be customizable by each user for himself – some need some columns, others need others.

  • Color differentiation of pants – if the product is already in the user’s cart – one line color. If the product is from your favorite supplier, it is different. If you can’t buy a third one.

  • Some of the data is always on the server, and some must be requested in real time from Spring.

The result is predictable:

  • The development of such a table took 2-3 times more time than with “traditional” JS.

  • The front-end developer is comfortable making edits.

  • A backend developer only needs to create a REST API to receive goods – without thinking about the interface and appearance.

Data control

With such a long chain (vendor ID – Spring – Bitrix) and delays in the transmission of information, trust the data 100%.

Accordingly, at any moment of time on our site there may be goods for which the “minimum purchase quantity” is greater than the “stock balance”, and the “stock balance” is less than the “multiplicity”. To avoid such problems, the site has developed a system for checking the basket for inconsistencies.

Error type

What to withdraw

How to calculate the recommended amount


Available quantity is not taken into account

Quantity available to order

= Quantity available to order

Ordered: 5

Quantity available for order: 2

Recommended: 2

Multiplicity not taken into account


= The current quantity, rounded up in multiples.

Ordered: 10

Multiplicity: 3

Recommended: 12

Minimum order quantity not included

Minimum order quantity

= Minimum order quantity

Ordered: 2

Minimum order quantity: 5

Recommended: 5

Fragment of the technical specification with checking the basket for errors and a proposal for correction.

Error in ordering in b2b online store
Error in ordering in b2b online store

Personal prices

The current business model assumes that each supplier “comes” to the site with its own price list, which is individual for each pharmacy chain. And this means that we had to solve one of the common tasks of wholesale LC: personal pricing.

Usually we find a borderline solution – we group all customers into a couple of dozen levels of the loyalty program and unload from the US, respectively, a couple of dozen prices for each product. But here the case was obviously different: the US stores thousands of prices for each product.

In order not to upload millions of records to the site and not to try to keep the entire catalog up-to-date, we switched to the “request for quotations from the US in real time” model.

When a user visits the site to place an order, we preload prices from the US for what he sees and a little ahead of time. Prices and balances are cached on the site for several hours. This creates a substantial load on the network and the network, but this problem can be solved (optimization of the network, new hardware, expansion of the Internet channel).

Website appearance customization

This is something from product development. We have not yet had a chance to create a website for a customer where the user could choose a background, but this was one of the requirements of the TK. It turned out: nothing complicated, most of all the work was put into this task by the front-end developer.


The site was launched in 2021 and already brings at least 200 wholesale orders per month. One developer is engaged in the project on a permanent basis, sometimes we involve additional forces. The project has reached its optimal “plateau”: with minimal support costs from the customer, it receives a stable flow of orders. The next move for business: attracting new customers and new suppliers to turn a B2B site into a marketplace.

This project is not the only big project for FC. We have developed a website for a network of pharmacies, a personal account of a loyalty program participant, we are developing a corporate portal and are engaged in other, still secret projects.

Similar Posts

Leave a Reply

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