1С-Битрикс: многоскладовость, 1С, персональные скидки

Задача состояла в том, чтобы автоматизировать работу с постоянными клиентами. Есть специфика: почти все товары импортируются из Японии, а их цена зависит от курса Юаня (большая часть товаров из Китая). Бумаги не напасешься чтобы печатать прайс-листы при смене курса валют! :)

Весь учет «Глобуса» построен на «1С: Управление торговлей», с которой нужно было интегрировать сайт (выгрузка товаров, обмен заказами). Кстати пока писалось ТЗ, наш клиент плавно переехал на новую версию 1С: Предприятия и 1С: УТ соответственно (всем бы так!).

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

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

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

Для того, чтобы доработать обмен с 1С сперва была сделана типовая выгрузка товаров. Полученные XML-файлы (CommerceML) мы подвергли изменениям, которые зафиксировали в техническом задании. 

Такое изменение естественно это потребовало и доработки обмена на стороне сайта.

Пара обсуждений, просьб перенести данные из одних узлов в другие и все было готово.

В результате мы получили:

• выгрузку контрагентов на сайт
• выгрузку информации о персональных скидках на сайт
• расчет цен на сайте в зависимости от курсов валют и персональных скидок

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

А еще как раз в момент программирования и запуска проекта в Хабаровске было наводнение, думаю вы помните…

Несмотря на эту сложность проект запустили, а время реакции наших коллег не уменьшилось ни на минуту.

С точки зрения программиста, проект получился тоже неординарный. ТЗ пестрило необычными задачками, решать которые было одно удовольствие. Взять, например, список адресов доставки. Согласно ТЗ «Во вкладке Адреса доставки клиент может увидеть все свои адреса для доставки и добавить новые, отредактировать существующие. Название адреса является ссылкой на редактирование записи.». То есть, адреса — это самостоятельная сущность, потенциально инфоблок. Но эти данные используются и на этапе оформления заказа! Решилось файлом result_modifier, который, если пользователь указал ID своего профиля доставки, записывал значения оттуда в скрытые поля заказа.

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

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

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

Скидка задается коэффициентом — 1,5 означает наценку 50%, 0,95 — 5% скидку, а 1 — это продажа товаров по обычной цене. Как видно на схеме, нет прямой связи между пользователями и товарами, только посредством типов цен и групп скидок. При этом для нового пользователя покупка каких-либо товаров невозможна до тех пор, пока менеджеры на сайте или в файлах импорта не укажут его скидку. Но это закономерно, так как случайных пользователей в этом интернет-магазине нет.

Вот такой получился «нестандартный» проект.