Kann beim Erstellen von Berichten keine Berichtsprache aus dem spezifischen Datensatz ermittelt werden (z.B. aus dem Feld Person-Korrespondenzsprache bei Personen, Anmeldungen, Rechnungen etc.), so wird neu versucht, die aktuelle Applikationssprache als Berichtsprache zu verwenden. Dieser Mechanismus funktioniert selbstredend nur, wenn in der Berichtvorlage eine entsprechende Sprachversion definiert wurde.
Bei Berichtvorlagen, welche die Option "Ein Dokument pro Objekt" nicht aktiviert haben, wird immer als erstes versucht die aktuelle Applikationssprache als Berichtsprache zu verwenden (die Datensätze werden nicht berücksichtigt).

Bei Bestätigungs- und Frage-Dialogen bei der Ausführung von Funktionen ist neu der OK-Button immer fokussiert, so dass der Benutzer die Tasten "ENTER" oder "LEERSCHLAG" drücken kann, um weiter zu kommen.
Die Bestätigungsmeldung einer erfolgreich ausgeführten Funktion wird nicht mehr in einem Dialog angezeigt, welcher "weg geklickt" werden muss, sondern neu in der Statuszeile ganz unten. Sind bei der Ausführung Fehler aufgetreten resp. bei Systemwarnungen wird immer der Dialog angezeigt (Verhalten wie bisher).

Die Anzahl der Felder im Dialog "Neues Objekt erstellen" für Durchführungen und Produkten wurde reduziert. Es sind jetzt nur noch die Felder sichtbar, welche für die Speicherung der neuen Durchführung resp. des neuen Produkts zwingend erforderlich sind.
Das Feld Anlasskategorie wurde ebenfalls entfernt, da die dazugehörende Auswahlliste fehlerhaft war.

In gewissen Situationen wurde bei einem Ausführungsfehler einer Funktion dem Benutzer dieser nicht angezeigt. Die Funktion wurde vom System nach der Parameter-Eingabe kommentarlos abgebrochen. Dies trat z.B. bei der "Personen anmelden"-Funktion auf.
In gewissen Fällen ist die Fortschrittsanzeige nach dem Beenden einer Funktion mit 100% Fortschritt sichtbar geblieben. Sie konnte auch vom Benutzer nicht geschlossen werden. Dies trat z.B. beim Löschen von mehreren E-Mail-Adressen auf der Person auf.

Die neue ExecutePropertyChangedActions-Methode für Personen setzt die Felder Anrede und Briefanrede automatisch, wann immer das Geschlecht geändert wird. Dieses Verhalten tritt nicht nur im UI auf, sondern auch beim Setzen der Props im Code.
Aus diesem Grund muss sichergestellt werden, dass in jeglicher Business Logik (!) immer zuerst das Feld Geschlecht gesetzt wird und erst dann die Felder Anrede und Briefanrede (da diese sonst wieder überschrieben werden).

Die neue ExecutePropertyChangedActions-Methode für Durchführungen setzt die Felder EndDatum und EndZeit automatisch, wann immer StartDatum und StartZeit geändert werden. Dieses Verhalten tritt nicht nur im UI auf, sondern auch beim Setzen der Props im Code.
Aus diesem Grund muss sichergestellt werden, dass in jeglicher Business Logik (!) immer zuerst die Felder StartDatum und StartZeit gesetzt werden und erst dann die Felder EndDatum und EndZeit (da diese sonst wieder überschrieben werden).

Die Newsletter-Mitgliedschaft ist ein DlMasterData-Objekt. Der Workflow für Mitgliedschaftsregistrationen muss auf dem Objekt geg. durch einen kundenspezifischen Workflow ersetzt werden.
Der Newsletter-Registrationen-Link listet nur Registrationen mit einem RegistrationOk-Status auf, d.h. es muss im verwendeten Mitgliedschaftsregistrations-Workflow mindestens ein Workflow-State mit dem Keyword "RegistrationOk" existieren.