In Cyclos kann man Kontotypen selber definieren. Dabei werden zwei Arten von Kontotypen unterschieden: 'Systemkonten' und 'Mitgliederkonten'.
Grundsätzlich empfiehlt es sich sparsam mit dieser Möglichkeit umzugehen, da zusätzliche Kontotypen auch zusätzliche Komplexität mit sich bringen. Ein weiterer Kontotyp macht immer dann Sinn
- wenn man eine andere Währung buchen können muss
- wenn für dieses Konto andere Regeln für Gebühren gelten sollen
- wenn andere Regeln für die Sichtbarkeit des Kontostandes gelten sollen
Die Überlegung, welche Konten man als Systemkonto anlegt sind von großer Bedeutung für die Komplexität eines Systems in Cyclos. Ein Systemkonto kommt in jedem Cyclos-System genau einmal vor, jedes Systemkonto ist deshalb auch immer ein eigener Kontotyp und jede Überweisung zu oder von einem Systemkonto an irgend welche anderen Konten muss man separat definieren. Wenn man sehr viele Systemkonten anlegt, dann kann das sehr schnell ins Kraut schiessen.
Die Gemeinschaftskonten aus dem ToG könnte man in Cyclos auf zwei verschiedene Arten abbilden, als Benutzerkonten in einer eigenen Mitgliedergruppe, oder als Systemkonten. Die beiden Ansätze haben unterschiedliche Vor- und Nachteile.
- Wenn ein Konto unbegrenzt sein soll, dann muss das in Cyclos ein Systemkonto sein. Nur Systemkonten können unbegrenzt sein, Benutzerkonten kann man so anlegen dass nach oben keine Grenze ist, aber nach unten muss man immer ein Limit angeben. Das Limit kann jedoch sehr hoch sein. 1 Milliarde Milliarden als negatives Limit habe ich schon mal ausprobiert (10 hoch 18) - dass ist dann ganz ähnlich wie ‚unlimitiert‘.
- Systemkonten können nur von Admins eingesehen werden. Nur Admins können von Systemkonten abbuchen. Wenn ein Tauschring auf maximale Transparenz wert legt dann können Systemkonten echt problematisch sein.
- Konto-bezogene Gebühren können nur auf Systemkonten eingehen. Ein Tauschring der fixe Monatsgebühren einführen möchte oder eine prozentuale Liegegebühr braucht dafür mindestens ein Systemkonto. Bei Gebühren auf Transaktionen (zB Überweisungsgebühren, Provisionen etc) kann man als Ziel auch ein Benutzerkonto angeben, wenn jedoch Liegegebühren eingeführt werden oder Mitgliedsgebühren, dann braucht man dafür ein Systemkonto.
‚Transparenz‘ und ‚unlimitiertes Konto‘ schliessen sich also aus.
Wenn man trotzdem will, dass die Mitglieder dieses Konto einsehen können, dann kann man sich damit behelfen, daß zwar die Gebühren über ein Systemkonto bucht, man alle Ein- und Ausgänge auf diesem Systemkonto aber auf ein Benutzerkonto spiegelt. Der Kontostand kann damit allen Teilnehmern sichtbar gemacht werden, um Talente von dort weiter ausbuchen braucht es dann aber trotzdem einen Admin, das halte ich aber für keine große Einschränkung.
Übliche ToG Gemeinschaftskonten wie Außenhandelskonten oder RTR-Konto sollen in der Regel keine Einnahmen aus Gebührenbuchungen erhalten, deshalb könnte man diese vermutlich besser als spezielle Benutzerkonten abbilden. Eigentlich will man diese Konten unlimitiert, was mit dieser Umsetzung als Benutzerkonten nicht geht. Eine sehr riesig hoch gesetztes Limit tut es aber auch.
Wenn man Benutzerkonten verwendet für die Umsetzung der Gemeinschaftskonten aus ToG, dann rate ich dazu, dafür eine eigene Benutzergruppe zu definieren. Dies ermöglicht es, für den Zugriff auf dieses Konto separat Regeln zu verwalten. In aller Regel wird man noch nicht mal einen eigenen Kontotyp benötigen sondern man verwendet dieselben Konten wie bei den Mitgliedern, nur eben in einer eigenen Benutzergruppe 'Gemeinschaftskonten' oder 'Außenhandel', und dann legt man in dieser Gruppe je einen Pseudobenutzer für jedes Gemeinschaftskonto an.
Diese Benutzer können von den Admins aus gebucht werden, dafür müssen sich diese nicht mit diesem Benutzer anmelden. Und wenn man will, dann kann man die Kontostände dieses Benutzertyps auch einsehbar machen durch die anderen Mitglieder.
Bei Konten wie dem Sozialkonto hat man oft Gebühren aus denen das Sozialkonto gespeist wird. Diese Kontogebühren kann man über ein zentrales Systemkonto buchen lassen und von dort automatisch weiter auf ein für alle sichtbares Benutzerkonto.
Gibt es Startguthabenkonto oder ein regelmäßiges Grundeinkommen von dem jeder neue Benutzer ein Startguthaben bekommt, dann könnte man das grundsätzlich auch als Benutzerkonto verwalten, wenn man bereit ist, das Startguthaben manuell auszuzahlen. Man könnte das Auszahlen eines Starguthabens aber auch als 'negative Gebühr' einrichten, damit könnte sie automatisiert mit dem Anlegen eines neuen Mitglieds oder im Falle des Grundeinkommens regelmäßig jeden Monat ausgezahlt werden. Entweder nimmt man dann dafür ein Systemkonto, oder man benutzt den selben Trick wie vorhin, indem man zwar über ein Systemkonto auszahlt, aber dies sofort weiter belastet an ein für alle sichtbares Benutzerkonto. In der Regel ist der Stand auf solch einem Startguthabenkonto aber nicht so wesentlich für die Teilnehmer, vielleicht genügt hier das nicht sichtbare Systemkonto auch.
Oliver [17.03.2018]
