«ПроАптека» — один из крупнейших маркетинговых союзов независимых аптек и сетей в России и наш давний клиент, для которого мы уже создавали крупный проект. 

Недавно у заказчика появилась идея нового сервиса, с которой он снова пришел к нам в студию. Новый проект — платформа «ПроАптека», где производители фармацевтических препаратов могут создавать особые промоактивности для стимулирования закупок и продаж в аптечных сетях-партнерах «ПроАптеки».

Нашей задачей было реализовать механизм работы с промоактивностями для обеих сторон: чтобы производители могли сами создавать подобные промо внутри системы, а аптеки — могли в них участвовать.

Для начала мы провели аналитику и построили CJM — карту путешествий конечного пользователя. Это помогло определиться с функциональностью сервиса, а также со всем, что потребуется для его создания: от ролей и разделов внутри личного кабинета до необходимой информации из базы данных. Позже на основе аналитики мы собрали прототипы, чтобы наглядно проверить юзабилити на всем пути пользователя до того, как приступать к дизайну.

Основное пространство сервиса — личный кабинет, где производители могут создавать промоактивности для аптек, вести расчеты с ними и видеть всю финансовую информацию.

Для входа в личный кабинет нужна авторизация, но не простая, а через систему сквозной идентификации и аутентификации. Выбор продиктован безопасностью данных: логины и пароли пользователей не хранятся на сервере сервиса — мы используем существующие учетные записи, фактически не имея к ним доступа. Данные аккаунтов производителей и всех аптек при этом хранятся в защищенной базе данных на отдельном сервере.

После авторизации пользователь попадает в личный кабинет в зависимости от своей роли: это либо кабинет производителя и поставщика препаратов, либо — кабинет аптечной сети. Естественно, кабинеты отличаются по функционалу.

Чтобы создавать промомероприятия в своем личном кабинете, производителю нужно сначала добавить туда конкретные товары — которые будут участвовать в этих самых промо. Для этого мы предусмотрели две вкладки:

• Справочник. Здесь хранятся все товары экосистемы — то есть вообще все товары всех аптек и всех производителей из базы данных «ПроАптеки». Товары из справочника — своего рода базовые (какие бывают в мастер-каталоге на типичном маркетплейсе). 
• Мои товары. Копии товаров из справочника, которые производитель фармпрепаратов определил как «свои»: чтобы те могли участвовать в промо, их нужно добавить в этот каталог вручную. Для быстрого добавления мы предусмотрели поиск и фильтры по категории препарата и его производителю.

Когда производитель собрал свой каталог товаров, он может приступить к пошаговому созданию промо:

Шаг 1. Задать общую информацию и условия промо:

• дата начала и окончания;
• тип промо: закупка (аптеки покупают препараты в запас на склад) или продажа (аптеки стараются реализовать препараты конечному покупателю);
• название и описание.

Шаг 3. Рассчитать бюджет промоактивности
Для этого из списка нужно выбрать аптеки, которые смогут участвовать в промо от производителя.

Система автоматически рассчитывает плановый бюджет промо в зависимости от количества участвующих аптек, количества товаров и вознаграждения за продажу каждой. Бюджет также включает комиссию сервиса.

Потенциальный бюджет важен, поскольку при создании промо ее потенциальный бюджет должен укладываться в свободные средства производителя на номинальном счете — о нем мы еще поговорим подробнее.

В своем личном кабинете аптеки видят только те промоактивности, в которых могут участвовать. Причем поучаствовать в промо аптека может в любой момент с даты старта и до окончания промо: если условия ей подходят, она может попытаться продать условный парацетамол в нужном количестве и в итоге либо получить вознаграждение от производителя при выполнении условий, либо нет. Важно: продажи и закупки учитываются только с момента старта участия в промо.

Промомероприятий от производителей в кабинете аптеки может быть множество, поэтому мы предусмотрели удобные фильтры по времени проведения, типу промо, бренду производителя и категории товара.

Самая сложная часть промомероприятий — это расчеты внутри системы. Для этого в личном кабинете производителя есть раздел «Финансы»: внутри можно просматривать историю операций и отслеживать баланс своего номинального счета на платформе «ПроАптека».

Номинальный счет — счет, который фактически не принадлежит ни одному из производителей. Но, отправляя туда деньги, каждый производитель становится бенефициаром и владеет частью средств на этом счете (они зачислятся на баланс производителя в его ЛК на площадке «ПроАптека»). Сумму с этого счета можно использовать для создания промо и перечисления вознаграждений аптекам.

При создании промо автоматически проверяется, соответствует ли бюджет промоактивности балансу производителя на номинальном счете. Если да, после создания промо автоматически активируется смарт-контракт в банке, который замораживает деньги для бюджетирования промо на номинальном счёте.

Баланс в личном кабинете уменьшается на сумму зарезервированных средств, а в разделе «Финансы» производитель может увидеть, сколько и каких средств зарезервировано под разные промоактивности.

Промо в момент создания вместе со списком всех аптек, которые могут в нем участвовать, отправляется заказчику в базу данных. Туда же попадают факты продаж аптек. Мы же периодически синхронизируем эти товародвижения в базе данных с нашим сервисом. Это позволяет производителю видеть внутри своего личного кабинета, какие аптеки и сколько товаров из промо продали.

Когда промоактивность завершается, она переходит в режим согласования итогов — искусственный тайм-аут, чтобы в личный кабинет подтянулись неучтенные продажи. После него в карточке промо появляется кнопка «акцептовать». Если производитель согласен с итоговой суммой продаж в рамках промо, он акцептует ее, если нет — может оспорить.

Основная задача акцептования — снизить бюрократические издержки в расчетах между производителем и аптеками. Если производитель акцептует промоактивность, то система автоматически создает УПД (Универсальный передаточный документ) и отчёт агента. УПД даёт право списать комиссию, а отчёт агента показывает, какая аптека сколько продала или выкупила и сколько ей нужно заплатить.

Как только документы подписаны с обеих сторон, промо автоматически переводится на следующий этап — период выплат. И мы снова возвращаемся к номинальному счету производителя:

• часть средств оттуда списывается автоматически как комиссия площадки «ПроАптека» и уходит ее на расчетный счет;
• сама промоактивность переводится в статус «период выплат».

В этот момент также автоматически создается протокол премирования на каждое юрлицо (аптечную сеть) на столько денег, сколько аптека заработала во время промо. Все эти протоколы также отправляются в «ПроАптеку» через ЭДО, а затем — аптекам, которые их подписывают. 

А дальше начинается самое интересное — чтобы не гонять деньги на номинальных счетах аптек и производителей туда-сюда, мы просто меняем бенефициара. Например, у производителя на номинальном счете был баланс ₽₽₽₽₽:

• ₽ — часть от этих денег он перевел «ПроАптеке» как комиссию,
• ₽₽ — часть от этих денег он должен перевести одной аптеке как вознаграждение,
• ₽₽₽ — еще часть он должен перевести другой аптеке как вознаграждение. 

Соответственно мы просто «отщипываем» причитающуюся каждой аптеке часть денег со счета производителя и меняем у нее бенефициара — таким образом деньги появляются на счетах аптек, при этом физически никуда не переводятся, а просто меняют владельца. Аптеки могут вывести полученные деньги с номинального счета на расчётный.

Этот сервис — один из самых интегрированных проектов студии: тут и система сквозной авторизации, и база данных «ПроАптеки», и ЭДО, и смарт-контракты — и всё это работает одновременно как единое целое.

Другая особенность проекта в том, что все операции, которые вносят какие-то изменения на стороне интеграции со смарт-контрактами, должны быть подписаны криптографической печатью. А это автоматически означает, что на проекте появляются электронные цифровые подписи, криптопровайдер КриптПро для подписания данных этими подписями, ГОСТ на шифрование подписей и не только.

Изначально по просьбе заказчика мы реализовали подписание всех документов между платформой, производителями и аптеками в автоматическом режиме. При этом ключ шифрования электронной подписи хранился на сервере заказчика.

Сервис «ПроАптеки» оперирует довольно чувствительным и персональными данными, поэтому стандартный деплой (перенос данных с сервера разработки на основной сервер проекта) нам не подходил: из соображений безопасности мы вообще не должны иметь доступа к серверу заказчика. А для стандартного деплоя необходимы, как минимум:

• наличие SSH-доступа к рабочему серверу,
• возможность устанавливать и обновлять пакеты на этом сервере,
• возможность настраивать окружение (версии языков, библиотек, веб-сервера).

Поэтому мы приняли решение использовать Docker-контейнеры и Portainer. Вот как это работает:

Когда разработчик что-то меняет в коде локально у себя, он может «завернуть» результат этих работ в Docker-образ — специальный «слепок», содержащий код и всё необходимое для его запуска (что-то вроде виртуального компакт-диска). Этот образ публикуется в специальном репозитории — Docker-реестре, к которому также имеет доступ «ПроАптека».

У «ПроАптеки» на сервере развернут специальный веб-интерфейс — Portainer. Он позволяет управлять Docker-контейнерами — запущенными экземплярами Docker-образов на сервере.

Когда по какой-то причине нужно обновить уже работающий Docker-контейнер (который лежит на сервере «ПроАптеки»), администратор через Portainer выбирает новый образ из реестра (который написал и положил туда разработчик) и нажимает кнопку обновления. Portainer автоматически останавливает старый контейнер и удаляет его, а после создаёт и запускает новый контейнер из нового образа. Вуаля — обновления установлены!