Маркетплейс. Хочешь сделать хорошо — напиши сам

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

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

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

Я хотел создать экосистему и объединить на своей площадке уже существующие на рынке продукты: 3PL-логистику, банкинг и систему ЭДО. При этом я видел маркетплейс максимально простым, то есть не перегруженным лишним функционалом. Вот основные задачи, которые я ставил перед разработчиками:

Я преследовал цель — уйти от человеческого фактора и «менеджеров на телефоне».

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

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

При этом не передавать оплату поставщику до отгрузки товара покупателю.

Все взаимодействия с участниками маркетплейса на старте — банком, поставщиками, транспортной компанией и компанией ЭДО — мы осуществляли по API. Для нас все, что передается по API, истина. Но без трудностей здесь не обошлось. С чем столкнулась команда при решении этих задач, и как в итоге их решила, расскажу далее.

Для организации ЭДО на площадке мы рассматривали несколько подрядчиков. Но оказалось, что все они берут не маленькие деньги, за то, что люди принимают и отправляют документы на их ресурсе. При этом ответственности никакой не несут. Поэтому мы организовали электронный документооборот на площадке своими силами, т.е. сделали так, чтобы пользователи не покидали личный кабинет для того, чтобы оформить и подписать ЭЦП какой-либо документ.

По цифровой подписи мы взаимодействуем с КриптоПро. Свой маркетплейс мы писали на Django. Так как этот фреймворк на языке программирования Python, а у разработчиков КриптоПро нет никакой поддержки этого языка, возник вопрос, как работать с инструментами электронной подписи и, собственно, подписывать документы на площадке. В результате мы написали библиотеку, которая позволяет подписывать документы, не заходя каждый раз в их приложение.

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

С одной стороны, у 1С есть модуль со своими полями, который позволяет вносить больше информации о товарах. Но особенность 1С в том, что каждая ее версия уникальна и этот дополнительный модуль пришлось бы переписывать под каждую их них. Поддерживать это все было бы очень сложно, потому что все наши поставщики очень разные: кто-то использует старую версию 1С, кто-то новую, а кто-то вообще не использует эту программу.

Мы нашли универсальное решение, которое работает на каждой версии 1С. Мы выгружаем только цены и остатки по существующему стандартному методу 1С. А дополнительную информацию о товаре в каталог маркетплейса поставщики могут добавить вручную с помощью нашего интерфейса.

Для расчета срока доставки конкретного товара с конкретного склада нам нужно было знать координаты этого склада. Но транспортная компания по части складов передавала по API не полные координаты: только долготу или только широту, — что делало расчет сроков доставки невозможным. В итоге, наш разработчик сам «починил» код логистической компании, чтобы мы смогли получать координаты полностью.

У транспортной компании была проблема с записью городов в системе. У них была своя система кодификации городов и складов в них. Поскольку они не использовали КЛАДР-код, мы не могли синхронизировать адреса складов транспортной компании с городами на сайте маркетплейса. Наш программист взял весь список городов, которые использует транспортная компания и с нуля переписал под нашу площадку на нашей стороне.

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

Транспортная компания рассчитывала срок доставки сформированного заказа (полной корзины с конкретного склада). Это значит, что в рамках API рассматривала задачу так: человек что-то хочет перевезти из пункта А в пункт Б и ему нужно посчитать, сколько это будет стоить. Нам этот алгоритм расчета не подходил, потому что на маркетплейсе в одном заказе покупателя может быть товар от разных поставщиков, который находится на разных складах в разных частях страны. Я хотел, чтобы покупатель видел, сколько времени будет ехать единица заказанного им товара из конкретного склада, т.е. рассчитывать срок доставки в фоновом режиме по каждой позиции в корзине. Это значит, что единовременно нам нужно просчитывать тысячи значений сроков. Это десятки тысяч запросов в секунду. Для транспортной компании такой вариант был неприемлем, поэтому ее программисты разработали для нас решение, в рамках которого от нас поступал один запрос с массивом данных, которые нужно было просчитать.

В итоге мы ушли от взаимодействия по API с транспортной компанией, а разработали отдельный программный продукт.

По условиям маркетплейса поставщик получает свои деньги только после отгрузки товара покупателю. При этом, как я уже говорил, в корзине покупателя может находиться товар от нескольких поставщиков. Нам нужен был банк, который сможет разделить платеж клиента между разными поставщиками после того, как клиент получит свой товар и а мы — свою комиссию. Оказалось, что у всех банков единая API-структура. Все они используют одно типовое, достаточно старое, решение, которое нам не подходило. Все, кроме Сбера. Только этот банк смог обеспечить нам разделение платежа клиента между поставщиками, так, как нужно нам.

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

На сегодня продукт уже прошел тестирование на реальных клиентах и поставщиках и полностью готов к запуску. У маркетплейса простой и интуитивно понятный интерфейс. Конечно, мы будем дописывать его в процессе и улучшать, делать еще проще и удобнее. Но все задачи, которые мы себе ставили, мы решили.