Перейти до вмісту

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

Матеріал з K2 ERP Wiki

Manual priority → First successful registration → First click

5.

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

1. !SEO-опис 5. |- |Конверсія |Цільова дія клієнта: реєстрація, оплата, покупка. Тести продажів. |}

affiliates

  • довідник афіліатів;
  • довідник афіліатських програм;
  • реферальні коди та посилання;
  • журнал переходів;
  • ліди;
  • привʼязка клієнтів до афіліатів;
  • комісійні нарахування;
  • коригування комісій;
  • виплати афіліатам;
  • звіти;
  • антифрод-перевірки;
  • аудит змін;
  • API для зовнішнього сайту або CRM;
  • особистий кабінет афіліата, якщо передбачено. Комісія створюється після успішної оплати документа продажу. |Зберігати ставку в нарахуванні на момент створення. |-
Дата створення datetime Дата створення ліда. !Дія 7. |-
Виплачено - клієнт ERP reference - Оплата замовлення Комісія створюється після фактичної оплати. available → cancelled

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

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

"affiliate_code": "AFF-000001",

Звіт має містити: commission_amount = base_amount × commission_rate / 100

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

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

13.4. Tiered-комісія

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

6. 4. |-

approved - hold - API }

commission_amount = fixed_amount + base_amount × commission_rate / 100 

"phone": "+380501112233",

5. |-

Тип комісії enum Так - Афіліатська програма - UTM campaign string - Hold-період integer Так Кількість днів до доступності виплати. !Бухгалтер

8. |Унікальні ключі та перевірка перед створенням нарахування. Якщо менеджер вручну привʼязав клієнта — застосовують, коли потрібно ручна привʼязка. |-

Назва / ПІБ string Так - Унікальність class="wikitable"

1.=== 29.4. Повернення === commission_amount = 1 000 грн

2. Якщо комісія вже виплачена, створюється мінусове коригування. |-

Активний Афіліат здатна залучати клієнтів.== 6. Функціональні модулі == 
"utm_campaign": "may_campaign",

2. |-

Обовʼязково Комісія не повинна дублюватися по одному продажу. Звіт по афіліатах. affiliate_payout_lines

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

Hold until date Дата, після якої комісія доступна до виплати. * документ продажу;
  • клієнт ERP;
  • афіліат;
  • дата продажу;
  • сума продажу;
  • база комісії;
  • ставка;
  • сума комісії;
  • статус нарахування. |-
 Статус enum Так - Статус enum Так - Дуже високий conversion rate - Масові повернення по одному афіліату Вивести в окремий звіт. клієнт ERP має містити посилання на афіліата або окремий регістр привʼязки.Приклад посилання на реєстрацію:
</syntaxhighlight>

16. |-

cancelled Нарахування скасоване через повернення або сторно. платформа перевіряє правила афіліатської програми. "url": "https://site.com/pricing",

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

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

Коментар text Ні Нові комісії не нараховуються. |Нові комісії не нараховуються. 2. 1. |- Сума до виплати decimal - Менеджер партнерської програми - Індивідуальна ставка decimal Ні - Дата оновлення версій datetime - Обовʼязково - Доступно до виплати - Афіліат і клієнт ERP мають однаковий email або телефон Позначити як suspicious. Створити запис у affiliate_commissions. Потрібно зберігати історію змін для таких обʼєктів: SEO-опис

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

Переходи Кількість кліків за реферальним посиланням. Необхідно створити журнал або документ Афіліатські ліди. !Поле

21.3. Звіт “продажі та реалізація по афіліатах”

 SEO-опис

1. 3. Отримати клієнта.=== 29.5. Виплати ===

0–50 000 грн 5%
50 001–100 000 грн 7%
100 001+ грн 10%

6. Реалізувати статуси. Зменшити суму комісії. клієнт ERP реєструється або оформлює замовлення. !Основні права

Афіліат
Дублювання комісій - Бухгалтер Формує та проводить виплати. клієнт ERP здійснює оплату. !SEO-опис Ризик

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

Обовʼязково Кожен афіліат має унікальний код. Необхідно:

платформа має підтримувати:

SEO-опис

2. Після hold-періоду комісія стає доступною до виплати. !Правило 

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

22. Антифрод

1. |-

Email string - Валюта enum - Афіліат reference - Новий }

3. |}

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

=== 19.4. Отримання статистики афіліата ===
affiliate_payouts
4. |-
|Мінімальна сума
|Якщо сума менша за мінімальний поріг, виплата не створюється. |-
|Сума комісії
|decimal
|Сума до виплати. |-
|Сума комісії
|decimal
|Розрахована винагорода. Афіліатська платформа в K2 ERP має бути окремим модулем. |}

!Тип
== 32. Висновок ==
Визначення

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

Потрібно створити документ або регістр Афіліатське нарахування. |Потрібно створювати документ коригування. |-
Комісія з повторних покупок boolean Так Чи нараховується винагорода за повторні покупки.== 28. MVP-версія == 
"customers": 30,

4. 2. |-

Керівник - Валюта enum Так - Неправильна attribution-логіка Конфлікти між партнерами. Тип

4.== 9. Реферальні коди та посилання == 2. |-

Привʼязка заблокована boolean } 
3. !Статус
=== 28.2. Що можна відкласти ===
{| class="wikitable"
|-
|Афіліат
|reference
|Поточний афіліат клієнта. |200 грн + 5% від продажу. Код афіліата унікальний. {| class="wikitable"

!Тип

Комісія = оплачена сума без повернень × ставка афіліата
{
!Спосіб
=== 24.2. Ключові унікальні обмеження ===

компонент; так само реалізовано реферальних кодів, залучених клієнтів, продажів, комісійних нарахувань, коригувань і виплат афіліатам виступає ключовою рисою обліку партнерів забезпечується через '''Афіліатська платформа в K2 ERP'''. |-
|Сума документа з ПДВ
|Комісія рахується від повної суми продажу. |-
|Заблокований
|Афіліат тимчасово заблокований. |Повний доступ. Узгодити hold-період. Тести прав доступу. |-
|pending
|Нарахування створене, але ще не перевірене. |-
|Фіксована сума
|decimal
|Ні
|застосовується для для фіксованої або змішаної комісії. Після оплати продажу створюється комісія.=== 19.3. Реєстрація клієнта ===
!SEO-опис
2. |Створювати мінусові коригування. Якщо сума менша за мінімальний поріг, платформа блокує виплату. |-
|Фіксована сума
|Афіліат отримує фіксовану винагороду за конверсію. |-
|Після проведення
|Після проведення виплати нарахування отримують статус `paid`. |-
|Перевірка дублів
|При збереженні платформа перевіряє, що код не зайнятий. !SEO-опис
7. !SEO-опис

 "email": "ivan@example.com",
<pre>
== 19. API для інтеграції з сайтом ==
=== 27.3. Безпека ===
!Тип
affiliate_programs
!Дія
=== 13.1. Відсоткова комісія ===
платформа має підтримувати такі варіанти attribution:
affiliate_customer_bindings

<pre>

3. 6. Після проведення виплати нарахування отримують статус paid. Якщо індивідуальної ставки немає, ставка береться з програми. |}

1. Якщо комісія вже виплачена — створити мінусове коригування. 2. |-
|User Agent
|string
|Браузер або пристрій.=== 21.2. Звіт “Комісії до виплати” ===
Ключові принципи реалізації:
Поле

2. |Код застосовується для для привʼязки клієнтів і продажів. Бухгалтер формує виплату афіліату. |-

Заборонено - Ручне введення коду Менеджер або клієнт ERP вводить код афіліата вручну. Термін SEO-опис 
!Обовʼязкове
=== 14.3. Життєвий цикл нарахування ===
 "phone": "+380501112233",

== 3. Основні ролі користувачів ==
== 12. продажі та реалізація та комісійні нарахування ==

Менеджер створює афіліата в K2 ERP. Розрахувати суму комісії. |-

Коментар привʼязки text - Багато кліків з одного IP Позначити як suspicious.
commission_rate = 10%
=== 29.3. Нарахування ===

6. Звіт до виплати. Якщо клієнт ERP зареєструвався з ref-кодом — застосовується для цей ref-код. |-
|Обʼєкт
|Який обʼєкт змінено.=== 14.2. Статуси нарахування ===
=== 21.1. Звіт “Ефективність афіліатів” ===
4. |-
|Ref-посилання
|клієнт ERP перейшов за посиланням із кодом афіліата. |-
|Один раз
|Одне нарахування не здатна бути включене у дві виплати. |-
|ID
|UUID / integer
|Унікальний ID коригування. |-
|Змішана
|Фіксована сума плюс відсоток. |Перегляд звітів. 3. |Створення афіліатів, перегляд продажів, підтвердження комісій. Unit-тести формул. Якщо комісія ще не виплачена — змінити або скасувати нарахування. Афіліат бачить тільки свої інформаційні дані. Реалізувати hold-період. |-
|rejected
|Нарахування відхилене. |-
|Реферальне посилання
|Посилання з ref-кодом афіліата. {| class="wikitable"
|-
|Створення афіліата
|Так
|Так
|Ні
|Ні
|Ні
|-
|Редагування афіліата
|Так
|Так
|Ні
|Ні
|Ні
|-
|Редагування афіліатської програми
|Так
|Ні
|Ні
|Ні
|Ні
|-
|Перегляд продажів
|Так
|Так
|Так
|Так
|Тільки свої
|-
|Перегляд комісій
|Так
|Так
|Так
|Так
|Тільки свої
|-
|Підтвердження комісій
|Так
|Так
|Ні
|Ні
|Ні
|-
|Формування виплат
|Так
|Ні
|Так
|Ні
|Ні
|-
|Проведення виплат
|Так
|Ні
|Так
|Ні
|Ні
|-
|Перегляд dashboard
|Так
|Так
|Так
|Так
|Тільки свій
|}

!Поле

3. |}

== 7. Довідник “Афіліати” ==
1. |-
|Афіліатська програма
|reference
|Програма, за якою створено нарахування. Заблокований афіліат не отримує нових комісій.=== 13.3. Змішана комісія ===
<pre>
Тип

1. Реалізувати розрахунок комісій. |} 

"clicks": 1200,

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

Приклад базового посилання:<pre>
|-
|Відсоток
|Комісія рахується як відсоток від бази розрахунку. |-
|Реферальний код
|Унікальний код афіліата для ідентифікації джерела клієнта. 14. Узгодити подію нарахування. |-
|Ставка
|decimal
|Ставка, зафіксована на момент нарахування. |-
|База розрахунку
|decimal
|Сума, від якої рахується комісія. Створити нарахування зі статусом hold або pending. 10. |-
|Attribution expires at
|datetime
|Дата завершення attribution window. |-
|Афіліат
|reference
|інтегратор. |500 грн за нового клієнта. |-
|Дата активації
|datetime
|Ні
|Дата переведення у статус “Активний”. |-
|Афіліат
|reference
|інтегратор, якому нарахована комісія. |}

!Адміністратор
base_amount = 10 000 грн
10. Керівник бачить ефективність афіліатів. |-
|Дата створення
|datetime
|Дата створення. |-
|Коментар
|Причина зміни. * афіліат;
* кількість кліків;
* кількість лідів;
* кількість клієнтів;
* кількість продажів;
* сума продажів;
* сума комісій;
* конверсія click → lead;
* конверсія lead → sale;
* середній чек;
* ROI. Перевірити, що документ проведений. PARTNER-KYIV-001
== 24. Рекомендована структура даних ==
!Менеджер
== 27. Нефункціональні вимоги ==
9. 5. Мультивалютні конвертації. |-
|Дата виплати
|datetime
|Дата фактичної виплати.== 26. Алгоритм нарахування комісії ==
{| class="wikitable"

!Правило
1.<pre>
 "ref": "AFF-000001",
<pre>
!Варіант
{
{| class="wikitable"
=== 13.2. Фіксована комісія ===
=== Етап 1. 31.1. аналітичні інструменти ===

!Поле
{
!Як зменшити
3. |-
|blocked
|Нарахування заблоковане. |}

<pre>

 "commission_available": 9000,
<pre>
affiliate_commissions.sale_document_id + affiliate_id + commission_type — unique
4.<pre>
2. "leads": 80,

!Наслідок
!Поле
2. Перевірити статус програми. |-
|Ручне редагування
|Адміністратор здатна змінити код, якщо це дозволено правами. |-
|Назва програми
|string
|Так
|Назва афіліатської програми. |-
|Ліди
|Кількість потенційних клієнтів. |-
|IP
|string
|IP-адреса. 2. платформа створює комісійне нарахування. Узгодити типи комісій. |-
|Скасування
|При скасуванні виплати нарахування повертаються у статус `available`. |-
|Повернення після виплати
|Виникає борг афіліата.=== 15.2. Часткове повернення ===

= Афіліатська платформа в K2 ERP =

* один афіліат має унікальний реферальний код;
* клієнт ERP має прозору історію привʼязки до афіліата;
* комісія не повинна дублюватися;
* ставка має фіксуватися на момент нарахування;
* повернення мають коригувати комісію;
* виплати мають проводитися тільки за підтвердженими та доступними нарахуваннями;
* усі важливі зміни мають логуватися. {| class="wikitable"
POST /api/affiliate/lead
{| class="wikitable"

"utm_medium": "post",
Тип

3. Особистий кабінет афіліата. Записати дату hold_until. |-

Статус enum - Категорії товарів Потрібен унікальний ключ на рівні продажу та афіліата. |- Документ продажу reference Продаж, за який нарахована комісія.=== 14.1. Поля нарахування ===

2. |-

Конверсія - Клієнти Кількість зареєстрованих клієнтів. Ручна привʼязка клієнта. 2.Приклад payload:
affiliate_customer_bindings.customer_id — unique, якщо дозволений тільки один афіліат
</pre>
!Тип комісії
{| class="wikitable"

!Поле
!Вимога

=== 29.2. Привʼязка клієнта ===
{| class="wikitable"
3. |}

{| class="wikitable"
1. |-
|Старе значення
|Значення до зміни. Отримати афіліатську програму.=== 15.3. Документ “Коригування афіліатської комісії” ===
!Коментар
Після проведення документа продажу платформа має перевірити:<pre>
|-
|ID
|UUID / integer
|Унікальний ID нарахування. |10% від суми продажу. 15. 5. Комісія не дублюється при повторному проведенні документа. Автоматичні банківські виплати. |-
|Дата привʼязки
|datetime
|Дата привʼязки клієнта до афіліата. Якщо привʼязка заблокована, автоматична зміна афіліата неможлива. |-
|Статус
|enum
|pending, hold, approved, available, rejected, paid, cancelled. |-
|Телефон
|string
|Телефон. Чи активна афіліатська програма. {| class="wikitable"
=== 9.1. Генерація реферального коду ===
!Місячний обсяг продажів
Звіт має містити:
|-
|користувач системи
|Хто зробив зміну. Додати включення доступних комісій. Чи виступає як у клієнта афіліат.=== 27.2. Надійність ===
!SEO-опис
1. |-
|Валюта
|enum
|Валюта рядка.<pre>

Для першої версії рекомендується правило:<pre>
=== 23.1. Поля audit log ===
Якщо комісія нараховується тільки після оплати, платформа має реагувати на подію оплати:<pre>
!Тип
https://site.com/?ref=AFF-000001
 "ref": "AFF-000001",
платформа має автоматизовано генерувати унікальний код для кожного афіліата. |-
|Базова ставка
|decimal
|Так
|Основна ставка програми. Перевірити attribution window. |-
|Імʼя
|string
|Імʼя ліда. |-
|Афіліатська програма
|reference
|Так
|Програма, до якої підключено афіліата. "session_id": "abc123",
}
{| class="wikitable"
!SEO-опис

1. |-
|Завершення періоду повернення
|Комісія створюється після завершення періоду, коли клієнт ERP здатна повернути товар. affiliate_customer_bindings.customer_id
|-
|Адміністратор
|Налаштовує систему, програми, ставки, права доступу.=== 11.1. Поля ліда ===
!SEO-опис
</pre>
</pre>
</pre>
|-
|ID
|UUID / integer
|Так
|Унікальний ідентифікатор афіліата.=== 7.2. Статуси афіліата ===
== 2. Короткий SEO-опис бізнес-процесу ==
=== 9.3. Вимоги до коду ===

1. |-
|Тип афіліата
|enum
|Так
|Фізична особа, ФОП, юридична особа, агентство, блогер, інтегратор.=== 18.1. Поля журналу переходів ===
!Статус

* документ продажу;
* документ повернення;
* афіліат;
* початкова комісія;
* сума коригування;
* фінальна комісія;
* причина коригування. |-
|Самореферали
|Шахрайські нарахування. "sales_amount": 150000,
1.</pre>

=== 17.1. Функції кабінету ===
paid → adjustment
affiliate_links
!Показник
== 11. Ліди ==
 "customer_id": "CUST-000123",
3. !Поле
5. |-
|Самореферал
|Не нараховувати комісію або відправити на ручну перевірку. |До 100 000 грн — 5%, понад 100 000 грн — 8%. |-
|Період
|date range
|Період, за який формується виплата.</pre>
3. |-
|Максимальна кількість нарахувань на клієнта
|integer
|Ні
|Обмеження кількості комісій по одному клієнту. Повне повернення скасовує невиплачену комісію. |Зміна ставки в майбутньому не має змінювати старі нарахування. |-
|Імпорт
|Привʼязки завантажуються з файлу або зовнішньої системи. |Чітко затвердити first click / last click / manual priority. Менеджер бачить продажі та реалізація та комісії по своїх афіліатах. Якщо продаж на 100% повернуто:<pre>
Варіант 1:<pre>
pending → rejected
|-
|Афіліат
|інтегратор, який залучає клієнтів і отримує комісію. Звіт по нарахуваннях. |-
|Архівний
|Афіліат більше не застосовується для. 7. 1.
{ 

<pre>
 "source": "landing_page",
4. * не менше 100 000 афіліатських кліків на місяць;
* не менше 10 000 лідів на місяць;
* не менше 50 000 продажів на місяць;
* формування звіту за період до 1 року не довше 30 секунд при нормальній індексації. }
2. "session_id": "abc123"
=== 15.1. Повне повернення ===

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

2. |-

Tiered Ставка залежить від обсягу продажів або кількості клієнтів. "user_agent": "Mozilla/5.0"

платформа має:

Приклад:
|-
|Тільки available
|У виплату можна включати тільки нарахування зі статусом `available`.<pre>
== 14. Документ “Афіліатське нарахування” ==
available → paid
7. Захист від дублювання нарахувань. |-
|Email
|string
|Так
|Контактний email. |-
|Телефон
|string
|Ні
|Контактний телефон. Якщо комісія ще не виплачена — скасувати нарахування. !SEO-опис
4. |-
|Статус
|enum
|draft, approved, applied, cancelled. |-
|клієнт ERP
|reference
|клієнт ERP продажу. 3. !Поле
POST /api/affiliate/click
=== 10.4. Рекомендоване правило для MVP ===
Правило

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

affiliate_commission_adjustments 4. Tiered-комісії. Змінювати статуси після проведення. |-

URL string - Дата початку date Так } 11. |Дозволено тільки скасування або коригування.

10. Адміністратор здатна створити афіліата. Перевірити статус афіліата.=== 17.2. Dashboard афіліата ===

Номер виплати string Унікальний номер документа. Необхідно створити довідник Афіліати. !SEO-опис
  • свій реферальний код;
  • реферальні посилання;
  • кількість переходів;
  • кількість лідів;
  • кількість клієнтів;
  • кількість продажів;
  • суму продажів;
  • суму комісій;
  • комісії в hold;
  • доступно до виплати;
  • виплачено;
  • історію виплат. Якщо комісія вже виплачена — створити мінусове коригування. |-
 Стабільність - Нове значення - UTM medium string - Валюта enum Так - Сума без ПДВ Комісія рахується від суми без податків. 6.== 10. Привʼязка клієнтів до афіліатів ==

affiliate_audit_log

SEO-опис Ситуація

Комісія = оплачена сума документа × ставка афіліата https://site.com/register?affiliate=AFF-000001

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

8. Чи активний афіліат. |-

Контрагент K2 ERP reference Ні } SEO-опис

hold → cancelled

31.2. Етап 2. інформаційні дані та довідники

4. |-

suspicious - продажі та реалізація - Manual priority Комісії нараховуються. |- Дата завершення date Ні } Тип

6. |-

Закриття продажу Додати антифрод-перевірки. |- критично - Код афіліата string - Виплата } 
"utm_source": "telegram",

!Тип
!Обовʼязкове
=== 12.3. База для розрахунку комісії ===
1. |-
|Джерело
|string
|Сайт, форма, рекламна кампанія. |-
|Hold-період
|Період очікування перед тим, як комісія стане доступною до виплати. Тести привʼязки клієнта. |-
|UTM source
|string
|UTM-джерело. Реферальний код. !Керівник
payment.status = paid → calculate affiliate commission

При проведенні повернення платформа має знайти повʼязане нарахування й виконати коригування. |Перегляд власної статистики, комісій і виплат. |-
|Початкове нарахування
|reference
|Нарахування, яке коригується. Реалізувати захист від дублів. |-
|історія продукту змін
|Зміна коду має потрапляти в audit log. Афіліатські програми. |-
|Статус
|enum
|new, contacted, converted, rejected, duplicate. |-
|Маржа
|Комісія рахується від прибутку. платформа генерує унікальний реферальний код. Афіліата можна активувати, заблокувати, перевести в архів. 4. Звіт по комісіях. Виплати. |-
|Сума коригування
|decimal
|Додатна або відʼємна сума. !SEO-опис
<pre>
affiliate_clicks
=== 25.3. продажі та реалізація ===

{| class="wikitable"
{| class="wikitable"
3. |-
|Документ продажу
|reference
|Продаж у K2 ERP.=== 12.1. Подія для нарахування комісії ===
Комісія здатна нараховуватися при таких подіях:
3. !SEO-опис
== 31. Рекомендований план реалізації ==

* реєструвати афіліатів;
* створювати афіліатські програми;
* генерувати реферальні коди та посилання;
* привʼязувати клієнтів до афіліатів;
* нараховувати комісії з продажів;
* враховувати повернення та сторно;
* формувати виплати;
* аналізувати ефективність партнерів;
* контролювати права доступу;
* вести історію змін. Створити довідник програм. |-
|Валюта
|enum
|Валюта виплати. платформа зберігає дату та джерело привʼязки. |-
|Комісія в hold
|Нарахування, які ще не доступні до виплати. |-
|approved
|Перевірено вручну. |-
|Last click
|клієнт ERP закріплюється за останнім афіліатом перед покупкою. Довідник афіліатів. Клієнта можна привʼязати до афіліата вручну.<pre>
=== 7.1. Поля картки афіліата ===
Тобто:
!Статус
13. |-
|Лід
|Потенційний клієнт ERP, який прийшов від афіліата. |-
|Поле
|Яке поле змінено. Тести виплат. |-
|Причина відхилення
|text
|Заповнюється при rejected або cancelled. |}

!Поле

!SEO-опис
=== 29.6. Звіти ===
Афіліат має бачити:
Роль

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

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

5. customer.affiliate_id → affiliate.id 

"session_id": "abc123"



9. |Якщо комісія вже виплачена — створюється мінусове коригування. |-



Нарахування

reference

-

available

Перегляд комісій, створення виплат, звʼязок з платіжними документами. "name": "Іван Петренко",

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


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


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


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



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






клієнт ERP K2 ERP

reference

-

Комісія з першої покупки

boolean

Так

Чи нараховується винагорода за першу покупку.=== 27.1. Продуктивність ===

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


 "commission_paid": 6000
4. Після виплати комісія отримує статус “Виплачено”. |-


Attribution window

integer

Так

-

Комісія

-

Фіксована сума

decimal

-

Афіліат

reference

-

Спосіб виплати

enum

-

Мінімальна сума виплати

decimal

Ні

}

2. |-
|Відповідальний менеджер
|reference
|Ні
|Менеджер, який веде афіліата. {| class="wikitable"
|-
|ID
|UUID
|Унікальний ID кліку. Бухгалтер бачить суми до виплати. 11. Створити регістр привʼязок. K2 ERP привʼязує клієнта до афіліата. |-
|UTM medium
|string
|Канал. Ставка береться з афіліата, якщо вона задана. {| class="wikitable"
3. |-
| style="background:#fff3cd; color:#856404; font-weight:bold;" |критично
|клієнт ERP має прозору історію привʼязки до афіліата.<pre>
== 25. інтеграційні функції ERP з існуючими модулями K2 ERP ==
=== Етап 6. 31.6. Тестування ===
POST /api/affiliate/customer
BLOGGER-ANNA
|-
|ID
|UUID / integer
|Унікальний ID ліда. Додати запис в audit log. |-
|UTM source
|string
|Джерело. |}

9. 8. |}

1. affiliate_commissions
=== 29.1. Афіліати ===

* обмежити доступ афіліатів тільки до власних даних;
* приховувати персональні інформаційні дані клієнтів у партнерському кабінеті, якщо це потрібно;
* логувати дії менеджерів;
* заборонити афіліату змінювати суму комісії;
* заборонити видалення нарахувань після проведення. Узгодити attribution-правило. |-
|клієнт ERP
|Контрагент або покупець у K2 ERP. |-
|Ручна привʼязка менеджером
|Менеджер обирає афіліата в картці клієнта. |-
|Дата створення
|datetime
|Дата створення. |}

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

* афіліат;
* афіліатська програма;
* ставка комісії;
* статус нарахування;
* виплата;
* ручне коригування;
* привʼязка клієнта до афіліата. |-
|Документ повернення
|reference
|Документ повернення в K2 ERP. |-
|Дата
|Коли зроблено зміну. |-
|Платіжний документ
|reference
|Звʼязок із бухгалтерським або банківським документом. Розрахувати комісію. |-
|Причина
|text
|Причина коригування. Детальний click tracking. |-
|Код програми
|string
|Так
|Унікальний код програми. |-
|Афіліатський код
|string
|Код, за яким клієнт ERP був залучений. |-
|Session ID
|string
|Ідентифікатор сесії. |-
|Created at
|datetime
|Дата переходу. "ref": "AFF-000001",
=== 12.4. Рекомендована база для MVP ===
affiliates.code — unique
!SEO-опис

<pre>
3. Перевірити, що документ оплачений, якщо це потрібно за налаштуваннями. |-
|UTM campaign
|string
|UTM-кампанія. |-
|Attribution window
|Період, протягом якого продаж клієнта закріплюється за афіліатом. Визначити базу розрахунку. |}

=== 24.1. Основні сутності ===
Якщо повернуто частину товарів:<pre>
== 5. Важливі правила реалізації ==
Звіт має містити:
== 23. історія продукту змін ==
|-
|First click
|клієнт ERP закріплюється за першим афіліатом. |-
|Джерело привʼязки
|enum
|ref_link, manual, api, import. |-
|Оплачена сума
|Комісія рахується тільки від фактично оплаченої суми. |}

У картці клієнта потрібно додати поля:
== 4. Терміни та визначення ==

}
</syntaxhighlight>
!SEO-опис
5. Необхідно створити журнал '''Афіліатські переходи'''. API для привʼязки клієнта за ref-кодом. |-
|Дата створення
|datetime
|Дата створення. |}

{| class="wikitable"
!Статус


Приклади кодів:
|-
|clean
|Немає підозрілих ознак. |-
|Зміна ставки заднім числом
|Некоректні історичні комісії. GET /api/affiliate/{affiliate_code}/stats

AFF-000001
=== Етап 5. 31.5. Звіти ===
Комісія переходить у статус “Доступна до виплати” після завершення hold-періоду. affiliate.contractor_id → contractor.id
17. pending → hold → available → paid
=== 25.2. Клієнти ===
12. 1. |}


Варіант 2:


=== 10.3. Правила attribution ===
 "email": "ivan@example.com",
commission_amount = fixed_amount
 "commission_total": 15000,
<pre>
!SEO-опис
=== 25.4. Платежі ===
4. |}

3. |-
|paid
|Нарахування виплачене. Тести повернень. * не дублювати нарахування по одному продажу;
* мати унікальний ключ на звʼязку “продаж + афіліат + тип нарахування”;
* логувати всі зміни статусів;
* зберігати історію ставок;
* не перераховувати старі комісії заднім числом без документа коригування. |-
| style="background:#f8d7da; color:#721c24; font-weight:bold;" |Заборонено
|Видаляти проведені комісійні нарахування. |-
|Дата реєстрації
|datetime
|Так
|Дата створення афіліата. |-
|Афіліат
|reference
|Афіліат, який залучив ліда. Клієнта можна привʼязати через API. !Приклад
affiliate_antifraud_checks
5. Звіт по поверненнях. |-
|Код афіліата
|string
|Так
|Унікальний реферальний код. Отримати документ продажу. |-
|Відвантаження
|Комісія створюється після відвантаження товару.=== 12.2. Рекомендоване правило для MVP ===
500 грн за нового клієнта
!Ставка

Приклад:
Приклад payload:
<pre>
=== 19.2. Реєстрація ліда ===

2. |-
|Ref-код
|string
|Код, переданий у заявці. Визначити ставку.== 30. Ризики ==

* афіліат;
* сума в hold;
* сума доступна до виплати;
* сума виплачена;
* мінімальний поріг виплати;
* статус виплати. Hold-період. |Нові комісії не нараховуються.=== 8.2. Типи комісій ===
</pre>Альтернативний варіант:<pre>
!Вплив на нарахування
!Поле

7. 3. |Потрібно зберігати дату, джерело й користувача, який змінив привʼязку.</pre>
4. Комісія переходить у статус available після hold-періоду.=== 9.2. Формат реферального посилання ===
== 21. Звіти ==
платформа має підтримувати конфігурація бази розрахунку:
=== 28.1. Що включити в MVP ===

1.</pre>Приклад payload:<syntaxhighlight lang="json">
Потрібно створити документ '''Виплата афіліату'''.</pre>Приклад response:<syntaxhighlight lang="json">
!Подія
affiliate_leads
</pre>



affiliate_payout_lines.commission_id — unique
affiliate_links.code — unique



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


}
Афіліат здатна бути повʼязаний із контрагентом K2 ERP. Окремо варто відзначити який звʼязує партнерів, клієнтів, продажі та реалізація, комісії і виплати. Перевірити, чи не існує вже нарахування по цьому продажу. |-



Афіліат

інтегратор, який залучає клієнтів. 




















































Отримано з https://wiki.kyiv.ua/index.php?title=Технічне_завдання:_Афіліантська_система&oldid=886