Технічне завдання: Афіліантська система

Афіліатська система в K2 ERP

Афіліатська система в K2 ERP — модуль для обліку партнерів, реферальних кодів, залучених клієнтів, продажів, комісійних нарахувань, коригувань і виплат афіліатам.

1. Мета розробки

Розробити в K2 ERP функціонал, який дозволяє:

• реєструвати афіліатів;
• створювати афіліатські програми;
• генерувати реферальні коди та посилання;
• привʼязувати клієнтів до афіліатів;
• нараховувати комісії з продажів;
• враховувати повернення та сторно;
• формувати виплати;
• аналізувати ефективність партнерів;
• контролювати права доступу;
• вести історію змін.

2. Короткий опис бізнес-процесу

1. Менеджер створює афіліата в K2 ERP.
2. Система генерує унікальний реферальний код.
3. Афіліат залучає клієнта через посилання або код.
4. Клієнт реєструється або оформлює замовлення.
5. K2 ERP привʼязує клієнта до афіліата.
6. Клієнт здійснює оплату.
7. Система перевіряє правила афіліатської програми.
8. Система створює комісійне нарахування.
9. Після hold-періоду комісія стає доступною до виплати.
10. Бухгалтер формує виплату афіліату.
11. Після виплати комісія отримує статус “Виплачено”.

3. Основні ролі користувачів

Роль	Опис	Основні права
Адміністратор	Налаштовує систему, програми, ставки, права доступу.	Повний доступ.
Менеджер партнерської програми	Працює з афіліатами, контролює привʼязки клієнтів і комісії.	Створення афіліатів, перегляд продажів, підтвердження комісій.
Бухгалтер	Формує та проводить виплати.	Перегляд комісій, створення виплат, звʼязок з платіжними документами.
Керівник	Аналізує ефективність партнерської програми.	Перегляд звітів.
Афіліат	Партнер, який залучає клієнтів.	Перегляд власної статистики, комісій і виплат.

4. Терміни та визначення

Термін	Визначення
Афіліат	Партнер, який залучає клієнтів і отримує комісію.
Афіліатська програма	Набір правил, за якими афіліату нараховується винагорода.
Реферальний код	Унікальний код афіліата для ідентифікації джерела клієнта.
Реферальне посилання	Посилання з ref-кодом афіліата.
Лід	Потенційний клієнт, який прийшов від афіліата.
Клієнт	Контрагент або покупець у K2 ERP.
Конверсія	Цільова дія клієнта: реєстрація, оплата, покупка.
Комісія	Винагорода афіліата за залученого клієнта або продаж.
Hold-період	Період очікування перед тим, як комісія стане доступною до виплати.
Attribution window	Період, протягом якого продаж клієнта закріплюється за афіліатом.
Виплата	Фактичне перерахування винагороди афіліату.

5. Важливі правила реалізації

Статус	Правило	Коментар
Обовʼязково	Кожен афіліат має унікальний код.	Код використовується для привʼязки клієнтів і продажів.
Обовʼязково	Комісія не повинна дублюватися по одному продажу.	Потрібен унікальний ключ на рівні продажу та афіліата.
Обовʼязково	Ставка комісії фіксується в момент створення нарахування.	Зміна ставки в майбутньому не має змінювати старі нарахування.
Важливо	Повернення має коригувати комісію.	Якщо комісія вже виплачена — створюється мінусове коригування.
Важливо	Клієнт має прозору історію привʼязки до афіліата.	Потрібно зберігати дату, джерело й користувача, який змінив привʼязку.
Заборонено	Видаляти проведені комісійні нарахування.	Дозволено тільки скасування або коригування.
Заборонено	Змінювати виплачену комісію напряму.	Потрібно створювати документ коригування.

6. Функціональні модулі

Система має складатися з таких функціональних блоків:

• довідник афіліатів;
• довідник афіліатських програм;
• реферальні коди та посилання;
• журнал переходів;
• ліди;
• привʼязка клієнтів до афіліатів;
• комісійні нарахування;
• коригування комісій;
• виплати афіліатам;
• звіти;
• антифрод-перевірки;
• аудит змін;
• API для зовнішнього сайту або CRM;
• особистий кабінет афіліата, якщо передбачено.

7. Довідник “Афіліати”

Необхідно створити довідник Афіліати.

7.1. Поля картки афіліата

Поле	Тип	Обовʼязкове	Опис
ID	UUID / integer	Так	Унікальний ідентифікатор афіліата.
Код афіліата	string	Так	Унікальний реферальний код.
Назва / ПІБ	string	Так	Назва компанії або ПІБ партнера.
Тип афіліата	enum	Так	Фізична особа, ФОП, юридична особа, агентство, блогер, партнер.
Статус	enum	Так	Новий, активний, заблокований, архівний.
Email	string	Так	Контактний email.
Телефон	string	Ні	Контактний телефон.
Контрагент K2 ERP	reference	Ні	Посилання на контрагента в ERP.
Відповідальний менеджер	reference	Ні	Менеджер, який веде афіліата.
Афіліатська програма	reference	Так	Програма, до якої підключено афіліата.
Індивідуальна ставка	decimal	Ні	Ставка, яка має пріоритет над ставкою програми.
Валюта	enum	Так	Валюта нарахувань.
Мінімальна сума виплати	decimal	Ні	Поріг, після якого можна створити виплату.
Дата реєстрації	datetime	Так	Дата створення афіліата.
Дата активації	datetime	Ні	Дата переведення у статус “Активний”.
Коментар	text	Ні	Внутрішній коментар менеджера.

7.2. Статуси афіліата

Статус	Опис	Вплив на нарахування
Новий	Афіліат створений, але ще не активований.	Нові комісії не нараховуються.
Активний	Афіліат може залучати клієнтів.	Комісії нараховуються.
Заблокований	Афіліат тимчасово заблокований.	Нові комісії не нараховуються.
Архівний	Афіліат більше не використовується.	Нові комісії не нараховуються.

8. Довідник “Афіліатські програми”

Необхідно створити довідник Афіліатські програми.

8.1. Поля програми

Поле	Тип	Обовʼязкове	Опис
Назва програми	string	Так	Назва афіліатської програми.
Код програми	string	Так	Унікальний код програми.
Статус	enum	Так	Активна, призупинена, архівна.
Тип комісії	enum	Так	Відсоток, фіксована сума, змішана, tiered.
Базова ставка	decimal	Так	Основна ставка програми.
Фіксована сума	decimal	Ні	Використовується для фіксованої або змішаної комісії.
Валюта	enum	Так	Валюта програми.
Hold-період	integer	Так	Кількість днів до доступності виплати.
Attribution window	integer	Так	Кількість днів, протягом яких продаж закріплюється за афіліатом.
Комісія з першої покупки	boolean	Так	Чи нараховується винагорода за першу покупку.
Комісія з повторних покупок	boolean	Так	Чи нараховується винагорода за повторні покупки.
Максимальна кількість нарахувань на клієнта	integer	Ні	Обмеження кількості комісій по одному клієнту.
Дата початку	date	Так	Дата старту програми.
Дата завершення	date	Ні	Дата завершення програми.

8.2. Типи комісій

Тип комісії	Опис	Приклад
Відсоток	Комісія рахується як відсоток від бази розрахунку.	10% від суми продажу.
Фіксована сума	Афіліат отримує фіксовану винагороду за конверсію.	500 грн за нового клієнта.
Змішана	Фіксована сума плюс відсоток.	200 грн + 5% від продажу.
Tiered	Ставка залежить від обсягу продажів або кількості клієнтів.	До 100 000 грн — 5%, понад 100 000 грн — 8%.

9. Реферальні коди та посилання

9.1. Генерація реферального коду

Система має автоматично генерувати унікальний код для кожного афіліата.

Приклади кодів:

AFF-000001
PARTNER-KYIV-001
BLOGGER-ANNA

9.2. Формат реферального посилання

Приклад базового посилання:

https://site.com/?ref=AFF-000001

Приклад посилання на реєстрацію:

https://site.com/register?affiliate=AFF-000001

9.3. Вимоги до коду

Вимога	Опис
Унікальність	Один код не може належати двом афіліатам.
Стабільність	Код не має змінюватися без окремого дозволу.
Ручне редагування	Адміністратор може змінити код, якщо це дозволено правами.
Перевірка дублів	При збереженні система перевіряє, що код не зайнятий.
Історія змін	Зміна коду має потрапляти в audit log.

10. Привʼязка клієнтів до афіліатів

10.1. Способи привʼязки

Спосіб	Опис
Ref-посилання	Клієнт перейшов за посиланням із кодом афіліата.
Ручне введення коду	Менеджер або клієнт вводить код афіліата вручну.
API	Сайт, CRM або інша система передає ref-код у K2 ERP.
Ручна привʼязка менеджером	Менеджер обирає афіліата в картці клієнта.
Імпорт	Привʼязки завантажуються з файлу або зовнішньої системи.

10.2. Поля в картці клієнта

У картці клієнта потрібно додати поля:

Поле	Тип	Опис
Афіліат	reference	Поточний афіліат клієнта.
Афіліатський код	string	Код, за яким клієнт був залучений.
Дата привʼязки	datetime	Дата привʼязки клієнта до афіліата.
Джерело привʼязки	enum	ref_link, manual, api, import.
Attribution expires at	datetime	Дата завершення attribution window.
Привʼязка заблокована	boolean	Якщо true, автоматична зміна афіліата заборонена.
Коментар привʼязки	text	Причина або додатковий опис.

10.3. Правила attribution

Система має підтримувати такі варіанти attribution:

Правило	Опис
First click	Клієнт закріплюється за першим афіліатом.
Last click	Клієнт закріплюється за останнім афіліатом перед покупкою.
Manual priority	Ручна привʼязка менеджером має пріоритет.

10.4. Рекомендоване правило для MVP

Для першої версії рекомендується правило:

Manual priority → First successful registration → First click

Тобто:

1. Якщо менеджер вручну привʼязав клієнта — використовується ручна привʼязка.
2. Якщо клієнт зареєструвався з ref-кодом — використовується цей ref-код.
3. Якщо є тільки перехід — використовується перший валідний перехід.

11. Ліди

Необхідно створити журнал або документ Афіліатські ліди.

11.1. Поля ліда

Поле	Тип	Опис
ID	UUID / integer	Унікальний ID ліда.
Афіліат	reference	Афіліат, який залучив ліда.
Ref-код	string	Код, переданий у заявці.
Імʼя	string	Імʼя ліда.
Телефон	string	Телефон.
Email	string	Email.
Джерело	string	Сайт, форма, рекламна кампанія.
UTM source	string	UTM-джерело.
UTM medium	string	UTM-канал.
UTM campaign	string	UTM-кампанія.
Статус	enum	new, contacted, converted, rejected, duplicate.
Клієнт K2 ERP	reference	Посилання на створеного клієнта.
Дата створення	datetime	Дата створення ліда.

12. Продажі та комісійні нарахування

12.1. Подія для нарахування комісії

Комісія може нараховуватися при таких подіях:

Подія	Опис
Оплата замовлення	Комісія створюється після фактичної оплати.
Відвантаження	Комісія створюється після відвантаження товару.
Закриття продажу	Комісія створюється після завершення документа продажу.
Завершення періоду повернення	Комісія створюється після завершення періоду, коли клієнт може повернути товар.

12.2. Рекомендоване правило для MVP

Комісія створюється після успішної оплати документа продажу.
Комісія переходить у статус “Доступна до виплати” після завершення hold-періоду.

12.3. База для розрахунку комісії

Система має підтримувати налаштування бази розрахунку:

Варіант	Опис
Сума документа з ПДВ	Комісія рахується від повної суми продажу.
Сума без ПДВ	Комісія рахується від суми без податків.
Маржа	Комісія рахується від прибутку.
Оплачена сума	Комісія рахується тільки від фактично оплаченої суми.
Категорії товарів	Комісія рахується тільки по товарах, які беруть участь у програмі.

12.4. Рекомендована база для MVP

Комісія = оплачена сума документа × ставка афіліата

Альтернативний варіант:

Комісія = оплачена сума без повернень × ставка афіліата

13. Формули розрахунку комісії

13.1. Відсоткова комісія

commission_amount = base_amount × commission_rate / 100

Приклад:

base_amount = 10 000 грн
commission_rate = 10%
commission_amount = 1 000 грн

13.2. Фіксована комісія

commission_amount = fixed_amount

Приклад:

500 грн за нового клієнта

13.3. Змішана комісія

commission_amount = fixed_amount + base_amount × commission_rate / 100

13.4. Tiered-комісія

Місячний обсяг продажів	Ставка
0–50 000 грн	5%
50 001–100 000 грн	7%
100 001+ грн	10%

14. Документ “Афіліатське нарахування”

Потрібно створити документ або регістр Афіліатське нарахування.

14.1. Поля нарахування

Поле	Тип	Опис
ID	UUID / integer	Унікальний ID нарахування.
Афіліат	reference	Партнер, якому нарахована комісія.
Клієнт	reference	Клієнт, який зробив покупку.
Документ продажу	reference	Продаж у K2 ERP.
Афіліатська програма	reference	Програма, за якою створено нарахування.
База розрахунку	decimal	Сума, від якої рахується комісія.
Ставка	decimal	Ставка, зафіксована на момент нарахування.
Фіксована сума	decimal	Якщо використовується фіксована або змішана комісія.
Сума комісії	decimal	Розрахована винагорода.
Валюта	enum	Валюта нарахування.
Статус	enum	pending, hold, approved, available, rejected, paid, cancelled.
Hold until	date	Дата, після якої комісія доступна до виплати.
Причина відхилення	text	Заповнюється при rejected або cancelled.
Дата створення	datetime	Дата створення.
Дата оновлення	datetime	Дата останньої зміни.

14.2. Статуси нарахування

Статус	Опис
pending	Нарахування створене, але ще не перевірене.
hold	Нарахування очікує завершення hold-періоду.
approved	Нарахування підтверджене менеджером.
available	Нарахування доступне до виплати.
rejected	Нарахування відхилене.
paid	Нарахування виплачене.
cancelled	Нарахування скасоване через повернення або сторно.

14.3. Життєвий цикл нарахування

pending → hold → available → paid
pending → rejected
hold → cancelled
available → paid
available → cancelled
paid → adjustment

15. Повернення та сторно

15.1. Повне повернення

Якщо продаж повністю повернуто:

1. Якщо комісія ще не виплачена — скасувати нарахування.
2. Якщо комісія вже виплачена — створити мінусове коригування.

15.2. Часткове повернення

Якщо повернуто частину товарів:

1. Перерахувати базу комісії.
2. Зменшити суму комісії.
3. Якщо комісія ще не виплачена — змінити або скасувати нарахування.
4. Якщо комісія вже виплачена — створити мінусове коригування.

15.3. Документ “Коригування афіліатської комісії”

Поле	Тип	Опис
ID	UUID / integer	Унікальний ID коригування.
Афіліат	reference	Партнер.
Початкове нарахування	reference	Нарахування, яке коригується.
Документ повернення	reference	Документ повернення в K2 ERP.
Сума коригування	decimal	Додатна або відʼємна сума.
Причина	text	Причина коригування.
Статус	enum	draft, approved, applied, cancelled.
Дата створення	datetime	Дата створення.

16. Виплати афіліатам

Потрібно створити документ Виплата афіліату.

16.1. Поля документа виплати

Поле	Тип	Опис
Номер виплати	string	Унікальний номер документа.
Афіліат	reference	Отримувач виплати.
Період	date range	Період, за який формується виплата.
Сума до виплати	decimal	Загальна сума нарахувань у виплаті.
Валюта	enum	Валюта виплати.
Статус	enum	draft, approved, paid, cancelled.
Спосіб виплати	enum	IBAN, card, PayPal, manual, інше.
Платіжний документ	reference	Звʼязок із бухгалтерським або банківським документом.
Дата створення	datetime	Дата створення.
Дата виплати	datetime	Дата фактичної виплати.

16.2. Таблична частина виплати

Поле	Тип	Опис
Нарахування	reference	Афіліатське нарахування.
Документ продажу	reference	Продаж, за який нарахована комісія.
Клієнт	reference	Клієнт продажу.
Сума комісії	decimal	Сума до виплати.
Валюта	enum	Валюта рядка.

16.3. Правила формування виплати

Правило	Опис
Тільки available	У виплату можна включати тільки нарахування зі статусом `available`.
Один раз	Одне нарахування не може бути включене у дві виплати.
Мінімальна сума	Якщо сума менша за мінімальний поріг, виплата не створюється.
Після проведення	Після проведення виплати нарахування отримують статус `paid`.
Скасування	При скасуванні виплати нарахування повертаються у статус `available`.

17. Особистий кабінет афіліата

Цей розділ реалізується, якщо в K2 ERP є зовнішній портал або партнерський кабінет.

17.1. Функції кабінету

Афіліат має бачити:

• свій реферальний код;
• реферальні посилання;
• кількість переходів;
• кількість лідів;
• кількість клієнтів;
• кількість продажів;
• суму продажів;
• суму комісій;
• комісії в hold;
• доступно до виплати;
• виплачено;
• історію виплат.

17.2. Dashboard афіліата

Показник	Опис
Переходи	Кількість кліків за реферальним посиланням.
Ліди	Кількість потенційних клієнтів.
Клієнти	Кількість зареєстрованих клієнтів.
Продажі	Кількість і сума продажів.
Конверсія	Відсоток переходів, які стали лідами або продажами.
Комісія в hold	Нарахування, які ще не доступні до виплати.
Доступно до виплати	Сума, яку можна виплатити.
Виплачено	Загальна виплачена сума.

18. Трекінг переходів

Необхідно створити журнал Афіліатські переходи.

18.1. Поля журналу переходів

Поле	Тип	Опис
ID	UUID	Унікальний ID кліку.
Афіліат	reference	Партнер.
Код афіліата	string	Код із URL.
URL	string	Сторінка переходу.
UTM source	string	Джерело.
UTM medium	string	Канал.
UTM campaign	string	Кампанія.
IP	string	IP-адреса.
User Agent	string	Браузер або пристрій.
Session ID	string	Ідентифікатор сесії.
Created at	datetime	Дата переходу.

19. API для інтеграції з сайтом

19.1. Фіксація кліку

POST /api/affiliate/click

Приклад payload:

{
  "ref": "AFF-000001",
  "url": "https://site.com/pricing",
  "utm_source": "telegram",
  "utm_medium": "post",
  "utm_campaign": "may_campaign",
  "session_id": "abc123",
  "user_agent": "Mozilla/5.0"
}

19.2. Реєстрація ліда

POST /api/affiliate/lead

Приклад payload:

{
  "ref": "AFF-000001",
  "name": "Іван Петренко",
  "phone": "+380501112233",
  "email": "ivan@example.com",
  "source": "landing_page",
  "session_id": "abc123"
}

19.3. Реєстрація клієнта

POST /api/affiliate/customer

Приклад payload:

{
  "ref": "AFF-000001",
  "customer_id": "CUST-000123",
  "email": "ivan@example.com",
  "phone": "+380501112233",
  "session_id": "abc123"
}

19.4. Отримання статистики афіліата

GET /api/affiliate/{affiliate_code}/stats

Приклад response:

{
  "affiliate_code": "AFF-000001",
  "clicks": 1200,
  "leads": 80,
  "customers": 30,
  "sales_amount": 150000,
  "commission_total": 15000,
  "commission_available": 9000,
  "commission_paid": 6000
}

20. Права доступу

Дія	Адміністратор	Менеджер	Бухгалтер	Керівник	Афіліат
Створення афіліата	Так	Так	Ні	Ні	Ні
Редагування афіліата	Так	Так	Ні	Ні	Ні
Редагування афіліатської програми	Так	Ні	Ні	Ні	Ні
Перегляд продажів	Так	Так	Так	Так	Тільки свої
Перегляд комісій	Так	Так	Так	Так	Тільки свої
Підтвердження комісій	Так	Так	Ні	Ні	Ні
Формування виплат	Так	Ні	Так	Ні	Ні
Проведення виплат	Так	Ні	Так	Ні	Ні
Перегляд dashboard	Так	Так	Так	Так	Тільки свій

21. Звіти

21.1. Звіт “Ефективність афіліатів”

Звіт має містити:

• афіліат;
• кількість кліків;
• кількість лідів;
• кількість клієнтів;
• кількість продажів;
• сума продажів;
• сума комісій;
• конверсія click → lead;
• конверсія lead → sale;
• середній чек;
• ROI.

21.2. Звіт “Комісії до виплати”

Звіт має містити:

• афіліат;
• сума в hold;
• сума доступна до виплати;
• сума виплачена;
• мінімальний поріг виплати;
• статус виплати.

21.3. Звіт “Продажі по афіліатах”

Звіт має містити:

• документ продажу;
• клієнт;
• афіліат;
• дата продажу;
• сума продажу;
• база комісії;
• ставка;
• сума комісії;
• статус нарахування.

21.4. Звіт “Повернення та коригування”

Звіт має містити:

• документ продажу;
• документ повернення;
• афіліат;
• початкова комісія;
• сума коригування;
• фінальна комісія;
• причина коригування.

22. Антифрод

22.1. Базові антифрод-перевірки

Ситуація	Дія
Багато кліків з одного IP	Позначити як suspicious.
Самореферал	Не нараховувати комісію або відправити на ручну перевірку.
Афіліат і клієнт мають однаковий email або телефон	Позначити як suspicious.
Масові повернення по одному афіліату	Вивести в окремий звіт.
Дуже високий conversion rate	Відправити на перевірку.

22.2. Статуси антифроду

Статус	Опис
clean	Немає підозрілих ознак.
suspicious	Потрібна перевірка.
blocked	Нарахування заблоковане.
approved	Перевірено вручну.

23. Історія змін

Потрібно зберігати історію змін для таких обʼєктів:

• афіліат;
• афіліатська програма;
• ставка комісії;
• статус нарахування;
• виплата;
• ручне коригування;
• привʼязка клієнта до афіліата.

23.1. Поля audit log

Поле	Опис
Користувач	Хто зробив зміну.
Дата	Коли зроблено зміну.
Обʼєкт	Який обʼєкт змінено.
Поле	Яке поле змінено.
Старе значення	Значення до зміни.
Нове значення	Значення після зміни.
Коментар	Причина зміни.

24. Рекомендована структура даних

24.1. Основні сутності

affiliate_programs
affiliates
affiliate_links
affiliate_clicks
affiliate_leads
affiliate_customer_bindings
affiliate_commissions
affiliate_commission_adjustments
affiliate_payouts
affiliate_payout_lines
affiliate_antifraud_checks
affiliate_audit_log

24.2. Ключові унікальні обмеження

affiliates.code — unique
affiliate_links.code — unique
affiliate_commissions.sale_document_id + affiliate_id + commission_type — unique
affiliate_customer_bindings.customer_id — unique, якщо дозволений тільки один афіліат
affiliate_payout_lines.commission_id — unique

25. Інтеграція з існуючими модулями K2 ERP

25.1. Контрагенти

Афіліат може бути повʼязаний із контрагентом K2 ERP.

affiliate.contractor_id → contractor.id

25.2. Клієнти

Клієнт має містити посилання на афіліата або окремий регістр привʼязки.

Варіант 1:

customer.affiliate_id → affiliate.id

Варіант 2:

affiliate_customer_bindings.customer_id
affiliate_customer_bindings.affiliate_id

25.3. Продажі

Після проведення документа продажу система має перевірити:

1. Чи є у клієнта афіліат.
2. Чи активний афіліат.
3. Чи активна афіліатська програма.
4. Чи продаж підпадає під правила програми.
5. Чи не було вже нарахування по цьому продажу.
6. Розрахувати комісію.
7. Створити запис у affiliate_commissions.

25.4. Платежі

Якщо комісія нараховується тільки після оплати, система має реагувати на подію оплати:

payment.status = paid → calculate affiliate commission

25.5. Повернення

При проведенні повернення система має знайти повʼязане нарахування й виконати коригування.

26. Алгоритм нарахування комісії

1. Отримати документ продажу.
2. Перевірити, що документ проведений.
3. Перевірити, що документ оплачений, якщо це потрібно за налаштуваннями.
4. Отримати клієнта.
5. Перевірити, чи клієнт має активну афіліатську привʼязку.
6. Отримати афіліата.
7. Перевірити статус афіліата.
8. Отримати афіліатську програму.
9. Перевірити статус програми.
10. Перевірити attribution window.
11. Перевірити, чи не існує вже нарахування по цьому продажу.
12. Визначити базу розрахунку.
13. Визначити ставку.
14. Розрахувати суму комісії.
15. Створити нарахування зі статусом hold або pending.
16. Записати дату hold_until.
17. Додати запис в audit log.

27. Нефункціональні вимоги

27.1. Продуктивність

Система має підтримувати:

• не менше 100 000 афіліатських кліків на місяць;
• не менше 10 000 лідів на місяць;
• не менше 50 000 продажів на місяць;
• формування звіту за період до 1 року не довше 30 секунд при нормальній індексації.

27.2. Надійність

Система має:

• не дублювати нарахування по одному продажу;
• мати унікальний ключ на звʼязку “продаж + афіліат + тип нарахування”;
• логувати всі зміни статусів;
• зберігати історію ставок;
• не перераховувати старі комісії заднім числом без документа коригування.

27.3. Безпека

Необхідно:

• обмежити доступ афіліатів тільки до власних даних;
• приховувати персональні дані клієнтів у партнерському кабінеті, якщо це потрібно;
• логувати дії менеджерів;
• заборонити афіліату змінювати суму комісії;
• заборонити видалення нарахувань після проведення.

28. MVP-версія

28.1. Що включити в MVP

1. Довідник афіліатів.
2. Афіліатські програми.
3. Реферальний код.
4. Ручна привʼязка клієнта.
5. API для привʼязки клієнта за ref-кодом.
6. Нарахування комісії з оплаченого продажу.
7. Hold-період.
8. Виплати.
9. Звіт по комісіях.
10. Захист від дублювання нарахувань.

28.2. Що можна відкласти

1. Особистий кабінет афіліата.
2. Детальний click tracking.
3. Tiered-комісії.
4. Складний антифрод.
5. Автоматичні банківські виплати.
6. Мультивалютні конвертації.
7. Маркетингові матеріали для афіліатів.

29. Критерії приймання

29.1. Афіліати

1. Адміністратор може створити афіліата.
2. Код афіліата генерується автоматично.
3. Код афіліата унікальний.
4. Афіліата можна активувати, заблокувати, перевести в архів.
5. Заблокований афіліат не отримує нових комісій.

29.2. Привʼязка клієнта

1. Клієнта можна привʼязати до афіліата вручну.
2. Клієнта можна привʼязати через API.
3. Система зберігає дату та джерело привʼязки.
4. Якщо привʼязка заблокована, автоматична зміна афіліата неможлива.

29.3. Нарахування

1. Після оплати продажу створюється комісія.
2. Комісія не дублюється при повторному проведенні документа.
3. Ставка береться з афіліата, якщо вона задана.
4. Якщо індивідуальної ставки немає, ставка береться з програми.
5. Комісія переходить у статус available після hold-періоду.

29.4. Повернення

1. Повне повернення скасовує невиплачену комісію.
2. Часткове повернення перераховує суму комісії.
3. Якщо комісія вже виплачена, створюється мінусове коригування.

29.5. Виплати

1. Виплата формується тільки з available-нарахувань.
2. Після проведення виплати нарахування отримують статус paid.
3. Якщо сума менша за мінімальний поріг, система блокує виплату.

29.6. Звіти

1. Керівник бачить ефективність афіліатів.
2. Менеджер бачить продажі та комісії по своїх афіліатах.
3. Бухгалтер бачить суми до виплати.
4. Афіліат бачить тільки свої дані.

30. Ризики

Ризик	Наслідок	Як зменшити
Дублювання комісій	Переплата афіліатам.	Унікальні ключі та перевірка перед створенням нарахування.
Неправильна attribution-логіка	Конфлікти між партнерами.	Чітко затвердити first click / last click / manual priority.
Повернення після виплати	Виникає борг афіліата.	Створювати мінусові коригування.
Зміна ставки заднім числом	Некоректні історичні комісії.	Зберігати ставку в нарахуванні на момент створення.
Самореферали	Шахрайські нарахування.	Додати антифрод-перевірки.

31. Рекомендований план реалізації

31.1. Етап 1. Аналітика

1. Узгодити типи комісій.
2. Узгодити attribution-правило.
3. Узгодити подію нарахування.
4. Узгодити hold-період.
5. Узгодити процес виплат.

31.2. Етап 2. Дані та довідники

1. Створити довідник афіліатів.
2. Створити довідник програм.
3. Додати поля в картку клієнта.
4. Створити регістр привʼязок.

31.3. Етап 3. Нарахування

1. Реалізувати розрахунок комісій.
2. Реалізувати захист від дублів.
3. Реалізувати статуси.
4. Реалізувати hold-період.

31.4. Етап 4. Виплати

1. Створити документ виплати.
2. Додати включення доступних комісій.
3. Змінювати статуси після проведення.

31.5. Етап 5. Звіти

1. Звіт по афіліатах.
2. Звіт по нарахуваннях.
3. Звіт до виплати.
4. Звіт по поверненнях.

31.6. Етап 6. Тестування

1. Unit-тести формул.
2. Тести привʼязки клієнта.
3. Тести продажів.
4. Тести повернень.
5. Тести виплат.
6. Тести прав доступу.

32. Висновок

Афіліатська система в K2 ERP має бути окремим модулем, який звʼязує партнерів, клієнтів, продажі, комісії та виплати.

Ключові принципи реалізації:

• один афіліат має унікальний реферальний код;
• клієнт має прозору історію привʼязки до афіліата;
• комісія не повинна дублюватися;
• ставка має фіксуватися на момент нарахування;
• повернення мають коригувати комісію;
• виплати мають проводитися тільки за підтвердженими та доступними нарахуваннями;
• усі важливі зміни мають логуватися.

Для MVP достатньо реалізувати довідник афіліатів, афіліатські програми, привʼязку клієнтів, просту відсоткову комісію, hold-період, виплати та базову звітність.