B2B-маркетплейс для мебельных производителей: SOLOMA
Как создать маркетплейс с нуля по SCRUM, если на старте есть только идея
B2B-маркетплейс для мебельных производителей: SOLOMA
Как создать маркетплейс с нуля по SCRUM, если на старте есть только идея
Маркетплейсы считаются логичным этапом эволюции любого крупного е-коммерса, несмотря на все свои теневые стороны и неочевидные сложности. Запросы на разработку таких проектов мы получаем регулярно, но после детального разговора на старте большинство заказчиков от первоначальной идеи отказываются. Большинство, но не все.
Тот, у кого хватает амбиций, смелости и уверенности в будущем успехе, идет до конца. Например, наш заказчик «ФомЛайн», который пришел к нам с идеей B2B-маркетплейса для мебельных производителей, а ушел — с готовым проектом (на самом деле не ушел, потому что планов еще на год вперед).
О том, как мы создавали этот масштабный проект с нуля, имея в основе лишь идею и пачку неопределенностей — рассказываем в кейсе.
Тот, у кого хватает амбиций, смелости и уверенности в будущем успехе, идет до конца. Например, наш заказчик «ФомЛайн», который пришел к нам с идеей B2B-маркетплейса для мебельных производителей, а ушел — с готовым проектом (на самом деле не ушел, потому что планов еще на год вперед).
О том, как мы создавали этот масштабный проект с нуля, имея в основе лишь идею и пачку неопределенностей — рассказываем в кейсе.
- «ФомЛайн» — один из крупнейших производителей эластичного пенополиуретана, который используется для производства матрасов и мягкой мебели. С 1992 года, что компания на рынке, она обзавелась 9 заводами в России, Казахстане и Узбекистане. Производственная сеть также включает 10+ технических лабораторий, собственный исследовательский центр и 3 резательных центра. Компания производит больше 102 тыс. тонн пенополиуретана в год, а теперь также мебельный клей и независимые пружинные блоки.
SCRUM против неопределенности
Заказчик пришел к нам с идеей — создать маркетплейс мебельных комплектующих, где поставщики смогут размещать свою продукцию, а покупатели — делать оптовые заказы разных категорий продукции на одной площадке.
Денис Фатеркин
Начальник отдела электронной коммерции компании «ФомЛайн»
— За долгие годы общения с производителями мебели мы досконально изучили их потребности и научились оперативно адаптироваться к меняющемуся спросу на комплектующие. Именно поэтому и приняли решение о запуске В2В-маркетплейса (источник).
Готовой бизнес-модели на старте проекта у заказчика не было. Зато было много вопросов:
- неясно, как будет устроена загрузка товаров в каталог: какими будут категории, товары от поставщиков и в каком количестве их будут добавлять;
- неясно, где будут храниться данные о товарах и как проводить их модерацию;
- на рынке нет готового решения, как встроить каталог от произвольного поставщика в каталог маркетплейса — даже крупные площадки не смогли решить эту задачу никак, кроме унификации файлов выгрузок;
- неясно, как будут устроены оплаты на маркетплейсе, кто будет заниматься доставкой и что делать с возвратами;
- неясно, что делать с бухгалтерскими документами и налогами;
- плюс множество других вопросов вроде монетизации проекта и привлечения поставщиков на площадку.
Полина
Руководитель проекта
— Всё это звучало, как вызов. Чтобы размотать клубок противоречий и реализовать проект в адекватные сроки, мы решили работать по чистому SCRUM с самого старта — действовали итеративно, уточняя требования на каждом новом этапе.
У заказчика был дедлайн, к которому нужно было реализовать минимально жизнеспособную версию проекта — MVP. Фич было очень много, поэтому первое, что сделали — определились с составом MVP.
У заказчика был дедлайн, к которому нужно было реализовать минимально жизнеспособную версию проекта — MVP. Фич было очень много, поэтому первое, что сделали — определились с составом MVP.
Работа итерациями и пошаговый запуск
Первое, с чем нам предстояло определиться для разработки MVP — структура каталога, какими будут данные по товарам и какое выбрать место их хранения. Каталог в админ-панели и интеграцию с мастер-системой хранения товаров собрали в первых спринтах (временных отрезках не более месяца, за которые команда создает функционирующую версию продукта). Дальше — приступили к выводу данных в каталоге и личному кабинету поставщика.
Полина
Руководитель проекта
— Особенность проекта в том, что после сдачи каждого этапа работ заказчику мы обновляли текущую версию сайта для пользователей, добавляя туда готовый функционал.
У заказчика высокие требования к безопасности — из-за этого было условие: перенос с нашего тестового сервера на сервер заказчика должны выполнять специалисты «ФомЛайн».
Контур оказался непростым: мы обкатывали его пару месяцев.
У заказчика высокие требования к безопасности — из-за этого было условие: перенос с нашего тестового сервера на сервер заказчика должны выполнять специалисты «ФомЛайн».
Контур оказался непростым: мы обкатывали его пару месяцев.
У «ФомЛайн» полностью своя IT-инфраструктура, которую они самостоятельно поддерживают «от» и «до». Чаще бывает иначе: заказчики советуются с нами, какой тариф у какого хостера взять, а все настройки мы берем на себя.
В нашем случае заказчик не планировал пускать нас внутрь своей инфраструктуры. Но было важно настроить сервер под проект так, как нужно для эффективной работы сайта: чтобы внутри были корректные версии необходимых сервисов, и всё было настроено и оптимизировано под параметры проекта.
При этом заказчик хотел иметь возможность просто и быстро развернуть у себя дополнительную копию сайта для тестирования или других задач, чтобы не приходилось ради этого обращаться к нам для повторной настройки отдельного сервера.
В нашем случае заказчик не планировал пускать нас внутрь своей инфраструктуры. Но было важно настроить сервер под проект так, как нужно для эффективной работы сайта: чтобы внутри были корректные версии необходимых сервисов, и всё было настроено и оптимизировано под параметры проекта.
При этом заказчик хотел иметь возможность просто и быстро развернуть у себя дополнительную копию сайта для тестирования или других задач, чтобы не приходилось ради этого обращаться к нам для повторной настройки отдельного сервера.
Иван
Технический директор
— Как дать заказчику возможность быстро сделать отдельную копию сайта, не имея доступа к серверу? Либо использовать какую-либо из систем управления конфигурациями, либо отдавать заказчику готовый программный код в контейнерах (с помощью Docker-ов). Мы выбрали первое.
Созвонились со специалистами заказчика, обсудили. Выяснили, что для управления серверами они используют систему управления конфигурациями под названием Ansible. Она позволяет в виде текстового файла конфигурации описывать, какие действия в каком порядке нужно произвести с сервером, какие программы установить, в каких программах какие настройки должны быть выставлены, чтобы полностью настроить сервер. Решили работать с ней.
Начали с базовой конфигурации для Ansible, отдали её заказчику вместе с кодом сайта, чтобы проверить работоспособность — специалисты «ФомЛайн» запустили конфигурацию, настроили сервер и развернули код — всё, пусть и не сразу, но заработало.
Созвонились со специалистами заказчика, обсудили. Выяснили, что для управления серверами они используют систему управления конфигурациями под названием Ansible. Она позволяет в виде текстового файла конфигурации описывать, какие действия в каком порядке нужно произвести с сервером, какие программы установить, в каких программах какие настройки должны быть выставлены, чтобы полностью настроить сервер. Решили работать с ней.
Начали с базовой конфигурации для Ansible, отдали её заказчику вместе с кодом сайта, чтобы проверить работоспособность — специалисты «ФомЛайн» запустили конфигурацию, настроили сервер и развернули код — всё, пусть и не сразу, но заработало.
Первое время возникали сложности: например, при подключении ElasticSearch некоторые настройки не работали на тестовом сервере заказчика или терялась часть настроек из конфигураций — из-за этого уходило время на отладку и поиск узких мест. Спустя несколько повторов процесс обкатали — и теперь проблем не возникает.
Иван
Технический директор
— В ходе разработки следующих спринтов, у нас менялись и дополнялись требования к серверу и списку сервисов на нём. Но внести изменения было просто — мы меняли уже существующую конфигурацию Ansible и отдавали её заказчику вместе с кодом спринтов.
Ansible сделан так, что повторный запуск конфигурации не ломает сервер и не стирает на нём никакие данные, а приводит текущее состояние сервера в соответствие тому, что описано в конфигурации, просто донастраивает его.
Ansible сделан так, что повторный запуск конфигурации не ломает сервер и не стирает на нём никакие данные, а приводит текущее состояние сервера в соответствие тому, что описано в конфигурации, просто донастраивает его.
Аналитика и ТЗ
Каждый проект мы начинаем с этапа агрегации требований. Обычно на этом этапе мы используем метод целевых персон, чтобы выявить ключевой для пользователей функционал, и пристально смотрим на конкурентное окружение, чтобы от него отстроиться.
В этом проекте пошли нестандартным путем — дополнительно продумывали CJM (Customer Journey Map — карта пути клиента), разрабатывая путь пользователя по сайту на основе опыта крупных маркетплейсов вроде Ozon или СберМегаМаркета.
В этом проекте пошли нестандартным путем — дополнительно продумывали CJM (Customer Journey Map — карта пути клиента), разрабатывая путь пользователя по сайту на основе опыта крупных маркетплейсов вроде Ozon или СберМегаМаркета.
Фрагмент аналитики с CJM
Позже эти данные помогли определиться со структурой сайта и написать техническое задание на разработку. Точнее — набор бэклогов на спринты, согласно идеалогии SCRUM.
Анастасия
QA-аналитик
— На старте была лишь идея и пожелания от заказчика, но никакой формализованной логики работы проекта ещё не было. Поэтому ТЗ мы писали итерациями — к каждому спринту своё. Каждое ТЗ описывало часть функционала сайта, а в финальном ТЗ мы собрали все, что добавилось по ходу разработки проекта и что мы отложили на предыдущих этапах.
Там, где были сложности, мы созванивались с заказчиком и разбирали вместе с нашими разработчиками, что и как должно работать.
Там, где были сложности, мы созванивались с заказчиком и разбирали вместе с нашими разработчиками, что и как должно работать.
Но ещё до начала разработки бэклога на первый спринт мы поработали над прототипами ключевых страниц.
Полина
Руководитель проекта
— На прототипах особое внимание нужно было уделить каталогу и личному кабинету поставщика. Каталог проектировали на основе данных о товарах заказчика и нескольких партнеров-производителей. На этом этапе мы лишь предполагали, какие товары будут продаваться на маркетплейсе, и на основе аналитики делали выводы, что выводить в карточке и на детальной странице товара. В итоге — предположили верно :)
Дизайн
Перед стартом разработки дизайн-концепции у нас уже было довольно четкий запрос от заказчика: дизайн должен быть легкий, светлый, без использования «ядовитых цветов», основной референс тоже был — СберМегаМаркет.
Евгений
Арт-директор
— Изначально проект планировался под названием заказчика — «ФомЛайн», но на звонке клиент сказал, что у них появилось новое название SOLOMA. Солома — отсылка к природному материалу, которым когда-то набивали первые матрасы. Заказчик также обозначил и палитру «канадская осень» — теплую, яркую и природную.
Так появилась идея использовать на главной странице сайта образы крафтовых мастеров в красных клетчатых рубашках (как отсылка к канадским лесорубам) — на демо дизайна заказчик сказал, что мы попали точно в цель.
С внутренними страницами нам дали полную свободу — они получились четкими и опрятными. А сам проект — теплым, но при этом технологичным.
Так появилась идея использовать на главной странице сайта образы крафтовых мастеров в красных клетчатых рубашках (как отсылка к канадским лесорубам) — на демо дизайна заказчик сказал, что мы попали точно в цель.
С внутренними страницами нам дали полную свободу — они получились четкими и опрятными. А сам проект — теплым, но при этом технологичным.
Полина
Руководитель проекта
— В дизайне мы сделали акцент на яркие баннеры, чтобы в дальнейшем у заказчика была возможность анонсировать в промо-блоках товары поставщиков и использовать их как рекламное место.
Эталонный каталог и протокол интеграции
На крупных маркетплейсах часто встречается практика, где в каталоге каждое предложение от поставщика — это отдельная карточка товара. Из-за этого в выдаче могут быть сотни одинаковых товаров, которые отличаются лишь ценой, данными о продавце и, возможно, фотографией. При такой схеме поставщикам приходится тратить много времени и сил на формирование собственных карточек: вручную добавлять фото, описания и все характеристики.
Нам хотелось максимально упростить и ускорить этот процесс, поэтому на проекте каталог устроен иначе — внутри есть мастер-товары, для которых поставщикам достаточно создать свои торговые предложения без необходимости заполнять характеристики, описание и загружать фотографии. Это удобно и пользователю — поскольку к одной карточке товара могут присоединиться несколько поставщиков, он сразу, на странице товара, может выбрать лучшее предложение.
Нам хотелось максимально упростить и ускорить этот процесс, поэтому на проекте каталог устроен иначе — внутри есть мастер-товары, для которых поставщикам достаточно создать свои торговые предложения без необходимости заполнять характеристики, описание и загружать фотографии. Это удобно и пользователю — поскольку к одной карточке товара могут присоединиться несколько поставщиков, он сразу, на странице товара, может выбрать лучшее предложение.
Полина
Руководитель проекта
— Ещё на старте проекта мы задавались вопросом о том, как будет устроен каталог и где будут храниться данные о самих товарах. Когда приступили к проработке каталога, вопрос о том, где хранить мастер-товары, оставался открытым.
Заказчик изначально склонялся к использованию PIM-системы — системы, которая позволяет хранить большой объем данных и управлять им, а также умеет выгружать данные в разных форматах под запросы разных систем.
После нескольких детальных обсуждений всех плюсов и минусов этого решения мы договорились использовать PIM-систему PIMCore для хранения данных. Чтобы отладить интеграцию с ней в процессе, помимо заказчика, участвовали специалисты KT-Team, интегратора Pimcore.
Заказчик изначально склонялся к использованию PIM-системы — системы, которая позволяет хранить большой объем данных и управлять им, а также умеет выгружать данные в разных форматах под запросы разных систем.
После нескольких детальных обсуждений всех плюсов и минусов этого решения мы договорились использовать PIM-систему PIMCore для хранения данных. Чтобы отладить интеграцию с ней в процессе, помимо заказчика, участвовали специалисты KT-Team, интегратора Pimcore.
Леонид
Разработчик
— PIM-системы на проектах, конечно, — явление редкое, но при должной проработке нет особых сложностей. Для нас это просто система заказчика, в которой он заполняет данные о своём каталоге — по факту, это мастер-система. В ней уже определена иерархия каталога, товары, их свойства, есть различные справочники.
За счет использования PIM-системы мы максимально упрощаем процесс работы с каталогом: маркетплейс формирует основную номенклатуру, а поставщики подключаются со своими предложениями по данной номенклатуре, просто указывая цену, остатки, упаковку и стоимость доставки.
За счет использования PIM-системы мы максимально упрощаем процесс работы с каталогом: маркетплейс формирует основную номенклатуру, а поставщики подключаются со своими предложениями по данной номенклатуре, просто указывая цену, остатки, упаковку и стоимость доставки.
Чтобы получить данные из Pimcore для сайта, мы использовали шину сообщений от Apache Kafka — это брокер сообщений между разными системами, который позволяет нескольким системам обмениваться данными через общий набор интерфейсов в режиме реального времени.
Kafka отдает нам данные в виде объектов — мы их парсим (автоматически собираем и структурируем с помощью отдельного сервиса), раскладываем по табличкам внутри сайта и используем. Дополнительно мы написали парсер схемы данных, который учитывает различные типы свойств, представленных в Pimcore, и на основе которого строится взаимодействие с данными, получаемыми от мастер-системы — в том числе, хранение, вывод и заполнение данных по готовым таблицам внутри сайта.
Kafka отдает нам данные в виде объектов — мы их парсим (автоматически собираем и структурируем с помощью отдельного сервиса), раскладываем по табличкам внутри сайта и используем. Дополнительно мы написали парсер схемы данных, который учитывает различные типы свойств, представленных в Pimcore, и на основе которого строится взаимодействие с данными, получаемыми от мастер-системы — в том числе, хранение, вывод и заполнение данных по готовым таблицам внутри сайта.
Леонид
Разработчик
— Благодаря использованию Apache Kafka на сайте заказчика практически такая же структура данных, как в мастер-системе Pimcore. Кроме того он может управлять выводом отдельных свойств в карточках товаров, фильтрах и на детальной странице товара.
Полина
Руководитель проекта
— При обмене через Apache Kafka есть продюсер сообщений (система, которая инициирует сообщение, — в нашем случае Pimcore) и потребитель (система, которая читает сообщение в Кафке, в нашем случае — сайт).
В протоколе мы зафиксировали события, при которых сообщения из Pimcore будут автоматически отправляться через Кафку на сайт (например, изменения в товарах, появление новых свойств и т. д.). Обмен односторонний — PIM присылает данные, мы их только читаем и обновляем информацию на сайте.
В протоколе мы зафиксировали события, при которых сообщения из Pimcore будут автоматически отправляться через Кафку на сайт (например, изменения в товарах, появление новых свойств и т. д.). Обмен односторонний — PIM присылает данные, мы их только читаем и обновляем информацию на сайте.
Как только мы согласовали протокол обмена данными, заказчик смог сформировать минимальный каталог в PIM-системе с несколькими категориями и заполненными данными по товарам, а мы — смогли его импортировать на сайт.
Осталось понять, какие данные и из какого источника должны приходить на сайт:
Чтобы разобраться, какие именно данные и откуда должны появляться на детальной странице товара и в списке товаров, мы раскрасили макеты страниц — отметив цветом каждый блок:
Осталось понять, какие данные и из какого источника должны приходить на сайт:
- PIM-система отдает данные о товарах;
- поставщики отдают торговые предложения, цены, остатки;
- сайт сам рассчитывает некоторые данные — например, минимальные цены, стоимость и сроки доставки;
- кроме того сайт сам формирует сортировки в каталоге и контент.
Чтобы разобраться, какие именно данные и откуда должны появляться на детальной странице товара и в списке товаров, мы раскрасили макеты страниц — отметив цветом каждый блок:
Так, например, фильтр в каталоге строится по схеме данных из Pimcore.
Дмитрий
Разработчик
— Заказчик может поменять список свойств, типы свойств, их описания и т. д. в своей системе и отправить эти данные в определенном формате на сайт — фильтр на сайте автоматически обновится.
Отдельная история — изображения товаров.
Леонид
Разработчик
— Изображения загружаются вместе с товарной номенклатурой в PIM-систему заказчика. Чтобы импортировать их оттуда на сайт сразу в нужном размере, мы интегрировались с сервисом Imaginary — он работает как прокси-сервис для отображения картинок. Мы забираем из PIM ссылку на конкретное изображение, прогоняем его через Imaginary с заданными параметрами размера, и сервис отдает на сайт изображение в нужном размере.
В первых спринтах мы также разработали функционал добавления торговых предложений — уникальных предложений от поставщиков со своей ценой, остатками, минимальным количеством для заказа и кратностью покупки. Торговые предложения «цепляются» к мастер-товарам, которые приходят из PIM.
Полина
Руководитель проекта
— Сначала мы сделали добавление торговых предложений через админ-панель на сайте, чтобы админы маркетплейса могли на себе обкатать процедуру добавления и сказать, хватает ли данных.
В следующих спринтах развивали функционал личного кабинета поставщика: добавляли интерфейсы загрузки торговых предложений через личный кабинет, подключали логирование, формировали раздел с историей заказов.
В следующих спринтах развивали функционал личного кабинета поставщика: добавляли интерфейсы загрузки торговых предложений через личный кабинет, подключали логирование, формировали раздел с историей заказов.
Интеграция с 1С
Как только был готов MVP, мы взялись за новые спринты, где в числе первых задач реализовали интеграцию сайта и 1С. Казалось бы, зачем, если данные о товарах мы получаем из PIM, а вся информация по пользователям и заказам хранится на сайте?
Полина
Руководитель проекта
— Интеграцию с 1С мы сделали, чтобы в дальнейшем автоматизировать процесс формирования документов и подтверждения новых пользователей на сайте. Реализовали с помощью уже упомянутого Apache Kafka.
В этом случае поставщик данных — уже сайт, а не PIM. Мы прописали набор топиков (событий), которые автоматически передаются в Kafka при наступлении этого события.
Например, при изменении реквизитов пользователя, данных банка, информации по заказу (смена статуса, состава заказа), изменившиеся данные автоматически отдельными записями отправляются в Kafka, а уже оттуда эти изменения забирает 1С и обновляет у себя.
В этом случае поставщик данных — уже сайт, а не PIM. Мы прописали набор топиков (событий), которые автоматически передаются в Kafka при наступлении этого события.
Например, при изменении реквизитов пользователя, данных банка, информации по заказу (смена статуса, состава заказа), изменившиеся данные автоматически отдельными записями отправляются в Kafka, а уже оттуда эти изменения забирает 1С и обновляет у себя.
Функциональные личные кабинеты
Для поставщика — свой, для покупателя — свой.
Дмитрий
Разработчик
— У поставщика есть возможность редактировать параметры заказов пользователей (например, менять срок доставки), или просматривать собственный каталог, в котором можно редактировать свои товарные предложения и легко добавлять новые.
У пользователя — реализована вся классика больших маркетплейсов: от проверки статуса заказа до возможности точь-в-точь его повторить.
У пользователя — реализована вся классика больших маркетплейсов: от проверки статуса заказа до возможности точь-в-точь его повторить.
Управление оплатами и документами
Один из самых сложных вопросов, который при создании маркетплейсов часто откладывают «на потом» — как будет устроена оплата заказов. В классических маркетплейсах схемы обычно две:
1. Оплата напрямую маркетплейсу
Пользователь платит напрямую маркетплейсу, и тот берет на себя все обязательные чеки. Деньги поставщику приходят уже за минусом комиссии. Так работают все крупные маркетплейсы вроде Озона и Вайлдберриз.
2. Оплата продавцу
Такую историю чаще используют маркетплейсы-франшизы, например мы делали так в проекте для Фитнес Формулы. Деньги за заказ уходят напрямую поставщику, за чеки тоже отвечает он. За услуги маркетплейса при таком подходе поставщик платит отдельно.
При идеальном раскладе все поставщики на площадке пользуются одной платежной системой, и тогда всё предельно просто: площадку интегрируют с этой системой, дают всем поставщикам индивидуальные доступы, и работают. Случай редкий. Чаще платежные системы разные, и тогда приходится интегрироваться с каждой из них, а поставщикам как-то самостоятельно разобраться с фискализацией и всеми чеками.
Чтобы не усложнять процесс оплат, на проекте SOLOMA предусмотрен лишь один вариант — оплата напрямую поставщику по счету. Для В2 В такой расклад удобнее всего. При этом заказы в корзине группируются по конкретному поставщику (как на AliExpress).
Как только пользователь оформил заказ, поставщик получает уведомление и видит в его в своем личном кабинете. Чтобы сгенерировать счет, ему достаточно перевести статус заказа с «Ожидает подтверждения» в «Подтвержден» — и счет-договор автоматически выставится пользователю.
1. Оплата напрямую маркетплейсу
Пользователь платит напрямую маркетплейсу, и тот берет на себя все обязательные чеки. Деньги поставщику приходят уже за минусом комиссии. Так работают все крупные маркетплейсы вроде Озона и Вайлдберриз.
2. Оплата продавцу
Такую историю чаще используют маркетплейсы-франшизы, например мы делали так в проекте для Фитнес Формулы. Деньги за заказ уходят напрямую поставщику, за чеки тоже отвечает он. За услуги маркетплейса при таком подходе поставщик платит отдельно.
При идеальном раскладе все поставщики на площадке пользуются одной платежной системой, и тогда всё предельно просто: площадку интегрируют с этой системой, дают всем поставщикам индивидуальные доступы, и работают. Случай редкий. Чаще платежные системы разные, и тогда приходится интегрироваться с каждой из них, а поставщикам как-то самостоятельно разобраться с фискализацией и всеми чеками.
Чтобы не усложнять процесс оплат, на проекте SOLOMA предусмотрен лишь один вариант — оплата напрямую поставщику по счету. Для В2 В такой расклад удобнее всего. При этом заказы в корзине группируются по конкретному поставщику (как на AliExpress).
Как только пользователь оформил заказ, поставщик получает уведомление и видит в его в своем личном кабинете. Чтобы сгенерировать счет, ему достаточно перевести статус заказа с «Ожидает подтверждения» в «Подтвержден» — и счет-договор автоматически выставится пользователю.
Полина
Руководитель проекта
— Факт оплаты отслеживается «ФомЛайн». Маркетплейс принимает платеж — менеджер площадки в админ-панели вручную устанавливает статус «Оплачен», после — отправляет деньги поставщику, и дальше тот может управлять статусами заказов. В зависимости от них автоматически генерируются закрывающие документы — их можно найти в отдельном разделе «Бухгалтерия».
Леонид
Разработчик
— Бухгалтерские документы для подтверждения оплаты, отгрузки, закрытия сделок — это стандартизованные законом формы. Чтобы генерировать документы в виде XLS-файлов по заданному шаблону, мы подключили специальную библиотеку. Файлы создаются автоматически, к ним добавляются лишь параметры заказа и нужные реквизиты. Сейчас маркетплейс умеет создавать 4 типа документов: счет-договор (счет на оплату), счет-фактуру на аванс, УПД (универсальный передаточный документ) и доверенность на получение грузов с факсимильной подписью.
Мы и шпаргалку на сайте предусмотрели, чтобы поставщикам было проще разобраться со статусами и документами — заказчик помог с заполнением, дав подробные инструкции.
Мы и шпаргалку на сайте предусмотрели, чтобы поставщикам было проще разобраться со статусами и документами — заказчик помог с заполнением, дав подробные инструкции.
Выбор доставки
Маркетплейс работает по системе DBS (Delivery by seller) — то есть не хранит товары на своих складах и не отправляет их покупателям, а выступает лишь в качестве торговой площадки. Это усложнило задачу на этапе разработки:
Добавление склада для поставщика мы сделали понятным с помощью пошаговой формы в личном кабинете. В ней достаточно прописать адрес и режим работы склада, график и способы отгрузки (самовывоз или доставка — у каждого варианта будут свои сроки) и географию доставки — заполненные данные влияют на расчет срока и стоимости доставки для пользователей маркетплейса.
- во-первых, нужно было реализовать понятный интерфейс, где поставщики сами смогут заполнить данные по складам;
- во-вторых, нужно грамотно использовать эти данные для расчета итоговой стоимости и срока доставки для пользователя.
Добавление склада для поставщика мы сделали понятным с помощью пошаговой формы в личном кабинете. В ней достаточно прописать адрес и режим работы склада, график и способы отгрузки (самовывоз или доставка — у каждого варианта будут свои сроки) и географию доставки — заполненные данные влияют на расчет срока и стоимости доставки для пользователей маркетплейса.
Полина
Руководитель проекта
— География доставки — один из наиболее сложных функционалов. На сайте подключена база городов с иерархией: выводятся страны, регионы, города, районы. Для каждого элемента таблицы из этой базы задается условие — «Доставлять» или «Не доставлять» в выбранный регион. Чтобы не заполнять вручную миллиарды строк, есть механизм наследования.
Например, можно поставить статус «Доставлять» плюс прописать сроки доставки и её стоимость для Москвы — и эти данные автоматически применятся и ко всем городам области. При этом, если в какой-то город Подмосковья поставщик товар почему-то не возит, конкретно для него можно поменять статус на «Не доставлять».
Например, можно поставить статус «Доставлять» плюс прописать сроки доставки и её стоимость для Москвы — и эти данные автоматически применятся и ко всем городам области. При этом, если в какой-то город Подмосковья поставщик товар почему-то не возит, конкретно для него можно поменять статус на «Не доставлять».
График работы склада влияет на возможность самовывоза. Например, если склад работает только в понедельник, среду и пятницу, то на сайте пользователь, выбрав самовывоз, увидит только подходящие даты — те, что выпадают на нерабочие дни склада, будут неактивными.
При этом, если пользователь выберет доставку до адреса, доступные даты автоматически рассчитываются по формуле с учетом срока отгрузки товара (который также заполняет поставщик в разделе информации о складе). На случай форс-мажоров для поставщиков мы предусмотрели возможность изменить дату отгрузки в личном кабинете — но сделать это для каждого заказа можно лишь один раз.
Проект также предусматривает работу с поставщиками, которые изготавливают продукцию на заказ.
Денис Фатеркин
Начальник отдела электронной коммерции компании «ФомЛайн»
— Производства, выпускающие продукцию на заказ, могут разместить свои предложения, фактически не имея товара на складе, лишь указав срок изготовления товара. Главное, что, демонстрируя свои торговые предложения на платформе, они должны обеспечить заявленный товар и объём (источник).
О проекте и планах развития
Леонид
Разработчик
— Проект интересный, местами сложный. Очень нравится работать с заказчиком, который имеет представление о продукте, о требованиях. Круто, что здесь мы используем Laravel в связке с Vue. В этом проекте мы использовали админку Orchid вместо растиражированного Voyager, мне нравится.
Дмитрий
Разработчик
— Мы постарались сделать работу для поставщиков максимально удобной: реализовали несколько способов загрузки торговых предложений, как через файл так и в ручную, реализовали возможность изменения заказов с учетом пожеланий заказчика, сделали очень классные личные кабинеты для различных ролей пользователей и многое другое. Еще многое — впереди.
Полина
Руководитель проекта
— В планах интеграция с ЭДО, поскольку сейчас, чтобы стать покупателем или поставщиком на платформе, необходимо вручную в ЭДО отправить необходимые документы. Планируем это автоматизировать: заодно упростим оборот документов между платформой и поставщиками.
Впереди ещё очень большой пласт работ: начиная от улучшений дизайна и заканчивая большими интеграциями. Так что скучать не приходится :)
Впереди ещё очень большой пласт работ: начиная от улучшений дизайна и заканчивая большими интеграциями. Так что скучать не приходится :)
Владимир
CEO&Founder Scrum-студии "Сибирикс"
— В подобного рода проектах ахиллесова пята — сопоставление пользовательских данных в карточках. Совместить данные, пришедшие из разных систем, в единые карточки, которые можно сравнивать по цене.
Мы уже писали про возможные варианты решения, однако в общем виде полноценно такую задачу не решил никто. Вариант с мастер-каталогом оказался жизнеспособным.
Использование PIM-системы (Pimcore) позволило сделать гибкий и удобный каталог. Кроме того, сам Pimcore имеет открытый код и позволяет вести доработки, не привязываясь к вендору (это особенно важно в нынешних реалиях с импортозамещениями). Брокер сообщений Apache Kafka позволяет сделать надежную и масштабируемую систему и строить микросервисы. От всей нашей команды желаю успешного развития проекту и процветанию бизнесу клиента. Было очень приятно работать вместе!
Мы уже писали про возможные варианты решения, однако в общем виде полноценно такую задачу не решил никто. Вариант с мастер-каталогом оказался жизнеспособным.
Использование PIM-системы (Pimcore) позволило сделать гибкий и удобный каталог. Кроме того, сам Pimcore имеет открытый код и позволяет вести доработки, не привязываясь к вендору (это особенно важно в нынешних реалиях с импортозамещениями). Брокер сообщений Apache Kafka позволяет сделать надежную и масштабируемую систему и строить микросервисы. От всей нашей команды желаю успешного развития проекту и процветанию бизнесу клиента. Было очень приятно работать вместе!
Отзыв заказчика
