Как реализовать отображение персональных цен на товары для клиентов, не перебирая всю CMS

Суть и проблематика задачи

Что такое персональные цены?

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

К примеру, договорился Ваш менеджер с ООО «рога и копыта», что для них на все швабры цена будет ниже от розничной на 20 процентов — и так Вы и продаете, при этом продаете так только для ООО «рога и копыта», а для остальных организаций и предпринимателей подаете по другим условиям :)

В чем сложность?

Проблематика данной задачи лежит в плоскости отличия систем: 1С и Битрикса в части учета контрагентов и работы с ценами

Если кратко, то имеем следующее:

• Для учетных систем 1С в персональных ценах сложности обычно нет, так как в 1С есть функционал соглашений. Соглашения эти могут быть типовыми — т.е. действующими для всех, и индивидуальными — действующими на конкретного контрагента, при этом у одного и того же контрагента может быть как типовое так и индивидуальное соглашение.
• Также стоит отметить, что учет в 1С в принципе построен от контрагентов — т.е. фактически от организаций и предпринимателей.
• В Битриксе же, соглашений не существует и понятия «контрагент» также — на стороне CMS все работает от пользователя, т.е. есть у нас пользователь, у него есть логин и пароль, а кто этот пользователь — ИП Пупкин, или ООО «Круасаны и бананы» неизвестно.
• Конечно, в битриксе есть профили покупателя, однако они привязаны к пользователю. В 1С же нет понятия «пользователя» в том смысле, в котором оно используется на сайте.
• К слову говоря о профилях покупателя: их мы использовали по назначению, так как требовалось, чтобы у одного пользователя могло быть в ЛК несколько юридических лиц — в b2b это классическая история (в корпоративном мире все мы помним и знаем, что у нас может быть 10 юридических лиц под разные задачи и направления).

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

Если говорить об устранении разности сущностей — это долго и дорого, да и битрикс в этом случае можно будет забыть.

Однако, в Битриксе есть довольно много преимуществ, из-за которых он и был выбран, поэтому идти этим вариантом для нас было бессмысленно.

И мы решили идти вариантом обхода

Читайте также нашу статью: Внедрение бонусной программы в интернет-магазине на базе Mindbox

Как сделали:

Чтоб добиться цели по отображению на сайте цен нужно было решить следующие задачи:

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

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

Как было описано выше, у одного контрагента может быть как типовое, так и индивидуальное соглашение.

Типовое по своей сути определяет тип цен, по которым в целом работает контрагент по всем направлениям.

Индивидуальное — определяет на какую категорию товаров или отдельный список товаров действуют индивидуальные цены и для какого контрагента.

и понятное дело, что если есть индивидуальное соглашение — оно в приоритете.

Задаемся вопросами:

Как мы можем определять тип цен в битриксе? — там есть функционал «тип цен», им и будем определять.

Как мы можем определять контрагента, к которому тип цен привязан? — по ИНН, ведь это уникальный идентификатор. Как мы можем определять товар, на который действует индивидуальная цена? — по коду/артикулу этого товара.

Ок, хорошо, а как это все увязать с сайтом? как говориться, следите за руками :)

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

Для идентификации какому ИНН — какой тип цен принадлежит передаем со стороны 1С справочник, который содержит колонки: «ИНН», «ИД», «тип цен».

Для персональных цен передаем второй справочник, который содержит колонки «ИНН», «код/артикул товара», «значение цены».

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

Что такое справочники в Битриксе? — все просто, это Highload-блоки.

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

Таким образом, мы знаем для какого ИНН отображать цены и откуда их брать:

При загрузке страницы проверяем справочники по ИНН, если есть индивидуальные цены — показываем из справочника индивидуальных цен, если нет — смотрим справочник типов цен и определяем по какому типу цены выводить цену.

Чтобы это все корректно работало на стороне сайта, пользуемся волшебным событием OnGetOptimalPrice

Profit :)

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

Из ограничений, можно отметить:

• Производительность.Чем больше данных будет в справочнике, тем «тяжелее» на выходе будет работать;
• Штатная фильтрация и сортировка по цене в каталоге учитывать персональные цены не будет (или Вам нужно будет сделать свои кастомные компоненты, которые не факт, что будут работать приемлемо);
• Персональные цены не будут учитываться модулем маркетинга Битрикса (т.е. скидки сделать через него не получится).

Однако, с одной стороны, в каждом решении есть плюсы и минусы, с другой — в нашей случае, эти ограничения были приемлемы, поэтому решение подошло!

Читайте также нашу статью: Как мы делали редизайн интернет-магазина для лидера рынка пневматики