Release-Notes Versionen 26.5.x

Allgemeine Funktionen

Auslieferung einer DS-GVO-Konfiguration der Leads

Damit die Leads DSGVO-konform gelöscht werden können, muss eine entsprechende Verarbeitungstätigkeit vorhanden sein. Im Standard wird jetzt eine Konfiguration ausgeliefert. Diese löscht alle Leads, die älter als 10 Jahre sind. Voraussetzung hierfür ist, dass der DSGVO-Timer aktiv ist und die Kategorie im Feld DS-GVO-Kategorie (GdprCatKey.Lead) hinterlegt ist. Für alle neu angelegten Leads erfolgt dies automatisch über das Setzen des Standardwerts “C0Cat-0001” im Feld mittels Feldeigenschaften.

Verknüpfung von Aktivitäten zu Datensätzen mit eindeutiger ID anhand des Betreffs

Bisher existierte im CRM keine Funktionalität im Standard, die den Betreff importierter E-Mails, die als Aktivitäten angelegt werden, auf die Projektnummer prüfte und bei vorhandenem Projekt mit dieser Nummer verknüpfte (analog zu den Verknüpfungen von Aktivitäten anhand der Vorgangsnummern).

Es wurden jetzt neue Felder auf Verträge, Messeinrichtung, Vertragskonten und Abschlussobjekten mit Patterns angelegt. Der Prozess C0LinkEntityToMail verknüpft nun die importierte Mail mit diesen Datensätzen basierend auf einem Matching von Nummern im Betreff (für Übersteuerung wie z.B. Aufnahme weiterer Entitäten in C2 sind die Methoden in SC0EntityLogic zu übersteuern).

Im Prozess C0TicketLinkActivitywurde das Startereignis für C0 auf false gesetzt.

EVI & TINA

Kachel "Testläufe" wurde auf die V2-Technologie migriert

Die Kachel wurde auf die V2-Technologie migriert und optisch verbessert.

Globale Variablen für die Schleupen-Credentials

• User zur Anmeldung am Webservice: globale Variable: C12SchleupenWebserviceUserName

  • Diese Variable entfällt. Sie muss über den Prozess “Schleupen: Credentials initialisieren“ in myEVI gefüllt werden.

• Passwort zur Anmeldung am Webservice: globale Variable: C12SchleupenWebserviceUserPassword

  • Diese Variable entfällt. Sie muss über den Prozess “Schleupen: Credentials initialisieren“ in myEVI gefüllt werden.

Details im Kapitel:

→ EVI-Schleupen Auslösen von Änderungsvorgängen EVI2Schleupen | Webservice

Prozessbegleitende Prüfung im Rahmen des Angebotserstellungsprozesses für Privatkunden

Im Rahmen des Angebotserstellungsprozesses für Privatkunden wurde eine neue, prozessbegleitende Prüfung integriert. Sobald eine manuelle Netzbetreiberauswahl getroffen und der Prozess fortgeführt wird, erfolgt im Hintergrund ein automatischer Datenabgleich zwischen den zuvor erfassten Lieferstellendaten und den für das ausgewählte Netzgebiet aktiven Tarifen.

Sollte für den gewählten Netzbetreiber kein passender Tarif zur Verfügung stehen, verbleibt die Benutzeroberfläche auf dem aktuellen Schritt, und ein modales Hinweisfenster informiert den Anwender frühzeitig über die fehlende Versorgungsmöglichkeit. Dem Sachbearbeiter stehen in diesem Pop-Up zwei Optionen zur Verfügung:

• Prozess abbrechen: Der Angebotsprozess wird direkt und ohne Speicherung eines unvollständigen Angebots beendet.

• Zurück zu Lieferstelle abfragen: Der Anwender wird zum vorherigen Schritt zurückgeführt, um die Adress- oder Lieferstellendaten direkt zu korrigieren.

Durch diese frühzeitige Validierung wird verhindert, dass Sachbearbeiter den gesamten Prozess durchlaufen, nur um am Ende festzustellen, dass kein Angebot generiert werden kann.

Verbessert

• Prozess-Effizienz: Die Prüfung auf Tarifverfügbarkeit wurde im Prozessablauf nach vorne verlagert. Anwender erhalten nun unmittelbar nach der Netzbetreiberauswahl Rückmeldung, anstatt erst im nachgelagerten Schritt der Tarifauswahl.

• Benutzerführung: Die Einführung des modalen Dialogs bietet klare, handlungsorientierte Entscheidungswege (Abbruch oder gezielte Korrektur), was die Benutzerfreundlichkeit des Angebotsprozesses steigert.

"Angebot online annehmen" wurde entfernt

Die Prozesse C12SLPAngebotOnlineAnnehmen und C12SLPAngebotOnlineAnnehmenErgebnis wurden entfernt.

Erweiterung des Loggings bei EVI2Schleupen-Prozessen

Beim Testen der Schleupen-Schnittstelle konnte man die übergebenen Daten nur über die Logs einsehen.

Daher wurden die EVI2Schleupen-Prozesse so erweitert, dass der Request an Schleupen in einem Schnittstellen-Details-Datensatz im Feld “Technische Information” (TechInfo.InterfaceDetail) abgespeichert wird (unabhängig vom Loglevel). Dabei wird der Request in einem lesbaren Format (pretty print JSON) abgespeichert. Dieser Schnittstellen-Details-Datensatz wird nun mit dem zugehörigen Eventresult verknüpft.

Damit wird eine Nachvollziehbarkeit geschaffen. Beispiel: Vom Geschäftspartner kann man das Event (C12EVENT) einsehen, welches fachlich die Übertragung an Schleupen (z.B. Bankverbindungsänderung) darstellt. In dem damit verknüpften Ergebnis des Events (C12EVENTRES) kann man sehen, ob die Übertragung erfolgreich war. Das JSON des Aufrufs kann dann im damit verknüpften Schnittstellen-Detail-Datensatz eingesehen werden.

Administration

Nicht benötigte mandantenfähige Entitäten

Mit der neuen Methode UnitUtils.setClientNo() in der Skript-Bibliothek können Administratoren und Consultants die Mandantennummer (ClientNo) auf Datensätzen gezielt auf bestimmte oder alle Mandanten setzen. Dies ermöglicht es, mandantenfähige Entitäten, die mandantenübergreifend genutzt werden sollen, direkt über BPM-Prozesse korrekt zu konfigurieren – ohne den bisherigen Umweg über nachträgliche SQL-Änderungen.

Die Methode setzt die übergebenen Mandanten auf dem Eintrag, ohne diesen automatisch zu speichern, und steht mit folgender Signatur zur Verfügung:

IContainer UnitUtils.setClientNo(IContainer entry, List<IUnit> | IUnit... units)

Wichtige Hinweise:

• Es gelten dieselben Einschränkungen wie bei UnitUtils.setUnits().

• Der ausführende Mitarbeiter kann nur Mandanten zuweisen, denen er im Unterbereich zugeordnet ist. Die Mandanten-Berechtigung über die Toolbar und die Zuordnung im Unterbereich müssen identisch konfiguriert sein.

• Werden Mandanten zugewiesen, für die der Mitarbeiter nicht berechtigt ist, erfolgt keine Zuweisung – ohne Fehlermeldung (analog zu UnitUtils.setUnit).

Details finden Sie im im Kapitel:

→ setClientNo

Löschung von Dokumenten nach Testlauf in der Skriptbibliothek

Wurden im Rahmen eines Testfalls Dokumente erstellt, so blieben diese im DocumentRoot erhalten, auch wenn diese mit ScriptTestUtils.addTestEntry(<Pk>, "Document") explizit aufgenommen wurden.

Mit dem Start der Methode testDeleteDokument in der Skriptbibliothek SCTestDocumentGeneration werden zuerst Pfade ermittelt und die physischen Dokumente aus dem DocumentRoot gelöscht.

Details finden Sie im Kapitel: → Skript-Bibliothek | Testklasse-hinterlegen

Vergangene Termin- und Besprechungsaktivitäten werden automatisch auf "Erledigt" gesetzt

Vergangene Termine und Besprechungen werden über einen Timer automatisch auf “Erledigt” gesetzt. Der Timer (C0SetPastActivitiesDone) ist im Standard aktiv und läuft 1x täglich um 22 Uhr.

Dabei werden alle Termine selektiert, die in den letzten 48 Stunden stattgefunden haben (Ende-Datum). Möchten Kunden einen anderen Zeitraum wählen, so soll eine Übersteuerung dieser Selektion vorgenommen werden.

Mehrere Dokumente mit einem Klick aus dem Web Client öffnen

Bisher konnten im Web Client mehrere Dokumente ausgewählt und anschließend über die Mehrfachbearbeitung heruntergeladen werden. In einer Zip-Datei waren die Dokumente enthalten.

Jetzt können mehrere Dokumente ausgewählt und im Lesemodus geöffnet oder bearbeitet werden.

Diese Option ist sowohl im Unterbereich als auch in der Listenansicht verfügbar.

Standardmäßige Aktivierung der Löschregeln für Zeitereignisse und Schnittstellen-Details

Der bestehende automatische Löschprozess für Zeitereignisse und Schnittstellen-Details wurde standarmäßig in der C0-Schicht aktiviert, das Datenvolumen ausreichend zu verringern.

Schreibschutz für Email-Benutzer bei Nutzung des Kerberos Logins

Das Feld “GroupwareLogin.Employee” (Groupware-Benutzer) war bisher im Kerncode schreibgeschützt. Dies verhinderte die Anpassung des Login-Namens, z.B. im Falle einer Namensänderung. Daher wurde der Schreibschutz entfernt.

Infoboards

Kachel “Meine Lead-Nachverfolgungen” zum Management von Leads

Um das Lead-Management für Vertriebsmitarbeiter zu vereinfachen, kann eine Standard-Kachelvariante “Meine Lead-Nachverfolgungen” mit einem Klick auf das aktuelle Board übernommen werden. Die Kachel stellt eine Kachelvariante der Scores-Kachel dar.

Die Kachel-Daten werden über folgende Kanäle geliefert:

• Meine offenen Leads

• Meine überfälligen Leads

• Meine fälligen Leads der nächsten 14 Tage

Hierfür stehen entsprechende Standard-Suchen zur Verfügung.

Benachrichtigungslogik in der Kachel “Kommentare und Aktivitäten”

Die Benachrichtigungslogik im Prozess C0IB_NotifyUserOfComment wurde im Standard so angepasst, dass eine Benachrichtigung nur für jeden erwähnten Mitarbeiter anstelle einer Benachrichtigung für alle Mitarbeiter generiert wird.

BPM im Web

Möglichkeiten zum Eingreifen bei Änderung von abhängigen Telecom- und Address-Datensätzen

Werden Adress- oder Kommunikationsdatensätze beim Geschäftspartner geändert, werden diese Änderung per interner Logik auf den Ansprechpartner übertragen. Da dies intern und nicht über BPM-Prozesse o.ä. erfolgt, war keine Reaktion auf diese Änderung bei den zum Ansprechpartner gehörigen Telekommunikations- bzw. Adressdatensätze möglich.

Nun ist es mithilfe eines neuen Start-Events in BPM möglich, auf die Änderung abhängigen Telekommunikations- und Adressdatensätze zu reagieren. Details finden Sie im Kapitel

→ Speichern | Speichern-der-Kommunikation-einer-Rolle-(nachher)

Vorschau

Gleichzeitige Veröffentlichung von mehreren (Teil-)Prozessen

Die Veröffentlichung und Deaktivierung von Prozessen kann direkt aus dem Dashboard heraus vorgenommen werden. Dabei ist auch eine Mehrfachauswahl möglich: Mehrere Prozesse können markiert und anschließend gemeinsam über den entsprechenden Button veröffentlicht oder deaktiviert werden. Dabei werden Teilprozesse automatisch vor den Hauptprozessen veröffentlicht, da ein Teilprozess immer bereits veröffentlicht sein muss, bevor ein Hauptprozess veröffentlicht werden kann, der diesen Teilprozess verwendet.

Greifen jedoch Teilprozesse untereinander aufeinander zu (z. B. Teilprozess A verwendet Teilprozess B, und Teilprozess B verwendet Teilprozess C), kann die automatische Veröffentlichung fehlschlagen.

Jetzt wird die Fehler-Ausgabe mit maschinell verständlichen Fehlern angereichert, so dass dann die Fehlerursache identifiziert werden kann. Nach der Veröffentlichung der Teilprozesse, sollen diese noch einmal gestartet, wenn sie in der Liste der geglückten Teilprozesse vorkommen. Erst dann werden die Hauptprozesse veröffentlicht.

Erweiterungen

KI-Modell

Fehlende Variablen für die KI erkennbar machen (Dummy-Werte für Platzhalter)

Im KI-Assistenten (Prompt-Editor) können leere Platzhalter (z. B. wenn keine CRM-Daten gefunden wurden) nun durch einen definierten Ersatzwert (NO_VALUE_FOUND) ersetzt werden. Dadurch wird sichergestellt, dass die KI erkennt, wenn Daten fehlen, anstatt fehlerhafte Annahmen aufgrund von Leerstrings zu treffen.

In der Prompt-Bibliothek gibt es hierfür die neue Option "Fehlende Werte ignorieren", die standardmäßig aktiviert ist. Zudem können individuelle Ersatzwerte oder Leerstrings durch eine spezielle Ausrufezeichen-Syntax definiert werden (z. B. ${custom.Beispiel!} oder ${custom.Beispiel!"WERT"}).

Hinweis zu BPM-Methoden: Auch in den BPM-Prozessen wurden Anpassungen vorgenommen, um fehlende Variablen zu behandeln (createPrompt) und Prompts auszulesen (getPromptContent). Details hierzu finden Sie in der entsprechenden Dokumentation (siehe unten).

Verbessert

Die Parameter-Reihenfolge in der BPM-Methode executeCustomPrompt wurde für eine bessere Handhabung optimiert.

Behoben

Das Problem, dass die KI durch unvollständige Prompts (aufgrund leerer Variablen) ungenaue oder sinnlose Antworten lieferte, wurde durch die Einführung des definierten Dummy-Wertes behoben.

Weiterführende Links zu aktualisierten und neuen BPM-Methoden

• createPrompt (Neuer Parameter replaceNullWithDefault)

• executePrompt (Wechsel Reihenfolge der Parameter userPrompt und systemPrompt)

• executeCustomPrompt (Wechsel Reihenfolge der Parameter userPrompt und systemPrompt))

• getPromptContent (Neue Methode)

KI-Preview: Darstellung des Prompt-Ausführungsbereichs

Die Benutzeroberfläche der KI-Vorschau wurde um eine transparente Darstellung des Ausführungsbereichs erweitert, um eine intuitive Zuordnung des Primärschlüssels (PK) zu ermöglichen. Anwender sehen nun im ersten Prozessschritt direkt, für welchen spezifischen Bereich der PK hinterlegt werden soll oder aus welchem Bereich er stammt.

Darüber hinaus wurde eine automatisierte Prüfung integriert. Beim Einfügen des PKs oder beim Klicken auf „Weiter“ prüft das System im Hintergrund, ob der angegebene PK dem ausgewählten Bereich entspricht (gefunden wird) und ob der zugehörige Datensatz aktiv ist. Inaktive Datensätze oder ungültige Schlüssel werden sofort erkannt und abgefangen, um Fehlern bei der nachgelagerten Prompt-Ausführung vorzubeugen.

Optimierte Validierungsprozesse

Die Validierungsprozesse innerhalb der Eingabeverwaltung und der Prompt-Bibliothek wurden grundlegend optimiert, um Fehleingaben bereits vorab zu verhindern.

Validierung in der Eingabeverwaltung

Beim Öffnen der Vorschau erfolgt eine automatische Prüfung, ob User-Prompt und System-Prompt kompatibel sind. Sollten Inkompatibilitäten vorliegen, werden die Eingabefelder für den PK und die Bereichsauswahl automatisch deaktiviert (disabled). Eine erfolgreiche Konfiguration führt zu folgenden Optimierungen:

• Im Bereichsfilter stehen ausschließlich gemeinsame Bereiche zur Auswahl.

• Existiert nur ein gemeinsamer Bereich, wird dieser automatisch vorausgewählt und das Auswahlfeld deaktiviert, um unnötige Klicks zu sparen.

Validierung in der Prompt-Bibliothek

Da Prompts in der Bibliothek für sich allein stehend immer als valide betrachtet werden, entfällt hier die Vorabvalidierung beim Öffnen der Vorschau. Die Prüfung auf Existenz, Aktivitätsstatus und Einhaltung der Filterregeln des Datensatzes erfolgt hier dynamisch direkt bei der Eingabe des PKs.

Umfragen

Benachrichtigung zuständiger Mitarbeiter, wenn ein Ansprechpartner eine Umfrage abgeschlossen hat

Wenn die Antwort einer Umfrage eines Ansprechpartners eingeht, erfolgt jetzt eine Benachrichtigung an relevante CRM-Anwender (als Einzelbenachrichtigung).

Diese Information wird aus dem zum Ansprechpartner gehörenden Geschäftspartner ausgelesen. Ob eine Benachrichtigung erfolgt, kann über eine CN-Anwendungsvariable C0Survey_Notification vom Typ “Liste” konfiguriert werden. In der Liste wird der technische Feldname festgehalten, in dem der Mitarbeiter steht, der die Benachrichtigung erhalten soll. Im Standard wird die Variable mit dem Listeneintrag “EmployeeOffice.Customer” ausgeliefert.

Kunde können dies in ihren Systemen um weitere Mitarbeiter-Felder erweitern.

Test-Studio

-

Scripting

Schreiben binärer Dateien mithilfe einer neuen Methode FileUtils.writeBinaryFile

Die Methode FileUtils.writeFile konnte textbasierte Dateien verarbeiten, allerdings keine binären Dateien. Dies führte dazu, dass PDF-Dateien fehlerhaft im Dateiverzeichnis des Applikationsservers abgelegt wurden. Daher wurde nun eine neue Methode FileUtils.writeBinaryFile geschaffen, mithilfe derer auch andere Dateitypen richtig abgelegt werden können.

In diesem Rahmen wurde auch im Prozess C12EASY_OpenDocument die Aufrufstelle für die Weiterverarbeitung des Base64 codierten Rückgabewerts entsprechend angepasst.

CURSOR-App