Specification

Plugin: Portal

Portalbenutzerprofil (Web User Account)

Portalbenutzer sind Personen die über das Webportal mit dem System
interagieren.
Im Portalbenutzerprofil werden generelle Informationen zur Benutzung des
Portals gespeichert und einzelne Funktionen wie '''Authentifikation'''
und '''Sessionmanagement''' bereitgestellt.

Einstellungen

Der Portalbenutzer kann seine Profildaten ändern

Der Portalbenutzer kann eine Standardrolle bestimmen.

Komponenten

Portalbenutzer (Web-User)

: Tryton-Modell: web.user

Jeder Portalbenutzer muss sich registrieren.

Für die Registrierung sind eine per double-opt in geprüfte Email und ein
Passwort nötig.

Mit jedem Portalbenutzer ist genau eine Partei verknüpft.

Ein Portalbenutzer kann ein Bild als Avatar definieren.

Ein Portalbenutzer hat ein freies Textfeld für einen im System angezeigten
Namen.
Wird es leer gelassen, wird der Portalbenutzer nur anonym genannt, ansonsten wird an
gewissen Stellen für andere Portalbenutzer dieser Name angezeigt.

Bei Änderungen des Profils (insbesondere der Bankverbindung) wird dem Portalbenutzer
eine Nachricht geschickt.

Partei (Party)

: Tryton-Modell: party.party

Eine Partei ist eine natürliche oder juristische Person, mit der Geschäfte
getätigt werden können (im Sinne von Geschäftspartei).

In der Partei werden sämtliche Parteibezogenen Informationen (Name, Adresse,
Kontaktdaten usw.) gespeichert.

Eine Partei kann beliebig viele Kontoverbindungen bei beliebigen
Kreditinstituten (Modell: bank.*) haben.

Bankverbindungen können über eine Testtransaktion von 1 Cent von den
Administratoren anhand eines eindeutigen Tokens
(Verwendungszweck/Überweisungsbetreffs) verifiziert werden.

Tryton Benutzer (Historisierung)

: Tryton-Modell: res.user

An verschiedenen Stellen im System soll die Tryton Historisierungsfunktion von
Objektveränderungen (bzw. von Veränderungen in Tabelleneinträgen)
Verwendung finden.
Die Historisierung bedarf eines Tryton-Benutzers, damit festgestellt
werden kann, welcher Benutzer eine Änderung in einem historisierten Objekt
vorgenommen hat.

Um die Historisierungsfunktionalität von Tryton benutzen zu können wird für
jeden Portalbenutzer, - analog zur Partei, - ein Tryton Benutzer angelegt,
dessen Loginmöglichkeit über eine direkte Tryton-Schnittstelle deaktiviert ist.
Der automatisch angelegte Trytonbenutzer erhält als Benutzernamen den
Benutzernamen des Portalbenutzers, also seine E-Mail-Adresse.
Sowohl Portalbenutzername als auch Tryton Benutzername müssen
eindeutig sein in ihrer jeweiligen Tabelle.
Um mögliche Namenskollisionen mit Tryton Benutzern zu vermeiden, die auf
anderem Wege (bspw. administrativ über den Tryton Client) bekommt der
verwendete Portalbenutzername einen zufälligen Suffix.
Der Tryton Benutzer ist deaktiviert und erhält kein Passwort.

Damit sollte es unmöglich sein, sich mit den Login-Credentials direkt in
Tryton anzumelden, bspw. via Tryton-Client oder RPC.

Plugin: Creative

Rollen

Mit der Rolle "Creative" kann ein Portalbenutzer über seine
Partei Künstler und Werke verwalten.

Im Portal kann bei Creatives optional ein Künstlerfilter eingestellt werden, mit dem
statt Übersichtsseiten mit allen Künstlern, direkt die entsprechenden
Detailseiten des ausgewählten Künstlers angezeigt werden.

Einstellungen

Eine Creative Partei kann einen voreingestellten Künstler für den
Künstlerfilter definieren.

Geldverteilungssystem

Abstrakte Ansätze eines Geldverteilungssystems sind schon im Creative-Plugin
vorhanden, müssen aber über weitere Plugins noch sinnvoll implementiert werden.

Darunter fallen die Nutzung (Utilisation), die Verteilung (Distribution) und
die Zuordnung von Nutzungen zu Werken und Künstlern (Allocation).

Komponenten

Verwaltung der Künstler (Artist)

Mit dem Künstler werden alle Angaben, die diesen identifizieren
(Name, Alleinstellungsmerkmal, Bandlogo/Foto, usw.) verknüpft.

Jeder Künstler kann mit keiner oder einer Realperson/-organisation
verknüpft sein.

Für Künstler gibt es vorerst ein rudimentäres, zweistufiges Rechtesystem: Die
Zugriffsliste (Access Parties) und der Zahlungsempfänger (Payee).

Strukturelle Arten von Künstlern

Es gibt zwei generelle Arten Künstler zu strukturieren:

- Solokünstler (Einzelperson, Solo, Einzelkünstler) und
- Künstlergruppen (Gruppenkünstler, Bands, Orchester, …).
Solokünstler

Vorgabe bei Neuanlage eines Künstlers ist der Solokünstler.
Jede Portalbenutzer-Partei kann mit mehreren Solokünstlern verknüpft sein,
die alle zusammengenommen die einzelnen Künstlernamen darstellen, unter
der die Realperson (Partei) bekannt ist.

Jede Portalbenutzer-Partei kann einen Standardsolokünstler voreinstellen, der an
verschiedenen Stellen zur Anwendung kommt.

Beim Typ Einzelperson sind die Parteien von Künstler und Portalbenutzer identisch.

Künstlergruppe

Künstlergruppen wie Bands oder Orchester setzen sich aus einzelnen Mitgliedern von
Solokünstlern zusammen.
Bei einer "Gruppe" von Einzelkünstlern kann die Künstlergruppe einer eigenen Partei
zugewiesen werden (Bspw. eine Band ist als GbR o.ä. angemeldet und stellt eine
eigenständige juristische Person vielleicht mit eigener Bankverbindung dar).

Mit einer Künstlergruppe können weitere Solokünstler als Mitglieder verknüpft werden.

Ein Solokünstler kann bei beliebig vielen Künstlergruppen Mitglied sein.

Änderungen an der Gruppenzugehörigkeit der Mitglieder wird über die Historisierung von
Tryton nachvollzogen.

Anlage

Portalbenutzer in der Rolle Creative können Künstler anlegen.

Bevor weitere Künstler angelegt werden können, muss der Portalbenutzer einen
Solokünstler erstellen, der dann bei neuen Künstlergruppen
Mitglied wird.

Im Portal werden bei Eingabe des Künstlernamens dem Portalbenutzer zuerst in unserer
Datenbank vorhandene Künstler angeboten, danach Künstler aus öffentlichen
Datenbanken (z.B. Musicbrainz) zur Ergänzung des Anlageformulars.

Falls der Künstler in unserer Datenbank nicht exisitert, wird er neu angelegt
und mit dem Portalbenutzer und/oder dessen Standardsolokünstler verknüpft.

Bei Anlage einer Künstlergruppe wird automatisch der
Standardsolokünstler den Mitgliedern hinzugefügt, wobei der Portalbenutzer in einem
Dropdown-Menü auch einen anderen über die Partei verknüpften Solokünstler
hinzufügen kann.

Es kann auch Künstler geben, die nicht über eine Partei mit einem Portalbenutzer verknüpft
sind:

- von [[Glossar#Adorer|Adorern]] gehörte, aber im System noch nicht erstellte Künstler,
- mit gelöschten Portalbenutzern verknüpfte Künstler die im System bestehen bleiben

Falls ein Künstler bereits existiert, und noch mit keinem Portalbenutzer verknüpft
ist, findet ein Forderungsprozess (Claim) statt, bei dem der Portalbenutzer den
Anspruch auf den Künstler erheben kann.

Nach Bestätigung des Portalbenutzers, dass der Künstler angefordert werden soll, wird
per Email ein Link mit einem Token geschickt, der nach Aufruf den
Anforderungsprozess erfolgreich abschließt.

Einladung

Die Mitglieder einer Künstlergruppe können als Portalbenutzer
identifiziert und eingeladen werden (Echtname, Emailadresse).

Die Einladung wird mit jeweils einem Link mit Token an die jeweiligen
Emailadressen versendet.

Der Absender versendeter Einladungen ist eine Adore-Adresse.

Die Eingeladenen können die Einladung akzeptieren oder ablehnen.

Bei Akzeptieren wird die fehlende notwendige Struktur für den Eingeladenen
angelegt (Portalbenutzer, Künstler).

Einladungen verfallen nach einer im System bestimmbaren Zeitdauer oder können
von den aktuellen Mitgliedern der Künstlergruppe für ungültig erklärt werden.

Zugriffsliste

Die Zugriffsliste (Feld: access_parties) enthält eine Liste von Parteien
(und dadurch verbundenen Portalbenutzern), die
Lese- und Schreibzugriff auf den Künstler und dessen Werke haben.

Bei einem Solokünstler ist der Portalbenutzer des Künstlers darin enthalten.

Bei Künstlergruppen sind alle verknüpften Portalbenutzer der Mitglieder
enthalten.

Bei Künstlergruppen werden bei Änderungen von Daten Emails an alle Mitglieder
versendet.

Zahlungsempfänger (Payee)

Der Zahlungsempfänger ist eine Partei, die die Bankgeschäfte eines oder
mehrerer Künstler übernimmt.

Das Unternehmen kann nur Gelder auszahlen, wenn ein validierter
Zahlungsempfänger vorhanden ist.

Validierung Zahlungsempfänger

Für jeden Künstler muss ein Zahlungsempfänger validiert werden.

Sobald ein Zahlungsempfänger bestimmt wurde, wird an dessen Emailadresse ein
vorausgefülltes, zu unterschreibendes Dokument geschickt.
Ggf. sendet das Unternehmen einen Brief an den Zahlungsempfänger um bei
Zustellung eine ladungsfähige Adresse zu verifizieren.

Der Zahlungsempfänger muss dieses unterschrieben an das Unternehmen
zurückschicken, damit er nach Überprüfung freigeschaltet werden kann.
(Feld: payee_valid).

Ein validierter Zahlungsempfänger kann für Auszahlungen aus allen validierten
Bankverbindungen der Portalbenutzer-Partei und des Künstlers eine Bankverbindung
auswählen.

Für jeden Künstler wird die zuletzt gewählte Bankverbindung als Standard
solange gespeichert, bis der Zahlungsempfänger wechselt.

Wahlvorgang

Bei Anlage eines neuen Künstlers ist der Zahlungsempfänger automatisch die
Portalbenutzer-Partei.

Bei Künstlergruppen kann ein bestehender oder nicht vorhandener
Zahlungsempfänger durch einen Neuvorschlag (Feld: payee_proposal) in einem
Wahlvorgang Einstimmig von allen Mitgliedern bestimmt werden.
Bei Gegenstimmen in der Wahl wird der Vorschlag zurückgesetzt und
zur Klärung zurück an die Gruppenmitglieder delegiert.

Ein aktueller Zahlungsempfänger kann jederzeit von jedem Mitglied der
Gruppe abgewählt werden.
Gibt es keinen Zahlungsempfänger, kann jedes Mitglied einen Zahlungsempfänger
vorschlagen.

Wird ein Zahlungsempfänger abgewählt oder vorgeschlagen, werden alle Mitglieder
per Email benachrichtigt.

Ist ein Zahlungsempfänger vorgeschlagen, kann jedes Mitglied diesen akzeptieren
und wird einer Liste (Feld: payee_acceptances) hinzugefügt.

Ist nach einer Akzeptierung die Liste der Zustimmungen gleich der Liste der
Mitglieder, ist die Wahl erfolgreich abgeschlossen und muss noch von den
Administratoren des Unternehmens validiert werden.

Der genaue Zeitpunkt aller relevanten Änderungen (Abwählung, Vorschlag,
Akzeptieren, Ablehnung oder Validierung) kann über die Historisierung in Tryton
nachvollzogen werden.

Bei erfolgreicher Abwahl werden alle Konten der Gruppe abgerechnet.

Verwaltung des Repertoires

Werke (Creation)

Ein Werk enthält alle Angaben, die ein Werk identifizieren
(Name, Künstler, usw.).

Ein Werk ist ein Stück im Sinne der Urheberschaft.

Werke haben eine Lizenz (Modell: licence) mit einem Gültigkeitszeitraum
(Felder: valid_from, valid_thru)

Mögliche Lizenzen können im System gepflegt werden.

Einem Werk können mehrere Fingerprints von verschiedenen Fingerprinting
Systemen zugeordnet werden.

Werkableitung

Künstler können bei einem Werk für die Urheberschaft von Komposition und Text
eingetragen werden (Feld: composition, lyrics).

Leitet sich ein Werk von anderen Werken ab, kann das abgeleitete
Werk (Derivat) dem ableitenden (Original) zugeordnet werden (Feld: derivative_creation,
original_creation).

Eine Werkableitung kann sich auf die Komposition (Composition) und/oder auf den Text(Lyrics)
beziehen, was als Eigenschaft der Ableitung gespeichert wird.

Ein Werk kann sich von mehreren Werken ableiten.

Werkableitungen müssen zyklenfrei aufeinander aufbauen.

Veröffentlichung (Release)

Ein "Release" ist eine assoziative Verknüpfung von
Werken im
Sinne einer Veröffentlichung auf einem Medium (z.B. CD-Album,
Internetveröffentlichung, usw.).

Veröffentlichungen werden in erster Linie für die Erfassung von Metadaten
verwendet und dienen der intuitiven Benutzerführung.

Möglicherweise vererben Veröffentlichungen einige Metadaten an die Werke oder
Künstler.

Eine Veröffentlichung enthält alle Angaben, die ein Werk identifizieren
(Name, Künstler, Albumcover, usw.).

Insbesondere gibt es ein Feld für den Namen des Künstlers (Feld:
display_artist_name), falls dieser für Veröffentlichungen seinen Namen ändert.

Ein Werk kann keinem, einem oder mehreren Veröffentlichungen zugeordnet werden.

Im Portal funktioniert die Werkeverwaltung sowohl über eine
veröffentlichungsbasierte Ansicht, in der die Veröffentlichungen mit
Albumcover und Werkeliste dargestellt werden,
als auch über eine komplette werkzentrierte Tabelle mit allen Werken
gelistet.

Sampler können vorerst nicht sinnvoll verwaltet werden, da es nur ein
rudimentäres Rechtesystem für Veröffentlichungen geben wird, bei der alle
involvierten Künstler Lese- und Schreibrecht auf Veröffentlichungen haben.
Einzelne Bestandteile (Tracks, Beiträge) von Samplern können ohne weiteres
verwaltet werden.
Es fehlt lediglich die Möglichkeit derartige Bestandteile zu einem Sampler
zusammenzufassen.

Anlage

Portalbenutzer in der Rolle "Creative" können sowohl neue Werke anlegen und diese
dabei einer Veröffentlichung zuordnen, als auch neue Veröffentlichungen
anlegen und Werken zuordnen.

Bei Anlage eines Werks soll das Lied als Audiodatei hochgeladen werden,
damit wir einen Fingerprint daraus generieren können.

Bis auf Ausnahmen werden als Audiodateien nur verlustfreie Formate akzeptiert (WAV, FLAC, AAC-losless...). Hierfür muss auch nach Upload die Datei überpruft werden, um Benutzerfehler zu vermeiden.

Die hochgeladenen Werke werden gespeichert.

Nach Hochladen wird anhand des Fingerprints in der internen Datenbank gesucht
und falls vorhanden über einen Forderungsprozess (Claim Process) beansprucht.

Ansonsten ist das Verfahren zur Anlage von Werken und deren Veröffentlichungen
analog zur Anlage von Künstlern (Suche in interner/öffentlicher Datenbank, ggf.
Forderungsprozess, ansonsten Neuanlage).

Das erfolgreiche anfordern (Claimen) eines Werks führt vorerst zu komplettem
Lese-/Schreibzugriff auf alle Veröffentlichungen, die mit dem Werk
zusammenhängen.

Fingerprint

Fingerprints werden zum einen auf Basis der Nutzungen (Utilisation) von
veröffentlichten (released) Werken (creations) erstellt (z.B.
Version auf CD), generalisieren aber über die Veröffentlichung (Version auf CD,
Schallplatte, Kassette, usw.).

Zum anderen werden Fingerprints von direkt hochgeladenen Musikstücken erstellt.

Ein Fingerprint identifiziert also genau ein Werk, das allerdings in
verschiedenen Veröffentlichungen genutzt werden kann.

Plugin: Adore

Rollen

Mit der Rolle "Adorer" erhält ein Portalbenutzer ein Konto (PocketCredit) und kann ein
zu verteilendes Budget festlegen.

Das Budget des Adorer kann nicht kleiner als ein Minimalbetrag sein, der auf administrativer Ebene festgelegt werden kann.

Mit der Rolle "Adored" erhalten alle bestehenden und neuen Künstlern ein Konto
(HatCredit).

Die Rolle "Adored" (und damit einschließlich der Rolle "Creative", falls keine
andere Rolle davon abhängt), muss wieder entfernt werden können.

Bei Entfernen der Rolle "Adored" bleiben die Daten bezüglich Künstlern/Werke
bestehen.

IMP Case

Nach Registrierung im System wird dem Portalbenutzer als Default-Rolle die Rolle
"Adorer" zugeordnet.

Einstellungen

Ein Adorer kann ein Budget festlegen.

Ein Adored kann für seinen Künstler eine Standardbankverbindung bestimmen.

Geldverteilungssystem

Konten

Buchhalterische Betrachtung

Für BuchhalterInnen mit Datevhintergrund: In Tryton ist ein Buchungssatz eine
Vernüpfung von mindestens zwei Buchungszeilen, die über die gleiche Summe im
Soll und Haben verfügen müssen. In einer Buchungszeile stehen an
Buchhaltungsdaten ausschließlich Datum, entweder Soll- oder Habenbetrag und das
einzelne Konto auf das gebucht werden soll. Für die unterschiedlichen
Benutzerrollen des Systems werden relevante Daten wie verteilte und zugeteilte
Gelder direkt aus der Buchhaltung ermittelt und summiert.

Tryton unterstützt den Abschluß von Geschäftsjahren und Buchungsperioden. Damit
die Berechnungszeiten aus der Buchhaltung performant bleiben, sollten
Buchungszeiträume zeitnah geschlossen werden. Beim Abschließen von Perioden
wird pro Konto der Saldo summiert und getrennt gespeichert.

Transaktionssicherheit ist in Tryton gegeben: Ein Buchungssatz wird entweder
gesamt, oder gar nicht umgesetzt.

Konten (Credit)

Jedes Konto hat eine ReferenzID, welche als Token für die Zuordnung von
Überweisung zu Konto fungieren kann.

In Tryton dürfen Konten standardmäßig überbucht werden (Usecase: Weiterreichen eventueller Kosten nach Anmeldung an den Webnutzer, z.B. ggf. Gema-Gebühren für das Fingerprinting).

Übersicht: Konten

'''Bankkonten (BankAccount):'''

- Portalbenutzer
- Künstler

'''Konten (Credit):'''

- CompanyCredit: Ein Konto des Unternehmens für Allocation- und Überweisungsgebühren
- PocketCredit: Ein Pocket-Konto pro Portalbenutzer
- HatCredit: Ein Hat-Konto pro Künstler
Übersicht: Transaktionen
Quell-Konto Quelle-Besitzer Ziel-Konto Ziel-Besitzer Ziel-Auslöser Action Kommentar
BankAccount (beliebig) PocketCredit Portalbenutzer manuell (Portalbenutzer) BankAccount: transfer_to_account_credit Zuordnung über ReferenzID; Validierung manuell von Administration
PocketCredit Portalbenutzer HatCredit Künstler automatisch bei Verteilung (monatlich) automatisch bei Löschen des Portalbenutzers Zuordnung nach Nutzung
PocketCredit Portalbenutzer CompanyCredit Company automatisch bei Verteilung (monatlich) automatisch bei Löschen des Portalbenutzers Gebühren für das Unternehmen
HatCredit Künstler HatCredit Künstler manuell (Zahlungsempfänger) AccountHat: distribute_to_hats Zielkonto beschränkt auf Mitglieder des Künstlers
HatCredit Künstler PocketCredit Zahlungsempfänger manuell (Zahlungsempfänger) AccountHat: transfer_to_account_credit
HatCredit Künstler BankAccount Künstler/Zahlungsempfänger manuell (Zahlungsempfänger) automatisch jährlich vor Kontenabschluss (mit Zahlungsempfänger) AccountHat: transfer_to_bank_account Zielkonto beschränkt auf validierte Bankkonten
HatCredit Künstler CompanyCredit Company automatisch bei Löschen des Künstlers automatisch jährlich vor Kontenabschluss (ohne Zahlungsempfänger)

Einzahlung von Guthaben

Nur Adorer können Geld auf dem PocketCredit einzahlen oder einzahlen lassen.

Eingezahltes Guthaben auf dem PocketCredit wird nicht wieder ausgezahlt.

Geld kann von einem beliebigen Bankkonto mit einer Überweisung unter Angabe der
ReferenzID des PocketCredit eines Adorers auf das Bankkonto des Unternehmens
eingezahlt werden.

Die Administration überprüft die Buchungseingänge und bucht nach Eingang die
Einzahlung intern auf das entsprechende PocketCredit mit der ReferenzID.

Nutzungen (Utilisations)

Ein Adorer (allg. Utilizer, Nutzer) nutzt einzelne Werke.

Die Nutzungen werden der C3s mit einem Player Plugin/Mod für Musikplayer übermittelt.

Das Player Plugin/Mod registriert sich mit einer ClientUuid per oauth am System.

Adorer können die ClientUuid einsehen und löschen, aber nicht manuell
erstellen.

Adorer können noch nicht abgerechnete, einzelne Nutzungen wieder löschen (z.B. bei fehlerhafter
Erkennung oder einem versehentlichen Abspielen eines Liedes) aber keine manuell
hinzufügen.

Verteilung (Distribution)

Ein Adorer kann einen festen, monatlichen Betrag (Budget) festlegen, welches
anhand der Einzelnutzungen im selben Zeitraum an die Hats der Adored verteilt
werden soll.

Das Budget wird jeden Monat automatisch vom Guthaben des PocketCredit
abgebucht

Das verwendete Budget kann nur maximal soviel wert sein, wie Geld als Guthaben
auf dem PocketCredit vorhanden ist.

Wenn das PocketCredit leer ist, wird kein Budget verteilt.

Der monatliche Prozess der Verteilung des Budgets aller Adorer wird
Distribution genannt.

Eine Distribution ist eindeutig identifizierbar.

Ein Distributionslauf erzeugt eine Liste von Zuordnungen (Allocations).

Zuordnung (Allocation)

Die Allocation ist nutzerbezogen und bezeichnet das Mapping von dem monatlichen
Budget eines Adorers, über die Nutzung von Werken heruntergebrochen auf die
Hats beliebig vieler Künstlern.

Das Ergebnis wird in einen einzelnen, zu der Allocation zugehörigen
Buchungssatz übertragen.

Eine Allocation setzt sich aus Allocationlines zusammen.

Genauere Zusammenhänge von Werkableitungen und Urheberschaft einzelner Artist an einem Werk können zwar erfasst werden,
sollen aber nicht zu einer automatisierten Verteilung führen, da die Verhältnisfrage schwer zu klären ist.
Daher wird pro Werk nur auf einen einzigen Künstler ausgeschüttet, Bands müssen die erhaltenen Gelder selbst verteilen.

Auf Buchungsebene wird pro Allocation ein Buchungsatz erzeugt. Es wird pro
Allocationline eine Buchungszeile als Hatanteil erzeugt und zusätzlich eine
Buchungszeile für das Pocket.

Zum Rückrechnen von Ausschüttungsanteilen auf den Künstler soll von Anfang an die
Historie der Künstlertabelle zum Zeitpunkt der Allocation hergenommen werden.
Dies wird aber erst relevant, sobald automatische Mechanismen der
Hatdistribution innerhalb eines Künstlers greifen.

Auf Alben wird die Nutzung niemals zurückgerechnet werden können, da ein
Werk auch keine, oder mehrere Releases haben kann.

Gehörte Werke können auf Alben nur mit Hilfe der unsicheren, nutzerabhängigen Metadaten geschlossen werden.
Diese sollen nur zu einer Zuordnung führen, falls das Album über einen fehlertoleranten Algorithmus mit einem
schon vorhandenen Album in unserer Datenbank in Verbindung gebracht werden kann.

Verwaltungskosten werden vor jeder Distribution von jedem zu verteilenden Budget
abgezogen und bei dem CompanyCredit des Unternehmens als Einnahmen verbucht.

Verwaltungskosten sind ein prozentualer Anteil am zum verteilenden Betrag.

Damit besteht eine Allocation anfänglich im Idealfall aus einer Allocationline für
das Budget, viele Allocationlines für die HatCredit der Künstler und einer
Allocationline für das CompanyCredit

Für Adored, die in unserem System nicht angemeldet sind, oder Künstler, die
keinen Zahlungsempfänger haben, wird der Betrag trotzdem auf die Hats gebucht.

Auszahlung (Payment)

Es gibt für jeden Künstler 2-3 notwendige Validierungmechanismen, um Geld zu
verteilen oder ausgezahlt zu bekommen:
- Einigung auf einen Zahlungsempfänger (bei Künstlergruppen)
- Vom Zahlungsempfänger unterschriebenes Dokument
- Validierung des Kontos

Zahlungsempfänger von Adored können das Guthaben des HatCredit
- für Solokünstler auf den PocketCredit übertragen
- für Künstlergruppen auf die HatCredit der Mitglieder weiterverteilen
- an eine validierte Bankverbindung überweisen

Die von dem Zahlungsempfängern verwendete (auch ggf. private) Bankverbindung wird bei
Künstlergruppen den Mitgliedern offengelegt und erscheint in der Kontenübersicht
und in der Abrechnung.

Bankkosten werden bei Auszahlung vom auszuzahlenden Betrag abgezogen und beim
CompanyCredit des Unternehmens als Einnahme verbucht.

Bankkosten sind abhängig von der Zahlungsform (Banküberweisung, Paypal, usw.)
und können sich nach der Höhe des zu überweisenden Betrags richten.

Bei Löschen des Portalbenutzers eines Adored oder entfernen der Rolle Adored bleibt
das Guthaben auf dem HatCredit.

Bei Löschen des Portalbenutzers eines Adorer wird das Guthaben des PocketCredit nach
bisherigem Hörverhalten verteilt, oder fällt an das Unternehmen, falls es kein
Hörverhalten gab.

Umverteiltung (Redistribution)

Um zu verhindern, dass Geld auf nicht zugeordneten Konten liegenbleibt, soll vor jeder Distribution eine Redistribution stattfinden.

In einer Redistribution werden die im letzten Monat an nicht zuordbare Hats verteilten Gelder
wieder in die Pockets der Adorer zurückgebucht und in der folgenden Distribution zusätzlich mit deren Budget neu verteilt.

Analog zur Distribution

- besteht eine Redistribution aus sämtlichen Reallocations des Monats
- ist eine Reallocation das Mapping von beliebig vielen Hats der Adored zurück auf einen Pocket der Adorer
- besteht eine Reallocation aus Reallocationlines
- wird auf Buchungsebene pro Reallocation ein Buchungssatz erzeugt
- wird pro Reallocationline eine Buchungszeile als Hatanteil erzeugt und zusätzlich eine Buchungsteile für das Pocket

Es wird immer nur der Betrag der Distribution des letzten Monats umverteilt.

Solange zwischen zwei Distributionen das Guthaben auf dem Hat nicht verändert wurde, kann der in der
letzten Distribution verteilte Betrag vollständig auf die ursprünglichen Pockets der Adorer zurückgeführt werden.

Sobald zwischen zwei Distributionen ein Payee für einen Hat bestimmt wurde, gilt das Geld der
letzten Distribution als zugeordnet und wird nicht umverteilt.

Auch auf diesen zusätzlichen, umverteilten Betrag fallen die Gebühren an das Unternehmen an.

Komponenten

Dashboards

Für die Rollen Adorer und Adored werden auf dem Dashboard Informationen
angezeigt, was noch für die Nutzung des Adore-Systems getan werden muss.

Bei der Rolle Adorer werden folgende Infoboxen angezeigt:
- "Player Plugin/Mod installieren/registrieren": Anleitung + Downloadlink zu Player Plugin/Mods (falls keine ClientUuid vorhanden ist)
- "Pocket aufladen": Anleitung + Token (falls das PocketCredit 0 € Guthaben hat)
- "Budget bestimmen": Anleitung (falls das Budget 0 € beträgt)
- "Auch Musiker?": Ja/Nein (falls noch nichts ausgewählt wurde)

Bei der Rolle Adored werden folgende Infoboxen angezeigt:
- "Klarnamen eingeben": Formular (falls beim Portalbenutzer der Klarname fehlt)
- "Künstler anlegen": Anleitung (falls der Portalbenutzer keinen Solokünstler hat)
- "Zahlungsempfänger validieren": Anleitung + Dokument-Download (falls der Portalbenutzer beim Solokünstler nicht validiert ist)
- "Werke anlegen": Anleitung (falls noch kein Werk registriert wurde)

Sidebars

Adorer sehen in der Sidebar das Guthaben des PocketCredit und können das Budget
einstellen.

Adored sehen in der Sidebar das Guthaben des HatCredits ihres Solokünstlers

Neuigkeiten

Bestimmte Events im System werden dem Adorer in einer Newsansicht dargestellt.

2DO

Bestimmte Events im System werden dem Adored in einer Newsansicht dargestellt.

2DO

Kontenübersicht (Hat/Pocket)

Die Kontenübersicht ist eine grobe Übersicht über alle Transaktionen, in denen
das Konto involviert war.

Für manche Transaktionen können Detailansichten aufgerufen werden.

Der Adorer sieht in seiner Übersicht über den PocketCredit
- Eingänge von Bankkonten
-Detail: Genaue Bankdaten
- Eingänge von Hats der Solokünstler (1 Eintrag pro Künstler)
- Abzüge der monatlichen Distribution
-Detail: Zusammensetzung nach Werke + Nutzungsanzahl, Gruppierung nach Künstler + Gebühren

Der Adored sieht in seiner Übersicht über den HatCredit
- Eingänge von Hats der Künstlergruppen (1 Eintrag pro Künstler)
- Eingänge von monatlichen Distributionen
-Detail: Zusammensetzung der Distribution nach Werken + Nutzungsanzahl
-Detail: Zusammensetzung eines Werks nach Adorern (anonyme Adorer summiert unter einem anonymen Posten)
- Abzüge von Hatverteilungen
-Detail: Zusammensetzung nach HatCredit der Mitglieder
- Abzüge von Banküberweisungen
-Detail: Bankkontodetails, Gebühren

Alle Portalbenutzer in der Zugriffsliste eines Adored haben vollständigen Lesezugriff
auf die Kontenübersicht.

Abrechnung (Billing)

Für Adored werden monatliche Abrechnungen erstellt und als pdf/csv zum Download
hinterlegt.

Alle Portalbenutzer in der Zugriffsliste eines Adored haben vollständigen Lesezugriff
auf die Abrechnungen.

Eine Abrechnung kann folgende Transaktionen enthalten:
- Eingänge von Hats der Künstlergruppen (1 Eintrag pro Künstler)
- Eingänge von monatlichen Distributionen (1 Eintrag pro Werk)
- Abzüge von Hatverteilungen
- Abzüge von Banküberweisungen

Die Metadaten einer Abrechnung enthält die Felder:
- Zahlungsempfänger (Name, ID)
- Kontostand (Beginn, Ende)
- Periode der Abrechnung (Monat/Jahr)

Die Tabelle einer Abrechnung enthält die Felder:
- ID (Allocationline)
- Typ (Bankeinzahlung, Banküberweisung, Hatverteilung, Distribution)
- Object (Konto, Hat, Werk)
- Soll (Betrag des Eingangs)
- Haben (Betrag des Abzugs)

Nach einer Abrechnung werden eine Buchungsperiode und damit alle Konten
(HatCredit, PocketCredit, CompanyCredit) abgeschlossen, pro Konto der Saldo
summiert und getrennt gespeichert.

Von der Administration soll im System festgelegt werden können, wie lang eine
Buchungsperiode ist (rechtlich jeden Monat gefordert, in Wirklichkeit ca. alle
3 Monate).

Außerdem findet eine Abrechnung statt, wenn ein Zahlungsempfänger eines Künstlergruppen
abgewählt wird.

Statistiken (Statistics)

2DO

Fingerprint-Crawler

Der Fingerprint-Crawler ist ein eigenständiger Service, der noch nicht
verarbeitete Datensätze von übertragenen Nutzungen aus dem Utilisation
Adore Modell einliest.

Die Fingerprints werden je nach verwendetem Fingerprinting-Algorithmus bei
einem entsprechenden Matching-Services angefragt und von dort als Ergebnis
ein eindeutig identifizierbares Werk entgegengenommen.

Werk, Künstler, creation.utilisation.adore-Referenz und
Fremdreferenz des Matching-Service werden im Model
'creation.utilisation' gespeichert.

S.a. https://chili.c3s.cc/issues/1760

Metadata-Crawler

Der Metadata-Crawler ist ein eigenständiger Service, der bereits
verarbeitete Datensätze von Werken und Künstlern einliest und mit
Daten aus verschiedenen Fremdquellen qualifiziert.

Es sollen Verweise zu anderen Quellen gespeichert und automatisch gepflegt
werden, bspw. musicbrainz-, lastfm-, librefm-ids.

S.a. http://developer.echonest.com/docs/v4#project-rosetta-stone

Aussichten

Zurückgestellt

- Es soll möglich sein, den ersten X Registrierungen direkt Y Euro gutzuschreiben
- PostIdent Online für Verifikation der Künstler
- automatisches Scannen der Buchungseingänge nach Tokens und Buchung auf die jeweiligen Konten
- Ein Mechanismus soll einen Zahlungsempfänger dazu befähigen, die Verteilung auf die Hats der Mitglieder nach einem bestimmbaren Verhaltnis zu automatisieren.
    -Dafür müssen in der Allocation pro Utilization so viele Allocationlines erzeugt werden, wie Künstler an dem entsprechenden Werk beteiligt sind. Damit könnten wir die jeweilgen Anteilsverhältnisse der Künstler am Werk impizit über die Anzahl der Einträge pro Utilization berechnen.
    -Ein weiterer Schritt wäre die Verteilungsmöglichkeit auf abgeleitete Werke (z.B. Remix, Cover, usw.), auch hinsichtlich der Attribution der (CC) Lizenz.
- Mitglieder sollen eine Standardrolle innerhalb der Gruppe einnehmen können (z.B. Gitarist, Sänger, usw.)
- Künstlergruppen sollen weiter in semantische Gruppen unterteilt werden können (Bands, Orchester, usw.), sobald das funktional notwendig wird.
- In einer Partei sollen auch Social Media Links gespeichert werden können.
- Vereinfachung des Payouts für einen mehrfachen Zahlungsempfänger: Eine Liste aller Bands mit Checkboxen und einem Betragsfeld, welche zusammen an ein Bankkonto überwiesen werden können
- Bei SafeCreative registrierte Werke sollen für einen Künstler importiert werden können.
- Blacklists für Künstler/Werke bei Nutzung über die Player Plugin/Mods
- Ein Wizard für die anfängliche Konfiguration, die die notwendigen Schritte anhand einer Auswahl der gewünschten Rollen möglichst optimal berechnet und präsentiert
- Künstler sollen zusätzlich freie Tags für Rollen bei einem Werk definieren können (Gitarre, Keyboard, Triangel usw. im Feld "Musicians")
    -Künstler sollen eine Standardrolle definieren können, die bei der Anlage eines Werks vorausgewählt ist.
- Um den Claim-Prozess zu vereinfachen, soll es analog zum Warenkorb ein "Claimkorb" geben, bei dem gesammelt alle claims beim checkout an die jeweilige EMail gesendet werden.
    -Das Claimen eines Release soll ermöglicht werden und das Claimen aller Werke darin implizieren
- Ein genaueres Rechtesystem für Releases soll ermöglichen, z.B. Sampler abbilden zu können (Minimalstruktur: Zugriffsliste analog zu Künstler).
- Für das Tracken, wie viel Geld ein nicht angemeldeter Künstler bekommen hat, soll in einem Feld ('virtual_hat' Decimal(16,16) ) ein Zähler implementiert werden, der sich diese Zahl merkt. Gründe: (1) Die regelmäßige Hat-Umverteilung und (2) die Adorereinstellungen, bei denen das Geld nicht auf dem Hat landen soll, würden diesen Wert verfälschen. Lösung für (1) ist das Hochzählen des Feldes bei jeder Distribution. Lösung für (2) ist das "virtuelle" Berechnen der Verteilung ohne Beachtung der Profileinstellungen des Portalbenutzes und Hochzählen des Feldes um diesen virtuellen Wert, bevor die wirkliche Allocation stattfindet (verdoppelt den Rechenaufwand, aber nur 1x im Monat).
- Für Adorer eine Möglichkeit der Anteilszeichnung mit dem Geld aus dem Hat, falls > 50 € Guthaben
- Independent-Grenzwert: Möglichkeit für Adorer, die Künstler auf Geringverdienende zu beschränken (Grenzwert in Euro)

Ideen

- TAN Listen für Edits von Daten (Lieder, etc.)
- Ein Streitschlichtungssystem für Verteilung von Guthaben des HatCredits an abgeleitete Werke, bei dem sich die Zahlungsempfänger der jeweiligen Bands pro Werk auf ein Verhältnis einigen müssen, bevor ausgezahlt bzw. auf das Hat eingezahlt wird.
- Portalbenutzer miteinbeziehen, um auf Fehler bei Zuordnungen von Künstlern/Werke aufmerksam zu werden, z.B. im player feedback an Portalbenutzer ermöglichen, wenn ein lied nicht oder falsch erkannt wird. Einbau eines Formulars für Korrekturvorschläge.
- Notwendige Validierung der Zugehörigkeit von Werken über
    -SafeCreative
    -EAN Code
- Bei Anlage von Künstlern/Werke könnte bei Abfrage der internen/öffentlichen Datenbank ein Disambiguierungsmechanismus helfen, der dem Portalbenutzer die sich am meisten unterscheidenden Merkmale der möglichen Bands als möglichst binäre Fragen präsentiert
- Neuigkeiten: Bestimmte Events im System werden dem Portalbenutzer in einer Newsansicht dargestellt.
- Statt eines einfachen Lizenz-Felds (für die creation) Release-Datum, Lizenz und Lizenz-Version Felder einrichten -- evtl eigene Tabelle mit Lizenzen, Versionen, die mit Logo, URL und ähnlichem angereichert werden können