inCust Knowledge Base
Доменна модельСутності

Сутність «Бренд» в системі inCust

Доменна підструктура всередині Бізнесу; володіє Роздрібними Покупцями, операційними активами та конфігурацією клієнтських процесів

🌐 Public

Сутність «Бренд» в системі inCust

Що це таке

Бренд — доменна підструктура всередині Бізнесу, що володіє Роздрібними Покупцями, операційними активами (Точки продажу, Термінали, Товари), Купонами і конфігурацією клієнтських процесів (правила програми лояльності, шаблони повідомлень, податки та збори, налаштування Кредитів за замовчуванням). Бренд є нижчим за Бізнес рівнем у доменній ієрархії: один Бізнес може володіти одним або кількома Брендами, кожен Бренд цілком належить рівно одному Бізнесу. Бренд не є самостійним тенантом — рівнем ізоляції даних залишається Бізнес.

Місце в архітектурі

У технічній архітектурі платформи (DOC-008) Бренд не виділяється як окремий сервіс чи компонент: фронт- і бекенд-кластери, сховища даних, шина подій і канали інтеграцій оперують у межах Бізнесу. Бренд існує як доменна категоризація всередині Бізнес-Панелі та АПІ Бізнес-Панелі — атрибут, що визначає належність ресурсів (Роздрібних Покупців, Точок продажу, Терміналів, Товарів, Купонів, правил, податків і зборів, налаштувань Кредитів) і застосовується для фільтрації, перевірок доступу та звітності. В АПІ Бізнес-Панелі (Business API, KNOW-006) ця категоризація матеріалізована як ресурс loyalty з ідентифікатором loyalty_id — окремого ресурсу brand у специфікації немає (див. розділ «Представлення в API»).

Доменна ієрархія:

Бізнес  →  Бренд  →  Точка продажу  →  Термінал

Робітники, як суб'єкти прав, належать Бізнесу (див. entity-business.md). Бренд виступає об'єктом прав: ролі, видані Бізнесом — насамперед «Менеджер Бренду» і «Менеджер Бренду / Тільки перегляд» — обмежують операції Робітника даними одного або кількох Брендів цього Бізнесу. Доступ до конкретних Терміналів регулюється окремим списком Терміналів Робітника (DOC-009).

Модель володіння

Належність сутностей Бренду узгоджена з моделлю володіння Бізнесу (entity-business.md).

Бренду напряму належать

  • Роздрібні Покупці — прив'язані до конкретного Бренду; Бізнес отримує контроль над ними опосередковано, через володіння цим Брендом.
  • Точки продажу.
  • Термінали — касові термінали, кіоски самообслуговування, паливні диспенсери, мийки тощо.
  • Товари.
  • Зовнішні форми.
  • Купони і серії купонів — самостійна сутність Бренду зі своєю механікою випуску, видачі та погашення. Купони можуть видаватись і погашатись у межах правил програми лояльності, але це лише один зі сценаріїв використання; випуск і застосування Купонів можливі й поза програмою лояльності.
  • Програма лояльності для клієнтів Бренду — товарні, чекові та купонні правила (правила, які видають вигоду за пред'явленим Купоном) і пов'язані налаштування Бренду (DOC-010).
  • Шаблони повідомлень для подій у межах Бренду.
  • Податки та збори (DOC-016).
  • Налаштування Кредитів за замовчуванням — пов'язаний рахунок, часова зона, дата періоду, ліміти на кількість і суму активних Кредитів Покупця, авто-погашення, овердрафт, інформування Клієнта, адреси електронної пошти Бізнесу для оповіщень про події Кредиту, URL зворотного виклику (webhook) для зовнішнього інформування (DOC-033).

Поліморфне володіння (Бізнес АБО Бренд)

  • Транзакції — на Бренд припадають роздрібні продажі, нарахування лояльності та термінальні операції; на Бізнес — операції з рахунком/бонусами Бізнесу. Операції з Корпоративними Покупцями за замовчуванням належать Бізнесу безпосередньо, але якщо виконані через Термінал, належать відповідному Бренду.
  • Повідомлення — на Бренд припадають маркетингові та транзакційні повідомлення Покупцям Бренду; на Бізнес — системні/організаційні повідомлення і повідомлення Корпоративним Покупцям.

Бренду НЕ належать

  • Робітники — належать Бізнесу безпосередньо; роль і список доступних Терміналів визначають, з якими Брендами Робітник фактично працює.
  • Корпоративні Покупці — належать Бізнесу безпосередньо, поза контекстом конкретного Бренду.
  • Налаштування моделі кредитування з фінансуванням роботодавцем (спеціальні рахунки типу «Кредитний з лімітом», розстрочки) — належать Бізнесу. Бренд задає лише значення за замовчуванням і обмеження, що застосовуються при створенні конкретних Кредитів у цій моделі (DOC-033).
  • Рахунок Бізнесу і Бонуси Бізнесу, АПІ-ключ Бізнесу, налаштування рольової моделі — Бізнес-рівень.

Режими роботи

Налаштування на рівні Бренду визначають варіанти поведінки бізнес-логіки в межах цього Бренду без впливу на інші Бренди того самого Бізнесу:

  • Схема розрахунку правил лояльності — «Найбільша вигода» або «Сума вигод» (DOC-010).
  • Поведінка купонів і правил — опція «При використанні купонів не використовувати правила програми лояльності» (DOC-010).
  • Параметри Кредитів за замовчуванням (DOC-033): пов'язаний рахунок, дата початку розрахункового періоду, часова зона, автоматичне погашення Чергових платежів, дозвіл овердрафту, інформування Клієнта.
  • Ліміти на одного Покупця в межах моделі кредитування з фінансуванням роботодавцем: кількість одночасно активних (не виплачених) Кредитів і допустима сумарна сума активних Кредитів (необмежені або задані числом).

Фінансово-облікові аспекти

Бренд є точкою конфігурації фінансових процесів, але не самостійним обліковим суб'єктом — фінансові операції фіксуються на рахунках Покупця та в журналі транзакцій (з належністю Бізнесу або Бренду згідно з правилами поліморфного володіння). На рівні Бренду налаштовуються:

  • Податки та збори (DOC-016).
  • Програма лояльності як набір правил, що породжують знижки, нарахування бонусів, нарахування на рахунки Покупця і випуск Купонів (DOC-010).
  • Значення за замовчуванням для Кредитів: рахунок за замовчуванням (тип «Гроші», тип за лімітами «Кредитний з лімітом»), на який посилаються створювані Кредити Роздрібних Покупців; списки адрес електронної пошти Бізнесу та URL зворотного виклику для оповіщень про події Кредиту (створення, повне погашення, списання Чергових платежів, помилки списання). Сама модель кредитування з фінансуванням роботодавцем налаштовується на рівні Бізнесу (DOC-033).

Транзакції списань Чергових платежів проводяться з типом special-account-write-offs і підтипом special-account-write-offs-loan, з посиланням на сутність Чергового платежу; рівень налаштування поведінки за замовчуванням (овердрафт, автоматичне чи ручне погашення) — Бренд.

Представлення в API

У Business API (KNOW-006) Бренд представлений ресурсом loyalty з ідентифікатором loyalty_id. Окремого ресурсу brand у специфікації немає: loyalty_id є технічним дескриптором Бренду, під яким згруповані всі підпорядковані ресурси і за яким відбувається фільтрація та перевірка прав. Власне програма лояльності (набір правил) — це підколекція rules всередині цього ресурсу, а не самостійний об'єкт верхнього рівня. Робота з тими самими ресурсами в контексті продажу виконується через Terminal API (KNOW-009), у контексті Роздрібного Покупця — через Client API (KNOW-008), але вже без керування конфігурацією Бренду.

Сам Бренд

  • GET /loyalty — список Брендів Бізнесу; POST /loyalty — створення Бренду.
  • GET /loyalty/{loyalty_id}, PATCH /loyalty/{loyalty_id} — читання та зміна Бренду.
  • GET|PATCH /loyalty/{loyalty_id}/settings — налаштування Бренду.
  • POST|DELETE /loyalty/{loyalty_id}/photo — фото Бренду.
  • GET|PATCH /loyalty/{loyalty_id}/online_store — налаштування онлайн-магазину.
  • GET|PATCH /loyalty/{loyalty_id}/pkpass/settings — налаштування карток pkpass.
  • GET /embedded/loyalties — список Брендів для embedded-віджетів.

Програма лояльності та правила

  • GET|POST /loyalty/{loyalty_id}/rules, GET|PATCH /loyalty/{loyalty_id}/rules/{rule_id} — товарні, чекові та купонні правила.
  • GET|PATCH /loyalty/{loyalty_id}/rules/settings — схема розрахунку («Найбільша вигода» / «Сума вигод») і поведінка купонів.
  • GET|POST /loyalty/{loyalty_id}/card_categories…, …/card_categories_rules, …/card_categories_settings — категорії карток та правила за категоріями.

Точки продажу

  • GET /pos — усі Точки продажу; POST /pos — створення (Бренд задається через loyalty_id у тілі); GET /loyalty/{loyalty_id}/pos — Точки конкретного Бренду.
  • GET|PATCH /pos/{pos_id} і підресурси …/online_store, …/references, …/photo; GET /pos/{pos_id}/terminals.

Термінали

  • GET /terminal, POST /terminal (Точка задається через pos_id у тілі); GET|PATCH /terminal/{terminal_id}.
  • Підресурси: …/settings/application, …/settings/external_devices/{amp|pax|stripe}, …/staff, …/notifications/settings, …/generate_ibeacon, …/update_apikey, …/goods.

Товари, ціни, податки, витрати

  • GET|POST /loyalty/{loyalty_id}/price_groups… — цінові групи, майстер-ціни, матриці цін.
  • GET|POST|DELETE /loyalty/{loyalty_id}/taxes…, …/taxes/summary — податки та збори.
  • …/additional_costs, …/additional_services — витрати/націнки та додаткові послуги.

Купони і серії купонів

  • GET|POST /coupons/batches, GET|PATCH /coupons/batch/{batch_id} — серії (ID Бренду береться з тіла запиту).
  • …/batch/{batch_id}/emission, …/coupons/send, …/aliases, …/external_codes, …/links — випуск, розсилання, аліаси, зовнішні коди, посилання.
  • GET /coupons/coupon/{code}, …/cancel — окремий купон.

Шаблони повідомлень

  • GET|PATCH /loyalty/{loyalty_id}/customers_messages, …/customers_messages_groups, …/customers_messages_values, …/customers_messages/template_test.

Програма рекомендацій

  • GET|PATCH /loyalty/{loyalty_id}/referral_program та ендпоінти логотипів referral/referrer (підсистема лояльності Бренду, KNOW-014).

Зворотний зв'язок

  • GET|PATCH /customer_feedback/loyalty/{loyalty_id}/settings, …/feedback_sources; аналогічні налаштування на рівні pos і terminal.

Обладнання та паливо

  • GET|POST /equipment/{loyalty_id}/controllers…, GET|POST /fuel/{loyalty_id}/controllers… — контролери обладнання та паливних колонок.

Налаштування Кредитів за замовчуванням, які Бренд задає, у специфікації представлені через пов'язані special_account-ресурси; сама модель кредитування з фінансуванням роботодавцем налаштовується на рівні Бізнесу.

Наслідки для запитів і доступу

Рольова модель (DOC-009). Усі ролі видає Бізнес; Бренд є об'єктом, до якого ці ролі застосовуються:

  • Менеджер Бренду — повний доступ до функціоналу управління Брендом, без доступу до даних і налаштувань Бізнесу.
  • Менеджер Бренду / Тільки перегляд — те саме, лише читання.
  • Ролі Менеджер Покупців, Менеджер Корпоративних Покупців, Менеджер Транзакцій (і їхні / Тільки перегляд варіанти) не мають управління Брендом, але отримують обмежений доступ на читання списку Брендів, Точок продажу, Терміналів — для контексту відображення Покупців і Транзакцій.
  • Доступ Робітника до конкретного Терміналу регулюється окремим списком Терміналів, а не роллю; роль Менеджер Терміналу (Касир) надається автоматично за наявності хоча б одного Терміналу в списку — Робітник може мати доступ не до всіх Терміналів Бренду.

Запити і фільтрація. Запити до АПІ Бізнес-Панелі, що повертають Роздрібних Покупців, Точки продажу, Термінали, Товари, Купони, правила, Кредити, фільтруються за Брендом (явно або через межі прав Робітника) — на рівні специфікації це фільтр за loyalty_id. Для запитів «за Бізнесом» (звітність, аудит) потрібно враховувати обидва шляхи доступу — прямий (сутності Бізнесу) і транзитивний (сутності всіх Брендів цього Бізнесу), згідно з entity-business.md.

Зовнішні точки входу

  • Бізнес-Панель (https://business.incust.com/, DOC-032) — основний інтерфейс управління Брендами, їх налаштуваннями, Точками продажу і Терміналами.

Джерела з Shared Drive

On this page