Version 12.40

Wichtig
XML-Berechtigungen werden mit diesem Release 12.40 das letzte Mal ausgeliefert.

RELion ONE stellt die Berechtigungsverwaltung künftig vollständig auf Systemberechtigungen (RELC, System) um.

Weitere Details sind der Dokumentation zu entnehmen.

Build

Neue und geänderte Funktionen

Allgemein

Cloud-Plan-basierte RELion-Lizenzprüfung

Ausgangssituation
Die RELion-Lizenznotwendigkeit eines Benutzers wurde ausschließlich anhand des lokalen (OnPrem-)Benutzer-Lizenztyps ermittelt. Für Benutzer der Windows-Gruppe war nicht klar geregelt, dass sie keine RELion-Lizenz benötigen. Es gab keine Anzeige, welcher Microsoft 365/Business Central-Plan einem Benutzer in der Cloud zugewiesen ist. Das Einlesen neuer Benutzer aus der Benutzertabelle nutzte eine abweichende Filterung, die nicht mit der übrigen Lizenzprüfung übereinstimmte. Nicht mehr benötigte RELion-Lizenzen konnten nur über eine einzelne, wenig flexible Funktion entfernt werden.

Auswirkung
In Business Central Online wurde die RELion-Lizenz-Notwendigkeit nicht korrekt ermittelt, da dort kein lokaler Lizenztyp existiert. Benutzer der Windows-Gruppe konnten fälschlich als RELion-lizenzpflichtig eingestuft werden. Administratoren konnten den einem Benutzer zugewiesenen Cloud-Plan nicht direkt in der RELion-Lizenzübersicht einsehen. Beim Einlesen neuer Benutzer konnten Benutzer berücksichtigt werden, die laut der eigentlichen Lizenzprüfung gar keine RELion-Lizenz benötigten. Nicht mehr benötigte Lizenzen ließen sich nicht gezielt nach Kriterien auswählen, sondern nur pauschal entfernen.

Anpassung
Die Notwendigkeit einer RELion-Lizenz wird in Business Central Online anhand der dem Benutzer zugewiesenen Microsoft 365/Business Central-Pläne korrekt ermittelt. Benutzer der Windows-Gruppe werden wie Benutzer mit eingeschränkten Rechten korrekt als nicht RELion-lizenzpflichtig behandelt. Ein neues Feld zeigt den zugewiesenen Cloud-Plan eines Benutzers an; bei mehreren zugewiesenen Plänen zeigt ein Klick auf das Feld alle Plannamen an. Das Einlesen neuer Benutzer aus der Benutzertabelle nutzt nun dieselbe Lizenzprüfung; nach dem Einlesen erscheint eine Meldung, falls keine neuen Benutzer gefunden wurden. Neue Auswahlfunktionen ermöglichen es, Benutzer nach verschiedenen Kriterien zu markieren (z. B. lizenziert, nicht lizenziert, benötigt eine Lizenz, benötigt keine Lizenz, Lizenz fehlt, Lizenz nicht mehr nötig). Für die markierten Benutzer kann die RELion-Lizenz gezielt in einem Schritt hinzugefügt oder entfernt werden. Neue Übersichten (Views) erleichtern das Filtern der Benutzerliste nach RELion-Status und Anmeldestatus. Die Seite bietet eine Kontexthilfe mit Verlinkung zur Online-Dokumentation sowie eine kurze geführte Einführung in die wichtigsten Funktionen.

Zusätzliche Hinweise
Weitere Informationen finden sich in der Online-Hilfe.

Instandhaltung

Outlook-Termin aus Inspektionstermin erstellen

Ausgangssituation
Aus einem Inspektionstermin konnte bislang kein Outlook-Kalendereintrag erstellt werden. Die Terminplanung und persönliche Organisation von Inspektionsterminen erforderte manuellen Aufwand außerhalb von RELion.

Auswirkung
Anwender mussten Inspektionstermine manuell in Outlook nachpflegen, um sie im eigenen Kalender zu führen.

Anpassung
In der Übersicht der Inspektionstermine sowie auf der Seite Inspektionstermin steht die neue Funktion Outlook-Termin erstellen zur Verfügung. Über die Funktion öffnet sich im Browser ein neuer Outlook-Termin, vorbefüllt mit dem Plandatum des Inspektionstermins, einer Uhrzeit (08:00 Uhr) sowie einem Titel und Beschreibungstext aus den relevanten Daten des Inspektionstermins. Der Outlook-Termin kann vor dem Speichern bearbeitet und um Datum, Uhrzeit, Teilnehmer, Ort und weitere Angaben ergänzt werden. Der Termin wird erst nach dem Speichern durch den Benutzer im Outlook-Kalender angelegt; eingeladene Teilnehmer erhalten den Termin automatisch zugesendet.

Zusätzliche Hinweise
Voraussetzung für das Speichern von Inspektionsterminen in Outlook ist eine auf dem Gerät installierte Outlook-Anwendung, über die sich Outlook im Browser öffnen lässt.

Feld “Anzahl gedruckt” bei gebuchter Verkaufsrechnung korrigiert

Ausgangssituation
In der gebuchten Verkaufsrechnung wurde das Feld Anzahl gedruckt beim Drucken eines Dokuments um 2 statt um 1 erhöht, sofern die Dokumentenarchivierung aktiviert war. Die Erhöhung erfolgte sowohl beim eigentlichen Druckvorgang als auch zusätzlich beim Archivieren des Dokuments.

Auswirkung
Der Wert im Feld Anzahl gedruckt entsprach nicht der tatsächlichen Anzahl der Druckvorgänge.

Anpassung
Die Archivierung eines Dokuments löst keine zusätzliche Erhöhung des Feldes Anzahl gedruckt mehr aus. Das Feld wird nur noch beim tatsächlichen Druckvorgang aktualisiert. Bestehende Archivierungsfunktionen arbeiten unverändert weiter.

Zusätzliche Hinweise
Beim Drucken ohne Archivierung erfolgt eine Erhöhung um 1. Beim Drucken mit Archivierung erfolgt die Erhöhung ebenfalls nur um 1. Eine Archivierung ohne Druck führt zu keiner Erhöhung.

Betriebskostenabrechnung

Fehlerbehandlung bei der Stapelverarbeitung “Abrechnung anlegen”

Ausgangssituation
Bei der Anlage von Abrechnungskarten für mehrere Objekte wurde die Verarbeitung beendet, sobald bei einem einzelnen Objekt ein Fehler auftrat. Nachfolgende Objekte wurden in diesem Fall nicht mehr verarbeitet. Eine vollständige Stapelverarbeitung war dadurch bei einzelnen fehlerhaften Objekten nicht möglich.

Auswirkung
Nachfolgende, an sich fehlerfreie Objekte wurden nicht mehr verarbeitet, sobald bei einem einzelnen Objekt ein Fehler auftrat. Abrechnungsläufe blieben dadurch unvollständig und mussten manuell nachgeholt werden.

Anpassung
Im Prozess Abrechnung anlegen wurde eine Fehlerbehandlung für die Stapelverarbeitung integriert. Die Abrechnungskarte wird weiterhin angelegt, sofern diese noch nicht vorhanden ist. Auftretende Fehler werden abgefangen und im Aktionsprotokoll dokumentiert. Bei einem Fehler werden die weiteren ausgewählten Verarbeitungsschritte für die betroffene Abrechnung nicht mehr ausgeführt; die Verarbeitung der übrigen Abrechnungen wird fortgesetzt.

Zusätzliche Hinweise
Die Bedienung der Funktion bleibt unverändert, bestehende Arbeitsabläufe müssen nicht angepasst werden. Grundsätzliche Einrichtungs- oder Konfigurationsfehler können gegebenenfalls weiterhin nicht automatisch behandelt werden; fehlende Abrechnungskreise bei einem Objekt führen weiterhin zu einem Fehler.

Erweiterung der Vertragsausnahmenprüfung

Ausgangssituation
Die Prüfung von Vertragsausnahmen erfolgte erst in nachgelagerten Verarbeitungsschritten. Fehlerhafte oder unvollständige Vertragsausnahmen konnten dadurch erst zu einem späteren Zeitpunkt erkannt werden. Die Darstellung von Fehlermeldungen war in der bisherigen Form nur eingeschränkt übersichtlich.

Auswirkung
Fehlerhafte oder unvollständige Vertragsausnahmen wurden erst in einem nachgelagerten Verarbeitungsschritt erkannt. Betroffene Datensätze und Fehlerursachen waren anhand der Fehlermeldungen nur eingeschränkt nachvollziehbar.

Anpassung
Die Prüfung wurde erweitert und erfolgt bereits direkt bei den Vertragsausnahmen. Vorhandene Ausnahmezeilen werden bereits bei der Erfassung bzw. Verarbeitung auf fachliche Korrektheit geprüft. Die Darstellung der Fehlermeldungen wurde überarbeitet, teilweise doppelte Zeilen wurden auf eine reduziert. Das Layout der Meldungen wurde verbessert, um betroffene Datensätze und Fehlerursachen verständlicher darzustellen. Die Prüfung bei leerem Filter Konten im Zusammenhang mit Zeilentyp Einzelkonto Absolut greift jetzt bereits in der Prüfung der Vertragsausnahmen.

Elektronische Belege

Nicht unterstütztes E-Belegformat PEPPOL30 wird blockiert

Ausgangssituation
Microsoft stellt im Business-Central-Standard neue Verarbeitungslogik für das elektronische Belegformat PEPPOL30 bereit. Diese neue Logik überträgt als Rechnungssteller nicht die Zahlungsempfänger-Informationen (ZE), sondern die Mandanteninformationen, und ist technisch grundlegend anders aufgebaut als das bisher unterstützte PEPPOL BIS 3.0. Eine Anbindung von RELion an dieses neue Format ist noch nicht erfolgt; eine Auswahl würde zu fehlerhaften E-Belegen führen.

Auswirkung
Ohne Absicherung könnte im Belegsendeprofil versehentlich das nicht unterstützte PEPPOL30-Format ausgewählt werden. Dies hätte zur Folge, dass fehlerhafte elektronische Belege erzeugt würden, da falsche Absenderinformationen übermittelt werden.

Anpassung
Ein Belegsendeprofil kann nicht mehr gespeichert werden, wenn das nicht unterstützte PEPPOL30-Format als elektronisches Belegformat hinterlegt ist. Die Formate PEPPOL BIS 3.0, XRechnung und ZUGFeRD bleiben weiterhin uneingeschränkt unterstützt und auswählbar. Die Prüfung erkennt und blockiert auch künftige, aktuell noch unbekannte elektronische Belegformate von Microsoft, sofern sie nicht zu den unterstützten Formaten zählen. Bei Auswahl eines nicht unterstützten Formats erscheint der Hinweis „Nicht unterstütztes E-Belegformat" mit dem Vorschlag, stattdessen XRechnung, ZUGFeRD oder PEPPOL BIS 3.0 zu verwenden; die Auswahl wird verworfen.

Mietanpassung

Vergleichsfeld “Index Online” in der Index Administration

Ausgangssituation
In der Tabelle RelC Index Administration stand bisher nur das – ggf. manuell gepflegte – Feld Index zur Verfügung; der online abgerufene Indexwert wurde nicht separat angezeigt.

Auswirkung
Es war nicht ersichtlich, ob und wie stark ein manuell erfasster Indexwert vom online abgerufenen Wert abweicht.

Anpassung
In der Tabelle steht nun ein zusätzliches, nicht editierbares Feld Index Online zur Verfügung. Das Feld wird auf der Seite Global Indexverwaltung direkt neben dem Feld Index angezeigt. Bei jedem Synchronisierungslauf wird Index Online automatisch mit dem online abgerufenen Wert befüllt, auch (und gerade) wenn dieser vom manuell erfassten Wert abweicht.

Zusätzliche Hinweise
Für Indexcodes ohne Online-Verfahren (rein manuelle Pflege) bleibt das Feld Index Online leer. Bereits vorhandene Datensätze werden nicht rückwirkend befüllt; der Wert wird erst ab dem nächsten Synchronisierungslauf eingetragen.

Vertragsverwaltung

Vertragsbeginn ändern am Einheitenvertrag: Startdatum der Sollstellungszeilen anpassen

Ausgangssituation

• Beim Ändern des Vertragsbeginns eines Einheitenvertrags im Assistenten Vertragsbeginn ändern blieb das Startdatum der zugehörigen Sollstellungszeilen unverändert.
• Waren bereits Buchungen vorhanden, erfolgte ein Eintrag in der Kachel Vertragsänderungen; über Änderungen überprüfen wurde die entstandene Differenz durch eine Gutschrift ausgeglichen, wobei Posten mit dem ursprünglichen Buchungsdatum stehen blieben.
• Waren noch keine Buchungen vorhanden, mussten die Sollstellungszeilen bisher manuell außerhalb des Assistenten angepasst werden.
• Zukünftige Sollstellungszeilen, die durch die Berechnung der Staffelmiete entstanden waren, blieben dabei unberücksichtigt.

Auswirkung
Nach einer Änderung des Vertragsbeginns war zusätzlich eine manuelle Anpassung der Sollstellungszeilen außerhalb des Assistenten erforderlich.

Anpassung

• Die Start- und Enddaten der Sollstellungszeilen werden jetzt direkt im Assistenten Vertragsbeginn ändern angepasst; ein Verlassen des Assistenten ist dafür nicht mehr erforderlich.
• Das gilt auch für Sollstellungszeilen, die durch die Berechnung der Staffelmiete entstanden sind.
• Ein neuer Schalter Startdatum der Sollstellungszeilen anpassen ist standardmäßig eingeschaltet und ermöglicht die Anpassung der Sollstellungszeilen direkt im Assistenten; wird er ausgeschaltet, läuft der Assistent wie bisher.
• Der Assistent schlägt ein neues Startdatum nur für Sollstellungszeilen vor, deren bisheriges Startdatum dem alten Vertragsbeginn entspricht; als neues Startdatum wird dann der neue Vertragsbeginn übernommen, unabhängig davon, ob dieser früher oder später liegt. Alle anderen Zeilen behalten ihr Startdatum, können aber ebenfalls manuell geändert werden.
• Die angezeigte Liste umfasst alle nicht stornierten Sollstellungszeilen des Einheitenvertrags.

Zusätzliche Hinweise
Bei ausgeschaltetem Schalter prüft der Assistent weiterhin, ob ungebuchte Sollstellungszeilen vor dem neuen Vertragsbeginn beginnen; ist das der Fall, bricht der Assistent mit einer entsprechenden Meldung ab. Bei eingeschaltetem Schalter wird dies bei der Anpassung der Sollstellungszeilen berücksichtigt.

WEG Verwaltung

Menüaufruf “Eigentümerobjekte”: Mietverträge durch WEG Kaufverträge ersetzt

Ausgangssituation
Auf der Seite Eigentümerobjekte führte der Menüaufruf zu den Mietverträgen, obwohl im Kontext von Eigentümerobjekten (WEG) die Kaufverträge relevant sind.

Auswirkung
Anwender gelangten über diesen Aufruf nicht zu den relevanten Kaufvertragsdaten.

Anpassung
Der Menüaufruf Mietverträge auf der Seite Eigentümerobjekte wurde durch den Aufruf WEG Kaufverträge ersetzt.

Schnellfilter statt Ansichten: WEG Kaufverträge

Ausgangssituation
Auf der Seite WEG Kaufverträge existierte der Bereich Ansichten mit den Einträgen Alle, Erfasst und Freigegeben. Solche Ansichten wurden mit RELion ONE auch auf diversen anderen Seiten eingeführt.

Auswirkung
Die Ansichten wirkten nicht additiv: Bei Auswahl einer Ansicht wurde eine zuvor gesetzte Filterung überschrieben. Dies führte in der Praxis zu Einschränkungen bei der gezielten Datenauswahl.

Anpassung
Die Ansichten auf der Seite WEG Kaufverträge wurden durch die Funktion Schnellfilter ersetzt. Schnellfilter wirken ergänzend zur bestehenden Filterung und ermöglichen eine flexiblere, kombinierbare Datenauswahl. Zusätzlich wurde das Menü Aktionen auf der Seite WEG Kaufverträge übersichtlicher gestaltet.

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

WEG Entgeltüberleitung Startdatum im Bericht

Ausgangssituation
Im Bericht WEG Entgeltüberleitung konnte bislang nur ein oberes Datumslimit (Buchungen bis Datum) für die Berücksichtigung von Buchungen angegeben werden. Der Bericht war zudem nicht direkt aus der zugehörigen Listenseite heraus aufrufbar.

Auswirkung
Buchungen konnten nicht gezielt auf einen bestimmten Zeitraum eingegrenzt werden, sondern nur bis zu einem Enddatum berücksichtigt werden. Der Bericht musste über einen anderen Weg aufgerufen werden, da keine direkte Ausführung aus der Listenseite möglich war.

Anpassung
In den Optionen des Berichts steht nun das optionale Feld Buchung ab Datum zur Verfügung, mit dem zusätzlich ein Startdatum für die Berücksichtigung von Buchungen festgelegt werden kann. Bleibt das Feld leer, bleibt das bisherige Verhalten unverändert. Wird ein Startdatum angegeben, das nach dem Enddatum liegt, erscheint eine Fehlermeldung. Die Filterlogik des Berichts berücksichtigt das neue Startdatum in allen betroffenen Verarbeitungsschritten (Rechnungen, Gutschriften sowie deren Stornierungen). Der Bericht ist nun direkt als Aktion in der zugehörigen Listenseite aufrufbar.

Stammdaten

Schnellfilter statt Ansichten: Objektübersicht

Ausgangssituation
Auf der Seite Objektübersicht existierte der Bereich Ansichten zur Filterung der angezeigten Daten. Solche Ansichten wurden mit RELion ONE auch auf diversen anderen Seiten eingeführt.

Auswirkung
Die Ansichten wirkten nicht additiv: Bei Auswahl einer Ansicht wurde eine zuvor gesetzte Filterung überschrieben. Dies führte in der Praxis zu Einschränkungen bei der gezielten Datenauswahl.

Anpassung
Die Ansichten auf der Seite Objektübersicht wurden durch die Funktion Schnellfilter ersetzt. Schnellfilter wirken ergänzend zur bestehenden Filterung und ermöglichen eine flexiblere, kombinierbare Datenauswahl.

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

Projektentwicklung

Word-Seriendruck für Bürgschaften-Rückgabeschreiben aus dem Projekt

Ausgangssituation
Für Bürgschaften und Einbehalte aus dem Projekt-Modul stand bislang keine Möglichkeit zur Verfügung, einen Word-Seriendruck zu erstellen.

Auswirkung
Schreiben zur Rückgabe von Bürgschaften mussten ohne automatisierten Seriendruck aus dem Projekt erstellt werden.

Anpassung
Aus einer Projektplanzeile kann über Aktionen ein Word-Seriendruck für Bürgschaften-Rückgabeschreiben erstellt werden. Dabei wird je Durchlauf nur eine Bürgschaft berücksichtigt; sind mehrere Bürgschaften vorhanden, wird die mit dem ältesten Fälligkeitsdatum herangezogen. Berücksichtigt werden dabei nur Bürgschaften, bei denen das Feld Zurückgegeben am nicht leer und das Feld Storniert nicht gesetzt ist. Der Seriendruck stellt u. a. Angaben zu Projekt, Kreditor, Objekt/Gebäude/Hauseingang/Einheit und Zuständigkeitseinheit sowie zur jeweiligen Bürgschaft (Nr., Fälligkeit, Beschreibung, Betrag, Erstellungsdatum, Art) zur Verfügung.

Zahlungsverkehr

Darstellung Sammelmandat in SEPA-Bestätigung verbessert

Ausgangssituation

• Beim Ausdruck der SEPA-Lastschrifteinzugsbestätigung (Word) für Sammelmandate wurde nur ein kleiner Teil der Datenfelder befüllt.
• Vertragsnummer und Objekt blieben bei Sammelmandaten korrekterweise leer, da kein Bezug zu einem einzelnen Vertrag oder Objekt besteht.
• Zusätzlich blieben jedoch auch die Anschrift des Empfängers, die Bearbeiterdaten (Name, Telefon, Fax, E-Mail) und die Absenderanschrift leer, obwohl diese Angaben vorhanden waren.
• Bei Vertragsmandaten, Einheitenmandaten und Sollstellungsmandaten war das Schreiben bereits vollständig befüllt.
• Im Eigentümer-Bereich des Schreibens wurde unabhängig von der Mandatsart eine Bankverbindung ausgewiesen.
• Der einleitende Anschreibentext war unabhängig von der Mandatsart immer identisch formuliert.

Auswirkung

• Für Sammelmandate erzeugte Schreiben enthielten weder Empfängeradresse noch Bearbeiterangaben noch Absenderanschrift.
• Das Dokument konnte dadurch nicht direkt wie vorgesehen versendet werden und musste manuell nachbearbeitet oder ergänzt werden.
• Die Bankverbindung im Eigentümer-Bereich war für den Empfänger ohne Mehrwert ersichtlich.
• Der Anschreibentext passte inhaltlich nicht in allen Fällen zur jeweiligen Mandatsart (Sammelmandat, Sollstellungsmandat, Vertrags-/Einheitenmandat).

Anpassung

• Bei Sammelmandaten werden die Empfängeradresse, die Bearbeiterdaten und die Absenderanschrift nun direkt aus dem Debitor und dessen Kontaktdaten ermittelt, unabhängig von einem Vertragsbezug.
• Die Bankverbindung im Eigentümer-Bereich wird nicht mehr ausgewiesen; dies betrifft Sammelmandate und Vertragsmandate gleichermaßen.
• Der einleitende Anschreibentext richtet sich nun nach der jeweiligen Mandatsart.

Erstellungszeitpunkt in SEPA-pain-Dateien ohne Sekundenbruchteile

Ausgangssituation

• Betroffen sind die Formate Deutschland (DK-Version 3.1 und 3.7) sowie Österreich (Rulebook RB6 und RB2023).
• Der Erstellungszeitpunkt <CreDtTm> wurde bisher mit drei Nachkommastellen bei den Sekunden erzeugt, z. B. 2026-08-28T20:59:40.000Z.
• Das österreichische Rulebook RB2023 schränkt das Format des Elements über ein eigenes Muster (Pattern) ein. Nach diesem Muster sind höchstens drei Nachkommastellen zulässig, die letzte Nachkommastelle darf nicht 0 sein. Der Wert .000 entsprach damit nicht dem österreichischen Schema.
• Die deutschen DK-Schemas enthalten diese Einschränkung nicht; dort war der bisherige Wert gültig.

Auswirkung

• Bei einer strengen Schema-Prüfung konnten pain-Dateien nach RB2023 von österreichischen Banken abgelehnt werden.
• Für deutsche pain-Dateien ergab sich keine Einschränkung; die Dateien wurden z. B. von der Konfipay-Schnittstelle angenommen.

Anpassung

• Der Erstellungszeitpunkt <CreDtTm> wird ohne Sekundenbruchteile ausgegeben. Neues Format: JJJJ-MM-TTThh:mm:ssZ, z. B. 2026-08-28T20:59:40Z statt bisher 2026-08-28T20:59:40.000Z.
• Die Anpassung gilt einheitlich für alle unterstützten Versionen: DK 3.1, DK 3.7, RB6 und RB2023. Das neue Format ist nach den deutschen und den österreichischen Schemas gültig.

Zusätzliche Hinweise

• Für die Anwendung ist keine Aktion erforderlich. Die Umstellung erfolgt automatisch bei der Dateierstellung.
• Das Kennzeichen Z steht für die koordinierte Weltzeit (UTC). Gegenüber der Ortszeit in Deutschland und Österreich ergibt sich eine Differenz von einer Stunde (Winterzeit) bzw. zwei Stunden (Sommerzeit).

Verwalterhonorar

Word-Vorlage für Verkaufsrechnung Verwalterhonorar

Ausgangssituation
Für die gebuchte Verkaufsrechnung/Verwalterhonorar (Bericht Nr. 5052293) stand bisher ausschließlich der Standard-RDLC-Bericht zur Verfügung.

Auswirkung
Für diesen Beleg konnte keine Word-Vorlage anstelle des Standardberichts erzeugt werden.

Anpassung
Für die gebuchte Verkaufsrechnung/Verwalterhonorar (Bericht Nr. 5052293) steht nun eine Word-Vorlage zur Verfügung. Die Word-Vorlage kann über die entsprechende Option in der Requestpage des Berichts anstelle des Standard-RDLC-Berichts verwendet werden.

Fehlerbehebung

Buchhaltung

Fehler Bericht Debitoren OP nach Objekt - falscher Summenausweis bei einem Debitor

Ausgangssituation
Beim Bericht Debitoren OP nach Objekt wurde bei einem Debitor mit offenen Posten in mehreren Objekten die Summenzeile ab dem zweiten Objekt fehlerhaft ausgewiesen. Die Summenzeile zeigte nicht nur die Summe des jeweiligen Objekts, sondern zusätzlich die aufaddierten Summen aller zuvor aufgelisteten Objekte desselben Debitors.

Auswirkung
Anwender erhielten bei Debitoren mit offenen Posten in mehreren Objekten zu hohe Objekt-Summenzeilen im Bericht. Dies konnte zu falschen Rückschlüssen bei der Auswertung der Debitorensalden führen. Die Gesamtsumme am Ende des Berichts war von dem Fehler nicht betroffen und zeigte stets den korrekten Wert.

Anpassung
Die Summenbildung wurde korrigiert, sodass jede Objekt-Summenzeile nun ausschließlich die Summe des jeweiligen Objekts zeigt.

Debitorenpostenausgleich: Teilbetrag wurde nicht korrekt übernommen

Ausgangssituation
Beim manuellen Ausgleich von Debitorenposten über die Seite Debitorenpostenausgleich (durch manuelle Eingabe eines Werts im Feld Ausgleichsbetrag) wurde ein eingegebener Teilbetrag nicht korrekt übernommen, wenn der Restbetrag der Zahlung oder Gutschrift kleiner als der Restbetrag der Rechnung war. Statt des gewünschten Teilbetrags erschien in diesen Fällen ein falscher Betrag, etwa der volle Restbetrag der Rechnung anstelle des tatsächlich noch verfügbaren Gutschrift- oder Zahlungsbetrags. Ein manuell eingegebener Ausgleichsbetrag wurde beim Speichern teilweise wieder verworfen oder verfälscht.

Auswirkung
Debitorenposten konnten nicht zuverlässig teilweise ausgeglichen werden. Ein Ausgleichsbetrag ließ sich nicht zuverlässig auf mehrere offene Posten aufteilen, ohne dass falsche Beträge angezeigt wurden. Komplexe Ausgleichsvorgänge mit mehreren betroffenen Posten waren dadurch erheblich erschwert.

Anpassung
Die Berechnung des Ausgleichsbetrags beim Anwenden eines Postens wurde korrigiert. Bei der Ermittlung, welcher Teil einer Zahlung, Gutschrift oder Rückerstattung bereits anderen Posten zugeordnet ist, wird der gerade anzuwendende Posten selbst nun korrekt nicht mehr mitgezählt. Der verfügbare Betrag des anzuwendenden Belegs wird nun korrekt als Grundlage der Berechnung herangezogen. Ein manuell eingegebener Ausgleichsbetrag bleibt dadurch erhalten und kann zuverlässig auf mehrere Posten aufgeteilt werden.

Falsche Übernahme des kumulierten AfA-Werts bei Zuschreibungen

Ausgangssituation
Im Bericht RE Anlagenspiegel mit Umbuchung wurde bei Anlagen, für die eine Zuschreibung gebucht wurde, der kumulierte AfA-Wert des Vorjahres falsch berechnet. Die gebuchte Zuschreibung wurde dabei fälschlicherweise in die kumulierte Abschreibung eingerechnet, anstatt separat als Teil des Anschaffungswerts behandelt zu werden. Der Bericht RE Anlagenspiegel (ohne Umbuchungen) sowie die übrigen Werte (Anschaffungskosten, Buchwerte) waren von diesem Fehler nicht betroffen.

Auswirkung
Im Folgejahresbericht wich der ausgewiesene Wert kum. AfA bis [Vorjahr] vom tatsächlich korrekten Wert ab. Dies führte zu Unstimmigkeiten zwischen dem Bericht des laufenden Jahres und dem des Folgejahres für Anlagen mit gebuchten Zuschreibungen.

Anpassung
Die Berechnung der Spalte kum. AfA bis [Vorjahr] wurde korrigiert. Welche Buchungsarten tatsächlich Teil der kumulierten Abschreibung sind, wird nun anhand der Einrichtung je AfA-Buch ermittelt, statt über einen festen Wertebereich der Buchungsart. Zuschreibungen fließen dadurch nicht mehr in die kumulierte AfA ein.

Fehlerhafte Bezeichnung im Hinweistext zur Ratenzahlung

Ausgangssituation
Im Bestätigungsdialog beim Ausführen der Ratenzahlung wurde als Quelle des hinterlegten Gegenkontos der Begriff IM Einrichtung angezeigt.

Auswirkung
Die Bezeichnung IM Einrichtung stimmte nicht mit der tatsächlichen Bezeichnung des Einrichtungsbereichs überein und konnte beim Anwender zu Verwirrung führen.

Anpassung
Der Hinweistext im Bestätigungsdialog verwendet nun die korrekte Bezeichnung RE Einrichtung.

Funktion nicht anr. Vorsteuer bei einer Gutschrift mit unrealisierter VSt. führt zu falscher Buchung

Ausgangssituation
Beim Buchen einer Einkaufsrechnung mit unrealisierter Vorsteuer und einer dazu nicht ausgeglichenen Gutschrift mit unrealisierter Vorsteuer wählte die Funktion Nicht anrechenbare Vorsteuer berechnen und buchen für die Gutschrift das Konto der realisierten statt der unrealisierten nicht anrechenbaren Vorsteuer.

Auswirkung
Es entstanden falsche Buchungssätze und falsche Salden auf den betroffenen Konten, obwohl diese bei korrektem Verhalten einen Saldo von 0 hätten aufweisen müssen.

Anpassung
Die Kontoauswahl berücksichtigt nun den tatsächlichen Ausgleichsstatus des Belegs anstelle des reinen Belegtyps, sodass auch eine nicht ausgeglichene Gutschrift korrekt als unrealisiert behandelt wird. Die Konten werden dabei aus der Einrichtung der MwSt.-Buchungsmatrix herangezogen.

Zusätzliche Hinweise
Betroffen ist die Funktion Nicht anrechenbare Vorsteuer berechnen und buchen.

Zahlungsverkehr

Falscher Verwendungszweck bei Guthabenauszahlung mit mehreren Debitorenposten

Ausgangssituation
Im Bericht RE Auszahlungsvorschlag werden pro Debitorenposten eigene Zahlungsvorschlagszeilen erstellt. Der Verwendungszweck wird gemäß der Einrichtung im Feld Auszahlung Verwendungszweck gebildet, zum Beispiel mit dem Platzhalter %16 für die Beschreibung des Debitorenpostens. Bei mehreren Debitorenposten derselben Einheit wurde für alle Zeilen derselbe Debitorenposten ausgelesen, und zwar der mit der frühesten Fälligkeit.

Auswirkung
Alle Zeilen enthielten denselben Verwendungszweck, zum Beispiel jeweils „…BK/HK-2018 Betriebs- und Heizkostenabrechnung 2018“. In den Zahlungsvorschlagszeilen standen außerdem dieselbe laufende Nummer des Debitorenpostens und dieselbe Belegnummer. Der Ausgleich der Debitorenposten war davon nicht betroffen, die Beträge und der Ausgleich waren korrekt.

Anpassung
Jede Zahlungsvorschlagszeile verwendet nun den zugehörigen Debitorenposten. Laufende Nummer, Belegnummer und Verwendungszweck werden je Zeile aus dem richtigen Posten gebildet. Bei zwei Debitorenposten entstehen zwei Zeilen mit jeweils eigenem Verwendungszweck.

Zusätzliche Hinweise
Bereits erstellte Auszahlungsvorschläge werden nicht automatisch korrigiert; diese sind neu zu erstellen. Eine Zusammenfassung mehrerer Posten zu einer Zeile erfolgt in diesem Bericht weiterhin nicht.

Betriebskostenabrechnung

Fehlende Vorzeichen in Nebenkosten-Anschreiben

Ausgangssituation
Beim Druck des Anschreibens der Nebenkostenabrechnung wurden die Vorzeichen in der Spalte Nachzahlung (+) / Guthaben (-) nicht einheitlich dargestellt. Bei den Einzelpositionen erschien das Vorzeichen korrekt, bei den zugehörigen Summenzeilen („Gesamt Betrag [Kostenart-Gruppe]“) fehlte bei positiven Werten (Nachzahlung) das führende Pluszeichen.

Auswirkung
Summenzeilen mit einer Nachzahlung wurden ohne Vorzeichen dargestellt, während Summenzeilen mit einem Guthaben korrekt mit Minuszeichen erschienen, was im Anschreiben uneinheitlich wirkte. Das Gesamtergebnis am Ende der Abrechnung war von diesem Fehler nicht betroffen.

Anpassung
Die Formatierung der Summenzeilen in der Spalte „Nachzahlung (+) / Guthaben (-)“ wurde vereinheitlicht, sodass positive Summenbeträge nun ebenfalls mit einem führenden Pluszeichen dargestellt werden.

D-Sätze werden bei ungeeignetem Dateiformat nicht korrekt eingelesen

Ausgangssituation
Beim Import von D-Sätzen im Heizkosten-Datenaustausch konnte versehentlich eine ZIP-Datei anstelle der eigentlichen Importdatei ausgewählt werden. Da der Import keine Prüfung des Dateiformats durchführte, wurde die Datei trotz ungeeigneten Formats verarbeitet.

Auswirkung
In diesem Fall wurde der erste Datensatz der Datei nicht übernommen, während die übrigen Datensätze korrekt importiert wurden. Der Import wurde ohne Fehler- oder Warnmeldung abgeschlossen, sodass der Datenverlust für Anwender nicht unmittelbar erkennbar war.

Anpassung
Der Import wurde erweitert, sodass ungeeignete Dateiformate erkannt und nicht mehr verarbeitet werden. Anwender erhalten nun eine eindeutige Rückmeldung, wenn eine nicht unterstützte Datei für den Import ausgewählt wird.

Abrechnungsstatistik kann nicht berechnet werden - Name ist zu lang

Ausgangssituation
In der Abrechnungsstatistik konnte die Aktion Zeilen aktualisieren bei Benutzerkennungen mit mehr als 20 Zeichen nicht ausgeführt werden. Betroffen waren insbesondere lange Benutzerkennungen externer Azure-AD-Benutzer.

Auswirkung
Die Aktualisierung der Abrechnungsstatistik wurde mit einer Fehlermeldung zur Überschreitung der zulässigen Zeichenlänge abgebrochen. Die Abrechnungsstatistik konnte dadurch für betroffene Benutzer nicht berechnet werden.

Anpassung
Das für die Benutzerkennung verwendete Feld Gespeichert durch wurde von 20 auf 50 Zeichen erweitert. Dadurch können auch längere Benutzerkennungen bei der Berechnung der Abrechnungsstatistik verarbeitet werden.

Zusätzliche Hinweise
Eine Anpassung durch den Anwender ist nicht erforderlich. Für das bisherige Verhalten war kein praktikabler Workaround auf Anwenderseite vorhanden. Aufgrund von technischen Restriktionen wird diese Änderung erst im Release 12.43 wirksam.

Mietanpassung

Bericht Sollmietenveränderung zeigt beendete Einheitenverträge nicht an

Ausgangssituation
Der Bericht Sollmietenveränderung zeigte beendete Einheitenverträge innerhalb des gewählten Berichtszeitraums nicht an. Dies betraf insbesondere Verträge, die zwischen Von-Datum und Bis-Datum des Berichtszeitraums endeten, obwohl zu Beginn des Zeitraums noch Sollstellungen für diese Verträge bestanden.

Auswirkung
Die Gesamtsumme Summe Objekt veränderte sich um den Betrag der nicht angezeigten, beendeten Verträge, ohne dass eine sichtbare Zeile diese Veränderung erklärte. Bei aktivierter Option Nur Differenzen war die Differenz in der Summenzeile für den Anwender nicht nachvollziehbar.

Anpassung
Eine beendete Einheit wird im Bericht nun mit ihrem ursprünglichen Betrag angezeigt, wodurch der Änderungsbetrag für den Anwender nachvollziehbar ist.

Mietanpassungsvorschlag wird trotz kritischem Wert nicht erstellt

Ausgangssituation
Im Einheitenvertrag musste die hinterlegte Sollstellungsart des Index mit der Sollstellungsart der zugehörigen Indexregel übereinstimmen, damit der Vertrag bei der Mietvertragsindexerhöhungs-Prüfung berücksichtigt wurde. Wurde die Sollstellungsart in der Indexregel geändert oder die Indexregel gelöscht, wurde der Einheitenvertrag nicht in allen Fällen zuverlässig aktualisiert, sodass die Werte auseinanderlaufen konnten. Die Mietvertragsindexerhöhungs-Prüfliste verglich Einheitenvertrag und Indexregel exakt anhand dieser Sollstellungsart.

Auswirkung
Bei abweichenden Werten wurde der betroffene Einheitenvertrag ohne Fehlermeldung nicht mehr in der Mietvertragsindexerhöhungs-Prüfliste angezeigt. Für mehrere Mietverträge wurde dadurch trotz erfüllter Erhöhungsvoraussetzungen kein Mietanpassungsvorschlag erstellt.

Anpassung
Die Sollstellungsart wird jetzt technisch eindeutig abgebildet, wodurch die Bezeichnungen für alle Sollstellungsarten korrekt angezeigt werden. Die Mietvertragsindexerhöhungs-Prüfliste sowie weitere betroffene Auswertungen berücksichtigen Einheitenverträge nun korrekt, auch wenn zuvor eine Abweichung bestand. Beim Ändern oder Löschen einer Indexregel wird die Sollstellungsart (sowie ggf. die Indexbezeichnung) im zugehörigen Einheitenvertrag automatisch synchronisiert.

Zusätzliche Hinweise
Bestehende Daten werden im Rahmen des Updates automatisch anhand der vorhandenen Indexregeln abgeglichen und korrigiert, sodass keine manuelle Nacharbeit erforderlich ist.

WEG Verwaltung

Korrekturen bei der Verarbeitung von Vorschreibungen im Wirtschaftsplan

Ausgangssituation
Bei der Erstellung eines Wirtschaftsplans konnten vorhandene Vorschreibungen in bestimmten Konstellationen nicht vollständig in die Wirtschaftsplanzeilen übernommen werden. Bei der Verarbeitung mehrerer Einheiten konnten Informationen aus einer zuvor verarbeiteten Sollstellung die Ermittlung nachfolgender Wirtschaftsplanzeilen beeinflussen. Bei mehreren vorhandenen Sollstellungen mit unterschiedlichen Konten konnte für eine Einheit ein nicht zutreffendes Sollstellungskonto ermittelt werden. Bei der Verarbeitung von 0-Beträgen konnten fachlich relevante Zeilen, insbesondere im Zusammenhang mit der Ausfallsrücklage, betroffen sein.

Auswirkung
Wirtschaftsplanzeilen konnten trotz vorhandener Sollstellungen und vorhandener Daten für den Wirtschaftsplan fehlen. Bei der Berechnung des Wirtschaftsplans konnte ein nicht zutreffendes Sollstellungskonto berücksichtigt werden. Dadurch konnten Konto und für die Berechnung verwendete Werte nicht zueinander passen. Die Verarbeitung der Ausfallsrücklage konnte bei der Bereinigung von Zeilen mit einem Betrag von 0 zu einem nicht erwarteten Ergebnis führen.

Anpassung
Die Verarbeitung der Vorschreibungen wurde korrigiert, sodass die Ermittlung der Wirtschaftsplanwerte für jede Sollstellung mit den jeweils zutreffenden Daten erfolgt. Die Verarbeitungsreihenfolge der Sollstellungen wurde angepasst. Die Ermittlung des zu einer Sollstellung gehörenden Kontos wurde korrigiert. Die Verarbeitung der Ausfallsrücklage wurde angepasst. Damit werden vorhandene Vorschreibungen bei der Erstellung des Wirtschaftsplans entsprechend der jeweiligen Einheit und Kontenzuordnung verarbeitet. Darüber hinaus wurde eine Ausnahmenprüfung korrigiert, die bei Ausnahmen ohne Vertragsbezug irrtümlich eine Fehlermeldung erzeugte und das Anwenden der Ausnahmen in Abrechnung und Wirtschaftsplan verhinderte. Beim Anwenden der Ausnahmen werden jetzt automatisch die Ausschlussgründe in den Wirtschaftsplan-Summenposten unter Berücksichtigung der neuen Beträge aktualisiert.

Zusätzliche Hinweise
Die Änderungen betreffen die Verarbeitung von Vorschreibungen bei der Erstellung bzw. Berechnung des Wirtschaftsplans.

Ausnahmen des Typs WGG-Deckelung - Fehler in der Kontenfindung

Ausgangssituation
Bei der Anwendung von Ausnahmen des Typs WGG-Deckelung (AT) im Wirtschaftsplan konnte es zu einer fehlerhaften Kontenfindung in den erzeugten Summenposten kommen. In betroffenen Fällen wurde für Summenposten nicht das vorgesehene Vorschreibungskonto verwendet, wodurch Folgeprozesse beeinträchtigt werden konnten.

Auswirkung
Die Kontenzuordnung in Summenposten nach Anwendung der WGG-Deckelung konnte fehlerhafte Ergebnisse liefern. Dadurch bestand das Risiko, dass nachgelagerte Verarbeitungen auf einer nicht korrekten Kontenbasis ausgeführt wurden. Betroffen war die österreichische Funktion zur WGG-Deckelung im Bereich Wirtschaftsplan.

Anpassung
Die Verarbeitung der WGG-Deckelungs-Ausnahmen wurde korrigiert. Die Kontenfindung für Summenposten erfolgt nun wieder auf Basis des vorgesehenen Vorschreibungskontos. Eine fehlerhafte Überschreibung der Kontozuordnung während der Verarbeitung von WGG-Deckelungs-Ausnahmen wurde entfernt.

Zusätzliche Hinweise
Die Korrektur wurde als Hotfix umgesetzt. Die Änderung betrifft ausschließlich Fälle, in denen Ausnahmen des Typs WGG-Deckelung (AT) verwendet werden.

Einheitenstorno bei vorhandenen Summenposten im Wirtschaftsplan nicht möglich

Ausgangssituation
Beim Stornieren eines Einheitenvertrags blieben zugehörige Summenposten in Wirtschaftsplan und Abrechnung bestehen.

Auswirkung
Der Einheitenvertrag konnte danach nicht gelöscht werden, da er noch durch diese Summenposten verwendet wurde. Der Storno-Assistent wies vor dem Fertigstellen nicht auf die betroffenen Wirtschaftsplan-Summenposten und die Einheit-Wirtschaftsplan-Daten hin.

Anpassung
Die Summenposten der Einheit werden beim Einheitenstorno sowohl in der Wirtschaftsplan- als auch in der Abrechnungsverarbeitung nun mitgelöscht, sodass sich der Einheitenvertrag anschließend löschen lässt. Das Protokoll des Storno-Assistenten zeigt betroffene Wirtschaftsplan-Summenposten und Einheit-Wirtschaftsplan-Daten bereits vor dem Fertigstellen an.

Zusätzliche Hinweise
Die bestehende Sperre des Wirtschaftsplans bleibt von dieser Anpassung unverändert. Wurde für eine Einheit in einem bereits vollständig verarbeiteten Wirtschaftsplan ein Einheitenstorno durchgeführt, kann der Bearbeitungsstatus dieses Wirtschaftsplans weiterhin nicht zurückgesetzt werden; dieses Verhalten ist von der aktuellen Anpassung nicht betroffen.

Wirtschaftsplan: Nachgetragener Vertragswechsel überträgt Werte nicht

Ausgangssituation
Beim Nachtragen eines Vertragswechsels in einem bestehenden Wirtschaftsplan wurden Werte der betroffenen Einheitenhistorien nicht korrekt übernommen.

Auswirkung
Anzahl Belege, Anzahl Empfänger und Betrag pro Periode Gesamt wurden teilweise mit 0 angezeigt, wodurch fehlerhafte Wirtschaftsplandaten entstehen konnten.

Anpassung
Die Verarbeitung von Vertragswechseln wurde korrigiert, sodass die erforderlichen Daten für die neue Einheitenhistorie vollständig berücksichtigt und die Wirtschaftsplanwerte korrekt übernommen werden.

Vertragsverwaltung

Protokollzeilen der Vertragsänderungen bleiben nach dem Löschen eines Vertragskopfs stehen

Ausgangssituation
Beim Löschen bzw. Stornieren eines Einheitenvertrags oder eines Vertrags blieben die zugehörigen Protokollzeilen der Vertragsänderungen in der Datenbank stehen, anstatt mit gelöscht zu werden.

Auswirkung
Nach dem Löschen eines Vertrags oder Einheitenvertrags verblieben nicht mehr zuordenbare Protokolldaten (u. a. Vertragsnummer, Einheit, Benutzer-ID sowie alte und neue Feldwerte) in der Datenbank.

Anpassung
Die Protokollzeilen der Vertragsänderungen werden beim Löschen des zugehörigen Vertragskopfs jetzt korrekt mit gelöscht. Bereits zuvor entstandene, verwaiste Protokollzeilen wurden bereinigt.

Storno-Sollstellung nach Indexanpassung hat andere Debitorenbuchungsgruppe als Sollstellung über Sollstellung erstellen

Ausgangssituation
Bei einer Indexmietanpassung mit rückwirkender Korrektur der Sollstellungen über den Bericht Änderungen überprüfen wurde die resultierende Korrekturbuchung mit der Debitorenbuchungsgruppe des Debitorenstammsatzes gebucht, statt mit der am Mietvertrag bzw. in der RE Vertrag Einrichtung hinterlegten Debitorenbuchungsgruppe. Derselbe Fehler trat auch beim Stornieren einer Sollstellungszeile sowie beim Assistenten Sollstellung nachbuchen auf. Betroffen waren insbesondere Verträge, bei denen die Debitorenbuchungsgruppe des Debitors von der am Vertrag bzw. in der RE Vertrag Einrichtung hinterlegten Buchungsgruppe abweicht.

Auswirkung
Reguläre Sollstellungen und die zugehörigen Korrekturbuchungen (z. B. aus Indexanpassung, Storno oder Nachbuchung) trugen unterschiedliche Debitorenbuchungsgruppen. Dadurch konnte beim Postenausgleich zwischen diesen Buchungen kein direkter Ausgleich erfolgen. Ein Workaround auf Anwenderseite war nicht möglich; fehlerhaft gebuchte Beträge mussten manuell nachkorrigiert werden.

Anpassung
Bei der Korrekturbuchung aus einer Indexanpassung, beim Stornieren einer Sollstellungszeile und beim Nachbuchen einer Sollstellung wird nun durchgängig die am Mietvertrag bzw. in der RE Vertrag Einrichtung hinterlegte Debitorenbuchungsgruppe verwendet. Die Debitorenbuchungsgruppe der Korrekturbuchung stimmt dadurch mit der Debitorenbuchungsgruppe der zugehörigen regulären Sollstellung überein, sodass der Postenausgleich korrekt funktioniert.

Kreditorische Verträge

Verwaiste Zähler-Verbindung nach Löschen eines kreditorischen Vertrags

Ausgangssituation
Beim Löschen eines kreditorischen Vertrags (Versorgervertrag), dem ein Zählerstamm zugeordnet war, blieb die Verknüpfung zu diesem Zählerstamm bestehen.

Auswirkung
Der betroffene Zählerstamm konnte keinem neuen kreditorischen Vertrag zugewiesen werden, da er weiterhin mit dem bereits gelöschten Vertrag verknüpft war.

Anpassung
Beim Löschen eines kreditorischen Vertrags, an dem ein Zählerstamm hinterlegt ist, erscheint nun eine Abfrage, ob die Verknüpfung zum Zählerstamm gelöscht werden soll. Wird dies bestätigt, wird die Verknüpfung entfernt und der Vertrag gelöscht, sodass der Zählerstamm bei Bedarf einem neuen Vertrag zugewiesen werden kann.

Stammdaten

Fehlanzeige des Währungscodes am Verteilcode der Einheit

Ausgangssituation
Bei Mandanten mit gepflegtem Mandantenwährungscode wurde am Verteilcode der Einheit fälschlicherweise der Währungscode vorangestellt angezeigt, obwohl es sich um eine reine Flächen- bzw. Mengenangabe und keinen Geldbetrag handelt. Betroffen waren unter anderem die Übersicht der Einheitenstämme (Spalte Verteilfaktor) sowie die zugehörige Infobox.

Auswirkung
Anwender sahen an den betroffenen Stellen einen irreführend formatierten Wert mit vorangestelltem Währungscode anstelle eines reinen Zahlenwerts.

Anpassung
Der Fehler wurde behoben. Am Verteilcode der Einheit wird der Währungscode nicht mehr angezeigt.

Verwaltungsende am Einheitenstamm darf nicht größer sein als Verwaltungsende am Objekt

Ausgangssituation
Wurde an einer Einheit im Einheitenstamm ein Verwaltungsende eingetragen, ließ sich am zugehörigen Objekt anschließend ein früheres Verwaltungsende eintragen.

Auswirkung
Das Objekt-Verwaltungsende konnte vor dem bereits gesetzten Verwaltungsende der zugehörigen Einheit liegen, ohne dass eine Fehlermeldung erschien.

Anpassung
Das Objekt-Verwaltungsende wird nun gegen das Verwaltungsende der zugehörigen Einheiten geprüft. Liegt das Objekt-Verwaltungsende vor dem Verwaltungsende einer Einheit, erscheint eine Fehlermeldung.

Elektronische Belege

Mietrechnung im ZUGFeRD-Format hält Validierung nicht stand

Ausgangssituation
Mietrechnungen im ZUGFeRD-Format bestanden die Validierung nicht. Ursache war ein XSD-Strukturfehler in der erzeugten CII-XML: Das Element SpecifiedTradePaymentTerms stand an ungültiger Position, nach statt vor dem Element SpecifiedTradeSettlementPaymentMeans.

Auswirkung
Die für eine Mietrechnung erzeugte ZUGFeRD-Datei war nicht schema-konform und bestand externe Validierungsprüfungen nicht. Normale Verkaufsrechnungen im ZUGFeRD-Format waren von diesem Fehler nicht betroffen und validierten erfolgreich.

Anpassung
Der Aufbau der ZUGFeRD-Datei wurde schema-konform korrigiert.

Mietrechnung: Kein PDF bei Belegsendeprofil mit Datenträger “PDF”

Ausgangssituation
Bei Debitoren, deren Belegsendeprofil im Feld Datenträger auf PDF gesetzt war, wurde bei der Registrierung eines Mietrechnungsvorgangs kein PDF-Dokument erzeugt oder archiviert.

Auswirkung
Die Registrierung des Mietrechnungsvorgangs schloss ohne Fehlermeldung ab, es entstand jedoch kein Beleg im RELion-Archiv. Bei Belegsendeprofilen mit der Einstellung Elektronischer Beleg oder PDF & Elektronischer Beleg war die Dokumentausgabe davon nicht betroffen.

Anpassung
Die Erzeugung des PDF-Belegs bei der Registrierung von Mietrechnungsvorgängen berücksichtigt nun korrekt die Einstellung PDF im Belegsendeprofil. Bei entsprechender Konfiguration des Datenträgers wird das PDF-Dokument wie vorgesehen erzeugt und archiviert.

Fehlermeldung beim Öffnen von Dokumenten (z. B. ZUGFeRD-Dateien)

Ausgangssituation
Beim Öffnen von PDF-Dokumenten über den Archivdateinamen in RELion Dokumente konnte es zu einer Fehlermeldung kommen. Das Verhalten trat insbesondere beim Aufrufen von ZUGFeRD-Dateien auf, jedoch nicht bei jedem Aufruf. In einzelnen Fällen konnte beim anschließenden Zurückgehen zusätzlich ein Fehler auftreten.

Auswirkung
Betroffene PDF-Dokumente konnten nicht angezeigt werden; es erschien die Meldung „Fehler beim Versuch, den Bericht anzuzeigen.“ Ein Workaround für die betroffenen Anwender war nicht bekannt.

Anpassung
Die Verarbeitung beim Anzeigen von Dateien wurde korrigiert. Fehler beim Anzeigen von Dateien werden abgefangen; wenn möglich, wird die anzuzeigende Datei heruntergeladen.

Zusätzliche Hinweise
Das beschriebene Verhalten wurde anhand einer ZUGFeRD-Datei festgestellt. In der Fehleranalyse wurde darauf hingewiesen, dass grundsätzlich auch andere PDF-Dokumente betroffen sein könnten.

PEPPOL30-Prüfung fehlerhaft/unvollständig

Ausgangssituation
Im Belegsendeprofil wird geprüft, ob ein nicht unterstütztes elektronisches Belegformat (PEPPOL30) für den Versand hinterlegt ist. Diese Prüfung schlug bei den Feldern E-Mail Format und Disk Format auch dann an, wenn der jeweilige Versandweg gar nicht auf Elektronischer Beleg eingestellt war — etwa wenn beim Datenträger PDF ausgewählt war, im Format-Feld aber noch ein alter PEPPOL30-Wert hinterlegt war.

Auswirkung
Es erschien eine Fehlermeldung zum nicht unterstützten PEPPOL30-Format, obwohl der elektronische Beleg über den jeweiligen Versandweg in diesem Fall gar nicht verwendet wurde.

Anpassung
Die Prüfung auf nicht unterstützte elektronische Belegformate (PEPPOL30) wird nur noch ausgelöst, wenn der jeweilige Versandweg tatsächlich auf Elektronischer Beleg eingestellt ist. Beim E-Mail-Versand erfolgt die Prüfung nur noch, wenn als E-Mail-Anhang nicht PDF ausgewählt ist. Beim Datenträger-Versand erfolgt die Prüfung nur noch, wenn als Datenträger Elektronischer Beleg oder PDF und Elektronischer Beleg ausgewählt ist.

Berechtigungssätze

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

Tabelleninformationen Modell

Änderungen im Datenmodell werden in den Tabelleninformationen angezeigt.