RetailCRM pro


Channel's geo and language: Russia, Russian


Официальный канал RetailCRM с техническими обновлениями.
@retailcrm — наш основной канал. В нем мы постим кейсы, новые интеграции и полезные статьи.
@retailCRMbot — отвечаем на вопросы, связанные с RetailCRM

Related channels

Channel's geo and language
Russia, Russian
Statistics
Posts filter


Тип пользовательского поля «Дата-время»

Новый тип пользовательских полей «Дата-время» открыт всем пользователям и доступен для работы и в интерфейсе, и в API/pipelang/twig.


Округление в большую или меньшую сторону в pipelang-функции round()

В pipelang-функцию round() добавлен третий параметр method с тремя вариантами значениями: common, ceil, floor (по-умолчанию common).

Наряду со стандартным режимом округления (method=common) можно указать принудительное округление в большую (method=ceil) или меньшую сторону (method=floor)

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

Примеры использования:

round(12.3456) # 12
round(12.3456, 2) # 12.35
round(12.3456, 2, "floor") # 12.34
round(12.3456, 0, "ceil") # 13.0
round(-1.5, 0, "ceil") # -1.0

Описание функции в документации https://docs.retailcrm.ru/Developers/Automation/PipeLang/Expressionlanguage/AvailableFunctions#h-1


Особенности передачи услуг в интеграционные доставки

В callback методах POST {integrationModule["baseUrl"]}/{integrationModule["integrations"]["delivery"]["actions"]["calculate"]} и POST {integrationModule["baseUrl"]}/{integrationModule["integrations"]["delivery"]["actions"]["save"]} поля save[packages][][items][][weight] и save[packages][][items][][unit] могут принимать значение null для услуг. Услуги в составе упаковок передаются только в случае наложенного платежа, когда необходимо взять плату за услугу.

#services


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

При создании оплаты в интеграционном модуле оплаты посредством коллбека POST {integrationModule["baseUrl"]}/{integrationModule["integrations"]["payment"]["actions"]["create"]} позиции заказа, являющиеся услугами, передаются со значением create[items][][paymentObject]=service

Описание метода в документации

#services


Запрет передачи кода маркировки для позиций заказа, являющихся услугами

В API-методах создания заказа POST /api/v5/orders/create и редактирования заказа POST /api/v5/orders/{externalId}/edit будет выдана ошибка "Services are not subject to marking", если код маркировки передается для позиции заказа, являющейся услугой.

#services


Запрет на создание паков для позиций заказа, являющихся услугами

В API-методе создания пака POST /api/v5/orders/packs/create будет выдана ошибка "Pack creating is not allowed for service items", если позиция заказа, для которой создается пак, является услугой.

Подробнее в документации:
* POST /api/v5/orders/packs/create

#services


Тип товара в API-методе создания товаров. Новые правила обработки входных данных в API-методах создания и редактирования товаров

1. В запросе API-метода пакетного создания товаров POST /api/v5/store/products/batch/create можно указать тип создаваемого товара. Допускается 2 варианта значений: product (товар) и service (услуга). Если тип не указан, то по умолчанию type=product.
2. В API-методах создания POST /api/v5/store/products/batch/create и редактирования товаров POST /api/v5/store/products/batch/edit для услуг (type=service) игнорируются переданные значения полей products[][manufacturer] и products[][markable].

Подробнее в документации:
* POST /api/v5/store/products/batch/create
* POST /api/v5/store/products/batch/edit

#services


Тип товара в API-методе получения товаров

В ответе API-метода GET /api/v5/store/products добавлено поле products[][type], обозначающее тип товара с вариантами значений: product (товар) и service (услуга).

Описание GET /api/v5/store/products

#services


Тип товара в Sandbox

В справочнике объектов доступно поле Product.typeCode. Возможные варианты значений: product (товар) и service (услуга).

Описание Product в справочнике объектов

#services


Работа с Услугами

У товаров в системе добавился атрибут Тип с двумя вариантами значений: товар product и услуга service.

Отличием услуг от товаров является:
1. Отсутствие информации в полях Единица измерения, Производитель, Признак маркировки, Вес, Габариты (длина, ширина, высота), а также отсутствия понятия остатков
2. Услуги, добавленные в состав заказа, не отслеживаются в маркировке, складских операциях (бронирование позиций заказа, отгрузка и тд), расчете веса и габаритов заказа. Услуги передаются с соответствующим признаком в фискальный чек Атол.Онлайн и интеграционные оплаты. Услуги передаются в интеграционную доставку только в случае наложного платежа, в остальных случаях не передаются.

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

#services


Новый тип пользовательского поля «Дата-время»

В системе появился тип пользовательского поля «Дата-время» (символьный код типа datetime). Поля данного типа поддерживаются во всех сущностях (клиент, корпоративный клиент, заказ, участие программы лояльности), что и другие типы полей.

В интерфейсе системы данный тип поля пока скрыт, но доступен для работы через API, pipelang и twig.


Новый API-метод веб-аналитики

POST /api/v5/web-analytics/visits/upload — позволяет осуществлять пакетную загрузку визитов.
Открывается возможность интеграции новых систем сбора аналитики.

На основе визитов появляется возможность сегментации клиентов, которые:

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

Подробнее в документации.


Поле catalogId у товаров в API-методе получения товаров

В API-методе GET /api/v5/store/products теперь возвращается поле products[][catalogId], обозначающее, к какому каталогу относится товар. Это поможет различать товары разных каталогов и магазинов в случае, когда у API-ключа доступ ко всем магазинам.

Соответствие каталогов и магазинов можно определить по данным из метода GET /api/v5/reference/sites (поля sites[][catalogId] и sites[][isCatalogMainSite]).

Подробнее в документации метода.


Идентификатор API-ключа в истории изменений заказа/клиента/задачи

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

Раньше через поле history[][apiKey][current] можно было только узнать, использовался ли текущий API-ключ, с которым выполняется запрос, для того или иного изменения в наборе записей истории. Теперь же в поле history[][apiKey][id] для каждого изменения, сделанного через API, возвращается идентификатор того ключа, с правами которого было внесено это изменение.

Подробнее в документации:

GET /api/v5/customers/history
GET /api/v5/customers-corporate/history
GET /api/v5/orders/history
GET /api/v5/tasks/history


Идентификатор API-ключа в Sandbox

В справочник объектов добавлен объект ApiKey, дающий возможность работать с сущностью API-ключа в выражениях. В объекте на данный момент доступно одно целочисленное поле id - уникальный в рамках CRM идентификатор API-ключа. В набор изменений EntityChangeSet в свою очередь было добавлено поле apiKeyOfChange типа ApiKey.

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

Подробнее про новые типы и поля — в справочнике объектов.


Заказы

В метод апи GET /api/v5/orders добавлен новый фильтр filter[deliveryServices][] по службам доставки.

Подробнее в документации.


Получение списка складов

В метод апи GET /api/v5/reference/stores добавлена возможность получения контактного лица на складе, параметр stores[][contact].

Подробнее в документации.


Получение настроек чатов через API

Теперь в методе GET /api/v5/settings возвращаются настройки чатов, связанные с оформлением заказа (Настройки>Чаты>Оформление заказа):

settings[mg][order_creation] — параметры, которые будут автоматически указываться в заказе при оформлении из чатов.

Параметры по умолчанию settings[mg][order_creation][default]:

• settings[mg][order_creation][default][site] — магазин
• settings[mg][order_creation][default][order_type] — тип заказа
• settings[mg][order_creation][default][order_method] — метод оформления

Параметры для отдельных каналов возвращаются в виде ассоциативного массива settings[mg][order_creation][channels][], где ключом является externalId канала:

• settings[mg][order_creation][channels][][site] — магазин
• settings[mg][order_creation][channels][][order_type] — тип заказа
• settings[mg][order_creation][channels][][order_method] — метод оформления

Также при изменении этих настроек будет вызываться callback для интеграций: POST /api/v5/{integrationModule["baseUrl"]}/{integrationModule["actions"]["settings"]}

Пример использования

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

Подробнее в документации:

GET /api/v5/settings
callback POST /api/v5/{integrationModule["baseUrl"]}/{integrationModule["actions"]["settings"]}


Уменьшится количество элементов в ответе списковых методов Bot API по умолчанию

C 1 августа изменится лимит по умолчанию в ответе на списковые методы с 1000 на 100. Если Вам необходимо получать более 100 элементов за 1 запрос, остается доступным передача значения в параметре limit.

Список методов которые затронут изменения:

GET /bots Получение списка ботов
GET /channels Получение списка каналов
GET /chats Получение списка чатов
GET /customers Получение списка клиентов
GET /dialogs Получение списка диалогов
GET /members Получение списка участников чата
GET /messages Получение списка сообщений
GET /my/commands Получение списка команд бота
GET /users Получение списка менеджеров


Мультивалютность

В RetailCRM появилась поддержка мультивалютности. На данный момент она скрыта от пользователей и проходит бета-тестирование.

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

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

#multicurrency

20 last posts shown.