Розподіл роялті та умови розподілу учасників
Правила створення, прийняття, версії та виплати договірних розподілів роялті між учасниками.
1. Основний принцип
Royalty Split фіксує, як допустимий дохід розподіляється між учасниками. Royalty Split сам по собі не передає авторські права, права на мастер-запис, видавничі права чи будь-які інші права інтелектуальної власності.
2. Володіння правами та розподіл доходів відрізняються
Особа може отримувати договірний відсоток доходу, не володіючи таким же відсотком майстра чи композиції. Право власності та право на оплату потрібно реєструвати окремо.
3. Типи сплітів
X2 може підтримувати розподіл основного доходу, розподіл композиції чи публікації, розподіл доходу лейблу та інший договірний розподіл учасників. Кожен тип має бути пов’язаний із відповідним джерелом доходу та контекстом прав.
4. Учасники та ролі
Поділ може ідентифікувати таких учасників, як артисти, продюсери, відомі виконавці, власники майстер-класів, автори пісень, видавці, адміністратори чи інші особи чи організації, які мають право на контракт.
5. Відсоткова перевірка
Активний остаточний розподіл повинен враховувати повний відповідний пул розподілу. Чернетки робочих процесів можуть визначати нерозподілену частину, але нерозподілені суми не виплачуються автоматично іншому учаснику.
6. Запрошення та прийняття
Учасники можуть отримати запрошення із зазначенням відповідного активу чи роботи, ролі учасника, відсотка, дати набуття чинності та основи розподілу. Учасники можуть прийняти або оскаржити запропонований розподіл.
7. Перевірка
Перед здійсненням платежу кожен учасник повинен пройти підтвердження бенефіціара, податку та платежу, необхідні для відповідної виплати. Перевірка професійної ролі потрібна лише тоді, коли учасник користується послугою або затверджує роль, яка цього вимагає.
8. Статуси
Розділ може використовувати такі статуси, як ЧЕРНЕТКА, ОЧІКУЄ НА ПРИЙНЯТТЯ, ЧАСТКОВО ПРИЙНЯТО, АКТИВНИЙ, ОСПЕРЕЖЕНИЙ, ПРИЗУПИНЕНО, ЗАМІНЕНО та ПРИПИНЕНО.
9. Дати набрання чинності та версії
Кожне поділ має мати дату набрання чинності та, у відповідних випадках, дату завершення. Зміни прийнятого розподілу повинні створити нову версію, а не мовчки перезаписувати історичні відсотки.
10. Порядок розрахунку
Якщо у відповідній угоді прямо не передбачено інше, розподіл учасників застосовується до правовласника або пулу учасників після відповідної частки доходу за контрактом X2. Індивідуальні податкові утримання, комісії за виплати або конвертація валюти можуть застосовуватися до кожного учасника окремо.
11. Несвоєчасне надходження
Запізніли або виправлені доходи повинні використовувати розподіл, застосовний до відповідного періоду права або договірної основи, а не автоматично використовувати поточний розподіл.
12. Суперечки
Якщо учасник оскаржує розподіл, X2 може утримувати лише відповідну частину, якщо це технічно та юридично можливо, тоді як безспірні суми продовжуються через звичайний облік.
13. Ретроактивні зміни
За умовчанням розділені зміни застосовуються перспективно з дати набрання чинності. Для коригування заднім числом може знадобитися згода учасника, договірні докази, виправлення встановленої помилки, судове або судове рішення або інша достатня підстава.
14. Учасники без повного доступу до X2
Учасник може бути запрошений електронною поштою та може отримати обмежений доступ, достатній для прийняття поділу, надання необхідної інформації про бенефіціара та отримання власного розподілу цього учасника без отримання ширших професійних дозволів.
15. Незатребувані асигнування
Невитребувана частка учасника або частка, яка очікує розгляду, не стає автоматично доходом X2 або часткою іншого учасника, якщо інше прямо не передбачено керівною угодою чи застосовним законодавством.
16. Комісії
X2 може включати звичайне розділене адміністрування у відповідній службі, одночасно застосовуючи розкриті Комісії за послуги або Комісії за користування до складної історичної звірки, автоматизації підприємства, масового імпорту або інших спеціалізованих операцій.
17. API доступу
API розподілу роялті можуть використовувати окремі області читання, створення, оновлення, запрошення, прийняття та оскарження. Дуже чутливі примусові зміни не повинні бути доступні через звичайні дозволи розробника.