Разработка модуля интеграции 1С-Битрикс с МойСклад

15.06.2021

Задача: Разработать модуль интеграции 1С-Битрикс с МойСклад для сайта AUDIO-DRIVE.

AUDIO-DRIVE — популярный интернет магазин электроники и аксессуаров. 

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

По мере увеличения каналов продаж, перед клиентом встал вопрос о переработке интеграции с системой учета МойСклад. Так после запуска интеграции с OZON проблема синхронизации встала особенно остро, задержка обмена остатками неизбежно приводила к отмене заказов, а маркетплейс грозил отключением магазина.

Анализ требований

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

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

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

Анализ готовых решений сторонних разработчиков показал, что без доработок под конкретную специфику магазина не обойтись. Доработка готового модуля не является оптимальным решением, ввиду сложности доработок, зависимости от обновлений и чужой архитектуры. Чтобы избежать дополнительных рисков и учесть все нюансы бизнес процессов клиента — мы пошли путем разработки собственного решения в виде модуля интеграции с МойСклад (на основе JSON API)

Разработка модуля

Логическая схема интеграции

Синхронизация товаров

Поскольку новые товары заводятся как в МС так и в битрикс, синхронизацию сделали двухсторонней.  

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

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

При изменении товара (название, цена, гарантия, вес, размер и штрихкод) в одной из систем — изменения синхронизируются в другой.

Синхронизация заказов 

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

Синхронизация остатков

Актуальные остатки хранятся только в МС и импортируются в битрикс по расписанию. 

Резервирование товара в МС происходит после установки “Доставка разрешена”, при этом происходит проверка доступного остатка в МС и установка флагов “Проведено” и “Резерв”, а также флага “Ошибка”, в случае недостаточности доступного остатка.

Синхронизация оплат

При создании оплаты в битрикс — в МС создается входящий платеж на выбранное (в битрикс) юрлицо и соответствующий счет. 

Если по одному заказу в битриксе создаются несколько оплат, то в МС создаются несколько входящих платежей, при этом в МС устанавливается флаг “Проведено”. При удалении или отмене оплаты в битрикс — удаляется платеж в МС

Синхронизация отгрузок

При установке флага “Отгружено” в битрикс — в МС создается отгрузка. При удалении или отмене отгрузки в битрикс — удаляется отгрузка в МС

Заключение

Кроме непосредственно самой интеграции, мы реализовали функционал загрузки оплат на основе отчетов транспортных компаний и маркетплейсов.

Так в битрикс можно загрузить файл отчета, например от СДЭК, после его обработки в МС будут созданы входящие платежи (на выбранное при импорте файла юрлицо и расчетный счет) и будут привязаны к заказам покупателей.

Наш модуль интеграции 1С-Битрикс с МойСклад работает быстрее штатного, например среднее время загрузки заказа в МС (после появления его в битрикс) составляет 10 секунд, примерно такое-же время требуется на синхронизацию статусов, а полный обмен остатками, ≈ 20 000 товаров, проходит за 3 минуты.

​Конфигуратор товаров в 1С-Битрикс, два подхода / likes 25 / блог студии Клондайк!

Пролог

Решение нестандартных задач всегда приводит к той или иной кастомизации. В статье мы рассмотрим два подхода к решению одной задачи, а также сравним плюсы и минусы каждого из решений.

Задача

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

Что должно получиться на выходе

• Интерфейс для администратора, через который можно было бы гибко управлять конфигуратором.
• Интерфейс для пользователя, при помощи которого он мог бы «собрать» себе товар, к примеру матрас размером 140×200, дефолтным чехлом и тремя зонами пружин, а в процессе подбора параметров видеть изменение цены.
• Сконфигурированные товары на ряду с обычными должны добавляться в корзину, а затем быть доступными в списке ранее заказанных.
• Сконфигурированные товары на ряду с обычными должны адекватно обрабатываться внутренними механизмами системы и быть доступными в стандартном разделе заказов.

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

Подход номер один, первая итерация

В первой итерации мы должны дать возможность администратору сайта создавать конфигурированные товары, матрасы.

Задачи первой итерации:

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

С виду почти ничего сложного, да? Теперь посмотрим на вводные данные.

Какие параметры определяют конфигурируемый матрас и как они зависят друг от друга

• Размер. В основе всех вычислений лежит размер, их около 20 штук — 140×180, 140×200… У размера есть ширина и длинна, они тоже меняются. У матраса для каждого размера должна быть стоимость.
• Чехол. У каждого матраса есть набор чехлов в которых он может быть выполнен, также можно указать дефолтный чехол, который изначально идет в комплекте с матрасом. Стоимость чехла зависит от размера матраса.
• Пружинные зоны. Каждый матрас может быть выполнен с различными пружинными зонами или вообще без них. Стоимость зон также зависит от размера матраса.

Итог по входным параметрам матраса

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

Обычный матрас из каталога имеет около 15 размерных вариантов, семь чехлов и до трех вариантов пружинных блоков. Вспоминаем что мы должны предоставить пользователю конечную стоимость матраса здесь и сейчас, а значит её нужно вычислить. Также держим в уме и другие задачи, к примеру «интерфейс администратора», полуавтоматическое конфигурирование из административной панели и прочее. Напоследок сдобрим это тем что всю эту прелесть нужно «подружить» с 1С-Битрикс. Какие будут идеи?

Первое над чем я задумался — это «дружба» с платформой, а точнее с её штатным функционалом. Крайне не хочется писать то, что уже реализовано в коробке, плюс, т.к. оно родное, поддержка всеми интерфейсами идет в комплекте. На примете было всего три функциональных блока которые можно было бы приспособить для данной задачи:

• Комплекты
• Наборы
• SKU (торговые предложения)

К сожалению комплекты и наборы не давали того функционала, который был необходим для создания конфигуратора, с релизом обновленной e-commerce платформы возможно что-то поменяется, тут приведен отрывок моего разговора с Юрием Волошиным по поводу новой платформы и в частности о подходе к созданию конфигураторов. Помимо этого для использования комплектов и наборов пришлось бы апнуть лицензию до «Бизнес», но это мелочи. Остался последний вариант — SKU.

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

Промежуточный итог

Мы определились с подходом — весь функционал конфигуратора будет построен на базе штатного механизма SKU. Это уже хорошо: знакомый функционал, и он полностью поддерживается платформой, т.е. в корзине и административном разделе заказов все заработает без дополнительных телодвижений. Остаются два интерфейса — административный и пользовательский.

Структура данных

Матрасы надо из чего-то генерировать, для этого нужен справочник сущностей. В первой итерации будет три справочника:

1. Размеры
2. Чехлы
3. Пружинные зоны

Каждый из справочников редактируемый и при необходимости в них можно что-либо добавить или убрать.

Административный интерфейс

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

• Свойство привязки к размеру и его стоимость
• Свойство привязки к пружинным зонам
• Свойство привязки зон к размерам
• Свойство, флаг, генерации SKU

Большая часть свойств представляли из себя некие табличные интерфейсы (screenshot 1).

 Screenshot 1.

Заполнение товара

Справочник, как не сложно догадаться, заполняется в три этапа:

• Первым этапом заполняются размеры, т.к. от них зависит стоимость конкретных предложений и комплектующих.
• Вторым этапом заполняются чехлы, в них, помимо описания и картинки, присутствует свойство привязки к размерам.
• На последнем, третьем, этапе заполняются пружинные зоны, они также имеют свойство привязки к размерам.

После того как справочник заполнен, можно приступать к товарам.

У каждого матраса в административном разделе появилась вкладка «генератор SKU». Во вкладке по порядку идут свойства:

• Привязка к размерам
• Привязка к чехлам
• Привязка к чехлу по умолчанию
• Привязка к пружинным зонам
• Флаг перегенерации SKU

Заполнив все необходимые данные, ставим флаг перегенерации SKU и сохраняем элемент инфоблока. (Тут в трех скринах показать админку).

Генерация SKU

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

• Сбор всех возможных размерных предложений
• Сбор всех доступных чехлов, в том числе и дефолтного
• Сбор всех доступных пружинных зон

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

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

После сбора всех необходимых данных запускается функция создания элементов SKU. По окончании работы функции у матраса появляется в среднем от 250-ти до 500-сот вариантов, элементов SKU.

Пользовательский интерфейс

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

Детальная карточка товара

В детальной карточке товара происходит проверка: проверяем есть ли у товара SKU, если есть, то подключаем дополнительный файл, в котором содержится интерфейс подбора параметров (screenshot 2).

 Screenshot 2.

Помимо самого интерфейса, в файле происходит подключение класса для работы генератора SKU.

Для построения пользовательского интерфейса нам понадобится выборка всех элементов SKU для дефолтного размерного ряда — того, что пользователь видит при переходе в детальную карточку товара.

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

Покупка, корзина и административный раздел заказов

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

В административном разделе заказов выбранные товары отображаются так же, как у пользователя в корзине — все параметры перечислены в названии элемента SKU.

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

Подход номер два, вторая итерация

Во второй итерации мы должны дать возможность администратору сайта создавать конфигурированные товары, кровати.

Задачи второй итерации:

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

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

Какие параметры определяют конфигурируемую кровать и как они зависят друг от друга:

1. Производитель. От производителя зависят все ниже лежащие параметры.
2. Размер. В основе всех вычислений лежит размер, у каждого производителя они разные — 140×180, 140×200… У размера есть ширина и длинна, они тоже меняются. У кровати для каждого размера должна быть стоимость.
3. Материал основания. Необязательный параметр.
4. Цвет основания. Необязательный параметр.
5. Материал отделки кровати. Необязательный параметр.
6. Комплектация кровати. Сюда входят ящики для белья, подъемные механизмы и прочее. Необязательный параметр.

Итог по входным параметрам матраса

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

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

В первом варианте у нас было три параметра, и в среднем на один матрас выходило от 250-ти до 500-т торговых предложений; самое большое число предложений которое мне удалось зафиксировать — 1245 штук. Кровати же сулили увеличить эту цифру в десятки раз, ведь каждый новый параметр комбинации возводит число вариантов в следующую степень.

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

Промежуточный итог

Мы определились с методом для второго подхода — это будет генератор без использования SKU, он не будет создавать сущностей, а представит из себя пользовательский и административный интерфейс, плюс некоторые сервисные функции.

Реализация

От первой итерации я взял административный и пользовательский интерфейс. В принципе, они меня полностью устраивали, в админке нужно было произвести некоторую модернизацию, но по большому счету мало что изменилось. Но если внешнее отображение сменилось незначительно, то «под капотом»» осталось 10% старого кода — та часть которая генерировала отображение интерфейсов.

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

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

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

Пользовательский интерфейс

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

Запускаем функции разбора свойств элемента инфоблока, ведь вся необходимая информация хранится в них. Как и ранее находил дефолтный размерный ряд. Ищем все точки пересечения (они, как и ранее, находятся в размерах), затем строим массив из всех возможных вариантов модификаций товара.

Важно, что данные для постройки и работы интерфейса у нас есть с самого начала, и за ними не приходится дополнительно обращаться в базу данных; исключением являются данные, описывающие чехлы и пружинные зоны — их все же придется запросить из БД (но единожды), а затем брать из кэша. На основе полученных данных строим интерфейс.

Пока все было сильно похоже на первую итерацию, да мы отказались от SKU, но логика работы изменилась не сильно. Теперь об интересном.

Добавление в корзину

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

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

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

Корзина

В корзине все чинно и аккуратно: стоимость приходит верная, правильно считается скидка, и подтягиваются свойства товара, к примеру размер и материал отделки (screenshot 3).

 Screenshot 3.

Административный раздел

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

Эпилог

Я расписал два подхода к решению по сути одной и той же задачи, конфигурированию сложных товаров в среде 1С-Битрикс. Осталось сравнить два подхода и сделать выводы.

Сравнение

Первая итерация

Плюсы:

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

Минусы:

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

Вторая итерация

Плюсы:

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

Минусы:

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

Выводы

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

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

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

crm.item.productrow.get

 crm.item.productrow.get({id: number}) 

Передает информацию о SKU продукта с идентификатором .

Параметры

Параметр	Описание	Доступно с версии
id	Артикул продукта 900 22

Ответ:

 {
"продуктРов": {
"идентификатор": 1263,
"Идентификатор владельца": 707,
"ВладелецТип": "В",
"идентификатор продукта": 2,
"productName": "Артикул продукта",
"цена": 611,
"priceAccount": 611,
"ценаЭксклюзив": 611,
"ценаНетто": 678,89,
"ценаБрутто": 678,89,
"количество": 1,
"скидкатипеид": 2,
"Ставка скидки": 10,
"сумма скидки": 67,89,
"Ставка налога": 0,
"taxIncluded": "Н",
"индивидуально": "Y",
"Код меры": 796,
"measureName": "шт",
"сортировать": 0
}
} 

Значения ответа:

• ownerId — ID элемента CRM, к которому привязан артикул товара (например, ID цитаты)
• ownerType — символьный код объекта CRM с привязанным артикулом продукта. Узнать, какой именно код соответствует типу сущности, можно с помощью методов класса \CCrmOwnerTypeAbb р.
• productId — Артикул товара из каталога.
• productName — артикул товара. По умолчанию соответствует артикулу товара из каталога, но может быть обновлен.
• цена — цена за артикул товара, включая скидки и налоги.
• priceAccount — цена за артикул товара с учетом скидок и налогов, конвертированная в валюту отчета.
• ценаЭксклюзив — цена за артикул товара с учетом скидки, но без учета налогов.
• ценаНетто — цена за артикул товара без учета скидок и налогов.
• ценаBrutto — цена за артикул товара с учетом налогов, без учета скидки.
• количество — количество артикулов товара шт.
• DiscountTypeId — тип скидки. Может быть 1 для скидки в абсолютном значении и 2 для скидки в процентах. По умолчанию равно 2.
• DiscountRate — процент скидки на артикул товара.
• DiscountSum — абсолютное значение скидки на артикул товара.
• taxRate — процент налога на артикул товара.
• MeasureCode — код единицы измерения артикула товара. Настраивается в разделе Единицы измерения в настройках CRM.
• MeasureName — условное обозначение единицы измерения артикула товара. Настраивается в разделе Единицы измерения в настройках CRM.

Примечание : Начиная с версии модуля CRM 21.1800.0 , вы можете изменить единицы измерения для SKU с помощью REST-методов семейства crm.item.productrow.* , передав только MeasureCode . Автоматически завершает MeasureName .



• sort — коэффициент сортировки.

© «Битрикс24», 2001-2023

Вверх

Битрикс24 On-Premise Edition

Скачать

Более мощный. Широкие возможности настройки. Полностью безопасный

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

Высокая производительность

Запустите столько бизнес-процессов, сколько вам нужно. Создайте как можно больше объектов CRM. Отправьте столько запросов, сколько вам нужно. Битрикс24 справится со всем этим и никогда не лагает.

Полная настройка

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

Широкий выбор изданий

Выберите версию On-Premise, которая соответствует потребностям вашего бизнеса, заплатите полную стоимость за первый год, а затем вам придется платить всего 25 % от исходной цены ежегодно. В любое время, когда вам нужно увеличить лимит пользователей, вы можете обновить свою версию.

Скачать Связаться с партнером Битрикс24

Двухфакторная авторизация

Виртуальная АТС

Служба поддержки

Модуль электронного обучения

Исходный код + API + SDK

Доступный

Мы предлагаем доступные цены на локальную версию Битрикс24 по модели подписки, установленную в размере 25% от стоимости автономной версии в год. Вы можете воспользоваться бесплатной 30-дневной пробной версией перед покупкой.

Бизнес

Предприятие

50

100

250

500

1000

5000

2 990 долларов США

24 990 долларов США

Попробуй бесплатно

Попробуй бесплатно

Узнайте больше о функциях и ценах для локальной версии

Полная безопасность

Вы получаете полный контроль над своими данными и над тем, кто может получить к ним доступ. Локальный Битрикс24 использует зашифрованное SSL-соединение с 256-битным ключом для защиты данных при передаче.

Двухэтапная авторизация

Приложения Bitrix24 OTP и Google Authenticator предоставляют одноразовые пароли для двухэтапной авторизации. Даже если ваш пароль будет украден, ваша учетная запись не будет доступна потенциальному хакеру.

Хостинг на собственном сервере

С локальной версией Битрикс24 вы получаете собственное частное облако, полностью находящееся под вашим контролем — идеальный выбор для компаний, у которых есть дополнительные проблемы с безопасностью.

Пользовательские правила резервного копирования

Зачем полагаться на стандартное ежедневное резервное копирование, если вы можете установить собственные правила резервного копирования для создания резервных копий важных данных — версия Битрикс24 для собственного хостинга дает вам именно это.

Скачать Связаться с партнером Битрикс24

Готовность к AWS

SSL и RSA-шифрование

Брандмауэр веб-приложений

Серверы Linux, Unix, Windows

Совместимость с MS Azure

Производительность корпоративного уровня

Работаете с большими объемами данных, процессов или запросов? Вашей компании требуется масштабируемое программное решение? Используйте Битрикс24 локально.

Максимальная скорость и производительность

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

Высокая надежность и универсальность

Независимо от того, работает ли у вас несколько десятков человек в одном офисе или несколько тысяч человек на разных континентах, Битрикс24 всегда обеспечит стабильную работу и универсальный быстрый доступ к системе.

Легко масштабируемый

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

Скачать Связаться с партнером Битрикс24

Права доступа на основе ролей

Масштабируемое веб-кластерное приложение

Система единого входа (NTLM, пользовательская)

Поддержка LDAP и Active Directory

Низкие требования

Больше интеграций, чем вы можете себе представить

В дополнение к сотням приложений и надстроек, которые вы можете получить на нашем Маркете, локальная версия Битрикс24 позволяет индивидуально интегрировать практически любое стороннее решение в ваши рабочие процессы и бизнес-процессы.

Легко интегрируется с любой ERP

Ведение крупного бизнеса требует тщательного планирования и управления. Локальную версию Битрикс24 можно легко интегрировать с выбранной вами ERP-системой.

100+ сторонних интеграций

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

Веб-службы SOAP

Подключайтесь и взаимодействуйте с другими приложениями на языке программирования из вашего Битрикс24.

Скачать Связаться с партнером Битрикс24

Интеграция с AD/LDAP

Интеграция с Office365

MS Exchange (календари)

MS SharePoint (списки)

Мобильный

Неограниченные возможности

Благодаря полному внешнему и внутреннему доступу к коду продукта локальная версия Битрикс24 дает вам практически неограниченные возможности для настройки и локализации.

Пользовательские цвета, макеты и меню

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