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

Обзор

Данные ненормализованные (Города, Области, Населенные пункты, Статусы чеков) – платформа сама нормализует их при обработке.

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

Рекомендованный порядок загрузки данных:

  1. Продуктовые категории (товарный классификатор);

  2. Продукты (товары / номенклатурный справочник);

  3. Клиенты;

  4. Чеки;

  5. Строки чеков;

  6. События;

  7. Бонусный баланс;

  8. Промокоды.

Клиенты

Рекомендованный формат данных по клиенту:

  • 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