2023.11 - November

1.Allgemein

1.1.               Einspielung der Bestandsdaten als Excel – Dachverband

Die Einspielung der Bestandsdaten in Excel-Form wurde überarbeitet, sodass nun die Vereinszuordnung auch über die Nummern des Dachverbandes (sofern in Phoenix II gepflegt) geschehen kann.
Hierzu wählt man bei der Herkunft „Dachverband B-Meldung“ aus, damit Phoenix weiß, dass er auf das Feld „VereinsNrSpez“ (meistens ist hier die Dachverbands-Nr hinterlegt) prüfen muss.

Achtung: Wenn Sie die Beitragsrechnungen über Phoenix erstellen, werden die eingelesenen Daten mit der Herkunft „Dachverband B-Meldung“ nicht berücksichtigt.

1.2.               Zahlungsart-Anzeige bei der Sammelanmeldung

Bei der Sammelanmeldung von Vereinen zu Seminaren wird nun die Zahlungsart mit angezeigt.

1.3.               Sortierung der Fragen im Fragen-Modul

Die Sortierung der Fragen wurde nun vereinheitlicht, sodass beim Anlegen einer Frage, bei der Abfrage dieser und beim Excel-Export die eingestellten Fragen in derselben Reihenfolge erscheinen.

1.4.               Postanschrift-Anzeige im Vereinsaccount

Wie bereits im GS-Admin unter „Vereine“ > Detailansicht eines Vereines wird nun auch im Vereinsaccount die Postanschrift bei den Vereinsdaten angezeigt. Somit ist direkt ersichtlich welche Postanschrift hinterlegt ist. Änderbar ist die Postanschrift weiterhin im Vereinsaccount unter „Funktionen“. Für den GS-Admin ändert sich nichts.

Open

1.5.      Verknüpfung von Kennzeichen und Zulassungsvoraussetzungen überarbeitet

Bei der Seminarverwaltung kann man zu den einzelnen Seminaren gewisse (vorher gepflegte) Zulassungsvoraussetzungen für die Teilnahme an Seminaren definieren. An diese Zulassungsvoraussetzungen lassen sich „Kennzeichen“, „Funktionen“ oder auch „Lizenzen“ verknüpfen, also die Notwendigkeit, dass man ein Personenkennzeichen (meistens dann eine Datei als Nachweis, z.B. „Teilnahme an einem Erste-Hilfe-Kurs“) , eine Funktion oder eine Lizenz hat, um an diesem Seminar teilnehmen zu können.
Die Verknüpfung zu den Personenkennzeichen wurden wie folgt erweitert und verbessert:

• Datei-Upload bei den Personenkennzeichen:

  • Lädt die Person selbst oder ein GS-Admin bei dieser Person eine Datei bei diesem Personenkennzeichen hoch, wird automatisch eine Verknüpfung zur Zulassungsvoraussetzung erstellt. Die Datei wird bei der Zulassungsvoraussetzung hinterlegt und ist dann im Seminar einsehbar.

• Datei-Upload bei den Zulassungsvoraussetzungen:

  • Wird bei den Zulassungsvoraussetzungen entweder bei der Seminaranmeldung selbst, im Personenaccount oder vom GS-Admin die Datei für das Personenkennzeichen hochgeladen, wird automatisch auch das Personenkennzeichen erstellt. Die Datei wird also korrekt verknüpft.

In beiden Fällen gehen wir davon aus, dass die Zulassungsvoraussetzung so eingestellt wurde, dass diese an ein Personenkennzeichen geknüpft ist.

In beiden Fällen wird nun eine Wiedervorlage für den GS-Admin erstellt, so das über die Wiedervorlagenübersicht der Bestätigungs- oder Ablehnungsprozess schnell und komfortabel durchführbar ist.

• Bei der Wiedervorlage:

  • Akzeptieren:

    • Das Kennzeichen wird als “IST” gekennzeichnet

    • Die Zulassungsvoraussetzung wird als “IST” gekennzeichnet.

  • Ablehnen:

    • Das Kennzeichen wird gelöscht

    • Die Zulassungsvoraussetzung wird gelöscht
      
      

2. Fakturierung

Mit den Release-News im vergangenen Oktober haben wir eine größere Umstellung im Bereich Fakturierung angekündigt. Für die von Ihnen zum Teil durchgeführten Tests in der Testumgebung und die Unterstützung bei der Umstellung möchten wir uns zunächst bei Ihnen bedanken.

Da wir die umfangreichen Rückmeldungen bis zum kommenden Release zwar umgesetzt bekommen würden, diese aber aus zeitlichen Gründen nicht mit der gleichen Sorgfalt und Intensität getestet werden können, wird die geplante Umstellung erst mit dem Release im Januar 2024 vorgenommen.

Die Umstellung ist aus unserer Sicht absolut notwendig und wird den Bereich Fakturierung zukünftig aufwerten und die Performance in diesem Modul optimieren. Jedoch darf die Umstellung kurzfristig zu keinem Fehler oder gar Verlust der Stabilität innerhalb des Moduls führen, weshalb aus unserer Sicht weitere (detaillierte) Tests notwendig sind. Zu dem Thema Stabilität und Qualität werden ab dem kommenden Jahr generell Prozessanpassungen vorgenommen (siehe hierzu 3. Information: Umstellung unseres Release-Prozesses).

Ebenso stehen bei einigen Sportfachverbänden im Januar und Februar die ersten Beitragsrechnungen für das Jahr 2024 an. Dies möchten wir nutzen, um basierend auf den alten, als auch den neuen Bestandsdaten die Rechnungsgenerierung im Test weiter zu prüfen.

Sollten Sie hierzu Fragen oder weitere Testrückmeldungen haben, wenden Sie sich bitte an uns. 

Information: Umstellung unseres Release-Prozesses

Bisher gestaltete sich der Release-Prozess wie folgt:

• Aufgrund der Kundenanforderung und Kapazitäten werden die Tickets in ein Release geplant

• Innerhalb des Release-Monats werden die umzusetzenden Tickets programmiert

• Eine Woche vor Release-Übernahme gibt es eine einwöchige Testphase (Tests durch Sie als Kunden als wir intern)

• Versand der Release-Informationen und Livestellung des Releases am letzten Mittwoch des Monats.

Potenzielle Risiken / Auswirkungen:

• Tickets werden zwar im Einzelnen getestet, allerdings nicht in Kombination mit anderen Anpassungen.

• Aufgrund zu wenig Testzeit (nur eine Woche) isst kein Komplett-Test von Phoenix II möglich.

Open

Der neue Release-Prozess gestaltet sich wie folgt:

• Einplanung erfolgt nach wie vor aufgrund Kundenanforderung und vorhandenen Kapazitäten.

• Tickets werden im Vormonat zur Release-Übernahme entwickelt (Entwicklung im Januar für März-Release).

• Zum Ende des Vormonats wird das Release generiert und in die für Sie als Kunden neu bereitgestellte TESTING-Umgebung gestellt („testing

kürzel.it4sport.de“).

• Die Entwicklungsphase für das Release ist abgeschlossen und es werden keine funktionalen Anpassungen mehr vorgenommen.

• In der Testing-Umgebung steht der aktuelle Code des Produktiv-Systems inkl. der umgesetzten Anforderungen / Tickets zur Verfügung.

• Das Release wird einen Monat in dieser Umgebung getestet. Abnahme der Anforderungen erfolgt zukünftig in der Testing-Umgebung, die durch die neue Vorgehensweise deutlich stabiler sein wird, als die bisher durch weitere Tests beeinflusste Test-Umgebung

• Nicht getestete oder nicht erfolgreich getestete Anforderungen werden bei entsprechenden Kapazitäten korrigiert oder fallen aus der Testing-Umgebung.  Neu-Einplanung für das Folge-Release.