Структура данных
Обзор
Данные ненормализованные (Города, Области, Населенные пункты, Статусы чеков) – платформа сама нормализует их при обработке.
Важно придерживаться правильной последовательности загрузки данных, так как между сущностями существуют зависимости. Например, Номенклатурный справочник зависит Товарного классификатора. В свою очередь Чеки зависят Номенклатурного справочника и Справочника клиентов.
Рекомендованный порядок загрузки данных:
Продуктовые категории (товарный классификатор);
Продукты (товары / номенклатурный справочник);
Клиенты;
Чеки;
Строки чеков;
События;
Бонусный баланс;
Промокоды.
Клиенты
Рекомендованный формат данных по клиенту:
local_id – внутренний идентификатор клиента в мастер-системе, string;
full_name – ФИО, string (может быть пустым) или набор из 3 полей;
first_name – Имя, string (может быть пустым);
middle_name – Отчество, string (может быть пустым);
last_name – Фамилия, string (может быть пустым);
register_date – Дата регистрации, yyyy-mm-dd hh:mm:ss, string;
sex – M/F, char (может быть пустым);
email – email, string (может быть пустым);
phone – номер телефона, string (может быть пустым);
push_id – push-идентификатор, string (может быть пустым);
birth_date – Дата рождения, yyyy-mm-dd, string (может быть пустым);
country – Страна, string (может быть пустым);
city – Населенный пункт, string (может быть пустым);
zip – почтовый индекс, string (может быть пустым);
<любые другие полезные поля, которые есть в клиентской анкете>.
Большинство полей могут быть пустыми, но чем больше передается, тем гибче можно сегментировать и персонализировать.
Поле register_date не может быть пустым и включать в себя даты ранее 2010 года и больше, чем текущий год.
Если есть дополнительные атрибуты клиентов, которые вы хотели бы использовать, их можно передавать в Платформу.
Чеки
Рекомендованный формат данных для чека:
local_id – Внутренний идентификатор чека в мастер-системе, string;
client_id – Внутренний идентификатор клиента в мастер-системе, string (ссылка на client.local_id);
number – Номер чека (который видит клиент), string (может быть пустым);
date – Дата оформления чека, yyyy-mm-dd hh:mm:ss, string;
status – Статус (для заказов; в случае чеков, как правило, не нужен), string (может быть пустым);
items_cnt – Количество единиц продукта (товара) в чеке, float;
items_sum – Сумма чека, money.
<любые другие полезные поля, которые есть в чеке>.
Если есть дополнительные атрибуты, которые вы хотели бы использовать, их можно передавать в Платформу.
Статусы в чеке нужно передавать (и затем обновлять), если чек используется для передачи данных о заказе (например, для интернет-магазинов), и есть необходимость использовать сценарии, завязанные на смену статуса заказа. Например, когда клиент оформил заказ, но долго не вносит за него деньги – взбадриваем его. Или наоборот: при поступлении денег от клиента шлём ему уведомление, что деньги зачислены, и заказ начал движение по статусам.
Поле date не может быть пустым и включать в себя даты ранее 2010 года и больше, чем текущий год.
В поле items_sum не должно быть пробелов (например, 12 345,67 – нельзя).
Строки чеков
Рекомендованный формат данных строки чека:
local_id – Внутренний идентификатор строки чека в мастер-системе, string;
client_id - Внутренний идентификатор клиента в мастер-системе, string (ссылка на client.local_id);
client_order_id – Внутренний идентификатор чека в мастер-системе, string (ссылка на order.local_id);
date – Дата оформления чека, yyyy-mm-dd hh:mm:ss, string;
product_id – Внутренний идентификатор продукта в мастер-системе, string;
price – Цена единицы продукта, money (может быть пустым);
cnt – Количество единиц продукта, float (может быть пустым);
sum – Сумма по строке, money (может быть пустым);
<любые другие полезные поля, которые есть в строке чека>.
Если у вас есть дополнительные атрибуты, которые вы хотели бы использовать, вы можете передавать их в Платформу.
Поле date не может быть пустым и включать в себя даты ранее 2010 года и больше, чем текущий год.
В полях price и sum не должно быть пробелов (например, 12 345,67 – нельзя).
События
Рекомендованный формат данных для события:
local_id – Внутренний идентификатор события в мастер-системе, string;
client_id – Внутренний идентификатор клиента в мастер-системе, string (ссылка на client.local_id; может быть пустым - см. Системное событие);
date – Дата события, yyyy-mm-dd hh:mm:ss, string;
name – Наименование события, string;
context – Контекст события (строка в формате JSON), string (может быть пустым).
Продуктовые категории
Рекомендованный формат данных для классификатора номенклатурного справочника:
local_id – Внутренний идентификатор продуктовой категории в мастер-системе, string;
parent_id – Внутренний идентификатор родительской продуктовой категории в мастер-системе, string;
name – Наименование продуктовой категории, string;
<любые другие полезные поля, которые есть в классификаторе>.
Продукты
Рекомендованный формат данных для продукта:
local_id – Внутренний идентификатор продукта в мастер-системе, string;
name – Наименование продукта, string;
category_id – Внутренний идентификатор продуктовой категории в мастер-системе (category.local_id), string;
sku – Код складского учёта, string (может быть пустым);
supplier – Поставщик, string (может быть пустым);
brand – Бренд, string (может быть пустым);
producer – Производитель, string (может быть пустым);
<любые другие полезные поля, которые есть в продукте>.
Бонусный баланс
Бонусный баланс (при интеграции с платформой лояльности) может передаваться в составе сущности Клиент, либо отдельно.
Рекомендованный формат передачи бонусных балансов:
client_id – Внутренний идентификатор клиента в мастер-системе, string (ссылка на client.local_id).;
bonus_active – бонусов активно, money;
bonus_expect_activate – бонусов ожидает активации, money (может быть пустым);
bonus_expect_deactivate – бонусов ожидает деактивации, money (может быть пустым;
bonus_expect_deactivate_next_date – ближайшая дата деактивации бонусов, yyyy-mm-dd hh:mm:ss, string (может быть пустым);
bonus_expect_deactivate_next_value – ближайшее количество деактивируемых бонусов, money (может быть пустым).
Промокоды
Рекомендованный формат данных для передачи в Платформу промокодов:
code – Текстовое представление промокода, string;
group – Наименование группы промокодов, string.
Last updated