Version 12.32

Tags:

• Release
• Installation
• Update
• Tabellen

  33 Minuten Lesezeit  

Neue und geänderte Funktionen

Stammdaten

Automatisierte Anlage der Zuständigkeits‑Dimension (DIM ZE)

Ausgangssituation

Die globalen Dimensionen DIM Objekt und DIM ZE spielen eine zentrale Rolle in Auswertungen und Berichten.

Bislang musste die DIM ZE manuell angelegt und dem jeweiligen Objekt zugeordnet werden.
Während die Objekt‑Dimension bereits automatisch zugeordnet wird, war dies für die ZE‑Dimension nicht der Fall. Wird die ZE‑Dimension nicht angelegt oder der Parameter „Gleicher Code“ nicht gesetzt, können fehlerhafte Buchungen und unübersichtliche Konstellationen entstehen.

Auswirkung

Fehlt die ZE‑Dimension oder ist der Parameter Gleicher Code nicht gesetzt, entstehen fehlerhafte Buchungen sowie unübersichtliche Datenstrukturen. Zusätzlich entsteht für Anwender ein regelmäßiger manueller Aufwand für die Pflege der Dimensionen.

Anpassung

Es wurde ein automatisierter Prozess zur Anlage der Zuständigkeits‑Dimension eingeführt.
Die Zuordnung erfolgt nun systemseitig analog zur Objekt‑Dimension.
Dadurch wird der manuelle Aufwand deutlich reduziert und Fehlerquellen werden minimiert.

Mietverwaltung

Sollstellungszeilen aus Wirtschaftsplan und Differenzberechnungslogik

Ausgangssituation

Bei der Erstellung von Sollstellungszeilen aus dem Wirtschaftsplan wurde bislang automatisch die Sollstellungsdifferenzberechnung angestoßen. Da diese Berechnung sehr umfangreich ist und für jede neu erzeugte Zeile erneut durchgeführt wurde, führte dies zu erheblichen Performanceeinbußen, insbesondere bei größeren Wirtschaftsplänen oder umfangreichen Vertragsbeständen.

Auswirkung

Die langen Berechnungszeiten verzögerten den gesamten Erstellungsprozess der Sollstellungszeilen. Dies führte zu Wartezeiten für Anwender und zu einer insgesamt niedrigeren Systemreaktionsgeschwindigkeit während dieser Aktion.

Anpassung

Zur Performanceoptimierung wurde eine neue Funktion implementiert, welche die Sollstellungsdifferenzberechnung während der Erstellung von Sollstellungszeilen aus dem Wirtschaftsplan deaktiviert.

Diese Funktion wird ausschließlich während dieser spezifischen Aktion ausgeführt. Nach Abschluss der Erstellung bzw. in anderen Bereichen steht die Sollstellungsdifferenzberechnung wie gewohnt zur Verfügung.

Wirtschaftsplan

Anpassung Einstellungen für Ausnahmen soll gleich sein

Ausgangssituation

Die Ausschlussgründe Vertragsbeginn in Abrechnungsperiode und Vertragsbeginn in Planungsperiode waren auf der Wirtschaftsplan Objekt Vorlagekarte anders platziert als auf der Wirtschaftsplan Objekt Karte.

Auswirkung

Die unterschiedliche Anordnung führte zu inkonsistenter Bedienung und erschwerter Orientierung.

Anpassung

Beide Einstellungen wurden in die Gruppe Vertrag verschoben, um das Layout an die Objektkarte anzugleichen.

Instandhaltung

Beauftragung archivieren erst beim Buchen

Ausgangssituation

Beim Verwenden der Funktion Beauftragung holen in einer Einkaufsrechnung wurde die zugehörige Beauftragung bereits während des Holvorgangs archiviert, obwohl die Rechnung noch nicht gebucht war.

Auswirkung

Dies führte zu Unklarheiten im Bearbeitungsstatus und konnte zu Fehlern in Dokumentation oder Prüfung führen.

Anpassung

Die Archivierung/Löschung erfolgt nun erst beim Buchen der Einkaufsrechnung, nicht mehr beim Holen.

Zusätzliche Hinweise

Abhängig von der Einrichtung wird die Beauftragung archiviert oder gelöscht.

Beauftragung holen mit Anhängen

Ausgangssituation

Bei der Funktion Beauftragung holen wurden bisher die in der Beauftragung vorhandenen Anhänge nicht automatisch in die Einkaufsrechnung übernommen. Beim Buchen der Einkaufsrechnung standen diese Anhänge somit nicht zur Verfügung und mussten ggf. manuell hinzugefügt werden.

Auswirkung

Die Nutzung der Funktion Beauftragung holen führte bisher zu unvollständigen Attachments in der gebuchten Einkaufsrechnung. Dies konnte zusätzlichen manuellen Aufwand für Anwender verursachen, insbesondere im dokumentations- oder prüfungsrelevanten Kontext.

Anpassung

Beim Buchen einer Einkaufsrechnung, die über die Funktion Beauftragung holen erstellt wurde, werden nun alle in der Beauftragung vorhandenen Anhänge automatisch als Anhänge in die gebuchte Einkaufsrechnung übernommen. Die Anhänge stehen im gebuchten Beleg vollständig und unmittelbar zur Verfügung.

Zusätzliche Hinweise

• Die Übernahme erfolgt ausschließlich beim Buchen der Einkaufsrechnung, nicht beim initialen Laden der Beauftragung.
• Bestehende manuelle Anhänge an der Einkaufsrechnung bleiben unverändert erhalten.
• Die Funktion unterstützt eine konsistente Dokumentation und erleichtert Prüfprozesse.

Kreditorische Verträge

Versorgerverträge - Ansicht Filter erweitern

Ausgangssituation

In der Liste Kreditorische Verträge fehlte eine schnelle Filterfunktion.

Auswirkung

Eine manuelle Suche war notwendig.

Anpassung

Im Menü wurde der Schnellfilter hinzugefügt:

• Alle anzeigen
• Aktive
• Zukünftige
• Aktive und zukünftige
• Beendete

Attribute verfügbar machen

Ausgangssituation

Auf der Seite Kreditorische Verträge waren bisher keine Attribute verfügbar.
Weder in der Vertragsübersicht noch in den einzelnen Verträgen existierte eine Möglichkeit, zusätzliche Informationen über Attribute darzustellen oder zu bearbeiten.

Auswirkung

Durch die fehlenden Attribute war eine detaillierte Klassifizierung oder Filterung von Verträgen nicht möglich. Anwender konnten keine zusätzlichen Merkmale hinterlegen, was die Transparenz und die gezielte Suche nach bestimmten Vertragsinformationen einschränkte.

Anpassung

Infobox für Attribute:
Attribute werden als Infobox sowohl in der Vertragsübersicht als auch in den einzelnen Verträgen eingefügt.

Erweiterung der Menüleiste in der Vertragsübersicht:
Folgende Aktionen wurden ergänzt:

• Attribute bearbeiten
• Nach Attributen filtern
• Attribute‑Filter löschen

Weitere Vertragsklassen

Ausgangssituation

In der Auswahlliste Vertragsklasse innerhalb der kreditorischen Vertragsarten stand bislang ausschließlich die Vertragsklasse Versorgervertrag zur Auswahl. Weitere Vertragsklassen für Dienstleistungs‑, Wartungs‑ oder Versicherungsverträge waren nicht verfügbar.

Auswirkung

Obwohl die neuen Vertragsklassen nun in der Auswahlliste angezeigt werden, können diese aktuell noch nicht ausgewählt werden. Die Verarbeitung der genannten Vertragsarten erfolgt weiterhin über die bestehende Funktionalität außerhalb der kreditorischen Verträge.

Anpassung

Neue Klassen:

• Dienstleistungsvertrag
• Wartungsvertrag
• Versicherungsvertrag

Kreditorische Verträge im Menüband

Ausgangssituation

Die kreditorischen Verträge können bislang nur über die Suchfunktion aufgerufen werden.

Auswirkung

• Umständliche Handhabung für den Anwender
• Fehlende Menüeinträge

Anpassung

In folgenden Bereichen wurde ein Aufruf für kreditorische Verträge integriert:

1. Rollencenter Technische Bearbeitung
2. Rollencenter Objektverwaltung
3. In allen Rollencentern unter dem Menüpunkt Objektverwalter/Verträge

Rechnungen/Gutschriften im Nachgang mit kreditorischen Vertrag verknüpfen

Ausgangssituation

Im Nachgang können kreditorische Rechnungen oder Gutschriften (z. B. Korrekturbelege) zu einem bereits abgeschlossenen kreditorischen Vertrag eingehen. Bei Versorgerverträgen ist eine Zuordnung über die bestehende Schlussrechnungslogik jedoch nicht möglich.

Es besteht der Bedarf, auch nachträglich eine Verbindung zwischen folgenden Belegarten und einem kreditorischen Vertrag herzustellen:

• EK‑Rechnung
• EK‑Gutschrift
• Gebuchte EK‑Rechnung
• Gebuchte EK‑Gutschrift

Auswirkung

Durch die fehlende Möglichkeit der nachträglichen Verknüpfung ist die Transparenz im Vertrags- und Rechnungswesen eingeschränkt. Korrekturbelege können nicht eindeutig einem bestehenden Versorgervertrag zugeordnet werden, was insbesondere bei später auftretenden Abweichungen oder Gutschriften zu Nachvollziehbarkeitsproblemen führt.

Anpassung

Alle vier Belegarten wurden um die Aktion Kreditorischen Vertrag verknüpfen erweitert. Bei Aufruf öffnet sich ein Fenster mit den Versorgerverträgen, die denselben Kreditor und dasselbe Objekt beinhalten. Es spielt keine Rolle, ob die Schlussrechnung bereits erfolgt ist. Im Versorgervertrag kann die Verknüpfung über die Infobox geöffnet werden. Die Verknüpfung erfolgt nur zum Vertragskopf und nicht zu einer Vertragszeile.

Dauerzahlung - Felder für Kreditor nicht mehr änderbar

Ausgangssituation

Wird eine Dauerzahlung aus einem kreditorischen Vertrag heraus erstellt, wird auf der Karte Dauerzahlungen automatisch die Vertragsnummer gefüllt. Bisher konnten die Felder Kreditor Nr., Eigentümer/Mieter, Objektnr. und Zuständigkeitseinheit weiterhin manuell geändert werden.

Auswirkung

Eine nachträgliche Änderung dieser Felder konnte zu Inkonsistenzen zwischen Vertrag und Dauerzahlung führen. Prozesssicherheit und Nachvollziehbarkeit waren reduziert.

Anpassung

Wenn eine Dauerzahlung über einen kreditorischen Vertrag erzeugt wurde und somit eine Vertragsnummer enthält, können die Felder Kreditor Nr., Eigentümer/Mieter, Objektnr. und Zuständigkeitseinheit nicht mehr verändert werden.

Damit wird sichergestellt, dass die Daten der Dauerzahlung mit den im Vertrag hinterlegten Daten übereinstimmen. Die Sperre ist aktiv, sobald die Vertragsnummer in der Dauerzahlung vorhanden ist.

Dauerzahlung - Umgang mit ungebuchter Rechnungsnummer ändern

Ausgangssituation

In der Dauerzahlung besteht eine Verknüpfung zur zugehörigen Schlussrechnung bzw. Schlussgutschrift. Wurde ein ungebuchter Einkaufsbeleg mit einer Dauerzahlung verknüpft, erfolgte beim anschließenden Buchen des Einkaufsbelegs keine Aktualisierung dieser Verknüpfung.

Auswirkung

Ein direkter Zugriff auf den gebuchten Einkaufsbeleg war aus der Dauerzahlung heraus nicht möglich, was die Nachvollziehbarkeit und Weiterbearbeitung beeinträchtigte.

Anpassung

Die Vorgehensweise wurde überarbeitet. Wird ein Einkaufsbeleg nach erfolgter Verknüpfung mit einer Dauerzahlung gebucht, wird die Verknüpfung in der Dauerzahlung automatisch aktualisiert. Die Dauerzahlung verweist nun auf den gebuchten Einkaufsbeleg, sodass die Navigation wieder vollständig gewährleistet ist. Die Anpassung dient der Sicherstellung konsistenter Verknüpfungen zwischen Einkaufsbelegen und Dauerzahlungen.

Dauerzahlung - Felder für Kreditorenvertrag einblendbar

Ausgangssituation

Aufgrund der neu gegebenen Möglichkeit, Kreditorenverträge mit Dauerzahlungen zu verknüpfen, sind weitere Felder sinnvoll geworden. Die für Anwender relevanten Informationen Kreditorenvertrag Nr. und Zeilennummer waren nicht sichtbar und konnten auch nicht eingeblendet werden.

Auswirkung

Durch die fehlende Einblendmöglichkeit war eine direkte Identifikation der zugehörigen Vertragszeile war nicht möglich. Für Auswertungen oder bei Rückfragen mussten Anwender in den Vertragsdetails nachschlagen. Die Arbeit in größeren Vertragsbeständen oder bei vielen Dauerzahlungen wurde erschwert.

Anpassung

Die Dauerzahlung Übersicht wurde um zwei neue einblendbare Felder erweitert:

• Kreditorenvertrag Nr.
• Zeilennummer

Beide Felder sind nun als weitere Felder im Menü Personalisieren/Einblenden verfügbar. Sie werden standardmäßig ausgeblendet, um die Übersichtlichkeit für Nutzer ohne Bedarf zu wahren. Bei Bedarf können die Felder individuell pro Benutzer eingeblendet werden. Nach dem Einblenden werden die Informationen direkt in der Übersicht angezeigt und ermöglichen eine sofortige Zuordnung zur jeweiligen Vertragszeile.

Zeile manuell abschließen

Ausgangssituation

In Versorgerverträgen (Kreditorischen Verträgen) besteht der Bedarf, einzelne Vertragszeilen manuell abzuschließen, wenn dies nicht über die Erstellung einer Schlussrechnung erfolgen soll. Bisher war ein solcher manueller Abschluss nicht möglich. Vertragszeilen blieben aktiv, auch wenn für den fachlichen Ablauf keine weitere Nutzung erforderlich war.

Auswirkung

Die Vertragszeile wurde nicht in die Abgeschlossenen Zeilen übertragen. Sie befand sich nach wie vor unter den aktuellen Vertragszeilen.

Anpassung

Zur Optimierung des Prozesses wurde eine neue Aktion Zeile abschließen in den Zeilen unter dem Menüpunkt Verwalten implementiert.

Beim Ausführen der Aktion wird das Feld Completed der Zeile auf Ja gesetzt und die Zeile wird in den Abgeschlossenen Zeilen angezeigt.

Einkaufsrechnung-/-gutschrift Verbindungen Versorgervertrag

Ausgangssituation

In Einkaufsrechnungen und Einkaufsgutschriften besteht bereits eine technische Verbindung zum Versorgervertrag, das Feld war bislang jedoch nicht standardmäßig eingeblendet

Auswirkung

Die fehlende Sichtbarkeit des Feldes Kreditorenvertrag führte zu folgenden Einschränkungen:

• Die Verbindung zum Versorgervertrag war nicht auf den ersten Blick erkennbar.
• Der Absprung zum zugehörigen Vertrag erforderte zusätzliche Navigationsschritte.
• Die Belegübersicht bot dadurch keine ausreichende Transparenz.

Anpassung

• Das Feld Kreditorenvertrag wird nun standardmäßig im Inforegister RELion eingeblendet.
• Das Feld ist nicht editierbar, da die Befüllung ausschließlich systemseitig erfolgt.
• Über das Feld kann direkt in den zugehörigen Versorgervertrag verzweigt werden.
• Bei Bestätigung der Schlussrechnung in der Dauerzahlung wird die Vertragsnummer weiterhin automatisch in das Feld eingetragen (bestehende Funktionalität bleibt bestehen).

Anzeige Geprüft-Vermerk und Bemerkung werden als zusätzliche Informationen nun direkt unter dem Feld Kreditorenvertrag im Beleg angezeigt. Beide Angaben sind Informationsfelder und nicht editierbar.

Diese Darstellung verbessert die Nachvollziehbarkeit fachlicher Prüfprozesse und reduziert die Notwendigkeit, in weitere Detailmasken zu wechseln.

Wordintegration

Word Vorlage Einkaufsbestellung

Ausgangssituation

Der Bericht Beauftragung stand bislang ausschließlich als RDLC-Layout zur Verfügung.
In diesem RDLC-Layout werden Inhalte entsprechend der auf der Request Page aktivierten Optionen (z. B. Rechnungsempfänger, Leistungsempfänger) gesteuert.

Auswirkung

Es wird nun zusätzlich das Word-Layout Standardlayout für Beauftragung (Word) bereitgestellt. Das Word-Layout orientiert sich inhaltlich und optisch am bestehenden RDLC-Layout.

Im Unterschied zum RDLC-Layout werden im Word-Layout jedoch grundsätzlich alle verfügbaren Informationen angedruckt – unabhängig davon, ob die entsprechenden Optionen in der Request Page aktiviert wurden.

Eine dynamische Steuerung einzelner Textbausteine oder Abschnitte über Request-Page-Optionen ist im Word-Layout nicht bzw. nur mit erheblichem Aufwand umsetzbar.

Anpassung

Für individuelle Anforderungen wird empfohlen, eigene Varianten über die Berichtslayouts zu erstellen. Diese Untervarianten können an spezifische Bedürfnisse angepasst werden und bieten eine praktikable Lösung für Szenarien, in denen nicht alle Informationen ausgegeben werden sollen.

BauSecura

Bausecura - Aktenzeichen übertragen

Ausgangssituation

Bei der Übermittlung von Schadens- bzw. Rechnungsdaten an BauSecura wurde bisher kein polizeiliches Aktenzeichen aus der Schadensmeldung an die Schnittstelle übergeben.

Auswirkung

Endanwender konnten bislang das in der Schadensmeldung erfasste polizeiliche Aktenzeichen nicht in den übermittelten Daten an BauSecura wiederfinden. Dies führte zu fehlender Transparenz und erschwerter Nachverfolgung bei polizeilich relevanten Schadensfällen.

Anpassung

Die Schnittstelle zur Übermittlung von Schadens- und Rechnungsdaten an BauSecura wurde erweitert. Ab sofort wird das in der Schadensmeldung erfasste polizeiliche Aktenzeichen (Feld: policeReportNumber) automatisch mit übertragen.

Action „Übertragungsstatus wechseln“ direkt promoten

Ausgangssituation

Auf der Seite BauSecura Meldungen war die Aktion Übertragungsstatus wechseln bislang im Untermenü Aktionen/Funktionen abgelegt und damit nur über einen zusätzlichen Navigationsschritt erreichbar.

Auswirkung

Durch die neue Platzierung ist die Funktion Übertragungsstatus wechseln für Anwender deutlich besser sichtbar und direkt zugänglich.

Die Bedienung wird insgesamt intuitiver, da eine häufig genutzte Aktion nicht mehr in einem Untermenü verborgen ist, sondern unmittelbar im Sichtbereich zur Verfügung steht.

Anpassung

• Die Aktion Übertragungsstatus wechseln wurde aus dem Untermenü Aktionen/Funktionen entfernt.
• Stattdessen wird sie nun als eigenständige, prominent platzierte Schaltfläche direkt neben Schaden an BauSecura melden angezeigt.
• Das dadurch funktionslos gewordene Untermenü Aktionen wurde vollständig entfernt.

Anpassung der Rechnungsnummern-Übermittlung

Ausgangssituation

Bei der Übergabe von Rechnungsdaten an BauSecura wurde bislang die Rechnungsnummer im Format “///BS ” übermittelt. Dieses Format war Grundlage für die technische Weiterverarbeitung im Zielsystem.

Auswirkung

Aufgrund technischer Anpassungen bei der Verarbeitung der Daten in BauSecura konnte das bisherige Format nicht mehr zuverlässig verarbeitet werden. In der Folge war eine Übergabe im bisherigen Format nicht mehr möglich.

Anpassung

Die Übergabe der Rechnungsnummer erfolgt ab sofort im neuen Format: “//B//B” Die Anpassung wurde systemseitig umgesetzt und wird automatisch bei jeder Datenübertragung an BauSecura angewendet.

Zusätzliche Hinweise

• Für Endanwender entsteht kein zusätzlicher Eingabeaufwand – die Umstellung erfolgt vollständig im Hintergrund.
• Historische Daten bleiben unverändert; das neue Format wird ausschließlich für neu übermittelte Rechnungen verwendet.
• Sollte die Weiterverarbeitung dennoch Fehlermeldungen erzeugen, ist eine Prüfung auf Altdaten oder fehlerhafte Eingabeformate empfohlen.

Änderung des Auslesens der Rechnungsnummer

Ausgangssituation

Das ursprüngliche Konzept sah die Übergabe der Rechnungsnummer in der End‑to‑End‑ID vor. In der Praxis wurde die Nummer jedoch über den Verwendungszweck geliefert.

Bei Zahlungen im Umfeld Bausecura/Funk wird die Rechnungsnummer nicht zuverlässig am Ende des Verwendungszwecks (SVWZ) ausgegeben, sondern erscheint zwischen beliebigem Text.
Der automatische Zahlungsausgleich konnte Belegnummern in BAUSECURA‑Zahlungen nicht in jedem Fall erkennen, weil:

• die Position im Text variabel war
• die Nummernlänge nicht definiert war

Die bisherige Kennzeichnung war:
Alt: ///BS REL_RNR00152
Aufbau: ///BS <Leerzeichen> <rechnr> <weiterer Text>

Auswirkung

• BAUSECURA‑Zahlungen können nun automatisch erkannt und zugeordnet werden.
• Dokumentnummern können optional im SVWZ‑Feld gesucht werden, was die Trefferquote bei der automatischen Zuordnung erhöht.
• Der Zahlungszuordnungsreport berücksichtigt beide neuen Optionen.

Anpassung

Zahlungsverkehr‑Einrichtung – neue Felder:

• BAUSECURA Search Payments
• Search for Doc. No. in SVWZ

Kontoumsätze übertragen – Erweiterungen:

• Erkennung von BAUSECURA‑Markierungen und SVWZ‑Dokumentnummern
• Neue Logiken zur Belegnummernerkennung in End‑to‑End‑ID und SVWZ
• Automatische Zuordnung zu passenden Kundenposten

Neues Markerformat:

• Neu: //BREL_RNR00152//B
• Aufbau: //B <rechnr> //B
• Vorteile: symmetrisch, ohne Leerzeichen, positionsunabhängig

Auslesereihenfolge (Parsing):

1. Suche in End‑to‑End‑ID nach //B … //B
2. Falls nicht gefunden → Prüfung des Verwendungszwecks (SVWZ)

Beispiele

• End‑to‑End‑ID: … //BREL_RNR00152//B … → erkannt
• SVWZ: … Schadensmeldung Januar //BREL_RNR00152//B … → erkannt

Zusätzliche Hinweise

• BAUSECURA‑Funktion nur aktiv, wenn Modul RE4045 lizenziert ist.
• Optionen können in der Zahlungsverkehr‑Einrichtung separat aktiviert werden.
• Wenn BauSecura Zahlungen suchen aktiv ist, wird diese Logik vor anderen Kontierungsregeln angewendet (nicht kompatibel mit allen anderen Regeln).
• Der Suchbetrag muss exakt dem Zahlungsbetrag entsprechen → Ausgleich nur bei exakter Übereinstimmung.
• Wird die Belegnummer erkannt, werden keine weiteren Zuordnungslogiken ausgeführt.
• Der Debitorenposten‑Ausgleich erfolgt immer eins‑zu‑eins.

Mitgliederwesen

Wohnungsbauprämie Automatisierungen und neue Funktionen

Ausgangssituation

• Die vorhandene Spaltenanordnung war unstrukturiert.
• Die Aktion Prämie berechnen musste manuell ausgeführt werden.
• Bei der Ermittlung der Einzahlungen wurden Daten eines vorhandenen Ehepartners nicht automatisch berücksichtigt.
• Es gab keine Möglichkeit, ein komplettes Wirtschaftsjahr komfortabel zu löschen.

Auswirkung

Die Bedienung wird vereinfacht, da Berechnungen und Datenübernahmen nun automatisch erfolgen.
Die Übersichtlichkeit verbessert sich durch die neue Spaltenanordnung.
Anwender können Wirtschaftsjahre schneller und effizienter löschen.

Anpassung

• Spaltenanordnung: Die Spalten der Seite Wohnungsbauprämie wurden neu strukturiert.
• Automatische Berechnung:
  Die bisherige Aktion Prämie berechnen entfällt.
  Die Berechnung erfolgt nun automatisch
  • bei der Ermittlung der Einzahlungen
  • bei Änderungen im Feld bezahlt vom Mitglied
• Automatische Datenübernahme:
  Daten eines vorhandenen Ehepartners werden automatisch bei der Ermittlung der Einzahlungen berücksichtigt.
• Neue Aktion:
  Wirtschaftsjahr löschen – ermöglicht das Löschen aller Sätze eines Wirtschaftsjahres in einem Schritt.

Zusätzliche Hinweise

Durch die Automatisierung entfällt die manuelle Berechnung vollständig. Die neue Löschfunktion sollte vorsichtig verwendet werden, da sie alle Daten des ausgewählten Wirtschaftsjahres entfernt.

Berichte mit Excellayout erstellen

Ausgangssituation

Der Bericht Mitgliederbestand zum Stichtag existierte nur im RDLC‑Format.

Auswirkung

Anwenderinnen und Anwender hatten keine systemseitige Möglichkeit, die Berichtsdaten sofort in einer strukturierten Excel-Pivottabelle auszuwerten. Für detaillierte Analysen oder individuelle Aufbereitungen war bisher ein zusätzlicher manueller Aufwand erforderlich.

Anpassung

Der Bericht Mitgliederbestand zum Stichtag wurde um ein Excellayout erweitert. Dieses Layout generiert automatisch eine Pivottabelle, die sich optisch am bekannten RDLC-Bericht orientiert. Das neue Excellayout wurde systemseitig als Standard definiert.

Zusätzliche Hinweise

• Das RDLC-Layout bleibt vorläufig verfügbar und kann bei Bedarf manuell ausgewählt werden.
• Die erzeugte Pivottabelle kann individuell erweitert oder angepasst werden, um spezifische Auswertungen zu unterstützen.

Bericht mit Excellayout erstellen

Ausgangssituation

Der Bericht Mitgliederliste nach §30 GenG stand nur im RDLC-Layout zur Verfügung. Eine direkte Weiterverarbeitung der Berichtsdaten in Excel war damit nur eingeschränkt möglich.

Auswirkung

Die Berichtsdaten konnten nicht direkt in eine strukturierte Excel‑Tabelle ausgewertet werden.

Anpassung

Das RDLC‑Layout wurde entfernt. Die erzeugte Pivottabelle kann individuell erweitert oder angepasst werden, um spezifische Auswertungen zu unterstützen.

Bericht Mitgliederanteilsbewegung mit Excellayout

Ausgangssituation

Der Bericht Mitgliederanteilsbewegung stand nur im RDLC-Layout zur Verfügung. Eine direkte Weiterverarbeitung der Berichtsdaten in Excel war damit nur eingeschränkt möglich.

Auswirkung

Die Berichtsdaten konnten nicht direkt in eine strukturierte Excel‑Tabelle ausgewertet werden.

Anpassung

Der Bericht Mitgliederanteilsbewegung wurde durch ein Excellayout ersetzt. Dieses Layout generiert automatisch eine Pivottabelle, die sich optisch am bekannten RDLC-Bericht orientiert. Das neue Excellayout wurde systemseitig als Standard definiert.

Bericht Mitglieder-Bewegungen und Genehmigung mit Excellayout

Ausgangssituation

Der Bericht Mitglieder‑Bewegungen und Genehmigung stand nur im RDLC-Layout zur Verfügung. Eine direkte Weiterverarbeitung der Berichtsdaten in Excel war damit nur eingeschränkt möglich.

Auswirkung

Die Berichtsdaten konnten nicht direkt in eine strukturierte Excel‑Tabelle ausgewertet werden.

Anpassung

Der Bericht Mitglieder‑Bewegungen und Genehmigung wurde durch ein Excellayout ersetzt. Dieses Layout generiert automatisch eine Pivottabelle, die sich optisch am bekannten RDLC-Bericht orientiert. Das neue Excellayout wurde systemseitig als Standard definiert.

Bericht Bilanznachweis mit Excellayout

Ausgangssituation

Der Bericht Bilanznachweis stand bislang ausschließlich im RDLC-Layout zur Verfügung. Eine direkte Weiterverarbeitung der Berichtsdaten in Excel war damit nur eingeschränkt möglich.

Auswirkung

Die Berichtsdaten konnten nicht direkt in eine strukturierte Excel‑Tabelle ausgewertet werden.

Anpassung

Der Bericht Bilanznachweis wurde durch ein Excellayout ersetzt. Dieses Layout generiert automatisch eine Pivottabelle, die sich optisch am bekannten RDLC-Bericht orientiert. Das neue Excellayout wurde systemseitig als Standard definiert.

Prüfung „Kontakt gemeinsame Veranlagung“

Ausgangssituation

Das Feld Gemeinsame Veranlagung und das Feld Kontakt gemeinsame Veranlagung waren bislang weitgehend unabhängig voneinander sichtbar und steuerbar. Es bestand keine automatische Konsistenzprüfung, ob derselbe Kontakt bereits bei einem anderen Mitglied für die gemeinsame Veranlagung hinterlegt war.

Auswirkung

Die Aktivierung der gemeinsamen Veranlagung erfolgt automatisch, sobald ein Kontakt eingetragen wird. Fehlerhafte oder doppelte Zuordnungen von Kontakten zur gemeinsamen Veranlagung werden verhindert.

Anpassung

Das Feld Gemeinsame Veranlagung wurde hinter das Feld Kontakt gemeinsame Veranlagung verschoben und wird funktional von diesem gesteuert.

• Beim Eintragen eines Kontakts wird „Gemeinsame Veranlagung“ automatisch aktiviert.
• Beim Entfernen des Kontakts oder beim Umstellen der Art auf „Nichtveranlagungsbescheinigung“ wird der Schalter automatisch deaktiviert.

Bei der Eingabe einer Kontaktnummer erfolgt nun eine systemseitige Prüfung:

• Derselbe Kontakt kann nur bei genau einem Mitglied als Kontakt zur gemeinsamen Veranlagung hinterlegt werden.
• Ist der Kontakt bereits bei einem anderen Mitglied eingetragen, erfolgt eine Fehlermeldung.

RELion Dokumente

Erweiterung der Infobox um Dokumententyp

Ausgangssituation

Im Laufe der Zeit wurde die Anzahl der Archive zur Verbesserung der Übersicht angepasst.
Um dennoch eine ausreichende Zuordnung der Dokumente zu den jeweiligen Kategorien sicherzustellen, wurde mit Version 12.27 das Feld Dokumententyp eingeführt.
Bei der Infobox wurden die Datensätze jedoch weiterhin ausschließlich über das Archiv kategorisiert, wodurch die erweiterte Zuordnung über den Dokumententyp nicht genutzt wurde.

Auswirkung

Wenn Anwender eine Kategorisierung über den Dokumententyp bevorzugten, konnten sie in der Infobox dennoch nur eine Auswahl über das Archiv treffen. Um die genaue Anzahl der Dokumente eines Dokumententyps zu ermitteln, war eine nachträgliche manuelle Filterung erforderlich.

Anpassung

Die Infobox wurde um das Feld Dokumententyp erweitert.
In der RELion Dokument‑Einrichtung kann unter Infobox Organisation nun ausgewählt werden, welche Ansicht für die Infobox genutzt werden soll:

• Nur Archivname
• Nur Dokumententyp
• Archivname und Dokumententyp

Zusätzliche Hinweise

Nur Archivname	Es werden nur Einträge angezeigt, die einem gültigen Archiv zugeordnet sind.
Nur Dokumententyp	Es werden nur Einträge angezeigt, die einen Wert im Feld Dokumententyp besitzen.
Archivname und Dokumententyp	Es werden auch Dokumente gezählt, die ein Archiv haben, aber keinen Dokumententyp.

Für jede Ansicht werden die Dokumente in der Infobox kategorisiert und mit Anzahl angezeigt.
Ein Klick auf die Zahl führt direkt in die RELion Dokument‑Recherche mit der passenden Vorfilterung.

Die Gesamtzahl der archivierten Dokumente (Archiv oder Dokumententyp) kann über den Eintrag Dokumente aufgerufen werden.

Die Ansicht kann zusätzlich über die Tabellenparameter beeinflusst werden.
Wenn man alle Einträge eines Datensatzes sehen möchte – unabhängig von Archiv oder Dokumententyp – kann dies über den Pfeil bei RELion Dokumente → Recherchieren erfolgen.

Mietanpassung

Erweiterung DataSet Manuelle Mietanpassung

Ausgangssituation

Im Bericht Manuelle Mietanpassung stand im Bereich RentAdjustmentUnitContractSumAmounts bisher nur eine begrenzte Anzahl an Feldern zur Verfügung. Werte zur alten (bisherigen) MwSt., zu bisherigen Brutto‑Beträgen sowie zu Differenzbeträgen zwischen neu und alt wurden nicht ausgewiesen.

Auswirkung

Durch die fehlenden Felder war eine transparente Nachvollziehbarkeit der Änderungen bei manuellen Mietanpassungen – insbesondere im Zusammenhang mit der MwSt.-Änderung und den daraus resultierenden Netto- und Brutto-Differenzen – nicht vollständig möglich.

Anpassung Das DataSet wurde um folgende Felder erweitert:

SumOfVATOld	Darstellung der bisherigen Mehrwertsteuer (MwSt. vor Stichtag).
SumOfAmountInclVATOld	Darstellung des bisherigen Gesamtbetrags brutto (Brutto vor Stichtag).
SumOfAmountDiff	Differenz zwischen neuem und altem Gesamtbetrag netto.
SumOfVATDiff	Differenz zwischen neuer und alter MwSt.-Summe.
SumOfAmountInclVATDiff	Differenz zwischen neuem und altem Gesamtbetrag brutto.

Geplante Instandhaltung

Projektplanzeilen Karte – Infobox Archivierung einblenden

Ausgangssituation

Die Infobox RELion Dokumente fehlte auf der Projektplankarte.

Auswirkung

Eine Archivierung war nicht direkt möglich.

Anpassung

Die Infobox wurde integriert.

Verwalterhonorar

Verwalterhonorar Dimensionen - RE Einrichtung

Ausgangssituation

Die Dimensionen für Verwalterhonorar in Bezug auf Erlöse und Aufwand wurden bisher in der FIBU-Einrichtung gepflegt.

Auswirkung

Die Einrichtung für Dimensionen musste an verschiedenen Stellen stattfinden.

Anpassung

Die Dimensionen für Verwalterhonorar (Erlöse und Aufwand) werden zukünftig aus der FIBU-Einrichtung entfernt. Die Felder wurden in das Inforegister Dimensionen in der RE Einrichtung integriert. Dies erleichtert die Verwaltung und sorgt für eine einheitliche Struktur.

Um Nachpflegearbeit für den Anwender zu vermeiden, wurde eine Synchronisierung eingebaut, so dass die Werte in den Feldern, die bereits in der FIBU Einrichtung gefüllt wurden vom System automatisch in die Felder der RE Einrichtung übertragen werden.

Zusätzlicher Hinweise

Für eine Übergangszeit von ca. drei Monaten werden die Felder in der Fibu Einrichtung noch vorhanden sein.

Zahlungsverkehr

Sollstellungs‑Zahlschein für Vertrag ermöglichen

Ausgangssituation

Bisher war es ausschließlich möglich, Sollstellungs‑Zahlscheine aus einem einzelnen Einheitenvertrag heraus zu erstellen. Bei Verträgen, denen mehrere Einheitenverträge zugeordnet sind, konnte kein übergeordneter Zahlschein für den Gesamtvertrag erzeugt werden. Eine einfache, zentrale Erstellung eines einheitlichen Zahlscheins für alle zugehörigen Einheiten war damit nicht möglich.

Auswirkung

Durch die Erweiterung kann der Sollstellungs‑Zahlschein nun direkt erstellt werden:

• aus der Vertragskarte oder
• aus der Vertragsliste (nur debitorische Verträge)

Der erzeugte Zahlschein enthält:

• den Gesamtbetrag aller Sollstellungsbeträge der dem Vertrag zugeordneten Einheitenverträge
• die Zahlungsreferenz in Form des Zahlungsschlüssels des Vertrags (V‑Nummer)

Dies erleichtert die Verarbeitung insbesondere bei Verträgen, die mehrere Einheiten umfassen, und gewährleistet einheitliche Zahlscheine für die Mietrechnung.

Anpassung

Die Funktion Debit Position Payment Form wurde in der Vertragskarte und der Vertragsliste ergänzt. Sie steht allen Österreich‑Kunden mit entsprechender Berechtigung zur Verfügung.

Beim Aufruf wird automatisch:

• die Summe aller relevanten Sollstellungen des Vertrags ermittelt
• die Zahlungsreferenz aus dem Zahlungsschlüssel des Vertrags gesetzt
• die Ausgabe der Zahlscheine gestartet

Die Funktion verhält sich analog zur bestehenden Erstellung des Sollstellungs‑Zahlscheins aus dem Einheitenvertrag – mit Ausnahme der oben beschriebenen Abweichungen.

Zusätzliche Hinweise

• Die Funktion steht ausschließlich für die Länderversion Österreich zur Verfügung.
• Die Sichtbarkeit der Aktion hängt von der Vertragsart (debitorisch) und den Berechtigungen ab.
• Die Anzahl der auszugebenden Zahlscheine kann beim Aufruf gewählt werden.

Rücklastschrift erkennen, wenn End-To-End-Id nicht eindeutig ist

Ausgangssituation

Bei der Verarbeitung von Rücklastschriften wurde die zugehörige Zahlung über die End-To-End-ID ermittelt. Wenn die End‑to‑end‑ID einer Lastschrift nicht eindeutig war, konnte das System den betroffenen Zahlungsposten nicht korrekt zuordnen. Stattdessen wurde der erstbeste Zahlungsposten gefunden. Dadurch trat beim automatischen Erstellen einer Rücklastschrift eine Betragsdifferenz auf und die Fehlermeldung wurde angezeigt:

„Der gesamte Zahlbetrag … ist größer als der Rücklastschriftbetrag … Bitte wählen Sie einen anderen Zahlungsposten oder lösen Sie den Vorgang manuell auf.“

Auswirkung

Der Übertrag des Kontoauszugs wurde abgebrochen. Die Verarbeitung konnte nicht fortgesetzt werden, und der Benutzer musste manuell eingreifen.

Anpassung

Es wurde eine Vorabprüfung der Betragskonsistenz implementiert. Wenn der Betrag nicht zum gefundenen Zahlungsposten passt:

• wird keine Rücklastschrift erzeugt,
• es wird stattdessen ein Fehlereintrag im Aktionsprotokoll erstellt,
• die Kontoauszugsübertragung wird nicht mehr unterbrochen.

Fehlermeldung im Aktionsprotokoll:

„#RÜCKLASTSCHRIFT/GVC MS03 kann nicht automatisch in der Zeile … (Buch.-Blattvorlagenname: … / Buch.-Blattname: …) - Kontoauszugszeile … (RE Ausz. Import Laufnr.: … / Auszugsnr.: …) erstellt werden. Bitte lösen Sie den Vorgang manuell auf.“

Zusätzlich wird der Betrag der Lastschrift-Gebühren überprüft. Wenn der Betrag der Gebührenrechnung aus dem Bank Buch.-Blatt mit dem Lastschrift-Gebührenbetrag aus der Kontoauszugszeile nicht übereinstimmt, wird noch ein zusätzlicher Fehler dem Aktionsprotokoll hinzugefügt.

„#RÜCKLASTSCHRIFT/GVC MS03 Der Gebührenbetrag für die Rücklastschrift ist nicht stimmig. Zeile … (Buch.-Blattvorlagenname: … / Buch.-Blattname: …) - Kontoauszugszeile … (RE Ausz. Import Laufnr.: … / Auszugsnr.: …).“

Zusätzliche Hinweise

Die Kontoauszugsverarbeitung läuft nun stabil weiter, auch bei uneindeutigen End‑to‑End‑IDs. Rücklastschriften, die nicht automatisch erzeugt werden können, sind klar im Aktionsprotokoll ersichtlich. Ein manueller Prüfschritt durch den Anwender ist weiterhin notwendig, wenn die automatische Zuordnung aufgrund uneindeutiger Daten nicht möglich ist.

Vertragsverwaltung

Vertragsliste – Satzmarken

Ausgangssituation

In der Page Vertragsübersicht reagierte ausschließlich der Bericht Vertragsschreiben auf die Übergabe und Auswertung von Satzmarken. Der Bericht Vertragsliste unterstützte diese Funktion bisher nicht.

Auswirkung

Satzmarken konnten im Bericht Vertragsliste nicht genutzt werden. Eine einheitliche Nutzung der Satzmarken-Funktionalität über beide Berichte hinweg war nicht möglich.

Anpassung

Der Beircht Vertragsliste wurde erweitert und reagiert nun analog zum Bericht Vertragsschreiben auf übergebene Satzmarken.

Satzmarken werden korrekt erkannt, verarbeitet und in der Ausgabe berücksichtigt. Die Bedienlogik ist damit zwischen beiden Berichten vereinheitlicht.

Fehlerbehebung

Stammdaten

Debitoren-Nummernserie wird unnötig verbraucht (globaler Adressstamm)

Ausgangssituation

Bei aktiver Synchronisation globaler Adressen und Debitorennummern in einem Mandanten wurden beim Anlegen der Debitoren über eine Vorlage mit lokaler Nummernserie fälschlicherweise zusätzliche lokale Nummern (neben den globalen) vergeben.

Auswirkung

• Ungewollte Nummernvergabe in der lokalen Nummernserie.
• Abweichendes Verhalten gegenüber der Kreditorenlogik.

Anpassung

• Debitorenvorlagen mit einer lokalen Nummernserie sind beim Anlegen von Debitoren (bei aktiver Synchronisation der Nummern) nicht mehr erlaubt. Eine Fehlermeldung wird in einem solchen Fall anzeigt.
• Anzeige der Nummernserie in der Übersicht- und Auswahlseite für Debitoren- und Kreditorenvorlagen.

Zusätzliche Hinweise

In jedem Mandanten, bei dem die Synchronisation der Adressen und der Debitorennummern eingeschaltet ist, wäre sinnvoll, die Debitorenvorlagen auf die Angabe der lokalen Nummernserie zu prüfen und ggf. das Feld Nummernserie zu leeren. Die Anzeige der Nummernserie in der Vorlagenübersicht und -auswahl soll die Prüfung erleichtern.

Buchhaltung

Fehler nicht anrechenbare Vorsteuer bei Berichtigungsobjekte im Beobachtungszeitraum

Ausgangssituation

Für ein zum 01.12.2025 in den Berichtigungszeitraum aufgenommenes Berichtigungsobjekt war die Option Rechnungen zulässig aktiviert. Dadurch konnten dem Objekt weitere Einkaufsrechnungen zugeordnet werden, für die weiterhin die ursprüngliche Quote der nicht anrechenbaren Vorsteuer hätte gelten müssen. Vor der Aufnahme wurden alle relevanten Posten korrekt gebucht.

Auswirkung

Neue Einkaufsrechnungen im Berichtigungszeitraum wurden ohne korrekte Anwendung der Vorsteuerkürzungsquote verarbeitet. Dadurch wurde die ursprüngliche Kürzung rückgängig gemacht und die Funktion Nicht anrechenbare Vorsteuer konnte nicht mehr korrekt arbeiten.

Anpassung

• Die gültige Vorsteuerkürzungsquote wird korrekt aus den §15a-Vorsteuerdaten übernommen.
• Bereits korrekt gebuchte Kürzungen werden nicht rückgängig gemacht.
• Posten werden wieder ordnungsgemäß geprüft und angepasst.
• Die Funktion berücksichtigt nun alle erforderlichen Einträge.

Bericht „Abgrenzungsbuchung einstellen“ erstellt nach jeder Seite eine Leerseite

Ausgangssituation

Bei der Ausführung des Berichts Abgrenzungsbuchung einstellen wurde nach jeder gedruckten Seite automatisch eine zusätzliche Leerseite erzeugt. Dies führte zu unnötig umfangreichen Ausdrucken und erschwerte sowohl die Lesbarkeit als auch die Weiterverarbeitung des Berichtsergebnisses.

Auswirkung

• unnötig lange Ausdrucke
• zusätzlicher Papierverbrauch
• erschwerte Lesbarkeit
• unübersichtlicher Seitenfluss

Anpassung

Die Layout‑ und Seitenlogik wurden korrigiert. Der Bericht erzeugt keine Leerseiten mehr und wird wieder seitenrichtig ausgegeben.

Anzeige des Kontennachweises korrigieren

Ausgangssituation

Durch Änderungen im Business Central-Standard wurden zusätzliche Variablen erwartet.
Ein überschriebenes Feld führte dazu, dass das gewünschte Schema nicht mehr geladen wurde.

Auswirkung

Durch das Überschreiben des mitgegebenen Werts wird das beabsichtigte Schema nicht mehr korrekt geladen. In der Folge erscheint der Kontennachweis falsch oder unvollständig, da die gewünschte Schemaauswahl nicht mehr wirksam ist.

Anpassung

Der Aufruf wurde technisch angepasst, sodass wieder das korrekte Schema geladen wird.

Ausgleich Buchen im Sachpostenausgleich

Ausgangssituation

Beim Sachpostenausgleich Ausgleich Buchen trat ein Fehler auf, der dazu führte, dass das System in eine Dauerschleife geriet. Infolge dessen wurde die folgende Meldung angezeigt:

„Ihre Änderungen können jetzt nicht gespeichert werden, da ein Datensatz in der Tabelle ‚Sachposten‘ in einer Transaktion aktualisiert wird, die von einer anderen Sitzung ausgeführt wird. Sie müssen warten, bis die andere Transaktion abgeschlossen ist, was eine Weile dauern kann. Versuchen Sie es später erneut.“

Auswirkung

Der Sachpostenausgleich konnte nicht abgeschlossen werden. Buchungen blieben ausstehend, was zu Verzögerungen im Prozess führte.

Anpassung

Der Fehler wurde behoben. Das System verarbeitet den Sachpostenausgleich nun korrekt. Sachposten lassen sich wieder ausgleichen und buchen, ohne dass eine Dauerschleife entsteht.

Mietverwaltung

Sollstellungsdifferenz – Startdatum ändern in Sollstellungszeile bringt falschen Hinweis

Ausgangssituation

In einem Mietvertrag liegt der Vertragsbeginn vor dem Verwaltungsbeginn und vor dem Datum RELion Sollstellung ab. Wird das Startdatum einer gebuchten Sollstellungszeile auf ein Datum vor diesem Wert geändert, erscheint ein Hinweis auf eine Sollstellungsdifferenz.
Der Bericht Änderungen überprüfen erkennt jedoch korrekt keine Differenz, da der Berechnungszeitraum erst ab RELion Sollstellung ab beginnt.

Auswirkung

• Es wurde eine Differenz angezeigt, obwohl fachlich keine vorlag.
• Der Hinweis führte zu Verwirrung, da der Bericht korrekt keine Differenz meldete.

Anpassung

Die Logik wurde erweitert:
Es wird kein Hinweis mehr ausgegeben, wenn:

• das geänderte Startdatum vor RELion Sollstellung ab liegt und
• der Zeitraum somit außerhalb des Differenzberechnungsfensters liegt.

Aufruf der Debitorenposten aus der Sollstellungsübersicht dauert zu lange

Ausgangssituation

Beim Aufruf der Debitorenposten aus der Sollstellungsübersicht heraus trat eine deutlich verlängerte Ladezeit auf.

Auswirkung

Es kam zu Verzögerungen im täglichen Arbeitsablauf.

Anpassung

Zur Optimierung wurde in der SQL‑Datenbank ein zusätzlicher Schlüssel implementiert, der gezielt die für den Aufruf relevanten Felder indexiert. Durch diesen technischen Eingriff können die Debitorenposten nun erheblich schneller geöffnet werden, da die Datenbankabfrage effizienter durchgeführt wird.

Neuvermietungsassistent - Anlage neuer Kontakt - Fehler bei Geschäftsbeziehung

Ausgangssituation

Bei der Anlage eines neuen Kontakts über den Neuvermietungsassistenten wird das Feld Geschäftsbeziehung nicht korrekt gefüllt.

Obwohl im Assistenten die Kontaktverknüpfung Debitor ausgewählt wird, setzt das System auf der Kontaktkarte den Wert der Geschäftsbeziehung fälschlicherweise auf keine.

Auswirkung

Durch die fehlerhafte Befüllung der Geschäftsbeziehung entsteht eine inkonsistente Datenbasis zwischen Kontakt, Debitor und den weiteren vertragsrelevanten Prozessen.

Anpassung

Das Systemverhalten wurde korrigiert. Wird im Neuvermietungsassistenten ein neuer Kontakt mit der Verknüpfung „Debitor“ angelegt, so wird nun auf der Kontaktkarte automatisch das Feld Geschäftsbeziehung mit dem Wert „Debitor“ befüllt.

Aktionsprotokoll Sollstellungslauf lückenhaft – Leerstände werden nicht erkannt

Ausgangssituation

Der reguläre Sollstellungslauf erkannte Lücken in Sollstellungszeilen nicht, wenn mehrere Leerstände hintereinander auftraten (innerhalb 3‑Monats‑Frist).

Auswirkung

• Verträge konnten unvollständigen Buchungsstoff enthalten.
• Fehlerhafte oder fehlende Sollstellungen blieben unentdeckt.

Anpassung

Die Prüfung wurde erweitert:
Auch mehrere aufeinanderfolgende Leerstände werden nun korrekt als Lücke identifiziert.

Zusätzliche Hinweise

Keine Prüfung für Verträge, die >3 Monate zurückliegen und bereits ein Vertragsende haben.

Sondereigentumsverwaltung

Lastschriftmandat wird falsch angelegt

Ausgangssituation

Bei der Anlage von Lastschriftmandaten wurde die Gläubiger‑ID eines SEV‑Vertrags übernommen, selbst wenn dieser bereits beendet war.

Auswirkung

Es konnten fehlerhafte Lastschriftmandate entstehen, da ein ungültiger SEV‑Vertrag herangezogen wurde.

Anpassung

• Es wird nur noch ein aktiver SEV‑Vertrag berücksichtigt.
• Beendete Verträge liefern keine Gläubiger‑ID mehr.
• Die Gläubiger‑ID wird nur gesetzt, wenn das Arbeitsdatum im Vertragszeitraum liegt.

Serienbrief mit Barcode – fehlende Indexwerte im Umlaufdokument

Ausgangssituation

Bei der Erstellung eines Serienbriefs mit Barcode wird automatisch ein Eintrag in Dokumente im Umlauf erzeugt. Dieser Eintrag beinhaltet jedoch nicht die Werte für Objekt Nr. sowie Eigentümer/Mieter im Bereich Indexe.

Die erforderlichen Informationen liegen in der Tabelle Datenzwischenspeicher korrekt vor, werden jedoch nicht in das Umlaufdokument übernommen.

Auswirkung

Im Umlaufdokument fehlen die Indexinformationen, die für die automatische Archivierung benötigt werden. Dadurch erfolgt beim Einscannen keine automatische Zuordnung und somit keine automatisierte Archivierung des Dokuments. Dies führt zu manuellem Aufwand, potenziellen Verzögerungen und einem erhöhten Fehlerpotenzial bei der Dokumentenablage.

Anpassung

• Die Logik zur Befüllung der Felder ObjectNr sowie Eigentümer/Mieter wurde angepasst.
• Die in der Tabellen Datenzwischenspeicher vorhandenen Werte werden nun korrekt in das erzeugte Umlaufdokument übernommen.
• Die Indexe stehen vollständig und in der erwarteten Struktur zur Verfügung.
• Die automatische Archivierung nach dem Einscannen wird damit wieder ordnungsgemäß ausgelöst.

Vertragsverwaltung

Verwaltungsbeginn am Objekt nachträglich ändern – Fehlermeldung korrigiert

Ausgangssituation

Bei der Änderung des Verwaltungsbeginns eines Objekts wurde eine Systemmeldung ausgegeben, deren Formulierung nicht korrekt war. Zusätzlich enthielt die fachliche Prüfung auf die Einheitenstämme Unstimmigkeiten, wenn Änderungen des Verwaltungsbeginns am Objekt vorgenommen wurden.

Auswirkung

• Verwirrende Meldungen
• Unvollständige Validierung
• Änderungen konnten blockiert sein

Anpassung

• Meldungstext korrigiert
• Logik zur Prüfung der Einheitenstämme überarbeitet
• Konsistente Prüfung zwischen Objekt- und Einheitenzeitraum

Bericht „Basisvertrag für Word Gestaltung“ liefert falsche Adresse

Ausgangssituation

Im Bericht Basisvertrag für Word Gestaltung wurden Empfängerfelder immer mit der Kontaktadresse des Mieters gefüllt – auch wenn eine abweichende Vertragsadresse existierte.

Auswirkung

• Falsche Adressen in Word‑Dokumenten
• Potenzielle Fehlzustellungen
• Unstimmige Dokumente im Rechts- und Kommunikationsprozess

Anpassung

Die Adresslogik wurde korrigiert:

• Wenn eine Vertragsadresse vorhanden ist → wird diese verwendet
• Nur wenn keine Vertragsadresse existiert → Kontaktadresse

Betroffene Dataset‑Felder:

• REVertragWordTab_EmpfaengerAdresse1
• REVertragWordTab_EmpfaengerAdresse2
• REVertragWordTab_EmpfaengerAdresse4
• REVertragWordTab_EmpfaengerAdresse5
• REVertragWordTab_EmpfaengerAdresse6
• REVertragWordTab_EmpfaengerAdresse7
• REVertragWordTab_EmpfaengerAdresse8

Adressfelder 6–8 in Vertragsadresse nur 50 statt 100 Zeichen

Ausgangssituation

Die Felder 6–8 der Vertragsadresse waren auf 50 Zeichen begrenzt, während Felder 1–5 100 Zeichen hatten. Längere Inhalte führten zu Fehlern.

Auswirkung

• Datenverlust
• Fehlermeldungen
• unterbrochene Datenübernahmen

Anpassung

Die Felder 6–8 werden auf 100 Zeichen erweitert. Die physische Umsetzung erfolgt nach einer dreimonatigen Sperrfrist.

Zusätzliche Hinweise

Bis zur physischen Anpassung besteht weiterhin die 50‑Zeichen‑Begrenzung.

Erbbaurechtsvertrag – Feld „Bearbeiter“ einblendbar machen

Ausgangssituation

Das Feld Bearbeiter war in der Karte Erbbaurechtsvertrag nicht über Personalisieren einblendbar.

Auswirkung

• Anwender konnten das Feld nicht anzeigen oder pflegen.
• Erschwerte Übersicht über Zuständigkeiten.

Anpassung

Das Feld Bearbeiter kann nun über Personalisieren ein‑ und ausgeblendet werden.

Zusätzliche Hinweise

• Keine fachlichen Änderungen, reine UI‑Verbesserung.
• Daten bleiben unverändert.

Mietsicherheit wird über Neuvermietungsassistent nicht korrekt angelegt

Ausgangssituation

Bei der Anlage von Mietsicherheiten über den Neuvermietungsassistenten wurden die Felder Eigentümer/Mieter-Kennzeichen sowie Objekt im erzeugten Datensatz nicht automatisch gefüllt. Die manuelle Erfassung von Mietsicherheiten war von diesem Verhalten nicht betroffen.

Auswirkung

Durch die fehlende Befüllung der Felder kam es in nachfolgenden Verarbeitungsschritten, insbesondere in der Kautionsverwaltung, zu Fehlfunktionen und inkonsistenten Datenbeständen.

Anpassung

• Die Datenlogik im Neuvermietungsassistenten wurde angepasst.
• Die Felder Eigentümer/Mieter-Kennzeichen und Objekt werden nun bei der Anlage von Mietsicherheiten automatisch und vollständig befüllt.
• Die erzeugten Datensätze stehen damit konsistent für alle nachgelagerten Prozesse zur Verfügung.

Zusätzliche Hinweise

Bereits zuvor manuell erfasste Mietsicherheiten sind nicht betroffen. Für bestehende Datensätze, die vor der Anpassung fehlerhaft erzeugt wurden, kann eine manuelle Nachpflege erforderlich sein.

Betriebskostenabrechnung

BK-Abrechnung – SEPA Mandatsschreiben mit falscher Adressierung

Ausgangssituation

Bei der Erstellung von SEPA‑Mandatsschreiben kam es in bestimmten Verarbeitungsszenarien zu einer fehlerhaften Adressbildung. Wurden Belege übergreifend für WEG‑Objekte und Mietobjekte gemeinsam erzeugt, blieb der Zusatztext „WEG 4711 vertreten durch …“ nach Verarbeitung der WEG‑Abrechnungen bestehen und wurde fälschlicherweise auch für nachfolgende Mietabrechnungen verwendet. Bei getrennter Verarbeitung trat der Fehler nicht auf.

Auswirkung

Endanwender erhielten in seltenen Fällen fehlerhafte SEPA‑Mandatsschreiben mit falscher Rücksendeadresse.

Anpassung

Adressdaten werden nun für jede Abrechnung kontextabhängig neu aufgebaut.

Erstellen BK‑Abrechnung – Meldung „Objektübergreifender Vertrag“

Ausgangssituation

Beim Holen der Abrechnungszeilen trat bei Verwendung Ausnahmen zu Instandhaltungsgrenzen, die auf prozentualen Sollstellungsbeträgen basieren, eine Fehlermeldung auf. Die Meldung “unter Mietvertrag XY gibt es Einheiten aus unterschiedlichen Objekten” wurde als Aktionsprotokoll mit Typ Fehler erstellt und die weitere Verarbeitung abgebrochen.

Auswirkung

Abrechnungen mit korrekt eingerichteten Ausnahmen konnten nicht durchgeführt werden.

Anpassung

Eine Prüffunktion meldete einen Fehler, den es nicht gab, dies wurde korrigiert.

Durch diese Änderung wird die Verarbeitung von einheitenbezogenen Vertragsausnahmen innerhalb von Instandhaltungsgrenzen wieder korrekt durchgeführt.

Zusätzliche Hinweise

Die Änderung wirkt ausschließlich auf die Prüflogik. Bereits begonnene Abrechnungen können mit Abrechnungszeilen holen fortgesetzt werden.

BK-Abrechnung – Rundungsfehler bei Hochrechnung von Verteilfaktoren

Ausgangssituation

Bei der Berechnung des Gesamtfaktors in Hochrechnungszeilen für die zeitanteilige Gewichtung von Faktoränderungen innerhalb der Abrechnungsperiode trat ein Rundungsfehler auf.

Auswirkung

Die fehlerhafte Berechnung führte zu inkorrekten Hochrechnungen in der Nebenkostenabrechnung. Dies führte zu Ungenauigkeiten bei der Umlage der Kosten.

Anpassung

Die Berechnungslogik wurde korrigiert.

Zusätzliche Hinweise

Bei den betroffenen Abrechnungen muss Abrechnung berechnen wiederholt werden, anschließend kann mit den nachfolgenden Schritten wie. z. B. Ausnahmen anwenden und Belege erzeugen weitergearbeitet werden.

Wirtschaftsplan

Abrechnungs- und Wirtschaftsplanzeilen lassen sich auch nach erfolgter Berechnung löschen

Ausgangssituation

Nach der Berechnung einer Abrechnung werden die Bearbeitungsaktionen korrekt deaktiviert. Die Funktion Zeilen löschen bleibt jedoch aktiv.

Auswirkung

Benutzer können weiterhin Löschaktionen ausführen, was zu inkonsistenten Zuständen und fehlerhaften Meldungen führt. Dies beeinträchtigt die Benutzerfreundlichkeit und kann zu unerwarteten Datenänderungen führen.

Anpassung

• Die Löschung einzelner Datensätze prüft den Bearbeitungsstatus der darüber liegenden Abrechnung bzw. Wirtschaftsplan.
• Löschaktion in der Zeile.
• Deaktivierung der Aktionen Zeilen löschen, Zeilen holen etc. abhängig vom Bearbeitungsstatus.

Instandhaltung

Verkaufsgutschrift-Berichte reagieren nicht auf Farbeinstellungen

Ausgangssituation

In den Berichten Verkaufsgutschrfit und gebuchte Verkaufsgutschrift wurde die Zeilenhinterlegung aus RE Einrichtung falsch angewendet – erste Zeile wurde wie zweite gefärbt und umgekehrt.

Auswirkung

• fehlerhafte Optik der Berichte
• schlechtere Lesbarkeit
• Abweichung vom RE‑Layout

Anpassung

Die Logik zur Zeilenhinterlegung wurde korrigiert. Berichte reagieren nun wieder korrekt auf RE Einrichtung.

Bericht „Eink.-Mitteilung über Rechnungskürzung“ druckt keine Fußzeilen

Ausgangssituation

Beim Druck des Berichts Eink.-Mitteilung über Rechnungskürzung wurden die im Layout vorgesehenen Fußzeilen nicht ausgegeben. Der Bericht wurde unabhängig von Drucker, Vorschau oder Export ohne Fußzeilen erzeugt.

Auswirkung

Verbindliche Hinweise, ergänzende rechtliche Angaben oder interne Kennzeichnungen in der Fußzeile fehlten vollständig. Dadurch konnte es zu Unvollständigkeiten in der Kommunikation mit Lieferanten oder internen Prozessstörungen kommen.

Dokumente entsprachen nicht der vorgesehenen Formvorgabe.

Anpassung

Drucklogik korrigiert: Fußzeilen werden wieder vollständig ausgegeben, unabhängig von der Ausgabeart.

Heizkostendatenaustausch

Verbesserung der HK-Einlesung

Ausgangssituation

Bei der Einlesung von D‑Sätzen für Heizkosten kam es im bisherigen Verhalten zu einer Fehlermeldung, wenn für denselben Abrechnungszeitraum mehrere D‑Satz‑Einlesungen mit identischem Kostenschlüssel vorhanden waren.

Die Meldung „Der Datensatz existiert bereits in der Tabelle Abrechnung Detailzeilen…“ war für Endanwender nicht nachvollziehbar und ließ keinen Rückschluss darauf zu, wie das Problem zu beheben ist.

Auswirkung

Durch die unpräzise Fehlermeldung wurde der Verarbeitungsvorgang abgebrochen. Endanwender konnten nicht erkennen, dass eine doppelte D‑Satz‑Einlesung vorlag. Ein Fortführen der Abrechnung war ohne technisches Eingreifen nicht möglich.

Anpassung

Die Verarbeitung doppelt vorhandener D‑Sätze wurde überarbeitet:

• Duplikate werden nun nicht mehr zu einem Abbruch der Verarbeitung führen. Stattdessen wird ein Hinweis im Aktionsprotokoll ausgegeben.
• Der Hinweis informiert eindeutig, dass Heizkostenzeilen mit identischem Kostenschlüssel mehrfach vorhanden sind.
• In der D‑Satz‑Anzeige der Datenpool-Infobox wurden zusätzliche Informationsfelder eingeblendet:
  • Einblendung des Feldes Key Type of costs
  • Sichtbarmachung der fünf gelb markierten Zusatzfelder aus der Anforderung
  • Nicht benötigte Felder wurden auf visible = false gesetzt
  • Positionierung der neuen Felder am rechten Rand

Diese Maßnahmen verbessern die Transparenz und ermöglichen die Fortsetzung der Verarbeitung, auch wenn doppelte Einlesungen vorhanden sind.

Zusätzliche Hinweise

Der Hinweis im Fehlerprotokoll dient als unterstützende Information. Die Bereinigung doppelter D‑Satz‑Einlesungen im Datenbestand bleibt weiterhin empfohlen.

Berichte

AT-Zahlschein DINA4 5052373 - Anpasssung der Schriftart auf OCR B

Ausgangssituation

Der AT‑Zahlschein wurde bisher standardmäßig mit der Schriftart „ClearRead Mono“ ausgeliefert. Diese Schriftart steht insbesondere in SaaS‑Umgebungen nicht mehr zur Verfügung.

Auswirkung

Aufgrund der fehlenden Verfügbarkeit der bisherigen Schriftart konnte der Bericht in betroffenen Umgebungen nicht mehr korrekt erzeugt oder dargestellt werden.

Anpassung

• Der AT‑Zahlschein wurde um die Schriftart OCR B erweitert.
• Die Ausgabe des Berichts erfolgt nun standardmäßig mit OCR B.
• Die bisherige Variante mit ClearRead Mono wird weiterhin parallel bereitgestellt und kann alternativ verwendet werden.

Zusätzliche Hinweise

Bei kundenseitigen Anpassungen oder eigenen Berichtvarianten sollte geprüft werden, ob dort ebenfalls auf OCR B umgestellt werden kann, um Kompatibilitätsprobleme zu vermeiden.

Mitgliederwesen

Mitglieder Konto Teilkündigung prüfen

Ausgangssituation

Bei der Verarbeitung von Teilkündigungen wurde nicht das in den Satzungsparametern unter GGH Teilkündigung hinterlegte Konto verwendet. Stattdessen wurde fälschlicherweise das Konto aus dem Parameter GGH beendetes Mitglied herangezogen. Dies führte dazu, dass Buchungen und Zuordnungen nicht korrekt gemäß den vorgesehenen fachlichen Vorgaben verbucht wurden.

Auswirkung

• Teilkündigungen wurden mit einem falschen Sachkonto verarbeitet.
• Es entstand eine potenzielle Abweichung in der bilanziellen Darstellung und der späteren Auswertbarkeit.
• Nachgelagerte Fachprozesse (z. B. Abschluss, Berichte, Rückstellungen) konnten dadurch beeinträchtigt werden.

Anpassung

• Die Kontoermittlung für Teilkündigungen wurde korrigiert.
• Ab sofort wird zuverlässig das in den Satzungsparametern definierte Konto aus GGH Teilkündigung verwendet.
• Das Konto GGH beendetes Mitglied wird nur noch bei vollständigen Beendigungen berücksichtigt.

RELion Dokumente

Korrektur der fehlerhaften Indexeinträge bei der Archivierung von Vertragsschreiben

Ausgangssituation

Die Berichtsfunktion zur Archivierung mehrerer Vertragsschreiben, ausgeliefert mit Release 30, erzeugte bei der Übergabe an das Archivierungssystem AAk teilweise fehlerhafte Indexeinträge. Bei mehreren archivierten Datensätzen wurde ausschließlich der zuletzt verarbeitete Datensatz korrekt indiziert. Die Datenfelder 17, 20 und 26 fehlten in den erzeugten Indexdaten.

Auswirkung

• Bei Mehrfacharchivierungen von Vertragsschreiben wurden unvollständige oder fehlerhafte Indexeinträge erzeugt.
• Dokumente konnten daher nicht korrekt an das Archivsystem AAk übergeben werden.
• Es bestand das Risiko, dass Kundenkorrespondenz nicht archiviert wird.

Anpassung

• Die Archivierungslogik wurde überarbeitet.
• Durch diese Änderung wird jeder Vertrags- und Einheitensatz eindeutig und unabhängig vom zuvor gesetzten Filter verarbeitet.
• Die Indexfelder werden korrekt erzeugt und vollständig an AAk weitergegeben.

Zusätzliche Hinweise

Bei Einzelaufruf der Berichts Vertragsschreiben, also für genau einen Vertrag, war die Archivierung bisher schon korrekt, es betrifft ausschließlich den Aufruf über mehrere Verträge gleichzeitig. Die Archivierung kann nach Integration der Korrektur wie gewohnt ausgeführt werden.

RELion Dokumente – Tabelle wurden doppelt eingefügt

Ausgangssituation

Bei der Initialisierung von Tabellen zu AAK‑Templates wurden neue Tabellen unabhängig von der Template‑ID angelegt. Dadurch konnten Tabellen mehrfach eingerichtet werden.

Auswirkung

Doppelte Tabellen führten zu Inkonsistenzen und Fehlern bei der Archivierung.

Anpassung

RELion prüft bei der Einrichtung einer neuen Tabelle, ob dazu bereits eine Einrichtung existiert. Bei Vorhandensein wird die Anlage unterbunden und eine Fehlermeldung ausgegeben. Dies wurde auch bei der zentralen Initialisierung der RELion Dokumente Tabellen Einrichtung umgesetzt.

Zusätzliche Hinweise

Stabilität und Datenintegrität wurden verbessert; keine UI‑Änderungen.

Berechtigungssätze

Die Standard Berechtigungssätze stehen als XML zur Verfügung RELion 12.32

Tabelleninformationen Modell

Änderungen im Datenmodell werden in den Tabelleninformationen angezeigt.

Hotfix 32.2

Fehlermeldung beim Buchen von Eingangsrechnungen

Ausgangssituation

Mit dem Update CU12.31 wurde das RELion-Feld Voucher Type in der deutschen Übersetzung als Belegart bezeichnet. In der Tabelle Einkaufszeile existieren jedoch mehrere Felder, die ebenfalls die Bezeichnung Belegart verwenden. Dadurch entstand bei der Verarbeitung projektbezogener Einkaufsrechnungen eine Kollision der übersetzten Feldbezeichnungen.

Auswirkung

• Beim Buchen projektbezogener Einkaufsrechnungen trat die Fehlermeldung auf: „Die Caption Belegart ist für mehrere Felder in der Tabelle uneindeutig Einkaufszeile.“
• Der Buchungsprozess konnte in betroffenen Szenarien nicht abgeschlossen werden.
• Anwender mussten die Verarbeitung abbrechen oder alternative Workarounds nutzen.

Anpassung

• Die Übersetzung des RELion-Feldes Voucher Type wurde geändert.
• Die neue Bezeichnung lautet RE Belegart.
• Durch die eindeutige Benennung werden Kollisionen mit bestehenden Feldern in der Tabelle Einkaufszeile vermieden.