Release-Notes Versionen 25.6.x

Allgemeine Funktionen

Lead-Neuanlage mit automatischer Aktivitätenanlage

Ein neuer Lead wird über den Neuanlage-Button angelegt. Die Anlage ist im Standard nicht durch Aktionsrechte eingeschränkt. Während der Lead-Neuanlage wird auch eine Aktivität generiert und mit einigen Lead-Feldern ausgefüllt.

Wird ein Wert in den Feldern „Termin von (geplant)“ und „Termin bis (geplant)“ sowie „Termin mit“ eingetragen, wird beim Speichern automatisch eine Aktivität von Typ „Termin“ für den verknüpften Mitarbeiter angelegt. Dabei werden die Informationen aus dem Lead in die Aktivität übernommen ("Notizen" und - falls gefüllt "Kontakt" und "Unternehmen"). Ist ein Geschäfts- bzw. Ansprechpartner im Lead hinterlegt, wird dieser in der Aktivität verknüpft („Aktivität mit“). Bei aktivierter Groupware-Integration wird der Termin damit automatisch in den Kalender des jeweiligen Mitarbeiters übernommen.

Zusätzlich gibt es ein Nachschlagefeld auf der Aktivität zur Verknüpfung des Leads (DefaultLead.Activity) mit doppelt persistenter Relation.

Wird der Termin oder die durchführende Person geändert, wird die Aktivität aktualisiert - außer der Termin kann nicht eindeutig identifiziert werden, dann wird eine Meldung ausgegeben.

Anpassung des Verhaltens von Tabellen

Die Zeilenselektoren ✅ erfüllen die gleiche Funktion wie die Markierung einer Zeile über STRG+<Klick>. Aus UX-Gründen (Verständlichkeit und Einfachheit) werden diese aber weiterhin dargestellt. Das Verhalten von Tabellen bei eingeblendeten und ausgeblendeten Zeilenselektoren wurde weitestgehend angepasst.

Ohne Inline-Listenbearbeitung

Shortcuts bei selektierter Zeile

Mit Inline-Listenbearbeitung

Shortcuts bei selektierter Zeile

Taste	Aktion
ALT+O	öffnet die selektierten Datensätze in einer neuen Ebene als Liste, wobei der erste Datensatz in der Detailansicht angezeigt wird
ALT+R	setzt die selektierten Datensätze auf "Erledigt" (nur bei Aktivitäten möglich)
ALT+ENTF	löscht die selektierten Datensätze Verhaltensänderung!
ALT+Q	bearbeitet die selektierten Datensätze (Mehrfachbearbeitung)
ALT+M	öffnet das Zeilenmenü

Standardwert für Aktivitäts-Priorität

Bei der Neuanlage einer Aktivität war bisher der Standardwert für die Priorität "A, Heute" was in dem Maildialog einer Wichtigkeit von Hoch entspricht.

Der Standardwert für die Priorität bei einer Neuanlage einer Aktivität wurde jetzt auf "B, In den nächsten 3 Tagen" geändert, was in dem Maildialog einer Wichtigkeit von Normal entspricht.

Nachträgliche Änderung der Anzahl einer Angebotsposition

Wenn es eine nachträgliche Änderung an einer Angebotsposition gab, welche Unterpositionen mit einer relativen Anzahl hatte, wurde diese Änderung bei den betroffenen Unterpositionen nicht nachgezogen. Hintergrund war, dass die Unterpositionen nach dem initialen Hinzufügen keine Information mehr hatten, in welcher Anzahl sie relativ abhängig von der Hauptposition sind.

Jetzt ist automatisch eine nachträgliche Veränderung der Anzahl bei relativen Unterpositionen möglich, da die relative Eigenschaft von Unterprodukten in Angebotspositionen beim Einfügen gespeichert wird. Zum Zeitpunkt des Einfügens der Unterposition wird der Initialwert der relativen Anzahl aus der Stückliste in der Angebotsposition festgehalten, um diesen Wert bei nachträglichen Änderungen nutzen zu können. Ändert man zu einem späteren Zeitpunkt die Anzahl der Hauptposition, wird die Anzahl der Unterposition automatisch immer mitgeändert.

Dabei bezieht sie sich immer auf den Wert, der beim Einfügen der Angebotsposition in der Stückliste hinterlegt war. Hat sich die Stückliste bzw. relative Anzahl im Produktstamm in der Zwischenzeit geändert, hat dies keine Auswirkungen auf bereit eingefügte Angebotspositionen.

Einbindung eines neuen HTML-Editors

Der bisherige Editor war aufgrund der Integration nur beschränkt anpassbar, was das Fixen von Bugs erschwerte.

Aus diesem Grund wurde ein neuer moderner, benutzerfreundlicher HTML-Editor in das CRM-System eingebaut.

Features des neuen Editors:

• Texte sind unter verschiedenen Formatierungen einzugeben (fett, kursiv, unterstrichen, durchgestrichen)

• Schriftarten können zwischen Arial, Times New Roman, Courier New und Verdana gewechselt werden

• Schriftgrößen sind von 8pt bis 36pt frei wählbar- Textausrichtung kann zwischen linksbündig, zentriert, rechtsbündig und Blocksatz umgestellt werden

• Fehlerhafte Eingaben können über Rückgängig-Funktion korrigiert werden (bis zu 10 Schritte)

• Formatierte Inhalte aus Word-Dokumenten werden korrekt dargestellt

• Formatierte Inhalte aus Word-Dokumenten können direkt eingefügt werden und werden an den korrekten Stellen platziert

• Formatierte Inhalte aus Excel-Dokumenten werden korrekt dargestellt

• Formatierte Inhalte aus Excel-Dokumenten können direkt eingefügt werden und werden an den korrekten Stellen platziert

• Formatierte Inhalte aus Outlook-Elementen werden korrekt dargestellt

• Formatierte Inhalte aus Outlook-Elementen können direkt eingefügt werden und werden an den korrekten Stellen platziert 

• Aufzählungslisten mit Bullet-Points können erstellt und verschachtelt werden

• Nummerierte Listen werden automatisch fortgeführt und können ebenfalls verschachtelt werden

• Textabschnitte und Listen können über Tab-Taste eingerückt und strukturiert werden

• Bestehende Aufzählungslisten können in nummerierte Listen umgewandelt werden

• Mehrere Einrückungsebenen ermöglichen hierarchische Gliederungen

• Externe Webseiten können über Hyperlinks verknüpft werden

• URL's werden automatisch auf Gültigkeit geprüft und bei Bedarf korrigiert 

• Bildgrößen können proportional angepasst werden 

• Bei versch. Systemsprachen passen sich die UI-Elemente entsprechend an (z.B: Tooltips) 

• Berücksichtigung gängiger Zeichenkonversionen (um bspw. einen Pfeil → zu bilden) 

Shortcut für die Aktualisierung eines Datensatzes

Zur Optimierung der Bedienung wurde neben dem bestehenden Aktualisierung-Button ein Tastaturkürzel eingeführt.
Über de Taste F9 können Datensätze im CRM-System direkt aktualisiert werden, ohne die Maus verwenden zu müssen. Die Wahl von F9 orientiert sich an Outlook und vermeidet Konflikte mit gängigen Browser-Shortcuts.

SSO-Felder beim Mitarbeiterabgleich

Die Login-Informationen bei SSO wurden bisher nicht beim Mitarbeiterabgleich transportiert.

Diese SSO-Felder wurden jetzt in der Suche C0EMPLOYEES_TO_MERGE hinzugefügt.

Betreffende Felder:

• Email.Employee

• SAMLLoginName.Employee

• OIDCLoginName.Employee

Nach einem Mitarbeiterabgleich werden oben genannte Felder, sofern gefüllt, mit transportiert.

EVI & TINA

Netzverträglichkeitsprüfung

Im Zuge einiger Meldungen im Netzanschluss muss eine Netzverträglichkeitsprüfung (NVP) durchgeführt werden. Eine Netzverträglichkeitsprüfung (NVP) wird immer in Form eines Vorgangs abgebildet. Ein Sacharbeiter kann die Prüfung über die Aktionsbox manuell starten und abschließen.

Die Netzverträglichkeitsprüfung ist erforderlich und muss BEENDET sein, damit das Projekt übergeben werden kann.

Details finden Sie im Kapitel → Netzverträglichkeitsprüfung

Prüfung der Leistungsdaten zum Anschluss

Eingehende Leistungsdaten aus dem Kundenportal werden in TINA als Vorgänge abgebildet und können dort auf Plausibilität geprüft werden.

Leistungsänderung der verbleibenden Gesamtleistung

Wird eine Leistungsänderung vorgenommen kann die verbleibende Gesamtleistung angesehen werden. Werden bestimmte Kriterien erfüllt, wird der Vorgang freigegeben.

Für die Anzeige musste die Entität CapacityChange um ein Feld erweitert werden.

Wird ein Datensatz Leistungsänderung (CapacityChange) angelegt, wird folgende Berechnung ausgeführt:

• TotalPower.Supply (über Anschluss am Anschlussobjekt, über Anschlussobjekt am Projekt) - TotalPowRemoved.CapacityChange

• Ergebnis speichern in NewTotalPower.CapacityChange

Wurde die Gesamtleistung berechnet, findet eine Palusibilitätsprüfung statt:

• Neue Gesamtleistung (NewTotalPower.CapacityChange) <= 30 kW und Materialnummer (ISU_MatNr.MeasuringDevice) an der Messeinrichtung beginnt mit DA10 oder

• Neue Gesamtleistung (NewTotalPower.CapacityChange) <= 40 kW und Wandlermessung (IsTransMeter.CapacityChange) = true

Ist die Prüfung erfolgreich, wird jeweils Projektstatus (Projectno.Project) auf 98 (C0S_PRJSTA_98) gesetzt.

Prüfung der Leistungsänderung bei Leistungsreduktion bzw. Geräteabmeldung

 Startpunkt für die Prüfung:

• Neuanlage bzw. Speichern des Projektes (Projektart Leistungsänderung) / der Leistungsänderung

• Anschlussobjekt ist am Projekt verknüpft

Wenn es sich um eine Leistungsänderung für einen Stromzähler handelt, wird geprüft, ob "IsTransMeter.CapacityChange" = false und "MaxNominalPower.CapacityChange" < 30 kW. Wenn ja, kann die Meldung automatisch freigegeben werden. Der Projektstatus wird auf 98 - Freigegeben gesetzt. 

Prüfung der Leistungsänderung bei Leistungserhöhung durch Gerätenachmeldung

 Startpunkt für die Prüfung:

• Neuanlage bzw. Speichern des Projektes (Projektart Gerätemeldung) / der Gerätemeldung

• Anschlussobjekt ist am Projekt verknüpft

Wenn es sich um eine Geräteanmeldung mit Meldungsart = "Nachmeldung §14a" (REG_TYPE-Nachmeldung) handelt, wird für jedes gemeldete Gerät (=Energieverbraucher an der Gerätemeldung) folgendes geprüft:

• Es existiert eine Messeinrichtung mit Zählernummer aus Energieverbraucher aus Gerätemeldung (MeterNo.EnergyConsumer). Verknüpfung über Anschlussobjekt am Projekt, Anlage an Anschlussobjekt und Messeinrichtung an Anlage

• es existiert bereits eine Gerätemeldung mit Meldungsart = "Anmeldung" (REG_TYPE-Anmeldung) am Anschlussobjekt für dieselbe Verbrauchertyp (ConsumerTypeKey.EnergyConsumer) und Leistung (DevicePower.EnergyConsumer)

  • wenn die Prüfung für alle Geräte erfolgreich war, kann die Meldung automatisch freigegeben werden: Der Projektstatus wird auf 98 - Freigegeben (neuer Schlüssel) gesetzt.

Prüfung der Leistungsänderung bei Leistungserhöhung

Startpunkt für die Prüfung:

• Neuanlage bzw. Speichern des Projektes (Projektart Leistungsänderung) / der Leistungsänderung

• Anschlussobjekt ist am Projekt verknüpft

Wenn es sich um eine Leistungsänderung für einen Stromzähler handelt, wird Folgendes geprüft (Anschlussobjekt → Anschluss):

• wenn "MaxNominalPower.CapacityChange" <= ConnectTypeKey.Supply 

  • Prüfung erfolgreich

  • wenn nicht, wird das Projekt in Korrektur gesetzt. Projektstatus = 30 (ohtnk61hgveu15kKeytabNum)

Prüfung der Leistungswerte über den Hausanschlusskasten

 Startpunkt für die Prüfung:

• Neuanlage bzw. Speichern des Projektes (Projektart Hausanschluss) / des Datensatzes Hausanschluss

• Anschlussobjekt ist am Projekt verknüpft

Wenn es sich um eine Meldung Hausanschluss handelt, werden folgende Prüfungen durchgeführt:

• wenn ConnectionTypeKey.HouseConnection = CONNECT_TYPE-Gbk (Gusskasten):

  • es darf nur 1 anmeldepflichtiges Gerät gemeldet werden

    • es existiert ein Hauptprojekt am Projekt (Startpunkt), wo ein weiteres Projekt mit Projektart Gerätemeldung verküpft ist

      • hier darf nur 1 Energieverbraucher (Anzahl Geräte = 1) gemeldet sein

  • TotalPower.HouseConnection < 40kW

  • wenn ConnectionTypeKey.HouseConnection = CONNECT_TYPE-Kg1 (Größe 1):

    • TotalPower.HouseConnection < 50kW

  • wenn ConnectionTypeKey.HouseConnection = CONNECT_TYPE-Kg2 (Größe 2):

    • TotalPower.HouseConnection < 100kW

    • wenn mind. 1 anmeldepflichtiges Gerärt vorhanden (Anschlussobjekt hat Energieverbraucher) oder gemeldet (es existiert eine Gerätemeldung mit mind. 1 Energieverbraucher), dann TotalPower.HouseConnection < 86kW

  • wenn ConnectionTypeKey.HouseConnection = CONNECT_TYPE-Kg3 (Größe 3):

    • TotalPower.HouseConnection < 180kW

• ist die Prüfung nicht erfolgreich, wird das Projekt in Korrektur gesetzt. Projektstatus = 30 (ohtnk61hgveu15kKeytabNum)

• Sonderfall: 

  • wurde ein Gewerbe (BuUnitCount.Location > 0) oder mehr als 4 Wohneinheiten (HouseUnitCount.Location > 4) gemeldet, muss die detaillierte Leistungsaufstellung vom Sachbearbeiter geprüft werden.

    • Es wird ein Vorgang angelegt:

      Subject.TicketPrüfung detaillierte LeistungsaufstellungTicketType.TicketPRLEISTAUFTicketStatus.TicketOFFENDescription.TicketBitte das angehängte Dokument zur Leistungsaufstellung kontrollieren und das Ergebnis bei Vorgangsabschluss festhalten. Ist die Leistungsaufstellung nicht korrekt, bitte das zugehörige Projekt in Korrektur setzen (Status: 30).PriorityKey.TicketBDelegatedFrom.TicketAnlageuserDelegatedGrpKey.TicketPLAUSIDueDate.TicketNOW + 5 WerktageRemindDate.TicketNOW + 2 Werktage

    • Vorgang wird verknüpft mit

      • Projekt

      • Geschäftspartner, der am Projekt in der Rolle "Anschlussnehmer" verknüpft ist

      • Standard-Ansprechpartner dieses Geschäftspartners

      • Dokument mit Kategorie "Leistungsaufstellung" (LEISTUNGSAUF)

Details finden Sie im Handbuch → Eingehende Leistungsänderungen prüfen

Automatische Plausibilisierungen bei Neuanlage von Meldungen in TINA

Bei der Neuanlage von Meldungen in TINA, sowohl über das Portal als auch manuell, finden automatisch Prüfungen statt. Wenn die Prüfungen fehlschlagen, wird ein Vorgang erzeugt.

Startpunkt der Prüfungen

 Die Prüfungen starten bei Neuanlage oder Speichern der folgenden Entitäten:

• Gerätemeldung

• Hausanschluss

• Leistungsänderung

• Zählertausch

• Bauanschluss

• Messkonzeptwechsel

• Plombierung

• Zählerausbau

• Im Folgenden werden diese Entitäten nur noch als "Meldung(en)" bezeichnet

Prüfung Wärmepumpe

Es wird geprüft, ob über den folgenden Weg ein Anschlussobjekt mit "Wohneinheit" == 1 gefunden wird

• Meldung hat Projekt, Projekt hat Anschlussobjekt

• wenn ja wird folgendes geprüft:

  • Meldung hat Projekt (direkte Verknüpfung), Projekt hat Gerätemeldung, Gerätemeldung hat Geräte mit Geräteart (DeviceType.Device) == WÄRMEPUMPE und Leistung (DevicePower.Device) >= 10

  • oder Meldung hat Projekt, Projekt hat Projekt mit Beziehung Hauptprojekt, (Haupt-)Projekt hat Projekt mit Beziehung Teilprojekt, (Teil-)Projekt hat Gerätemeldung, Gerätemeldung hat Geräte mit Geräteart (DeviceType.Device) == WÄRMEPUMPE und Leistung (DevicePower.Device) >= 10

• wird mindestens ein Datensatz gefunden, gilt die Prüfung als fehlgeschlagen

Kundenkommentar bei der Anmeldung eines Hausanschlusses

Bei der Anmeldung eines Hausanschlusses kann optional ein Kundenkommentar über das Attribut "activity" am Projekt mitgegeben werden. Dieser wird an das erzeugte Projekt verknüpft.

Dies gilt für folgende Services

• createCapacityChange

• createContstructionSupply

• createDeviceRegistration

• createHouseConnection

• createMeterExchange

• createMeterRemoval

• createSealing

Entität Produkte (Product)

Der Bereich Produkte (Product) wurde im Standard um ein Feld erweitert:

• Anzeigename DE: Externe Referenznummer

• Anzeigename EN: External reference number

• Interner Name: ExtRefNo.Product

• Datentyp: String(100)

Entität Hausanschluss (HouseConnection)

Der Bereich Hausanschluss (HouseConnection) wurde im Standard um ein Feld erweitert:

• Anzeigename DE: Beschreibung Energieträger Heizung

• Anzeigename EN: Medium heating description

• Interner Name: HeatMediumDesc.HouseConnection

• Datentyp: String(255)

• Kein Schreibschutz

Das Feld hängt am TINA-Modul.

Hintergrund: Im Hausanschluss-Prozess für TINA muss es möglich sein, einen Energieträger für die Heizung näher beschreiben zu können, wenn es sich um eine nicht-elektrische Heizung handelt.

Abbildung von Dienstbarkeiten

Während des Hausanschluss-Prozesses kann die Notwendigkeit einer Dienstbarkeit entstehen. Der Sachbearbeiter möchte eine beschränkt persönliche Dienstbarkeit des Grundstückseigentümers vorbereiten, wenn dessen Grundstück für die Herstellung der erforderlichen Strom-, Wasser oder Gasleitungen benötigt, aber sein Grundstück selbst nicht angeschlossen werden soll.

Eine Dienstbarkeit ist ein beschränktes dingliches Nutzungsrecht an einer fremden Sache, meist einem Grundstück. Der Eigentümer des belasteten Grundstücks muss dabei bestimmte Handlungen dulden oder unterlassen, während der Berechtigte das Recht hat, das Grundstück in einem bestimmten Umfang zu nutzen. Dienstbarkeiten werden durch Einigung und Eintragung ins Grundbuch begründet und sind im Grundbuch vermerkt. Sie sind dingliche Rechte, was bedeutet, dass sie unabhängig vom jeweiligen Eigentümer bestehen und auch bei einem Verkauf des Grundstücks weiterhin gültig bleiben, bis sie gelöscht werden.

Dienstbarkeiten werden über Prozesse gesteuert, die über die Aktionsbox von einem Projekt ausgelöst werden können.

In der Entität "Dienstbarkeiten" (Easement) werden dagegen alle für die Erstellung der Dienstbarkeit wichtigen Informationen hinterlegt.

Details finden Sie in Kapiteln:

→ Entität Dienstbarkeiten (Easement)

→ Abbildung von Dienstbarkeiten

→ Abbildung von Dienstbarkeiten (Administration)

Prüfungen bei Zählermeldung

Bei der Meldung eines neuen Zählers über das Kundenportal entsteht in TINA ein Projekt der Art "Neuer Zähler". Es finden hierbei verschiedene Prüfungen statt:

• ist ein Netzanschluss vorhanden

• gibt es mehrere Projekte für den Hausanschluss am betroffenen Anschlussobjekt

• liegt eine Anschlussverstärkung vor

Details finden Sie in Kapiteln:

→ Prüfungen bei Zählermeldung

→ Prüfungen bei Zählermeldung (Administration)

Auskunft Kampfmittelfreiheit

Für ehemalige Bombenabwurfgebiete des zweiten Weltkriegs ist erforderlich, dass vor Beginn eines Bauvorhabens der Grundstückseigentümer Maßnahmen trifft, um mögliche Schäden Dritter durch Kampfmittel zu verhindern.
Bevor Netzbetreiber, deren Netzgebiet sich über eine solche Zone erstreckt, baulich tätig werden, fordern sie entsprechende Informationen zu betroffenen Grundstücken an.

Ein Sachbearbeiter kann einen Vorgang über die Aktionsbox an einem Projekt starten und eine Information zur Einholung verfassen und als Aktivität versenden.

Details finden Sie in Kapiteln:

→ Auskunft Kampfmittelfreiheit

→ Auskunft Kampfmittelfreiheit (Administration)

Angebotsprozess im Netzanschluss

Es steht ein Prozess zur Erstellung und Nachverfolgung von Angeboten im Rahmen der Netzanschlussprozesse zur Verfügung.

Hierzu gehören auch der Versand von Erinnerungen an Kunden, die Erstellung von Auftragsbestätigungen, sowie das eventuelle Nachfordern von notwendigen Dokumenten.

Details finden Sie in Kapiteln:

→ Angebotsprozess

→ Angebotsprozess (Administration)

Automatische Status-Mails

Im Rahmen eines Netzanschluss-Begehrens werden Meldungen aus dem ITC-Portal an TINA übermittelt. In TINA bilden Projekte den Kopf für diese Netzanschluss-Vorhaben. Die Statusführung erfolgt hierbei über den Projektstatus. Bei Statuswechseln soll der Antragssteller des jeweiligen Projekts über Änderungen per E-Mail informiert werden.

Für Projekte der folgenden Projektarten werden beim Erreichen bestimmter Projekt-Statuswerte Status-E-Mails versendet. 

Details finden Sie in Kapiteln:

→ Automatische Status-Mails

→ Automatische Status-Mails (Administration)

Ortstermine erstellen

In Projekten müssen Baubesprechungen auch vor Ort stattfinden. Der Projektleiter kann die am Projekt beteiligten Parteien zu einem bereits telefonisch abgestimmten Termin vor Ort per E-Mail einladen.

Im ersten Schritt wird ein Vorgang erzeugt, in dem projektbeteiligte Personen ausgewählt werden können. Im nächsten Schritt wird eine Einladung erfasst und zuletzt per E-Mail versendet.

Details finden Sie in Kapiteln:

→ Ortstermine erstellen

→ Ortstermine erstellen (Administration)

Aktionsboxeinträge zu den Erzeugungsanlagen am Projekt

Bisher waren in TINA auf den Projekten die Aktionsboxeinträge für die Prozesse zu den Erzeugungsanlagen aktiv, auch wenn die Suche noch nicht ausgeführt wurde und demnach keine Einträge in der Liste vorhanden waren. Ebenso konnten mehrere Projekte in der Liste markiert und die Aktionen ausgeführt werden. Die Aktionen beziehen sich jedoch immer auf genau ein Projekt.

Grundsätzlich werden die Aktionsboxeinträge für die Erzeugungsanlagen in der Listenansicht grundsätzlich inaktiv, wenn nicht genau ein Projekt-Datensatz in der Liste ausgewählt ist.

Einer Anlage können mehrere Adressen zugeordnet werden

Es ist jetzt möglich, eine Anlage mit mehreren Adressen bzw. Anschlussobjekten verknüpfen zu können, um beispielsweise große Erzeugungsanlagen wie etwa eine große Solaranlage, die sich über mehrere Gebäude oder Flurstücke erstreckt, abbilden zu können.

Um dies zu erreichen, wurde eine neue m:n-Relation zwischen den Anlagen (Installation) und den Adressen (Address) geschaffen.
Diese wird allerdings im Standard initial per Maskenkonfiguration im Unterbereich auf "Nicht sichtbar" geschaltet. Bei Bedarf kann der Kunde diese in seinem System sichtbar schalten.

Werden Adressen von Personen oder Anschlussobjekten verknüpft, so sind diese "ReadOnly", in diesem Unterbereich neu angelegte Adressen können bearbeitet und auch nach einer Verknüpfung zu einer anderen Anlage bearbeitet werden.

Optimierung der SC12EVIBaseUtils und Entitäten mit ERP-Kennzeichen

Die bisherige Implementierung der Methoden SC12EVIBaseUtils.getExtRefNo() und SC12EVIBaseUtils.isExtRefNo wurde bereits optimiert, um die Performance zu verbessern.

Hierbei müssen einige Entitäten nachgeladen werden. Um die Performance für diese Entitäten zu verbessern, wird geprüft, ob in die Datensätze in einem Suchergebnis nachgeladen werden. Wenn das der Fall ist, muss das Feld, das zum Nachladen führt, die Feldeigenschaft "Aufnahme in Selektionsergebnismenge" erhalten.

Dies gilt für folgende Entitäten:

• Activity

• C12METERREAD

• C12PDOC

Entfernung der Pflichtfeldeigenschaft

Folgende Attribute sind jetzt keine Pflicht mehr:

• Im Service ag.itc.createHouseConnection Attribut powerHeatStick

• im Objekt device Attribut powerComprEl

Folgende Felder sind jetzt keine Pflichtfelder mehr:

• connectorPosition

• connectionType

Im Objekt "device" wurde die (bedingte) Pflichtfeldbedingung für folgende Attribute entfernt:

• product

• producer

• model

• series

• meterNo

Objekt "customerProfile" wurde erweitert

Das bestehende Objekt customerProfile innerhalb der ITC-Portalschnittstelle wurde wie folgt erweitert:

Details finden Sie im Kapitel → Objekttyp-Mapping | customerProfile

Administration

Masken-Editor

Entitäts-Masken können von Administratoren übersteuert werden.

Jetzt können auch Texte auf Masken-Komponenten internationalisiert und Icons hinterlegt werden.

Icon-Auswahl

Im Masken-Editor können jetzt auf Tabs und Labels Icons hinterlegt werden.

Über den Button "Icon wählen" kann über einen Icon-Auswahl-Dialog ein Icon hinterlegt oder entfernt werden. Wir empfehlen bei der Maskengestaltung eine Größe von 16x16 Pixel.

Internationalisierung

Im Masken-Editor können jetzt Tabs, Collapsibles und Labels internationalisiert werden.

Über den Button "Internationalisierung" kann in der Konfiguration der Internationalisierungs-Dialog gestartet und die Texte in verschiedenen Sprachen angepasst werden.

Meldung über nicht unterstützte Einstellungen im Rich Client

Da der Windows Client nach der Abkündigung mittlerweile nicht mehr zugänglich ist, wurde die Meldung im Masken-Editor entfernt.

Feldeigenschaften von Memo-Feldern bearbeiten

Bisher gab es keine Möglichkeit, direkt zu dem Dialog zu wechseln, wo die Feldeigenschaften eines Memo-Felde bearbeitet werden konnten. Wenn dann noch das zugehörige Label nicht auf der Maske vorhanden war, musste man umständlich suchen, um das korrekte Feld zu finden. Absprung per Kontextmenü war ebenfalls nicht möglich.

Jetzt kann man in der Memoansicht über den Schalter Feld verwalten direkt in die Feldeigenschaften des Memofeldes springen.

Umbau der Selektion von Linkrelationen auf gleichen Entitäten

Ab Version 2025.6 unterscheiden wir die Behandlung von "normalen" und "reflexiven" Relationen.

Definition

Reflexive Relationen sind Relationen zwischen zwei gleichen Entitäten.
Bei diesen muss dann sowohl die Hin- als auch die Rückrichtung einzutragen werden.

Welche Relationen gibt es

Es gibt Standard-Linktabellen, die keine zusätzlichen Relationsinformationen halten.
Es gibt attributierte Linktabellen, die zusätzliche Relationsinformationen enthalten.

Eindeutigkeit

Einträge zwischen Relationen sind eindeutig zu halten.

• Auf „normalen“ Standard-Linktabellen (also Linktabellen ohne zusätzliche Attribute zwischen zwei unterschiedlichen Entitäten) ist die Kombination aus MasterPk und SlavePk eindeutig, aktuell ist auch das Active-Flag zu berücksichtigen, siehe Abschnitt Active-Flag weiter unten.

• Auf attributierten Standard-Linktabellen (also Linktabellen mit zusätzlichen Attributen zwischen zwei unterschiedlichen Entitäten) ist die Kombination aus MasterPk und SlavePk eindeutig, aktuell ist auch das Active-Flag zu berücksichtigen, also gleich mit den „normalen“ Standard-Linktabellen.

  • Hier ist allerdings eine Klärung im PM anhängig, da der Kunde TEN gefragt hat, ob dies generell ermöglicht werden soll.

• Auf Reflexiven Relationen müssen Einträge mit Relationsattributen ebenfalls eindeutig sein, allerdings kommt hier noch das bzw. die Relationsattribute der RowModelMergerFields zum Tragen, diese bestimmen ebenfalls die Eindeutigkeit mit.
  Beispiel:
  Die Geschäftspartner KundeA und KundeB werden miteinander verknüpft.
  Wird die Verknüpfung KundeA als Mutter von KundeB eingetragen, darf keine zweite Verknüpfung mit dem Attribut Mutter erfolgen, da dies keine eindeutige Verknüpfung wäre. Damit ist implizit hinterlegt, dass KundeB Tochter von KundeA ist.
  Die Verknüpfung KundeB als Mutter von KundeA darf eingetragen werden, sie ist aber sehr wahrscheinlich fachlich falsch.

• Neu mit Version 25.6 auf reflexiven Relationen
  In diese Linktabellen ist sowohl die Hin- als auch die Rückrichtung einzutragen.
  Beispiel:

  • rAcAc

    • Datensatz 1: masterPk: myPk1 und slavePk: myPk2

    • Datensatz 2: masterPk: myPk2 und slavePk: myPk1

  • rCuCu

  • Datensatz 1: masterPk: myPk1, slavePk: myPk2 und RelationTypeKey: MUTTER

  • Datensatz 2: masterPk: myPk2, slavePk: myPk1 und RelationTypeKey: TOCHER

• Die Daten werden nach dem folgenden Muster in die Datenbank geschrieben:

  • Initiale Richtung (das ist bereits vor Version 25.6 so):

    • Der Pk des Datensatzes aus dem Hauptfenster wird in MasterPk geschrieben.

    • Der Pk des im Unterbereich zur Verknüpfung ausgewählten Datensatzes wird in SlavePk geschrieben.

    • Der gewählte RelationPk (z. B. MUTTER) wird in das entsprechende Feld geschrieben

  • Zusätzlich muss ab Version 25.6 noch die "Rückrichtung" geschrieben werden

    • Der Pk des im Unterbereich zur Verknüpfung ausgewählten Datensatzes wird in MasterPk geschrieben.

    • Der Pk des Datensatzes aus dem Hauptfenster wird in SlavePk geschrieben.

    • Der AssignedPk (TOCHER) aus der S_Keytab zum gewählten RelationPk (hier MUTTER) wird in das entsprechende Feld geschrieben.

Regeln über den DefaultSetter

Über den DefaultSetter kann geprüft werden, ob für die Relation spezielle Regeln gelten und ggf. noch Daten redundant in eine der beiden Tabellen geschrieben werden müssen

• Im Feld RelationName steht die Relation, die besondere Regeln enthält.

• Im Feld BelongingLookupField steht der Name des Feldes, zu dem die Regel gilt. (Die Kombination aus RelationName und BelongingLookupField ist eindeutig)

• Im Feld DefaultFlagInLinkTable ist das physische Feld benannt, in dem der Marker für die doppelte Persistenz gespeichert wird.

• In den Feldern DefaultFlagInMaster bzw. DefaultFlagInSlave sind die virtuellen Felder in der Anwendung benannt, wie sie in die jeweilige Entität delegiert werden.

• Im Feld RelationTypeKey ist das virtuelle Feld aus Sicht der Master-Entität benannt, falls es eines gibt. Das physische Feld kann über die V_Metadata selektiert werden
  Beispiel:
  select DelegatedToPhysField from v_metadata where AttributeName = 'EasementRoleCu.Easement'
  oder insgesamt:
  select DelegatedToPhysField from v_metadata where AttributeName in (select RelationTypeKey from DefaultSetter where RelationTypeKey is not null)

• Im Feld RemoveOldLink gibt es die Konfiguration TRUE, FALSE, PROPERTY
  TRUE bedeutet, dass ein zuvor existenter Link entfernt wird
  FALSE bedeutet, dass ein zuvor existenter Link beibehalten wird, das Flag DefaultFlagInLinkTable aber zurückgesetzt wird
  PROPERTY bedeutet, dass der Anwender entscheiden kann, welches Verhalten er auf dieser Relation wünscht

• Das Feld ClearOnlyRelation gibt an, ob bei einer Änderung der bestehenden Relation das Flag in den anderen Relationen zurückgesetzt werden muss:
  Beispiel:
  Ansprechpartner Unterbereich Adressen:
  Es sind zwei Adressen hinterlegt, eine ist als Postadresse und eine als Anzeigeadresse markiert. Im Standard ist ClearOnlyRelation in beiden Fällen (DefaultCoPeAd.rCoPeAd und LetterCoPeAd.rCoPeAd) auf true gesetzt.

          Das bedeutet, dass beim Setzen des jeweiligen Flags das Flag in dem anderen Datensatz des Unterbereichs entfernt wird.

• RelationTypePk (ab Version 25.6)
  Zur Vorbelegung des RelationTypeKeys, in dem man den Pk eines Schlüssels hinterlegen kann, der dann in die Rolle der Relation geschrieben wird.
  Vor Version 25.5 konnte man das nur erreichen, indem man einen Standardwert auf das Relationsfeld setzt. Gibt es aber mehrere doppeltpersistente Felder auf derselben Relation, reichte dies nicht aus. 

Active-Flag

• Auf Relationen zwischen Entitäten, die Bewegungsdaten enthalten, dürfen inaktive Einträge gelöscht werden.
  Beispielsweise Aktivitäten zu Mitarbeitern (rEmAc), hier können inaktive Relations-Datensätze gelöscht werden, da diese Information nur selten relevant ist.

• Auf Relationen zwischen Entitäten, die System-Konfigurationen enthalten, muss geprüft werden, ob inaktive Einträge wieder aktiviert werden müssen, hier ist das Löschen der inaktiven Daten nicht erlaubt.
  Soll ein neuer Eintrag geschrieben werden, ist zu prüfen, ob ein inaktiver existiert und dieser ist dann wieder zu aktivieren
  Hier sind insbesondere diese Linktabellen zu nennen

  • rGrEm: Gruppen eines Mitarbeiters

  • rEmUn: Mandanten eines Mitarbeiters

  • rEmEm: Stellvertretungen eines Mitarbeiters

Statements zum Ermitteln von attributierten Felden, die im Zuordnungsbrowser angeboten werden (RowModelMergerFields)

Mit diesem Statement können die Attribute auf "reflexiven" Releationen ermittelt werden:

with sub_Linktable as (
	select lv1.RowPk as linkTable from lmdVarchar lv1, lmdVarchar lv2, lmdVarchar lv3
            where lv1.RowPk = lv2.RowPk and lv1.RowPk = lv3.RowPk and
                        lv3.Fieldname = 'LinkTable' and coalesce(lv3.c2, lv3.c1, lv3.c0) != 'NONE' and
                        lv1.FieldName = 'MasterTable' and lv2.FieldName = 'SlaveTable' and
                        coalesce(lv1.c2, lv1.c1, lv1.c0) = coalesce(lv2.c2, lv2.c1, lv2.c0)
)
select a.rowPk, coalesce(c2, c1, c0) as rowModelMergerField
from amdBoolean a, sub_Linktable t
where a.fieldname = 'RowModelMergerField'
and a.rowPk like '%.' || t.linktable
and coalesce(a.c2, a.c1, a.c0) = 1
order by t.linkTable

Mit diesem Statement können die Attribute auf allen Relationstabellen ermittelt werden, auch die auf "normalen" Tabellen.

with sub_Linktable as (
      select rowPk as linkTable from lmdVarchar where fieldname = 'LinkTable' and coalesce(c2, c1, c0) != 'NONE'
      )
select a.rowPk,
       coalesce(c2, c1, c0) as rowModelMergerField
from amdBoolean a, sub_Linktable t
where a.fieldname = 'RowModelMergerField'
  and a.rowPk like '%.' || t.linktable
  and coalesce(a.c2, a.c1, a.c0) = 1
order by t.linkTable

Vorgangsmanagement: Erweiterung der Logik bei Benachrichtigungen und Beobachtungen

Für noch besseres Vorgangsmanagement ist es wichtig, dass auf den Vorgängen und Anliegen Benachrichtigungen zu Veränderungen am Vorgang/Anliegen versendet werden.

Die Benachrichtigungen sind für folgende Personen und Gruppen relevant:

• Delegiert an

• Delegiert an Gruppe

• Verantwortlich

Hierfür sind 3 neue globale Variablen wichtig, welche zur Steuerung von Benachrichtigungen im Vorgangsmanagement führen. Dies kann vom Administrator vorgegeben oder verändert werden. Es wird eine Benachrichtigung an Verantwortlich/Delegiert an/ Delegiert an Gruppe erstellt, wenn ein Vorgang oder Anliegen geändert oder eine Aktivität zum Vorgang erstellt wurde. Dies erfolgt bei der Einstellung true. Bei false: Es wird keine Benachrichtigung erstellt.

•  C0Ticket_Notification_DelegatedTo

  • Default Wert = false

• C0Ticket_Notification_DelegatedToGroup

  • Default Wert = false

• C0Ticket_Notification_Responsible

  • Default Wert = true

Detaillierte Beschreibung der Logiken finden Sie im Kapitel

→ Vorgangsmanagement | Benachrichtigungen

Den internen Name eines Feldes kopieren

Per Strg+Shift+<Klick> auf den entsprechenden Eintrag in der Listenkomponente kann wie bereits an anderen Stellen der interne Name des Feldes in die Zwischenablage kopiert werden.

Aktualisierung von Benachrichtigungen durch das Ändern der Mandaten-Zuordnung

Wenn ein Vorgang an einen Mitarbeiter delegiert wurde, der einem anderen Mandanten zugehörig ist, kam die Benachrichtigung erst mit Verzögerung (2 Tage) beim anderen Benutzer an.

Klassen UnitUtils.setUnits bzw. UnitUtils.enableUnitsExclusive aktualisieren jetzt das Benachrichtigungsmenü. Diese Funktion wurde im UnitHandler ergänzt.

Einschränkungen nach Datum in Kacheln und Admin im Web

Bisher konnte man in den laufenden Instanzen nicht nach Datum einschränken. Um dieses zu ermöglichen, musste zuerst die Common-Komponente "DateRangePicker" erstellt werden.

Im nächsten Schritt wurde der FilterSorter angepasst.

Durch die Tasache, dass dieser Zeitraum-Filter in der allgemeinen FilterSorter-Komponente realisiert wurde, steht er nun automatisch auch in Kacheln zur Verfügung. Insofern kann der Filtern ab sofort in allen Kacheln der zweiten Generation (V2.0), wie z.B. der Compact List, genutzt werden.

Infoboards

Verbesserungen der Post-IT-Kachel

Die Post-IT-Kachel hat 2 Verbesserungen erfahren:

1. Kachel-Metadaten wurden so geändert, so dass die Minimalhöhe/-breite "sehr klein" anstatt "klein" ist

2. Mit Betätigung von STRG+<Klick> öffnet sich ein Datensatz in einem neuen Tab im Hintergrund. Der Fokus bleibt weiterhin im aktuell sich befindlichen Tab erhalten.

Verbesserte Achsendarstellung für die Charts-V2-Kachel

Bisher war die Achsendarstellung der Charts-Kachel etwas suboptimal. Wenn bspw. Datenpunkte zwischen 6 und 9 vorhanden waren, zeigte die Achse Punkte von 6 bis 9 auf. Befanden sich aber nur ganzzahlige Werte in den Datenpunkten (6, 7, 8, 9) so verwendete die Kachel nicht-ganzzahlige-Achsenpunkte (6.0, 6.2, 6.4, ...). Das hatte zur Folge, dass die Kachel-Achsenbeschriftung unnötig aufgebläht war.

Jetzt wird bei der Darstellung nur auf die signifikanten Stellen geachtet. Das soll an folgenden Beispielen demonstriert werden:

• Die Datenmenge (6,7,8,9) hat keine signifikanten Stellen, daher ist die Achsenbeschriftung ganzzahlig sein.

• Die Datenmenge (6.2, 6.5, 7.1, 7.5, 8.0) hat für alle Werte eine signifikante Stelle nach dem Komma, daher wird die Achsenbeschriftung auch maximal in 0.1-Schritten und nicht kleiner dargestellt.

• Die Datenmenge (70, 10, 6, 4.2) hat als geringsten Wert eine signifikante Stelle nach dem Komma, daher wird auch hier die Achsenbeschriftung auch maximal in 0.1-Schritten und nicht kleiner dargestellt. Es ist hier nicht sinvoll, die Achse von 4.2 bis 70 in 0.1-Schritten darzustellen, aber die Achse erlaubt nicht noch kleinere Achsenwerte.

Erweiterungen

Anfrage zu dem KI-Anbieter als PreView darstellen

Mit der neuen Vorschau-Funktion wird der Prozess zur Erstellung und Überprüfung von Prompts für den KI-Assistenten erheblich vereinfacht. Administratoren können nun direkt in der Prompt-Bibliothek und der Eingabe-Verwaltung eine Vorschau generieren, um die Anfragen an die KI und deren Antworten zu simulieren und zu visualisieren.

Details finden Sie im Kapitel → KI-Prompts | Vorschau

Details finden Sie im Kapitel → KI-Eingaben | Vorschau

BPM

Memo-Ansicht auf BPM-Masken

Um die Inhalte des Memo-Feldes in Prozess-Schritten besser darstellen zu können, können die Felder auf BPM-Masken in Memo-Ansicht geöffnet werden.

Scripting

Es wurden neue Befehle implementiert und verbessert.

Details finden Sie im Scripting-Handbuch.

CURSOR-App