B2B платформа по оптовой продаже расходников для офисной техники

Особенности проекта

Переход с 1С:Предприятие 7.7 на 1С: Предприятие 8.3.
Главная проблема была связана с тем, что начало работ над порталом совпало по времени с переходом компании РМ со старой версии 1С: Предприятие 7.7 на новую, реализованную «с нуля» на основе библиотеки стандартных подсистем, конфигурацию на платформе 1С: Предприятие 8.3.

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

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

• Холдинги (группа юр. лиц, представляющих собой фактически одного клиента); 
• Контрагенты (справочник с реквизитами) 
• Договоры (полная информация о сторонах договора и типе цен в нем); 
• Список типов цен 
• Склады 
• Категории сайта (для перегруппирования номенклатуры, структура каталога в 1С и на сайте не совпадает) 
• Категории 1С (для той же цели) 
• Номенклатура (собственно товары с характеристиками) 
• Цены (значения цен) 
• Остатки (с учетом резервов) 
• Категории пользователей 
• Финансы (данные о дебиторской задолженности) 
• Менеджеры (отдельный список разрешенных пользователей портала) 
• Индивидуальные цены (те самые персональные цены на конкретную позицию)
• Регионы (перечень регионов, в которых работают контрагенты, используется для привязки складов) 

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

«Решением в нашем случае является использование дополнительного компонента Symfony process component -который позволяет выполнять команды синхронизации в нужной очереди дождавшись выполнение предыдущей синхронизации. Таким образом, расписание синхронизации свелось к одному единственному запуску процесса, который, в свою очередь, управляет синхронизацией данных в нужном порядке, при этом гарантирует четкую очередность выполнения», — рассказывает технический директор Compo Владимир Гантурин. 

Ну и, конечно, надо было так выстроить синхронизацию, чтобы исключить сбои и минимизировать время процесса. В итоге полная загрузка данных, порядка 600 000 записей, синхронизируется за 7-9 минут, в зависимости от нагрузки.

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

Другие виды обмена происходят гораздо чаще, данные о наличии могут обновляться вплоть до 1 минуты. Технически возможен и обмен в реальном времени, но практически вреда от такой реализации будет больше чем пользы.

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

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

Оформление и дизайн

Нестандартные решения

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

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

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

Кроме того, перед началом подбора номенклатуры пользователь указывает следующие данные:

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

Некоторые контрагенты RM-Company делают заказы с помощью внутренних UID-кодов товаров, или их частей. Нами были разработаны соответствующие инструменты подбора по UIDу и части UIDа, плюс возможность загрузки Excel-файла с кодом товара и количеством. При загрузке на сайт, исходя из данных этого файла, формируется корзина.

Отображение наличия товара и валюты отличается и настраивается для разных контрагентов на платформе. Какие-то клиенты видят остатки, как “много-мало-достаточно”, другие могут видеть фактические остатки в штуках по своим складам. Этим достигается гибкость работы компании. Похожая ситуация и с брендами. Если клиент не работает с какими-то брендами, то такие они отключаются и ненужная номенклатура не отображается для выбора.

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

Общая структура B2B платформы

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