Version 12.34

Build

Neue und geänderte Funktionen

Vertragsverwaltung

Vertragsklasse in Mietrechnungskopf

Ausgangssituation

In den Tabellen Mietrechnungen sowie Registrierte Mietrechnungen / Stornierte Mietrechnungen stand das Feld Vertragsklasse bisher nicht zur Verfügung. Dadurch war eine parallele Archivierung von WEG‑Kaufverträgen und Mietverträgen innerhalb eines Mandanten bei identischen Vertragsnummern nicht möglich.

Auswirkung

Verträge mit gleicher Vertragsnummer konnten nicht eindeutig unterschieden werden. Dies führte zu Einschränkungen bei der Archivierung und Auswertung unterschiedlicher Vertragsarten.

Anpassung

Die genannten Tabellen wurden jeweils um das Feld Vertragsklasse erweitert. Die Vertragsart kann nun eindeutig je Datensatz unterschieden und verarbeitet werden.

Zusätzliche Hinweise

• Durch die Erweiterung ist eine parallele Archivierung von WEG‑Kaufverträgen und Mietverträgen innerhalb eines Mandanten nun möglich.
• Bestehende Prozesse zur Mietrechnungsverarbeitung bleiben unverändert; die Ergänzung dient der besseren Differenzierung und Archivierung.

Word Integration

Verkaufsgutschrift – Word Vorlage Felder erweitern

Ausgangssituation

In den Berichten für ungebuchte und gebuchte VK-Gutschriften fehlten Felder, die zur Eigentümer-ZE und Verwaltung-ZE des Objekts gehören.

Auswirkung

In folgenden Berichten wurden zusätzliche Felder ergänzt:

• Ungebuchte VK-Gutschrift – Gutschrift an Debitor
• Gebuchte VK-Gutschrift – Inst. Verkauf – Gutschrift

Anpassung

Das DataSet der Berichte wurde um folgende Felder erweitert:

• Ihre Referenz
• Vertragsnr.
• Externe Belegnr.
• Buchungsdatum
• Fälligkeitsdatum
• Leistungszeitraum von
• Leistungszeitraum bis
• RCO = Eigentümer-ZE (Name, Adresse, PLZ, Ort, Telefon etc.)
• RCM = Verwaltung-ZE (Name, Adresse, PLZ, Ort, Telefon etc.)

Erweiterung DataSet Einkaufsbestellung

Ausgangssituation

Der Bericht Einkaufsbestellung basierte bislang auf einem DataSet, das nur einen eingeschränkten Umfang an Kontakt‑, Einheiten‑, Projekt‑ und Leistungszeitraumdaten enthielt.
Insbesondere Informationen zu Ansprechpartnern vor Ort, detaillierten Einheitenstammdaten sowie Projektleiter‑ und Leistungszeitraumangaben waren entweder nicht oder nur unvollständig im DataSet verfügbar.

Für Fachbereiche und nachgelagerte Prozesse (z. B. Drucklayouts, Auswertungen, Übergabe an Drittsysteme) bestand dadurch ein erhöhter manueller Aufwand bzw. die Notwendigkeit zusätzlicher Datenquellen.

Auswirkung

Das DataSet des Berichts wurde erweitert und stellt nun zusätzliche Informationen strukturiert zur Verfügung. Dadurch ergeben sich folgende Auswirkungen:

• Vollständigere Abbildung der Einkaufsbestellung im Bericht
• Reduzierung manueller Ergänzungen von Kontakt‑ und Projektinformationen
• Verbesserte Grundlage für Layoutanpassungen, Auswertungen und Weiterverarbeitung
• Höhere Datenkonsistenz zwischen Beauftragungskopf, ‑zeile und Projekt

Die Erweiterung ist abwärtskompatibel: Bestehende Berichtslayouts funktionieren weiterhin, nutzen jedoch die neuen Felder nur bei expliziter Anpassung.

Anpassung

Das DataSet des Berichts Einkaufsbestellung wurde um folgende Felder ergänzt:

Kontakt vor Ort (aus Beauftragungskopf)

• Kontakt vor Ort
• Kontaktnummer (PO_FieldContact)
• Kontakt Name (PO_FieldContactName)
• Kontakt Straße (PO_FieldContactAddress)
• Kontakt Straße 2 (PO_FieldContactAddress2)
• Kontakt PLZ (PO_FieldContactPostCode)
• Kontakt Ort (PO_FieldContactCity)
• Kontakt Telefon (PO_FieldContactPhoneNo)
• Kontakt Mobilnummer (PO_FieldContactMobilePhoneNo)
• Kontakt Emailadresse (PO_FieldContactEMail)

Einheitenstamm (aus Beauftragungskopf)

• Einheitenstamm
• Einheitenstamm Straße (UM_Address)
• Einheitenstamm Straße 2 (UM_Address2)
• Einheitenstamm Ort (UM_City)
• Einheitenstamm PLZ (UM_PostCode)
• Einheitenstamm Topografische Nr. (AT) (UM_TopographicNo)

Leistungszeitraum (aus Beauftragungszeile)

• Leistungszeitraum von (PurchaseLine_ServicePeriodFrom)
• Leistungszeitraum bis (PurchaseLine_ServicePeriodTo)

Projektleiter (aus Projekt)

• Name (JobManagerName)
• Funktion (JobManagerJobTitle)

Instandhaltung

Übertragung des Objektkontos in gebuchte Verkaufsrechnung bzw. Debitorenposten

Ausgangssituation

Im Kopf der Verkaufsrechnung konnte ein Objektkonto hinterlegt werden. Dieses Objektkonto wurde jedoch beim Buchen der Verkaufsrechnung weder in die gebuchte Verkaufsrechnung übernommen noch in den daraus entstehenden Debitorenposten eingetragen.

Auswirkung

Objektbezogene Informationen aus der Verkaufsrechnung gingen im Buchungsprozess verloren. Dadurch war die Nachvollziehbarkeit von Objektbezügen in gebuchten Belegen und Folgedaten eingeschränkt.

Anpassung

Das Objektkonto aus dem Kopf der Verkaufsrechnung wird nun vollständig weiterverarbeitet:

• Übernahme des Objektkontos in die gebuchte Verkaufsrechnung
• Eintragung des Objektkontos in den entstehenden Debitorenposten

Durch diese Erweiterung wird die Datenkonsistenz verbessert und der Objektbezug bleibt über den gesamten Prozess hinweg erhalten.

Zusätzliche Hinweise

• Die Änderung findet ausschließlich bei neu gebuchten Verkaufsrechnungen Anwendung.
• Bereits gebuchte Verkaufsrechnungen oder bestehende Debitorenposten werden nicht automatisch ergänzt.
• Es wird empfohlen, Objektkonten konsequent im Kopf der Verkaufsrechnung zu pflegen, um eine vollständige Nachverfolgbarkeit sicherzustellen.

Inspektionsaufgaben

Ausgangssituation

Eine strukturierte Möglichkeit zur Anlage und Verwaltung von Inspektionsaufgaben war bisher nicht vorhanden. Inspektionstermine konnten nicht systematisch aus definierten Aufgaben abgeleitet und überwacht werden.

Auswirkung

Mit der neuen Funktionalität steht nun eine eigene Tabelle mit zugehörigen Seiten zur Verfügung, über die Inspektionsaufgaben strukturiert erfasst werden können.

Inspektionsaufgaben lassen sich mit bestehenden Ausstattungen verknüpfen und bilden die Grundlage für die Erzeugung und Überwachung von Inspektionsterminen.

Anpassung

• Anwender können Inspektionsaufgaben erfassen und diesen relevante Ausstattungen zuordnen.
• Die angelegten Inspektionsaufgaben dienen als Basis für die Planung und Nachverfolgung von Inspektionsterminen.

Zusätzliche Hinweise

• Die Funktionalität befindet sich im Preview-Status.
• In kommenden Releases sind Erweiterungen und Anpassungen der Funktionalität möglich.

Aktion Inspektionstermin erzeugen

Ausgangssituation

Inspektionstermine mussten bislang manuell angelegt und gepflegt werden. Eine direkte Funktion zur automatisierten Erzeugung oder Aktualisierung von Inspektionsterminen auf Basis von Inspektionsaufgaben stand nicht zur Verfügung.

Auswirkung

Die Planung und Pflege von Inspektionsterminen war aufwendig und nur eingeschränkt konsistent möglich. Änderungen an Inspektionsaufgaben konnten nicht automatisiert auf bestehende Inspektionstermine übertragen werden.

Anpassung

Es wurde eine neue Funktion zur Erzeugung und Aktualisierung von Inspektionsterminen implementiert:

• Inspektionstermine können direkt aus einer Inspektionsaufgabe heraus erzeugt oder aktualisiert werden.
• Änderungen an Inspektionsaufgaben lassen sich gezielt auf die zugehörigen Inspektionstermine anwenden.
• Die Pflege der Inspektionstermine erfolgt damit konsistent auf Basis der definierten Inspektionsaufgaben.

Zusätzliche Hinweise

• Die Funktionalität befindet sich im Preview‑Status.
• In kommenden Releases sind Erweiterungen und Anpassungen der Funktion vorgesehen.

Prüfliste EK‑Rechnungen übernehmen

Ausgangssituation

Es stand kein standardisierter Bericht zur übersichtlichen Darstellung von Kopf‑ und Zeileninformationen ungebuchter Einkaufsrechnungen und Einkaufsgutschriften zur Verfügung. Die Analyse ungebuchter Einkaufsbelege war daher nur eingeschränkt möglich bzw. nur über mehrere unterschiedliche Auswertungen realisierbar.

Auswirkung

Die Transparenz und Nachvollziehbarkeit im Einkaufs‑ und Buchhaltungsprozess waren eingeschränkt. Prüf‑ und Abstimmungsprozesse erforderten erhöhten manuellen Aufwand.

Anpassung

• Neuer Bericht Checkliste Einkaufsbelege
• Bereitstellung in der Rolle RELion Objektbuchhaltung
• Aufrufpfad: Bericht Fibu → Berichte → Sonstiges → Checkliste Einkaufsbelege

Zusätzliche Hinweise

• Der Bericht berücksichtigt ausschließlich ungebuchte Einkaufsrechnungen und ‑gutschriften.
• Die Auswertung dient als Prüf‑ und Kontrollhilfe vor der Buchung und ersetzt keine Buchungs‑ oder Freigabefunktion.

BauSecura

Buchung Selbstbehalt – Obsolete in Pages und Quellcode entfernen

Ausgangssituation

In der Instandhaltung Einrichtung im Bereich BauSecura standen bislang die Felder Konto für Selbstbehalt sowie Aufwandskonto für Versicherungsschäden zur Verfügung.

Auf Basis dieser Felder wurde im BauSecura‑Prozess bei der Erstellung der Verkaufsrechnung eine komplexe Buchungslogik für den Selbstbehalt angewendet. Dies führte zu mehrzeiligen und schwer nachvollziehbaren Buchungssätzen.

Auswirkung

Die bestehende Buchungslogik erhöhte die Komplexität bei der Verbuchung von Selbstbehalten erheblich. Die daraus resultierenden Buchungen waren sowohl für Anwender als auch für nachgelagerte Prozesse nur eingeschränkt nachvollziehbar.

Zudem stellte sich heraus, dass die beiden zusätzlichen Kontofelder nicht mehr erforderlich sind. Das ursprüngliche Buchungskonzept erzeugte einzeilige Buchungssätze und trug damit zu einer besseren Nachvollziehbarkeit des Prozesses bei.

Anpassung

• Die Felder Konto für Selbstbehalt und Aufwandskonto für Versicherungsschäden wurden vollständig aus der Instandhaltung Einrichtung (Bereich BauSecura) entfernt.
• Die Buchungslogik in der Verkaufsrechnung wurde auf das ursprüngliche Konzept zurückgeführt.
  • Der Selbstbehalt wird wieder als einzeilige Buchung verbucht.
  • Eine komplexe Aufteilung oder Mehrzeiligkeit entfällt vollständig.

Zusätzliche Hinweise

• Durch die Entfernung der Felder entfällt deren Pflege in der Einrichtung.
• Bestehende Prozesse und Auswertungen, die bereits auf dem ursprünglichen Buchungskonzept basieren, bleiben unverändert funktionsfähig.
• Für bestehende Daten sind keine manuellen Nacharbeiten erforderlich.

Mahnwesen

Funktion Mahnungstext aktualisieren für RELion anpassen

Ausgangssituation

Der Business Central Standard erlaubt die nachträgliche Aktualisierung von Mahntexten gemäß aktueller Mahnstufen. RELion bietet diese Möglichkeit bislang nicht.

Auswirkung

Ohne diese Funktionalität müssen Mahnungen entweder manuell angepasst werden oder die gesamte Verarbeitung der Mahnungserstellung neu gestartet werden, um die aktuell eingestellten Texte der jeweiligen Stufen zu ziehen. Beides ist sehr zeitaufwändig.

Anpassung

• Die Funktion Mahnungstext aktualisieren… steht nun auch für RELion‑Mahnungen zur Verfügung.
• Über einen Bericht kann die Stufe ausgewählt werden, aus der der Text übertragen wird, optional inkl. Gebührenaktualisierung.
• RELion‑spezifische Optionen (Anfügen der Zeilen, Bezeichnung der Mahngebühr) werden berücksichtigt.

Mahnung Dataset erweitern

Ausgangssituation

Für kundenindividuelle Layouts fehlten in Mahnberichten wichtige Datenfelder zu Objekt, Einheit, Vertrag und ZE.

Auswirkung

Bestimmte Layoutanforderungen konnten nicht umgesetzt werden.

Anpassung

• Erweiterung der Mahnberichte um Inhalte zu Objekt, Einheit, Vertrag und ZE
• Ergänzung von:
  • Belegnummer
  • Fälligkeitsdatum
  • externer Vertragsnummer
• Gültig für die Berichte 5052456, 5052485, 5052486, 5052487

Betriebskostenabrechnung

Verbesserung einer Fehlermeldung in der Abrechnung

Ausgangssituation

Bei der Abrechnung wird eine Fehlermeldung ausgegeben, wenn Textbausteine nicht korrekt eingerichtet sind. Die bisherige Fehlermeldung lieferte jedoch keinen eindeutigen Hinweis darauf, wo die fehlerhafte Konfiguration vorliegt. Insbesondere fehlte der direkte Bezug zur betroffenen Einrichtung im Berichtstext, was die Fehlersuche erschwerte.

Auswirkung

Anwender können die Ursache der Fehlermeldung nur mit erhöhtem Analyseaufwand identifizieren.

Anpassung

Die bestehende Fehlermeldung wurde um einen erklärenden Hinweis ergänzt, der der bisherigen Meldung vorangestellt wird.

Neuer zusätzlicher Text: „Die Einrichtung im RE Berichtstext Nr. xxx für die folgende Textzeile ist nicht korrekt:“

Mitgliederwesen

Bericht Mitgliederguthabenliste als Excellayout

Ausgangssituation

Der Bericht Mitgliederguthabenliste war nur als RDLC‑Layout verfügbar, eine direkte Excel‑Weiterverarbeitung war eingeschränkt möglich.

Auswirkung

Eine strukturierte Auswertung in Excel‑Pivottabellen war systemseitig nicht möglich.

Anpassung

• Der Bericht wurde durch ein Excellayout ersetzt.
• Das Excellayout erzeugt automatisch eine Pivottabelle.
• Das Excellayout ist als Standard definiert.

Zusätzliche Hinweise

• Das RDLC‑Layout wurde entfernt.
• Die erzeugte Pivottabelle kann individuell erweitert werden.

Bericht Bilanznachweis mit Sachkontobezug als Excellayout

Ausgangssituation

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

Auswirkung

Eine strukturierte Excel‑Auswertung war nur eingeschränkt möglich.

Anpassung

• Der Bericht Bilanznachweis mit Sachkontobezug wurde auf ein Excel‑Layout umgestellt.
• Dieses Layout erzeugt automatisch eine Pivottabelle, die sich in Aufbau und Darstellung am bisherigen RDLC‑Bericht orientiert.
• Das neue Excel‑Layout wurde systemseitig als Standardlayout definiert.

Zusätzliche Hinweise

• Das RDLC‑Layout wurde entfernt.
• Die Pivottabelle kann individuell angepasst werden.

E-Belege

Buchen & Senden analysieren und korrigieren

Ausgangssituation

Bei Verwendung der Funktion Buchen & Senden wurde ein XML‑Beleg erzeugt. Nach der initialen Erstellung und einer programminternen Überarbeitung (u. a. Austausch der Firmendaten gegen ZE‑Daten) wurde der Beleg im anschließenden Sende‑Lauf erneut erzeugt. Dabei wurden fälschlicherweise wieder die Firmendaten verwendet.

Auswirkung

Der versendete XML‑Beleg enthielt nicht die vorgesehenen ZE‑Daten, sondern erneut die Firmendaten.

Anpassung

• Der Fehler wurde korrigiert.
• Der XML‑Beleg wird nun auch beim Buchen & Senden korrekt mit ZE‑Daten erzeugt und versendet.
• Eine erneute Überschreibung findet nicht mehr statt.

Zusätzliche Hinweise

• Die Korrektur betrifft ausschließlich die Erzeugung und den Versand des XML‑Belegs.
• Die fachlichen Buchungsdaten bleiben unverändert.

Zahlungsverkehr

Leere Kontoauszüge beim Import ignorieren

Ausgangssituation

Beim Import von CAMT.053‑Bankauszugsdateien wurden bislang alle Datensätze verarbeitet, ohne zu prüfen, ob die Datei tatsächlich Kontobewegungen enthält. Eine entsprechende Prüfmöglichkeit war systemseitig nicht vorgesehen. In der Zahlungsverkehr Einrichtung stand kein Steuerungsfeld zur Verfügung, um dieses Verhalten zu beeinflussen.

Auswirkung

Dadurch konnten auch Bankauszugsdateien ohne Buchungen importiert werden. Dies führte vereinzelt zu Problemen bei der automatischen Weiterverarbeitung sowie zu unnötigen Importvorgängen.

Anpassung

Folgende Erweiterungen wurden umgesetzt:

• Einführung einer neuen Systemeinstellung
  In der Zahlungsverkehr Einrichtung wurde das neue Kontrollfeld Prüfung auf leeren Bankkontoauszug ergänzt.
• Erweiterung der Importlogik
  Ist das Kontrollfeld aktiviert, prüft das System beim Import von CAMT.053‑Dateien, ob mindestens ein Buchungsdatensatz (Ntry/Amt) mit einem Betrag ungleich 0 enthalten ist. Ist dies nicht der Fall, wird die Datei beim Import übersprungen.

Zusätzliche Hinweise

Die Prüfung ist optional und kann ein‑ oder ausgeschaltet werden.

Zahlungsschlüssel nur aktiven Objekten und Einheiten zuweisen

Ausgangssituation

In RELion können Zahlungsschlüssel automatisch für Verträge, Einheitenverträge oder Objektkonten vergeben werden. Im bisherigen Verfahren wurden bei der automatischen oder nachträglichen Zuweisung jedoch teilweise auch Datensätze berücksichtigt, die zum Zeitpunkt der Verarbeitung bereits beendet waren. Zudem bestand keine Möglichkeit, die Zuweisung zeitlich einzugrenzen oder zu steuern.

Auswirkung

Die bestehenden Prüfungen waren nicht ausreichend und konnten dazu führen, dass Zahlungsschlüssel auch für nicht mehr aktive Objekte oder Einheitenverträge vergeben wurden. Insbesondere bei Banken mit begrenztem oder kostenpflichtigem Zahlungsschlüsselbestand konnte dies zu einem unnötigen Verbrauch von Zahlungsschlüsseln führen.

Anpassung

Die automatische und nachträgliche Zuweisung von Zahlungsschlüsseln wurde um zusätzliche Prüfungen erweitert:

• In der Zahlungsverkehr Einrichtung wurde das neue Feld Stichtag ergänzt. Ist kein Datum hinterlegt, wird automatisch das Arbeitsdatum verwendet.
• Zahlungsschlüssel werden nur noch vergeben, wenn das Objekt zum Stichtag aktiv ist.
  Ein Objekt gilt als aktiv, wenn kein Verwaltungsende hinterlegt ist oder das Verwaltungsende nach dem Stichtag liegt.
• Bei Verträgen erfolgt eine Zuweisung nur, wenn:
  • noch kein Zahlungsschlüssel vorhanden ist,
  • der Vertrag nicht als leerstehend gekennzeichnet ist und
  • das Ende der Verwaltung bzw. des Vertrags nicht vor dem Stichtag liegt.
• Bereits bestehende Zahlungsschlüssel an Verträgen, Einheiten oder Objektkonten werden berücksichtigt und nicht überschrieben.

Zusätzliche Hinweise

• Für Banken mit Zahlungsschlüsselbestand wird der verfügbare Vorrat geprüft.
  Wird der definierte Mindestbestand unterschritten, erhält der Anwender einen entsprechenden Hinweis.
• Beendete Objekte oder Einheitenverträge erhalten keine neuen Zahlungsschlüssel mehr.
  Dadurch wird der Zahlungsschlüsselbestand gezielt, nachvollziehbar und wirtschaftlich gesteuert.

Forderungsmanagement

Rechtsfallverwaltung

Ausgangssituation

Das Modul Forderungsmanagement beschränkte sich bislang auf den Einsatz von Mahnakten. Um ein umfassenderes Forderungsprofil abzubilden und zusätzlich die Möglichkeit zu schaffen, Rechtsfälle sowie Kündigungsvorschläge für Verträge zu pflegen, wurde der Funktionsumfang des Forderungsmanagements erweitert.

Auswirkung

Das bisherige Forderungsmanagement war im Umfang begrenzt. Fälle, die nach einer erfolglosen Mahnung weiterbearbeitet werden mussten, konnten nicht ausreichend unterstützt werden.

Anpassung

Das Forderungsmanagement wurde um folgende Funktionalitäten erweitert:

Zusätzlich wurden weitere unterstützende Funktionen ergänzt:

• Infobox Ausgeglichene Debitorenposten
  Zeigt zu einem Debitorenposten alle damit ausgeglichenen Posten an – auch bei Teilausgleichen.
• Infobox Einheit Überblick
  Stellt auf der Einheitenvertrag‑Karte detaillierte Informationen zur zugehörigen Einheit dar.
• Rollencenter‑Einblick Meine Mahnvorgänge
  Verfügbar in den Rollencentern Objektbuchhaltung und Rechtsfälle. Zeigt alle nicht registrierten Mahnvorgänge des aktuellen Bearbeiters in einer Liste an.

Zusätzliche Hinweise

• Die Zahlungsverkehr Einrichtung wurde um ein eigenes Inforegister Forderungsmanagement erweitert.
• Die bisherigen Inhalte zur Mahnakte wurden in dieses Register überführt und übersichtlich gruppiert.
• Eine detaillierte Anwenderdokumentation für das erweiterte Forderungsmanagement wird in Kürze bereitgestellt.

Fehlerbehebung

Mietverwaltungsverträge

Sollstellungsdifferenz - Reichweiten ungleich 1M

Ausgangssituation

Bei der Berechnung von Sollstellungsdifferenzen wurden Reichweiten berücksichtigt, deren Beginn vor dem Datum RELion Sollstellung ab lag. Dies konnte in bestimmten Konstellationen zu fehlerhaften Ergebnissen führen.

Auswirkung

Die berechneten Differenzen konnten von den fachlich erwarteten Werten abweichen. Die Problematik trat nur bei Reichweiten auf, die vor dem Startdatum der RELion-Sollstellung begannen.

Anpassung

• Die Logik zur Sollstellungsdifferenzberechnung wurde angepasst.
• Für die Berechnung wird künftig ausschließlich die erste vollständig nach dem Datum RELion Sollstellung ab liegende Reichweite berücksichtigt.
• Unvollständige Reichweiten vor diesem Zeitpunkt fließen nicht mehr in die Differenzberechnung ein.
• Dadurch wird eine konsistente und fachlich korrekte Ermittlung der Sollstellungsdifferenzen sichergestellt.

Einheitenvertragsübersicht - Aufruf der Debitorenposten über das Feld “Saldo Sollstellungen”

Ausgangssituation
Der Aufruf der Debitorenposten war mit langen Ladezeiten verbunden.
Dies führte insbesondere bei größeren Datenmengen zu verzögerten Reaktionszeiten im Programm.

Auswirkung

Die Nutzung der Funktion war zeitintensiv.
Arbeitsabläufe wurden durch lange Wartezeiten beeinträchtigt.

Anpassung

Die Programmierung des Aufrufs der Debitorenposten wurde technisch optimiert um die Performance zu erhöhen. Die Optimierung wirkt sich ausschließlich auf die Lade- und Reaktionszeit aus.

Neuvermietungsassistent überträgt nicht alle Daten aus dem Mietvertragsentwurf in Kontaktkarte

Ausgangssituation

Bei der Neuanlage von Kontakten aus Mietvertragsentwürfen wurden bestimmte Kontaktfelder bislang nicht automatisch übernommen. Folgende Informationen aus dem Mietvertragsentwurf wurden bei der Kontaktanlage nicht berücksichtigt:

• Geburtsname
• Bemerkung Telefonnummer
• Mobilnummer
• Bemerkung Mobilnummer
• Telefon (geschäftlich)
• Beruf

Auswirkung

• Die fehlende Übernahme der genannten Felder machte eine manuelle Nachpflege der Kontaktdaten erforderlich.
• Dies führte zu einem erhöhten Zeitaufwand bei der Kontaktanlage über den Neuvermietungsassistenten sowie zu einem erhöhten Risiko unvollständiger oder inkonsistenter Kontaktinformationen in der Vertrags‑ und Stammdatenverwaltung.

Anpassung

• Der Neuvermietungsassistent wurde funktional erweitert.
• Bei der Erstellung neuer Kontakte werden nun alle oben genannten Felder automatisch übernommen, sofern entsprechende Angaben im jeweiligen Mietvertragsentwurf vorhanden sind.
• Damit wird eine vollständigere, konsistente und effizientere Datenerfassung sichergestellt.

Zusätzliche Hinweise

• Die Anpassung betrifft ausschließlich neu angelegte Kontakte.
• Bestehende Kontakte werden durch diese Änderung nicht automatisch ergänzt oder aktualisiert.

Überarbeitung Bericht Sollmietenveränderung

Ausgangssituation

Im Bericht Sollmietenveränderung wurde die Einheiteninformation nicht in allen Fällen ausgegeben. Insbesondere fehlte die Anzeige, wenn vor dem betrachteten Zeitraum kein Sollstellungsbetrag vorhanden war.

Auswirkung

• Durch dieses Verhalten entstand ein uneinheitliches Berichtslayout.
• Die Zuordnung der Einträge zu den jeweiligen Einheiten war für Anwender teilweise nicht eindeutig nachvollziehbar, da einzelne Zeilen keiner Einheit klar zugeordnet werden konnten.

Anpassung

• Die Logik der Berichtsausgabe wurde überarbeitet.
• Die Einheiteninformationen werden nun unabhängig vom Vorhandensein eines Sollstellungsbetrags vor dem relevanten Zeitraum stets ausgegeben.

Sollstellungsdifferenzzeilen und WEG ohne Aufteilung

Ausgangssituation

Bei Eigentümerwechseln innerhalb einer Abrechnungsperiode ohne anteilige Aufteilung wurde in bestimmten Konstellationen das Endedatum der Sollstellungszeile nicht in allen Fällen korrekt ermittelt.

Auswirkung

Durch die fehlerhafte Ermittlung des Endedatums konnten Sollstellungsdifferenzen nicht korrekt berechnet werden. Dies führte in einzelnen Fällen zu Abweichungen bei den dargestellten Forderungs‑ bzw. Saldenwerten nach Eigentümerwechseln. Betroffen waren ausschließlich Konstellationen mit einem Eigentümerwechsel innerhalb einer Abrechnungsperiode ohne Aufteilung.

Anpassung

• Die Logik zur Berechnung des Endedatums der Sollstellungszeile wurde überarbeitet.
• Das Endedatum wird nun auch bei Nutzung der Funktion Eigentümerwechsel ohne Aufteilung konsistent und regelkonform ermittelt.

Berechneter Saldo für den Mietvertrag tlw. falsch/Vertragskontoauszug

Ausgangssituation

Beim Buchen von Verkaufsrechnungen bzw. ‑gutschriften, die aus Schadensmeldungen mit Weiterberechnung an Versicherungen oder Dritte entstehen, wurde bei hinterlegter Einheit und vorhandener Einheitenhistorie in der Schadensmeldung die Mietvertragsnummer (MV‑Nr.) in den entstehenden Debitorposten übernommen.

Der Debitorposten bezieht sich fachlich jedoch auf die Versicherung bzw. den Dritten und nicht auf den Mieter.

Auswirkung

• Die Übernahme der Mietvertragsnummer im Debitorposten war fachlich nicht korrekt.
• In der Seite Debitorenposten (bei Aufruf aus einem Mietvertrag) sowie im Bericht Vertragskontoauszug wurde der Posten dadurch einem Mietvertrag zugeordnet. Dies führte in der Folge zu einem fehlerhaften Saldenausweis auf dem betreffenden Mietvertrag.

Anpassung

• Die automatische Übernahme der Mietvertragsnummer in den Debitorposten wurde für Verkaufsrechnungen und ‑gutschriften aus Schadensmeldungen mit Weiterberechnung an Versicherungen oder Dritte korrigiert.
• In diesen Fällen wird künftig keine MV‑Nummer mehr in den Debitorposten geschrieben.

Zusätzliche Hinweise

• Bestehende Buchungen bleiben unverändert.
• Die Korrektur wirkt sich ausschließlich auf neu erzeugte Debitorposten aus.

Mietrechnung legt neue Zeilen in der Tabelle MwSt.-Betragszeile an

Ausgangssituation

Bei der Erzeugung von E‑Belegen aus Mietrechnungen wurde die Tabelle MwSt.‑Betragszeile bisher automatisch mit den aus der Mietrechnung ermittelten Mehrwertsteuerbeträgen befüllt. Diese zusätzliche Befüllung war fachlich nicht erforderlich und konnte im Rahmen der Migration auf Business Central 28 zu Migrationsfehlern führen.

Auswirkung

• Die unnötige Befüllung der Tabelle MwSt.-Betragszeile erhöhte die Komplexität der Datenstruktur bei der E‑Belegerstellung.
• Im Zuge der Migration auf Business Central 28 bestand dadurch das Risiko von Migrationsproblemen, obwohl die relevanten MwSt‑Informationen bereits an den vorgesehenen Stellen der Mietrechnung bzw. des E‑Belegs vorlagen.

Anpassung

• Die Logik zur Befüllung der Tabelle MwSt.‑Betragszeile im Rahmen der E‑Belegerstellung wurde entfernt.
• Die Erzeugung der E‑Belege bleibt inhaltlich unverändert; die MwSt.‑Informationen stehen weiterhin vollständig und korrekt in der Mietrechnung sowie im generierten E‑Beleg zur Verfügung. Lediglich die interne Speicherung der MwSt.‑Beträge in der Tabelle MwSt.-Betragszeile erfolgt nicht mehr.

Instandhaltung

Einkaufsrechnung/Einkaufsgutschrift: Prüfung Leistungszeitraum funktioniert nur in eine Richtung

Ausgangssituation

In der Zeile einer Einkaufsrechnung bzw. -gutschrift wurde der Leistungszeitraum geprüft. Die Prüfung erfolgte bisher ausschließlich bei Änderungen des bis-Datums. Nachträgliche Änderungen am von-Datum wurden nicht validiert.

Auswirkung

Inkonsistente Eingaben im Leistungszeitraum waren technisch möglich.
Diese führten erst beim Buchen der Einkaufsrechnung bzw. -gutschrift zu einer Fehlermeldung bzw. zu einem Fehlerabfang.

Anpassung

Die Prüfung des Leistungszeitraums wurde erweitert.
Neben dem bis-Datum wird nun auch das von-Datum validiert.

Zusätzliche Hinweise

Durch die frühzeitige Validierung wird die Datenqualität verbessert.
Buchungsfehler aufgrund inkonsistenter Leistungszeiträume werden vermieden.

BauSecura

Rechnung/Gutschrift an Versicherung in Verkaufsbelegen korrigieren

Ausgangssituation

In den Berichten

• Verkauf Rechnung Verwaltungshonorar
• Verkauf Gutschrift Verwaltungshonorar

wurde im bisherigen BauSecura‑Prozess geprüft, ob an der Schadensmeldung eine Versicherungsmeldung hinterlegt ist. Diese Information diente als Grundlage für die Steuerung der Betreffanzeige in der erzeugten Rechnung bzw. Gutschrift.

Im Zuge der Überarbeitung des BauSecura‑Prozesses werden jedoch keine Versicherungsmeldungen mehr erzeugt. Auch eine manuelle Anlage ist nicht mehr vorgesehen. Die bestehende Prüf‑Logik in den genannten Berichten griff dadurch nicht mehr, was zu einer fehlerhaften Betreffanzeige führte.

Auswirkung

Da BauSecura‑Schadensmeldungen keine Versicherungsmeldungen mehr enthalten, konnte der bisherige Prüfschritt nicht erfüllt werden.

Infolgedessen wurde bei BauSecura‑Abrechnungen keine eindeutige Kennzeichnung als Versicherungsabrechnung ausgegeben. Dies reduzierte die Transparenz im Abrechnungsprozess und erschwerte sowohl interne als auch externe Zuordnungen der Belege.

Anpassung

Die Berichte wurden dahingehend angepasst, dass die Betreffanzeige nicht mehr von der Existenz einer Versicherungsmeldung abhängt, sondern direkt auf Basis einer BauSecura‑Abrechnung gesteuert wird. Es wird nun folgender Betreff ausgegeben:

• Rechnung Verwaltungshonorar:
  Rechnung an Versicherung
• Gutschrift Verwaltungshonorar:
  Verkaufsgutschrift an Versicherung

Die Anzeige erfolgt automatisch, sofern es sich um eine BauSecura‑Abrechnung handelt.

Zusätzliche Hinweise

• Die Anpassung betrifft ausschließlich die Logik zur Betreffanzeige. Layout, Berechnung und sonstige Inhalte der Berichte bleiben unverändert.
• Durch die Änderung ist sichergestellt, dass BauSecura‑Abrechnungen auch ohne Versicherungsmeldungen weiterhin eindeutig als Versicherungsabrechnungen gekennzeichnet sind.

Mietanpassung

Erweiterung DataSet Bericht Manuelle Mietanpassung um Netto-Summen

Ausgangssituation

Das DataSet des Berichts manuelle Mietanpassung enthielt bisher keine detaillierten Summenfelder für Nebenkosten, sonstige Kosten sowie deren zugehörige Mehrwertsteueranteile.

Auswirkung

Mit den fehlenden Feldern war eine transparente und vollständige Darstellung der einzelnen Kostenbestandteile nur eingeschränkt möglich.

Anpassung

Das DataSet wurde um folgende Felder ergänzt:

• Summe Nebenkosten (netto) CT_SumOfAncillaryCostsNetAmount
• Summe Mehrwertsteuer Nebenkosten CT_SumOfAncillaryCostsVAT
• Summe sonstige Kosten (netto)CT_SumOfOtherCostsNetAmount
• Summe Mehrwertsteuer sonstige Kosten CT_SumOfOtherCostsVAT
• Summe Mehrwertsteuer Miete CT_SumOfRentVATAmount

Vertragsverwaltung

Falsche Berechnung des Status auf der Mietvertragskarte

Ausgangssituation

Bei Verträgen, die sich formal noch in der Erstlaufzeit befanden, wurde der Status Erstlaufzeit angezeigt, auch wenn sich der Vertrag faktisch verlängerte.

Auswirkung

Die Statusanzeige konnte missverständlich sein und entsprach nicht der tatsächlichen Vertragslaufzeit.

Anpassung

Der Vertragsstatus wird nun korrekt angepasst und zeigt bei Verlängerung Automatisch verl. bis [neues Kündigung-zum-Datum] an.

Zusätzliche Hinweise

Die Anpassung betrifft ausschließlich die Anzeige, bestehende Vertragsdaten bleiben unverändert.

Standardlayout Vertragsschreiben fehlerhaft

Ausgangssituation

Bei der Ermittlung der Einheitenverträge im Bericht Vertragsschreiben wurde der eingegebene Stichtag bisher nicht berücksichtigt. Dadurch konnten auch Einheitenverträge in die Auswertung einfließen, die zum Stichtag fachlich nicht (mehr) gültig waren.

Auswirkung

Die im Bericht ausgegebenen Vertragsdaten konnten vom tatsächlichen Vertragsstand zum Stichtag abweichen. Dies konnte zu inhaltlich falschen oder irreführenden Vertragsschreiben führen.

Anpassung

Der Bericht wurde so angepasst, dass der Stichtag bei der Ermittlung der Einheitenverträge berücksichtigt wird.

Ist die neue Option Nur aktive Einheitenverträge aktiviert, werden ausschließlich die zum Stichtag gültigen Einheitenverträge ermittelt und ausgegeben. Die Option Nur aktive Einheitenverträge ist standardmäßig aktiviert.

Zusätzliche Hinweise

• Durch die Standardaktivierung der Option wird eine stichtagsbezogen korrekte Datengrundlage ohne zusätzlichen Bedienaufwand sichergestellt.
• Das Verhalten kann bei Bedarf bewusst über die entsprechende Option im Bericht gesteuert werden.

Verwalterhonorar

Rechnung Verwalterhonorar - fehlerhafte Darstellung bei mehreren Textzeilen

Ausgangssituation

Bei der Erstellung von Verkaufsrechnungen über den Bericht Verwalterhonorar Stapelberechnung wurde bisher für jede Textzeile eines Verwaltungsvertrags zusätzlich eine Zeile mit dem Abrechnungszeitraum erzeugt. Diese zusätzliche Zeile wurde anschließend auch in der Verkaufsrechnung gedruckt.

Auswirkung

Durch die bisherige Logik wurden Verkaufsrechnungen unnötig aufgebläht.
Insbesondere reine Textzeilen ohne Leistungsbezug führten zu zusätzlichen Datumszeilen, was die Lesbarkeit der Rechnung beeinträchtigte und zu Rückfragen bei Endanwendern führte.

Anpassung

Die Generierungslogik wurde überarbeitet.
Textzeilen im Verwaltungsvertrag werden ohne zusätzliche Zeile für den Abrechnungszeitraum ausgegeben.
Damit wird die Darstellung der Verkaufsrechnung klarer und entspricht der fachlichen Erwartung.

DSGVO

Löschung nach Quarantäne

Ausgangssituation

Nach der Anonymisierung und Quarantäne im Rahmen der Datenschutz‑Grundverordnung werden die zugehörigen Anfragen endgültig gelöscht. In diesem Prozess kann es vorkommen, dass einzelne Datenbanktabellen nicht mehr vorhanden sind, aber in den Protokollen der Anfragen vorkommen.

Auswirkung

Beim Versuch, die anonymisierte Anfrage endgültig zu löschen, tritt ein Fehler auf. Der Löschvorgang wird abgebrochen, da im Protokoll auf eine Tabelle verwiesen wird, die im System nicht mehr vorhanden ist. Dadurch ist eine vollständige Löschung der Anfrage nicht möglich, was zu Funktionsstörungen im Löschprozess und evtl. zusätzlichen Arbeitsaufwänden führt.

Anpassung

Der Löschprozess verarbeitet Anfrage‑Protokolle auch dann korrekt, wenn referenzierte Tabellen nicht mehr in der Datenbank vorhanden sind.

Mahnwesen

Unterschiedliche Daten bei Mahnvorschlagsposten

Ausgangssituation

Bei beendeten Verträgen mit mehreren offenen Posten wurden Vertragsbeginn und Vertragsende nicht in allen Zeilen angezeigt. Die Anzeige erfolgte nur bei offenen Posten aus Sollstellungen.

Auswirkung

Die Übersichtlichkeit und Nachvollziehbarkeit der offenen Posten war eingeschchränkt. Eine eindeutige fachliche Zuordnung war erschwert.

Anpassung

Vertragsbeginn und Vertragsende werden nun bei allen offenen Posten eines Vertrags angezeigt – unabhängig von der Herkunft aus einer Sollstellung.

Buchhaltung

Steueränderungen bei Validierung Datumsarten

Ausgangssituation

Bei der Validierung von Datumsarten in RELion traten zwei verbesserungswürdige Fälle auf. Zum einen führt in Business Central die Änderung des Belegdatums immer zur Validierung des MwSt.-Datums, wodurch es in RELion ungewollt zu Änderungen der Steuerdaten kommen kann. Zum anderen führte eine Änderung des MwSt.-Datums in gebuchten MwSt.-Posten nicht nur zu einer Aktualisierung des Vorsteueranteils %, sondern teilweise auch zu einer Änderung der MwSt.-Geschäftsbuchungsgruppe.

Auswirkung

Diese Fälle können in bestimmten Konstellationen negative Auswirkungen auf die Buchhaltung haben und den Benutzer in der Anwendung irritieren.

Anpassung

• Eine Validierung des MwSt.-Datums aktualisiert die davon abhängigen Daten (z. B. Steuerdaten) nur noch dann, wenn sich der neue Wert tatsächlich von der bisherigen Eingabe unterscheidet.
• Änderungen des MwSt.-Datums in den Posten wirken sich nur noch auf das MwSt.-Datum und den Vorsteueranteil % in den Sachposten aus, nicht jedoch auf die MwSt.-Geschäftsbuchungsgruppe.

Informationen in Druckausgabe Sachkontoauszug fehlen

Ausgangssituation

In der Druckausgabe des Sachkontoauszugs wurden im oberen Bereich zentrale Informationen nicht dargestellt. Betroffen waren die Felder:

• Erstellungsdatum
• Seitennummer
• Mandant

Auswirkung

Die resultierende Druckausgabe entsprach nicht den formalen Anforderungen an einen vollständigen Bericht. Insbesondere war eine eindeutige Identifikation der Ausdrucke im Hinblick auf Mandant, Erstellungszeitpunkt und Seitenbezug eingeschränkt, was die revisionssichere Ablage, den Versand sowie Prüfprozesse erschwerte.

Anpassung

Der Bericht wurde layout‑ und logikseitig korrigiert. Die betroffenen Felder werden im Kopfbereich der Druckausgabe nun wieder korrekt aus den entsprechenden Parametern ermittelt und ausgegeben:

• Erstellungsdatum,
• Seitennummer,
• Mandant.

RELion Dokumente

Ausgangssituation

Im Bereich der RELion‑Dokumente wurde aufgrund der neuen archivierungsfähigen kreditorischen Verträge das Feld Vertragsnr. neu angelegt und befüllt. Beim Vorgang Buchen und Senden von E‑Belegen in Verkaufsrechnungen führte dies zu einer Rekursion.

Auswirkung

Die Rekursion erzeugte einen Fehler mit der Meldung, dass nicht genügend Speicher zur Verfügung steht. Infolgedessen konnten E‑Belege nicht erstellt und versendet werden.

Anpassung

Die Validierung der neuen Vertragsnummer wurde angepasst. Dadurch tritt die Rekursion nicht mehr auf und E‑Belege können in Verkaufsrechnungen über Buchen und Senden wieder erfolgreich erstellt und versendet werden.

Nicht archivierte Datei-Einträge werden bei Änderung in Archiv kompakt dupliziert

Ausgangssituation

Bei Dokumenten mit einem nicht archivierten Unterdokument in RELion führte eine Änderung in Archiv kompakt dazu, dass dieses Unterdokument ab der zweiten Änderung kein Gelöscht‑Datum mehr erhielt. Dies trat unabhängig von der Art der Änderung auf.

Auswirkung

Bei einer einmaligen Änderung (z. B. Verschieben in ein anderes Archiv) traten keine Auswirkungen auf. Ab der zweiten Änderung wurde aufgrund des fehlenden Gelöscht‑Datums die Datei doppelt angelegt. Dadurch nahm die Anzahl der Dateien bei weiteren Änderungen weiter zu.

Anpassung

• Das Programm wurde dahingehend angepasst, dass bei nicht archivierten Unterdokumenten die fehlenden Gelöscht‑Daten nun korrekt gesetzt werden.
• Dies ermöglicht es, das Unterdokument in den neuen Eintrag zu überführen, ohne eine Duplizierung der Dateien vorzunehmen.
• Mehrfache Änderungen führen somit nicht mehr zur Vervielfachung nicht archivierter Unterdokumente.

Betriebskostenabrechnung

Belegeanzeige in der Abrechnung aus RELion Dokumente fehlerhaft

Ausgangssituation

In der Infobox RELion Dokumente werden die Verbindungen zu Kreditorenposten sowie zugehörigen Belegen nicht korrekt angezeigt, wenn den Abrechnung Detailzeilen zuvor reine Sachpostenbuchungen zugrunde liegen.

Die Anzeige funktioniert nur, wenn zu einem verlinkten Sachposten auch ein Kreditorenposten existiert. Sobald Sachposten folgen, zu denen ein Kreditorenposten vorhanden ist, bricht die Anzeige unerwartet ab.

Beobachtet wurde außerdem, dass die Meldung Archiv nicht aktiv angezeigt wird, ohne dass klar ist, ob ein Zusammenhang zur fehlerhaften Anzeige besteht.

Auswirkung

• Belege, die am Kreditorenposten sichtbar sein müssten, werden in der Infobox nicht durchgängig dargestellt.
• Bei Zeilen, die vorher korrekt funktionierten, erscheint nach bestimmten Buchungskonstellationen keine Anzeige mehr.
• Anwender erhalten dadurch eine unvollständige oder irreführende Darstellung zu den vorhandenen Belegen.

Anpassung

Es wurde eine Korrektur implementiert, sodass die Beleganzeige wieder zuverlässig funktioniert, sobald zu einem Sachposten ein zugehöriger Kreditorenposten existiert. Die interne Logik der Infobox wurde angepasst, damit sie nach Sachpostenbuchungen, auch solchen ohne Kreditorenbezug (z. B. interne Umbuchungen), wieder korrekt in den erwarteten Zustand zurückkehrt.

Zusätzliche Hinweise

• Das Verhalten rein sachpostenbasierter Zeilen ohne Kreditorenbezug bleibt unverändert – hier erfolgt auch weiterhin keine Beleganzeige, da dies fachlich korrekt ist.
• Der Hinweis Archiv nicht aktiv wird geprüft, zeigt aber nach aktuellem Stand keinen direkten Einfluss auf die Funktion der Belegverknüpfung.

Berechtigungssätze

In RELion wurden neue Tabellen der rollenspezifischen Berechtigungssätze hinzugefügt.

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

Hinweis

Anwender, die RELC‑Berechtigungssätze sowie E‑Belege nutzen, müssen sicherstellen, dass bei den jeweiligen Mitarbeitern die erforderlichen Microsoft E‑Belege‑Berechtigungen hinterlegt sind. Microsoft liefert hierfür folgende Berechtigungen mit, die im Benutzer- bzw. Mitarbeiterprofil ergänzt werden müssen:

Tabelleninformationen Modell

Änderungen im Datenmodell werden in den Tabelleninformationen angezeigt.