Version 12.28

Tags:

• Release
• Installation
• Update
• Tabellen

  32 Minuten Lesezeit  

Neue und geänderte Funktionen

RE Berichtsauswahl

Initialisierung der Berichtsauswahl ergänzen

Ausgangssituation

In der RE Berichtsauswahl fehlten Initialisierungsfunktionen für die Verwendungen RE Mahnung, RE Registrierte Mahnung, Objektkonten und Einheiten. Bei einer Initialisierung wurden bestehende Einträge gelöscht, ohne dass neue Einträge angelegt wurden. Zudem waren die gespeicherten Berichts-IDs nicht korrekt den Beschreibungen zugeordnet.

Auswirkung

Ohne Initialisierungslogik wurde bei der Initialisierung der genannten Bereiche eine Meldung ausgegeben. Beim Ausführen der Funktion “Alles initialisieren” wurden in den genannten Verwendungen die Einträge gelöscht, jedoch keine Standardeinträge eingefügt.

Anpassung

Für die genannten Verwendungen wurde jeweils eine Initialisierungsfunktion mit Vorbelegung implementiert. Diese sorgt dafür, dass bei einer Initialisierung passende Berichtseinträge automatisch angelegt und korrekt zugeordnet werden.

Zusätzliche Hinweise

Eine Prüfung bestehender Berichtseinträge wird empfohlen, um fehlerhafte Zuordnungen zu bereinigen.

Betriebskostenabrechnung

Kennzeich. EUR in Belegen Abrechnung

Ausgangssituation

• In verschiedenen Berichtsformaten (z. B. Einzelaufstellung, Anlage Par35, Steuer-Splitt) fehlte bislang eine konsistente Kennzeichnung der Währung „EUR“ bei Beträgen.

Auswirkung

• Die fehlende oder uneinheitliche Währungskennzeichnung konnte zu Missverständnissen bei der Interpretation der Beträge führen.
• Die Lesbarkeit und Nachvollziehbarkeit der Belege war eingeschränkt.
• Die Änderungen werden erst durch Belege erzeugen wirksam. Bei bestehenden Belegen bleibt die alte Darstellung erhalten.

Anpassung

• Die Spaltenüberschriften für die Beträge wurden z.T. mit der Kennzeichnung EUR ergänzt.
• Anschreiben mit Forderungssplit (Erweiterte Darstellung bei Steuerpflichtigen)

• Abrechnung Einzelaufstellung:

• Anlage zu Paragraf 35a EStG

• Nachweis der Vorsteuerbeträge aus Eingangsrechnungen

Instandhaltung

Restriktionen aufgeben

Ausgangssituation

Bestimmte Aktionen im Zusammenhang mit Schadensmeldungen waren bislang nur bei spezifischen Statuswerten möglich.

Auswirkung

Dies führte in der Praxis zu Einschränkungen bei der Bearbeitung und Weiterverarbeitung von Schadensmeldungen, insbesondere im Zusammenhang mit Rechnungsfreigaben und Kontenanpassungen.

Anpassung

Die Freigabe einer Rechnung mit zugeordneter Schadensmeldung ist nun auch dann möglich, wenn die Schadensmeldung den Status Abgeschlossen hat. Bisher war eine Rechnungsfreigabe nur zulässig, wenn die Schadensmeldung den Status Freigegeben hatte.

Das Erlöskonto innerhalb einer Schadensmeldung kann nun auch dann noch geändert werden, wenn diese den Status Freigegeben hat. Zuvor war eine Änderung nur im Status Erfasst möglich.

Zahlungsverkehr

Rücklastschrift: Aktualisierung der Beschreibung

Ausgangssituation

Im bisherigen Prozess der Rücklastschriftverarbeitung wurde die EndToEndId nicht korrekt berücksichtigt, wenn keine explizite Einrichtung für die Lastschrift-EndToEndId vorgenommen wurde. Dies führte dazu, dass Rücklastschriften nicht automatisch zugeordnet und kontiert werden konnten. Die betroffenen Buchungen mussten manuell bearbeitet werden, was zu erhöhtem Aufwand und Fehleranfälligkeit führte.

Auswirkung

Die fehlende EndToEndId-Einrichtung hatte zur Folge, dass Rücklastschriften nicht wie vorgesehen verarbeitet wurden. Dies betraf insbesondere Fälle, in denen die automatische Kontierung und Aufhebung des Postenausgleichs nicht funktionierte. Die Beschreibung wurde auch nicht richtig aktualisiert, das Wort Rücklastschrift kam 2x in der Beschreibung vor.

Anpassung

Die Änderung wurde im Rahmen der Releases 12.26 Hotfix 1 und 12.27 Hotfix 3 umgesetzt. Die Verarbeitung von Rücklastschriften wurde dahingehend angepasst, dass auch ohne explizite Einrichtung der EndToEndId eine korrekte Zuordnung und Kontierung erfolgt. Die Systemlogik wurde erweitert, sodass die EndToEndId aus der Zahlungsverkehr-Einrichtung dynamisch generiert und verwendet wird. Die Beschreibung wird nun auch richtig aktualisiert.

Zusätzliche Hinweise

• Die Änderung betrifft ausschließlich die Rücklastschriftverarbeitung im Zahlungsverkehrsmodul.
• Die Einrichtung der EndToEndId ist weiterhin optional, wird jedoch empfohlen, um eine eindeutige Zuordnung zu gewährleisten.

Revision: Rücklastschrift ohne Lastschrift EndToEndId Einrichtung

Ausgangssituation:

Bisher wurde bei der Verarbeitung von Rücklastschriften, mit einer oder mehreren Einheiten, vorausgesetzt, dass für die zugehörige Lastschrift eine EndToEndId eingerichtet ist. Fehlt diese EndToEndId, konnte die Rücklastschrift/en nicht korrekt zugeordnet und verarbeitet werden.

Auswirkung:

Rücklastschriften ohne eine zugehörige EndToEndId der Lastschrift wurden bislang nicht erkannt und blieben unbearbeitet. Dies führte zu Unstimmigkeiten im Zahlungsverkehr und erforderte manuelle Nacharbeiten.

Anpassung:

Mit dem aktuellen Release wird nun auch die Rücklastschriften (mit einer oder mehreren Einheiten) erkannt und verarbeitet, wenn für die ursprüngliche Lastschrift keine EndToEndId eingerichtet ist. Die Zuordnung erfolgt anhand alternativer Kriterien, sodass der Prozess robuster und automatisierter abläuft.

Erweiterung Kontierungsregel Belegnummer in SVWZ

Anpassung

Neue Kontierungsprüfung auf Basis der Belegnummer im Verwendungszweck ist möglich. Hierfür muss die Einrichtung vorgenommen werden:

Hinweis:

Beim Einrichten der Felder „Anfangszeichen Belegnr.“ und „Länge Belegnr.“ ist darauf zu achten, dass die Kombination exakt dem Aufbau der Belegnummer entspricht.

Beispiel: Für die Belegnummer REL_RNR00063 muss

• „Anfangszeichen Belegnr.“ = REL_RNR
• „Länge Belegnr.“ = 5 gewählt werden, da „00063“ der variable, nummerische Teil ist.

Eine falsche Einrichtung wie

• „Anfangszeichen Belegnr.“ = REL_
• „Länge Belegnr.“ = 8 führt dazu, dass die Belegnummer nicht korrekt erkannt oder verarbeitet wird.

2. Beim Importieren der Kontoauszüge, prüft das System die Einrichtung und die dazu gehörigen Daten, ob Debitorenposten auf Basis der Rechnungsnummer/Externe Belegnummer zugewiesen und kontiert werden können.

3. Diese Prüfung kann auch im Nachhinein ausgeführt werden über eine spezifische Funktionen die im Kontoauszug zur Verfügung stehen:

Belegnummern Extrahieren

Diese Funktion sucht sich die umgebuchten, importieren Haben-Umsatzzeilen. Sie extrahiert aufgrund der Einrichtung die Belegnr. und Externe Belegnr. in die dafür vorgesehenen Filter-Felder. Der Aufruf bzw. Start der Funktion erfolgt unmittelbar nach dem Import des Kontoauszuges.

Debitorenposten identifizieren

Diese Funktion sucht offene Rechnungsposten die zum Kontoumsatz aufgrund der Belegnummern passen und speichert die Information in die Tabelle „Identifizierte Debitorenposten“. Die Funktion setzt die Filter in den Debitorenposten wie folgt:

Such-Schleife 1, wenn Filterstring Belegnr. der Umsatzzeile <> Leer:

• Filterstring auf die Objektnummer(n) zu denen das Bankkonto gehört
• Belegart = Rechnung
• Offen = Ja
• Belegnr. = Filterstring Belegnr. der Umsatzzeile

Wenn Treffer gefunden wurden, werden diese in die Tabelle „Identifizierte Debitorenposten“ übertragen. Wenn keine Treffer gefunden wurden, dann Such-Schleife 2, wenn Filterstring Externe Belegnr. der Umsatzzeile <> Leer:

• Filterstring auf die Objektnummer(n) zu denen das Bankkonto gehört
• Belegart = Rechnung
• Offen = Ja
• Belegnr. = Filterstring Externe Belegnr. der Umsatzzeile Wenn Treffer gefunden wurden, werden diese in die Tabelle „Identifizierte Debitorenposten“ übertragen.

Hinweis:

Die Kontierungsprüfung auf Basis der Belegnummer im Verwendungszweck ist mit anderen Arten von Kontierungsregeln nicht kompatibel. Daher wird sie vor der Suche nach anderen Kontierungsregeln geprüft.

• Ein Ausgleich offener Posten erfolgt nur bei exakter Übereinstimmung der Belegnummer.
• Wenn mehrere Belege erkannt werden, wird der Betrag auf mehrere Zeilen im Bankbuchungsblatt aufgeteilt (eine Zeile pro Belegnummer) und entsprechend ausgeglichen.
• Sollte nach der Aufteilung ein Restbetrag verbleiben, wird dieser als separate Zeile im Bankbuchungsblatt hinzugefügt und nicht kontiert.

Bausecura

Alte Funktionalität auf Obsolete ändern und ausblenden

Ausgangssituation

Die Kommunikation mit BauSecura erfolgte bislang über eine XML-Dateischnittstelle, bei der Daten lokal erzeugt und per E-Mail versendet wurden.

Auswirkung

Die dateibasierte Lösung war fehleranfällig, technisch veraltet und nicht optimal für eine automatisierte, sichere Kommunikation.

Anpassung

Die Schnittstelle wird zukünftig auf eine Webservice-basierte Kommunikation umgestellt. Im Zuge dieser Umstellung wurden in der Seite Instandhaltung Einrichtung die folgenden Felder entfernt bzw. intern auf obsolet gesetzt:

• „Dateinamenvorlage für BauSecura-Datenaustausch“
• „E-Mail BauSecura"

Neue Kachel Bausecura

Ausgangssituation

Eine direkte Übersicht über Schadensmeldungen, die über BauSecura abgewickelt werden, war bislang nicht in den Rollencentern verfügbar.

Auswirkung

Anwender mussten die entsprechenden Schadensmeldungen manuell suchen oder über Umwege aufrufen.

Anpassung

Es wurde eine neue Kachel BauSecura Monitoring implementiert in folgenden Rollencentern:

• RELion Technische Bearbeitung
• RELion Objektverwaltung
• RELion Objektbuchhaltung

Die Kachel zeigt die Anzahl der Schadensmeldungen, die über BauSecura abgewickelt werden. Beim Anklicken öffnet sich die Seite BauSecura Monitoring, in der die entsprechenden Schadensmeldungen aufgelistet sind.

Mahnwesen

Neue Mahnmethodik Business Central

Ausgangssituation

In einem Microsoft-Feature (wird mit Business Central 27 automatisch aktiviert) wird eine neue Mahnmethodenlogik (z. B.: bei Vortexte und Nachtexte, neue Mahnmethodenseite in den Mahnungen) beabsichtigt.
https://learn.microsoft.com/en-us/dynamics365/business-central/finance-automate-reminders

Anpassung

Für Relion ONE mussten Anpassungen vorgenommen werden. In diesem Release ist die neue Mahnmethodenlogik optional. Mit Business Central 27 wird es automatisch aktiviert. Mit diesem CU kann manuell die Funktionsverwaltung für die neue Mahnmethodenlogik aktiviert werden.

Wird mit diesem CU die Aktivierung manuell stattfinden sollte, bitte übertragen Sie die Texte einmalig (pro Mandant). Die Migrationsfunktion finden Sie unter:

Ergänzung der Mahnvorschlagsliste

Ausgangssituation

Die Mahnvorschlagsliste konnte bislang nicht vollständig und effizient bearbeitet werden. Es fehlten relevante Felder zur besseren Einschätzung und Bearbeitung offener Posten. Die Übersichtlichkeit und Nachvollziehbarkeit war eingeschränkt.

Auswirkung

Erweiterung der Inhalte der Mahnvorschlagsliste

• Zusätzliche Felder wurden ergänzt, insbesondere vor der Vertragsnummer:
  • Vertragsklasse
  • Vertragsart
  • Anzahl offene Mieten
  • Höhe der monatlichen Sollstellung
  • Vertragsbeginn/Ende
  • Kautionshöhe
• Ziel ist eine verbesserte Transparenz und Bearbeitungsmöglichkeit für die Anwender.

Aktualisierung der Mahnvorschlagsliste

• Die neuen Felder werden bei der Erstellung der Liste berechnet.
• Die bestehende Funktion Mahnvorschlagsliste aktualisieren wurde erweitert, um die neuen Inhalte zu berücksichtigen.

Abdruck der Mahnkommentare in Berichte

• Mahnkommentare werden nun in folgenden Berichten abgedruckt:
• Debitoren-OP nach Objekt
• Mahnauswertung je Einheit / Vertrag

Neues Feld „Mahnungskommentar“ (Lookup)

• Lookup auf alle Mahnkommentare, gefiltert nach Debitorennummer des Postens.
• Es kann genau ein Kommentar in das Feld übernommen werden („Kommentar“ wird übertragen).
• Das Lookup-Feld steht auch im Assistenten zur Verfügung.
• Die Beschreibung im Report wurde angepasst:
  • „Erfassen Sie die Änderungen, welche an der Mahnvorschlagsliste bzw. dem/den Debitorenposten durchgeführt werden sollen.“
• Wird der Report aus den Debitorenposten heraus aufgerufen, ist das Feld ausgegraut.
• Ist am Debitorenposten ein Mahnkommentar hinterlegt, wird dieser bei Erstellung der Mahnvorschlagsliste automatisch in das Feld übernommen.

Anpassung

Die oben genannten Änderungen wurden technisch umgesetzt und stehen mit dem nächsten Release zur Verfügung. Die Funktionalitäten wurden erweitert, ohne bestehende Abläufe zu beeinträchtigen

Filterfehler Mahnungskommentare: diese werden nicht überall angezeig

Ausgangssituation

Mahnungskommentare, die manuell an einem Debitorenposten erfasst wurden, enthielten korrekte Informationen zu Mietvertrag, Einheitennummer/Historie und Debitor. Diese Kommentare wurden jedoch nicht in der Ansicht des Debitors angezeigt. Ursache war ein fehlerhaft gesetzter Filter, der die Anzeige verhinderte.

Auswirkung

Die fehlende Anzeige führte zu Informationsverlusten bei der Bearbeitung von Mahnvorgängen. Insbesondere war es nicht möglich, Mahnungskommentare konsistent über verschiedene Sichten (Debitor, Mietvertrag, Posten) hinweg einzusehen. Dies beeinträchtigte die Nachvollziehbarkeit und Transparenz im Mahnprozess.

Anpassung

Die Filterlogik wurde überarbeitet und wie folgt angepasst:

• Debitorenposten: Filterung erfolgt nun über die lfd. Nr. des Debitorenpostens, um eine eindeutige Zuordnung sicherzustellen.
• Debitorenansicht: Filterung erfolgt ausschließlich über die Debitorennummer, um alle zugehörigen Kommentare sichtbar zu machen.
• Mietvertragsansicht: Der Filter wurde so angepasst, dass die Kommentare korrekt über die Vertragsreferenz angezeigt werden.
• Vertragsübersicht: Über die Vertragsübersicht können nun auch Mahnkommentare hinterlegt werden.

Wordlayouts

Dataset erweitern II.

Ausgangssituation

Im Bericht Vertragsschreiben standen bislang nur eingeschränkte Informationen zum Lastschriftmandat zur Verfügung.

Auswirkung

Für weiterführende Auswertungen und Dokumentationen fehlten relevante Felder, insbesondere im Zusammenhang mit SEPA-Mandatsdaten.

Anpassung

Das DataSet des Berichts wurde im Bereich Customer um folgende Felder erweitert:

• Art (CR_DDM_MandateType)
• Gültig ab-Datum (CR_DDM_StartDate)
• Gültig bis-Datum (CR_DDM_CompletionDate)
• Gläubiger-ID (CR_DDM_Identification)
• Typ (CR_DDM_Type)
• Unterschriftsdatum (CR_DDM_SignatureDate)
• Unterschriftsort (CR_DDM_SignaturePlace)

Zusätzliche Hinweise

Es werden nur Sammel- bzw. Vertragsmandate ausgewertet. Keine Einheiten- oder Sollstellungsmandate. Sofern für den Vertrag ein Vertragsmandat vorliegt, wird dieses ausgegeben. Existiert kein Vertrags- aber ein Sammelmandat, wird dieses ausgegeben.

Sondereigentumsverwaltung/Objekteigentümerverwaltung

Ausblenden der Funktion „Neue Version erstellen“ für SEV/OEV-Berichtsschemata

Ausgangssituation

Auf der Seite „Berichtsschema Übersicht“ sowie auf der Berichtsschema Karte war unter Aktionen/Funktionen die Option „Neue Version erstellen“ verfügbar – unabhängig von der Art des Berichtsschemas. Diese Funktion wurde ursprünglich für die Jahresvorschau entwickelt.

Auswirkung

Bei Auswahl dieser Funktion für Berichtsschemata der Art SEV-Verwaltung oder OEV-Verwaltung kam es wiederholt zu Problemen. Dies führte zu Anwenderfehlern und in der Folge zu Support-Tickets, die vermeidbar gewesen wären.

Anpassung

Die Funktion „Neue Version erstellen“ wird künftig nicht mehr angezeigt, wenn es sich um ein Berichtsschema der Art SEV oder OEV handelt. Die Auswahlmöglichkeit wurde sowohl in der Übersicht als auch auf der Karte entfernt.

Mitgliederwesen

Mitgliederstatistik Beträge nach Filterauswahl aktualisieren

Ausgangssituation

Die Seite Mitgliederzeilen enthielt bislang mehrere vordefinierte Ansichten wie Vorjahr Eintrittsgeld, Bis Vorjahr Anteilsbewegungen, Neue Anteile Vorjahr etc., um die Datenanzeige zu strukturieren bzw. insb. die Summenbildung im Fußbereich zu steuern.

Auswirkung

Ansichten überschreiben bestehende Filterbedingungen, was die kombinierte Filterung erschwerte und die Flexibilität bei der Datenauswahl einschränkte.

Anpassung

Die vorhandenen Ansichten wurden durch Schnellfilter ersetzt. Schnellfilter wirken ergänzend zur bestehenden Filterung und ermöglichen eine flexiblere und kombinierbare Datenauswahl.

Zusätzlich wurde der Fußbereich der Seite sowohl optisch als auch inhaltlich überarbeitet.

• Der aktuell ausgewählte Schnellfilter wird angezeigt.
• Änderungen am Schnellfilter sowie manuelle Eingriffe in die Filterbedingungen (z. B. zusätzliche Filter) werden bei der Berechnung der Werte sofort berücksichtigt.

Bericht Ratenzahlungsplan (Mitgliedskarte)

Ausgangssituation

Der Bericht Ratenzahlungsplan Mitglied war bislang ausschließlich als RDLC-Variante verfügbar.

Auswirkung

Eine flexible Weiterverarbeitung oder individuelle Anpassung des Berichts in Word war nicht möglich.

Anpassung

Der Bericht wurde nun auch als Word-Variante implementiert. Diese ist zusätzlich als Standardbericht markiert.

Mietanpassung

Vereinheitlichung Anz. Nachkommastellen in Indexschreiben => EINE Nachkommastelle

Ausgangssituation

Die Anpassungsprozentsätze im Indexschreiben wurden bislang zum Teil mit einer und teilweise mit zwei Nachkommastellen dargestellt.

Auswirkung

Die Darstellung wirkte teilweise übergenau und wich von der üblichen Praxis in vergleichbaren Dokumenten ab.

Anpassung

Die Darstellung der Anpassungsprozentsätze wurde an allen Stellen auf eine Nachkommastelle reduziert.

Geldflussdarstellung

Geldfluss Index verbessern

Die Perfomance beim Neuerstellen der Geldflussposten wurde um 30 % verbessert.

Geplante Instandhaltung

Report gebuchte Verkaufsgutschrift um Leistungszeitraum ergänzen

Ausgangssituation

Der Bericht “Inst. Verkauf – Gutschrift” druckt Gutschriften auf Basis der im System hinterlegten Daten. Eine explizite Darstellung des Leistungszeitraums war bislang nicht vorgesehen. Anders als in der Verkaufsrechnung, wo der Leistungszeitraum auch bisher schon ausgewiesen wurde. Die Verkaufsgutschrift wurde diesbezüglich nun nachgezogen.

Auswirkung

Die Nachvollziehbarkeit der abgerechneten Leistungen war eingeschränkt, da der Leistungszeitraum nicht direkt im Anschreiben ersichtlich war. Dies konnte zu Rückfragen und zusätzlichem Klärungsbedarf führen.

Anpassung

Der Bericht wurde um die Option „Leistungszeitraumzeile anzeigen“ erweitert. Bei Aktivierung dieser Option wird im Bericht eine zusätzliche Zeile mit Angabe des Leistungszeitraums angedruckt.

Zusätzliche Hinweise

Die Option ist standardmäßig deaktiviert und muss bei Bedarf manuell aktiviert werden. Die Erweiterung betrifft ausschließlich die Darstellung im Bericht und hat keine Auswirkungen auf die zugrunde liegenden Daten oder Berechnungen.

Projektentwicklung

Projektplanzeilen: Projektnummer und Projektbezeichnung in der Infobox einblenden

Ausgangssituation

Beim Öffnen der Projektplanzeilen über ein Projekt war bislang nicht ersichtlich, zu welchem Projekt die jeweilige Zeile gehört. Die Projektzugehörigkeit konnte nur über zusätzliche Filter oder Spalten ermittelt werden, was die Übersichtlichkeit beeinträchtigte.

Auswirkung

Nutzerinnen und Nutzer mussten zusätzliche Schritte unternehmen, um die Projektzuordnung zu erkennen.

Anpassung

Zur Verbesserung der Übersichtlichkeit und Benutzerfreundlichkeit wurde folgende Änderung umgesetzt:

Projektnummer und Projektbezeichnung werden nun in der Infobox im Bereich Projektplanzeilen Details angezeigt.

Fehlerbehebung

Instandhaltung

Vorbelegung der Option “Beleg archivieren” im Bericht Beauftragung korrigiert

Ausgangssituation

Mit dem Update CU12.20 wurde die Vorbelegung der Option Beleg archivieren im Bericht Beauftragung auf das übliche Standardverhalten umgestellt. Dabei wurde sowohl der Einrichtungsparameter zur initialen Belegung als auch die Zuletzt gewählte Option berücksichtigt.

Auswirkung

Die Option war beim Berichtaufruf unter bestimmten Umständen automatisch aktiviert, was zu unbeabsichtigter Archivierung von Belegen führen konnte.

Anpassung

Die Vorbelegung wurde korrigiert. Die Option Beleg archivieren ist beim Aufruf des Berichts nun sicherheitshalber immer deaktiviert und muss bewusst aktiviert werden.

Zusätzliche Hinweise

Mit dieser Änderung wird das Verhalten wiederhergestellt, das vor CU12.20 galt. Die bewusste Aktivierung soll eine versehentliche Archivierung vermeiden und die Kontrolle beim Anwender belassen.

Infobox “Klauseln Dienstleistungsvertrag” fehlt in Karten für Dienstleistungsvertrag, Wartungsvertrag und Versicherungsvertrag

Ausgangssituation

In den Dienstleistungvertragsseiten fehlte bislang eine Infobox über die hinterlegten Klauseln.

Auswirkung

Die Prüfung und Einsicht relevanter Vertragsklauseln war nur auf der zugehörigen Übersichtsseite möglich.

Anpassung

Die Infoxbox „Klauseln Dienstleistungsvertrag“ wurde in folgenden Seiten implementiert:

• Dienstleistungs-Vertrag
• Wartungsvertrag
• Versicherungsvertrag

Wirtschaftsplan/Abrechnung

Wirtschaftsplan-Berechnung neue Vorauszahlung arbeitet mit Ausnahmen fehlerhaft

Ausgangssituation

Im Wirtschaftsplan wurde auch dann eine neue Vorauszahlung berechnet und ausgegeben, wenn für eine Abrechnungsart ein Ausschlussgrund vorlag. Dies führte zu einer fehlerhaften Darstellung, insbesondere bei Mietverhältnissen mit Pauschalen oder expliziten Ausschlüssen.

Auswirkung

Die Ausgabe der neuen Vorauszahlung erfolgte fälschlicherweise trotz vorhandener Ausschlussgründe. Dies konnte zu Missverständnissen bei der Interpretation der Wirtschaftspläne führen.

Anpassung

Die Programmlogik wurde so angepasst, dass bei Vorliegen eines Ausschlussgrundes die neue Vorauszahlung zwar berechnet aber im der Wirtschaftsplan Einzelaufstellung nicht mehr angedruckt wird. Die Gesamtsumme je Einheit wird ebenfalls nicht mehr ausgegeben, wenn ein Ausschlussgrund vorliegt.

Abrechnungen - Wirtschaftsplan berechnet auf “JA” setzen dauert lange und bricht dann ab

Ausgangssituation

• Bei der Berechnung des Wirtschaftsplans wurde die Funktion „0-Zeilen löschen“ verwendet.
• Die Nutzung dieser Funktion hatte bei sehr großen Objekten keine spürbare Verbesserung der Verarbeitungsgeschwindigkeit zur Folge.
• Insbesondere bei Wirtschaftsplänen mit hoher Anzahl an Einheiten kam es zu langen Laufzeiten und teilweise zum Abbruch der Berechnung.

Auswirkung

• Die unzureichende Performance führte zu eingeschränkter Nutzbarkeit der Funktion bei umfangreichen Datenmengen.
• Anwender mussten auf manuelle Nachbearbeitung zurückgreifen, was den Arbeitsaufwand erhöhte.
• Die Berechnung konnte bei ca. 400 Einheiten und großem Kontenplan nicht zuverlässig abgeschlossen werden.

Anpassung

• Die Datenbeschaffung wurde optimiert: Bei Datenquellen mit ausschließlich Abrechnungsbezug werden nur relevante Kombinationen aus Konto und Abrechnungskreis bzw. Einheitennummer geladen.
• Objektkonten mit der Verwendung „Wirtschaftsplan“ werden in den Wirtschaftsplanzeilen weiterhin mit allen vorhandenen Abrechnungskreisen dargestellt, da sie häufig für Verwaltungspauschalen und manuell geplante Umlagen, quasi als Platzhalter verwendet werden.
• Das Löschen der Zeilen mit Betrag 0, kann jetzt bei Bedarf auch direkt aus der Wirtschaftsplankarte mit “Wirtschaftsplanzeilen mit Betrag 0 löschen” aufgerufen werden.

Auschluss-Grund für neue Vorauszahlungen im WP “Vertragsbeginn in Abr.-Periode” wird nicht gesetzt

Ausgangssituation

Bei der Erstellung der NK-Abrechnung wurde festgestellt, dass trotz Aktivierung des Ausschlussgrundes „Vertragsbeginn in Abr.-Periode“ neue Vorauszahlungen für Verträge berechnet wurden, deren Vertragsbeginn im Abrechnungsjahr liegen.

Auswirkung

Die fehlerhafte Prüfung führte dazu, dass Verträge mit einem Vertragsbeginn nach dem Abrechnungszeitraum nicht korrekt ausgeschlossen wurden. In der Folge wurden ungewollt neue Vorauszahlungen generiert.

Anpassung

Die Prüfung des Ausschlussgrundes T0105 wurde im Wirtschaftsplan korrigiert. Die Logik wurde dahingehend angepasst, dass Vertragsbeginne ab dem „Abrechnung von“-Datum korrekt als Ausschlusskriterium erkannt und berücksichtigt werden.

Fehler bei Abrechnungszeilen holen und Kontensaldo in Abrechnungszeilen im Fenster Abrechnungszeilen

Ausgangssituation

Bei der Funktion „Abrechnungszeilen holen“ sowie „Kontensaldo in Abrechnungszeilen Gesamt“ traten mehrere Probleme auf:

• Mit dem erneuten Holen der Abrechnungszeilen über die Aktionen in der Seite Abrechnungszeilen kamen eigenartige Fehlermeldungen.

Auswirkung

• Bei Verwendung der Funktion “Abrechnungszeilen holen” und “Kontensalden in Abrechnungszielen Gesamt” sowie “Abrechnung Detailwerte holen” gab es eine irreführende Fehlermeldung, die zu inkonsistenten Daten führen konnte.
• Dadurch konnten fehlerhafte oder doppelte Zeilen enthalten. Die Salden wurden nicht sauber aktualisiert.
• Die Nutzer erhielten irreführende Systemmeldungen, z. B. „Der Datensatz existiert bereits in der Tabelle Abrechnung Detailzeilen“.
• Zum Teil trat das Aktualisierungsproblem auch beim Abrechnung berechnen auf und führte in Kombination mit “Zeilen mit 0-Betrag löschen” zu falschen Abrechnungsergebnissen.

Anpassung

• Die Funktion „Abrechnungszeilen holen“ wurde überarbeitet, sodass die Anzeigereihenfolge korrekt wiederhergestellt wird.
• Die Saldenanzeige wurde stabilisiert.
• Wiederholtes Holen der Salden bzw. Aktualisieren der Salden ist wieder möglich.

Zusätzliche Hinweise

Beim Holen der Abrechnungszeilen über Abrechnungskarte trat dieses Problem nicht auf.

Wirtschaftsplan Ausschlussgründe funktionieren nicht wie erwartet

Ausgangssituation

Bei der Erstellung eines Wirtschaftsplans für den Zeitraum 01.01.2025 bis 31.12.2025 wurde festgestellt, dass der Ausschlussgrund “VZ-Beginn im Planungszeitraum“ nicht korrekt berücksichtigt wird. RELion erkennt zwar, dass für bestimmte Mieter bereits ein neuer Sollstellungsbetrag zum 01.01.2025 existiert, zieht daraus jedoch nicht die erwartete Konsequenz, diese Einheitenverträge von einer erneuten Anpassung auszuschließen.

Auswirkung

Die betroffenen Einheitenverträge werden trotz vorhandener manueller Anpassungen erneut im Rahmen der Wirtschaftsplan-Berechnung berücksichtigt. Dies kann zu fehlerhaften oder doppelten Sollstellungen führen und erhöht den manuellen Korrekturaufwand.

Anpassung

Die Berechnungslogik wurde dahingehend korrigiert, dass Einheitenverträge mit bereits vorhandenen Sollstellungen im Planungszeitraum nun zuverlässig ausgeschlossen werden. Der Ausschlussgrund wird nun wie erwartet interpretiert und umgesetzt.

Wirtschaftsplan berechnet die neue Vorauszahlung falsch

Ausgangssituation

Die Funktion zur Berechnung der monatlichen Vorauszahlungen berücksichtigte bisher Wirtschaftsplan Summenposten mit Ausschlussgründen nicht korrekt.

Auswirkung

In bestimmten Fällen wurden die Vorauszahlungsbeträge im Wirtschaftsplan fehlerhaft dargestellt.

Anpassung

Die Berechnungslogik wurde überarbeitet, sodass die monatlichen Vorauszahlungen jetzt in allen Fällen richtig berechnet und angezeigt werden.

Zusätzliche Hinweise

Die Änderung betrifft ausschließlich die Berechnung und Darstellung im Wirtschaftsplan.

Abrechnung Objekt Vorlage - Buchungsmethode auf Enum Umstellen

Ausgangssituation

• In der Vorlage zur Objektabrechnung war die Buchungsmethode „Pro-Forma-Abrechnung“ nicht als Auswahl verfügbar.
• Auf der Abrechnungskarte konnte diese Methode hingegen ausgewählt werden, was zu Inkonsistenzen in der Anwendung führte.

Auswirkung

• Anwender konnten die Buchungsmethode „Pro-Forma-Abrechnung“ nicht direkt in der Vorlage definieren.
• Dies führte zu Einschränkungen bei der automatisierten Verarbeitung und zu erhöhtem manuellem Aufwand bei der Abrechnungsvorbereitung.

Anpassung

• Die Auswahl der Buchungsmethode in der Vorlage wurde um die Option „Pro-Forma-Abrechnung“ erweitert.
• Mit Pro-Forma Abrechnungen können auch im laufenden Jahr Abrechnungen zur Vorschau erstellt werden.
• Eine Freigabe zum Druck, die Freigabe zum Buchen und das Buchen sind jedoch nicht verfügbar.

Abrechnung Statistik - auch wenn gebucht Aktualisierung ermöglichen

Ausgangssituation:

Die Abrechnungsstatistik war bei bereits gebuchten Abrechnungen deaktiviert.

Auswirkung:

Für bereits gebuchte Abrechnungen konnte die Statistik nicht nachträglich erstellt werden.

Anpassung:

Die Funktion “Zeilen aktualisieren” ist jetzt auch verfügbar wenn “Freigabe zum Buchen” oder “Gebucht” bereits auf Ja stehen

Verwalterhonorar

Keine Zeilendimensionen in Verkaufsrechnungen

Ausgangssituation

Bei Verwalterhonorarverträgen, die vor dem aktuellen Release angelegt wurden, sind keine Aufwand- bzw. Ertrags-Dimensionen hinterlegt. Dies führt dazu, dass beim Erstellen einer Verkaufsrechnung über die Stapelverarbeitung die Verkaufszeilen auch keine Standarddimensionen mehr enthalten. Daher kann die Verkaufsrechnung nicht gebucht werden.

Auswirkung

Die fehlenden Dimensionen verhindern die Buchung der Verkaufsrechnung.

Anpassung

Beim Erstellen der Verkaufsrechnung werden sowohl die Dimensionen aus der Verwalterhonorarvertragszeile als auch aus der erstellten Verkaufszeile zusammengeführt. Es spielt keine Rolle mehr, ob die Aufwands- bzw. Ertrags-Dimensionen gefüllt sind.

Verwaltergebührenabrechnung funktioniert nicht

Ausgangssituation

Beim Aufruf der Funktion „Verwalterhonorar Stapelberechnung“ kam es zu einer unerwartet langen Laufzeit, wenn in der Abrechnung Verträge verarbeitet wurden, deren Vertragsende vor dem Ende des Abrechnungszeitraums lag.

Auswirkung

Die Berechnung wurde in diesen Fällen nicht abgeschlossen und das System reagierte nicht mehr wie erwartet. Ein manueller Eingriff war erforderlich, um den Vorgang zu beenden.

Anpassung

Die Ursache für die blockierende Verarbeitung wurde behoben. Die Funktion verarbeitet nun auch Verträge mit einem Vertragsende vor dem Abrechnungszeitraum korrekt und ohne Unterbrechung.

Zusätzliche Hinweise

Die fachliche Logik der Berechnung bleibt unverändert. Die Änderung betrifft ausschließlich die technische Stabilität und Performance der Funktion.

Berichte

Berichtslayout kann nicht hochgeladen werden - (BC Online): Fehlermeldung wg. Schriftart Courier

Ausgangssituation

Die Berichte

• Mietrechnung
• Registrierte Mietrechnung
• Stornierte Mietrechnung verwendeten bislang die Schriftart „Courier New“ bei einem internen Control.

Auswirkung

In Business Central Online (Cloud) kam es zu Fehlermeldungen im Zusammenhang mit der Schriftart „Courier New“, da diese dort nicht zuverlässig unterstützt wird.

Anpassung

Die intern verwendete Schriftart wurde auf „Segoe UI“ umgestellt. Diese ist systemseitig verfügbar und kompatibel mit der Cloud-Umgebung.

Zusätzliche Hinweise

Die Umstellung betrifft ausschließlich die technische Darstellung. Inhalt und Layout der Berichte bleiben unverändert.

Seriendruckfeld “Firmendaten_PLZ” wird nicht gefüllt

Ausgangssituation

In Word-Vorlagen, die das Seriendruckfeld Firmendaten_PLZ enthalten, wurde dieses Feld im Berichtsdaten-Zwischenspeicher nicht oder nicht korrekt belegt. Die Postleitzahl der Firma fehlte oder war falsch, obwohl entsprechende Adressdaten in der Objektkarte vorhanden waren.

Auswirkung

Berichte, die auf dem Feld Firmendaten_PLZ basieren, enthielten keine oder falsche Postleitzahlen. Dies führte zu fehlerhaften Dokumenten.

Anpassung

Die Logik zur Befüllung des Berichtsdaten-Zwischenspeichers wurde überarbeitet.

• Ist die Verwaltung-Zuständigkeitseinheit in der Objektkarte nicht belegt, wird die PLZ der Firma aus der Eigentümer-Zuständigkeitseinheit übernommen.
• Ist die Verwaltung-Zuständigkeitseinheit belegt, wird die PLZ der Firma aus der Verwaltung-Zuständigkeitseinheit übernommen.

Korrektur fehlerhafter Schriftartbezeichnungen

Ausgangssituation

In mehreren RDLC-Layouts innerhalb der Module: Mitgliederverwaltung, Mietanpassung und in den Objekt Abrechnungsübersichten für WEG und Miete wurden z.T. fehlerhafte Schriftartbezeichnungen verwendet.

Auswirkung

Die fehlerhaften Schriftartbezeichnungen konnten zu Darstellungsproblemen in den generierten Berichten führen.

Anpassung

Die Schriftartbezeichnungen in den betroffenen RDLC-Dateien wurden korrigiert. Es werden ausschließlich die Schriftarten Segoe UI und Courier New verwendet, um eine konsistente und korrekte Darstellung sicherzustellen.

Zusätzliche Hinweise

Die Korrekturen betreffen ausschließlich die Schriftartbezeichnungen in den Layout-Dateien. Inhaltliche oder strukturelle Änderungen an den Berichten wurden nicht vorgenommen.

WEG

Korrektur der Adressanzeige in der Beschlusssammlung

Ausgangssituation

Beim Druck der Beschlusssammlung wurde im Kopfbereich stets die Adresse des ersten Objekts aus der Objektliste ausgegeben, unabhängig davon, welches Objekt tatsächlich ausgewählt oder relevant war.

Auswirkung

Die fehlerhafte Adressanzeige führte zu Verwirrung bei Endanwendern und potenziell falscher Dokumentation in ausgedruckten Unterlagen.

Anpassung

Die Adresszeile im Kopfbereich der Beschlusssammlung wurde angepasst. Ab sofort wird die korrekte Adresse des jeweils relevanten Objekts angezeigt.

Mietanpassung

Sollmietenveränderung berücksichtigt Vertragsende nicht /steg Hamburg

Ausgangssituation

Im Bericht Sollmietenveränderung wurde das Vertragsende bislang nicht korrekt berücksichtigt. Dies konnte dazu führen, dass Brutto- und Nettowerte mehrfach ausgewiesen wurden – insbesondere im Zusammenhang mit Leerstandssollstellungen.

Auswirkung

Die Auswertung enthielt in bestimmten Fällen Doppelrechnungen, was zu fehlerhaften Darstellungen und potenziellen Abweichungen in der Analyse führte.

Anpassung

Die Berechnungslogik wurde dahingehend korrigiert, dass das Vertragsende nun korrekt berücksichtigt wird. Brutto- und Nettowerte werden nur für den tatsächlich gültigen Vertragszeitraum ausgewiesen.

Fehlende Variable in Berichtstextsteuerung Indexscheiben

Ausgangssituation

In der Berichtstextsteuerung für das Indexmietschreiben stand bislang die Variable WIN:SNJ zur Verfügung, um Texte gezielt nur bei Vorliegen einer Nachzahlung einzublenden.

Auswirkung

Es war nicht möglich, Texte ausschließlich dann anzuzeigen, wenn keine Nachzahlung vorliegt.

Anpassung

Die Berichtstextsteuerung wurde um die Variable WIN:SNN erweitert. Sie stellt das Gegenstück zu WIN:SNJ dar und ermöglicht die gezielte Steuerung von Texten für den Fall, dass keine Nachzahlung vorliegt.

Texte, die nur angedruckt werden sollen, falls eine Nachzahlung vorliegt, werden mit der Bedingung WIN:SNJ gesteuert. Texte, die nur angedruckt werden sollen, falls keine Nachzahlung vorliegt, werden mit der Bedingung WIN:SNN gesteuert. Beispiele:

WIN:SNJWir bitten Sie höflich um Kenntnisnahme und Überweisung des neuen Mietzinses ab dem folgenden Monat i.H.v. VIN:GB EUR sowie um Nachzahlung für den Zeitraum bis i.H.v. VIN:GBN EUR auf das oben genannte Konto der Vermieterin. WIN:SNNWir bitten Sie höflich um Kenntnisnahme und Überweisung des neuen Mietzinses ab dem folgenden Monat i.H.v. VIN:GB EUR auf das oben genannte Konto der Vermieterin.

Anpassung Umsatzmietschreiben

Ausgangssituation

Im Anschreiben zur Umsatzmietabrechnung wurde der Steueranteil sowie die Gesamtsumme (brutto) bislang nur in den Spalten „Anspruch Betrag“ und „Gesamtsaldo“ ausgewiesen. In der Spalte „Angeforderte Zahlungen“ fehlte diese Information.

Auswirkung

Die Darstellung war uneinheitlich und erschwerte die vollständige Nachvollziehbarkeit der angeforderten Beträge.

Anpassung

Die Spalte „Angeforderte Zahlungen“ wurde dahingehend erweitert, dass nun ebenfalls der Steueranteil sowie die Gesamtsumme (brutto) ausgewiesen werden.

Zusätzlich wurde die Formatierung angepasst:

• Die Werte in den Spalten „Angeforderte Zahlungen“ und „Anspruch Betrag“ werden nicht mehr fett gedruckt.
• Die Werte in der Spalte „Gesamtsaldo“ werden weiterhin fett gedruckt.

Indexschreiben (Word) falsch formatiert

Ausgangssituation

Das Word-Layout des Indexmietschreibens wich in Formatierung und Darstellung vom vorhandenen RDLC-Layout ab. Insbesondere waren die Abstände zwischen Bezeichnern und Werten teilweise zu groß und uneinheitlich.

Auswirkung Die optische Darstellung war weniger kompakt und wirkte im Vergleich zum RDLC-Bericht uneinheitlich.

Anpassung

Das Layout des Word-Dokuments wurde überarbeitet und dem RDLC-Layout angeglichen. Die Abstände zwischen Bezeichnern (z. B. „Bearbeiter“, „Telefonnr.“, „IBAN“ etc.) und den zugehörigen Werten wurden verkleinert. Zudem wurden überflüssige Doppelpunkte entfernt. Außerdem wurde die Darstellung der Tabellen überarbeitet und vereinheitlicht.

Mietverwaltung

Filter aktive Mietverträge funktioniert nicht wenn weitere Filter aktiv

Ausgangssituation

In diversen Vertragsseiten (z. B. Mietverträge, Wohnraummietverträge, Gewerbemietverträge sowie Mietverträge für Garagen und Stellplätze) wurden mit RELion One Ansichten wie „Aktive“, “Zukünftige” und „Beendete“ etc. eingeführt.

Auswirkung

Ansichten wirken nicht additiv, d. h. bei Auswahl einer Ansicht wird eine zuvor gesetzte Filterung (z. B. nach Mieternamen) überschrieben. Dies führte in der Praxis zu Einschränkungen bei der gezielten Datenauswahl.

Anpassung

Die Ansichten wurden durch die aus früheren RELion-Versionen bekannten Schnellfilter ersetzt. Schnellfilter wirken ergänzend zur bestehenden Filterung und ermöglichen eine flexiblere und kombinierbare Datenauswahl.

Im Zuge dieser Umstellung wurde auch die Auswahl „Genehmigungsstatus“ als Schnellfilter implementiert. Diese ersetzt die bisherige Auswahl über eine Radiobutton-Abfrage.

Zusätzliche Hinweise

Es existieren weitere Seiten, die aktuell noch Ansichten verwenden (z.B. Vertragsübersicht. WEG-Kaufverträge, SEV-Verträge usw.). Diese werden mit künftigen RELion-Versionen ebenfalls angepasst.

Einzelwertberichtigung Miete ermittelt den Saldo zum Stichtag falsch

Ausgangssituation

Im Bericht wird zur Ermittlung der Spalte Saldo Stichtag ohne USt. ein Stichtag verwendet. Die Berechnung dieses Wertes war fehlerhaft, da nachträgliche Postenausgleiche, die bis zum Erstellungsdatum des Berichts erfolgt sind, in die Berechnung einbezogen wurden. Dadurch konnte der Report bei unterschiedlichen Erstellungsdaten abweichende Werte für denselben Stichtag liefern.

Auswirkung

Die inkonsistente Berechnung führte dazu, dass sich die Ergebnisse für die Zuführung oder Auflösung aus der Einzelwertberichtigung (EWB) je nach Erstellungsdatum des Berichts unterschieden. Dies verursachte einen erheblichen manuellen Prüfaufwand, da keine andere systemseitige Auswertung zur Verfügung stand, um die Differenzen nachvollziehbar zu belegen.

Anpassung

Die Berechnungslogik des Berichts wurde angepasst. Künftig wird bei der Ermittlung des Saldo Stichtag ohne USt. ausschließlich der offene Posten zum gewählten Stichtag berücksichtigt. Nachträgliche Postenausgleiche, die nach dem Stichtag erfolgt sind, fließen nicht mehr in die Berechnung ein. Damit liefert der Report unabhängig vom Erstellungsdatum stets konsistente Werte zum gewählten Stichtag.

Mietkaufassistent schlägt bereits ausgezogenen Mieter für Übereignung vor

Ausgangssituation

Bisher war das Systemverhalten wie folgt:

• Der Mieter aus dem aktuellen Mietvertrag wurde unter bestimmten Umständen nicht korrekt vorgeschlagen
• Das Feld „Neuer Vertragsbeginn“ war nicht vorbelegt
• Die Seite zum Lastschriftmandat im Assistenten wurde nur angezeigt, wenn die Option „Lastschriftmandat anlegen“ auf „Ja“ gesetzt war.
• Das Feld „Typ“ im Lastschriftmandat war nicht automatisch vorbelegt.

Auswirkung

Durch die vorgenommenen Änderungen ergeben sich folgende Verbesserungen für die Endanwender:

• Der Mieter aus dem aktuellen Mietvertrag wird nun korrekt vorgeschlagen
• Das Feld „Neuer Vertragsbeginn“ wird automatisch mit dem aktuellen Arbeitsdatum vorbelegt.
• Die Seite zum Lastschriftmandat wird nun unabhängig von der Auswahl der Option „Lastschriftmandat anlegen“ angezeigt.
• Das Feld „Typ“ im Lastschriftmandat ist nun standardmäßig mit der Option „CORE“ vorbelegt.

Anpassung

Die Änderungen wurden wie folgt umgesetzt:

• Erweiterung der Logik zur Anzeige des Mieters basierend auf dem aktuellen Mietvertrag.
• Automatische Vorbelegung des Feldes „Neuer Vertragsbeginn“ mit dem Arbeitsdatum bei Erstellung eines neuen Vertrags.
• Anpassung des Assistentenflusses, sodass die Seite zum Lastschriftmandat immer angezeigt wird.
• Einführung einer Standardvorbelegung für das Feld „Typ“ mit dem Wert „CORE“.

Einkauf

Programmänderung zur Buchung von Einkaufsrechnungen über Mehrfachauswahl

usgangssituation

Bei der Buchung mehrerer Einkaufsrechnungen über die Mehrfachauswahl wurden Einbehalte aus Projekt-Teil- und Schlussrechnungen nicht korrekt verarbeitet. Es wurden keine Posten für TR- oder SR-Einbehalte erstellt. Zudem wurden bestehende Einbehalte bei Schlussrechnungen nicht aufgelöst. Die Kreditorenposten blieben offen mit vollem Restbetrag.

Auswirkung

Fehlende Buchungsposten führten zu inkorrekten offenen Beträgen und potenziellen Folgefehlern in der Rechnungsbearbeitung.

Anpassung

Projektrechnungen werden künftig bei der Buchung über die Mehrfachauswahl ausgeschlossen. Es erfolgt eine Prüfung, ob markierte Rechnungen Projektrechnungen enthalten. Die Buchungslogik wurde angepasst, sodass bei Auswahl mehrerer Rechnungen Projektrechnungen nicht verarbeitet werden. Ein Hinweis im Anschluss an die Buchung weist auf die nicht berücksichtigten Rechnungen hin.

Validierung Freistellungsbescheinigung greift nicht

Ausgangssituation:

In der Einkaufsrechnung wurde der Status zur Prüfung gemäß §48 EStG nicht mehr automatisch gesetzt, wenn ein entsprechendes Konto verwendet wurde. Ursache war eine Änderung im Rahmen von CU12.27, die im Bereich der Einkaufsbestellung vorgenommen wurde und sich auf die automatische Vorbelegung auswirkte.

Auswirkung:

Die Prüfung gemäß §48 EStG musste manuell angestoßen werden, was zu Mehraufwand und potenziellen Fehlern in der Bearbeitung führte.

Anpassung:

Die automatische Vorbelegung des Prüfstatus wurde wiederhergestellt. Wird in der Einkaufsrechnung ein Konto verwendet, das der Prüfung nach §48 EStG unterliegt, wird der Status nun wieder automatisch auf „Zu prüfen“ gesetzt.

EK-Gutschrift Betrag wird nicht in Indizes übertragen

Ausgangssituation

Beim Buchen einer EK-Gutschrift, wenn diese über Continia erstellt und nach Archiv Kompakt archiviert werden soll, wird der Betrag nicht mit übergeben.

Auswirkung

Der Index Betrag bleibt leer. Es muss in ArchivKompakt manuell der Wert eingetragen werden.

Anpassung

Das Programm wurde dahingehend angepasst, dass der korrekte Betrag nachträglich gefüllt wird, analog der EK-Rechnung. Damit wird eine nachträgliche Bearbeitung des Index obsolet.

Mahnwesen

Spalte “Bemerkungen” kann in RELion ONE nicht bearbeitet werden

Ausgangssituation

In früheren Versionen von RELion war es möglich, im Rahmen eines Mahnvorgangs das Feld bzw. die Spalte „Bemerkungen“ innerhalb der Seite RE Mahnvorgänge zu befüllen. Diese Funktion wurde von Anwendern genutzt, um individuelle Hinweise oder ergänzende Informationen zu einzelnen Mahnvorgängen zu dokumentieren.

Auswirkung

Die fehlende Bearbeitbarkeit des Feldes führte zu Einschränkungen in der internen Dokumentation und Kommunikation innerhalb des Mahnprozesses. Anwender konnten keine individuellen Hinweise mehr hinterlegen, was insbesondere bei komplexen oder mehrfach bearbeiteten Vorgängen zu Informationsverlusten führte.

Anpassung

Im Rahmen der Produktpflege wurde die Bearbeitbarkeit des Feldes „Bemerkungen“ im Mahnvorgang wiederhergestellt. Die Anpassung umfasst:

• Aktivierung des Eingabefeldes für Bemerkungen in der Seite RE Mahnvorgänge.
• Sicherstellung der Übernahme der eingegebenen Bemerkungen in nachgelagerte Prozesse, insbesondere in die registrierten Mahnungen.
• Integration in die Vorschlagsliste, sodass Bemerkungen auch bei der Erstellung und Bearbeitung von Mahnvorschlägen sichtbar und editierbar sind.

Reg. Mahnungen falsches Buchungsdatum und Belegnr. aus 2024

Ausgangssituation

Bei der Registrierung von Mahnungen über die Mahnungen wurde festgestellt, dass das in der Request Page eingetragene Buchungsdatum dauerhaft gespeichert blieb. Dieses Datum wurde bei nachfolgenden Mahnvorgängen automatisch übernommen, auch wenn ein neuer Mahnvorgang mit einem anderen Buchungsdatum gestartet wurde.

Auswirkung

• Das Buchungsdatum wurde in den Mahnköpfen, Mahnübersichten und Mahnposten inkorrekt überschrieben.
• Die Belegnummern wurden dadurch ebenfalls dem Jahr 2024 zugeordnet.
• In den Mahnzeilen wurde das ursprünglich korrekte Buchungsdatum weiterhin angezeigt, was zu Inkonsistenzen führte.
• Die Ursache war ein persistenter Parameterwert in der Request Page, der nicht automatisch zurückgesetzt wurde.

Anpassung

Die Ursache wurde identifiziert und behoben. Die Parameter der Request Page wurden so angepasst, dass das Buchungsdatum nicht mehr über Mahnvorgänge hinweg gespeichert bleibt

Sollstellung

Fehlermeldung beim Buchen unklar

Ausgangssituation

Beim Ausführen der Buchungsvorschau im Sollstellungsbuchblatt trat eine Fehlermeldung auf, deren Inhalt für Anwender nicht nachvollziehbar war. Die Ursache lag in einem nicht freigegebenen Zeitraum in der Finanzbuchhaltungseinrichtung. Die Meldung war technisch formuliert und ließ keine Rückschlüsse auf den tatsächlichen Konflikt zu.

Auswirkung

Die unklare Fehlermeldung führte zu Unsicherheit bei den Anwendern und erschwerte die Fehleranalyse. Insbesondere bei automatisierten Buchungsvorgängen war nicht ersichtlich, warum die Buchungsvorschau fehlschlug. Dies führte zu Rückfragen beim Support und verzögerte die Bearbeitung.

Anpassung

Die Fehlermeldung wurde überarbeitet und so angepasst, dass der zugrunde liegende Konflikt – ein nicht freigegebener Zeitraum – nun eindeutig und verständlich kommuniziert wird. Die neue Meldung erscheint zuverlässig beim ersten Ausführen der Buchungsvorschau, auch nach einem Neustart des Clients.

Funktion “Erstelle Plansollstellungen” erstellt inkonsistente Einträge

Ausgangssituation

Beim Erstellen von Plansollstellungen konnte bislang nicht nachvollzogen werden, warum in bestimmten Fällen keine neue Plansollstellung erzeugt wurde.

Auswirkung

Fehlende Rückmeldungen führten zu Unsicherheit bei der Bedienung und erschwerten die Fehleranalyse.

Anpassung

Die Funktion wurde dahingehend erweitert, dass nun eine Fehlermeldung protokolliert wird, wenn keine neue Plansollstellung erzeugt werden kann, weil bereits eine bestehende Plansollstellung für den gewählten Zeitraum und die gewählte Plansollstellungsart vorhanden ist.

Konkret betrifft dies folgende Fälle:

• Es existiert bereits eine Plansollstellung mit exakt gleichem Startdatum (ohne Enddatum) für die gewählte Plansollstellungsart.
• Es existiert eine Plansollstellung mit Start- und Enddatum, wobei das Startdatum der neu anzulegenden Plansollstellung in diesen Zeitraum fällt.

In allen anderen Fällen wird die neue Plansollstellung wie gewohnt angelegt. Dabei werden ggf. vorhandene Plansollstellungen der gleichen Art beendet oder die neue Plansollstellung mit einem Endedatum versehen – abhängig von der zeitlichen Überschneidung mit bestehenden Einträgen.

Geplante Instandhaltung

Buchung von Einkaufsrechnungen ohne Projektposten bei abweichender RE-Kontogruppe

Ausgangssituation

Bei der Buchung von Projekt-Einkaufsrechnungen wurden in bestimmten Fällen keine Projektposten erzeugt. Dies trat auf, wenn an dem gewählten Objektkonto (Baukonto) nicht die RE-Kontogruppe „Kosten“ bzw. “Kosten/Zahlung” hinterlegt war.

Auswirkung

Es wurden keine Projektposten gebildet

Anpassung

Bei Auswahl des Objektkontos in der Projektplanzeile werden nur die Objektkonten angezeigt, die im Feld RE Kontengruppe “Kosten” oder “Kosten/Zahlung” hinterlegt haben

Stammdaten

Einrichtung Freigabeverfahren Kreditor bei Stammdatensynchronisierung

Ausgangssituation

In der bisherigen Version der Zahlungsverkehr-Einrichtung war keine automatisierte Sperrlogik für Kreditoren bei Änderungen an deren Bankverbindungen implementiert. Änderungen an Kreditorenbanken konnten vorgenommen werden, ohne dass dies Auswirkungen auf die Zahlungsfreigabe des zugehörigen Kreditors hatte.

Auswirkung

Mit der neuen Option im Register „Kreditor“ der Zahlungsverkehr-Einrichtung wird bei bestimmten Aktionen an der Kreditorenbank automatisch das Feld „Gesperrt“ auf der Kreditorenkarte auf den Wert „Zahlung“ gesetzt. Dies betrifft folgende Aktionen:

• Änderung der Bankverbindung
• Neuanlage einer Bankverbindung
• Löschung einer Bankverbindung Der Kreditor ist dadurch für den Zahlungsverkehr gesperrt, bis eine Freigabe erfolgt.

Anpassung Die neue Option kann in der Zahlungsverkehr-Einrichtung aktiviert werden. Ist sie aktiv, erfolgt die automatische Sperrung wie oben beschrieben. Die Anpassung wurde auch für die Stammdatensynchronisierung implementiert. Zur Freigabe des Kreditors für den Zahlungsverkehr muss das Feld „Gesperrt“ manuell auf leer gesetzt werden. Dies darf nicht durch den Benutzer erfolgen, der die Änderung an der Bankverbindung vorgenommen hat. Die Freigabe muss durch einen anderen Benutzer durchgeführt werden.

Zahlungsverkehr

Fehler bei der Erstellung der Verknüpfungen zu einer globalen Adresse

1. Fehlerhafte Bankdaten in Verknüpfungen

Ausgangssituation

Bei aktivierter Synchronisation von Adressdaten über mehrere Mandanten hinweg wurden bei Änderungen an globalen Adressen oder zugehörigen Debitoren, Kreditoren oder Kontakten die Verknüpfungen neu aufgebaut. Dabei wurden die Bankdatenfelder in den Verknüpfungen mit zufälligen Bankkontodaten belegt – abhängig vom zuletzt gelesenen Datensatz.

Auswirkung

In den Verknüpfungssätzen zu Debitoren, Kreditoren und Kontakten wurden inkonsistente oder falsche Bankverbindungen gespeichert. Dies konnte zu Problemen bei der Weiterverarbeitung führen.

Anpassung

Die Initialisierung der Verknüpfungssätze wurde korrigiert.

• Bei der Erstellung von Verknüpfungen dieser Art werden keine Bankdaten mehr übernommen. Die Bankdatenfelder bleiben leer.

Zusätzliche Hinweise

Für Bankkonten bestehen separate Verknüpfungssätze, bei denen die Bankdaten entsprechend gefüllt sind.

2. Fehlende Verknüpfungen bei Kontaktkopien

Ausgangssituation

Bei aktivierter Synchronisation von Adressdaten und Kontaktnummern über mehrere Mandanten hinweg wurden beim Anlegen eines neuen Kontakts in einem Mandanten zwar automatisch Kopien in anderen Mandanten erstellt, jedoch ohne die zugehörigen Verknüpfungssätze.

Auswirkung

Die automatisch erzeugten Kontaktkopien waren nicht mit der globalen Adresse verknüpft. Dies führte zu unvollständigen Datenbeziehungen und potenziellen Fehlern in den Auswertungen.

Anpassung

Die Erstellung der Kontaktkopien wurde so angepasst, dass die Verknüpfungssätze für jede Kopie immer angelegt werden.

RELion Dokumente

Archivierung von Archiv kompakt, wenn Objektnr. geändert, wird diese nicht validiert

Ausgangssituation

Nachdem Dokumente in Archiv kompakt archiviert wurden und Objektnr. mit den dazu gehörigen Adressdaten gefüllt war, konnte man anschließen die Objektnr. ändern ohne dass dies als Fehler angezeigt wurde.

Auswirkung

Es wurden falsche oder nicht existierende Objektnr. nach RELion ungeprüft übertragen. Dies führte zu falschen Daten.

Anpassung

Es wurde eine Prüfung der Objektnr. unabhängig von deren Adresse implementiert. Zusätzlich wurde eine Validierung des Wertes für alle Felder implementiert, die eine Tabellenrelation hatten.

Zusätzliche Hinweise

Die Änderung wirkt sich nur auf zukünftige Prüfungen aus. Bereits falsch nach RELion übertragene Objektnr. müssen manuell in Archiv Kompakt geändert werden, um anschließend nach RELion übertragen zu werden.

Fehlermeldung “Typ NAVInteger ist unbekannt”

Ausgangssituation

Beim Speichern eines aus Archiv Kompakt kommenden Dokuments wird versucht die korrekte RecordID mit zu geben. Wenn der Index Belegnr. gefüllt ist und es sich bei dem Beleg um keine EK- oder VK-Rechnung oder -Gutschrift handelt wird geprüft, ob es sich um ein Bankposten handelt. Dort wurde die Dokumentnummer übergeben anstatt danach zu filtern, wodurch der Fehler aufgekommen war.

Auswirkung

Dokumente, die aus Archiv Kompakt kamen konnten nicht nach RELion übertragen werden. Sie blieben bei den Statuszeilen mit der Fehlermeldung “stecken”.

Anpassung

Das Programm wurde dahingehend angepasst, dass bei Bankposten die Filterung korrekt übergeben wird. Dadurch kommt es hier zu keinem Fehler mehr und zukünftige Dokumente können nach RELion übertragen werden.

Zusätzliche Hinweise

Die Änderung greift für zukünftige Dokumente, die nach RELion übertragen werden. Dokumente, die sich aktuell in den Statuszeilen mit der Fehlermeldung befinden, müssten einmal manuell abgearbeitet werden. Dazu markiert man alle Zeilen mit dieser Fehlermeldung und führt die Aktion Datensatz verarbeiten aus.

Sonstiges

Global-RE Branchen: Fehlerhafte Filteranzeige (redundant in Zeile)

Ausgangssituation

Die Filteranzeige wurde bislang in jeder Zeile der Seite „Globale-RE Branchen“ redundant dargestellt.

Auswirkung

Die wiederholte Anzeige führte zu einer verwirrenden Darstellung.

Anpassung

Die Filteranzeige wird nun nur noch einmalig im Fußbereich der Seite dargestellt.

Berechtigungssätze

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

Objekt ID	Objektname	Berechtigungssatz	Name
5052503	RelC Identified Cust. Ledger	R12 OBJEKTVW; RE12 BUHA	REL Objektverwaltung Aareon; REL Buchhaltung Aareon

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

Tabelleninformationen Modell

Änderungen im Datenmodell werden in den Tabelleninformationen angezeigt.

Hotfix

Version 28.1

Validierung von Unit No. und Unit History verursacht Fehlermeldung

Ausgangssituation

In den RELion-Dokumenten hatten einige Feldvalidierungen keinen Filter auf den aktuellen Mandanten. Als eine Prüfung der Felder beim Archivieren hinzugefügt wurde, um zu verhindern, dass von Archiv Kompakt ungültige Daten nach RELion übertragen werden, griff diese Prüfung auch beim Archivieren der Dokumente in RELion nach Archiv Kompakt, und zwar bei der Speicherung der AAK Dokument ID.

Auswirkung

Wurde der Aufgabenwarteschlangenposten in einem Mandanten angelegt, der gewisse Objekte, Kreditoren oder Debitoren nicht besaß, wurde nach dem erfolgreichen Archivieren der RELion-Dokumente bei dem anschließenden Zurückschreiben der AAK Dokument ID diese Feldprüfung durchgeführt. Allerdings konnten die Objekte in diesem Mandanten nicht gefunden werden und es wurde die Fehlermeldung „Im Filter wurde folgendes nicht gefunden…“ ausgegeben.

Anpassung

Die entsprechenden Felder bekamen einen Filter auf den Mandanten, in dem das RELion-Dokument angelegt wurde. Zusätzlich wurde die Feldvalidierungsfunktion aus der Modify-Funktion entfernt und dort eingefügt, wo direkt das Dokument erzeugt wird. Dies verhindert, dass die Validierung der Felder mehrmals durchlaufen wird.

Index Ändern auf AAK Seite EM/Objekt führt zu Fehler im RELion

Ausgangssituation

In Archiv Kompakt wird bei einem Dokument der Index für Objektnr. und Eigentümer/Mieter nach einer in einem anderen Mandanten existierenden Kombination bearbeitet und die Änderung gespeichert. In den RELion Dokumente Statuszeilen wird diese Änderung aufgelistet und sie läuft auf einen Fehler, da die erneute Prüfung auf korrekte Objektnr.-E/M-Kombination nicht mandantenübergreifend prüft.

Auswirkung

Das geänderte Dokument kann nicht nach RELion übertragen werden und eine weiterführende Bearbeitung ist nicht möglich.

Anpassung

Bei der Prüfung der Felder Objektnr. und Eigentümer/Mieter wurde zusätzlich die Abfrage nach dem Mandanten eingebaut. Dadurch wird der Fehler vermieden und eine Änderung am Dokument in Archiv kompakt wird nach RELion übertragen.

Zusätzliche Hinweise

Die bereits in den Statuszeilen auf Fehler stehenden Einträge müssen manuell über “Aktion -> Datensatz verarbeiten” verarbeitet werden, damit sie nach RELion übertragen werden.