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

Обзор

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

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

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

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.