#785: Buchungssatz.java
projectforge-business/src/main/java/org/projectforge/reporting/Buchungssatz.java Java-Interface — Vertrag für Buchungssätze (Buchungssatz) für die Berichtsebene. Quelle: projectforge-business/src/main/java/org/projectforge/reporting/Buchungssatz.java 86 Zeilen · 23 Code · 43 Kommentare · 20 leer
Definiert den schreibgeschützten Vertrag für einen einzelnen Buchungssatz in Finanzberichten. Implementiert von BuchungssatzDO (JPA-Entität) und BuchungssatzImpl (Berichts-Adapter). Das Interface ist das Adapter-Muster zwischen der Persistenzschicht (DO) und der Berichtsschicht (BWA, Kostenberichte): Es extrahiert nur die für Berichte benötigten Felder und verbirgt JPA-Interna vor den Berichtskonsumenten.
Felder
| Methode | Typ | Zweck |
|---|
getId() | Long | Surrogater Datenbankschlüssel |
getYear() | Integer | Buchungsjahr |
getMonth() | Integer | Buchungsmonat (1-12) |
getFormattedMonth() | String | Monat nullauffüllt (01-12) |
getSatznr() | Integer | Laufende Nummer innerhalb des Monats |
getDatum() | LocalDate | Buchungsdatum |
getBetrag() | BigDecimal | Geldbetrag |
getSh() | SHType | Soll/Haben-Kennzeichen |
Adapter-Muster
Das Interface sitzt zwischen BuchungssatzDO (der JPA-Entität mit Hibernate-Annotationen, Lazy-Loading und Persistenzbelangen) und den Berichts-Engines (ReportBwa, KostReportSenior). Durch die Definition eines reinen schreibgeschützten Interfaces berührt die Berichtsschicht niemals direkt JPA-Entitäten – sie sieht nur diesen Vertrag. Dies verhindert versehentliches Lazy-Loading bei der Berichtsgenerierung (das außerhalb einer Transaktion eine LazyInitializationException auslösen würde) und entkoppelt die Berichtslogik von ORM-spezifischen Details.
Wichtiger Commit: 4c04cfd65 — int→Long Migration
Der Rückgabetyp von getId() wurde im Rahmen der MAJOR-ID-Migration von Integer auf Long geändert. Dies erforderte die Aktualisierung aller Implementierungen (BuchungssatzDO, BuchungssatzImpl) und aller Berichtsgeneratoren, die getId() aufriefen. Das Interface fungierte als Vertragsgrenze: Die Änderung des Rückgabetyps hier erzwang eine compiler-gestützte Aktualisierung aller Aufrufer und verhinderte so stille Brüche.
Git-Verlauf
868d6abb7 2025→2026 | 63081666f 2024→2025 | 4c04cfd65 MAJOR: int→Long Migration | b6092df09 2023→2024 | a6a7aece4 Importe optimieren | 57761f2a2 Überflüssige public-Schlüsselwörter entfernen | 9456bbb6c Monat→1-basiertes Integer | 8c31eba2a Umfangreiche Migration Calendar/DateHolder | 9ebb88522 Erster Commit
Wichtiger Commit: 9456bbb6c — Monat 1-basiert
Die Monatsdarstellung wurde von 0-basiert (Calendar-Stil) auf 1-basiert (menschenlesbar) geändert. Die Methode getFormattedMonth() wurde hinzugefügt, um nullaufgefüllte Zeichenfolgen ("01"–"12") für eine konsistente Anzeige und Sortierung bereitzustellen. Dies war Teil einer umfassenderen Bemühung, die Verwirrung um 0-basierte Monate in der gesamten Codebasis zu beseitigen (betrifft EmployeeSalary, VacationServiceImpl, AccountingRecord und MonthlyEmployeeFilter).