Version 12.38

☝️XML-Berechtigungen werden mit dem Release 12.40 im Oktober 2026 das letzte Mal ausgeliefert

RELion ONE stellt die Berechtigungsverwaltung künftig vollständig auf Systemberechtigungen (RELC, System) um. XML-Berechtigungen (R12) werden nur noch bis Ende Oktober 2026 gepflegt.

Weitere Details finden Sie in der Dokumentation.

Build

Neue und geänderte Funktionen

Buchhaltung

Verbesserungen beim Aufruf der Funktion § 15a Planposten erstellen

Ausgangssituation

• Die Funktion Planposten erstellen wird über das Rollencenter Objektbuchhalter aufgerufen.
• Wird der Bericht mit Drucken oder Senden an PDF ausgeführt, werden beim nächsten Aufruf aufgrund der Funktion Standardwerte verwenden von die zuletzt verwendeten Optionen übernommen.
• Dabei wurde das Feld Startdatum automatisch vorbelegt und gleichzeitig für die Bearbeitung gesperrt.
• Um das Startdatum ändern zu können, musste zunächst die Option Rückwirkende Korrektur deaktiviert und anschließend wieder aktiviert werden.
• Die Vorbelegung des Startdatums mit dem ersten Tag des aktuellen Monats entsprach nicht dem üblichen Anwendungsfall, da Planposten häufig für die Umsatzsteuer-Voranmeldung vergangener Zeiträume erstellt werden.
• Zusätzlich wurde das Feld Buchungen zugelassen bis angezeigt.

Auswirkung

• Das Startdatum konnte nicht unmittelbar angepasst werden.
• Für Anwender entstand ein zusätzlicher manueller Arbeitsschritt, um das Feld editierbar zu machen.
• Die automatische Vorbelegung des Datums konnte zu Fehleingaben oder unnötigen Korrekturen führen.
• Die Bedienbarkeit des Berichts wurde insbesondere bei wiederholten Aufrufen eingeschränkt.

Anpassung

• Das Feld Startdatum bleibt beim Aufruf des Berichts grundsätzlich editierbar. Für Vormonate muss Rückwirkende Korrektur aktiviert werden.
• Die Funktion Zuletzt verwendete Optionen und Filter bleibt erhalten.
• Die gespeicherten Optionen führen nicht mehr dazu, dass das Startdatum gesperrt wird.
• Das Verhalten wurde für Aufrufe aus dem Menü Objektbuchhalter angepasst.
• Beim Aufruf aus einem § 15a-Objekt wird weiterhin der Filter auf das aktuell geöffnete Objekt gesetzt.
• Für das Startdatum gelten auch bei Aufrufen aus dem § 15a-Objekt dieselben Regeln hinsichtlich der Bearbeitbarkeit.
• Das Feld Buchungen zugelassen bis wurde entfernt.

Zusätzliche Hinweise
Die Änderung verbessert die Bedienbarkeit bei der regelmäßigen Erstellung von Planposten für vergangene Meldezeiträume. Vorhandene Einstellungen und Filter können weiterhin wiederverwendet werden, ohne dass das Startdatum manuell entsperrt werden muss.

Bereinigung verbliebener Ausgleichs-IDs

Ausgangssituation
In der Anwendung treten wiederkehrend Fälle auf, in denen Ausgleichs-IDs nach Buchungsvorgängen fälschlicherweise bestehen bleiben. Die genaue Ursache ist nicht abschließend geklärt. Es ist bekannt, dass auch systemseitige Probleme im Microsoft-Standard zu diesen Situationen beitragen können.

Da die Entfernung solcher Ausgleichs-IDs nicht vollständig innerhalb der regulären Ausgleichs- oder Buchungsprozesse erfolgt, verbleiben diese IDs in Datensätzen, in denen sie nicht mehr gültig sind.

Auswirkung
Stehengebliebene Ausgleichs-IDs können in Folgeprozessen zu Fehlverhalten oder Abbrüchen führen. Dies betrifft insbesondere:

• zukünftige Zahlungs- und Auszahlungsvorgänge,
• Mahnprozesse,
• weitere Verarbeitungsschritte, bei denen Offene Posten ausgewertet werden.

Fehlerhafte Ausgleichs-IDs können darüber hinaus zu inkonsistenten Datenbeständen führen, wenn Folgeprozesse auf Basis dieser IDs falsche Annahmen treffen.

Anpassung
Zur Sicherstellung konsistenter Daten wurde eine nachgelagerte Bereinigungslösung implementiert. Die Lösung basiert auf einem Bericht-Stapel, welcher vollautomatisch prüft, ob sich Ausgleichs-IDs an nicht mehr auszugleichenden Posten befinden. Die Logik orientiert sich am bisherigen Vorgehen, das in Einzelfällen per SQL-Skript manuell durchgeführt wurde.

Funktionsumfang – der Bericht führt folgende Schritte durch:

• Prüfung, ob Ausgleichs-IDs an Offenen Posten bestehen, obwohl diese nicht mehr durch einen Buch.-Blatt belegt sind (Kontrolle u. a. anhand detaillierter Posteninformationen, Offen-Kennzeichen und Belegnummern).
• Löschung ungültiger Ausgleichs-IDs.
• Zurücksetzen des Ausgleichsbetrags auf 0.
• Protokollierung der bereinigten Posten, inkl. laufender Nummer und Postenart (Debitoren/Kreditoren).

Der Bericht ist so ausgelegt, dass er manuell (Vorschau, Drucken, Sofortausführung) ausgeführt werden kann. Alternativ kann der Bericht so konfiguriert werden, dass er ausschließlich über die Planung (Warteschlange) ausgeführt werden kann.

Empfohlene Ausführungszeit: täglich nach Dienstschluss, zwingend außerhalb der regulären Arbeitszeiten, um Beeinträchtigungen laufender Ausgleichsprozesse auszuschließen.

Zusätzliche Hinweise

• Die Ausführung des Berichts ersetzt keine Fehleranalyse bei auffälligen Buchungsfällen, sondern dient der präventiven Datenbereinigung.
• Bei systematischem, häufigem Auftreten stehenbleibender IDs sollte eine fachliche Ursachenprüfung erfolgen.

Fehlende Anzeige wichtiger Informationen

Ausgangssituation
In mehreren Rollencentern standen relevante Informationen nicht in der vorgesehenen Form zur Verfügung.

• In Objektbuchhaltung fehlte der Einblick Meine Objekte, sodass Anwender nicht direkt auf die ihnen zugeordneten Objekte zugreifen konnten.
• In Objektverwaltung standen die Aktivitätenkachel Recht sowie der Einblick Meine Mahnvorgänge nicht zur Verfügung, wodurch rechtliche Vorgänge und eigene Mahnvorgänge nicht direkt einsehbar waren. Zudem wurden in den Ansichten MW Bank-BBL und MW Bankposten keine Betragsinformationen angezeigt, was eine direkte Einsicht sowie eine schnelle Zuordnung und Kontrolle der Beträge einschränkte.

Auswirkung
Der fehlende direkte Zugriff auf zugeordnete Objekte sowie auf rechtliche Vorgänge und Mahnvorgänge erschwerte die tägliche Arbeit in den betroffenen Rollencentern.

Ohne unmittelbare Einsicht in Betragsinformationen in MW Bank-BBL und MW Bankposten war zudem eine effiziente Prüfung und Zuordnung von Bankposten nicht durchgängig möglich.

Anpassung
Der Einblick Meine Objekte kann nun im Rollencenter Objektbuchhaltung eingeblendet werden. Im Rollencenter Objektverwaltung wurde die Aktivitätenkachel Recht verfügbar gemacht und der Einblick Meine Mahnvorgänge ergänzt. Zusätzlich wurde die Anzeige der Beträge in den Ansichten MW Bank-BBL und MW Bankposten ergänzt.

Zusätzliche Hinweise
Die Anzeige der Einblicke erfolgt entsprechend der jeweiligen Benutzer- und Berechtigungskonfiguration. Die Beträge werden unmittelbar in den jeweiligen Ansichten dargestellt und stehen dort für die weitere Prüfung zur Verfügung.

Befüllung des Kreditorenstammblatts

Ausgangssituation
Beim Erzeugen des Kreditorenstammblatts (Dokumentenversand aus dem Kreditorenstamm) wurden nur die Kreditorennummer und die Kontaktnummer der verknüpften Geschäftsbeziehung befüllt. Alle übrigen Platzhalter des Dokuments – Name, Adresse, Kontaktdaten, USt-IdNr./Steuernummer, Kreditor-Bankverbindung sowie die Fakturierungsangaben (Buchungsgruppe, Zahlungsform, Zahlungsbedingung, Ausgleichsmethode, EK-Preise inkl. MwSt.) – blieben im gedruckten bzw. versendeten Kreditorenstammblatt leer.

Auswirkung
Das erzeugte Kreditorenstammblatt enthielt keine verwertbaren Stamm-, Kontakt-, Steuer- und Bankdaten des Kreditors. Anwender mussten diese Angaben manuell aus der Kreditorenkarte nachschlagen und ergänzen, um ein vollständiges Kreditorenstammblatt zu erhalten.

Anpassung

• Die Datenermittlung für das Kreditorenstammblatt wurde erweitert. Neben Kreditorennummer und Kontaktnummer werden nun zusätzlich Name, Adresse, Länder-/Regionscode, Telefon-/Faxnummer, E-Mail, USt-IdNr., Steuernummer, Kreditorenbuchungsgruppe, Zahlungsform, Zahlungsbedingung, Ausgleichsmethode und das Kennzeichen EK-Preise inkl. MwSt. aus dem Kreditorenstamm übernommen.
• Zusätzlich wird die zum aktuellen Stichtag gültige Kreditor-Bankverbindung (IBAN, BIC, Bankname, Kontoinhaber, Gültig-seit-Datum) ermittelt und eingesetzt.
• Das Kreditorenstammblatt wird dadurch beim Druck bzw. Versand automatisch vollständig befüllt, sofern die entsprechenden Angaben im Kreditorenstamm gepflegt sind.

Gebuchte Nummernserie in Belegbeschreibungen

Ausgangssituation

• Bei gebuchten Belegen (Beauftragung, Gutschrift, Rechnung, jeweils im Einkauf und Verkauf) wurde in der Buchungsbeschreibung die ungebuchte Nummernserie angezeigt.
• Wurde für die Buchung eine abweichende Nummernserie verwendet, blieb nach der Buchung ein interner, für den Kunden nicht nachvollziehbarer Inhalt in der Beschreibung stehen.

Auswirkung
Die fehlerhafte Beschreibung wirkte sich auf den Rechnungsversand, die Zahlung und das Mahnwesen aus, da die dort angezeigte Belegnummer für den Kunden nicht der tatsächlich gebuchten Nummer entsprach.

Anpassung

• Entspricht die Kopfbeschreibung eines Belegs dem Standardtext (Belegart + Belegnummer), wird sie beim Buchen automatisch durch Belegart + die gebuchte Belegnummer ersetzt.
• Die Anpassung betrifft Beauftragung, Gutschrift und Rechnung, jeweils im Einkauf und im Verkauf.
• Ein bereits individuell erfasster, vom Standardtext abweichender Buchungstext im Belegkopf bleibt unverändert.

Instandhaltung

Inspektionsaufgaben und Termine

Ausgangssituation

• In der Inspektionsaufgabe gab es kein Feld, um den vereinbarten Leistungsumfang zu erfassen; im Inspektionstermin existierte das Feld Leistung bereits, war jedoch im Inforegister Planung platziert.
• Auf der Seite Ausstattung Belege war nicht ersichtlich, wie viele Schadensmeldungen mit einer Ausstattung verknüpft sind.
• Im Rollencenter RELion Objektverwaltung fehlten die Kacheln Meine Objekte - Inspektionen und Meine Inspektionstermine, die im Rollencenter RELion Technische Bearbeitung bereits vorhanden waren.

Auswirkung

• Der vereinbarte Leistungsumfang konnte in der Inspektionsaufgabe nicht erfasst werden, und im Inspektionstermin war das Feld Leistung an einer wenig naheliegenden Stelle zu finden.
• Verknüpfte Schadensmeldungen zu einer Ausstattung mussten separat gesucht werden.
• Nutzer des Rollencenters RELion Objektverwaltung hatten keinen direkten Überblick über ihre Inspektionsobjekte und -termine.

Anpassung

• In der Inspektionsaufgabe steht im Inforegister Allgemein das neue Feld Leistung (bis zu 100 Zeichen) zur Verfügung.
• Im Inspektionstermin wurde das bestehende Feld Leistung vom Inforegister Planung in das Inforegister Allgemein verschoben.
• Beim Anlegen neuer Termine aus der Inspektionsaufgabe wird der Inhalt des Felds Leistung automatisch in den Termin übernommen, kann dort aber individuell überschrieben werden; bereits bestehende Termine bleiben davon unberührt.
• Die Seite Ausstattung Belege zeigt in einer neuen Zeile Schadensmeldungen die Anzahl der verknüpften Schadensmeldungen an; durch Anklicken der Anzahl gelangt man in die Liste der Schadensmeldungen bzw. bei genau einer Meldung direkt in diese.
• Im Rollencenter RELion Objektverwaltung stehen nun ebenfalls die Kacheln Meine Objekte - Inspektionen und Meine Inspektionstermine zur Verfügung.

Zusätzliche Hinweise
Bei der Anzeige der verknüpften Schadensmeldungen wird der auf der Seite Ausstattung Belege eingetragene Datumsfilter berücksichtigt und auf das Schadensdatum angewendet.

Inspektionstermine - Belege RELion Dokumente und Belege

Ausgangssituation

• Die Karte Inspektionstermin war bislang nicht in die Archivierungsfunktion der RELion Dokumente eingebunden.
• Eine direkte Ablage von Dateien oder Belegen zu einzelnen Inspektionsterminen war nicht möglich.

Auswirkung

• Dokumente mussten außerhalb des Inspektionstermins verwaltet oder indirekt zugeordnet werden.
• Die Nachvollziehbarkeit sowie die zentrale Ablage dokumentenbezogener Informationen waren eingeschränkt.

Anpassung

• Die Karte Inspektionstermin ist nun archivierungsfähig.
• Belege können direkt einzelnen Inspektionsterminen zugeordnet werden.
• Dateien können direkt aus dem Inspektionstermin heraus archiviert werden.
• Der Inspektionstermin wurde in die bestehende Archivierungslogik der RELion Dokumente integriert.

Zusätzliche Hinweise

• Die Archivierung erfolgt analog zu den bereits archivierungsfähigen Bereichen innerhalb der RELion Dokumente.
• Die zentrale und kontextbezogene Ablage von Dokumenten verbessert die Nachvollziehbarkeit und erleichtert den Zugriff auf relevante Informationen.

Konsistenzsicherung bzgl. Gebäude/Hauseingang

Ausgangssituation

• Die Gebäudezuordnung eines Hauseingangs konnte nachträglich geändert werden.
• Dies war auch dann möglich, wenn für die bestehende Kombination aus Hauseingang und Gebäude bereits Einheitenstämme vorhanden waren.
• Die zugehörigen Einheitenstämme wurden bei der Änderung nicht automatisch angepasst und behielten die ursprüngliche Kombination bei.

Auswirkung

• Durch nachträgliche Änderungen konnten Inkonsistenzen zwischen Hauseingängen und den zugehörigen Einheitenstämmen entstehen.
• Die Datenbestände konnten dadurch unterschiedliche Gebäudezuordnungen für fachlich zusammengehörige Objekte enthalten.

Anpassung

• Für die Änderung der Gebäudezuordnung eines Hauseingangs wurde eine Plausibilitätsprüfung eingeführt.
• Die Gebäudezuordnung kann nur noch geändert werden, wenn die bisherige Kombination in keinem Einheitenstamm verwendet wird.
• Wird die bisherige Kombination bereits in einem Einheitenstamm verwendet, wird die Änderung verhindert.
• In diesem Fall wird eine entsprechende Fehlermeldung angezeigt.

Zusätzliche Hinweise

• Die neue Prüfung dient der Sicherstellung einer konsistenten Datenhaltung.
• Bestehende Verknüpfungen zwischen Hauseingängen und Einheitenstämmen werden vor unbeabsichtigten Inkonsistenzen geschützt.

Einkaufsbelege - Infobox erweitern

Ausgangssituation

• In der Einkaufszeile wird das Feld Objektkontonr. mit der zugehörigen Objektkontobeschreibung vorbelegt.
• Diese Beschreibung kann in der Zeile überschrieben werden und dadurch von der tatsächlichen Objektkontobeschreibung abweichen.
• Die Objektkontonr. und ihre Beschreibung waren in der Infobox der ungebuchten Einkaufsbelege bislang nicht sichtbar.

Auswirkung
Wurde die Zeilenbeschreibung überschrieben, war die tatsächliche Objektkontobeschreibung weder in der Zeile noch in der Infobox ersichtlich.

Anpassung
In der Infobox der ungebuchten Einkaufsbelege (Einkaufsanfrage, Einkaufsbestellung, Einkaufsrechnung, Einkaufsgutschrift) werden Objektkontonr. und Objektkontobeschreibung nun zusätzlich unterhalb des Sachkontos angezeigt.

Zusätzliche Hinweise
Die Anzeige ist auf ungebuchte Einkaufsbelege beschränkt; gebuchte Einkaufsbelege und Verkaufsbelege sind davon ausgeschlossen.

E-Belege

E-Belege Typ ZUGFeRD für Mietrechnung

Ausgangssituation

• Für den elektronischen Rechnungsversand unterstützt Business Central verschiedene E-Beleg-Formate.
• Für Mietrechnungen standen bisher die Formate PEPPOL BIS 3.0 und XRECHNUNG zur Verfügung.
• Das Format ZUGFeRD war für Mietrechnungen noch nicht verfügbar, obwohl es insbesondere bei Rechnungen im Umfeld der öffentlichen Hand stark nachgefragt wird.

Auswirkung
Kunden, die für Mietrechnungen einen E-Beleg im Format ZUGFeRD benötigten, konnten diesen bislang nicht erzeugen.

Anpassung
Mietrechnungen können nun zusätzlich als E-Beleg im Format ZUGFeRD erstellt werden.

Betriebskostenabrechnung

Abrechnung und Wirtschaftsplan - Stapeldruck als Aktion

Ausgangssituation

• Der Stapeldruck für Abrechnungen und Wirtschaftspläne konnte bisher nur über die Berichtsauswahl aufgerufen werden.

Auswirkung

• Für den Aufruf waren mehrere Klicks erforderlich, einschließlich der Auswahl des gewünschten Berichts aus der Berichtsauswahl.
• In der täglichen Anwendung führte dies zu einem erhöhten Klickaufwand bei regelmäßig genutzten Druckvorgängen.

Anpassung

• Für Abrechnungen und Wirtschaftspläne wurde der Stapeldruck als eigenständige Aktion unter Berichte bereitgestellt.
• Die Aktion steht jetzt in der Abrechnungsübersicht, Abrechnungskarte, Einheit Abrechnungen, Wirtschaftsplanübersicht, Wirtschaftsplankarte sowie Einheit Wirtschaftsplan zur Verfügung.
• In den Seiten für Einheit-Abrechnungen wird der PDF-Stapeldruck direkt über die neue Aktion aufgerufen.
• Durch Personalisieren kann die Schaltfläche auch direkt auf Start gelegt werden.

Zusätzliche Hinweise

• Die bisherige Aufrufmöglichkeit über die Berichtsauswahl bleibt weiterhin erhalten, die neue Aktion heißt Stapeldruck.
• Die neue Aktion kann vom Anwender über die Möglichkeiten zur Anpassung des Menübands einfacher genutzt und positioniert werden.

Reduzierung redundanter Meldungen in Aktionsprotokollzeilen

Ausgangssituation
Bei umfangreichen Stapelprozessen in Abrechnung und Wirtschaftsplan entstehen zahlreiche Fehler- und Hinweiszeilen in Form von Aktionsprotokollposten. Häufig werden identische Meldungen mehrfach erzeugt, da die Prüfungen an verschiedenen Stellen wiederholt durchlaufen werden.

Auswirkung
Die bisherige Vorgehensweise führte zu:

• Redundanten Meldungen im Protokoll.
• Erhöhtem Speicherbedarf.
• Unübersichtlichen Protokollen und zusätzlichem Aufwand für die Anwender bei der Analyse.

Anpassung
Die Meldungen über Aktionsprotokolle wurden überarbeitet, so dass viele gleichartige Meldungen nur noch einmal kommen.

• Die Änderung verbessert die Lesbarkeit und reduziert die Anzahl der Protokollzeilen erheblich.
• Es erfolgt keine Änderung an der fachlichen Logik der Berechnung, sondern ausschließlich an der Protokollausgabe.
• Anwender profitieren von einer besseren Übersicht und Zeitersparnis bei der Fehleranalyse.

Drucktext Verteilung

Ausgangssituation

• In der Nebenkostenabrechnung und im Wirtschaftsplan wurde die Beschreibung einer Verteilung bisher automatisch aus dem Verteilungscode, der Verteilungsbeschreibung oder der Verteilungsart ermittelt.
• Für objektbezogene Sonderfälle bestand keine Möglichkeit, eine individuelle Beschreibung für die Ausgabe der Verteilung zu hinterlegen.

Auswirkung
Bei Verteilungen auf Basis externer Berechnungen, beispielsweise durch Wärmemessdienste oder Gebührenbescheide, entstand der Bedarf nach einer individuell formulierten Bezeichnung in den Auswertungen.

Anpassung

• In der Objektkontokarte wurde das neue Feld Drucktext Verteilung im Inforegister Wirtschaftsplan/Abrechnung ergänzt.
• Wird in diesem Feld ein Wert erfasst, wird dieser Text als Verteilungsbeschreibung in der Nebenkostenabrechnung und im Wirtschaftsplan ausgegeben.
• Der hinterlegte Drucktext ersetzt für dieses Konto die bisher automatisch ermittelte Verteilungsbeschreibung.
• Ist das Feld leer, bleibt das bisherige Verhalten unverändert bestehen und die Standardlogik zur Ermittlung der Verteilungsbeschreibung wird weiterhin verwendet.

Zusätzliche Hinweise

• Bei Verteilungen vom Typ Zeitanteilig und Nicht zeitanteilig steht in der Einzelabrechnung nur ein begrenzter Platz für die Ausgabe der Verteilungsbeschreibung zur Verfügung. Ein automatischer Zeilenumbruch wird nicht durchgeführt, um die bestehende Formatierung und Seitenaufteilung der Ausgaben nicht zu beeinflussen.
• Die bestehende Logik zur Ermittlung von Standardbeschreibungen bleibt aus Gründen der Rückwärtskompatibilität erhalten und wird verwendet, sofern kein individueller Drucktext hinterlegt wurde.

Kreditorische Verträge

Kontierung in Schlussrechnung vom Versorgervertrag übernehmen

Ausgangssituation
In den Kontierungsvorgaben zu einer Vertragszeile eines kreditorischen Vertrags gab es keine Anzeige, welchen prozentualen Anteil eine einzelne Kontierungszeile am Gesamtbetrag der Vertragszeile hat.

Auswirkung
Der prozentuale Anteil einer Kontierungszeile am Gesamtbetrag der Vertragszeile musste manuell ermittelt werden, da keine entsprechende Information zur Verfügung stand.

Anpassung

• In den Kontierungsvorgaben steht das neue Feld Verteilung % zur Verfügung.
• Das Feld zeigt den prozentualen Anteil der jeweiligen Kontierungszeile am Gesamtbetrag (Betrag brutto) der Vertragszeile an; der Gesamtbetrag der Vertragszeile entspricht dabei 100 %.
• Das Feld wird automatisch berechnet und ist nicht editierbar.
• Das Feld wird standardmäßig unmittelbar nach dem Feld Betrag brutto angezeigt.

Kreditorische Verträge - Kontierung Vertragszeile

Ausgangssituation
Rechnungen von Versorgern (z. B. Gemeinden für Grundsteuer, Wasser, Abwasser) enthielten teilweise mehrere Positionen, die auf unterschiedliche Konten gebucht werden mussten. An der Vertragszeile eines kreditorischen Vertrags gab es keine Möglichkeit, eine Verteilung inklusive Kontierungsinformationen zu hinterlegen. In der Dauerzahlung vorhandene Verteilungen mussten von Periode zu Periode neu erfasst werden.

Auswirkung
Die Aufteilung mehrteiliger Versorgerrechnungen auf mehrere Konten musste wiederkehrend manuell vorgenommen werden. Es fehlte eine dauerhaft an der Vertragszeile hinterlegte Grundlage für die Kontierung und Verteilung solcher Beträge.

Anpassung
An einer aktiven Vertragszeile kann eine Verteilung inklusive vollständiger Kontierungsinformationen hinterlegt werden, wobei eine oder mehrere Kontierungszeilen gepflegt werden können. Über die neue Aktion Kontierungsvorgaben auf der Vertragszeile öffnet sich eine Übersicht zur Pflege der Kontierungszeilen:

• Objektkonto
• Beschreibung
• Betrag brutto
• Abrechnungskreis
• Geschäfts- und Produktbuchungsgruppe
• MwSt-Gruppen
• Regel für die automatische Weiterbelastung.

Die Aktion Kontierungsvorgaben steht nur zur Verfügung, wenn an der Vertragszeile E/M-Kennzeichen, Objekt und Betrag brutto hinterlegt sind. Die hinterlegten Kontierungsinformationen werden in die Vorgabeverteilung der Dauerzahlung übernommen. Beim Schließen des Kontierungsdialogs wird geprüft, dass die Summe der Beträge aller Kontierungszeilen dem Betrag brutto der Vertragszeile entspricht; andernfalls erscheint eine entsprechende Fehlermeldung und der Dialog kann nicht geschlossen werden. Bei einer abgeschlossenen Vertragszeile können die hinterlegten Kontierungsinformationen weiterhin über eine eigene Aktion eingesehen, aber nicht mehr geändert werden.

Zusätzliche Hinweise
Die § 35-Felder (z. B. haushaltsnahe Beschäftigung/Dienstleistung, Handwerkerleistung) in den Kontierungszeilen sind nur editierbar, wenn beim gewählten Objektkonto Beträge § 35a zulässig auf Ja gesetzt ist. Wird die Vertragszeile mittels der Schaltfläche Vertrag fortschreiben aus der DZ kopiert, so werden die Kontierungsinformationen aus der ursprünglichen Vertragszeile ebenfalls übernommen. Änderungen, die an der Dauerzahlung Vorgabeverteilung vorgenommen werden, werden nicht in die Kontierungsinformationen der Vertragszeile zurückgeschrieben.

Migration von Dienstleistungsverträgen in Kreditorische Verträge

Ausgangssituation

• Dienstleistungsverträge befinden sich bisher auf der Tabelle Mietverträge.
• Für die Übernahme dieser Verträge in die Struktur der Servicevertrags-/Kreditorischen Verträge wird eine Funktion benötigt.

Auswirkung
Dienstleistungsverträge müssten manuell in die neue Struktur überführt werden.

Anpassung

• Der Bericht DL-Vertrag zu Servicevertrag kopieren kopiert alle Verträge gemäß dem gesetzten Filter in einen neuen Eintrag der Tabelle Kreditorische Verträge.
• Für die Vertragsart/-klasse wird beim Kopieren von Dienstleistungsverträgen der erste Eintrag der Tabelle Kreditorische Vertragsart mit der Vertragsklasse Servicevertrag verwendet.
• Informationen des Vertragskopfes und Zeilen (soweit möglich), Kündigungsdaten, Links, Notizen, Bemerkungen und Attribute werden beim Kopieren übernommen.
• Nicht übernommen werden die Verlinkungen zu EK-Belegen.
• Alle DL-Verträge, die nicht beendet sind, werden migriert; bereits migrierte Verträge werden beim erneuten Ausführen des Berichts übersprungen.
• Sobald ein Dienstleistungsvertrag über diesen Bericht kopiert wurde, kann ein neuer Dienstleistungsvertrag/Servicevertrag nur noch in der Tabelle Kreditorische Verträge erfasst werden. In der alten Tabelle können kopierte DL-Verträge nur noch eingesehen werden.

Zusätzliche Hinweise
Da die Zeilenstruktur des neuen kreditorischen Vertrags nicht mit der des alten DL-Vertrags übereinstimmt, ist nach der Migration eine Nachbearbeitung der Zeilen im neuen Vertrag erforderlich. Gegebenenfalls müssen Dauerzahlungen neu erstellt werden bzw. Einträge in den Wiederkehrenden Buchblattzeilen müssen gelöscht/beendet werden.

Kreditorische Verträge - Kündigungsdaten

Ausgangssituation

• Für kreditorische Verträge gab es bislang keine strukturierte Möglichkeit, verschiedene Kündigungsklauseln zu erfassen; diese Funktion stand nur im DL-Vertrag zur Verfügung.
• Kreditorische Verträge verfügten über mehrere fachlich nicht mehr relevante bzw. redundante Kündigungsfelder direkt auf Vertragsebene.
• Die bisherige Validierungslogik zum Vertragsende erzeugte auch in fachlich unkritischen Fällen Fehlermeldungen.
• Nach Eintrag eines Kündigungsdatums waren die Felder Gekündigt am und Gekündigt zum nicht mehr editierbar.

Auswirkung

• Kündigungsklauseln konnten bei kreditorischen Verträgen nicht analog zum Mietvertrag/DL-Vertrag abgebildet werden.
• Anwender erhielten teilweise Fehlermeldungen zum Vertragsende, auch wenn keine fachlich inkonsistente Konstellation vorlag.
• Eine bereits eingetragene Kündigung konnte nicht zurückgenommen oder korrigiert werden.
• In der Vertragsübersicht fehlte eine einfache Möglichkeit, Kündigungsinformationen transparent einzusehen.

Anpassung

• Für kreditorische Verträge steht nun eine eigene Kündigungsdaten-Tabelle analog zum Mietvertrag zur Verfügung, u. a. mit den Feldern Kündigung durch, Kündbar zum, Kündigungsfrist, Verlängerungsfrist, Status, Sonderkündigung, Bemerkung Sonderkündigung, Beschreibung und Karenztage.
• Eine neue Kündigung-Infobox zeigt die relevanten Kündigungsinformationen auf der Liste und der Vertragskarte der kreditorischen Verträge an; sie ist standardmäßig ausgeblendet und kann manuell eingeblendet werden.
• Die Validierungslogik zum Vertragsende in den Vertragszeilen wurde überarbeitet, sodass Fehlermeldungen nur noch bei fachlich inkonsistenten Konstellationen erscheinen.
• Die Felder Gekündigt am und Gekündigt zum bleiben nach Eintrag eines Kündigungsdatums weiterhin editierbar, sodass Kündigungen zurückgenommen oder korrigiert werden können.
• Die Felder Gekündigt am und Gekündigt zum können in der Liste der kreditorischen Verträge über Personalisierung/Spalteneinblendung angezeigt werden (standardmäßig ausgeblendet). Die bisherigen, nicht mehr benötigten Kündigungsfelder (Kündigung durch, Kündbar zum, Kündigungsfrist, Kündigung zum, Verlängerungsfrist, Sonderkündigung) wurden aus Tabelle, Vertragskarte, Listen/Infoboxes sowie der Validierungs- und Berechnungslogik entfernt.

Zusätzliche Hinweise
Bestehende Daten aus den entfernten Feldern wurden im Zuge der Umstellung in die neue Kündigungsdaten-Tabelle migriert.

Bestehende Vertragsklasse Dienstleistungsvertrag in neue Tabelle umarbeiten

Ausgangssituation
Dienstleistungsverträge wurden bisher über die bestehende Vertragsklasse Dienstleistungsvertrag abgebildet. Diese Struktur bot nicht die notwendige Grundlage für die geplante Vereinheitlichung mit anderen kreditorischen Vertragsarten.

Auswirkung
Dienstleistungsverträge konnten nicht über eine eigene, auf die neue Tabellenstruktur Kreditorische Verträge abgestimmte Karte erfasst und verwaltet werden.

Anpassung

• Dienstleistungsverträge mit der Vertragsklasse Dienstleistungsvertrag werden jetzt über die neue Tabelle Kreditorische Verträge mit der Vertragsklasse Servicevertrag abgebildet.
• Eine neue Karte zur Erfassung und Verwaltung von Service-Verträgen steht zur Verfügung; der Aufbau entspricht dem Versorgervertrag, unter anderem mit der Logik aktiver und abgeschlossener Vertragszeilen.
• Die zugrunde liegende Tabelle wurde um die für DL-Verträge/Servicevertrag benötigten Felder erweitert.
• Aus der Vertragszeile kann eine Dauerzahlung erstellt und geöffnet werden für wiederkehrende Zahlungen. Die Funktionalität Wiederkehrendes Buchblatt steht nicht mehr zur Verfügung.
• Aus dem Vertrag heraus kann direkt eine Beauftragung erstellt werden, in die die relevanten Daten aus dem Vertrag übernommen werden.
• Aus der Einkaufsrechnung heraus kann der Vertrag über die Schaltfläche Kreditorischer Vertrag verknüpfen mit der Einkaufsrechnung verknüpft werden.
• Um einen Servicevertrag anlegen zu können, muss in der Tabelle Kreditorische Vertragsart ein Datensatz mit der Vertragsklasse Servicevertrag existieren.

Zusätzliche Hinweise

• Der Vertrag selbst besitzt keinen eigenen Status mehr; Status-Informationen werden stattdessen an den zugehörigen Belegen (z. B. Einkaufsrechnung, Dauerzahlung) geführt.
• Für das Kopieren bestehender DL-Verträge in die neue Struktur der Serviceverträge gibt es eine eigene Funktion, die ebenfalls mit diesem Release ausgeliefert wird.
• Eine Verarbeitung der Kreditorischen Verträge mit dem Rechnungsmanager wird mit einem der nächsten Rechnungsmanager Release veröffentlicht.

Ticketsystem

Problem Lösungszuordnung Beauftragung automatisch erstellen

Ausgangssituation
In der Seite RE Problem-/Lösungszuordnungen konnte der Schalter Autom. Auftrag unabhängig vom Schalter Autom. SM aktiviert werden.

Auswirkung
Es konnten inkonsistente Einstellungen entstehen, bei denen Autom. Auftrag aktiviert war, ohne dass Autom. SM aktiviert war.

Anpassung
Der Schalter Autom. Auftrag kann in der Seite RE Problem-/Lösungszuordnungen nur noch aktiviert werden, wenn der Schalter Autom. SM bereits aktiviert ist; eine Plausibilitätsprüfung verhindert die inkonsistente Einstellung.

RELion Dokumente

Archivierung von Rechtsfällen in RELion

Ausgangssituation
Die Karte Rechtsfälle war bislang nicht in die Archivierungsfunktion der RELion Dokumente eingebunden. Eine direkte Ablage von Dateien oder Belegen zu einzelnen Rechtsfällen war nicht möglich.

Auswirkung
Dokumente zu Rechtsfällen mussten außerhalb des Rechtsfalls verwaltet oder indirekt zugeordnet werden. Die Nachvollziehbarkeit sowie die zentrale Ablage rechtsfallbezogener Informationen waren eingeschränkt.

Anpassung
Die Karte Rechtsfälle ist nun archivierungsfähig. Belege können direkt einzelnen Rechtsfällen zugeordnet werden. Dateien können direkt innerhalb des Rechtsfalls archiviert werden. Die Karte Rechtsfälle wurde in die bestehende Archivierungslogik der RELion Dokumente integriert.

Zusätzliche Hinweise
Die Archivierung erfolgt analog zu den bereits archivierungsfähigen Bereichen innerhalb der RELion Dokumente. Die zentrale und kontextbezogene Ablage von Dokumenten verbessert die Nachvollziehbarkeit und erleichtert den Zugriff auf alle relevanten Unterlagen eines Rechtsfalls. Bestehende Funktionen zur Dokumentenverwaltung und Archivierung stehen auch für Rechtsfälle zur Verfügung.

Verwalterhonorar

Verwaltervertrag - § 35a Informationen hinzufügen

Ausgangssituation
Im Verwalterhonorarvertrag standen keine Felder zur Erfassung von Informationen nach § 35a zur Verfügung. Bei der Erstellung von Einkaufsrechnungen aus Verwalterhonorarabrechnungen konnten entsprechende Beträge daher nicht automatisiert übernommen werden.

Auswirkung
Informationen zu haushaltsnahen Beschäftigungen, haushaltsnahen Dienstleistungen und Materialkosten stehen nach der Übernahme unmittelbar in der Einkaufsrechnung zur Verfügung. Eine manuelle Nacherfassung dieser Werte in der Einkaufsrechnung ist nicht erforderlich.

Anpassung
Teilweise wird mittels Verwalterhonorar Rechnungen von einer Gesellschaft auf eine andere übertragen. In diesem Kontext kommt es vor, dass § 35-Informationen in den Einkaufsbeleg (Bericht Verwalterhonorar Rechnung Verkauf -> Einkauf) übernommen werden sollen. Damit das möglich ist, kann man für diesen Anwendungsfall die Felder für § 35a in die Verwalterhonorarzeile einblenden und befüllen. Wird dann der Bericht Verwalterhonorar Rechnung Verkauf -> Einkauf ausgeführt, wird geprüft, ob in der zugehörigen Verwalterhonorarvertragszeile § 35a-Angaben hinterlegt sind. In dem Falle werden diese Informationen in die Einkaufszeile übernommen.

Im Verwalterhonorarvertrag wurden die folgenden Felder ergänzt:

• Haushaltsnahe Beschäftigungen Betrag
• Haushaltsnahe Dienstleistungen Betrag
• Material Betrag

Beim Ausführen des Berichts Verwalterhon.Rechn Verk->Eink werden die Werte dieser Felder in die daraus erzeugte Einkaufsrechnung übernommen.

Zusätzliche Hinweise
In der Verkaufsrechnung werden die drei neuen Felder nicht angezeigt. Die Felder haben keine Auswirkung auf die Verarbeitung oder Darstellung der Verkaufsrechnung und dienen ausschließlich der Übergabe an die Einkaufsrechnung.

Vertragsverwaltung

Vertragsschreiben - Word Vorlage weitere Vertragspartner andrucken

Ausgangssituation
Im Bericht Vertragsschreiben wurden im CBR-Block (Contact Business Relation) alle Kontaktgeschäftsbeziehungsdatensätze ausgegeben, die im Vertrag im Inforegister Kontakte eingetragen waren. Eine Filterung nach dem Aktiv-Status der Vertragspartner war nicht möglich.

Auswirkung
Kontakte, für die mehrere Kontaktgeschäftsbeziehungsdatensätze vorlagen (z. B. wenn ein Mieter mehrere Einheiten in einem Vertrag angemietet hatte), erschienen im CBR-Block mehrfach. Es wurde zudem nicht zwischen aktiven und nicht aktiven Vertragspartnern unterschieden.

Anpassung

• Der Bericht Vertragsschreiben verfügt nun über die Option Kontaktgeschäftsbeziehungen mit den Auswahlmöglichkeiten Alle (Standardeinstellung) und Nur aktive Vertragspartner.
• Bei der Einstellung Alle werden weiterhin alle im Vertrag im Inforegister Kontakte eingetragenen Kontakte im CBR-Block ausgegeben.
• Bei der Einstellung Nur aktive Vertragspartner werden nur Kontaktgeschäftsbeziehungen berücksichtigt, bei denen die Option Vertragspartner den Wert Aktiv hat.
• Jeder Kontakt wird im CBR-Block unabhängig von der gewählten Einstellung nur noch einmal ausgegeben, auch wenn für ihn mehrere Kontaktgeschäftsbeziehungen bestehen (z. B. durch mehrere Einheitenverträge oder manuell angelegte Kontaktgeschäftsbeziehungen).

Zahlungsschlüssel stornieren bzw. freigeben bei Vertragsstorno/Löschen eines Vertrags

Ausgangssituation
Beim Stornieren oder Löschen eines Vertrags wurden zugehörige Zahlungsschlüssel nicht automatisch entsprechend des Vertragsstatus behandelt. Dadurch konnten Zahlungsschlüssel weiterhin aktiv bzw. belegt bleiben.

Auswirkung

• Die Konsistenz zwischen Vertragsstatus und zugeordneten Zahlungsschlüsseln wird sichergestellt.
• Nicht mehr benötigte RELion-Zahlungsschlüssel verbleiben nach einer Vertragsstornierung oder Vertragslöschung nicht aktiv im System.
• BK- und BB-Zahlungsschlüssel stehen nach der Freigabe wieder für eine erneute Verwendung zur Verfügung.

Anpassung

• Die Verarbeitung von Zahlungsschlüsseln bei Stornierung oder Löschung eines Vertrags wurde erweitert.
• Zugehörige RELion-Zahlungsschlüssel werden nun automatisch storniert.
• Bei Verwendung von BK- oder BB-Zahlungsschlüsseln werden diese automatisch freigegeben.

Fehlerbehebung

Buchhaltung

Kontierungsregel greift nicht bei fehlendem Verwendungszweck

Ausgangssituation
Bei bestimmten Zahlungstransaktionen ohne Verwendungszweck griffen die hinterlegten Kontierungsregeln nicht, ohne dass ein Unterschied zu funktionierenden Regeln erkennbar war.

Auswirkung
Betroffene Zahlungstransaktionen ohne Verwendungszweck konnten keinem Zahlungsschlüssel zugeordnet werden, wodurch die zugehörige Kontierungsregel nicht angewendet wurde.

Anpassung
Bei leerem Verwendungszweck wird der Zahlungsschlüssel nicht mehr aus dem Verwendungszweck ermittelt; die Zuordnung erfolgt in diesem Fall stattdessen korrekt über die IBAN.

Falscher Saldo bei OP-Liste

Ausgangssituation
Bei der OP-Liste wurde der Saldo bei Vorhandensein von Mahnkommentaren falsch ausgewiesen. Der Saldo wurde entsprechend der Anzahl der eingetragenen Mahnkommentare vervielfacht, anstatt korrekt berechnet zu werden.

Auswirkung
Der ausgewiesene Saldo in der OP-Liste war bei vorhandenen Mahnkommentaren deutlich zu hoch (z. B. Vervierfachung bei 4 Mahnkommentaren). Die Summe der offenen Posten stimmte dadurch nicht mit dem tatsächlich offenen Betrag überein.

Anpassung
Die Berechnung des Saldos in der OP-Liste wurde korrigiert. Der Saldo entspricht nun unabhängig von vorhandenen Mahnkommentaren dem korrekten Wert, wie er auch in der OP-Liste ohne Mahnkommentare ausgewiesen wird.

Fehlerhafte Rücklastschriften

Ausgangssituation

• Bei der Verarbeitung von Rücklastschriften wurden aus den Kontoauszugsdaten zwei Beträge herangezogen: der Urspr. Betrag (OAMT) und ein separat ausgewiesener Gebührenbetrag.
• Beide Beträge wurden bislang jeweils mit dem von der Bank gelieferten Vorzeichen (DBIT/CRDT) unverändert übernommen.
• In bestimmten Fällen lieferten Banken für diese beiden Beträge voneinander abweichende Vorzeichen-Kennzeichnungen bzw. stellen Banken keine Vorzeichen-Kennzeichnung für die Gebühr bereit.

Auswirkung

• In den betroffenen Fällen wurde die daraus resultierende Rücklastschriftgebühr nicht korrekt ermittelt.
• Statt eines geringen Gebührenbetrags wurde im Bank-Buch.-Blatt eine deutlich zu hohe Zusatzbuchung (bis zum Doppelten des eigentlichen Rücklastschriftbetrags) erzeugt.
• Die betroffene Buchblattzeile war zudem untrennbar mit der zugehörigen Erstattungszeile verknüpft und ließ sich weder separat löschen noch im Betrag anpassen.

Anpassung

• Der Gebührenbetrag wird beim Import des Kontoauszugs künftig unabhängig von der bankseitigen Vorzeichen-Kennzeichnung einheitlich als Belastung behandelt.
• Die Berechnung der Rücklastschriftgebühr wurde zusätzlich so abgesichert, dass sie auch bei künftig abweichenden Vorzeichen-Kombinationen in den Bankdaten korrekt bleibt.
• Die Rücklastschriftgebühr wird dadurch wieder in der tatsächlich zutreffenden Höhe im Bank-Buch.-Blatt ausgewiesen.

Zusätzliche Hinweise
Zur Nachvollziehbarkeit wurden auf der Kontoauszugs-Detailkarte sowie in der Buchungsdetail-Ansicht zwei zusätzliche, standardmäßig ausgeblendete Felder hinterlegt (ursprünglicher Transaktionsbetrag und Gebührenbetrag), die bei Bedarf für Rückfragen eingeblendet werden können. Bereits vor dieser Anpassung fehlerhaft erzeugte Buchblattzeilen werden durch diese Änderung nicht automatisch korrigiert und müssen bei Bedarf einzeln nachbearbeitet werden.

Fehler Buchungsart bei Dauerzahlungen fehlt

Ausgangssituation
In den Verteilungszeilen von Dauerzahlungen stand kein Feld für die Buchungsart zur Verfügung. Bei Aufteilungsbuchungen mit befüllten Buchungsgruppen (z. B. über ein Durchlaufkonto ohne Steuerbezug) konnte die Buchungsart der Verteilungszeile daher nicht mit an die Buchung übergeben werden.

Auswirkung
Dauerzahlungen mit solchen Aufteilungsbuchungen konnten nicht gebucht werden; beim Buchen erschien eine Fehlermeldung.

Anpassung
In den Verteilungszeilen der Dauerzahlung (Verteilungen, Default-Verteilungen, Verteilungen je Zahlungstermin) steht nun ein Feld für die Buchungsart zur Verfügung. Die Buchungsart wird beim Erfassen eines Objektkontos automatisch aus dem hinterlegten Sachkonto übernommen, kann aber auch individuell je Verteilungszeile angepasst werden. Beim Buchen, in der Buchungsvorschau und bei der Zahlungsvorauswahl wird die Buchungsart nun korrekt an die erzeugte Buchungszeile übergeben.

Zusätzliche Hinweise
Die Meldung „Die MwSt.-Buchungsmatrix Einrichtung ist nicht vorhanden“ beim Freigeben einer Dauerzahlung hängt mit einer separaten Einrichtung der MwSt.-Buchungsmatrix zusammen und ist von dieser Anpassung nicht betroffen.

Verarbeitung von CAMT-Dateien dauert mehrere Stunden

Ausgangssituation

• Der Import von CAMT.053.V8-Kontoauszugsdateien im Modul Bankbeleg Import konnte bei Dateien, die Buchungen mehrerer Bankkonten enthielten, sehr lange dauern.
• Die Verarbeitungsdauer stieg dabei nicht im Verhältnis zur Anzahl der enthaltenen Buchungszeilen, sondern überproportional mit der Anzahl der in der Datei enthaltenen Bankkonten.

Auswirkung
Bei Dateien mit einer größeren Anzahl enthaltener Bankkonten konnte der Import mehrere Stunden in Anspruch nehmen. Während der Verarbeitung einer Datei stand die Import-Funktion nicht für weitere Importe zur Verfügung. Die interne Ablage der beim Import verarbeiteten Rohdaten wuchs dadurch unnötig stark an.

Anpassung
Die interne Verarbeitungslogik des CAMT.053.V8-Imports wurde so angepasst, dass die Dateiinformationen je Kontoauszug nur noch für den jeweils aktuell verarbeiteten Kontoauszug aufbereitet werden, anstatt bei jedem enthaltenen Kontoauszug erneut die gesamte Datei zu verarbeiten. Die Verarbeitungsdauer richtet sich dadurch im Wesentlichen nach der Menge der enthaltenen Daten und steigt nicht mehr überproportional mit der Anzahl der in der Datei enthaltenen Bankkonten.

Zusätzliche Hinweise
Die über die Aktion Bank Account XML Structure abrufbare XML-Struktur einer Bankbeleg-Import-Position zeigt nach der Anpassung nur noch den zu dieser Position gehörenden Ausschnitt der Datei an, nicht mehr den Inhalt der gesamten importierten Datei.

Skontorückrechnung - Fehlermeldung

Ausgangssituation
Bei der Verarbeitung Skonto rückrechnen konnte bei Rechnungsposten mit § 35a-Beträgen (Handwerkerleistungen, haushaltsnahe Dienstleistungen, haushaltsnahe Beschäftigungsverhältnisse) eine Fehlermeldung erscheinen, dass die Summe der § 35a-Werte den Bruttobetrag des Postens übersteigt. Ursache war eine rein rundungsbedingte Abweichung von ein bis zwei Cent zwischen dem Bruttobetrag und der Summe der drei unabhängig voneinander gerundeten § 35a-Teilbeträge.

Auswirkung
Das Buchen der Skonto-Rückrechnung wurde in diesen Fällen durch die Fehlermeldung blockiert, obwohl keine tatsächliche Berechnungsabweichung vorlag.

Anpassung
Übersteigt die Summe der § 35a-Teilbeträge den Bruttobetrag nur um eine geringfügige, im Rahmen der Rundungsgenauigkeit liegende Differenz, wird der Betrag Handwerkerleistungen automatisch entsprechend reduziert, sodass die Summe den Bruttobetrag nicht mehr übersteigt. Bei einer größeren Abweichung erscheint weiterhin die Fehlermeldung, da es sich dann um eine tatsächliche Berechnungsabweichung handelt.

RELion ignoriert Mittelverwendung bei Stapelbuchungen Darlehen

Ausgangssituation
Bei der Buchung von Darlehen-Planposten über die Stapelbuchung wurde die im Darlehen hinterlegte Mittelverwendung (Aufteilung der Buchung nach Objekt) nicht berücksichtigt.

Auswirkung
Statt einer separaten Buchungszeile je Objekt entstand nur eine aggregierte Buchungszeile je Konto (Zins, Tilgung, Kreditor). Bei Darlehen mit mehreren Objekten in der Mittelverwendung wurden alle Beträge ausschließlich auf das letzte Objekt der Mittelverwendung gebucht, statt korrekt auf alle beteiligten Objekte verteilt zu werden.

Anpassung
Der Buchungsbetrag wird bei der Stapelbuchung nun korrekt aus dem jeweiligen Planposten übernommen, auch wenn nur ein Objekt in der Mittelverwendung vorhanden ist. Die Berechnung des Anteils je Objekt (Quote bzw. Verteilungsfaktor) erfolgt nun auf Basis des tatsächlichen Planposten-Betrags, sodass die Aufteilung auf die einzelnen Objekte korrekt berechnet wird. Die Ermittlung der zugehörigen Planposten bei der Stapelbuchung wurde an die Logik der Direktbuchung angeglichen.

Zusätzliche Hinweise
Bereits vor dieser Korrektur über die Stapelbuchung fehlerhaft gebuchte Sammelposten sind von der Korrektur nicht rückwirkend betroffen und müssen weiterhin manuell auf die einzelnen Objekte aufgeteilt werden.

Planposten in FiBu buchen ignoriert den Zahlungsformcode an der Darlehenbuchungsgruppe

Ausgangssituation
An der Darlehensbuchungsgruppe kann im Feld Auszahlungen Zahlungsformcode ein Zahlungsformcode für die Auszahlung an den Kreditor hinterlegt werden. Beim Buchen von Darlehens-Planposten (z. B. Zins, Tilgung) wurde dieser Zahlungsformcode nicht auf den entstehenden Kreditorenposten übertragen.

Auswirkung
Der gebuchte Kreditorenposten enthielt statt des hinterlegten Zahlungsformcodes keinen Wert. Betroffene Kreditorenposten mussten vor der Zahlungsverarbeitung (z. B. Zahllauf/SEPA) manuell nachgepflegt werden.

Anpassung
Der an der Darlehensbuchungsgruppe hinterlegte Auszahlungen Zahlungsformcode wird beim Buchen der Darlehens-Planposten nun korrekt auf den Kreditorenposten übertragen. Dies wurde sowohl für Einzelobjekt-Darlehen als auch für Mehrobjekt-Darlehen ohne aktivierte Sammel-/Saldobuchung über mehrere Objekte verifiziert.

Zusätzliche Hinweise
Bereits vor dieser Korrektur gebuchte Kreditorenposten sind von der Korrektur nicht rückwirkend betroffen und müssen ggf. weiterhin manuell nachgepflegt werden.

Fehlerhafte Darstellung im Bericht Debitor Kontoauszug zusammengefasst

Ausgangssituation
Im Bericht Debitor Kontoauszug zusammengefasst wurde im Filter Buchungsdatum nach die Auswahl des Zeitraumtyps nicht korrekt übernommen. Unabhängig von der gewählten Einstellung sprang der Filter nach der Auswahl automatisch wieder auf den Wert Tag zurück.

Auswirkung
Anwender konnten den gewünschten Zeitraum nicht wie vorgesehen filtern. Dies führte zu einer eingeschränkten Bedienbarkeit des Filters und verhinderte die Auswertung von Daten anhand anderer Zeitraumtypen.

Anpassung
Die Filterlogik wurde korrigiert. Die im Feld Buchungsdatum nach ausgewählte Einstellung bleibt nun erhalten und wird korrekt verarbeitet. Anwender können den gewünschten Zeitraumtyp wieder uneingeschränkt verwenden.

Gebuchte Zahlungsvorgänge verschwinden nicht aus der Ansicht

Ausgangssituation
Beim gleichzeitigen Verbuchen mehrerer Zahlungstransaktionen wurde ein temporärer Zwischenspeicher für fehlerhafte Journalstapel (Gen. Journal Batch) über mehrere Transaktionen hinweg weiterverwendet. Fehlereinträge aus einer zuvor verarbeiteten Zahlungstransaktion konnten dadurch nachfolgende Transaktionen beeinflussen. In bestimmten Konstellationen konnte eine erfolgreich verbuchte Zahlungstransaktion fälschlicherweise als nicht vollständig verarbeitet behandelt werden.

Auswirkung
Der Verarbeitungsstatus von Zahlungstransaktionen konnte unter Umständen nicht korrekt ermittelt werden. Bereits erfolgreich verbuchte Zahlungstransaktionen konnten weiterhin in den offenen Zahlungstransaktionen erscheinen. Dies konnte zu Verunsicherung bei der Nachverfolgung des Verarbeitungsstatus führen.

Anpassung
Der temporäre Zwischenspeicher für fehlerhafte Journalstapel wird nun vor der Verarbeitung jeder einzelnen Zahlungstransaktion zurückgesetzt. Die Bewertung des Verbuchungsergebnisses erfolgt dadurch ausschließlich auf Basis der aktuell verarbeiteten Zahlungstransaktion. Die Statusermittlung nach der Verbuchung wurde dadurch verbessert und von vorherigen Verarbeitungsvorgängen entkoppelt.

Zusätzliche Hinweise
Die Änderung betrifft ausschließlich die interne Verarbeitung und Statusbewertung bei der Verbuchung von Zahlungstransaktionen. Es sind keine Anpassungen an bestehenden Prozessen oder Benutzereinstellungen erforderlich.

Bankverbindung Debitor

Ausgangssituation

• Bei der Anlage oder Änderung einer Debitorenbankverbindung wurde der Kontoinhaber automatisch aus dem zugeordneten Debitor bzw. Kontakt übernommen.
• Ein manuell erfasster oder geänderter Kontoinhaber konnte durch nachfolgende Änderungen an der Debitoren- oder Kontaktzuordnung wieder überschrieben werden.
• Dadurch war es möglich, dass bewusst erfasste abweichende Kontoinhaber unbeabsichtigt verloren gingen.

Auswirkung

• Bereits eingegebene Kontoinhaber bleiben erhalten.
• Eine manuelle Pflege des Feldes Kontoinhaber wird nicht mehr automatisch durch die Standardvorbelegung überschrieben.
• Abweichende Kontoinhaber können dauerhaft erfasst und gespeichert werden.

Anpassung

• Die automatische Vorbelegung des Feldes Kontoinhaber erfolgt nur noch, wenn das Feld leer ist.
• Ist bereits ein Wert im Feld Kontoinhaber vorhanden, wird dieser nicht mehr durch den Namen des Debitors oder Kontakts ersetzt.
• Die Vorbelegung aus Debitor oder Kontakt steht weiterhin bei der Neuanlage zur Verfügung, sofern noch kein Kontoinhaber hinterlegt wurde.

Zusätzliche Hinweise
Die Änderung betrifft ausschließlich die automatische Befüllung des Feldes Kontoinhaber. Bereits gespeicherte Kontoinhaber werden durch die Änderung nicht verändert.

Belegnummer aus dem Bericht Afa-Buchung wird falsch gebildet

Ausgangssituation
Seit RELion Version 12.29 erhielt im Bericht Afa berechnen bei Verwendung mehrerer Zuständigkeitseinheiten (ZE) jede Afa-Buchung eine eigene, hochgezählte Belegnummer, sobald im Bericht eine Belegnummer eingetragen wurde.

Auswirkung
Statt der bisher üblichen gemeinsamen Belegnummer je Afa-Lauf (z. B. Monat.Jahr) entstand pro Buchung eine eigene laufende Nummer, was bei Kunden zu unerwünschten Ergebnissen führte.

Anpassung
Wird im Bericht Afa berechnen keine Belegnummer eingetragen, wird weiterhin eine Nummernserie aus dem Buchblatt verwendet. Wird im Bericht Afa berechnen eine Belegnummer erfasst, wird diese für alle erstellten Zeilen eingetragen; eine ZE-übergreifende Buchung mit derselben Belegnummer ist in diesem Fall nicht mehr zulässig. Ein entsprechender Buchungsversuch wird durch eine Fehlermeldung abgefangen, die auf die unterschiedlichen Zuständigkeitseinheiten und die gleiche Belegnummer hinweist.

Zusätzliche Hinweise
Der Tooltip zum Feld Belegnr. im Bericht Afa berechnen wurde ergänzt: Die eingetragene Belegnummer gilt für alle erstellten Zeilen und kann nur innerhalb derselben Zuständigkeitseinheit verwendet werden. Bei Verwendung mehrerer Zuständigkeitseinheiten sollte stattdessen eine Nummernserie über den Buch.-Blattnamen gepflegt werden.

Wiederk. Buch.-Blatt: Leistungszeitraum falsch und nicht änderbar

Ausgangssituation
Im wiederkehrenden Buchungsblatt wurde das Feld Leistungszeitraum bis automatisch berechnet. Bei Buchung auf den letzten Tag eines Zeitraums (z. B. Buchungsdatum 31.05.) und hinterlegter Wiederholungshäufigkeit (z. B. monatlich) wurde dabei ein falscher, deutlich zu später Wert ermittelt statt des erwarteten Periodenendes.

Auswirkung
Der angezeigte Leistungszeitraum stimmte nicht mit dem tatsächlichen Abrechnungszeitraum überein.

Anpassung
Die Berechnung des Feldes Leistungszeitraum bis berücksichtigt nun korrekt das Feld Leistungszeitraum von zusammen mit der hinterlegten Wiederholungshäufigkeit. Das Feld Leistungszeitraum bis ist nun editierbar. Eine Prüfung verhindert nun, dass der Leistungszeitraum bis vor dem Leistungszeitraum von liegt; in diesem Fall erscheint eine Fehlermeldung.

Instandhaltung

Aufgabenerstellung aus Notiz - Abfrage beim Buchen der EK-Belege fehlt

Ausgangssituation
Beim Buchen eines Einkaufsbelegs mit einer daran hängenden Notiz erschien beim Buchen keine Abfrage mehr, ob aus der Notiz eine Aufgabe erzeugt werden soll.

Auswirkung
Anwender, die Aufgaben aus Notizen erzeugen lassen, erhielten beim Buchen des Einkaufsbelegs keine mit dem gebuchten Beleg verknüpfte Aufgabe mehr. Um dennoch eine Aufgabe zu erhalten, musste die Notiz bzw. Aufgabe manuell ein zweites Mal direkt im gebuchten Beleg angelegt werden.

Anpassung
Das ursprüngliche Verhalten wurde wiederhergestellt: Beim Buchen des Einkaufsbelegs erscheint wieder die Abfrage, ob aus der in den gebuchten Beleg übernommenen Notiz eine Aufgabe erzeugt werden soll. Bei Bejahung dieser Abfrage wird eine Aufgabe angelegt, die mit dem gebuchten Beleg verknüpft ist.

Vertragsverwaltung

Filter Einheitenverträge funktioniert nicht richtig

Ausgangssituation
Auf der Seite Einheitenverträge wie auch auf anderen Vertragsseiten wurden Ansichten wie Aktive, Zukünftige und Beendete etc. eingeführt.

Auswirkung
Diese Ansichten wirken nicht additiv, d. h. bei Auswahl einer Ansicht wird eine zuvor gesetzte Filterung überschrieben. Dies führt in der Praxis zu Einschränkungen bzw. Auflösung einer bereits zuvor getroffenen Filterung 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.

Zusätzliche Hinweise
Es existieren weitere Seiten, die aktuell noch Ansichten verwenden. Diese werden mit künftigen RELion-Versionen ebenfalls angepasst.

Vertragsänderungsprotokoll - Spaltenbreite korrigieren

Ausgangssituation
Im Vertragsänderungsprotokoll wurden mehrstellige Beträge aufgrund einer zu geringen Spaltenbreite teilweise über zwei Zeilen umgebrochen dargestellt. Die Darstellung der Beträge war dadurch eingeschränkt lesbar.

Auswirkung
Mehrstellige Beträge werden nun vollständig in einer Zeile dargestellt. Die Lesbarkeit des Vertragsänderungsprotokolls wurde verbessert.

Anpassung
Die Spaltenbreite für die Betragsanzeige im Vertragsänderungsprotokoll wurde vergrößert. Das Layout des Berichts wurde entsprechend angepasst.

Zusätzliche Hinweise
Die Anpassung betrifft ausschließlich die Darstellung im Vertragsänderungsprotokoll; fachliche Berechnungen und Werte bleiben unverändert.

Status-Anzeige von Kautionszahlungen (unbezahlt/teilbezahlt/offen) funktioniert nicht in allen Fällen

Ausgangssituation
In der Übersicht der Mietverträge zeigt eine Spalte den Status der Mietsicherheit an (leer, Unbezahlt, Teilbezahlt oder Vollbezahlt). Wurde eine Mietsicherheit zu einem Vertrag gelöscht (z. B. eine versehentlich angelegte und wieder entfernte Sicherheit), wurde der angezeigte Status unabhängig vom tatsächlichen Zahlungsstand zurückgesetzt. Das galt auch dann, wenn am selben Vertrag noch weitere, gültige Mietsicherheiten mit eigenem Zahlungsstand bestehen blieben.

Auswirkung
Der angezeigte Status der Mietsicherheit in der Vertragsübersicht war in diesen Fällen nicht mehr zuverlässig und stimmte nicht mit dem tatsächlichen Zahlungsstand überein. Der korrekte Status erschien erst wieder, wenn der betroffene Vertrag bzw. eine seiner Mietsicherheiten erneut geöffnet und gespeichert wurde.

Anpassung
Beim Löschen einer Mietsicherheit wird der Status am Vertrag nicht mehr pauschal zurückgesetzt. Bestehen am Vertrag noch weitere Mietsicherheiten, wird der Status anhand dieser verbleibenden Sicherheiten korrekt neu ermittelt. Nur wenn keine Mietsicherheit mehr am Vertrag vorhanden ist, wird der Status geleert.

Zusätzliche Hinweise
Für bereits fehlerhaft angezeigte Bestandsverträge kann der Bericht Aktualisierung Mietsicherheitsstatus ausgeführt werden, um den Status für alle Verträge neu zu berechnen. Alternativ kann der betroffene Vertrag geöffnet und die Mietsicherheitsdaten erneut gespeichert werden.

Manuelle Mietanpassung: Erhöhung pro Verteilcode wird auch ohne gewählten Verteilcode berechnet

Ausgangssituation
Im Bericht Manuelle Erhöhung der manuellen Mietanpassung wurde beim Feld Erhöhung Betrag pro Verteilcode (netto) bzw. dessen Grenzen min. und max. nicht geprüft, ob tatsächlich ein Verteilcode ausgewählt war.

Auswirkung
Blieb das Feld Verteilcode leer, wurde trotzdem ein Erhöhungsbetrag berechnet und in die erzeugten Mietanpassungszeilen übernommen, obwohl unklar war, auf welchen Verteilcode sich die Erhöhung je m²/Verteileinheit bezieht.

Anpassung
Die Berechnung der Erhöhung je Verteilcode (netto-Betrag sowie Unter- und Obergrenze) prüft nun zusätzlich, ob ein Verteilcode ausgewählt wurde. Bleibt das Feld Verteilcode leer, wird keine Erhöhung mehr berechnet, unabhängig davon, welches der drei Erhöhungsfelder befüllt ist.

Zusätzliche Hinweise
Andere Erhöhungsarten (Fixbetrag, Prozentual) sind von dieser Änderung nicht betroffen.

Mietrechnung: doppelte Bildung von registrierten Mietrechnungen

Ausgangssituation
Bei der Registrierung eines Mietrechnungsvorgangs konnte es vorkommen, dass nach dem Erzeugen einer registrierten Mietrechnung ein nachfolgender Schritt (z. B. die Erzeugung des elektronischen Belegs) fehlschlug. In diesem Fall wurde die bereits angelegte registrierte Mietrechnung nicht mehr zurückgenommen, während der zugehörige Entwurf weiterhin bestehen blieb.

Auswirkung
Bei jedem erneuten Registrierungsversuch desselben Entwurfs wurde eine weitere, inhaltsgleiche registrierte Mietrechnung erzeugt. Dadurch konnten für denselben Vorgang bzw. Vertrag mehrere doppelte registrierte Mietrechnungen entstehen.

Anpassung
Schlägt ein Schritt bei der Registrierung fehl, wird die zuvor angelegte registrierte Mietrechnung inklusive Zeilen wieder entfernt. Der zugehörige Entwurf bleibt dabei unverändert erhalten und kann später erneut registriert werden, ohne dass ein Duplikat entsteht. Der Fehler wird protokolliert und ist über die Aktion Stammdaten prüfen auf der Seite Mietrechnungsliste einsehbar, sodass der betroffene Beleg gezielt korrigiert oder von der Registrierung ausgeschlossen werden kann, ohne die übrigen Belege im Vorgang zu blockieren.

Betriebskostenabrechnung

Abrechnung detailliert - Tage als Ganzzahl darstellen

Ausgangssituation

• Im Bericht Abrechnung detailliert für Einheit wurden die Werte in der Spalte Berechn.Tage/GesamtTage mit Nachkommastellen ausgegeben.
• Dadurch wurden beispielsweise Werte wie 365,00/365,00 dargestellt.
• Tage und Gesamttage stellen fachlich Ganzzahlwerte dar und sollen ohne Dezimalstellen ausgewiesen werden.

Auswirkung

• Die Darstellung der Tageswerte in der Einzelabrechnung entsprach nicht der fachlich erwarteten Ausgabe.
• Die Anzeige von Nachkommastellen konnte zu Missverständnissen bei der Interpretation der Abrechnung führen.

Anpassung

• Die Formatierung der Werte für Berechnungstage und Gesamttage wurde angepasst.
• In der Spalte Berechn.Tage/GesamtTage werden die Werte künftig beispielsweise als 365/365 ausgegeben.

Zusätzliche Hinweise

• Die Änderung betrifft ausschließlich die Darstellung der Werte im Bericht.
• Die Berechnung der Abrechnungsergebnisse bleibt unverändert, es muss jedoch Belege erzeugen neu gestartet werden.

Doppelte Darstellung detaillierter Vorauszahlungen in Hausgeldabrechnung bei Eigentümerwechsel

Ausgangssituation

• In Einzelfällen wurden in der Anlage Vorauszahlung Details Vorauszahlungen mehrfach dargestellt.
• Das Verhalten konnte bei WEG-Abrechnungen mit Eigentümerwechsel innerhalb des Abrechnungszeitraums auftreten.
• Die mehrfache Darstellung betraf ausschließlich die Ausgabe der Vorauszahlungen im Detail.

Auswirkung

• Vorauszahlungen wurden in der Detaildarstellung mehrfach ausgewiesen.
• Die Darstellung konnte zu Irritationen bei den Eigentümern führen.
• Die zugrunde liegenden Abrechnungsdaten und Berechnungsergebnisse waren hiervon nicht betroffen.

Anpassung

• Die Darstellung in der Anlage Vorauszahlung Details wurde korrigiert.
• Vorauszahlungen werden je Abrechnungsart korrekt zusammengeführt und nur einmal ausgegeben.
• Die Darstellung für Eigentümer- und Mieterabrechnungen wird weiterhin entsprechend der bisherigen Logik unterstützt.

Zusätzliche Hinweise

• Die Anpassung betrifft ausschließlich die Darstellung der Vorauszahlungen in der Detailanlage.
• Die Berechnung der Vorauszahlungen sowie die Abrechnungsergebnisse bleiben unverändert.
• Besonders relevant ist die Anpassung für Abrechnungen mit Eigentümerwechsel innerhalb des Abrechnungszeitraums.

Abrechnung bilanziell buchen - Rundungsdifferenzbetrag

Ausgangssituation
Bei der bilanziellen Buchung von Abrechnungen konnte es vorkommen, dass die in der Objekt-Abrechnungsübersicht ausgewiesenen Differenzbeträge nicht mit den im Buchblatt dargestellten Werten übereinstimmten. Ursache war eine abweichende Berechnung nicht anrechenbarer Steuerbeträge bei steuerfreien Einheiten.

Auswirkung
Die in der Objekt-Abrechnungsübersicht dargestellten Differenzen konnten von den tatsächlich gebuchten Differenzen abweichen. Die Abstimmung zwischen Abrechnungsübersicht und Buchungsergebnis war dadurch erschwert.

Anpassung
Die Aufsummierung der nicht anrechenbaren Steuerbeträge bei steuerfreien Einheiten wurde überarbeitet.

Zusätzliche Hinweise

• Die Änderung betrifft den Prozess Abrechnung bilanziell buchen.
• Durch die Anpassung wird eine konsistente Darstellung der Differenzbeträge in Übersicht und Buchung sichergestellt.

Abrechnung Anschreiben - Vorzeichen bei Vorauszahlung Zuschüsse

Ausgangssituation
In der Abrechnungstabelle des Anschreibens wurden Zuschüsse innerhalb der Spalte Ihre Vorauszahlung mit einem falschen Vorzeichen dargestellt. Die rechnerische Ermittlung der Abrechnung war davon nicht betroffen. Der Fehler betraf ausschließlich die Anzeige im Anschreiben.

Auswirkung

• Die Darstellung der Vorauszahlungen konnte irreführend sein, da Zuschüsse mit einem nicht korrekten Vorzeichen ausgewiesen wurden.
• Die zugrunde liegenden Berechnungen und die Abrechnungsergebnisse blieben unverändert korrekt.

Anpassung

• Die Darstellung der Zuschüsse in der Spalte Ihre Vorauszahlung wurde korrigiert.
• Zuschüsse werden nun mit dem fachlich korrekten Vorzeichen im Anschreiben ausgewiesen.

Zusätzliche Hinweise
Die Änderung betrifft ausschließlich die Ausgabe bzw. Darstellung im Anschreiben. Eine Änderung der Berechnungslogik oder der Abrechnungsergebnisse erfolgt nicht. Bestehende Abrechnungen sollten bei Bedarf hinsichtlich der Darstellung der Vorauszahlungen im Anschreiben überprüft werden.

RELion Dokumente

Löschung Mieter, der Wohnverhältnis nicht antreten möchte

Ausgangssituation
Die Löschung eines Mieters oder Einheitenvertrags konnte fehlschlagen, obwohl keine Dokumente mehr vorhanden waren, die Anhänge hatten.

Auswirkung
Einheitenvertrag konnte nicht gelöscht werden.

Anpassung
Die Löschprüfung wurde erweitert. Verwaiste Einträge in RELion Dokument ohne Dokumentbezug oder Dokumentanhang werden bei der Prüfung nicht mehr berücksichtigt.

Zusätzliche Hinweise
Gültige Dokumentverknüpfungen werden weiterhin geprüft und schützen vor unbeabsichtigten Löschungen.

Dokument kann nicht an Karte der Projektplanzeile archiviert werden

Ausgangssituation
Die Archivierung von Dokumenten an Projektplanzeilen funktionierte in der Kartenansicht nicht.

Auswirkung
Dokumente konnten in der Kartenansicht weder angezeigt noch archiviert werden.

Anpassung
Die Dokumenten-Infobox wurde korrigiert. Dokumente werden nun auch in der Kartenansicht angezeigt und können dort archiviert werden.

Unnötiger Index beim Archivieren der Dokumente

Ausgangssituation
Bei der Dokumentenarchivierung wurden Vertragsindizes teilweise erzeugt, obwohl keine Vertragsinformationen vorhanden waren.

Auswirkung
Dadurch wurden Vertragsindizes mit leerem Wert angelegt.

Anpassung
Vertragsklasse und Vertragsnummer werden nur noch dann als Archivindizes angelegt, wenn beide Angaben vollständig vorhanden sind. Indizes mit einem leeren Wert werden nicht erstellt.

Archivierungs-Assistent - Vertragsnr./Vertragsklasse bei einseitiger Füllung

Ausgangssituation
Im Archivierungs-Assistenten konnte die Archivierung fehlschlagen, wenn nur die Vertragsnummer oder nur die Vertragsklasse gefüllt war und die Felder nicht bearbeitet werden konnten.

Auswirkung
Die Archivierung konnte in bestimmten Fällen nicht abgeschlossen werden, weil die Vertragsnummer und die Vertragsklasse immer entweder beide leer oder beide gefüllt sein müssen.

Anpassung
Nicht editierbare Felder für Vertragsnummer und Vertragsklasse werden bei einseitiger Befüllung automatisch geleert. Dadurch kann die Archivierung erfolgreich durchgeführt werden.

E-Belege

XRechnung wird als fehlerhaft zurückgewiesen

Ausgangssituation
Beim Export einer gebuchten Debitorenverkaufsrechnung als XRechnung wurde die erzeugte XML-Datei bei der Validierung gegen das XRechnung-3.0-Schema als fehlerhaft eingestuft.

Auswirkung
Die exportierte XRechnung wäre vom Empfänger als ungültig zurückgewiesen worden. Ursache waren unter anderem eine falsche Position eines Elements im XML sowie vertauschte IBAN- und BIC-Angaben in den Zahlungsmitteldaten.

Anpassung
Die Position des betroffenen Elements im XML wurde korrigiert, sodass sie der Vorgabe des XRechnung-Schemas entspricht. IBAN und BIC werden bei der Erstellung der XRechnung nun korrekt den jeweiligen Feldern zugeordnet.

Zusätzliche Hinweise
Die Korrekturen betreffen sowohl den Rechnungs- als auch den Gutschriften-Export als XRechnung. Für Verkaufszeilen (auch bei Sachkontenbuchungen), zu denen ein E-Beleg erstellt wird, muss im Feld Einheitencode eine gültige Einheit angegeben sein, da die XRechnung sonst als fehlerhaft validiert werden kann. Für die korrekte Erstellung der XRechnung muss zudem die Steuerkategorie in der MwSt.-Buchungsmatrix-Einrichtung passend zum verwendeten Befreiungscode eingerichtet sein.

Berechtigungssätze

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

Tabelleninformationen Modell

Änderungen im Datenmodell werden in den Tabelleninformationen angezeigt.

Candidate 38.2

Performanceoptimierung im Dokumentenarchiv (BC 365 / RELion Dokumente)

Ausgangssituation
Nach der Migration in eine Azure-Umgebung wurden bei verschiedenen Business-Central-Seiten Performanceeinbußen festgestellt. Beim Wechsel zwischen Datensätzen wurde die Dokumentenarchiv-Infobox (Dokumentenarchiv Infobox) jeweils neu geladen und löste dabei umfangreiche Datenbankabfragen aus. Da mehr Daten geladen wurden als für die Anzeige erforderlich, verlängerten sich die Antwortzeiten insbesondere bei größeren Dokumentenbeständen.

Auswirkung
Seiten mit Dokumentenarchiv-Infobox reagierten verzögert, wodurch das Arbeiten in Listen und Belegen spürbar verlangsamt werden konnte. Der Effekt verstärkte sich bei häufigen Datensatzwechseln und großen Dokumentenbeständen.

Anpassung
Die Datenbankabfragen der Dokumentenarchiv-Infobox wurden optimiert: Geladen werden nur noch die für die Anzeige tatsächlich benötigten Daten, über speziell optimierte, schreibgeschützte Abfragen mit reduziertem Datenbankzugriff. Die bisherige Verarbeitung wurde vollständig durch die neue Implementierung ersetzt.

Zusätzliche Hinweise
Die Optimierung ist ab Version 12.37 der RELion Core Application enthalten. Sollten nach dem Update weiterhin Performanceeinbußen auftreten, wird eine erneute Analyse der Systemauslastung und der Profiler-Daten empfohlen.

Sachposten können im Konsolidierungsmandanten nicht geöffnet werden

Ausgangssituation
Beim Öffnen der Sachposten in einem Mandanten ohne RELion-Einrichtung, z. B. einem Konzern- oder Konsolidierungsmandanten, wurde eine Fehlermeldung angezeigt.

Auswirkung
Die Sachposten-Ansicht konnte in solchen Mandanten nicht geöffnet werden.

Anpassung
Die Sachposten-Seite prüft die RELion-Einrichtung nun korrekt und lässt sich dadurch auch in Mandanten ohne RELion-Einrichtung öffnen.