Direkt zum Hauptinhalt

Versionshistorie

In Entwicklung

Geändertes Verhalten:

  • Text- und CSV-Ausgaben von Berichten werden jetzt immer in UTF-8 geschrieben, CSV zusätzlich mit Byte-Order-Mark für Excel. Bisher folgte der Zeichensatz dem Wirtssystem: unter Windows die ANSI-Codepage, im Linux-Container UTF-8 – derselbe Bericht ergab also je nach Betriebsart unterschiedliche Dateien. Wer eine Textausgabe unter Windows automatisiert weiterverarbeitet, muss die Leseseite auf UTF-8 umstellen

Neue Funktionen:

  • Open Banking: WinLine-Abgleich. Vorschläge, die die Buchhaltung inzwischen direkt in WinLine gebucht hat, werden erkannt und stillgelegt, statt bei der Freigabe eine zweite Zahlung zu erzeugen. Geprüft wird zweifach: Ist der zugeordnete offene Posten in WinLine bereits ausgeglichen, erhält die Transaktion den Status OP bereits ausgeglichen; existiert auf dem WinLine-Bankkonto bereits eine Buchung mit gleichem Betrag und Datum (Toleranz wie die Datums-Toleranz des Lernmodus, Standard ±5 Tage), den neuen Status In WinLine bereits gebucht mit Journalnummer, Datum und Gegenkonto als Nachweis. Jede WinLine-Buchung wird dabei nur einem Umsatz zugeordnet, sodass monatliche Abbuchungen gleicher Höhe ihren jeweils eigenen Monat behalten; konkurrieren mehrere Umsätze gleicher Höhe um zu wenige Buchungen, wird nicht geraten: sie bleiben als Vorschlag mit Prüfhinweis stehen und werden nicht automatisch gebucht. Erledigte Umsätze zählen in den Filtern „Handlungsbedarf" und „Mit Fehler" nicht mehr mit. Der Abgleich läuft automatisch vor jeder Freigabe, beim Import neuer Umsätze und beim „Neu abgleichen"; die Aktion Mit WinLine abgleichen im Transaktionsjournal stößt ihn jederzeit für die markierten oder alle offenen Transaktionen an (für die Automatisierung auch POST /banking/winline-abgleich). So erkannte Umsätze fließen zusätzlich als manuell gebuchte Vorgänge in den Lernmodus ein. Hintergrund: In einer Echtumgebung waren 195 von 216 automatisch zugeordneten Kreditkarten-Vorschlägen in WinLine längst gebucht.
  • Open Banking: Lernmodus. Lernt aus manuell in der WinLine gebuchten Transaktionen automatisch Buchungsregel-Vorschläge – auch als Nachbesserung, wenn ein Tool-Vorschlag (Regel oder KI) falsch war und die Buchhaltung stattdessen von Hand richtig gebucht hat. Aktivierung je Bankkonto im Tab „Lernmodus", Schwellwerte (Mindestanzahl, Konsistenz %, Datums-Toleranz) einstellbar. Vorschläge erscheinen unter Banking → Buchungsregel-Vorschläge und lassen sich annehmen (legt die Buchungsregel an bzw. korrigiert sie) oder ablehnen (Muster wird nicht erneut vorgeschlagen). Die Aktion „Historie analysieren" öffnet einen Dialog mit optionalem Zeitraum: leer verarbeitet alle noch ungeprüften Transaktionen des Kontos, mit Zeitraum wird auch bereits Geprüftes im gewählten Fenster erneut analysiert. Für die Automatisierung steht derselbe Aufruf auch über POST /banking/lernmodus zur Verfügung. Verrechnungskonten (Kreditkarte/PayPal) verwenden automatisch ein erweitertes Zuordnungsfenster, weil Beleg-Buchung und Kontoumsatz dort zeitlich weit auseinanderliegen; erkennt der Lauf mehrere Muster derselben Gegenpartei mit unterschiedlichen Zielkonten (z.B. Finanzamt: USt und LSt), warnt die Begründung des Vorschlags. Ist die KI-Rechnungserkennung des Kontos aktiviert, verfeinert die KI Bezeichnung und Verwendungszweck-Filter der Vorschläge; ohne KI oder bei Fehlern bleiben die automatisch abgeleiteten Texte. Siehe Lernmodus
  • Open Banking: Sammelzahlung über eine Teilmenge der offenen Posten. Überweist ein Geschäftspartner ohne Rechnungsnummern im Verwendungszweck, erkannte die Zuordnung über den Zahlernamen bisher nur den Fall, dass alle seine offenen Posten zusammen den Zahlbetrag ergeben. Bezahlte er nur einen Teil (Praxisfall: 10.703,41 € für zwei von vier offenen Rechnungen, zwei kleine blieben offen), gab es keinen Vorschlag, obwohl die Kombination eindeutig war. Jetzt wird bei nicht passender Gesamtsumme die Kombination gesucht, deren Restbeträge den Betrag ergeben – bis 16 offene Posten je Partner, Gutschriften eingeschlossen. Nur eine eindeutige Kombination wird übernommen; gibt es mehrere passende, bleibt es beim bisherigen Verhalten (Personenkonto erkannt, manuelle Zuordnung). Das Verarbeitungsprotokoll nennt in diesem Fall „eindeutige Teilmenge der offenen Posten". Gilt für Zahlungseingänge (Debitor, Zahlername) und Ausgänge (Kreditor, Empfängername)
  • Open Banking: Aktion „OP zuordnen". Im Transaktionsjournal zeigt die neue Aktion OP zuordnen die in Frage kommenden offenen Posten als Auswahlliste – mit Kontonummer, Name, Belegnummer, OP-Buchungsnummer und Restbetrag. Bisher mussten Kontonummer und OP-Buchungsnummer für eine manuelle Zuordnung als Freitext eingetippt und dafür vorher in der WinLine nachgeschlagen werden; die Auswahl legt die manuelle Zuordnung jetzt direkt an. Die Vorschläge stammen – in dieser Reihenfolge – aus den bei mehrdeutiger Bankverbindung ermittelten Kandidatenkonten, aus dem bereits erkannten Personenkonto oder aus einer Namenssuche über den Auftraggeber der Transaktion. Findet sich kein passender offener Posten, sagt die Meldung das und der bisherige Freitext-Weg bleibt erhalten. Die Aktion steht überall dort zur Verfügung, wo auch „Manuell buchen" möglich ist. Siehe Open Banking
  • Berichtswesen: PowerReport-Abfragen kennen zwei neue, optionale Angaben, die es in der WinLine-Oberfläche genauso gibt: die Kennung (Spalte „ID", z.B. LIST_40126) und den Benutzernamen. Die Kennung unterscheidet Datenquellen, die sich sonst nicht auseinanderhalten lassen — dieselbe Auswertung als Snapshot und als View —, und sie kann den Datenquellennamen auch ersetzen
  • Berichtswesen: PowerReport-Abfragen lassen sich per „Datenquelle wählen" aus den in WinLine vorhandenen Datenquellen übernehmen — Name, Application, Mandant, Benutzer, Filter und Selektionen werden zusammen gesetzt. Die Application ist damit keine Pflichtangabe mehr: bleibt sie leer, wird sie beim Lauf aus der Systemtabelle ermittelt. Das ist die Konsequenz aus derselben Beobachtung wie bei der Fehlermeldung unten — sie ist in der WinLine-Datenquellenverwaltung schlicht nirgends ablesbar. Bestehende Abfragen mit ausgefüllter Application bleiben unverändert gültig
  • Berichtswesen: Eigene SQL-Abfragen werden beim Speichern auf zwei Konstrukte geprüft, die in der Berichtsabfrage nicht funktionieren: ein allgemeiner Tabellenausdruck (WITH …) und ein ORDER BY auf oberster Ebene. Beides ist unzulässig, weil die Abfrage intern als abgeleitete Tabelle eingebettet wird. Bisher liess sich eine solche Abfrage speichern und fiel erst beim Öffnen des Report-Designers mit einer SQL-Syntaxmeldung auf, die die Ursache nicht nannte — jetzt nennt der Validierungshinweis das Problem und den Ausweg (abgeleitete Tabelle statt WITH, Sortierung über die Gruppierung des Berichtslayouts). Innerhalb von OVER(…) bleibt ORDER BY erlaubt, ebenso mit TOP oder OFFSET
  • Berichtswesen: Spalten lassen sich direkt im Feld „Spalten" tippen – während der Eingabe erscheinen Vorschläge aus dem Entitätstyp mit technischem Pfad und Anzeigename; die Auswahl einer Verweiseigenschaft (›) führt in die nächste Ebene; Sonderpfade bleiben möglich und werden dezent gekennzeichnet
  • Berichtswesen: Spalten einer MesoXPO-Datenquelle lassen sich per „Spalten wählen" aus einem Baum auswählen statt Pfade zu tippen; bestehende Sonderpfade bleiben erhalten.
  • Berichtswesen: Eine Sammlung wird per „Als Detailabfrage anlegen" zur Detailabfrage samt Master-Detail-Beziehung; Spaltenpaare und Vorfilter werden aus der Sammlung hergeleitet, vor dem Anlegen bestätigt und die beteiligten Spalten automatisch in beide Abfragen übernommen. Die hergeleiteten Masterspalten erscheinen im offenen Spaltenbaum angekreuzt und überleben auch das anschließende „Übernehmen".
  • Berichtswesen: Die Feldliste des Report-Designers zeigt Detailtabellen jetzt unter ihrer Mastertabelle — „Detailbereich einfügen" bietet die Beziehung direkt an.
  • Berichtswesen: Beziehungen und Spaltenlisten werden beim Speichern gegeneinander geprüft: Verweist ein Spaltenpaar auf eine Spalte, die in der Abfrage nicht (mehr) geladen wird, meldet das Speichern den Fehler — Details stehen an der Beziehung im Feld „Validierungshinweis". Und falls doch eine fehlerhafte Beziehung gespeichert ist, bleibt die Feldliste des Report-Designers jetzt nutzbar: die betroffene Beziehung wird übersprungen und im Protokoll vermerkt, statt die Feldliste komplett zu leeren.
  • Berichtswesen: Detailbereiche, die im Designer von Hand eingefügt wurden und nur Felder einer Master-Detail-Beziehung zeigen, werden beim Öffnen und Rendern automatisch an diese Beziehung gebunden — bisher wiederholte ein solcher ungebundener Detailbereich sämtliche Detailzeilen unter jedem Kopfdatensatz (z.B. alle Preise unter jedem Artikel).
  • Berichtswesen: Die interne Berichts-Kennung (versteckter Parameter „MesoReportOid") wird beim Öffnen automatisch wiederhergestellt, falls sie aus dem Layout entfernt wurde — bisher blieb die Vorschau dann kommentarlos leer, weil der Bericht beim Rendern nicht mehr zugeordnet werden konnte. Fehler beim Datenaufbau der Vorschau stehen jetzt zusätzlich im Protokoll.
  • Berichtswesen: Spalten auf optionalen Feldern (z.B. Datums- und Mengenfelder der Preisliste) funktionieren jetzt in Feldliste und Ausführung — bisher ließ ein einziges solches Feld die Feldliste des Designers komplett leer bleiben.
  • Berichtswesen: Spalten auf Kennzeichen-Feldern mit eigenem Wertetyp (z.B. Varianten-Kennzeichen des Artikels) lassen die Feldliste nicht mehr leer bleiben. Solche Felder erscheinen im Bericht jetzt mit ihrer Beschreibung statt als Zahl, z.B. „Hauptartikel mit Ausprägung" statt 1.
  • Berichtswesen: Der Report-Designer meldet beim Öffnen sichtbar, wenn die Feldliste unvollständig sein wird — etwa weil eine Beziehung auf Spalten verweist, die in den Abfragen fehlen, oder der Schema-Aufbau scheitert. Bisher stand die Ursache nur im Serverprotokoll.
  • Berichtswesen (MESO-WSREPORT): Eigene Berichte im Report-Designer auf Basis von MesoXPO-Entitäten, freien SQL-Abfragen sowie WinLine-PowerReport- und LIST-Definitionen. Master-Detail-Berichte über verknüpfte Abfragen, Ausführung für einen oder mehrere Mandanten, Wirtschaftsjahr wählbar (aktuell, fest, jahresübergreifend) und MESOSAFE-Filterung im Kontext eines WinLine-Benutzers. Export als PDF, Excel, Word, RTF, CSV, Text, HTML, MHT, XPS und Bild. Ohne WinLine-Benutzerkontext greift keine MESOSAFE-Filterung – das erfordert die eigene Berechtigung „Report ohne Benutzerkontext ausführen"
  • Berichtsaufträge: Berichte laufen zeitgesteuert für ausgewählte Mandanten und WinLine-Benutzer und werden in eine Dateiablage geschrieben, mit Journal je Einzelausgabe. Am Auftrag gesetzte Parameter haben Vorrang vor den Standard-Platzhaltern und wirken im Bericht, in den Abfragen und im Dateinamen. Läuft ein Auftrag für mehrere Benutzer, muss der Benutzer im Dateinamensmuster vorkommen. Ausgaben ohne auflösbaren Benutzerkontext werden nicht ausgeführt, sondern als fehlgeschlagen protokolliert; ein Lauf ganz ohne Ausgabe nennt seinen Grund
  • Berichtswesen: Dashboards versenden. Ein Berichtsauftrag kann statt eines Berichts jetzt auch ein XAF-Dashboard ausführen – Zeitplan, Mandanten, Ausgabeziele und Journal sind identisch zu Berichten. Unterstützt werden die Formate PDF, Excel (XLSX) und Bild (fest 1920×1080). SQL-Datenquellen im Dashboard kennen dieselben Platzhalter wie Berichts-Abfragen ({{Mandant}}, {{Wirtschaftsjahr}}, …) und laufen automatisch gegen die WinLine-Datenbank des jeweiligen Mandanten; Objekt-Datenquellen zeigen die Daten der WorkerService-Datenbank wie im Dashboard-Viewer der Weboberfläche. In dieser ersten Ausbaustufe ohne Benutzerkontext (MESOSAFE) und ohne Wirkung von „Auch bei leerem Ergebnis ausgeben" – siehe Dashboards versenden
  • Berichtswesen: Dashboard-Vorschau in der Oberfläche. Dashboards mit SQL-Datenquellen lassen sich jetzt auch im Blazor-Dashboard-Viewer/-Designer und im Windows-Client ansehen, ohne den DevExpress-Verbindungsdialog zu sehen – die Verbindung wird über einen konfigurierten Vorschau-Mandanten (Dashboard:VorschauMandant) aufgelöst, dieselbe Konvention wie beim Dashboard-Versand. Ohne konfigurierten Mandanten erscheint eine sprechende Fehlermeldung statt des Dialogs; der WinForms-Designer bleibt davon unberührt. Siehe Dashboards versenden
  • Personenkonto- und Kontakt-Quellen für Belegzeilen-Workflows: Neue Einstellungen steuern, aus welchen Beleg-Feldern Kundenkonto, Kontakt, Händlerkonto und Kontakt Händler des erzeugten CRM-Falls befüllt werden – wählbar sind Rechnungsadresse, Lieferadresse und (bei Konten) Zusatzadresse, jeweils optional mit Rückfall auf die Rechnungsadresse. Händlerkonto und Kontakt Händler sind standardmäßig deaktiviert („Nicht schreiben"); Kundenkonto und Kontakt verhalten sich standardmäßig wie bisher
  • Laufsperre für den Mehrinstanzbetrieb: Der WorkerService darf jetzt mehrfach gegen dieselbe Datenbank laufen. Eine Anwendungssperre stellt sicher, dass jeder Job je Fälligkeit nur auf einer Instanz läuft; die übrigen Instanzen überspringen den Lauf und protokollieren das. Der aktuelle Zustand ist unter GET /health/detailed im Abschnitt JobRunLocks sichtbar, abschaltbar über "JobRunLock": { "Enabled": false }. Siehe Mehrere Instanzen
  • Berichtsversand per E-Mail: Ein Ausgabeziel kann den Bericht als Anhang versenden – an feste Adressen und an die Adresse des WinLine-Benutzers, in dessen Kontext der Bericht gelaufen ist. Betreff und Text unterstützen Platzhalter
  • Berichte als CRM-Workflow-Fall: Ein Ausgabeziel legt einen Fall an und hängt den Bericht als Archivdokument daran. Welche Felder des Falls belegt werden, ist frei konfigurierbar
  • Platzhalter mit Format, Präfix und Suffix: {{Heute:yyyy-MM}} oder {{Mandant|prefix=[|suffix=]}} – wirkt auch auf Zielverzeichnis und Dateiname sowie auf die Felder von E-Mail- und CRM-Workflow-Zielen
  • Fall-Id in Folgezielen: Ein Ziel, das nach einem CRM-Workflow-Ziel läuft, kann den angelegten Fall über {{FallId}} benennen
  • Berichtswesen: Vorschau an der Datenquelle. Die neue Aktion Vorschau an der Berichts-Datenquelle führt sie probeweise aus – über denselben Weg wie der echte Bericht – und zeigt je Abfrage die Zeilenzahl, die vollständige Spaltenliste mit Typ und die ersten 20 Zeilen als Beispieltabelle. Je Beziehung nennt sie die Trefferquote („2 von 3 Zeilen aus OffenePosten haben Kindzeilen in Teilzahlungen“), bei 0 Treffern zusätzlich den Hinweis, dass die Verknüpfung nicht greift – ein falscher Schlüssel fällt damit auf, bevor jemand ein Layout baut. Scheitert der Probelauf, steht die Meldung der Datenbank im Klartext im Dialog statt nur im Serverprotokoll. Mandant, WinLine-Benutzer und Wirtschaftsjahr sind wählbar; gespeichert wird nichts
  • Berichtswesen: LIST-Auswertungen decken mehr Listen ab. Der SQL-Generator für WinLine-LIST-Definitionen deckt jetzt 96 von 118 Demo-Listen ab – durch einen Fallbezug je Listenart (die passende Grundbedingung je nach Struktursatz-Fall), zehn neu unterstützte Listenarten und einen Datums-Anker für relative Zeitfilter
  • Berichtswesen: Filter je LIST-Abfrage wählbar. Die Aktion „Filter wählen" an einer WinLine-LIST-Abfrage zeigt die zur Listenart passenden WinLine-Filter und übernimmt den gewählten Namen als Überschreibung; ohne Auswahl bleibt der im Listenkopf hinterlegte Filter der Standard. Enthält der verwendete Filter – Kopf-Filter oder Überschreibung – Abfrage-Zeilen (z.B. „Kontonummer?"), die ein Berichtslauf nicht interaktiv beantworten kann, meldet der Lauf das jetzt laut statt die Liste stillschweigend ungefiltert oder gar nicht zu erzeugen. Auch die Liste selbst muss nicht mehr eingetippt werden: „Liste wählen" zeigt das WinLine-Listenverzeichnis mit Gruppen, mesonic-Vorlagen und einem Kennzeichen, ob der SQL-Generator die jeweilige Listenart unterstützt
    • Hinweis: Bestehende LIST-Berichte, deren WinLine-Filter negierte Bedingungen oder absteigende Sortierungen enthalten, liefern nach diesem Update die korrekte — also eine andere — Ergebnismenge bzw. Reihenfolge (Fehlerbehebung im Filter-Übersetzer des Pakets MesoXPO.Business 4.79).

Verbesserungen:

  • Dokumentation vervollständigt: Die README beschreibt jetzt alle sieben Module in der Lizenzübersicht (Berichtswesen fehlte), alle acht Jobs in der Stack-Vorlage, die HTTP-Endpunkte samt API-Schlüssel und den Umstand, dass Endpunkte ohne konfigurierten Schlüssel ungeschützt sind, die Fehlerberichterstattung an den Hersteller (Sentry) und deren Abschaltung, sowie die bisher fehlenden Einstellungen der Bankkonto-Reiter Matching, FIBU-Buchung, Vorauszahlung und KI. Drei falsch benannte Felder im Banking-Abschnitt wurden korrigiert
  • Open Banking: Gemeinsame Bankverbindung von Kunde und Lieferant wird jetzt aufgelöst. Ist dieselbe IBAN sowohl an einem Debitor als auch an einem Kreditor hinterlegt – der Fall des debitorischen Kreditors, also eines Geschäftspartners, von dem man kauft und an den man verkauft –, entschied sich die IBAN-Erkennung bisher stillschweigend für eines der beiden Konten. Jetzt werden alle Konten zu dieser Bankverbindung gesucht und gegen die offenen Posten geprüft: Passt der Betrag der Transaktion zu genau einem der Kandidaten, ist die Zuordnung eindeutig und wird als Vorschlag übernommen (Zuordnungsmethode „IBAN-Match+OP-Disambiguierung"). Bleibt es mehrdeutig, wird nichts mehr geraten – die Transaktion nennt die in Frage kommenden Konten im Feld Mehrdeutige Konten neben der Fehlermeldung und wartet auf die manuelle Zuordnung, die sich über die neue Aktion „OP zuordnen" erledigen lässt
  • Open Banking: Das Transaktions-Journal zeigt im Tab „Technische Details" jetzt den Zeitpunkt „Lernmodus geprüft" – so ist nachvollziehbar, ob und wann der Lernmodus eine Transaktion bereits gegen das WinLine-Buchungsjournal geprüft hat

Fehlerbehebungen:

  • 🐛 Open Banking: keine zweite Zahlung auf eine bereits bezahlte Rechnung. Wurde ein Personenkonto über die IBAN oder den Namen erkannt und fand die Betrags-/Datumssuche auf diesem Konto nur einen bereits ausgeglichenen offenen Posten mit passendem Betrag, wurde dieser trotzdem als Zahlungsziel vorgeschlagen – bei Freigabe entstand eine zweite Zahlung auf die längst bezahlte Rechnung (typisch bei Kreditkarten-Feeds: gleicher Händler, gleicher Betrag). Solche Treffer erhalten jetzt den Status OP bereits ausgeglichen mit Konto und Belegnummer als Hinweis und werden nicht gebucht; bei mehrdeutiger IBAN (Kunde und Lieferant mit derselben Bankverbindung) zählt ein bezahlter Posten nicht mehr als Treffer.
  • Open Banking: Buchungstext-Vorlagen für Vorauszahlung und Sammelzahlungen wirken jetzt: Die Felder „Buchungstext Vorauszahlung", „Buchungstext Sammel (Debitor)" und „Buchungstext Sammel (Kreditor)" sowie „Vorauszahlung Buchungsart" waren pflegbar, wurden beim Buchen aber ignoriert – alle Buchungen erhielten den allgemeinen FIBU-Buchungstext und die Debitor-Buchungsart. Jetzt gilt je Fall die passende Vorlage (Konto → Banking:Default… in der appsettings.json → allgemeine Vorlage). Achtung: Die appsettings-Standardwerte VZ {{PayerName}} {{Buchungsdatum}}, DZ {{PayerName}} Sammel und KZ {{PayeeName}} Sammel greifen damit ab sofort; wer die bisherigen Texte behalten will, leert diese Werte
  • Open Banking: zwei Felder waren in der Detailansicht des Bankkontos unsichtbar: „Buchungstext Kreditor" (Reiter FIBU-Buchung) und „Ausgeglichene-OP-Toleranz (Tage)" (Reiter Kostenbuchungen) fehlten im Layout und ließen sich nur über den Rückfallwert steuern. Ein Test sichert jetzt, dass jedes Feld der Bankkonto-Reiter im Layout platziert ist
  • Open Banking: KI-Protokoll neuer Konten und Mandanten steht auf „Global": Bisher stand es auf „Anthropic" und übersteuerte damit still ein global in der appsettings.json konfiguriertes OpenAI-kompatibles Protokoll. Bestehende Konten und Mandanten behalten ihren Wert; wer die globale Konfiguration nutzt, prüft dort einmal auf „Global"
  • OP-Versand: „Anhänge im Journal speichern" wirkt jetzt: Die Einstellung war pflegbar, das OP-Versand-Journal hatte aber keine Anhänge. Jetzt werden OP-Blatt und Originalrechnungen der versendeten Mail am Journaleintrag abgelegt (neuer Reiter „Anhänge")
  • Mail-Dienst: leeres Feld „Filter Beleg Archivformularnummern" filterte alle Belegdokumente weg: Ein leerer Text galt als gesetzter Filter, der auf keine Formularnummer passte – Beleg-Anhänge fehlten, obwohl „leer" alle Belegdokumente bedeuten soll. Leer, Leerzeichen und überzählige Kommas gelten jetzt als „kein Filter", Nummern werden getrimmt, Semikolon wird als Trenner akzeptiert
  • Protokolle konnten den Datenträger volllaufen lassen: Die Protokolldateien des Workers hatten keine wirksame Größenbegrenzung (bis zu 31 Tage mit je bis zu 1 GB), und die Stack-Vorlage enthielt keine Rotation für das Docker-Log – bei einem Kunden ist dadurch ein Volume vollgelaufen. Jetzt gilt: höchstens 14 Dateien mit je 50 MB, die Stack-Vorlage begrenzt das Docker-Log je Container auf 30 MB. Im Container schreibt der Worker seine Dateien jetzt in das Volume /app/logs; zuvor zeigte der Pfad auf Logs (Großschreibung) und lief unter Linux am Volume vorbei. Health-Check-Aufrufe werden nicht mehr als Information protokolliert. Bestehende Stacks: logging:-Block ergänzen, siehe Protokollierung
  • Open Banking: Gutschrift-Auszahlungen an Kunden wurden als Sachkonto-Buchung erkannt. Zahlt man einem Kunden eine Gutschrift aus, ist das eine Ausgangszahlung an einen Debitor. Die Buchungsart richtete sich bisher nach der Zahlungsrichtung statt nach dem tatsächlich erkannten Konto: Für den per IBAN erkannten Debitor entstand im Ausgang eine Kostenbuchung auf ein Sachkonto („B") ohne OP-Bezug – der offene Posten des Kunden blieb offen, und der Betrag landete auf einem Aufwandskonto. Jetzt bestimmt das Kennzeichen des erkannten Personenkontos die Buchungsart (Debitor → „DZ", Kreditor → „KZ"), und der Buchungsstapel erzeugt den OP-Ausgleich auch für Debitor-Buchungen im Ausgang
  • Open Banking: „Noch nicht zugeordneter Restbetrag" war bei Ausgangszahlungen falsch. Weil der Transaktionsbetrag im Ausgang negativ ist, wuchs der angezeigte Restbetrag mit jeder manuellen Zuordnung, statt zu sinken. Die Anzeige rechnet jetzt richtungsunabhängig
  • Open Banking: Einstellungen in den Konto-Tabs gingen bei bestehenden Konten beim Speichern verloren. Bei Banking-Konten, die vor der jeweiligen Programmversion angelegt wurden, wurden Änderungen in den ausgelagerten Einstellungs-Tabs (z.B. Lernmodus „Aktiviert", Matching-Schwellwerte) kommentarlos nicht gespeichert – nach dem erneuten Öffnen stand wieder der alte Wert. Neu angelegte Konten waren nicht betroffen. Jetzt werden die Einstellungen auch an Bestandskonten zuverlässig gespeichert
  • Open Banking: Automatische Regelerzeugung legte Dubletten an. Wurden in einem Banking-Lauf mehrere gleichartige Transaktionen derselben Gegenpartei per KI oder Namens-Matching zugeordnet (typisch: viele Kreditkarten-Umsätze desselben Anbieters), entstand für jede davon eine eigene, identische Buchungsregel – die Duplikat-Prüfung sah die im selben Lauf gerade angelegten Regeln nicht. Jetzt entsteht je Gegenpartei höchstens eine Regel pro Lauf
  • Open Banking: Leere Tabs im Banking-Konto. In den Einstellungen eines Banking-Kontos blieben die Tabs „FIBU-Buchung", „Zahlungseingänge" und „KI-Unterstützung" komplett leer, „Kostenbuchungen" zeigte nur einen Teil der Felder – die Einstellungen existierten weiter und blieben wirksam, waren aber in der Oberfläche nicht mehr erreichbar. Alle Felder sind jetzt wieder sichtbar und bearbeitbar
  • Open Banking: Lernmodus fand Buchungen aus früheren Wirtschaftsjahren nicht. Die Suche nach manuellen WinLine-Buchungen war auf das aktuelle Wirtschaftsjahr begrenzt – ältere, noch ungeprüfte Transaktionen (z.B. aus dem Vorjahr) konnten dadurch nie gepaart werden und galten nach 90 Tagen trotzdem als geprüft. Die Suche umfasst jetzt alle Wirtschaftsjahre, die der Analysezeitraum berührt
  • Open Banking: Nach fehlgeschlagenem Annehmen zeigte der Vorschlag fälschlich „Angenommen". Schlug das Speichern beim Annehmen eines Buchungsregel-Vorschlags fehl (z.B. Validierungsfehler an der erzeugten Regel), zeigte die Ansicht den Status „Angenommen", obwohl nichts gespeichert war – jedes weitere Speichern scheiterte erneut, bis die Änderungen manuell verworfen wurden. Jetzt werden die Änderungen bei einem Fehler automatisch zurückgenommen und eine Meldung nennt die Ursache
  • Dashboards in der Weboberfläche: Elemente blieben leer – „Ist ein Fehler aufgetreten beim Versuch, Daten zu laden". Betroffen war jedes Dashboard mit mehr als einer SQL-Abfrage; welche Elemente ausfielen, wechselte von Aufruf zu Aufruf, und der Versand derselben Dashboards durch den Dienst war nie betroffen. Ursache: die Platzhalter ({{Mandant}}, {{Heute}}, {{Wirtschaftsjahr}} …) wurden an einer Stelle gebunden, die je SQL-Text nur einmal durchlaufen wird. Ein Dashboard lädt seine Elemente aber in parallelen Anfragen, von denen jede alle Abfragen der Datenquelle ausführt – die übrigen gingen mit unersetzten Platzhaltern an den SQL Server („Incorrect syntax near '{'"). Die Bindung geschieht jetzt unmittelbar vor jeder Ausführung. Das gespeicherte Dashboard bleibt dabei unverändert, die Platzhalter überstehen also auch ein Speichern aus dem Entwurfsmodus
  • Berichtswesen: Eine CRM-Aktion ohne eigene Fall-Id wird nicht mehr als Fehlschlag gemeldet. WinLine legt zu manchen Workflows eine Aktion an, die nur eine Schrittnummer trägt und keine Fall-Nummer. Das Workflow-Ziel wies das ab, obwohl der Fall in WinLine entstanden war — im Journal stand „Die Fallanlage ist fehlgeschlagen" ohne Begründung, Fall-Id und Schrittnummer blieben leer. Wer daraufhin erneut auslöste, legte die Aktion ein zweites Mal an. Jetzt gilt sie als Erfolg, die Schrittnummer steht im Journal, und der Text nennt sie ausdrücklich als „CRM-Aktion … ohne eigene Fall-Id". Der alte Ersatzwert ohne beide Nummern bleibt ein Fehlschlag, und eine Fall-Id 0 wird nach wie vor nicht an ein nachfolgendes Mail-Ziel weitergegeben
  • Berichtswesen: Schlägt eine WinLine-Datenquelle fehl, nennt die Meldung jetzt die tatsächlich hinterlegten Applications. Bisher stand dort nur der erfolglos angefragte Wert, obwohl der vorhandene bekannt war. Hintergrund: die Application steht in info.application der Datenquelle und stimmt regelmäßig nicht mit dem Präfix des Tabellennamens überein — eine Datenquelle in LIST_40126 kann die Application INFO tragen
  • Berichtswesen: Manuelle Änderungen an der Datenbindung eines Detailbereichs bleiben beim Speichern im Report-Designer jetzt erhalten. Bisher entfernte das Speichern alle Bindungen aus dem Layout; beim nächsten Öffnen wurden sie neu hergeleitet, wodurch eine abweichende manuelle Einstellung verloren ging – in der Vorschau vor dem Speichern war davon nichts zu sehen. Ebenso bleibt eine bewusst gewählte Hauptabfrage des Berichts erhalten, statt beim Öffnen auf die erste Abfrage der Datenquelle zurückzufallen
  • Berichte ausführen: Mandant war nicht auswählbar. Im Dialog „Bericht ausführen" blieb die Mandantenliste leer („Keine Daten zum Anzeigen"). Aufgefallen ist es kaum, weil der Vorschau-Mandant des Berichts vorbelegt war – wer für einen Lauf aber einen anderen Mandanten wählen wollte, kam nicht weiter. Die Liste ist jetzt gefüllt
  • Report-Designer: Feldliste blieb bei freien SQL-Abfragen leer (Meldungen „Value cannot be null. (Parameter 'company')" und „Incorrect syntax near '{'"): Zwei Ursachen im selben Weg. Erstens bezog der Schema-Aufbau der Feldliste seinen Mandanten aus dem WinLine-BI-Selektor der Abfrage – ein Feld, das eine freie SQL-Abfrage gar nicht hat; er verwendet jetzt den Vorschau-Mandanten des Berichts, also denselben, mit dem auch die Schnellvorschau rendert. Zweitens blieben die Platzhalter ({{Mandant}}, {{Heute}}, {{Wirtschaftsjahr}} …) beim Ermitteln der Feldliste ungebunden im SQL stehen, was der SQL Server als Syntaxfehler abwies – sie werden jetzt auch hier als Parameter gebunden. Ist am Bericht kein Vorschau-Mandant gesetzt, sagt die Meldung das jetzt auch so
  • KI-Dokumentenerkennung: Umlaute im BelegPro-Rucksack kamen in der WinLine-Belegmaske als Ersatzzeichen an: Der Rucksack (T096) wird jetzt in der von der WinLine erwarteten UTF-8-Bytekodierung geschrieben – KI-erkannte Buchungstexte mit Umlauten oder Sonderzeichen erscheinen wieder korrekt
  • Workflow-Eigenschaften waren in der Weboberfläche nicht bearbeitbar: Das Auswahlfeld an den Mail-Workflow-Einstellungen zeigte verknüpfte Workflow-Eigenschaften nicht an und speicherte Änderungen nicht. Es zeigt jetzt die verknüpften Eigenschaften und übernimmt Hinzufügen wie Entfernen zuverlässig
  • Mail-Dienst: Rechnungs- und Belegmails mit einem leeren PDF-Anhang galten als erfolgreich versendet. Schlägt die Umwandlung eines Belegs in PDF fehl (z.B. weil der Konvertierungsdienst kurzzeitig eine leere Antwort liefert), lieferte der Anhang 0 Bytes statt des Belegs – im Mail-Journal stand trotzdem „Versendet" ohne Fehlermeldung. Ein solcher Anhang wird jetzt erkannt: die Mail wird nicht verschickt, im Journal erscheint eine Fehlermeldung mit dem betroffenen Dateinamen
  • Berichtswesen: Der LIST-Auswertungsweg „SQL aus der Listendefinition erzeugen" lieferte bisher nie Daten – das zugrunde liegende WinLine-Feld ist in der Praxis immer leer. Er erzeugt das SQL jetzt selbst aus der Listendefinition und braucht dafür keine vorbereitete WinLine-BI-Datenquelle mehr. Spalten, die sich nicht abbilden lassen, werden übersprungen und mit Namen im Protokoll vermerkt statt die Liste ganz zu verweigern. Trägt der Berichtslauf einen WinLine-Benutzer, greifen dessen CRM-Leserechte der Liste (T174); ohne Benutzerkontext liefert die Liste ungefiltert – wie bei den übrigen Auswertungswegen ohne Benutzerkontext

Version 2.8.0 (August 2026)

Neue Funktionen:

  • Ursachen in der Warnmail des Überwachungsdienstes: Die Warnmail nennt je Vorgang die Ursache und die empfohlene Maßnahme, gegliedert in Handlungsbedarf, Versand fehlgeschlagen und bewusst übersprungen. Zusätzlich Betreff, Kundenkonto und -name, Ansprechpartner mit Mailadresse, Kundenmailadresse, Ersteller, verknüpfter Beleg und zuständige Mail-Einstellung
  • Übersprungene Mails (neues Journal): Der Mail-Dienst hält fest, warum für einen Vorgang keine E-Mail erzeugt wurde. Einsehbar unter Mail-Dienst → Übersprungene Mails
  • Informationsmail ohne Handlungsbedarf: Neue Einstellung je Mandant. Standard aus – liegen nur bewusst übersprungene Vorgänge vor, kommt keine Mail mehr
  • Vorschau des Überwachungsberichts: Neue Aktion auf der Überwachungseinstellung. Zeigt für einen frei wählbaren Rückblick-Zeitraum, was der nächste Lauf melden würde – ohne Versand und ohne Speicherung. Der Duplikatsschutz ist dabei abgeschaltet, damit auch bereits gemeldete Vorgänge sichtbar bleiben. Läuft in der Web-Verwaltung und im Windows-Client, ein gestarteter WorkerService ist nicht erforderlich
  • Web-UI als Windows-Dienst: Die Web-Oberfläche lässt sich jetzt als eigener Windows-Dienst betreiben, unabhängig vom Hintergrunddienst. Bisher startete sie nur aus der Konsole – als Dienst brach Windows den Start nach 30 Sekunden mit Fehler 1053 ab. Startmeldungen und Startfehler gehen ins Windows-Ereignisprotokoll (Quelle MESO-WorkerService-WebUI). Siehe Web-UI als Windows-Dienst

Verbesserungen:

  • Uhrzeit in Journal- und Protokollansichten: Alle Zeitstempel-Spalten der Journale zeigen jetzt Datum und Uhrzeit (z.B. Postausgang „Angelegt am", Übersprungene Mails „Erstmals/Letztmals am", Warnungsjournal, Bestellzeilen-Workflow-Journal sowie „Gelöscht am" und „Fall zuletzt geändert" im Termin-Journal)
  • Belegzeilen-Workflows: Belegverknüpfung früher verfügbar: Die Verknüpfung des erzeugten Falls zum Beleg (Objekt-Workflow, T185) wird jetzt unmittelbar nach der Fallanlage geschrieben – vorher erst nach Mutter-Fall-Verknüpfung, benutzerdefinierten Feldern und Anhängen. WinLine-seitige Auswertungen sehen die Belegverknüpfung damit früher

Fehlerbehebungen:

  • Folgeschritte wurden nie gemeldet: Der Überwachungsdienst prüfte nur die Fall-ID. Sobald für einen Fall eine Mail versendet war, blieb jeder Folgeschritt mit eigener Workflow-Nummer unbeachtet
  • Fehlgeschlagener Versand galt als Erfolg: Ein Journaleintrag mit gefüllter Fehlermeldung unterdrückte die Warnung
  • Bewusst gefilterte Vorgänge wurden als Fehler gemeldet: Der Überwachungsdienst wendete Filterkriterium, Workflow-Eigenschaften, Abholdatum und Workflow-Status nicht an. Diese Bedingungen kommen nun aus derselben Quelle wie im Versandpfad
  • Gelöschte Journaleinträge unterdrückten Warnungen: Die Prüfung berücksichtigt jetzt GCRecord
  • Sonderzeichen in Filterkriterien zerlegten die Warnmail: Alle Werte werden HTML-escaped

Paketaktualisierungen:

  • DevExpress: 25.2.5 → 26.1.3 (alle Komponenten). DevExpress wird jetzt von nuget.org bezogen; der Lizenzschlüssel muss dafür registriert sein (in Container- und CI-Builds über die Umgebungsvariable DevExpress_License)
  • Kennwörter: DevExpress 26.1 hasht Kennwörter standardmäßig mit SHA512 (600.000 Iterationen) statt bisher SHA1 (20.000). Bestehende Kennwörter bleiben gültig – beide Verfahren sind aktiv, neu gesetzte Kennwörter verwenden das stärkere. Ohne diese Umstellung könnte sich in einer bestehenden Installation niemand mehr anmelden
  • MesoXPO-DevEx26.1 / MesoXPO.Business-DevEx26.1: Wechsel vom 25.2- auf den 26.1-Paketzweig
  • eMail: 2026.2.17.95 → 2026.7.31.109
  • Microsoft.Data.SqlClient: → 7.0.2, Microsoft.Identity.Client: → 4.87.0
  • Sicherheitsupdate: Microsoft.Graph.Core 3.2.5 → 3.2.6 und damit die Kiota-Bibliotheken 1.21.1 → 1.22.1. Behebt CVE-2026-44503 (hoher Schweregrad): Bei einer Weiterleitung auf einen anderen Host gab die Bibliothek Cookies, Proxy-Zugangsdaten und eigene Header an das Weiterleitungsziel weiter

Version 2.7.4 (Juli 2026)

Neue Funktionen:

  • Neues Modul: NextCloud-Kalendersynchronisation (MESO-WSNEXTCLOUD): Bidirektionale Kalender-Synchronisation zwischen Microsoft 365 und NextCloud
    • Bidirektionaler Terminabgleich M365 ↔ NextCloud mit Last-Write-Wins-Konfliktauflösung
    • Flexible Sync-Paare: pro Pair ein M365-Kalender und ein NextCloud-Kalender
    • Konfigurierbare Zeitfenster (Standard: 30 Tage rückwirkend / 365 Tage voraus)
    • Serientermine: tägliche und wöchentliche Wiederholungen (RRULE) werden als echte Serie übertragen (v1); komplexere Muster (monatlich/jährlich/etc.) werden übersprungen und mit einem Journal-Fehler protokolliert (nie als degradierter Einzeltermin übertragen)
    • Terminfeld-Mapping: Betreff, Beschreibung, Start-/Enddatum, Ganztags-Status, Erinnerung (VALARM); Teams-/Talk-Links als Text in Ort/Beschreibung
    • Feld-Mapping v1 begrenzt: KEINE Teilnehmer/Einladungen, KEINE Anhänge, KEINE Kategorien/Farben
    • Bidirektionale Löschungen: wenn ein Termin in einem System gelöscht wird, wird es auch im anderen gelöscht
    • Symmetrische Konfliktauflösung: Last-Write-Wins für Änderungen und Löschungen
    • Delta-Sync über Graph-Delta-Link (mit Selbstheilung bei abgelaufenem Token) und CalDAV-Sync-Token
    • Journal-Protokollierung mit Sync-Status, Konflikten und Fehlerbehandlung
    • Neue Lizenz: MESO-WSNEXTCLOUD
  • 🕒 Konfigurierbare Zeitzone für Termine: Die zuvor fest verdrahtete Zeitzone Europe/Vienna ist jetzt konfigurierbar — global über die Einstellung DefaultTimeZone (Standard Europe/Berlin) und optional pro Termin-Einstellung bzw. Kalender-Sync-Paar über das Feld Zeitzone überschreibbar. Betrifft sowohl den CRM-Terminsync als auch die NextCloud-Synchronisation. Hinweis: Neu erstellte Termine tragen dadurch standardmäßig Europe/Berlin statt Europe/Vienna (gleiche Uhrzeit, korrektes Zonenlabel).
  • Splitbuchungen: Buchungsregeln können jetzt mehrere Buchungszeilen erzeugen (z.B. Darlehen: Tilgung + Zinsen). Betrags-Ermittlung per Regex, fester Betrag, Prozent oder Restbetrag. Bei fehlgeschlagener Regex-Extraktion wird automatisch ein LLM-Fallback zur Betrags-Erkennung verwendet. Splitbuchungen erzeugen das WinLine-native Splitbuchungs-XML (mehrere T331-Zeilen mit gleicher Buchungsnummer).
  • 💾 Benutzerdefinierte Ansichten speichern: Benutzer können eigene Ansichtseinstellungen (Spaltenanordnung, Sortierung, Gruppierung, Filter) unter einem frei wählbaren Namen speichern und jederzeit wieder laden. Gespeicherte Ansichten können optional mit anderen Benutzern geteilt werden. Verfügbar über die Toolbar-Aktionen „Ansicht speichern", „Gespeicherte Ansichten", „Ansicht aktualisieren" und „Ansicht löschen".
  • 🔍 Filter-Presets in allen Modulen: Vordefinierte Filter für schnellen Zugriff auf typische Geschäftsvorfälle:
    • Banking-Transaktionsjournal (11 Presets): Offene Vorgänge, Zahlungseingänge/-ausgänge, Handlungsbedarf, KI-Vorschläge, Gebucht, Fehler, Freigabe ausstehend, Vorauszahlungen u.v.m.
    • Buchungsregeln (5 Presets): Aktive/Inaktive Regeln, KI-generiert, Manuell erstellt
    • Mail-Warteschlange (5 Presets): Entwürfe, Fehler, Entwürfe & Fehler, Ignoriert
    • Mail-Journal (5 Presets): Erfolgreich versendet, Fehler, Fehlende Empfänger, Ignoriert
    • OP-Journal (5 Presets): Fehler, Unversendet, Versendet, Ignoriert
    • Banking-Konten (3 Presets): Aktive/Inaktive Konten
    • OP-Einstellungen (3 Presets): Aktiv/Inaktiv
  • 🎨 Farbkodierung in ListViews: Zeilen werden jetzt visuell nach Status hervorgehoben:
    • Rot: Fehler (Transaktionsjournal, Mail-Warteschlange, Mail-Journal, OP-Journal)
    • Gelb: Vorschläge/Entwürfe (Transaktionsjournal, Mail-Warteschlange)
    • Grün: Gebucht (Transaktionsjournal)
    • Grau: Inaktiv/Ignoriert/Vorschau (Buchungsregeln, Banking-Konten, OP-Einstellungen, Mails)
    • Orange: Fehlende Empfänger (Mail-Journal)
  • 📋 Buchungsregel DetailView: Neues übersichtliches Tab-Layout mit 4 Tabs (Stammdaten, Erkennungsmerkmale, Buchungsziel, Vorlagen)
  • 📊 Erweiterte Standard-Spalten im Transaktionsjournal: PayeeName (Empfänger), Verwendungszweck und Fehlermeldung sind jetzt für alle Benutzer sichtbar — nicht mehr nur für die Buchhalter-Rolle
  • ✅ Validierungen ergänzt: Pflichtfeld-Prüfung für MailSettings.Name, Prioritäts-Bereich (0–99) für Buchungsregeln
  • 🗂️ Visueller Empfängerregel-Editor: Neue Karten-basierte Ansicht für Empfängerregeln mit Drag & Drop
    • Farbcodierung nach Zustelltyp (To/Cc/Bcc) und Regel-Besonderheiten
    • Accordion-Bearbeitung direkt in der Kartenansicht
    • Flowchart-Vorschau zeigt die Regellogik als Diagramm (DevExtreme dxDiagram, deutsche Einheiten)
    • Diagramm zeigt Bedingungen (z.B. „wenn Rechnungsmail → Cc") und Ausschlusslogik
    • Vollständig deutsche Bezeichnungen im Editor und in der Vorschau
    • Standard-Grid weiterhin als Experten-Ansicht verfügbar
  • 🚚 Händler & Händlerkontakt als Mail-Empfänger: Die erweiterten Empfängerregeln unterstützen nun zwei neue Regeltypen:
    • Supplier (Händler): E-Mail aus Incidence.Haendlerkonto → Kontenstamm.Adresse.EMailAdresse
    • SupplierContact (Händlerkontakt): E-Mail des zugeordneten Händler-Ansprechpartners aus Incidence.KontaktHaendler
    • Vollständig integriert in den Karten-/Flowchart-Editor (eigene Icons, deutsche Bezeichnungen)
    • Nutzbar in Prioritäts-, Bedingungs- und Ausschlusslogik analog zu Kunde/Kundenkontakt
  • 🎨 CSS EDV Custom Theme: Fluent-Theme mit firmenspezifischer Farbpalette
    • Primärfarbe (#458407), Akzentfarbe, Hintergrund- und Kartenfarben
    • Splash-Screen mit Dark-Mode-Unterstützung
    • WinForms-Client: WXI-Skin mit passender Akzentfarbe
  • 📋 Verbesserte DetailView-Layouts: Mail-Warteschlange und Mail-Journal DetailViews mit übersichtlichem Tab-Layout und mehrspaltigem Formular
  • 🔧 Model-Unterschiede in Navigation: ModelDifference-ListView unter Benutzerverwaltung verfügbar für Admin-Zugriff auf gespeicherte Layout-Anpassungen

Refactoring:

  • 🏗️ Buchhalter-Controller vereinfacht: Die Filter-Logik (Offene Vorgänge / Alle Transaktionen) wurde aus dem rollenspezifischen Controller entfernt und durch modulübergreifende ListViewFilter-Presets ersetzt. Der Buchhalter-Controller fokussiert sich nun auf Spaltenanpassungen und Fehlersortierung.
  • 🏗️ Banking OP-Abfrage vereinfacht: OpenItemSettings und KreditorOpSettings werden für das Banking-Matching nicht mehr benötigt. Der neue BankingOpQueryService fragt Offene Posten direkt anhand des Kontenstamm-Kennzeichens (C004='2' Debitoren, C004='3' Kreditoren) ab — ohne zusätzliche Filter. In BankAccountSettings ersetzen vier neue Felder (DebitorAccountFrom/DebitorAccountTo, KreditorAccountFrom/KreditorAccountTo) die bisherigen Verknüpfungen zu OpenItemSettings und KreditorOpSettings. Standardbereiche: Debitoren 10000–49999, Kreditoren 60000–69999.
  • 🎨 Theme-Migration: rule-card-editor.css, Banking-Dashboard, Overview-Dashboard und Status-Farben auf Fluent CSS-Variablen migriert

Bugfixes:

  • 🐛 Plausibilitätsprüfung bei Multi-OP-Kreditor-Matches: Wenn der Empfänger einer Ausgangs-Zahlung (z.B. per Kreditkarte/AMEX) über PayeeName-Fuzzy-Match, LLM-Rechnungserkennung oder Name-Match identifiziert wird, aber im Verwendungszweck keine konkrete Belegnummer steht, wurden bislang ALLE offenen OPs des Kreditors als „Sammelzahlung" ins Journal geschrieben — auch wenn die Summe völlig unplausibel war (Beispiel: 25,97 € Zahlung, 112 OPs mit Σ 1.427,22 € als Treffer). Die neue Plausibilitäts-Logik (ApplyKreditorMultiOpMatch) entscheidet jetzt dreistufig:

    1. Summen-Treffer (Σ Restbeträge ≈ Transaktionsbetrag) → echte Sammelzahlung wie bisher
    2. Eindeutiger Betrags-Treffer (genau ein OP mit Restbetrag = Transaktionsbetrag, ±2 %) → SuggestedMatch mit diesem einzelnen OP, Konfidenz 0,75
    3. Sonst → nur Kreditor-Identifikation (MatchedKontonummer + ErkanntesPersonenkonto), kein konkreter OP-Vorschlag, Konfidenz 0,50, mit klarer Fehlermeldung „Kreditor erkannt, aber n offene OPs (Summe X) passen weder als Sammelzahlung … manuelle Zuordnung erforderlich"

    Außerdem werden BelegNr-Listen in Fehlermeldungen ab >10 OPs auf Top-10 + „… (+n weitere)" gekürzt — verhindert unleserliche Multi-Zeilen-Fehler im Journal.

  • 🐛 GMI-Banking: robustes Deserialisieren des records-Felds: Die GMI-Schnittstelle liefert das records-Feld je nach Antwort als Array oder als einzelnes Objekt. Der GmiBankingProvider verarbeitet nun beide Varianten korrekt, statt bei einem Einzelobjekt einen Deserialisierungsfehler zu werfen.

  • 🐛 Sammelzahlungen: alle erkannten OPs werden gebucht: Erkannte das Matching mehrere Rechnungen im Verwendungszweck (z.B. „DV-2607008 / DV-2607009 / DV-2607066"), wurden zwar alle OPs im Journal erfasst, aber bei der FIBU-Buchung entstand nur eine Zahlungszuordnung (T340) über den Gesamtbetrag auf die erste Rechnung — die übrigen OPs blieben in WinLine offen, die erste war überzahlt. Jetzt wird bei der Buchung (Freigabe und Automatik) für jeden erkannten OP eine eigene Zahlungszuordnung mit seinem Restbetrag erzeugt — sowohl für Kreditor-Sammelzahlungen (KZ) als auch für Debitor-Sammelüberweisungen (DZ). Sicherheitsbedingungen: alle OPs müssen zum selben Personenkonto gehören, die Restbetragssumme muss dem Transaktionsbetrag exakt entsprechen und die Transaktion muss in EUR vorliegen (bei Fremdwährung wären OP-Restbeträge und Zahlbetrag nicht vergleichbar); andernfalls bleibt das bisherige Verhalten (Einzel-Zuordnung, manuelle Prüfung empfohlen). Vorauszahlungen erhalten weiterhin bewusst keine Zahlungszuordnung. Die erkannten OP-Zuordnungen sind jetzt außerdem in der Detailansicht des Banking-Journals sichtbar (Tab „Matching-Ergebnis" → „Erkannte OP-Zuordnungen" mit Belegnummer, Betrag und Restbetrag je OP).

  • 🐛 Zeitliche Plausibilitätsprüfung: keine Zuordnung zu erst später erstellten Rechnungen: Eine Zahlung konnte bislang einem offenen Posten zugeordnet werden, dessen Rechnungsdatum nach dem Zahlungsdatum liegt (Beispiel aus der Praxis: eine AMEX-Zahlung vom 06.06. wurde einer Rechnung vom 04.07. zugeordnet). Das Matching prüfte Betrag, IBAN, Name und Belegnummer, aber nie, ob die Rechnung zum Zahlungszeitpunkt überhaupt schon existierte — insbesondere beim erneuten Abgleich (Re-Match) älterer Transaktionen gegen die inzwischen gewachsene OP-Liste. Jetzt werden offene Posten, deren Belegdatum nach (Zahlungsdatum + Toleranz) liegt, in allen Zuordnungspfaden (Score, Belegnummer/Rechnungsmuster, Betrags-Fallback, Sammelzahlung, IBAN-/Namens-Match) aus der Kandidatenliste entfernt. Maßgeblich ist das spätere Datum aus Wertstellung und Buchungsdatum. Die Toleranz ist pro Banking-Konto konfigurierbar (Einstellung OP-Datum-Toleranz (Tage) unter „Zahlungseingänge → Matching-Schwellwerte", Standard 3 Tage; fängt Valuta-/Zeitzonen-Versatz ab). Vorauszahlungen (echte Vorkasse) laufen weiterhin über den separaten Vorauszahlungs-Pfad und sind nicht betroffen.

  • 🐛 Idempotenz: keine doppelte Zahlung für bereits gebuchte offene Posten: Solange ein vom Dienst erzeugter Buchungsstapel in WinLine noch nicht verbucht war, galt der offene Posten in der FIBU weiterhin als offen und konnte in einem späteren Lauf erneut zugeordnet werden — dieselbe Rechnung landete ein zweites Mal im Zahlungsstapel. Beim Laden der OP-Kandidaten werden jetzt alle offenen Posten ausgeschlossen, für die bereits ein Journal-Eintrag mit Status Gebucht (Debitor/Ausgang/Kreditor) oder Freigabe ausstehend existiert. Der Filter greift für Zahlungseingänge und -ausgänge sowie beim automatischen Lauf und beim erneuten Abgleich. Die Anzahl entfernter OPs wird im Log protokolliert.

  • 🐛 Erneuter Mailversand nach dem Löschen von Journal-Einträgen: Nach einem Versandfehler (z.B. abgelaufenes App-Secret) blieb das Löschen der Fehlerzeilen im Mail-Journal wirkungslos — der Mail-Job betrachtete den Workflow-Schritt weiterhin als „bereits verarbeitet" und versandte die Mail nie erneut. Ursache: Die Anwendung löscht Datensätze zunächst nur logisch (Markierung zum Löschen), die Auswahlabfrage des Jobs berücksichtigte diese Markierung aber nicht. Jetzt werden zum Löschen markierte Einträge in Mail-Journal und Postausgang ignoriert: nach dem Löschen erzeugt der nächste Job-Lauf die betroffenen Mails neu — ein „Purge DB" ist dafür nicht mehr nötig.

Verbesserungen:

  • ☑️ Mehrfachauswahl in den Listen des Windows-Clients: Alle Listenansichten besitzen jetzt eine Auswahl-Checkbox — inklusive „Alle auswählen" in der Kopfzeile und in Gruppenzeilen. Damit lassen sich Massenaktionen wie das Löschen mehrerer Journal-Einträge in einem Schritt ausführen, statt jeden Datensatz einzeln zu bearbeiten.
  • 🔐 Anmeldungen überstehen Container-Neustarts: Die DataProtection-Schlüssel der Admin-Oberfläche (zum Signieren von Anmelde-Cookies und Antiforgery-Tokens) werden jetzt dauerhaft im Verzeichnis /app/keys abgelegt. Zuvor erzeugte jeder Container-Start/-Update neue Schlüssel, wodurch alle Benutzer abgemeldet wurden. Für Persistenz über Updates hinweg muss ein Volume auf /app/keys gemountet werden (im Portainer-Stack-Beispiel bereits als Volume mesoworker-keys enthalten).

Paketaktualisierungen:

  • MesoXPO-DevEx25.2: → 2026.4.73-beta03
  • MesoXPO.Business-DevEx25.2: → 2026.4.73-beta05
  • WinLineServerClient: → 1.4.0

Version 2.7.3 (März 2026)

Neue Funktionen:

  • Neues Modul: Offene Posten (MESO-WSOP): Automatischer Versand von OP-Infos an Kunden
    • Ermittlung offener Posten aus der WinLine FIBU (Tabelle T019) mit Gruppierung nach Kunden
    • Flexible Selektion nach Kontoart (Debitoren/Kreditoren), Fälligkeit, Mahnstufe, Mindest-Überfälligkeitstagen und individuellen Filtern
    • HTML-Vorlagen mit Platzhaltern für Kunden- und OP-Daten ({{#OP}}...{{/OP}} Wiederholungsbereiche)
    • Mehrstufige Empfängerermittlung: Rechnungs-E-Mail, Kunden-E-Mail, Kontakt, Mahnempfänger, statische Empfänger
    • Optionale Anhänge: Originalrechnungen aus MesoArchivWeb und OP-Blatt aus der FIBU als PDF über WinLine Server
    • Entwurfsmodus: OP-Mails können als Entwurf im Postausgang gespeichert und vor dem Versand geprüft/bearbeitet werden
    • Journal-Protokollierung mit konfigurierbarem Sendeintervall (SendIntervalDays) zur Vermeidung von Mehrfachversand
    • Ignorieren-Flag zum manuellen Ausschließen einzelner Kunden (im Journal oder Postausgang)
    • Vorschau-Funktion in der Administrationsoberfläche
    • Neue Lizenz: MESO-WSOP
  • OP-Blatt: Korrekter Report-Service-Endpunkt und alternative Formular-ID: Der OP-Blatt-Download verwendet den WinLine Report-Service (/ewlservice/reports) mit PDF-Validierung. Über die neue Einstellung OpenItemListFormId kann ein alternatives Formular für das OP-Blatt angegeben werden.
  • Interner Sentry-Fehlertracker: Automatische Erfassung und Protokollierung von Laufzeitfehlern zur schnelleren Diagnose
  • CSS-Inlining für OP-Mails: HTML-Mails werden für maximale E-Mail-Client-Kompatibilität mit inline CSS-Styles versehen (HtmlAgilityPack)

Fehlerbehebungen:

  • Zeilenumbrüche in UserColumn-Platzhaltern: Mehrzeilige Texte aus benutzerdefinierten Spalten (z.B. über VBScript mit vbCrLf gespeichert) werden nun korrekt als <br /> in HTML-Mails dargestellt. Zuvor wurden \r\n-Zeilenumbrüche von HTML-Renderern ignoriert. Gleichzeitig werden die Werte HTML-encoded (XSS-Schutz).
  • NullReferenceException beim Ignorieren von Draft-Mails: Mehrfachauswahl von Entwurfs-Mails im Postausgang und anschließendes Ignorieren führte zu einer Exception, wenn optionale Referenzen (WorkflowSettings, SmtpAccount, EmlFile) nicht gesetzt waren (z.B. bei OP-Mails). Null-Prüfungen ergänzt.

Paketaktualisierungen:

  • MesoXPO-DevEx25.2: 2026.4.65 → 2026.4.70
  • MesoXPO.Business-DevEx25.2: 2026.4.49 → 2026.4.56

CI/CD:

  • Pandoc-Publizierung aus Documentation-Workflow entfernt, nur noch BookStack-Publish
  • CI-Workflows mit Reusable Workflows konsolidiert
  • Docker-Builds beschleunigt (QEMU, Provenance und SBOM entfernt)
  • Zentraler Beta-Deploy-Workflow für alle Container

Version 2.7.2 (März 2026)

Fehlerbehebungen:

  • OutOfMemoryException behoben: SQL-Subquery statt XPCollection/IN-Clause für große Datenmengen in der Filter-Auswertung

Verbesserungen:

  • XAF ListViews auf wesentliche Spalten reduziert, DetailViews für QueuedMail/MailJournal/RecipientRuleTemplate ergänzt
  • CI: GitHub Workflows optimiert — Docker einmal bauen, Win-Builds parallelisiert

Version 2.7.1 (März 2026)

Verbesserungen:

  • XPView-Performance: XPView statt XPCollection für Filter-Auswertung in MailWorkerJob, AppointmentWorkerJob und IncidenceFilterService — deutlich geringerer Speicherverbrauch
  • WorkflowSettings: Workflows werden als ListView statt TagBox dargestellt

Version 2.7.0 (März 2026)

Neue Funktionen:

  • ArchivLinkInt/ArchivLinkExt Platzhalter: Neue Platzhalter-Variablen für interne und externe Dokumenten-Links aus MesoArchivWeb in E-Mails
  • Optionaler Betreff für MailMerge-Templates (MailTemplateSubject): Neues Feld MailTemplateSubject in den Mail-Einstellungen ermöglicht die Definition eines eigenen E-Mail-Betreffs bei Verwendung von Rich-Text-Vorlagen (MailMerge). Unterstützt dieselben Platzhalter-Variablen wie der restliche Mail-Inhalt. Wenn leer, wird wie bisher die Kurzbeschreibung des Vorgangs verwendet.
  • Deutsche Lokalisierung: Vollständige deutsche Übersetzung der Administrationsoberfläche mit Request Localization

Sicherheit:

  • SQL-Injection-Schwachstellen durch SqlSanitizer behoben

Refactoring:

  • RecipientResolverService aufgebrochen und Feld-Logik extrahiert
  • Anhang-Logik aus OrderLineWorkflowService extrahiert
  • Interfaces für WorkflowGenerationHelper und OrderLinePropertyMapper eingeführt
  • TimeProvider statt DateTime.Now in Services

Plattform:

  • Migration auf .NET 10

Paketaktualisierungen:

  • MesoXPO-DevEx25.2: 2026.4.65 → 2026.4.66 (Hauptansprechpartner-Fix bei Sortierung < 0)

CI/CD:

  • BookStack-Publish in Documentation-Workflow integriert
  • Automatisches Löschen alter Artifacts (purge_artifacts.yml)

Version 2.6.3 (Februar 2026)

Neues Modul: Open Banking (MESO-WSBANKK)

  • Automatischer Bankkonto-Abruf über GetMyInvoices (GMI) und fino Open Banking API
  • Score-basiertes Debitor-OP-Matching (IBAN, Betrag, Rechnungsnummer)
  • FIBU-Buchungsstapel-Import für Debitor-Zahlungen (DZ + T340)
  • Sammelüberweisungen: mehrere OPs in einem T331 mit N×T340
  • Vorauszahlung: automatische OP-Generierung für erkannte Debitoren ohne OP
  • Manuelle OP-Zuordnung (BankTransactionManualAssignment) mit 1:N-Split
  • Ausgangsbuchungen (B): regelbasierte Erkennung via BuchungsRegel (IBAN/Name/Betrag-Filter)
  • Kreditor-OP-Matching (KZ): Abgleich gegen T019-Kreditoren-OPs (V050.C004=3)
  • KI-Sachkonto-Klassifikation: T055-Kontobezeichnungen + T028-Buchungshistorie als LLM-Kontext
  • Verrechnungskonten: PayPal/Kreditkarten-Kettenbuchungen mit BuchungsRichtung Eingang/Ausgang/Beide
  • LLM-Fallback für Rechnungsnummern-Erkennung (Anthropic Claude, IONOS, Ollama, LM Studio)
  • Vorschau-Modus: vollständiges Matching ohne FIBU-Import
  • Benachrichtigungs-Mails für nicht zuordenbare Transaktionen

Version 2.6.2 (Februar 2026)

Fehlerbehebungen:

  • Textbaustein-Ermittlung: neuester Textbaustein über alle Wirtschaftsjahre: ProcessTextbausteinAsync ermittelt nun den neuesten Textbaustein (sortiert absteigend nach Mesoyear) zur angegebenen Nummer und Mandant. Der implizite MesoYear-Filter des MesoObjectLayer wird hierfür temporär deaktiviert (IgnoreMesoYear/ResetIgnoreMesoyear).
  • Mailversand bei wiederholter Workflownummer im selben Vorgang: Die Duplikat-Erkennung für Incidence-basierte Workflows prüft nun neben IncidenceId und WorkflowNumber auch die StepNumber. Damit wird bei mehrfacher Verwendung derselben Workflownummer (z.B. Schritt 1 → Mail versendet → Schritt 2 mit gleicher Workflownummer) der Folgeschritt korrekt als neuer Mailversand erkannt. Betrifft IncidenceFilterService und MailWorkerJob.

Paketaktualisierungen:

  • MesoXPO-DevEx25.2: 2026.4.56-beta02 → 2026.4.60
  • MesoXPO.Business-DevEx25.2: 2026.4.42-beta07 → 2026.4.45
  • WinLineServer.ApiExtensions / WinLineServerClient: 1.2.3 → 1.2.4

Version 2.6.1 (Februar 2026)

Fehlerbehebungen:

  • Zusatzempfänger aus Vorgang (T170) im klassischen Pfad: SendToIncidenceAdditionalRecipient mit Zusatzfeld-Unterstützung wurde im Legacy-Mailversand (MailsFromIncidence) implementiert — bisher wurde die Einstellung nur im erweiterten Empfängerregelsystem (UseAdvancedRecipientRules) ausgewertet
  • Zusatzfeld-Unterstützung für Personenkonto-Zusatzempfänger: SendToCustomerAdditionalRecipient unterstützt nun auch Zusatzfelder (z.B. Zusatzfeld10) über die Zusatz-Navigation, nicht nur direkte Spalten
  • Textbaustein-Ermittlung verwendet Mesoyear aus dem Vorgang: ProcessTextbausteinAsync verwendet nun incidence.Mesoyear direkt statt das maximale Mesojahr aus dem Mandantenstamm abzufragen — damit wird der Textbaustein passend zum jeweiligen Vorgang geladen

Version 2.6.0 (Februar 2026)

Neue Funktionen:

  • Zusatzempfänger aus T170 und Zusatzfeldern: Empfänger können nun aus dem Zusatz-Objekt (Zusatzfelder) geladen werden, sowohl für klassische als auch erweiterte Empfängerregeln
  • Zentraler SmtpAccountResolver: Einheitliche SMTP-Konto-Ermittlung mit Prioritätskette (Workflow → Workflow-Einstellung → Mandant → System-Standard)
  • SMTP-Konto prüfen Button: Neuer Test-Button in der WorkflowSettings-DetailView zeigt pro Workflow das aufgelöste SMTP-Konto und dessen Herkunft an
  • Semantic Versioning für Container-Images: Docker-Images werden zusätzlich mit semantischen Versions-Tags (z.B. 2.6.0, 2.6, 2) versehen

Verbesserungen:

  • Textbausteine werden immer aus dem aktuellen Mesojahr geladen

Version 2.5.4 (Januar 2026)

🐛 Fixed

  • Outlook blockiert eingebettete Grafiken: Behebung des Problems, dass Outlook eingebettete Grafiken in E-Mails als unsicher blockiert
    • Ursache: Bilder wurden über temporäre Dateien mit .tmp Extension eingebettet, die von Outlook's Sicherheitsfunktionen blockiert werden
    • Lösung: Bilder werden jetzt direkt aus dem Byte-Array als LinkedResource eingebettet (ohne temporäre Dateien)
    • Automatische Erkennung des Bildformats anhand der Datei-Extension oder Magic Bytes (PNG, JPEG, GIF, BMP, WebP)
    • Korrekte MIME-Type Zuordnung durch MimeKit basierend auf Dateiname mit richtiger Extension
    • Unterstützte Formate: PNG, JPEG, GIF, BMP, WebP mit automatischer Fallback-Erkennung
    • Geänderte Dateien: MesoWorker.Module/Models/MailData.cs und EmailGenerationTests/Models/MailData.cs

Version 2.5.3 (Januar 2026)

📚 Dokumentation

  • Ressourcenempfehlung für Docker Container: Umfassende Dokumentation für Container-Dimensionierung erstellt
    • Detaillierte CPU- und RAM-Empfehlungen für MesoWorkerService und Blazor Server Container
    • Drei Szenarien dokumentiert: Kleine Installation (Test), Mittlere Installation (Standard), Große Installation (Enterprise)
    • Ressourcenverbrauch nach Komponenten analysiert (Mail-Dienst, Workflow-Erzeugung, Terminsynchronisation, Überwachungsdienst)
    • Speicher- und Netzwerkanforderungen spezifiziert (Disk Storage, I/O, Bandbreite, Latenz)
    • Monitoring und Performance-Tuning Anleitung mit konkreten Schwellwerten
    • Best Practices für Produktivbetrieb (Health-Checks, Log-Rotation, Skalierung, Backups)
    • Checklisten für Deployment und laufenden Betrieb
    • Neue Dokumentationsdatei: Docs/RESSOURCENEMPFEHLUNG.md
    • Referenz in README.md im Inhaltsverzeichnis und Container-Deployment-Sektion

Version 2.5.2 (Januar 2026)

📚 Dokumentation

  • Formatangaben für Platzhalter als eigene Sektion: Dokumentation umstrukturiert für bessere Übersichtlichkeit
    • Eigener Hauptabschnitt (Sektion 8) für zentrale VariableReplacementService-Dokumentation
    • Hervorgehobene Verwendung durch alle Hauptkomponenten (Mail-Dienst, Workflow-Erzeugung, Terminsynchronisation, Überwachungsdienst)
    • Alle Platzhalter-Typen beschrieben: Basis-Platzhalter, Property, UserColumn, Image
    • Standard .NET Format-Strings dokumentiert (Datum, Währung, Zahlen, Prozent)
    • RTF-zu-Text-Konvertierung dokumentiert (ToPlainText, ToHtmlText)
    • Prefix/Suffix-Funktionalität mit Beispielen erklärt
    • Bild-Platzhalter mit HTML-Attributen beschrieben
    • Vollständige Beispiele und Kombinationen hinzugefügt
    • Verweise aus Mail-Vorlagen, OrderLineWorkflow und Terminsynchronisation eingefügt
    • Verbesserte Auffindbarkeit und Zugänglichkeit der Formatierungsdokumentation

Version 2.5.1 (Januar 2026)

🏗️ Refactoring

  • Zentrale E-Mail-Content-Generierung: Legacy MailsFromIncidence verwendet jetzt IMailContentBuilder
    • Duplicate Variablen-Ersetzungslogik entfernt (~305 Zeilen / 26% Code-Reduktion)
    • ReplaceVariables Methode durch IVariableReplacementService ersetzt
    • EmbedImages Methode durch IMailContentBuilder.EmbedImages ersetzt
    • ReplaceAnlagenPlaceholder durch IMailContentBuilder.ReplaceAnlagenPlaceholder ersetzt
    • Duplicate WinLineObjectValueResolver Klasse entfernt (bereits in VariableReplacementService)
    • Zentrale Wartung und Erweiterung der Content-Generierung vereinfacht
    • Konsistente Variablen-Ersetzung zwischen Legacy- und Advanced-Recipient-System

Version 2.5.0 (Januar 2026)

💎 Added

  • Automatisches Löschen von Terminen über MS Graph API
    • Neue Funktion zur automatischen Löschung von Terminen wenn bestimmte Bedingungen erfüllt sind
    • Zwei Löschbedingungen konfigurierbar (OR-verknüpft):
      • DeleteProperty: Eigenschaft die angibt, dass der Termin gelöscht werden soll
      • DeleteFilter: Filterkriterium zur Ermittlung welcher Termine gelöscht werden sollen
    • Löschung erfolgt pro Empfänger einzeln über die Graph API
    • Neue Journal-Properties Deleted (bool) und DeletedOn (DateTime) zur Nachverfolgung
    • Performance-Optimierung: Löschbedingungen werden VOR der Terminerstellung geprüft - Termine die Bedingungen erfüllen werden nicht angelegt
    • Nachträgliche Löschung: Bereits erstellte Termine werden bei nachträglicher Konfiguration oder Datenänderung gelöscht
    • Automatische Ausführung nach jedem Job-Lauf für bereits erstellte Termine
    • Robuste Fehlerbehandlung für bereits gelöschte Termine (404 Not Found)
    • Anwendungsfälle: Stornierte Aufträge, Status-Änderungen, eigenschafts- oder filter-basierte Löschung
    • Vollständige Integration in AppointmentWorkerJob mit Logging und Fehlerbehandlung

Version 2.4.1 (Januar 2026)

💎 Added

  • Neue Einstellung "Warte auf Beleg-Workflow" für Auftragszeilen-Workflow-Erzeugung
    • Neue Option WaitForVoucherWorkflow in OrderLineWorkflowSettings
    • Verhindert die Erzeugung von Belegzeilen-Workflows, wenn noch kein Beleg-Workflow existiert
    • Nicht verarbeitete Zeilen werden beim nächsten Job-Lauf automatisch erneut geprüft
    • Ermöglicht sequentielle Workflow-Erzeugung: zuerst Beleg-Workflow, dann Zeilen-Workflows
    • Funktioniert unabhängig von der bestehenden LinkVoucherWorkflowAsParent Option
    • Detailliertes Logging für übersprungene Belegzeilen

Version 2.4.0 (Januar 2026)

💎 Added

  • Modul-basierte Lizenzierung: WorkerService unterstützt jetzt modulare Lizenzierung
    • Drei separate Module können individuell lizenziert werden:
      • MESO-WSMAIL: Mailservice (aktiviert MailWorkerJob und NoRuleWarningJob)
      • MESO-WSBELEG: Belegzeilenworkflows (aktiviert OrderLineWorkerJob)
      • MESO-WSGRAPH: Graph API Terminabgleich (aktiviert AppointmentWorkerJob)
    • Automatische Erkennung lizenzierter Module beim Start
    • Jobs werden nur aktiviert wenn das entsprechende Modul lizenziert ist
    • Detailliertes Logging zeigt welche Module lizenziert sind und welche Jobs aktiviert werden
    • Basis-Produkt MESO-WorkerService weiterhin erforderlich

🏗️ Refactoring

  • LicenseService erweitert um modulspezifische Prüfmethoden
    • CheckModuleLicenseAsync für einzelne Modulprüfung
    • GetLicensedModulesAsync zur Ermittlung aller lizenzierten Module
  • Job-Registrierung erfolgt jetzt nur noch für lizenzierte Module
  • Lizenzprüfung erfolgt früher im Startup-Prozess vor Job-Registrierung

Version 2.3.1 (Januar 2026)

🏗️ Refactoring

  • XAF Navigationsstruktur strukturiert: Navigation an Hauptkomponenten angepasst
    • NavigationItemAttribute zu allen Business Objects hinzugefügt
    • Logische Gruppierung nach Funktionsbereichen:
      • Stammdaten (Company, Workflow)
      • Mail-Dienst (MailSettings, MailJournal, WorkflowSettings, QueuedMail, NoRuleWarningSettings, NoRuleWarningJournal)
      • Bestelldatei-Workflows (OrderLineWorkflowSettings, OrderLineWorkflowJournal)
      • Termin-Synchronisation (AppointmentSettings, AppointmentJournal, GraphApiSettings)
      • Erweiterte Einstellungen (RecipientRuleTemplate, RecipientRuleDefinition, FilteringCriterion, PropertyValue)
    • Verbesserte Übersichtlichkeit und intuitive Navigation in der Administrationsoberfläche
    • Dokumentation der Menüstruktur in README.MD

Version 2.3.0 (Januar 2026)

💎 Added

  • Terminsynchronisation über MS Graph API: Neue Funktion zur automatischen Erstellung von Kalender-Terminen aus CRM-Einträgen
    • Flexible Workflow-Selektion mit optionalen Filtern für präzise CRM-Eintrags-Auswahl
    • Konfigurierbare Datumsfeld-Zuordnung (Start-/Enddatum, Kalenderstart-/-enddatum, Eskalationsdatum, Erfassungsdatum)
    • Optional: Zeitdauer-Addition zu ermittelten Datumsfeldern
    • Ganztags-Termin-Option steuerbar über konfigurierbare CRM-Eigenschaft
    • Flexible Empfänger-Ermittlung über eMail-Adressen:
      • Verfassender Benutzer des Workflows
      • Delegiert an Benutzer
      • Delegiert an Gruppe (alle Gruppenmitglieder)
      • XRM-Einträge (CrmMehrfacheinträge mit 1:N Benutzern oder Gruppen)
      • Vertreter des zugewiesenen Benutzers
      • Kombinationen mehrerer Quellen möglich
    • Betreff und Body mit VariableReplacementService für dynamische Inhalte
    • Optionale Fall-Anhänge mit Filterung nach Archiv-Formular-ID
    • Journal zur Dokumentation erstellter Termine mit Graph Event IDs
    • Optionale Rücksynchronisation von Terminänderungen aus Exchange zurück in CRM:
      • Konfigurierbar mit Zeithorizont (z.B. 7 Tage)
      • Nur verfügbar wenn ein CRM-Eintrag zu einem einzelnen Termin führte
      • Synchronisiert Änderungen an Datum, Betreff und Body zurück in entsprechende CRM-Felder
    • Authentifizierung über Azure AD Client Credentials (App-only)
    • Termine werden in persönlichen Kalendern der Empfänger erstellt
    • Automatische Ausführung alle 10 Minuten (konfigurierbar)
    • Umfassende Fehlerbehandlung und Protokollierung

Version 2.2.4 (Januar 2026)

💎 Added

  • Workflow-Erzeugung aus Bestelldateizeilen: Neue Optionen zum Anfügen von Anhängen
    • AttachVoucherDocument: Fügt das Beleg-Dokument aus der ArchivId der Belegstufe als Anhang zum erzeugten CRM-Fall hinzu
    • AttachVoucherAttachments: Fügt alle Beleganhänge aus der DokumentenId als Anhänge zum CRM-Fall hinzu
    • AttachParentWorkflowAttachments: Kopiert Anhänge vom übergeordneten CRM-Fall (bei aktiviertem LinkVoucherWorkflowAsParent)
    • Automatische Duplikatserkennung verhindert mehrfaches Anfügen derselben Dokumente
    • Umfassende Fehlerbehandlung und Protokollierung für robuste Dokumentenverarbeitung

Version 2.2.3 (Dezember 2025)

🐛 Fixed

  • EML-Generierung bei Änderung von QueuedMail-Entwürfen: RTF-Formatierung bleibt erhalten
    • Beim Ändern des Body einer QueuedMail (Draft) wird RTF nun korrekt zu HTML konvertiert
    • Verhindert, dass RTF-Code in der EML-Datei erscheint
    • Formatierungen (Fett, Kursiv, Absätze etc.) bleiben erhalten
    • Verwendet RichEditDocumentServer für präzise RTF-zu-HTML-Konvertierung

Version 2.2.2 (Dezember 2025)

Neue Funktionen:

  • Schnellstart-Sektion in README.MD: Neue übersichtliche Schritt-für-Schritt-Anleitung zur Inbetriebnahme
    • Klare Darstellung der erforderlichen Reihenfolge: ConnectionStrings konfigurieren, Service starten (Datenbank wird automatisch erstellt)
    • Beide Deployment-Optionen (Windows und Container) im Schnellstart abgedeckt
    • Wichtige Hinweise und Tipps zur korrekten Installation

Verbesserungen:

  • README.MD-Struktur verbessert: Installation und Ersteinrichtung umstrukturiert
    • Datenbank-Ersteinrichtung als kritischer erster Schritt deutlich hervorgehoben
    • Warnhinweise an allen relevanten Stellen hinzugefügt
    • Verweise auf Schnellstart-Sektion für schnelle Orientierung
    • Verbesserte Navigation durch aktualisiertes Inhaltsverzeichnis

Version 2.2.1 (Dezember 2025)

Neue Funktionen:

  • Deutsche Übersetzungen für die Administrationsoberfläche: Alle fehlenden Beschriftungen wurden ins Deutsche übersetzt
    • Workflow-Protokoll aus Bestelldateizeilen: Vollständige Übersetzung aller Felder
    • Workflow-Einstellungen: Vollständige Übersetzung aller Felder
    • Mail-Anhänge: Vollständige Übersetzung hinzugefügt
    • Verbesserte Benutzerfreundlichkeit der Administrationsoberfläche

Version 2.2.0 (Dezember 2025)

Neue Funktionen:

  • Workflow-Erzeugung aus Bestelldateizeilen: Neue Funktion zur automatischen CRM-Fall-Erzeugung auf Basis von Belegzeilen
    • Automatische Workflow-Generierung aus Bestelldateizeilen
    • Flexible Filterkriterien für präzise Zeilenselektion
    • Verhindert Mehrfachverarbeitung durch intelligente Protokollierung
    • Optionale Speicherung der erzeugten Fall-ID in benutzerdefinierter Spalte
    • Konfigurierbar über die Administrationsoberfläche
    • Automatische Ausführung alle 5 Minuten (konfigurierbar)
    • Umfassende Fehlerbehandlung und Protokollierung
  • Konfigurierbare Datumsfelder für Workflows aus Bestelldateizeilen
    • Wahl zwischen Standard-Datumsfeldern und Kalender-Datumsfeldern
    • Standardmäßig deaktiviert für Abwärtskompatibilität

Fehlerbehebungen:

  • Deutsche Sprachressourcen im Container-Deployment
    • Deutsche Sprachauswahl in der Administrationsoberfläche funktioniert nun korrekt im Container

Version 2.1.1 (Dezember 2025)

Fehlerbehebungen:

  • Thread-Safety-Problem im Mail-Dienst behoben

Version 2.1 (November 2025)

Neue Funktionen:

  • Automatische EML-Neuerzeugung für Entwürfe im Postausgang
    • Automatische Regenerierung bei Änderungen an Empfänger, Betreff, Text, CC und BCC
    • Erhaltung der bestehenden Anhänge beim Regenerieren
    • Funktioniert nur bei E-Mails mit aktiviertem Entwurf-Status
    • Nahtlose Integration in die Detailansicht des Postausgangs
  • Logische Zeitbereiche für Workflow-Filterung
    • Unterstützte Zeitbereiche: Dieses Jahr, Dieser Monat, Dieses Quartal, Diese Woche, Heute, Seit gestern
    • Automatische Berechnung des Startdatums basierend auf dem gewählten Zeitbereich
    • Kompatibel mit bestehenden Filter-Optionen
    • Vereinfachte Konfiguration ohne Wartung fester Datumswerte
  • Überwachungsdienst für fehlende E-Mail-Versendungen
    • Mandantenspezifische Konfiguration mit flexiblen Zeiträumen
    • Grace Period zur Vermeidung von Fehlalarmen für gerade verarbeitete Workflows
    • Automatische Duplikatsverhinderung durch Protokollierung
    • HTML-formatierte Warnungs-E-Mails mit detaillierter Fall-Auflistung
    • Konfigurierbare Empfänger und optionale SMTP-Konten
    • Zeitplanbasierte Ausführung mit konfigurierbaren Intervallen
    • Umfassende Fehlerbehandlung und Protokollierung

Version 2.0 (Oktober 2025)

Neue Funktionen:

  • Erweiterte Empfängerregeln mit Prioritätssystem
  • Bedingte Zustellungslogik
  • Individuelle E-Mail-Zustellung pro Empfänger
  • Microsoft 365 OAuth-Authentifizierung für SMTP
  • Container-Support mit Docker Images
  • Health-Checks für Monitoring

Verbesserungen:

  • Migration auf .NET 9
  • Modernisierung der Software
  • Verbesserung der Administrationsoberfläche

Fehlerbehebungen:

  • Diverse Fehlerbehebungen im Mail-Versand
  • Verbesserungen der Anhangsverwaltung

Keine Kommentare vorhanden