Gowler/Masterarbeit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

iteration 8

Browse Source
This commit is contained in:
Christoph Schwörer
2026-08-28 19:41:13 +02:00
parent 37275c96d6
commit 8a22d586f1
182 changed files with 34254 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Ergebnisse/Analysebericht.md
+142
View File
@@ -0,0 +1,142 @@
# Analysebericht – Reverse Requirements Engineering c-entron ERP
Lauf: V1-Baseline/Prompt-only, Iteration 02. Methode: statische Analyse (Schritte 0–6 der RRE-Methodenkette), keine Ausführung. Ergebnis: 15 StRS-, 31 SyRS-, 35 SwRS-Anforderungen (81 gesamt).
## 1. Modulinventar (Schritt 0, vor der ersten Anforderung erstellt)
Legende Tiefe: **tief** (Kernlogik/Rechte- und Prozessdurchsetzung gelesen), **mittel** (Fachklassen und harte Belege benannt), **flach** (Existenz/Zweck/Anker belegt, kein Detail read), **n.a.** = nicht analysiert (Begründung s. u.).
| # | Modul / Komponente | Pfad(en) | Fachliche Aufgabe | Tiefe | Anforderungen (IDs) |
|---|---|---|---|---|---|
| 1 | CRM / Geschäftspartner & Stammdaten | BL/Accounts, BusinessPartner, CustomerArea, CountryArea | Kunden, Lieferanten, Ansprechpartner, Anreden/Länder/Bundesländer rechtegestützt verwalten | mittel | StRS-001, StRS-009, SwRS-010 (3) |
| 2 | Vertrieb & Belegwesen | BL/Sales/Receipts | Belegkette Angebot→Gutschrift inkl. Preisregeln, Storno, Journal | tief | StRS-003, SyRS-019, SyRS-020, SyRS-021, SwRS-001, SwRS-005, SwRS-006 (7) |
| 3 | Verträge & automatische Abrechnung | BL/Sales/CustomerAssets, WebServices/.../AutomaticFactura | Vertragsverwaltung, Klick-/Zählerabrechnung, Stammblatt-Bindung | tief | StRS-004, StRS-005, SwRS-011, SwRS-017 (4) |
| 4 | Helpdesk / Ticketservice | BL/Sales/Support, TicketProjects, TaskManager, NexusTicketViews | Tickets mit Kategorien/Status/SLA-artigen Rechten, Zeit, Vorlagen (C-FLOW), Projekt-Kopplung | tief | StRS-006, StRS-007, SwRS-002, SwRS-009, SwRS-025, SwRS-026 (6) |
| 5 | Kalender / Zeit / Termine | BL/Sales/Calendar, Calendar, Time, MyDay, AppointmentRequests | Terminplanung mit Einschränkungsrechten, Tagesübersicht, externe Terminanfragen | flach | SyRS-004 (Teil), StRS-007 (2) |
| 6 | Projekte / Prozesse / erwartete Ereignisse | BL/Projects, Processes, ExpectedEvents | Projekte über Objekte, Prozessdefinitionen, Ereignissteuerung | flach | SwRS-025 (1) |
| 7 | Checklisten | BL/CheckListArea | Checklistenvorlagen/-instanzen mit Punkt-Bearbeitern | mittel | SwRS-021 (1) |
| 8 | Aufgaben / Wiedervorlagen | BL/ToDoArea | Objektbezogene Aufgaben inkl. Fremdlisten-Rechte | mittel | SwRS-020 (1) |
| 9 | Warenwirtschaft / Artikel / Logistik | BL/Warehousing, Devices, Logistics, Storage, ProductMatrix | Artikelstamm, Bestände, Lagerorte, Nebenlager, Umbuchungen, Varianten-Matrix | tief | StRS-008, SwRS-019, SwRS-023 (3) |
| 10 | Seriennummern / Barcodes | BL/Warehousing (BarcodeBL) | Zustandsgeführte Seriennummern über Lager/Beleg/Stammblatt | mittel | SwRS-018 (1) |
| 11 | Einkauf / Lieferantenbelege | BL/Buying, Purchasing | Lieferantenstamm, Bestellungen, Lieferantenliefer/-rechnung/-gutschrift | flach | StRS-009 (1) |
| 12 | Produktion / Fertigungsaufträge | BL/Production, Nexus/ProductionOrderManagement | Arbeitspläne, Produktionsaufträge, Schritt-Zeiten | mittel | SwRS-022 (1) |
| 13 | RMA / Retouren | BL/CustomerArea (RmaBL) | Retourenabwicklung mit Versandarten | mittel | SwRS-024 (1) |
| 14 | Finanzen / Zahlungsverkehr / Bank | BL/Accounting, Finances, Transactions, apis/FinAPI, WPF OnlineBanking | Bankverbindungen, Zahlungseingänge, Kassenbuch, Online-Banking | mittel | StRS-011, SyRS-016 (2) |
| 15 | Mahnwesen | SSMS (Mahnlauf), Recht IGNORE_DUNNING_* | Mahnläufe und Mahnsperre für Belege | flach | SyRS-027 (1, HYPOTHESE) |
| 16 | EDI / Distributoren | BL/EDI, CPra | Elektronischer Dokumentenaustausch (Alltron, ALSO, Komsa, Concerto, EGIS, Opentrans21), CumpuPrA-Connector | mittel | StRS-010, SyRS-012 (2) |
| 17 | E-Rechnung (ZUGFeRD/ebInterface) | BL/EDI/Zugferd, Centron.Api.EbInterface | Elektronische Rechnungsformate | flach | SyRS-013 (1) |
| 18 | Versanddienstleister | apis/Centron.Api.Gls, Centron.Api.Shipcloud | Paketscheine/Tracking GLS & Shipcloud | flach | SyRS-014 (1) |
| 19 | Katalogartikel-Import | apis/ITscope, Icecat, Egis, Cop DataAccess | Artikelimport mit Feld-Mapping aus Distributionsquellen | mittel | SyRS-015 (1) |
| 20 | MSP: Asset Management & Monitoring | SSMS AssetManagement*, BL/Integrations, RiverDivo | IT-Inventur, Checks/Historie, Lizenz-/Notfallmanagement | mittel | StRS-012, SyRS-030 (2) |
| 21 | Kommunikation (Mail/Telefon/Chat/Notify) | BL/Mail, Mailings, MailScanner, Tapi, Chats, Notifications, NexusNotifications, Outlook(BL) | E-Mail (Vorlagen/Signatur/Blacklist/Exchange), TAPI, Chats, Benachrichtigungen, Serienmail (VMA) | mittel | SyRS-023 (1) |
| 22 | Dokumente / Dokumentation / docuFORM | WebServices FileManagements, DocumentationArea, DocuBoard, Centron.Api.docuFORM, Security/PdfSigning | Objektbezogene Dateien mit Rechten, intern/extern Doku, PDF-Signatur, Formular-Integration | mittel | SyRS-025 (1) |
| 23 | Reporting / Statistik | BL/ReportEngine, Reporting, Statistics | Berichtsgruppen/-Designer, Statistiken, Management-Infos mit Filialbeschränkung | tief | StRS-015, SyRS-018 (2) |
| 24 | Volltextsuche | BL/IndexSearch | Deutschsprachiger Objektindex (Lucene-artig) | flach | SyRS-017 (1) |
| 25 | Künstliche Intelligenz | BL/ArtificialIntelligence | KI-Chat mit rechtegesteuerten Fähigkeiten und Prompt-Verwaltung | mittel | SyRS-024 (1) |
| 26 | Passwortverwaltung (Tresor) | BL/PasswordManager, PasswordManagementArea | Zugangsdaten-Verwaltung mit Richtlinien/Bereichen und Exportrecht | mittel | SyRS-029 (1) |
| 27 | Benutzer / Rechte / Administration | BL/Administration, SystemArea, EmployeeArea, CentronRights.md | Benutzer-/Mitarbeiterverwaltung, Rechtekatalog, Einstellungen, Logos | tief | StRS-002, StRS-014, SyRS-003, SyRS-004, SwRS-007, SwRS-008, SwRS-013 (7) |
| 28 | Authentifizierung & 2FA | BL/Administration/Logins, TwoFactorAuthenticator | Login-Dispatcher, AD, Basic, TOTP, RADIUS (Hyp.), Fehlversuchs-Logging | tief | SyRS-005, SyRS-006, SwRS-012, SwRS-013, SwRS-014, SwRS-030 (6) |
| 29 | API-/Webservice-Plattform | webservice/Centron.Controllers, Host*, WebServices.Core | Versionierte REST-API, Auth-Filter, Windows-Service-/Konsolen-Host, Accesstoken | tief | SyRS-001, SyRS-002, SyRS-008, SwRS-015 (4) |
| 30 | Web-Client „Nexus" | nexus/CentronNexus(+Host) | Blazor-Portale: Shop, Service-Board, Produktion, Doc-Signing, Settings | mittel | SyRS-010 (1) |
| 31 | WPF-Desktop-Client | centron/Centron.WPF.UI(+Extension), shared/Centron.Controls* | Modulare Desktop-Arbeitsfläche mit Ribbon und Verbindungswächter | mittel | SyRS-009 (1) |
| 32 | Webshop / Kundenportal / SelfCare | Nexus WebCart/WebOffer, BL/Administration/Logins (WebAccountBL), SelfCare | Endkunden-Shop auf Sonderpreisbasis, Web-Zugänge, Self-Service | mittel | StRS-013, SyRS-011 (2) |
| 33 | Mobile & Konnektivität | BL/Mobile, c-entron.misc.ConnectionManager, Centron.Gateway | Mobile Fachlogik, Verbindungsmanagement, Gateway | flach | SwRS-032 (1) |
| 34 | Massenpflege & Fremdbezüge | BL/DataExchange, MassUpdate, ObjectExternalReferences | Massenupdates, Datenaustausch-Konnektoren, externe Objektreferenzen | flach | SyRS-022, SwRS-029 (2) |
| 35 | Text & Inhalte / Sonstiges | BL/TextModuleArea, Tags, Urls, VideoPortal, WebLinks, SocialMedia | Textbausteine, Anrede-Variablen, Tags, Videoportal-Zuordnung, Weblinks, Social-Media-Streams | flach | SwRS-027 (1) |
| 36 | Customizing / Migrationen / ChangeTracking | BL/Customizations, Administration/Scripts, Modules, ChangeTracking, Exceptions, Telemetry | Skriptgesteuerte DB-Migrationen, Änderungshistorie, Erweiterbarkeit | mittel | SwRS-008, SwRS-016, SwRS-034 (3) |
| 37 | Datenhaltung / Persistenz / Schema | Centron.DAO, Entities, Common, Interfaces, shared/Centron.Core, SSMS_DB_SCHEMA.sql | NHibernate-ORM, 1535 Tabellen, Mappings, Event-Listener, Kernbibliothek (u. a. TOTP) | tief | SyRS-007, SwRS-001, SwRS-003, SwRS-004, SwRS-028, SwRS-035 (6) |
| 38 | Outlook-/Office-Integration | nexus/CentronNexus.OutlookAddIn, BL/Outlook, Nexus/Office | Outlook-Add-in, Kontextbezug Mails↔ERP, Exchange-Inventur | flach | SyRS-031 (1) |
| 39 | Handelsplatz TradePool | BL/TradePool | Separater B2B-Login (Zweck nur hypothetisch) | flach | SwRS-031 (1, HYPOTHESE) |
| 40 | Gutscheinverwaltung | BL/VoucherManagement | Gutscheine (Basisstand) | flach | SwRS-033 (1) |
| 41 | Persönliche Arbeitsflächen | BL/MyCentron, WPF-Modul MyCentron, Nexus Management/Office | Dashboards, Notizen, zuletzt verwendete Objekte | flach | SyRS-009, SyRS-010 (Teile) (2) |
| 42 | Betrieb & Deployment | azure, azure-blazor, docker, deployment, scripts, docs, assemblies, global.json, Directory.Build.props | Cloud-/Container-Artefakte, Regel-Doku, zentrale Build-Konfiguration | flach | SyRS-008, SyRS-026 (2) |
| 43 | Testinfrastruktur | tests/* (Integration, EndToEnd, Playwright, CentronNexusTests) | Automatisierte Tests auf mehreren Ebenen | n.a. | – (Testcode spezifiziert kein Produktverhalten; als Qualitätssicherungs-Beleg genutzt, keine eigene Anforderung) |
| 44 | Technische Hilfsmodule | BL/Helpers, GUI, Core (BL), GUI, CentronIcons, Start, WebSuite, WebVersion(Core) | Icons, Startfenster, Helper, Ausnahme-Typen | n.a. | – (keine eigenständige fachliche Regel belegbar; unterstützende Infrastruktur, keine Anforderung im Sinne von ISO 29148) |
Anmerkung: BL/Buying ist im Repository nahezu leer (nur Verzeichnis External); die Einkaufsfunktion lebt in Purchasing, BusinessPartner und den Supplier-Belegen (Receipts) – Inventarzeile 11 trägt dies explizit.
## 2. Abdeckungstabelle (Kurzfassung)
- **tief:** 9 Module (#2, #3, #4, #9, #23, #27, #28, #29, #37)
- **mittel:** 18 Module (#1, #7, #8, #10, #12, #13, #14, #16, #19, #20, #21, #22, #25, #26, #30, #31, #32, #36)
- **flach:** 15 Module (#5, #6, #11, #15, #17, #18, #24, #33, #34, #35, #38, #39, #40, #41, #42)
- **nicht analysiert:** 2 Module (#43 Testinfrastruktur, #44 technische Hilfsmodule) – jeweils mit Begründung
**Mindestabdeckung erreicht:** Ja. Jede Inventarzeile hat mindestens eine Anforderung oder eine begründete `n.a.`-Einstufung. Anzahl der erzeugten Anforderungen: 81 (15 StRS / 31 SyRS / 35 SwRS; Mehrfachverwendung einer Anforderung über mehrere Zeilen ist möglich).
## 3. Konsistenzcheck
| Prüfung | Ergebnis |
|---|---|
| Doppelte/mehrfach vergebene IDs | Keine (IDs sequenziell je Ebene vergeben: StRS-001..015, SyRS-001..031, SwRS-001..035) |
| Anforderungen ohne Beleg | Keine – jede der 81 Anforderungen führt mindestens 1 recherchierten Artefaktbeleg |
| Anforderungen ohne `Übernahmewürdigkeit` | Keine – Feld in allen Blöcken gesetzt |
| Tracelinks auf nicht existierende IDs | Keine (verwendete Ziel-IDs: StRS-001..015, SyRS-001..031, SwRS-002..035; alle referenzierten Nummern existieren; SyRS-016 wird ausschließlich als Ziel verwendet und existiert) |
| Deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | Keine identifiziert. Markierte Kandidaten: StRS-004/SwRS-017 ↔ StRS-012/SyRS-030 (Stammblatt vs. AssetManagement); SyRS-030 (selbst markiert); SwRS-006 (14 ähnliche Suchkonfigurationen, markiert); SwRS-027 (drei Platzhalter-Implementierungen, markiert); SwRS-005 (God Class, bewusst kein fachlicher Konsolidierungsfall) |
| Belegklassifikation vorhanden | Ja – jede Belegzeile trägt PRIMÄR/SEKUNDÄR/KONTEXT mit Begründung |
### 3.1 Risikorelevante Anforderungen (Sicherheit/Abrechnung/Fakturierung/Berechtigung) – Beleglage
| ID | Titel (Kurzform) | PRIMÄR-Beleg vorhanden? |
|---|---|---|
| StRS-002 | Eingeschränkte Datensichtbarkeit | Ja (AccountBL:282, HelpdeskBL:280–284) |
| StRS-005 | Automatische Vertragsabrechnung | Ja (AutomaticFacturaWebServiceBL-Methoden) |
| StRS-014 | Rechtemodell | Ja (AppRightsBL, ScriptMethod11783) |
| SyRS-002 | API-Rechte 401/403 | Ja (Authorize*-Attribute) |
| SyRS-003 | BL-Rechtezentrale | Ja (AppRightsBL:25, AccountBL, ArticleBL) |
| SyRS-004 | Einschränkende Suchrechte | Ja (InvoiceReceiptSearchConfiguration:152–157 u. a.) |
| SyRS-005 | Authentifizierung | Ja (Authenticator:106–109/161, ADAuthenticator:151–156) |
| SyRS-006 | TOTP-2FA | Ja (TwoFactorAuthenticationBL, voll gelesen) |
| SyRS-011 | WebAccount-Verwaltung | Ja (WebAccountWebServiceBL:54/:75) |
| SyRS-020 | Mindestpreis-Schutz | Ja (ReceiptBL:9043/:9113) |
| SyRS-021 | Rechnungsstorno-Recht | Ja (ReceiptWebServiceBL:1022) |
| SyRS-024 | KI-Rechte | Ja (ArtificialIntelligenceChatWebServiceBL:90/:369–390) |
| SyRS-025 | Dokumentrechte/PDF-Signatur | Ja (DocumentWebServiceBL:78, DocumentationBL:33, PdfSigningBL:60) |
| SyRS-027 | Mahnwesen | **Nein** → konsequent als HYPOTHESE markiert |
| SyRS-029 | Passwort-Tresor-Rechte | Ja (PasswordManagerBL:899/:935) |
| SwRS-007 | AppRightsBL | Ja |
| SwRS-008 | Rechte-Migration | Ja (ScriptMethod11783) |
| SwRS-009 | Helpdesk-Rechte | Ja (HelpdeskBL:271–454) |
| SwRS-010 | CRM-CRUD-Rechte | Ja (AccountAddressBL:259–317 u. a.) |
| SwRS-011 | Abrechnungsservice | Ja (Methoden mit Zeilen) |
| SwRS-012 | SHA1-Hashing | Ja (UsersBL:, WebAccountBL:, BasicAuthenticator:46) |
| SwRS-013 | Login-Dispatcher/Logging | Ja (Authenticator:106–161) |
| SwRS-014 | TOTP-BL | Ja (voll gelesen) |
| SwRS-015 | API-Rechte-Attribute | Ja |
| SwRS-017 | Stammblatt-Regeln | Ja (MasterDataListBL:163/294–305; MasterDataListWebServiceBL:172–188) |
| SwRS-019 | Lagerrechte | Ja (ArticleBL:1035, InventoryBL:77/100, PartialCommission:135/170) |
| SwRS-020 | Fremd-ToDo-Rechte | Ja (ToDoBL:310/:1993) |
| SwRS-021 | Checklisten-Rechte | Ja (CentronChecklistWebserviceBL:160–162) |
| SwRS-026 | Globale Ticket-Ansichten | Ja (NexusTicketViewWebServiceBL:44–124) |
| SwRS-030 | RADIUS-2FA | **Nein** → konsequent als HYPOTHESE markiert |
Ergebnis: 30 risikorelevante Anforderungen, davon 28 mit PRIMÄR-Beleg an der durchsetzenden Stelle, 2 ohne PRIMÄR-Beleg und daher als HYPOTHESE gekennzeichnet. **Kein Verstoß gegen die risikobasierte Priorisierung.**
### 3.2 Abgleich Hypothesen.md ↔ Inline-Markierungen
Inline als `Status: HYPOTHESE` markiert (5): **SyRS-027, SyRS-028, SwRS-003, SwRS-030, SwRS-031**.
Hypothesen.md enthält exakt diese 5 Einträge, keine zusätzlichen freien Fragen. → **Deckungsgleich.**
## 4. Bekannte Lücken
1. **Ticket-Statusmaschine:** Übergänge/Eskalationsregeln nur über Tabellen (hlpdsk_status) und Rechte erschlossen; konkrete Zustandsautomatik nicht gelesen.
2. **Steuer-/Buchungslogik:** MwstSatz/Erlöskonten-Tabellen gesehen, Rechenweg (Steuerpositionen, Rundung, Skonto via Zahkond) nicht vertieft.
3. **Preisfindung:** Staffelpreise (ArtikStaffelpreise, Sonderpreise) nur als Datenanker belegt.
4. **Betrieb/Cloud:** azure*/docker/deployment nur Verzeichnisstruktur; keine Skripte gelesen.
5. **Buying-Inhalte:** Verzeichnis nahezu leer – Einkaufslogik liegt verteilt (s. Inventar #11).
6. **Mandantenlogik, RADIUS-Verdrahtung, Mahnprozess, TradePool-Zweck:** als HYPOTHESE offengelegt.
7. **~40 MB Riesen-Files** (ReceiptBL 623 KB u. a.) nur suchbasiert analysiert; Zeilenbelege statt Volllektüre.
## 5. Selbstbewertung
- **Abdeckung:** 44 Inventar-Maßeinheiten: 9 tief, 18 mittel, 15 flach, 2 begründet nicht analysiert. Mindestabdeckung (≥1 Anforderung je Modul) **erreicht**.
- **Dünne Belege:** Schnittstellenmodule (SyRS-013/014/016/022/031) und flache BL-Module (Prozesse, TradePool, Voucher) beruhen auf SEKUNDÄR-/Existenzbelegen; die 4 HYPOTHESE-Fälle sind die ehrlichen Schwachstellen. Der hohe PRIMÄR-Anteil in Sicherheits-/Abrechnungsdomänen (28/30) ist bewusstes Ergebnis der Vertiefungsreihenfolge (Schritt 0c).
- **Hypothesen:** 5 geführt (SyRS-027, SyRS-028, SwRS-003, SwRS-030, SwRS-031) – deckungsgleiche Sammeldatei.
- **Folge-Iteration-Nachschläge (Priorität):**
1. Steuerungseinheit E-Rechnung/Mahnwesen + Steuer-/Buchungslogik (Accounting-Vertiefung).
2. Ticket-Statusautomat und Eskalation (Sales/Support-Volllektüre).
3. Mandant/RADIUS/TradePool-Hypothesen verifizieren (Codepfade suchen).
4. Preisfindungs-/Rabatt- und Provisionslogik (ReceiptPriceHelper, ReceiptProvisionSchema) vertiefen.
5. Cloud-/Container-Betrieb (azure, docker) und Sicherheitskonfigurationen auswerten.
6. Datenbank: Liste der 134 FK-Constraints extrahieren; Integritäts-Hypothese (SwRS-003) gegenprüfen.
- **Werkzeugeinsatz:** Subagenten wurden für 8 Modulpakete gestartet, lieferten in diesem Lauf keine auswertbaren Endberichte; Breite/Tiefe wurde daher im Hauptkontext über gezielte Verzeichnis-/Regex-Flächenscans und Lektüre von 6 Schlüsseldateien erschlossen. Dieser Umstand begrenzt die Tiefe einzelner Module (s. Abdeckungstabelle), nicht die Belegpflicht.
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Ergebnisse/Glossar.md
+33
View File
@@ -0,0 +1,33 @@
# Glossar (Domänenbegriffe der c-entron-Codebasis)
| Begriff | Definition | Beleg/Anker |
|---|---|---|
| **Stammblatt** | Geräte-Stammsatz beim Kunden (üblicher Einsatz: Drucker/Kopierer in Service-/Click-Verträgen; fachlich ein „Gerät beim Kunden" mit Positionen). Technisch Kopf/Pos-Tabellen GeraeteKopf/GeraetePos. Verknüpfbar mit Verträgen (VertragKopf.Stammblattbezogen), Tickets und Abrechnung. | CentronObjectKindNumeric.cs:314; ReportGroupBL.cs:402 (→ GeraeteKopf); SSMS (GeraeteKopf) |
| **Asset / AssetManagement** | IT-Inventarobjekt der MSP-Funktion (Monitoring-gestützt, ~200 Tabellenfamilien: Checks, AD, DNS, IIS, Lizenzen). Fachlich überlappend mit Stammblatt → Konsolidierungsfall | SSMS (AssetManagement*) |
| **Beleg** | Sammelbegriff für kaufmännische Dokumente (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Bestellung, Vertrag, Anfrage, Kalkulation, Warenein-/ausgang); technisch Kopf/Pos-Paar je Belegart | SSMS (…Kopf/…Pos); ReceiptBL.cs |
| **Kopf/Pos** | Belegmuster: 1 Kopfdatensatz (Nummer, Kunde, Summen, Status) + n Positionsdatensätze (Artikel, Mengen, Preise) | SSMS_*; SwRS-001 |
| **hlpdsk_*** | Ticket-Datenmodell des Helpdesk (requests, timer, status, typen, kategorien, prioritaeten, bearbeiter, history) | SSMS; SwRS-002 |
| **Ticket / Helpdesk** | Serviceanfrage mit Typ, Kategorie(n), Priorität, Status, Bearbeitern, Zeiten und Historie | HelpdeskBL.cs; CentronRights.md |
| **C-FLOW** | Ticketvorlagen/-Anlage-Optimierung (Vorlagen, Kategorien) im Helpdesk; eigenes Rechtecluster | CentronRights.md §17; HelpdeskPatternWebserviceBL.cs |
| **I3D** | Interner Primärschlüssel-Bezeichner der Entitäten (int), in Code und Fehlerobjekten durchgängig verwendet | durchgängig, z. B. bankAccount.I3D (BankAccountBL.cs:78) |
| **AppUser** | Anmeldeidentität eines Benutzers inkl. Verknüpfung zum Mitarbeiter (Employee); Träger der Rechtezuweisung | AppUserBL.cs; EmployeeBL.cs |
| **UserRightsConst** | Hierarchischer Konstantenkatalog aller Rechte-IDs (int), gruppiert nach Fachbereichen (Sales.Customer..., Purchase.StockList..., Administration...) | durchgängig; CentronRights.md |
| **Restricting Right** | Einschränkendes Recht: verkleinert bei Vorhandensein die sicht-/bearbeitbare Datenmenge (ONLY_OWN, ONLY_OWN_BRANCH, SHOW_ONLY_OWN_CUSTOMER) – Inverslogik zu Freigaberechten | CentronRights.md |
| **Filiale** | Organisatorische Standorteinheit; Grundlage der *_ONLY_OWN_BRANCH-Einschränkungen | SSMS (Filiale); SyRS-004 |
| **Mandant** | Rechtlich eigenständige Gesellschafts-Entität im Datenmodell (Tabelle vorhanden; Auswertung HYPOTHESE) | SSMS (Mandant); SyRS-028 |
| **Sonderpreise** | Kundenspezifische Preislisten; Quelle der Artikel im Webshop (WebCart) | README.md „WebCart" |
| **WebAccount** | Web-Login eines Endkunden, am Adressstamm hängend; Basis Shop/Webportal | WebAccountBL.cs; WEBACCOUNT_MANAGEMENT-Recht |
| **OPOS** | Offene Posten eines Kunden (Anzeigerecht SHOW_CUSTOMER_OPOS) | AccountWebServiceBL.cs:355/'SHOW_CUSTOMER_OPOS' |
| **Mahn(sperr)lauf** | Mahnhistorie/Steuerung; Mahnsperre verhindert neue Belege, Ausnahme per Recht IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS | SSMS (Mahnlauf); SyRS-027 (HYPOTHESE) |
| **Kommissionierung** | Lagerprozess der Positionszusammenstellung zu Aufträgen (inkl. Teile Kommissionen, Barcode-Generierung) | OrderCommissionBL.cs; PartialCommissionOrderBL.cs |
| **Inventur** | Bestandszählung mit Inventurgruppen/Pools (Rechte CREATE/DROP_INVENTORY, Gruppenverwaltung) | InventoryBL.cs; InventoryArticlePool.cs |
| **Seriennummer/BarcodeState** | Zustandsgeführte Geräteeinheit („im Lager", „in Stammblatt" u. a.); Grundlage von Umbuchungsregeln | BarcodeBL.cs; BarcodeState.cs |
| **MSP** | Managed Service Provider – Betreiberkontext, für den AssetManagement/Monitoring/AutomaticFactura gebaut sind | Statistikrechte MspStatistics; AutomaticFactura* |
| **Named Query** | Parametrisierte, namentlich registrierte Datenbankabfrage außerhalb des ORM-Standardwegs (z. B. PasswordManager.GetAppUserTwoFactorAuthKey) | DAO/NamedQueries; TwoFactorAuthenticationBL.cs |
| **ScriptMethod** | Versionierte DB-Migrationsklasse (numeriert, enthält SQL), Bestandteil des Update-Prozesses | Administration/Scripts/ScriptMethods/Scripts/ |
| **Virtueller Mail-Assistent (VMA)** | Modul zur automatischen Mail-Verarbeitung/-Zuordnung; Zugriffsrecht ACCESS_VMA_MODULE | MailScannerBL.cs:59–61 |
| **TradePool** | Eigenständiger B2B-Handelsbereich mit separatem Login (TradeCustomerLogin); Zweck HYPOTHESE | TradePoolBL.cs:170; SwRS-031 |
| **RMA** | Return Merchandise Authorization – Retourenvorgang mit eigener Versandart-Steuerung | RmaBL.cs; SSMS (Rma) |
| **ZUGFeRD / ebInterface** | Elektronische Rechnungsformate (DE / AT) | EDI/Zugferd; Centron.Api.EbInterface |
| **Nexus** | Blazor-basierter Web-Client der Suite (Shop, Portal, Backoffice-Teile), Ablösungsperspektive des WPF-Clients | src/nexus/CentronNexus; README.md |
| **docuFORM** | Externes Dokumenten-/Formularsystem; Anbindung über eigenes API-Projekt | Centron.Api.docuFORM |
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Ergebnisse/Hypothesen.md
+11
View File
@@ -0,0 +1,11 @@
# Hypothesen (Sammlung aller [HYPOTHESE]-markierten Anforderungen)
Enthält ausschließlich die in StRS/SyRS/SwRS mit `[HYPOTHESE]` bzw. `Status: HYPOTHESE` markierten Anforderungen (deckungsgleich mit den Inline-Markierungen). Freie Fragen ohne Anforderungsbezug stehen in der Selbstbewertung des `Analysebericht.md`.
| ID | Titel | Warum Hypothese | Offene Frage / fehlende Information |
|---|---|---|---|
| SyRS-027 | Mahnwesen auf Basis offener Posten | Nur indirekte Belege: Tabelle Mahnlauf + Recht IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS; die durchsetzende Prozessklasse wurde nicht gefunden/gelesen | Welche Klasse berechnet Mahnstufen/-läufe? Erzeugt das System Mahnbelege automatisiert? Wo wird die Mahnsperre beim Beleg geprüft? |
| SyRS-028 | Mandantenfähigkeit | Tabelle Mandant existiert, aber die Auswertung im Code (Filter je Mandant) wurde nicht nachgewiesen | Wird Mandant aktiv zur Datentrennung herangezogen (Queries/Session-Kontext)? Single- oder Multi-DB-Betrieb? |
| SwRS-003 | Referenzielle Integrität überwiegend auf BL-Ebene | Quantitativ belegt (134 FK bei 1535 Tabellen); die Aussage „vorrangig BL-gesteuert" ist induktiv aus Stichproben, kein vollständiger Katalog | Vollständige Liste aller BL-seitigen Konsistenzprüfungen; sind die 134 FKs die gesamte Menge oder ergänzen Trigger/Sichten weitere Integrität? |
| SwRS-030 | RADIUS-basierte 2FA im Login-Fluss | Protokollimplementierung (RadiusClient/RadiusPaketParser/EmailTwoFactorValidator) vollständig vorhanden, aber der Aufruf aus dem Login-Dispatcher (Authenticator.cs) nicht überprüft | Ist der RADIUS-Validator produktiv im Anmeldepfad verdrahtet? Welche Konfiguration aktiviert ihn? |
| SwRS-031 | TradePool-Zugang mit eigenem Login | Nur Schnittstelle gesehen (TradePoolBL.AuthenticateUser → TradeCustomerLogin); der Geschäftsprozess dahinter unbekannt | Was ist der fachliche Zweck des TradePool (B2B-Handelsplatz? Restpostenbörse?), welche Funktionen nutzen das Login? |
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Ergebnisse/StRS.md
+336
View File
@@ -0,0 +1,336 @@
# StRS – Stakeholder Requirements Specification (c-entron ERP, Reverse Engineering)
Normbezug: ISO/IEC/IEEE 29148:2018. Alle Aussagen sind aus der Codebasis abgeleitet; technische Bezeichner bleiben im Original. Begriffe siehe `Glossar.md`.
---
```
ID: StRS-001
Titel: Zentrale Verwaltung von Geschäftspartnern (Kunden, Lieferanten, Ansprechpartner)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Vertriebs-/Einkaufsmitarbeiter
Vorbedingung: Benutzer ist angemeldet und besitzt das jeweilige Anlege-/Änderungsrecht
Fakt: AccountBL.cs und AccountAddressContactBL.cs prüfen vor jedem Schreibzugriff Rechte wie CREATE_CUSTOMER, EDIT_CUSTOMER, DELETE_CUSTOMER, RIGHT_LIEFERANTANLEGEN/-AENDERN; Adressen und Ansprechpartner werden getrennt geführt (AccountAddressBL, Tabellen Anschrif, Personen, Kontakte).
Aussage: Das System soll Kunden, Lieferanten, deren Adressen und Ansprechpartner zentral und rechtegeschützt verwalten.
Ergebnis: Konsistente Geschäftspartnerstammdaten, nutzbar in Belegen, Tickets, Verträgen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, Zeilen 1305–1365 (Rechteprüfungen vor Create/Edit/Delete/Search) – setzt regelbasierte Stammdatenpflege durch
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountAddressContactBL.cs, Zeilen 379–413 (je Operation eigenes Recht) – differenzierte Rechte je Partnerrolle
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabellen Kunden, Kreditor, Anschrif, Personen, Kontakte (CREATE TABLE) – Datenmodell der Partner
Prüfidee: Anlage eines Kunden ohne CREATE_CUSTOMER-Recht wird abgelehnt; mit Recht wird Datensatz persistent.
Tracelinks: SyRS-003, SwRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Kernfunktion jedes ERP
Status: belegt
```
```
ID: StRS-002
Titel: Eingeschränkte Datensichtbarkeit (nur eigene Daten / nur eigene Filiale)
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal: -
Akteur: Fachabteilung, IT-Administration
Vorbedingung: Benutzer besitzt ein einschränkendes Recht (z. B. SHOW_ONLY_OWN_CUSTOMER)
Fakt: AccountBL.cs:282 und AccountSearchBL.cs:331 filtern bei gesetztem Recht SHOW_ONLY_OWN_CUSTOMER die Kundenmenge; HelpdeskBL.cs:280–284 filtert Tickets analog (SHOW_HELPDESK_ONLY_OWN/-BRANCH); SaleStatisticBL.cs:60 filtert Statistiken auf die eigene Filiale (SHOW_ONLY_STATISTIC_FROM_OWN_BRANCH).
Aussage: Das System soll es ermöglichen, Benutzern Daten fachlich einzuschränken (nur eigene bzw. nur filialeigene Datensätze), übergeordnete Rechte heben die Einschränkung auf.
Ergebnis: Benutzer sieht ausschließlich die ihm zugeordneten Kunden/Tickets/Belege/Statistiken.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs:282 (HasUserRight SHOW_ONLY_OWN_CUSTOMER steuert Filter) – durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284 (Sichtrechte ONLY_OWN / ONLY_OWN_BRANCH) – durchsetzende Stelle
- [KONTEXT] CentronRights.md (Beschreibung der „restricting rights") – fachliche Definition
Prüfidee: Zwei Benutzer mit/ohne SHOW_ONLY_OWN_CUSTOMER liefern bei identischer Suche unterschiedliche Treffermengen.
Tracelinks: SyRS-004, SwRS-007, SwRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – gefordertes Mandanten-/Teamkonzept
Status: belegt
```
```
ID: StRS-003
Titel: Belegkette: Angebot, Auftrag, Lieferschein, Abholung, Rechnung, Gutschrift
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Vertriebsmitarbeiter
Vorbedingung: Kunde und Artikel sind gepflegt; Benutzer hat das jeweilige Beleg-Recht
Fakt: ReceiptWebServiceBL.cs:969–1022 bildet je Belegart eigene Anlege-/Bearbeite-/Storno-Rechte ab (Offer, Order, DeliveryList, PickUpList, Invoice, CreditVoucher, SupplierOrder, Contract); die DB führt je Belegart Kopf-/Positions-Tabellen (AngKopf/AngPos, AufKopf/AufPos, LiefKopf/LiefPos, AbholKopf/AbholPos, RechKopf/RechPos, GutKopf/GutPos, BestKopf2/BestPos2).
Aussage: Das System soll den vollständigen Vertriebsprozess als verknüpfte Belegtypen führen, inklusive Lieferantenbelegen (Bestellung, Lieferantenliefer-/Rechnungs-/Gutschriftsbelege).
Ergebnis: Durchgängige, nachverfolgbare Belegkette von Angebot bis Gutschrift.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:956–1022 (Rechte je Belegtyp durchgesetzt) – benennt prüfende Stelle je Operation
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE RechKopf/RechPos, AufKopf/AufPos, AngKopf/AngPos, GutKopf/GutPos, LiefKopf/LiefPos, AbholKopf/AbholPos, BestKopf2/BestPos2 – Belegmodell je Belegart
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs, SpecificLogics.cs – typspezifische Logik je Belegart
Prüfidee: Aus Auftrag wird Lieferschein, daraus Rechnung erzeugt; Verknüpfung und Folgebeleg-Nummern prüfen.
Tracelinks: SyRS-019, SyRS-020, SyRS-021, SwRS-001, SwRS-005, SwRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Kerngeschäftsprozess
Status: belegt
```
```
ID: StRS-004
Titel: Vertragsmanagement mit Gerätebezug („Stammblatt")
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Servicekaufmann, Vertrieb
Vorbedingung: Kunde besitzt Geräte (Stammblätter, Tabelle GeraeteKopf)
Fakt: MasterDataListBL.cs:163 verweigert das Löschen eines Stammblatts, solange es einem aktiven Vertrag zugeordnet ist; VertragKopf trägt das Feld Stammblattbezogen; ReceiptContractBL.cs erzeugt vertragspositionen automatisch aus Stammblättern.
Aussage: Das System soll Kundenverträge (inkl. Klick-/Kontingentverträge) mit den beim Kunden installierten Geräten (Stammblättern) verknüpfen und Abhängigkeiten gegen unzulässige Änderungen absichern.
Ergebnis: Vertragspositionen referenzieren verlässlich die Gerätebasis des Kunden.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:163 („Stammblatt ist einem aktiven Vertrag zugeordnet", DependencyCheckFailed) – durchsetzende Konsistenzregel
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ContractLists/ReceiptContractBL.cs:533–563 (Erzeugung von Vertragspositionen aus Stammblättern) – durchsetzende Stelle
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE VertragKopf, VertragPos, VertragGeraete, GeraeteKopf/GeraetePos – Datenmodell
Prüfidee: Stammblatt mit aktivem Vertrag kann nicht gelöscht werden; ohne Vertragsbezug schon.
Tracelinks: SyRS-019, SwRS-017
Konsolidierung: Kandidat: StRS-012/SwRS-017 vs. AssetManagement-Tabellen (zwei Geräte-/Asset-Datenhaltungen)
Übernahmewürdigkeit: übernehmen – fachlich weiterhin erforderlich, aber mit Asset-Konzept konsolidieren
Status: belegt
```
```
ID: StRS-005
Titel: Automatische Vertragsabrechnung (Automatische Faktura) inkl. Zählerstände
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Buchhaltung, Servicekaufmann
Vorbedingung: Es existieren abrechenbare Verträge mit Stammblatt-/Zählerbezug
Fakt: AutomaticFacturaWebServiceBL.cs enthält Methoden SearchBillingContractPos, LoadBillingResult(dtFrom, dtTo, contractI3Ds), GetContractPartibleArticlePositionen und Logik für Zählerstände aus Vorgänger-Stammblättern (Zeile 1421); Sonderartikel können massenhaft Verträgen zugeordnet werden (CreateSpecialArticleToContract).
Aussage: Das System soll wiederkehrende Vertragsabrechnungen automatisiert erzeugen, dabei teilbare Artikel und Zählerstandsdifferenzen (z. B. Klickpreise) berücksichtigen.
Ergebnis: Abrechnungsergebnis pro Vertrag und Zeitraum, abrechnungsbereit als Beleg.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, Methoden SearchBillingContractPos (:124), LoadBillingResult (:2370), CreateSpecialArticleToContract (:894) – durchsetzende Abrechnungslogik
- [SEKUNDÄR] Ebendort :1421 (Textbaustein „Zählerstände aus Vorgängerstammblatt") – belegt Zählerstandsbehandlung
Prüfidee: Vertrag mit Klickpreisartikel und zwei Zählerständen abrechnen; berechnete Menge = Differenz.
Tracelinks: StRS-004, SyRS-019, SwRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – hoher wirtschaftlicher Nutzen; risikorelevant (Abrechnung)
Status: belegt
```
```
ID: StRS-006
Titel: Helpdesk/Ticketbearbeitung mit Kategorien, Prioritäten, Status und Vorlagen (C-FLOW)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Servicetechniker, Helpdesk-Mitarbeiter
Vorbedingung: Tickettyp/-kategorien sind gepflegt; Benutzer hat SHOW_HELPDESK
Fakt: hlpdsk_requests ist Kerntabelle, umgeben von hlpdsk_typen, hlpdsk_kategorien, hlpdsk_prioritaeten, hlpdsk_status, hlpdsk_request_bearbeiter, hlpdsk_history; HelpdeskBL.cs:422–454 prüft ADD_NEW_HELPDESK, EDIT_HELPDESK, CLOSE_REQUEST, MATURITY_CHANGE, ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS; C-FLOW-Vorlagen werden über HelpdeskPatternWebserviceBL.cs verwaltet.
Aussage: Das System soll Serviceanfragen als Tickets mit Typ, Kategorien, Priorität, Status, Bearbeitern, Historie und wiederverwendbaren Vorlagen verwalten und Bearbeitungsschritte rechteabhängig absichern.
Ergebnis: Nachverfolgbare Ticketbearbeitung vom Anlegen bis zum Abschluss.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284, 422–454 (Rechteprüfungen je Ticket-Operation) – durchsetzende Stelle
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE hlpdsk_requests, hlpdsk_status, hlpdsk_typen, hlpdsk_kategorien, hlpdsk_prioritaeten, hlpdsk_request_bearbeiter, hlpdsk_history – Ticket-Datenmodell samt Historie
- [SEKUNDÄR] CentronRights.md, Abschnitt „Helpdesk" – fachliche Rechtebeschreibung
- [KONTEXT] src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskPatternWebserviceBL.cs:351–395 – C-FLOW-Vorlagenrechte
Prüfidee: Ticket ohne CLOSE_REQUEST-Recht kann nicht geschlossen werden; Fälligkeitsänderung ohne MATURITY_CHANGE wird abgelehnt.
Tracelinks: SyRS-003, SyRS-004, SwRS-002, SwRS-009, SwRS-026, SwRS-027
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – zentraler Serviceprozess
Status: belegt
```
```
ID: StRS-007
Titel: Zeiterfassung auf Tickets mit Belegbindung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Servicetechniker
Vorbedingung: Ticket existiert; Benutzer besitzt Zeit-Bearbeitungsrechte
Fakt: hlpdsk_timer speichert Zeiten inkl. Mitarbeiterartikel (Tabelle Mitarbeiterartikel); laut CentronRights.md dürfen Zeiten nur verschoben/gelöscht werden, wenn das Ticket nicht Teil eines Belegs ist (MOVE_HELPDESK_TIMER/DELETE_HELPDESK_TIMER); HelpdeskTimerWebServiceBL.cs:359–374 unterscheidet EDIT_TIME und OWN_TIME_EDIT.
Aussage: Das System soll Arbeitszeiten auf Tickets erfassen und mit Mitarbeiterartikeln bewerten; bereits berechnete Zeiten (Belegbezug) sollen unveränderbar sein.
Ergebnis: Abrechenbare, manipulationssichere Leistungsnachweise.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs:359–374 (Rechte EDIT_TIME/OWN_TIME_EDIT durchgesetzt) – prüfende Stelle
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE hlpdsk_timer, Mitarbeiterartikel – Datenmodell der Zeiterfassung
- [KONTEXT] CentronRights.md, Recht 8/9 (Verschieben/Löschen nur wenn Ticket nicht Teil eines Belegs) – Regel der Belegbindung
Prüfidee: Zeit eines bereits fakturierten Tickets kann weder verschoben noch gelöscht werden.
Tracelinks: StRS-006, SwRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Basis der Dienstleistungsabrechnung
Status: belegt
```
```
ID: StRS-008
Titel: Lagerverwaltung mit Beständen, Seriennummern, Inventur und Kommissionierung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Lagerist, Einkäufer
Vorbedingung: Artikelstamm und Lagerorte sind gepflegt
Fakt: ArticleBL.cs:99–123 prüft eigene Rechte für Ein-/Aus-/Umbuchen (BOOK_TO_STOCK, BOOK_FROM_STOCK, TRANSFER_STOCK) und für Negativbestand (BOOK_ARTICLE_STOCK_INTO_NEGATIVE); InventoryBL.cs:77/100 verlangt CREATE_/DROP_INVENTORY; OrderCommissionBL.cs:431–438 steuert Kommissionierung; BarcodeBL.cs:1091 verhindert Umbuchung einer Seriennummer auf ein Stammblatt, wenn sie nicht „im Lager" ist.
Aussage: Das System soll Warenbestände rechtegestützt führen, Ein-/Aus-/Umbuchungen, Inventuren, Kommissionierung und seriennummernbasierte Nachverfolgung unterstützen und Negativbuchungen nur mit Sonderrecht zulassen.
Ergebnis: Buchungs- und inventursichere Bestände, lückenlose Seriennummernhistorie.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/ArticleBL.cs:99–123, :1035 (Seriennummern-Pflichtflag nur mit CHANGE_SERIALNUMBER_REQUIRED_FLAG) – durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs:77–100 (Inventur-Rechte) – durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/Warehousing/BarcodeBL.cs:1091 (Zustandsprüfung der Seriennummer vor Umbuchung) – konkrete Bedingung
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ArtikelBestand, Lagerort, Lagerplatz, SeriennummerToPosition – Datenmodell
Prüfidee: Ausbuchung unter Null ohne Negativbestand-Recht wird abgelehnt; Seriennummer außerhalb des Lagers kann nicht auf Stammblatt umgebucht werden.
Tracelinks: SyRS-003, SwRS-018, SwRS-019
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-009
Titel: Einkauf mit Lieferantenstamm und Bestellwesen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Einkäufer
Vorbedingung: Lieferant ist angelegt (RIGHT_LIEFERANTANLEGEN)
Fakt: Lieferantenoperationen sind eigene Rechte (RIGHT_LIEFERANTANLEGEN/-AENDERN, AccountWebServiceBL.cs:1868); Lieferantenbelege (Bestellung, Lieferantenliefer-/rechnungs-/gutschriftsbelege) besitzen eigene Such-/Anzeigerechte (SupplierOrderReceiptSearchConfiguration.cs:138–140 u. a.); SearchSupplierBL.cs/SupplierAssetBL.cs implementieren Lieferantensuche und Lieferanten-Assets; EDI-Verzeichnisse (Alltron, ALSO, Komsa, Concerto) koppeln Distributoren an.
Aussage: Das System soll Lieferanten, Bestellungen und Lieferantenbelege getrennt rechtegeschützt führen und Lieferanten-Assets sowie Distributorenanbindungen unterstützen.
Ergebnis: Beschaffungsprozess von Lieferantenstamm bis Lieferantenrechnung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Accounts/AccountWebServiceBL.cs:1868 (Rechteprüfung RIGHT_LIEFERANTAENDERN vor Änderung) – prüfende Stelle
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/SupplierOrderReceiptSearchConfiguration.cs:138–140 (ShowRight/OnlyOwnBranchRight je Lieferantenbeleg) – durchgesetzte Sichtrechte
- [SEKUNDÄR] src/backend/Centron.BL/BusinessPartner/SearchSupplierBL.cs, SupplierAssetBL.cs – Lieferanten-Fachlogik
- [KONTEXT] src/backend/Centron.BL/EDI/ (Unterverzeichnisse Alltron, ALSO, Komsa, Concerto, Opentrans21) – Distributor-Kopplung
Prüfidee: Bestellung anlegen ohne Recht RIGHT_BESTELLUNGANLEGEN schlägt fehl (Recht in ReceiptWebServiceBL.cs:975 referenziert).
Tracelinks: StRS-010, SyRS-012, SwRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-010
Titel: Elektronischer Dokumentenaustausch mit Lieferanten/Distributoren (EDI)
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal: -
Akteur: Einkauf, System (automatisiert)
Vorbedingung: EDI-Gateway ist je Distributor konfiguriert (EDIGatewaySettingBL)
Fakt: BL/EDI enthält distributorsspezifische Verzeichnisse (Alltron, ALSO, AlsoCH, Concerto, EGIS, Komsa, Opentrans21, SupplierEDI, Zugferd) plus EDIDispatcherBL.cs (14 KB) als zentrale Steuerung und EDILogBL.cs zur Protokollierung.
Aussage: Das System soll Geschäftsdokumente (z. B. Bestellungen, Auftragsbestätigungen, Rechnungen) elektronisch und distributorsspezifisch austauschen und den Austausch protokollieren.
Ergebnis: Automatisierter, nachverfolgbarer Dokumentenverkehr ohne Medienbruch.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs (zentraler Dispatcher), EDILogBL.cs (Austausch-Protokoll), EDIGatewaySettingBL.cs (Gateway-Konfiguration) – umsetzende Klassen
- [SEKUNDÄR] Verzeichnisstruktur src/backend/Centron.BL/EDI/{Alltron,ALSO,AlsoCH,Concerto,EGIS,Komsa,Opentrans21,SupplierEDI,Zugferd} – je Partner ein Profil
Prüfidee: Ausgehende Bestellung erzeugt EDI-Nachricht im Profil des Lieferanten und einen EDILog-Eintrag.
Tracelinks: StRS-009, SyRS-012, SyRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Schnittstelle ins Zielsystem migrieren
Status: belegt
```
```
ID: StRS-011
Titel: Finanzprozesse: Zahlungseingänge, Online-Banking, Kassenbuch, Bankverbindungen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Buchhaltung
Vorbedingung: Offene Posten existieren; Bankkonto ist hinterlegt
Fakt: BL/Finances enthält IncomingPayments, Payments, OnlineBanking; BankAccountBL.cs:74–81 schützt Bankverbindungen durch eigene Rechte (CREATE_NEW_/EDIT_Bank_Account); Zahlungseingang und ZahlungseingangLog sind eigene Tabellen; Kassenbuch-Tabelle existiert; api-Projekt Centron.APIs.FinAPI koppelt Online-Banking.
Aussage: Das System soll Bankverbindungen, Zahlungseingänge samt Zuordnung/Protokoll und Kassenbuch führen und Online-Banking anbinden.
Ergebnis: Nachvollziehbare Zahlungszuordnung zu offenen Posten (OPOS-Anzeige ist rechtgesteuert, SHOW_CUSTOMER_OPOS).
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounting/BankAccountBL.cs:74–81 (Rechte vor Anlage/Änderung von Bankverbindungen) – prüfende Stelle
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Zahlungseingang, ZahlungseingangLog, Kassenbuch, Bankverbindungen, Mahnlauf – Finanz-Datenmodell
- [SEKUNDÄR] src/apis/Centron.APIs.FinAPI sowie WPF-Modul Modules/OnlineBanking – Online-Banking-Anbindung
- [KONTEXT] AccountWebServiceBL.cs:359–360 (SHOW_CUSTOMER_FINANCE, EDIT_LIMIT_CUSTOMER) – Finanzsicht-/Limitrechte
Prüfidee: Bankverbindung ohne EDIT-Recht nicht änderbar; Zahlungseingang erzeugt Logeintrag und reduziert OPOS.
Tracelinks: SyRS-016, SwRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Abrechnung)
Status: belegt
```
```
ID: StRS-012
Titel: IT-Asset-Management und Monitoring für betreute Kundenumgebungen (MSP)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: MSP-Techniker (Managed Service Provider)
Vorbedingung: Kundenumgebung wird durch Monitoring-Dienste erfasst
Fakt: Das DB-Schema enthält ca. 200 AssetManagement*-Tabellen (Geräte, AD-Benutzer/-Gruppen, Checks: Ping/SNMP/HTTP/SQL/Backup/SSL, DHCP-/DNS-/IIS-/Hyper-V-/Exchange-Details, Lizenzmanagement, Dokumentation, Notfallpläne) sowie MonitoringServiceSettings und AccountDevices; es existiert eine Gerätezuordnung zu Kunden und Tickets (AccountDevicesToTickets).
Aussage: Das System soll die IT-Infrastruktur von Kunden vollständig inventarisieren, überwachen (Checks) und die Bestände dokumentieren sowie mit Tickets verknüpfen.
Ergebnis: Aktueller Asset-Bestand mit Monitoring-Ergebnissen je Kunde.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AssetManagementDevices, AssetManagementChecks, AssetManagementCheckResults, MonitoringServiceSettings, AccountDevices, AccountDevicesToTickets – durchgesetztes Datenmodell
- [SEKUNDÄR] src/backend/Centron.BL/Integrations, src/backend/Centron.BL/RiverDivo – Integrationslogik (flach analysiert)
Prüfidee: Fehlgeschlagener Check (z. B. Ping) erzeugt CheckResult, der dem Gerät und Kunden zugeordnet ist.
Tracelinks: StRS-004, SyRS-030
Konsolidierung: Kandidat: StRS-004/SwRS-017 (Stammblatt/GeraeteKopf) – doppelte Geräte-Datenhaltung, im Zielsystem zu einem Asset-Konzept zusammenführen (vgl. Prompt-Beispiel Drucker „Stammblätter" vs. „Assets")
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-013
Titel: Webshop für Kunden der Anwender (WebAccount, Sonderpreise)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Endkunde (Web-Benutzer), Vertrieb
Vorbedingung: Web-Account ist im Adressstamm angelegt; Sonderpreise sind gepflegt
Fakt: README.md beschreibt: WebCart ist für Kunden der Kunden; Login als Web-Account (Anlage im Adressstamm); sichtbare Artikel stammen aus den „Sonderpreisen" des Kunden; Nexus enthält WebCart- und WebOffer-Bereiche; WebAccountBL.cs verwaltet Web-Zugänge (Recht WEBACCOUNT_MANAGEMENT).
Aussage: Das System soll Endkunden einen Web-Zugang bieten, über den sie kundenspezifische Artikel (Sonderpreise) sehen, in den Warenkorb legen, bestellen und Angebote einsehen können.
Ergebnis: Bestellungen/Angebotsanfragen aus dem Web landen im Belegwesen des ERP.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs:253/415/480 (Passwort-Handling von Web-Accounts), AccountWebServiceBL-Kontext Recht WEBACCOUNT_MANAGEMENT – Zugangsverwaltung
- [SEKUNDÄR] src/nexus/CentronNexus/WebCart, src/nexus/CentronNexus/WebOffer – Shop-/Angebotsbereiche der Web-App
- [KONTEXT] README.md, Abschnitt „WebCart" – fachliche Beschreibung des Shops (Sonderpreise als Artikelquelle)
Prüfidee: Web-Account sieht genau die Artikel seiner Sonderpreisliste; Bestellung erzeugt Beleg beim Mandanten.
Tracelinks: SyRS-010, SyRS-011, SwRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-014
Titel: Feingranulare Benutzer- und Rechteverwaltung
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal: -
Akteur: IT-Administrator
Vorbedingung: Administrator besitzt Administrationsrechte
Fakt: Rechte sind numerische Konstanten in UserRightsConst (hierarchisch: Sales.Customer.Helpdesk.*, Purchase.StockList.*, Administration.* u. a.); CentronRights.md dokumentiert sie fachlich inkl. „restricting rights"; die Durchsetzung erfolgt über AppRightsBL.HasUserRight/CheckRightsFromUser und API-Attribute; Administration-Skripte (ScriptMethod11783.cs) führen neue Rechte per Datenmigration ein.
Aussage: Das System soll ein feingranulares, je Benutzer zuweisbares Rechtemodell besitzen, das fachliche Operationen (Anzeigen/Anlegen/Ändern/Löschen je Objektart) und einschränkende Rechte abbildet und versionierbar erweitert wird.
Ergebnis: Jede geschützte Funktion ist nur mit zugewiesenem Recht ausführbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs (HasUserRight, CheckRightsFromUser, GetRightsFromCurrentUser) – zentrale Prüfstelle
- [PRIMÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11783.cs (Migration führt Recht „Seriennummer Hauptgerät am Stammblatt ändern" ein) – Rechte-Lebenszyklus
- [SEKUNDÄR] CentronRights.md – fachliche Rechtedokumentation
Prüfidee: Neu vergebenes Recht erscheint in Rechteverwaltung und öffnet ausschließlich die zugehörige Funktion.
Tracelinks: SyRS-002, SyRS-003, SyRS-004, SwRS-007, SwRS-008, SwRS-016
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-015
Titel: Berichte, Statistiken und Management-Informationen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Geschäftsführung, Controlling
Vorbedingung: Benutzer besitzt Statistik-/Reportrechte
Fakt: BL/Statistics enthält Verkaufs-, Ticket-, Einkaufs-, Mitarbeiter- und MSP-Statistiken, jeweils rechtgeschützt (Controlling.Finances.MANAGEMENT_INFO, Controlling.Analytics.*, teils filialbezogen); ReportEngine (ReportDataBL 94 KB, ReportGroupBL) stellt Berichtsgruppen inkl. Mapping auf Tabellen bereit (z. B. STAMMBLATT → GeraeteKopf).
Aussage: Das System soll betriebswirtschaftliche Auswertungen und konfigurierbare Berichte bereitstellen, deren Sichtbarkeit über Rechte und Filialzugehörigkeit gesteuert wird.
Ergebnis: Kennzahlen und Berichte gemäß Benutzerrechten.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Statistics/SaleStatistics/SaleStatisticBL.cs:54–60 (Rechte OFFER_/TICKET_STATISTIC, Filialfilter SHOW_ONLY_STATISTIC_FROM_OWN_BRANCH) – durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/ReportEngine/ReportGroupBL.cs:402 (Berichtsgruppe STAMMBLATT → Tabelle GeraeteKopf) – konkrete Zuordnung
- [SEKUNDÄR] src/backend/Centron.BL/Statistics/MspStatistics/MspStatisticBL.cs, CacheOrderStatisticsBL.cs usw. – Statistikbereiche
Prüfidee: Benutzer ohne MANAGEMENT_INFO erhält keine Management-Statistik; Filialbenutzer sieht nur eigene Filiale.
Tracelinks: StRS-002, SyRS-018
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Ergebnisse/SwRS.md
+739
View File
@@ -0,0 +1,739 @@
# SwRS – Software Requirements Specification (c-entron ERP, Reverse Engineering)
Normbezug: ISO/IEC/IEEE 29148:2018. Jede SwRS-Anforderung referenziert ihre SyRS-Anforderung; Kettentrace via `Traceability.md`.
---
```
ID: SwRS-001
Titel: Kopf-/Positions-Datenmodell je Belegart
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal: -
Akteur: Software (Persistenz)
Vorbedingung: Beleg wird gespeichert
Fakt: Jede Belegart besitzt eine Kopf- und eine Positions-Tabelle (AngKopf/AngPos, AufKopf/AufPos, LiefKopf/LiefPos, AbholKopf/AbholPos, RechKopf/RechPos, GutKopf/GutPos, AnfrKopf/AnfrPos, BestKopf2/BestPos2, VertragKopf/VertragPos, WareKopf/WarePos, LiGutKopf/LiGutPos, KalkKopf/KalkPos) – jeweils mit PRIMARY KEY (Schema enthält 1482 PRIMARY KEYs).
Aussage: Die Software soll Belege strukturell als Kopf mit beliebig vielen Positionen abbilden und je Belegart eigene Kopf-/Pos-Entitäten führen.
Ergebnis: Belegpositionen sind referenzierbar; Summen/Status kopfseitig, Artikelbezug positionsseitig.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE RechKopf (Zeile 3231), RechPos (12131), AufKopf (3016), AufPos (9681) u. a. – Schema-Struktur je Belegart
- [SEKUNDÄR] src/backend/Centron.Entities (Entity-Klassen je Tabelle) – Abbildung im Code
Prüfidee: Beleg mit 3 Positionen erzeugt 1 Kopf- und 3 Positionsdatensätze mit gemeinsamer Kopf-ID.
Tracelinks: SyRS-007, SyRS-019
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-002
Titel: Ticket-Datenmodell mit Stammdimensionen und Historie (hlpdsk_*)
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal: -
Akteur: Software (Persistenz)
Vorbedingung: Ticket wird angelegt/geändert
Fakt: Kerntabelle hlpdsk_requests; Dimensionen hlpdsk_typen, hlpdsk_kategorien, hlpdsk_prioritaeten, hlpdsk_status; Mehrfach-Bearbeiter hlpdsk_request_bearbeiter; hlpdsk_history hält Änderungsverlauf; hlpdsk_timer speichert Zeiten; CacheTicketStatistic puffert Statistik; NotifyHelpdeskHistory dokumentiert Benachrichtigungen.
Aussage: Die Software soll Tickets mit referenzierbaren Stammdaten (Typ, Kategorie, Priorität, Status), beliebig vielen Bearbeitern, Zeitdaten und Änderungshistorie führen.
Ergebnis: Lückenlose, auswertbare Historie je Ticket.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE hlpdsk_requests (:4521), hlpdsk_status (:4628), hlpdsk_history (:18680), hlpdsk_timer (:18452), hlpdsk_request_bearbeiter (:18981) – durchgesetztes Datenmodell
Prüfidee: Statuswechsel erzeugt Eintrag in hlpdsk_history mit altem/neuem Status.
Tracelinks: SyRS-007, StRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-003
Titel: Referenzielle Integrität überwiegend auf BL-Ebene (wenige FK-Constraints)
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Softwarearchitektur, Entwicklung
Vorbedingung: -
Fakt: Das Schema enthält 1535 Tabellen, 1482 PRIMARY KEYs, dagegen nur 134 Vorkommen von FOREIGN KEY (Zählung über Schema-Datei). Geschäftsregeln (z. B. „Stammblatt nicht löschbar bei aktivem Vertrag", MasterDataListBL.cs:163) werden in der BL durchgesetzt.
Aussage: [HYPOTHESE, risikorelevant für Migration] Die Software hat Referenzen zwischen Geschäftsobjekten bisher vorrangig in der Anwendungslogik statt per FK-Constraint abgesichert; im Zielsystem soll jede fachliche Referenz entweder per Constraint oder per nachweisbar zentralem Konsistenzdienst geschützt werden.
Ergebnis: Keine verwaisten Referenzen auch bei direkten DB-Zugriffen/Importen.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql – Zählung: 1535 CREATE TABLE, 1482 PRIMARY KEY, 134 FOREIGN KEY – quantitativer Nachweis
- [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:163 – beispielhafte BL-Konsistenzprüfung
- Es fehlt: systematische Katalogisierung aller BL-seitigen Konsistenzprüfungen (nur Stichproben) → HYPOTHESE
Prüfidee: Stichprobe: Löschen eines referenzierten Stammdatensatzes über rohe SQL ist möglich (Ist) – im Zielsystem wird es durch Constraint verhindert.
Tracelinks: SyRS-007
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Migrationsrisiko, in Zielarchitektur adressieren
Status: HYPOTHESE
```
```
ID: SwRS-004
Titel: Datenzugriffsschicht: DAOFactory, GenericDAO, Repositories, Named Queries, Stored Procedures
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal: Wartbarkeit
Akteur: Software-Komponenten
Vorbedingung: Session ist geöffnet (DAOSession)
Fakt: DAOFactory.cs (11 KB) erzeugt typspezifische DAOs; GenericDAO.cs (25 KB) und GenericStoredProcedureDAO.cs (20 KB) abstrahieren CRUD bzw. Prozeduraufrufe; AdoNETDataAccess sowie NamedQueries-Verzeichnis bedienen Spezialfälle; EventListener (TruncateStringsEventListener etc.) hängen in der NHibernate-Pipeline.
Aussage: Die Software soll Datenzugriffe ausschließlich über die DAO-Abstraktion führen (Generics für Standards, Repositories/Named Queries/Prozeduren für Spezialfälle), damit keine BL-Klasse rohe Verbindungen aufbaut.
Ergebnis: Austauschbare, testbare Zugriffsschicht.
Belege:
- [PRIMÄR] src/backend/Centron.DAO/{DAOFactory.cs, GenericDAO.cs, GenericStoredProcedureDAO.cs, DAOSession.cs} – Zugriffsarchitektur
- [SEKUNDÄR] src/backend/Centron.DAO/{AdoNETDataAccess/, NamedQueries/, Repositories/} – Spezialkanäle
Prüfidee: Code-Review/Architekturtest: keine ADO.NET-Verbindung außerhalb von Centron.DAO.
Tracelinks: SyRS-007
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – ORM im Zielsystem neu bewerten (EF Core)
Status: belegt
```
```
ID: SwRS-005
Titel: Zentrale Beleglogik (ReceiptBL) mit typspezifischen Spezialisierungen
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Software-Komponenten (Verkauf/Einkauf)
Vorbedingung: Belegoperation wird ausgeführt
Fakt: ReceiptBL.cs (623 KB) und ReceiptItemBL.cs (230 KB) enthalten die Belegkernlogik; IReceiptSpecificLogic.cs (26 KB) definiert die Schnittstelle, SpecificLogics.cs registriert typspezifische Implementierungen je Belegart; ReceiptProgressionBL.cs steuert Belegfortschreibung, ReceiptTemplateBL.cs Vorlagen, ReceiptCompleteReasonBL.cs Abschlussgründe.
Aussage: Die Software soll gemeinsame Beleglogik zentral halten und belegartspezifisches Verhalten über die Schnittstelle IReceiptSpecificLogic auslagern.
Ergebnis: Neue Belegarten werden durch Spezialisierung statt Kopie ergänzt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/{ReceiptBL.cs, IReceiptSpecificLogic.cs, SpecificLogics.cs} – zentrale Logik + Spezialisierungsmechanismus
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/{ReceiptProgressionBL.cs, ReceiptTemplateBL.cs, ReceiptCartBL.cs} – Nebenprozesse
Prüfidee: Belegart X nutzt gemeinsame Preis-/Steuerlogik, überschreibt aber Positionsvalidierung spezifisch.
Tracelinks: SyRS-019, SyRS-020, SyRS-021
Konsolidierung: Kandidat: Aufteilung der 623-KB-Klasse in fachliche Module im Zielsystem (God-Class-Antipattern)
Übernahmewürdigkeit: übernehmen – fachlich; strukturell refaktorisieren
Status: belegt
```
```
ID: SwRS-006
Titel: Suchkonfiguration je Belegart mit Rechte- und Branch-Properties
Ebene: SwRS
Typ: Daten/Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Software (Suchen/Listen)
Vorbedingung: Benutzer startet Belegsuche
Fakt: Je Belegart existiert eine Klasse im Verzeichnis ReceiptSearch mit Properties ShowRight, OnlyOwnRight, OnlyOwnBranchRight sowie SQL-Fragmenten (z. B. ContractReceiptSearchConfiguration.cs:95: „IsMasterDataList = Cast(AK.Stammblattbezogen AS bit)"); Lieferanten- und Kundenbelege besitzen getrennte Konfigurationsklassen.
Aussage: Die Software soll jede Belegsuche über eine Konfiguration aufbauen, die Sichtrechte, Einschränkungen und SQL-Auswahl je Belegart kapselt.
Ergebnis: Einheitliches, erweiterbares Rechte-/Filterverhalten aller Beleglisten.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/{InvoiceReceiptSearchConfiguration.cs:152–157, ContractReceiptSearchConfiguration.cs:95/:168–173} – durchgesetzte Such-Rechte
- [SEKUNDÄR] Weitere Konfigurationen: Offer/Order/DeliveryList/PickupList/CreditVoucher/Supplier* in demselben Verzeichnis – wiederholtes Muster
Prüfidee: Neue Belegart erhält Konfiguration; Suche filtert automatisch nach OnlyOwnBranch.
Tracelinks: SyRS-004
Konsolidierung: Kandidat: 14 nahezu identische Konfigurationsklassen – im Zielsystem als generische, deklarative Belegtyp-Definition führen
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-007
Titel: Zentrale Rechteprüfungs-API (AppRightsBL)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Software-Komponenten
Vorbedingung: Aktueller Benutzerkontext liegt vor
Fakt: AppRightsBL (src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs) bietet HasUserRight(userI3D, rightI3D), CheckRightsFromUser(userI3D, params rightIds) und GetRightsFromCurrentUser; Aufrufe erfolgen flächendeckend aus BL- und WebServiceBL-Klassen.
Aussage: Die Software soll Rechte ausschließlich über diese zentrale API ermitteln und prüfen (ein Recht, Rechtemenge oder komplettes Rechteprofil).
Ergebnis: Einheitliche Rechteauswertung; keine verstreuten Eigenimplementierungen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:25 – Klassendefinition der zentralen Prüf-API
- [KONTEXT] Aufrufnachweise u. a. in AccountBL.cs:282, PasswordManagerBL.cs:899, RmmConnectionSettingsWebServiceBL.cs:30
Prüfidee: HasUserRight liefert für fehlendes Recht false; CheckRightsFromUser liefert exakt die Teilmenge vorhandener Rechte.
Tracelinks: SyRS-003, SyRS-004
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-008
Titel: Rechte als versionierte, hierarchische Konstanten (UserRightsConst)
Ebene: SwRS
Typ: Daten/Sicherheit
Qualitätsmerkmal: Wartbarkeit
Akteur: Entwicklung, Administration
Vorbedingung: Neues Feature benötigt neues Recht
Fakt: Rechte sind int-Konstanten in einer verschachtelten Konstantenstruktur (UserRightsConst.Sales.Customer.Helpdesk...; Purchase.StockList...; Administration...; Logistic.Commissioning...); neue Rechte werden per Datenmigrationsskript eingeführt (ScriptMethod11783.cs legt das Recht „Seriennummer Hauptgerät am Stammblatt ändern" mit deutscher Bezeichnung und Beschreibung an).
Aussage: Die Software soll Rechte als stabile numerische IDs in einer fachlich gruppierten Konstantenstruktur führen und neue Rechte über versionierte Migrationen einführen.
Ergebnis: Rechtekatalog ist erweiterbar, referenzierbar und historisch nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11783.cs (Anlage eines neuen Rechts via Migration) – Einführungsprozess
- [SEKUNDÄR] CentronRights.md – fachliche Dokumentation einzelner IDs
Prüfidee: Migrationsskript ausführen → Recht erscheint in der Rechteverwaltung mit Text und Gruppe.
Tracelinks: SyRS-003, SwRS-016
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-009
Titel: Rechte-Durchsetzung im Helpdesk (HelpdeskBL)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Software-Komponenten (Helpdesk)
Vorbedingung: Ticketoperation wird angestoßen
Fakt: HelpdeskBL.cs prüft vor Ausführung: Sichtrechte (SHOW_HELPDESK, ONLY_OWN, ONLY_OWN_BRANCH, Zeilen 271–284), Anlegen (ADD_NEW_HELPDESK:422), Bearbeiten (EDIT_HELPDESK:428), Abschluss (CLOSE_REQUEST:435), Fälligkeit (MATURITY_CHANGE:445) sowie Zuweisungsbegrenzung auf eigene Abteilung (ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS:454).
Aussage: Die Software soll jede Ticket-Zustandsänderung (ansehen, anlegen, bearbeiten, fällig machen, zuweisen, abschließen) vorab gegen das jeweils zugeordnete Recht prüfen.
Ergebnis: Ticketbearbeitung entlang des definierten Rechtekatalogs.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284, :422–454 – durchsetzende Stellen je Operation
- [KONTEXT] CentronRights.md, Abschnitt Helpdesk – fachliche Zuordnung
Prüfidee: Jede der sechs Operationen wird ohne zugehöriges Recht abgelehnt.
Tracelinks: SyRS-003, SyRS-004, StRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
Status: belegt
```
```
ID: SwRS-010
Titel: CRUD-Rechte für Kunden/Adressen/Kontakte (AccountBL, AccountAddressBL, AccountAddressContactBL)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Software-Komponenten (CRM)
Vorbedingung: Stammdatenoperation wird angestoßen
Fakt: AccountBL.cs:1305–1365 prüft CREATE_/EDIT_/DELETE_/SEARCH_CUSTOMER und UNLOCK_CUSTOMER; AccountAddressBL.cs:259–317 trennt CREATE_ADDRESS, EDIT_LOCATION, EDIT_CUSTOMER, Sprach-/Währungsänderung (EDIT_CUSTOMER_ADDRESS_LANGUAGE/-CURRENCY); AccountAddressContactBL.cs:379–413 unterscheidet Kunden- und Lieferantenkontakte (RIGHT_LIEFERANT...); AccountWebServiceBL.cs aggregiert dieselben Rechte für UI-Flags.
Aussage: Die Software soll jede Änderung an Geschäftspartnerstammdaten feld-/operationsscharf gegen Rechte prüfen und die Benutzeroberfläche anhand derselben Rechtemenge steuern.
Ergebnis: Kein unautorisierter Stammdaten-Write; UI zeigt nur erlaubte Aktionen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountAddressBL.cs:259–317 (je Änderungsart eigene Prüfung) – durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountAddressContactBL.cs:389–413 (Rollentrennung Kunde/Lieferant) – konkrete Bedingungen
Prüfidee: Währungsänderung ohne EDIT_CUSTOMER_ADDRESS_CURRENCY schlägt fehl, sonstige Felder bleiben speicherbar.
Tracelinks: SyRS-003, StRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
Status: belegt
```
```
ID: SwRS-011
Titel: Abrechnungsservice für Verträge (AutomaticFacturaWebServiceBL)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Software (Abrechnungslauf)
Vorbedingung: Verträge mit Abrechnungszeitraum vorhanden
Fakt: AutomaticFacturaWebServiceBL.cs stellt u. a. bereit: SearchBillingContractPos(:124) zur Ermittlung abrechenbarer Vertragspositionen, LoadBillingResult(dtFrom, dtTo, contractI3Ds) (:2370) für das Abrechnungsergebnis, GetContractPartibleArticlePositionen(:2376) für teilbare Artikel sowie Massenzuordnung von Sonderartikeln zu Verträgen (:894, :899, :904, :923); Zählerstände des Vorgänger-Stammblatts fließen in die Abrechnung ein (:1421).
Aussage: Die Software soll aus Verträgen periodische Abrechnungspositionen deterministisch ermitteln (Zeitraum, teilbare Artikel, Zählerstandsdifferenzen) und als Abrechnungsergebnis bereitstellen.
Ergebnis: Reproduzierbares Abrechnungsergebnis je Vertrag und Periode.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, Methoden laut Zeilenangaben – durchsetzende Abrechnungslogik
Prüfidee: Zweimaliger Lauf mit identischen Parametern liefert identisches BillingResult (Determinismus).
Tracelinks: SyRS-019, StRS-005
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Abrechnung)
Status: belegt
```
```
ID: SwRS-012
Titel: Passwort-Hashing mit SHA1 (Sicherheits-Migrationsfall)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Software (Authentifizierung)
Vorbedingung: Passwort wird gesetzt oder geprüft
Fakt: Passwörter werden über SHA1Decoder.GetDecodedSHA1String gehasht – in UsersBL.cs:65/:88/:107 (Benutzer), WebAccountBL.cs:56/:192/:415/:480 (Web-Accounts) und BasicAuthenticator.cs:46 (Login-Vergleich). Gerätezugänge nutzen CryptoUtils.CreatePasswordHash (TicketBL.cs:169).
Aussage: Die Software soll Passwort-Hashing auf ein modernes, gesalzenes, rechenintensives Verfahren (z. B. Argon2/bcrypt/PBKDF2) umstellen; beim ersten erfolgreichen Login mit Alt-Hash soll transparent neu gehasht werden.
Ergebnis: Gespeicherte Passwort-Artefakte sind auch bei Datenabfluss nicht praktikabel rückrechenbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/UsersBL.cs:65/:88/:107; src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs:56/:192/:415/:480; src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs:46 – konkrete Hash-Aufrufe
Prüfidee: Bestandsnutzer kann sich weiter anmelden (Alt-Hash-Verifikation); danach liegt neuer Hash im modernen Format vor.
Tracelinks: SyRS-005, SyRS-011
Konsolidierung: nein
Übernahmewürdigkeit: veraltet – SHA1 gilt als kryptografisch gebrochen; Funktion ersetzen, Migration der Hashes planen
Status: belegt
```
```
ID: SwRS-013
Titel: Zentraler Login-Dispatcher mit Fehlversuchs-Logging (Authenticator)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Software (Authentifizierung)
Vorbedingung: Login-Request liegt vor
Fakt: Authenticator.cs wählt anhand der Konfiguration das Verfahren und ruft intern AuthenticateUser (Zeilen 106–109); erfolglose Anmeldungen werden geloggt (Zeile 161: „c-entron Login failed. No c-entron user with username and password hash was found.").
Aussage: Die Software soll Authentifizierungsverfahren über eine zentrale Komponente dispatchen und jeden Fehlversuch mit Benutzername/Grund (ohne Passwort) protokollieren.
Ergebnis: Auffällige Anmeldeserien sind auswertbar; Verfahrenswechsel ohne Code-Änderung an Aufrufern.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:106–109/:161 – Dispatcher + Logging
Prüfidee: Drei Fehlversuche erzeugen drei unabhängige Logeinträge mit Zeitstempel und Benutzername.
Tracelinks: SyRS-005
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-014
Titel: TOTP-2FA-Verwaltung und -Validierung (TwoFactorAuthenticationBL)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Software (Authentifizierung)
Vorbedingung: Benutzer initiiert 2FA-geschützten Vorgang
Fakt: Drei Operationen: AppUserTwoFactorAuthKeyExists (prüft Vorhandensein), UpdateAppUserTwoFactorAuthKey (Named Query PasswordManager.UpdateAppUserTwoFactorAuthKey setzt Schlüssel je Benutzer), ValidateAuthenticationPin (holt Schlüssel via GetAppUserTwoFactorAuthKey, validiert via TwoFactorAuthenticator.ValidatePin; fachliche Fehlermeldungen bei fehlendem Schlüssel bzw. falscher PIN).
Aussage: Die Software soll TOTP-Schlüssel je Benutzer verwalten und PINs serverseitig validieren, mit klar getrennten Fehlerfällen (kein Schlüssel vs. falsche PIN).
Ergebnis: Zwei-Faktor-Prozess technisch durchsetzbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, Methoden ValidateAuthenticationPin/UpdateAppUserTwoFactorAuthKey/AppUserTwoFactorAuthKeyExists – vollständig gelesen
Prüfidee: PIN aus Authenticator-App mit identischem Secret → Erfolg; manipulierte PIN → Fehler „Die eingegebene PIN ist ungültig!".
Tracelinks: SyRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-015
Titel: Deklarative Rechte-Attribute für API-Controller
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Wartbarkeit/Sicherheit
Akteur: Software (API), Entwicklung
Vorbedingung: Neuer geschützter Endpunkt wird implementiert
Fakt: AuthorizeUserRightAttribute, AuthorizeAnyUserRightAttribute, AuthorizeAllUserRightsAttribute (je ~1,7–2 KB) kapseln die Prüfung als Authorization-Filter; AuthorizeCentronHostedAttribute/:CentronHostedAuthorization schränkt auf die gehostete Umgebung ein; README empfiehlt: komplexe fachliche Regeln bleiben in WebServiceBL, einfache Checks deklarativ.
Aussage: Die Software soll einfache Rechteprüfungen deklarativ an Controllern/Actions kennzeichnen und fachlich komplexe Prüfungen weiterhin in der Fachlogikschicht führen.
Ergebnis: Einheitliches, prüfbares Autorisierungsmuster ohne Codeduplikate.
Belege:
- [PRIMÄR] src/webservice/Centron.Controllers/Authorization/{AuthorizeUserRightAttribute.cs, AuthorizeAnyUserRightAttribute.cs, AuthorizeAllUserRightsAttribute.cs, CentronHostedAuthorization.cs} – Filterimplementierung
- [KONTEXT] src/webservice/Centron.Controllers/Authorization/README.md – Architekturleitlinie
Prüfidee: Controller-Methode mit [AuthorizeAllUserRights(A,B)] → Zugriff nur bei beiden Rechten.
Tracelinks: SyRS-002, SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-016
Titel: Datenbank-Migrationen als versionierte C#-Skriptklassen (ScriptMethods)
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: System (Update-Prozess), Entwicklung
Vorbedingung: Softwareupdate wird eingespielt
Fakt: Unter Administration/Scripts/ScriptMethods/Scripts liegen numerierte Klassen (z. B. ScriptMethod11125.cs–ScriptMethod11799.cs), die SQL-DDL/-DML als eingebettete Statements enthalten (u. a. Fallunterscheidungen zu Stammblattbezogen/KontingentVertrag) und Rechte/Stammdaten nachziehen (ScriptMethod11783.cs).
Aussage: Die Software soll Schema- und Stammdatenänderungen ausschließlich über einmalig ausgeführte, numerisch versionierte Migrationsskripte einspielen (identifizierbar, protokollierbar).
Ergebnis: Reproduzierbarer Datenbestand über Installationen hinweg.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11125.cs u. a. (nummerierte Skriptklassen mit SQL) – Migrationsmechanismus
- [SEKUNDÄR] ScriptMethod11783.cs (Rechte-Stammdaten-Migration) – Beispiel
Prüfidee: Mehrfaches Ausführen derselben ScriptMethod verändert den Bestand nicht erneut (Idempotenz-SQL im Skript stichprobenartig zu verifizieren).
Tracelinks: SyRS-007, SwRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Konzept; im Zielsystem durch Migrations-Framework ersetzen
Status: belegt
```
```
ID: SwRS-017
Titel: Stammblatt-Fachregeln (MasterDataListBL)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Software (Service/Verträge)
Vorbedingung: Stammblatt (GeraeteKopf) wird bearbeitet
Fakt: MasterDataListBL.cs verhindert Löschen bei aktivem Vertrag (:163, DependencyCheckFailed); Entfernen/Ersetzen der Hauptgeräte-Seriennummer läuft über eigene Methoden mit Fehlerfällen „kein Stammblatt gefunden", „keine Seriennummer", „keine Hauptposition" (:294–:305); Barcode-Ablösung setzt DeviceHeadNumber/DevicePositionI3D zurück (Kommentar :425); Änderung schreibt Historieneintrag (:410); ein Stammblatt ohne Kundenbezug ist unzulässig (:895).
Aussage: Die Software soll den Lebenszyklus von Stammblättern (Gerätestammsätzen) absichern: Vertragsbindung verhindert Löschung, Seriennummernwechsel ist historisiert und erfordert gültige Ausgangsdaten, Kundenzuordnung ist Pflicht.
Ergebnis: Konsistente Gerätestammdaten mit Verlauf.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:163, :294–305, :425, :895 – konkrete Prüfregeln
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/MasterDataLists/MasterDataListWebServiceBL.cs:172–188 (Seriennummernwechsel nur mit Recht CHANGE_MAIN_DEVICE_SERIAL_NUMBER) – Rechtebindung
Prüfidee: Löschversuch bei aktivem Vertrag → Fehler DependencyCheckFailed; Serienwechsel ohne Recht → Fehlermeldung mit RightCheckFailed.
Tracelinks: SyRS-019, StRS-004
Konsolidierung: Kandidat: SyRS-030/StRS-012 (AssetManagement) – zwei Gerätemodelle zusammenführen
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-018
Titel: Seriennummern-Zustandsautomaten beim Umbuchen (BarcodeBL)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Lager, Software
Vorbedingung: Seriennummer existiert und hat einen Zustand (BarcodeState)
Fakt: BarcodeBL.cs:1091 lehnt die Umbuchung einer Seriennummer auf ein Stammblatt ab, wenn die Seriennummer nicht „im Lager" ist (Fehlertext mit Seriennummer); BarcodeState kennt u. a. „in Stammblatt" (BarcodeState.cs:19, Mapping in BarCode.cs:100); ReceiptItemBL.cs:314 verhindert doppelte Verwendung eines Stammblatts in Belegen („Stammblatt ist bereits in ... enthalten").
Aussage: Die Software soll Seriennummern zustandsbasiert führen und Zustandsübergänge (Lager ↔ Beleg ↔ Stammblatt) nur entlang zulässiger Regeln zulassen; Doppelverwendung wird verhindert.
Ergebnis: Keine widersprüchlichen Seriennummern-Positionen im System.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/BarcodeBL.cs:1091 (Zustandsprüfung vor Umbuchung) – konkrete Bedingung
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptItemBL.cs:314 (Doppelverwendungs-Prüfung) – konkrete Bedingung
- [SEKUNDÄR] src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs:19 – Zustandsdefinition
Prüfidee: Seriennummer im Zustand „in Stammblatt" kann nicht erneut ausgebucht werden; Umbuchung greift nur aus „im Lager".
Tracelinks: SyRS-019, StRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-019
Titel: Rechte- und Regelschutz der Lagerverwaltung (ArticleBL, InventoryBL, OrderCommissionBL)
Ebene: SwRS
Typ: Sicherheit/funktional
Qualitätsmerkmal: Sicherheit
Akteur: Software (Warenwirtschaft)
Vorbedingung: Lageroperation wird angestoßen
Fakt: ArticleBL.cs:999–1081 prüft STORE_ARTICLE, CREATE_NEW_ARTICLE, CHANGE_ARTICLE_PRICE, CHANGE_SERIALNUMBER_REQUIRED_FLAG (Flag-Änderung nur bei Berechtigung, :1035), EDIT_MaterialGroup und NOT_CHANGEABLE_ARTICLE_PROPERTIES (Sperrliste); SecondStockArticleBL.cs:108–111 verlangt TRANSFER_STOCK für Nebenlager-Umbuchung; InventoryBL.cs:77/:100/:198/:575/:963 erzwingt Inventurrechte; OrderCommissionBL.cs:431–438 und PartialCommissionOrderBL.cs:135/:170/:426/:453 setzen Kommissionierrechte.
Aussage: Die Software soll Lagerbewegungen, Preisänderungen, Stammdaten-Sperrfelder, Inventuren und (Teil-)Kommissionierungen jeweils gegen das zugeordnete Recht prüfen und den Zugriff sonst verweigern.
Ergebnis: Revisionssichere Lagerprozesse.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/ArticleBL.cs:1035 (Seriennummern-Pflichtflag gegen Recht) – konkrete Durchsetzung
- [PRIMÄR] src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs:77/:100 – Inventur anlegen/verwerfen nur mit Recht
- [PRIMÄR] src/backend/Centron.BL/Warehousing/Commissions/PartialCommissionOrderBL.cs:135/:170 – Teilkommission Create/Delete nur mit Recht
Prüfidee: Negativbuchung ohne BOOK_ARTICLE_STOCK_INTO_NEGATIVE scheitert; Inventurverwerfen ohne DROP_INVENTORY scheitert.
Tracelinks: SyRS-003, StRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
Status: belegt
```
```
ID: SwRS-020
Titel: Wiedervorlagen und Fremd-ToDo-Rechte (ToDoBL)
Ebene: SwRS
Typ: funktional/Sicherheit
Qualitätsmerkmal: -
Akteur: Anwender
Vorbedingung: ToDo/Wiedervorlage existiert
Fakt: ToDoBL.cs hält Objektarten je Fachobjekt (u. a. Wiedervorlage Geräte/Stammblatt AssetKind 11, Zeilen 86/:161); RIGHT_FREMDTODOLISTE erlaubt Zugriff auf ToDos anderer Benutzer (:1993), RIGHT_FREMDTODOLISTEVERWERFEN deren Verwerfen (:310, mit Code-Kommentar zur Grundsatzfrage).
Aussage: Die Software soll Aufgaben/Wiedervorlagen objekttypisiert führen und den Zugriff auf fremde Aufgabenlisten sowie deren Verwerfen nur mit gesonderten Rechten erlauben.
Ergebnis: Datenschutzkonforme Aufgabentrennung mit Steuerungsrechten.
Belege:
- [PRIMÄR] src/backend/Centron.BL/ToDoArea/ToDoBL.cs:310, :1993 (Rechteprüfungen) – durchsetzende Stellen
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ToDoListe – Datenanker
Prüfidee: Ohne RIGHT_FREMDTODOLISTE sind fremde ToDos weder sicht- noch verwerfbar.
Tracelinks: SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-021
Titel: Checklisten-Verwaltung und -Verarbeitung (CentronChecklistBL)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Servicetechniker, Qualitätsmanagement
Vorbedingung: Checklistenvorlage existiert
Fakt: CentronChecklistBL.cs (19 KB) und UpdateChecklistBL.cs verwalten Checklisten; Rechte unterscheiden Vorlagen anlegen/bearbeiten, Checklisten bearbeiten und Bearbeiter einzelner Punkte ändern (CREATE_NEW_CHECKLIST_TEMPLATES, EDIT_CHECKLIST_TEMPLATES, EDIT_CHECKLISTS, EDIT_CHECKLIST_ITEM_EDITOR); der Webservice umgeht Einzelprüfungen für Admins (CentronChecklistWebserviceBL.cs:160–162).
Aussage: Die Software soll Checklisten aus Vorlagen instanziieren, Punkte einzelnen Bearbeitern zuweisen und Bearbeitungsstände rechtgeschützt pflegen.
Ergebnis: Nachvollziehbar abgearbeitete Prüf-/Arbeitslisten je Vorgang.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/CheckListArea/CentronChecklistWebserviceBL.cs:160–162 (Admin-Ausnahme + Recht EDIT_CHECKLIST_ITEM_EDITOR) – durchsetzende Stelle
- [SEKUNDÄR] src/backend/Centron.BL/CheckListArea/{CentronChecklistBL.cs, UpdateChecklistBL.cs} – Fachlogik
- [KONTEXT] CentronRights.md, Abschnitt 16 (Checklisten-Rechte) – Katalog
Prüfidee: Bearbeiterwechsel an einem Checklistenpunkt ohne EDIT_CHECKLIST_ITEM_EDITOR schlägt fehl (außer Admin).
Tracelinks: SyRS-003, StRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-022
Titel: Produktionsaufträge mit Arbeitsschritten und Zeiterfassung
Ebene: SwRS
Typ: funktional/Daten
Qualitätsmerkmal: -
Akteur: Produktionsmitarbeiter
Vorbedingung: Fertigungsartikel mit Produktionsschritten ist angelegt
Fakt: ProductionBL.cs (13 KB) und ProductionOrderBL.cs (9 KB) bilden die BL; das Schema führt ArticleProductionOrders, ArticleProductionStep(s), ArticleProductionOrderStepItems, ArticleProductionMaterials sowie Zeitdaten (ArticleProductionOrderStepItemTimes, ...TimeDataRecordings) und Arbeitspläne (Arbeitsplan*, Arbeitsschritt*); der Nexus-Bereich ProductionOrderManagement stellt eine Web-Oberfläche.
Aussage: Die Software soll Produktionsaufträge aus Arbeitsplänen erzeugen, Material- und Arbeitsschritte je Position führen und Zeitdaten je Schritt erfassen.
Ergebnis: Auswertbare Produktionszeiten und -fortschritte je Auftrag.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ArticleProductionOrders (:20517), ArticleProductionStep (:20496), ArticleProductionOrderStepItemTimes (:26066) – Datenmodell
- [SEKUNDÄR] src/backend/Centron.BL/Production/{ProductionBL.cs, ProductionOrderBL.cs}; src/nexus/CentronNexus/ProductionOrderManagement/ – Logik/Oberfläche
Prüfidee: Produktionsauftrag enthält alle Arbeitsplang-Schritte; gebuchte Zeit ist Schritt zuordenbar.
Tracelinks: SyRS-010, StRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-023
Titel: Lagerorte/Lagerplätze und Nebenlager (StorageBL)
Ebene: SwRS
Typ: Daten/funktional
Qualitätsmerkmal: -
Akteur: Lager
Vorbedingung: Artikel ist lagerpflichtig
Fakt: StorageBL.cs (45 KB) verwaltet Lagerorte/-plätze (Tabellen Lagerort, Lagerplatz); SecondStockArticleBL (Nebenlager) verlangt für Umbuchungen TRANSFER_STOCK; das Schema kennt NebenlagerArtikel; InventoryArticlePool.cs definiert Inventur-Pools.
Aussage: Die Software soll Bestände je Lagerort/Lagerplatz führen, Nebenlager unterstützen und Umbuchungen zwischen Lagern rechtegeschützt buchen.
Ergebnis: Ortsscharfe Bestandsführung über Haupt- und Nebenlager.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Storage/StorageBL.cs – Lagerortlogik (flach analysiert)
- [PRIMÄR] src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs:108–111 (TRANSFER_STOCK-Prüfung) – Rechte-Durchsetzung Nebenlager
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Lagerort, Lagerplatz, NebenlagerArtikel – Datenmodell
Prüfidee: Umbuchung Hauptlager→Nebenlager ohne TRANSFER_STOCK schlägt fehl; Bestand ist je Lagerort getrennt ausgewiesen.
Tracelinks: SyRS-003, StRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-024
Titel: RMA-Prozess (RmaBL)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Service/Disposition
Vorbedingung: Ware soll retourniert werden
Fakt: RmaBL.cs (110 KB) ist eine eigene Geschäftslogik; Kerntabelle Rma plus Versandart (RmaSendKindBL); BL/CustomerArea enthält zudem Kunden-Prozesse wie Interessen (InterestBL) und Produktzuordnung (ProductBL).
Aussage: Die Software soll Retouren (RMA) als eigenen Vorgangstyp mit eigener Versandart-Steuerung führen und an Kundenvorgänge koppeln.
Ergebnis: Nachverfolgbare Retourenabwicklung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs, RmaSendKindBL.cs – implementierte Prozesslogik
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Rma (:4145) – Datenmodell
Prüfidee: RMA-Vorgang trägt Kunde, Artikel/Bezug und Versandart; Zustandswechsel ist dokumentiert.
Tracelinks: StRS-003, StRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Prozessdetails in Folgeiteration vertiefen
Status: belegt
```
```
ID: SwRS-025
Titel: Projekt-, Prozess- und Ereignissteuerung (ProcessBL, ProjectBL, TicketProjectBL, ExpectedEventsBL)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Projektleiter, Organisation
Vorbedingung: Projekt/Prozessdefinition existiert
Fakt: ProcessBL.cs (28 KB) implementiert Prozesslogik; ProjectBL.cs (klein) und TicketProjectBL.cs (10 KB) koppeln Projekte an Tickets; ExpectedEventsBL.cs (10 KB) verwaltet erwartete Ereignisse; Schema enthält CRMProjekt/CRMProjektObjekt.
Aussage: Die Software soll Geschäftsprozesse und Projekte (inkl. Ticket-Projekt-Zuordnung und erwarteter Ereignisse) als eigenständige, referenzierbare Objekte führen.
Ergebnis: Projekte bündeln Tickets/Belege; Ereignissteuerung liefert Folgeaktionen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Processes/ProcessBL.cs; Projects/ProjectBL.cs; TicketProjects/TicketProjectBL.cs; ExpectedEvents/ExpectedEventsBL.cs – Modulklassen (flach analysiert)
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE CRMProjekt (:20116), CRMProjektObjekt – Datenmodell
Prüfidee: Projekt aggregiert zugeordnete Tickets und Objekte in einer Sicht.
Tracelinks: StRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-026
Titel: Ticket-Ansichten (Views) global vs. benutzerbezogen (NexusTicketViewWebServiceBL)
Ebene: SwRS
Typ: funktional/Sicherheit
Qualitätsmerkmal: -
Akteur: Helpdesk-Anwender
Vorbedingung: Ticketliste wird konfiguriert
Fakt: NexusTicketViewWebServiceBL.cs erfordert für das Anlegen/Ändern/Löschen globaler Ansichten das Recht Administration.EDIT_GLOBAL_PROFILES (:44, :66, :76, :88, :105, :124); private Ansichten sind davon ausgenommen.
Aussage: Die Software soll gespeicherte Ticket-Ansichten (Filter/Sortierungen) benutzerbezogen und global unterscheiden und globale Ansichten nur durch Berechtigte verwalten lassen.
Ergebnis: Standardisierte Arbeitsoberflächen im Helpdesk ohne unkontrollierte globale Änderungen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/NexusTicketViews/NexusTicketViewWebServiceBL.cs:44–124 (Rechteprüfung je globalem Vorgang) – durchsetzende Stelle
Prüfidee: Globale Ansicht ohne EDIT_GLOBAL_PROFILES kann nicht gespeichert werden; private Ansicht jederzeit.
Tracelinks: SyRS-003, StRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-027
Titel: Textbausteine und Anrede-/Einverständnis-Variablenersetzung (TextModuleBL)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Anwender (Schreibverkehr)
Vorbedingung: Textbaustein/Platzhalter ist definiert
Fakt: TextModuleBL.cs (30 KB) verwaltet Textbausteine; SalutationAndAgreementReplacementBL.cs (19 KB) ersetzt Anrede- und Einverständnis-Variablen; Schema führt GeschaeftspartnerTextbausteine; die Mail-Verarbeitung besitzt ein separates VariableReplacement-Verzeichnis – Platzhalterlogik existiert an mehreren Stellen.
Aussage: Die Software soll wiederkehrende Texte als Bausteine verwalten und Platzhalter (Anrede, Einverständniserklärung u. a.) kontextabhängig befüllen.
Ergebnis: Konsistente, personalisierte Dokumente und Mails.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/TextModuleArea/{TextModuleBL.cs, SalutationAndAgreementReplacementBL.cs} – Baustein-/Ersetzungslogik
- [SEKUNDÄR] src/backend/Centron.BL/Mail/VariableReplacement/ – zweite Ersetzungsimplementierung
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE GeschaeftspartnerTextbausteine – Datenanker
Prüfidee: Dokument mit Anrede-Platzhalter wird mit anredekonformem Text an den Belegempfänger gerendert.
Tracelinks: SyRS-023, SyRS-018
Konsolidierung: Kandidat: Platzhalter-/Ersetzungslogik an mehreren Stellen (TextModuleArea vs. Mail/VariableReplacement vs. ReportEngine ReplacementBLs) – im Zielsystem zentralisieren
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-028
Titel: Schutz vor Datenbank-Längenüberschreitungen auf ORM-Ebene
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Software (Persistenz)
Vorbedingung: Entität mit String-Feldern wird gespeichert
Fakt: TruncateStringsEventListener.cs und StringOrBinaryDataWouldBeTruncatedEventListener.cs sind NHibernate-Event-Listener: Einer kürzt zu lange Strings, der andere fängt den SQL-Fehler „String or binary data would be truncated" ab/erweitert Diagnose; WhyIsMyEntityUpdatedEventListener.cs unterstützt die Fehlersuche bei unerwarteten Updates.
Aussage: Die Software soll Zeichenketten vor dem Speichern auf die Spaltenlänge begrenzen bzw. Truncation-Fehler diagnosesicher behandeln, statt mit generischem SQL-Error abzustürzen.
Ergebnis: Keine unkontrollierten Speicherabbrüche durch zu lange Eingaben; Diagnose im Fehlerfall.
Belege:
- [PRIMÄR] src/backend/Centron.DAO/{TruncateStringsEventListener.cs, StringOrBinaryDataWouldBeTruncatedEventListener.cs} – technische Durchsetzung in der Persistenzpipeline
Prüfidee: 300-Zeichen-Text in 255er-Spalte wird gekürzt gespeichert bzw. liefert Fehler mit Feld/Tabellenangabe.
Tracelinks: SyRS-007
Konsolidierung: nein
Übernahmewürdigkeit: Workaround – kürzen statt validieren maskiert Eingabefehler; im Zielsystem durch Eingabevalidierung ersetzen
Status: belegt
```
```
ID: SwRS-029
Titel: Objekttypen-Katalog und externe Referenzen (CentronObjectKindNumeric, ObjectExternalReferences)
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal: Wartbarkeit
Akteur: Software-Komponenten
Vorbedingung: Verknüpfung zwischen Objekten oder zu externen Systemen wird angelegt
Fakt: CentronObjectKindNumeric.cs bildet Objektarten numerisch ab (z. B. MasterDataListClass → „Stammblatt", :314); ToDo- und Rechteprüfungen referenzieren dieselben Konstanten; BL/ObjectExternalReferences kapselt Fremdschlüssel zu externen Systemen.
Aussage: Die Software soll Geschäftsobjektarten über einen zentralen numerischen Katalog identifizieren und externe Referenzen (Drittsystem-IDs) getrennt führen.
Ergebnis: Typsichere Objektverknüpfungen und nachverfolgbare Fremdbezüge.
Belege:
- [SEKUNDÄR] src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs (:314) – Objektarten-Katalog
- [SEKUNDÄR] src/backend/Centron.BL/ObjectExternalReferences/ – Fremdschlüssel-Verwaltung (flach analysiert)
Prüfidee: Fremdschlüssel eines Drittsystems ist dem internen Objekt einschließlich Objektart eindeutig zugeordnet.
Tracelinks: SyRS-007, SyRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-030
Titel: RADIUS-basierte Zwei-Faktor-Authentifizierung im Login-Fluss
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Benutzer, Software
Vorbedingung: RADIUS-Server ist konfiguriert; Benutzer hat RADIUS-2FA aktiviert
Fakt: Unter Administration/Logins/TwoFactor existieren RadiusClient.cs, RadiusPaketParser.cs (RFC-konforme Paketbehandlung: SharedSecret, Request/Response-Authenticator via MD5/HMACMD5, Password-Decrypt/-Encrypt) und EmailTwoFactorValidator.cs. Die Einbindung in den Authenticator-Loginpfad wurde nicht festgestellt.
Aussage: [HYPOTHESE] Die Software soll als Alternative zur TOTP-2FA (SwRS-014) auch RADIUS-/E-Mail-basierte Zweitfaktoren unterstützen.
Ergebnis: Unternehmen mit bestehender RADIUS-Infrastruktur können 2FA zentral betreiben.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/{RadiusClient.cs, RadiusPaketParser.cs, EmailTwoFactorValidator.cs} – vollständige Implementierung der Protokollschicht
- Es fehlt: Nachweis der Durchsetzung im Login-Ablauf (Authenticator.cs-Kopplung nicht geprüft) → HYPOTHESE
Prüfidee: Login mit RADIUS-Account erfordert und verdrahtet den zweiten Faktor gegen den Test-RADIUS-Server.
Tracelinks: SyRS-005, SyRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE
```
```
ID: SwRS-031
Titel: TradePool-Zugang mit eigenem Login (TradeCustomerLogin)
Ebene: SwRS
Typ: Schnittstelle/Sicherheit
Qualitätsmerkmal: -
Akteur: Handelspartner (TradePool-Teilnehmer)
Vorbedingung: TradePool-Zugang ist freigeschaltet
Fakt: TradePoolBL.cs:170 stellt AuthenticateUser(userName, password) bereit und liefert ein TradeCustomerLogin-Objekt; das Modul enthält ein Core-Verzeichnis.
Aussage: [HYPOTHESE] Die Software soll einem B2B-Handelsplatz („TradePool") einen eigenen, ERP-seitig authentifizierten Zugang für Handelskunden bieten.
Ergebnis: Handelspartner erhalten sessionbasierten Zugriff auf TradePool-Funktionen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/TradePool/TradePoolBL.cs:170 (AuthenticateUser-Signatur und Rückgabetyp) – Schnittstelle
- Es fehlt: Geschäftsprozess/Nutzungskontext des TradePool (nur Klasse gesehen) → HYPOTHESE
Prüfidee: Gültige Credentials liefern TradeCustomerLogin; ungültige werden abgelehnt.
Tracelinks: SyRS-005, StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall – Eigenwelt TradePool bei Migration separat bewerten
Status: HYPOTHESE
```
```
ID: SwRS-032
Titel: Mobile Anbindung und Verbindungsmanagement
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Mobile Nutzer, Software
Vorbedingung: Webservice ist erreichbar
Fakt: BL/Mobile enthält mobile Fachlogik; das eigenständige Projekt c-entron.misc.ConnectionManager kapselt Verbindungseinstellungen; Centron.Gateway (src/backend) stellt eine Gateway-Schicht; der WPF-Client überwacht die Verbindung per ConnectionHeartbeatTimer.
Aussage: Die Software soll mobile/entfernte Clients über eine abgesicherte Verbindungsschicht anbinden und Verbindungsverluste erkennen.
Ergebnis: Stabile Nutzung mobiler/entfernter Arbeitsplätze.
Belege:
- [SEKUNDÄR] src/webservice/c-entron.misc.ConnectionManager/, src/backend/Centron.BL/Mobile/, src/backend/Centron.Gateway/ – Anbindungskomponenten (flach analysiert)
- [SEKUNDÄR] src/centron/Centron.WPF.UI/ConnectionHeartbeatTimer.cs – Verbindungsüberwachung im Client
Prüfidee: Temporärer Verbindungsabbruch wird erkannt, Client meldet und versucht Wiederverbindung.
Tracelinks: SyRS-001, SyRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Detailtiefe in Folgeiteration
Status: belegt
```
```
ID: SwRS-033
Titel: Gutscheinverwaltung (VoucherManagement)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Vertrieb/Buchhaltung
Vorbedingung: Gutschein soll ausgestellt/eingelöst werden
Fakt: VoucherManagementBL.cs (Basis-Implementierung, 1,2 KB) existiert als eigenes BL-Modul; Guthaben-/Gutschriftsbelege sind separat modelliert (GutKopf/GutPos siehe SwRS-001).
Aussage: Die Software soll Gutscheine als eigenes Objekt verwalten (Ausgabe/Einlösung), getrennt von Gutschriftsbelegen.
Ergebnis: Gutschein-Lebenszyklus nachvollziehbar.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs – dediziertes Modul (flach, noch Basisstand)
Prüfidee: Gutschein erhält Code/Wert und kann genau einmal eingelöst werden.
Tracelinks: StRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Ausbau prüfen (Modul wirkt rudimentär)
Status: belegt
```
```
ID: SwRS-034
Titel: Änderungsverfolgung (ChangeTracking) über Geschäftsobjekte
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit
Akteur: System, Revision
Vorbedingung: Objekt wird geändert/importiert
Fakt: Es existieren ChangeTracking-Verzeichnisse in BL und DAO (inkl. History) sowie eine ImportKind-Enumeration, die Änderungsquellen beschreibt (u. a. „Stammblatt", ImportKind.cs:17); ReceiptLogBL und HelpdeskTimerLogBL schreiben fachliche Änderungsjournale; AnlageLog/AccountLogs sind eigene Log-Tabellen.
Aussage: Die Software soll fachlich relevante Änderungen an Geschäftsobjekten mit Quelle (Benutzer/Import/Prozess) zeitlich nachvollziehbar protokollieren.
Ergebnis: Änderungshistorie für Audit und Fehleranalyse.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/ChangeTracking/History/, src/backend/Centron.DAO/ChangeTracking/, src/backend/Centron.Interfaces/ChangeTracking/History/ImportKind.cs – Tracking-Infrastruktur
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerLogBL.cs:183 (Alt-/Neu-Protokollierung, z. B. Stammblattwechsel) – konkretes Änderungsjournal
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AccountLogs, AnlageLog – Log-Tabellen
Prüfidee: Feldänderung erzeugt Logeintrag mit Alt-/Neuwert und Quelle.
Tracelinks: SyRS-019
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SwRS-035
Titel: Entity-Mapping (Fluent NHibernate) je Geschäftsobjekt
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal: Wartbarkeit
Akteur: Software (Persistenz), Entwicklung
Vorbedingung: Neues Datenbankfeld/-tabelle wird eingeführt
Fakt: Die Mappings liegen konventionsgetrieben im Verzeichnis Centron.DAO/Mappings je Fachbereich (z. B. EmployeeArea/EmployeeMaps.cs bildet MasterDataListView auf Spalte „StammblattAnsicht" ab; TemporaryEntities/VertragKopfMaps.cs mappt Stammblattbezogen); Spalten bleiben deutsch benannt.
Aussage: Die Software soll jede persistente Entität über ein explizites, versionierbares Mapping auf ihre Tabelle/Spalten abbilden.
Ergebnis: Nachvollziehbare, refaktorierfeste Schema-Kopplung.
Belege:
- [PRIMÄR] src/backend/Centron.DAO/Mappings/EmployeeArea/EmployeeMaps.cs:80; Mappings/TemporaryEntities/VertragKopfMaps.cs:115 – konkrete Mappingbeispiele
- [SEKUNDÄR] src/backend/Centron.Entities/Entities/** – Entitäten
Prüfidee: Spaltenumbenennung ohne Mapping-Anpassung bricht Build- bzw. Integrationstest erkennbar.
Tracelinks: SyRS-007
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Ergebnisse/SyRS.md
+664
View File
@@ -0,0 +1,664 @@
# SyRS – System Requirements Specification (c-entron ERP, Reverse Engineering)
Normbezug: ISO/IEC/IEEE 29148:2018. Tracelinks zur fachlichen Herkunft siehe jeweils Feld `Tracelinks` und `Traceability.md`.
---
```
ID: SyRS-001
Titel: Versionierte REST-API (v1)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: -
Akteur: Externe Clients, Web-Frontend
Vorbedingung: API-Host läuft; Client ist authentifiziert
Fakt: Controller liegen unter src/webservice/Centron.Controllers/Controllers/v1 in fachlichen Bereichen (Accounts, Administration, Contracts, Customers, DataExchange, Helpdesks, Integrations, Nexoware, Offers, Orders, Receipts, SelfCare, Tickets, WebAccount, WebVersion); Routen nutzen apiVersion-Templating (README: "v{version:apiVersion}/...").
Aussage: Das System soll seine Geschäftsfunktionen über eine versionierte HTTP-REST-API (Namespace v1) bereitstellen, damit Änderungen der API abwärtskompatibel eingeführt werden können.
Ergebnis: Clients sprechen stabile, versionierte Endpunkte je Fachbereich an.
Belege:
- [PRIMÄR] src/webservice/Centron.Controllers/Controllers/v1/* (Bereichsverzeichnisse) – Struktur der API
- [SEKUNDÄR] src/webservice/Centron.Controllers/Authorization/README.md – dokumentiertes Routing-Muster
Prüfidee: GET auf v1-Endpunkt eines Fachbereichs liefert 2xx/4xx, nie 404 bei bestehender Version.
Tracelinks: StRS-003, StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-002
Titel: Rechte-Durchsetzung auf API-Ebene mit HTTP 401/403
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: System (API-Pipeline)
Vorbedingung: Geschützter Endpunkt wird aufgerufen
Fakt: Attribute AuthorizeUserRightAttribute, AuthorizeAnyUserRightAttribute, AuthorizeAllUserRightsAttribute (und AuthorizeCentronHostedAttribute) laufen als Authorization-Filter vor der eigentlichen Aktion; laut README liefert die Pipeline 401 bei fehlender Authentifizierung und 403 bei fehlendem Recht; die Prüfung erfolgt über HasUserRight().
Aussage: Das System soll jeden API-Aufruf deklarativ gegen die geforderten Benutzerrechte prüfen (einzeln, mindestens eines oder alle) und bei Verstoß mit 401/403 ablehnen, bevor Geschäftslogik ausgeführt wird.
Ergebnis: Kein Zugriff auf geschützte Ressourcen ohne gültige Anmeldung und Recht.
Belege:
- [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, AuthorizeAnyUserRightAttribute.cs, AuthorizeAllUserRightsAttribute.cs (inkl. Verhalten laut README: Filter vor Action, 401/403) – durchsetzende Stelle
- [SEKUNDÄR] src/webservice/Centron.Controllers/Authorization/README.md (Tab. „HTTP Response Codes") – spezifiziert Antwortverhalten
Prüfidee: Aufruf ohne Token → 401; mit Token ohne Recht → 403; mit Recht → 200.
Tracelinks: StRS-014, SwRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
Status: belegt
```
```
ID: SyRS-003
Titel: Zentrale Rechte-Durchsetzung in der Geschäftslogik
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: System (Business Layer)
Vorbedingung: Geschäftsoperation wird ausgelöst (UI, API oder Hintergrundjob)
Fakt: AppRightsBL (Administration/Rights) stellt HasUserRight(userI3D, rightI3D), CheckRightsFromUser und GetRightsFromCurrentUser bereit; BL-Klassen prüfen jeweils vor der Operation (Beispiele: AccountBL, HelpdeskBL, ArticleBL, InventoryBL, PasswordManagerBL); UserRightsConst enthält numerische Rechte-IDs.
Aussage: Das System soll sämtliche sicherheitsrelevanten Geschäftsoperationen unabhängig vom Aufrufkanal (UI, API, Job) in der Geschäftslogiksschicht gegen Benutzerrechte prüfen und bei fehlendem Recht mit Fehler abbrechen.
Ergebnis: Rechteprüfung kann clientseitig nicht umgangen werden.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:25 (Klasse mit HasUserRight/CheckRightsFromUser) – zentrale Prüf-API
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs:1305–1365; src/backend/Centron.BL/Warehousing/ArticleBL.cs:999–1081 (Prüfung vor Persistierung) – durchsetzende Stellen
- [KONTEXT] CentronRights.md – Rechtekatalog
Prüfidee: Direkter BL-Aufruf ohne Recht schlägt mit Fehlercode (z. B. RightCheckFailed) fehl.
Tracelinks: StRS-002, StRS-014, SwRS-007
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
Status: belegt
```
```
ID: SyRS-004
Titel: Einschränkende Sichtbarkeitsrechte in Suchen (nur eigene / nur eigene Filiale)
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: System (Suchfunktionen)
Vorbedingung: Benutzer besitzt einschränkendes Recht (*_ONLY_OWN, *_ONLY_OWN_BRANCH, SHOW_ONLY_OWN_CUSTOMER)
Fakt: Je Belegart existiert eine ReceiptSearchConfiguration mit Properties ShowRight, OnlyOwnRight, OnlyOwnBranchRight (z. B. InvoiceReceiptSearchConfiguration.cs:152–157, ContractReceiptSearchConfiguration.cs:168–173); HelpdeskBL.cs:271–284 und AccountSearchBL.cs:76/214/331 wenden analoge Filter für Tickets und Kunden an; Kalendersichten nutzen RIGHT_KALENDERANZEIGENEIGENE/-ALLE (ScheduleBL.cs:372–378, 693–697).
Aussage: Das System soll Such- und Listenabfragen (Belege, Tickets, Kunden, Kalender, Statistiken) automatisch auf die dem Benutzer erlaubte Datenmenge einschränken.
Ergebnis: Einschränkende Rechte wirken filternd auf Datenebene, nicht nur in der Oberfläche.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs:152–157 (ShowRight/OnlyOwn-/OnlyOwnBranchRight als Teil der Suchkonfiguration) – durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284 – Ticketfilterung
- [SEKUNDÄR] CentronRights.md (restricting rights) – fachliche Semantik
Prüfidee: Benutzer mit EDIT_OFFER_ONLY_OWN_BRANCH kann nur Belege der eigenen Filiale öffnen.
Tracelinks: StRS-002, SwRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
Status: belegt
```
```
ID: SyRS-005
Titel: Mehrere Authentifizierungsverfahren (lokal, Active Directory, Basic)
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Benutzer, System
Vorbedingung: Benutzerkonto existiert
Fakt: Authenticator.cs zentralisiert die Anmeldung (AuthenticateUser; Fehlversuche werden geloggt: Zeile 161 „c-entron Login failed..."); ActiveDirectoryAuthenticator.cs prüft optional den Zertifikats-Hash der Domäne (GetDomainCertificateHash aus WebServiceConfigHelper); BasicAuthenticator.cs:46 decodiert das Passwort als SHA1; TradePoolBL.cs:170 besitzt ein eigenes AuthenticateUser für TradePool-Logins.
Aussage: Das System soll Benutzer wahlweise gegen die lokale Benutzerverwaltung oder das Active Directory authentifizieren, Fehlversuche protokollieren und bei AD optional das Serverzertifikat verifizieren.
Ergebnis: Nur erfolgreich authentifizierte Benutzer erhalten eine Sitzung; Fehlversuche sind nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:106–109, :161 (Authentifizierung + Fehlversuchs-Logging) – durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/ActiveDirectoryAuthenticator.cs:151–156 (Zertifikatsprüfung) – konkrete Bedingung
- [SEKUNDÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs:46 – SHA1-Passwortprüfung
Prüfidee: Falsches Passwort erzeugt Logeintrag und keine Sitzung; AD-Login mit falschem Zertifikat-Hash schlägt fehl.
Tracelinks: StRS-014, SwRS-012, SwRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Sicherheit); Hashverfahren separat modernisieren (SwRS-012)
Status: belegt
```
```
ID: SyRS-006
Titel: Zwei-Faktor-Authentifizierung per TOTP (Google Authenticator)
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Benutzer
Vorbedingung: Dem Benutzer ist ein TwoFactorAuthKey in der Personalverwaltung hinterlegt
Fakt: TwoFactorAuthenticationBL.ValidateAuthenticationPin lädt den Benutzerschlüssel (Named Query PasswordManager.GetAppUserTwoFactorAuthKey) und prüft die PIN über Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin; ohne hinterlegten Schlüssel liefert die Methode eine Fehlermeldung („Ihrem Benutzer ist kein Zwei-Faktor Schlüssel ... hinterlegt").
Aussage: Das System soll die zweite Faktor-Stufe als zeitbasierte Einmal-PIN (TOTP) validieren und Benutzer ohne hinterlegten Schlüssel mit fachlicher Fehlermeldung ablehnen.
Ergebnis: Anmeldung bzw. geschützte Aktion nur mit gültiger TOTP-PIN.
Belege:
- [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, Methoden ValidateAuthenticationPin, UpdateAppUserTwoFactorAuthKey (Named Queries PasswordManager.GetAppUserTwoFactorAuthKey/UpdateAppUserTwoFactorAuthKey) – durchsetzende Stelle
- [SEKUNDÄR] Verweis auf Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin – TOTP-Bibliothek
Prüfidee: Gültige aktuelle PIN wird akzeptiert, abgelaufene PIN abgelehnt; Benutzer ohne Schlüssel erhält definierte Fehlermeldung.
Tracelinks: StRS-014, SyRS-005, SwRS-014
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Sicherheit)
Status: belegt
```
```
ID: SyRS-007
Titel: Persistenz über Microsoft SQL Server mit NHibernate-ORM
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal: Wartbarkeit
Akteur: System
Vorbedingung: Datenbank ist erreichbar
Fakt: Centron.DAO kapselt den Zugriff (GenericDAO, GenericStoredProcedureDAO, DAOFactory, DAOSession, NHibernateConfiguration, Repositories, NamedQueries); das mitgelieferte Schema SSMS_DB_SCHEMA.sql definiert 1535 Tabellen mit 1482 PRIMARY-KEY- und nur 134 FOREIGN-KEY-Constraints; BinaryFormatter ist nur für die NHibernate-Konfigurationsserialisierung aktiviert (Directory.Build.props).
Aussage: Das System soll seine Daten in einer SQL-Server-Datenbank über ein ORM (NHibernate) mit klar getrennter Datenzugriffsschicht (DAOFactory/Generics/Repositories/Named Queries) persistieren.
Ergebnis: Einheitlicher, austauschbarer Datenzugriff; Schema zentral versionierbar.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql (1535 CREATE TABLE; gezählt per Suche) – physisches Datenmodell
- [SEKUNDÄR] src/backend/Centron.DAO/{DAOFactory.cs, GenericDAO.cs, GenericStoredProcedureDAO.cs, NHibernateConfiguration/} – Zugriffsarchitektur
- [SEKUNDÄR] src/backend/Centron.DAO/Mappings/** – Entity-Tabellen-Mappings
Prüfidee: Entity wird über GenericDAO gespeichert und per Named Query wieder gelesen.
Tracelinks: StRS-001, StRS-003, SwRS-001, SwRS-003, SwRS-004
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-008
Titel: Betrieb des Backends als Windows-Dienst oder Konsole
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit/Übertragbarkeit
Akteur: Systemadministrator
Vorbedingung: Deployment-Paket ist installiert
Fakt: Es existieren getrennte Host-Projekte Centron.Host, Centron.Host.Console und Centron.Host.WindowsService unter src/webservice; ein Verzeichnis docs/Background Service dokumentiert den Dienstbetrieb.
Aussage: Das System soll das Backend wahlweise als Windows-Dienst (Dauerbetrieb) oder als Konsolenanwendung (Entwicklung/Diagnose) betreiben können.
Ergebnis: Gleiche Funktionalität in zwei Betriebsmodi.
Belege:
- [PRIMÄR] src/webservice/Centron.Host.WindowsService/, src/webservice/Centron.Host.Console/, src/webservice/Centron.Host/ – Betriebsmodi
- [SEKUNDÄR] docs/Background Service/ – Betriebsdokumentation
Prüfidee: Start als Dienst und als Konsole führt jeweils zu erreichbarer API.
Tracelinks: SyRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – in Zielarchitektur als Container-Dienst neu denken
Status: belegt
```
```
ID: SyRS-009
Titel: Windows-Desktop-Client (WPF)
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Benutzbarkeit
Akteur: Anwender
Vorbedingung: Benutzer ist am Backend angemeldet
Fakt: Centron.WPF.UI ist der Hauptclient (App.xaml, FrontWindow mit Ribbon, Modulverzeichnis Modules mit Fachmodulen z. B. OnlineBanking, MyCentron; Localization, ViewModels, Views); ConnectionHeartbeatTimer.cs überwacht die Verbindung; eigene Controls-Bibliothek (src/shared/Centron.Controls inkl. Preview-Projekt).
Aussage: Das System soll einen Windows-Desktop-Arbeitsplatz mit modularen Fachbereichen und Ribbon-Oberfläche bereitstellen, der Verbindungsverluste erkennt.
Ergebnis: Vollständige Bedienung des ERP am Arbeitsplatz.
Belege:
- [PRIMÄR] src/centron/Centron.WPF.UI/{App.xaml, FrontWindow.xaml, Modules/} – Client-Struktur
- [SEKUNDÄR] src/centron/Centron.WPF.UI/ConnectionHeartbeatTimer.cs – Verbindungsüberwachung
- [SEKUNDÄR] src/shared/Centron.Controls, Centron.Controls.Preview – wiederverwendbare Steuerelemente
Prüfidee: Netzwerkunterbrechung wird durch Heartbeat-Mechanismus erkannt und gemeldet.
Tracelinks: StRS-001
Konsolidierung: nein
Übernahmewürdigkeit: veraltet – durch Web-Client (Nexus) abzulösen; UI-Muster/Fachlogik übernehmen
Status: belegt
```
```
ID: SyRS-010
Titel: Web-Client „c-entron Nexus" (Blazor)
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Benutzbarkeit/Übertragbarkeit
Akteur: Anwender, Endkunde
Vorbedingung: Nexus-Host ist erreichbar; Benutzer angemeldet
Fakt: src/nexus/CentronNexus ist eine Blazor-Anwendung mit Bereichen WebCart, WebOffer, ServiceBoard, ProductionOrderManagement, DocumentSigning, Management, Office, Settings; Ressourcen werden mehrsprachig gepflegt (SharedResource.resx/.en-US.resx); UI-Konventionen (DevExpress-Blazor-Komponenten, LibMan/CDN mit Integrity-Hash) sind im README festgelegt.
Aussage: Das System soll eine moderne, mehrsprachige Web-Oberfläche für Backoffice- und Kundenportal-Funktionen bereitstellen.
Ergebnis: Browserbasierte Nutzung zentraler Geschäftsprozesse ohne lokale Installation.
Belege:
- [PRIMÄR] src/nexus/CentronNexus/{WebCart, WebOffer, ServiceBoard, ProductionOrderManagement, DocumentSigning}/ – Funktionsbereiche der Web-App
- [SEKUNDÄR] README.md (Regeln zu Komponenten/Integrität), SharedResource.*.resx – Lokalisierung und UI-Standards
Prüfidee: Sprachwechsel ändert Oberflächentexte einer Maske; Shop ist als Web-Account erreichbar.
Tracelinks: StRS-013, SyRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Zielplattform der Migration
Status: belegt
```
```
ID: SyRS-011
Titel: Web-Konten für Endkunden (WebAccount)
Ebene: SyRS
Typ: Schnittstelle/Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Vertrieb (Verwaltung), Endkunde (Nutzung)
Vorbedingung: Kunde existiert im Adressstamm
Fakt: WebAccountBL.cs verwaltet Web-Zugänge: Passwörter werden als SHA1-Hash gespeichert/aktualisiert (Zeilen 56, 192, 415, 480), beim Ändern wird der Hash geprüft (Zeile 253); Verwaltungsoperationen erfordern das Recht WEBACCOUNT_MANAGEMENT (WebAccountWebServiceBL mehrfach).
Aussage: Das System soll für Adressen Web-Zugänge verwalten (anlegen, Passwort ändern/zurücksetzen), deren Administration nur berechtigten Benutzern erlaubt ist.
Ergebnis: Kunden können sich im Webportal anmelden; Verwaltung bleibt geschützt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Administration/Logins/WebAccountWebServiceBL.cs:54, :75 u. a. (Rechteprüfung WEBACCOUNT_MANAGEMENT vor jeder Operation) – durchsetzende Stelle
- [SEKUNDÄR] src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs:56/192/253/415/480 – Passwort-Lifecycle
- [KONTEXT] README.md, WebCart-Abschnitt – Zusammenspiel mit Shop
Prüfidee: Verwaltungsaufruf ohne WEBACCOUNT_MANAGEMENT → Fehler; Passwortänderung setzt neuen Hash.
Tracelinks: StRS-013, SyRS-010, SwRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Rechtemodell; Hashverfahren modernisieren (SwRS-012)
Status: belegt
```
```
ID: SyRS-012
Titel: EDI-Dispatcher mit Distributor-Profilen und Austauschprotokoll
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Zuverlässigkeit
Akteur: System
Vorbedingung: Gateway-Einstellungen je Distributor sind konfiguriert
Fakt: EDIDispatcherBL.cs (14 KB) steuert den Austausch, EDIGatewaySettingBL.cs hält Gateway-Konfiguration, EDILogBL.cs protokolliert; Unterverzeichnisse je Distributor/Standard (Alltron, ALSO, AlsoCH, Concerto, EGIS, Komsa, Opentrans21, SupplierEDI, Import).
Aussage: Das System soll ein- und ausgehende EDI-Nachrichten je Geschäftspartner-Profil verarbeiten, verteilen und jeden Austausch protokollieren.
Ergebnis: Fehlgeschlagene oder erfolgreiche Übertragungen sind je Dokument nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EDI/{EDIDispatcherBL.cs, EDILogBL.cs, EDIGatewaySettingBL.cs} – Verarbeitung/Protokoll/Konfiguration
- [SEKUNDÄR] Verzeichnisstruktur EDI/* – Partnerprofile
Prüfidee: Testnachricht für Distributor X erzeugt EDILog-Eintrag mit Dokumentbezug.
Tracelinks: StRS-010, StRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-013
Titel: Elektronische Rechnung (ZUGFeRD/ebInterface)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Übertragbarkeit
Akteur: Buchhaltung, System
Vorbedingung: Rechnung ist erstellt
Fakt: BL/EDI enthält ein Verzeichnis Zugferd; als separat versionierte Komponente existiert Centron.Api.EbInterface unter src/apis (ebInterface ist das österreichische E-Rechnungsformat).
Aussage: Das System soll Rechnungen in elektronischen Rechnungsformaten (ZUGFeRD, ebInterface) erzeugen/austauschen können.
Ergebnis: E-Rechnung als strukturiertes Dokument zum Beleg.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/EDI/Zugferd/ – ZUGFeRD-Erzeugung
- [SEKUNDÄR] src/apis/Centron.Api.EbInterface/ – ebInterface-API-Projekt
Prüfidee: Erzeugte E-Rechnung validiert gegen das jeweilige Formatschema.
Tracelinks: StRS-003, StRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Detailtiefe der Formate in Folgeiteration prüfen
Status: belegt
```
```
ID: SyRS-014
Titel: Versanddienstleister-Anbindung (GLS, Shipcloud)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Lager/Versand
Vorbedingung: Liefer- bzw. Abholbeleg mit Versandbezug
Fakt: Separate API-Projekte Centron.Api.Gls und Centron.Api.Shipcloud existieren; ShipcloudPackageTemplateBL.cs verwaltet Paketschein-Vorlagen.
Aussage: Das System soll Paketetiketten/Versanddaten bei GLS und Shipcloud anfordern und Vorlagen je Paketdienst verwalten.
Ergebnis: Versandetikett/Sendungsnummer am Beleg.
Belege:
- [SEKUNDÄR] src/apis/Centron.Api.Gls/, src/apis/Centron.Api.Shipcloud/ – Dienstleister-Integration
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs – Vorlagenverwaltung
Prüfidee: Paketschein-Erzeugung liefert Tracking-Nummer und Etikett (PDF).
Tracelinks: StRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-015
Titel: Katalogartikel-Import aus IT-Distributionsquellen (ITscope, Icecat, EGIS, Cop)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Zuverlässigkeit
Akteur: Einkauf, System (Hintergrundimport)
Vorbedingung: Importquelle ist konfiguriert
Fakt: Separate Data-Access-Projekte existieren (ITscopeDataAccess, IcecatDataAccess, EgisDataAccess, CopDataAccess); das DB-Schema enthält ein dediziertes Import-Modell (ArticleImports, ArticleImportMappings, ArticleImportField, ArticleImportLogs, ArticleImportDistributors, ArticleImportMultiDistributor).
Aussage: Das System soll Artikeldaten (inkl. Feld-Mapping und Mehr-Distributoren-Zuordnung) aus externen Katalogquellen importieren und Importe protokollieren.
Ergebnis: Aktualisierter Artikelstamm mit Herkunfts- und Fehlerprotokoll.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ArticleImports, ArticleImportMappings, ArticleImportField, ArticleImportLogs – durchgesetztes Import-Datenmodell
- [SEKUNDÄR] src/apis/Centron.APIs.ITscopeDataAccess/, ...IcecatDataAccess/, ...EgisDataAccess/, ...CopDataAccess/ – Quellsysteme
Prüfidee: Importlauf erzeugt Logeinträge; Feldzuordnung aus ArticleImportMappings wird angewendet.
Tracelinks: StRS-008, StRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-016
Titel: Online-Banking-Anbindung über FinAPI
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: Sicherheit
Akteur: Buchhaltung
Vorbedingung: Bankzugang ist eingerichtet (CreateFinApiAccount)
Fakt: src/apis/Centron.APIs.FinAPI implementiert den Anbieter-Zugriff; im WPF-Client existieren Dialoge zum Anlegen eines FinAPI-Kontos und zum Zurücksetzen des FinAPI-Passworts (CreateFinApiAccount/ResetFinApiPassword, jeweils mit CheckPassword()); BL/Finances/OnlineBanking enthält die fachliche Logik.
Aussage: Das System soll Bankkonten über die FinAPI-Schnittstelle anbinden und Zugangsdaten dafür geschützt verwalten.
Ergebnis: Kontoumsätze stehen für den Zahlungsabgleich zur Verfügung.
Belege:
- [SEKUNDÄR] src/apis/Centron.APIs.FinAPI/ – Anbieteranbindung
- [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConfigurationSettings/ResetFinApiPassword/ResetFinApiPasswordViewModel.cs:210/:248 – Passwort-Handling im Client
- [SEKUNDÄR] src/backend/Centron.BL/Finances/OnlineBanking/ – Fachlogik
Prüfidee: Kontoumsatz-Abruf liefert buchungsfähige Umsätze; falsches Passwort wird vom Dialog abgefangen.
Tracelinks: StRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-017
Titel: Volltext-/Indexsuche mit deutscher Sprachanalyse
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Performance-Effizienz
Akteur: Anwender
Vorbedingung: Index ist aufgebaut (IndexBuilder)
Fakt: BL/IndexSearch enthält IndexSearchBL, IndexBuilder und einen GermanAnalyzer.cs (20 KB) sowie die Fehlerbehandlung ObjectIndexingFailedException; Indizes liegen unter Indexes/.
Aussage: Das System soll Geschäftsobjekte indizieren und eine deutschsprachig optimierte Suche darüber anbieten; Indexierungsfehler sollen objektbezogen behandelt werden.
Ergebnis: Schnelle Volltextsuche über Geschäftsobjekte.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/IndexSearch/{IndexSearchBL.cs, IndexBuilder.cs, GermanAnalyzer.cs, ObjectIndexingFailedException.cs} – Suchinfrastruktur
Prüfidee: Suche nach Wortstamm findet flektierte Formen; defektes Objekt blockiert nicht den Gesamtindex.
Tracelinks: StRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-018
Titel: Report-Engine mit Berichtsgruppen, Benutzerrechten und PDF-Export
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Benutzbarkeit
Akteur: Anwender, Controlling
Vorbedingung: Bericht ist definiert (ReportGroup/ReportData)
Fakt: ReportEngine umfasst ReportDataBL (94 KB), ReportGroupBL (32 KB), FastReportHelper (FastReport als Engine), PDF-Export/PdfStrategy, benutzerdefinierte Generatoren sowie SQL-Abfrage-Verwaltung (ReportDataQueryBL); der Zugriff auf den SQL-Manager erfordert Administration.SQL_MANAGER oder REPORT_MANAGEMENT (ReportDataWebBL.cs:496).
Aussage: Das System soll Berichte auf Basis definierter Datenabfragen über FastReport erzeugen, als PDF exportieren und die Verwaltung von Abfragen/Berichten nur berechtigten Benutzern erlauben.
Ergebnis: Druckfertige Berichte/PDF je Berichtsgruppe.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/ReportEngine/ReportDataWebBL.cs:496 (Rechteprüfung SQL_MANAGER/REPORT_MANAGEMENT) – durchsetzende Stelle
- [SEKUNDÄR] src/backend/Centron.BL/ReportEngine/{FastReportHelper.cs, PdfExport/, ReportGroupBL.cs} – Engine/Export/Gruppierung
Prüfidee: Bericht ohne REPORT_MANAGEMENT-Recht nicht änderbar; PDF-Ausgabe öffnet valide Datei.
Tracelinks: StRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-019
Titel: Belegversionierung und Belegjournal („Versions"-Tabellen, Beleglog)
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal: Zuverlässigkeit
Akteur: System
Vorbedingung: Beleg existiert und wird geändert/abgeschlossen
Fakt: Zu nahezu jeder Belegart existiert eine Versions-Tabelle (RechKopf/RechPosVersions, AufKopf/AufPosVersions, AngKopf/AngPosVersions, LiefKopf/LiefPosVersions, AbholKopf/AbholPosVersions, GutKopf/GutPosVersions, VertragKopf/VertragPosVersions, AnfrKopf/AnfrPosVersions); ReceiptLogBL.cs (75 KB) protokolliert Belegänderungen (z. B. Stammblatt hinzugefügt/entfernt, Vertragspreise).
Aussage: Das System soll frühere Belegstände gesondert speichern (Versionstabellen) und Änderungen an Belegen in einem Journal festhalten.
Ergebnis: Belegänderungen sind zeitlich nachvollziehbar; historische Stände bleiben abrufbar.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE RechKopfVersions, AufKopfVersions, VertragKopfVersions u. a. – durchgesetzte Versionstabellen
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs:1266–1279 u. a. (Logeinträge je Änderung) – Journallogik
Prüfidee: Beleg ändern → neuer Versions-Datensatz + Logeintrag mit Alt-/Neuwert.
Tracelinks: StRS-003, StRS-004, SwRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-020
Titel: Mindestpreis-Schutz bei Verkaufspreisen
Ebene: SyRS
Typ: funktional/Sicherheit
Qualitätsmerkmal: -
Akteur: Vertrieb
Vorbedingung: Position wird bepreist; Mindestpreis ist definiert
Fakt: ReceiptBL.cs:9043 und :9113 prüfen das Recht ALLOW_IGNORE_MINIMUM_PRICE: ohne dieses Recht darf der Mindestpreis nicht unterschritten werden (Zeile 9113: Ablehnung, wenn „== false").
Aussage: Das System soll Preisunterschreitungen unter den Mindestpreis blockieren, sofern der Benutzer nicht das explizite Ausnahmerecht besitzt.
Ergebnis: Margenschutz; Ausnahmen nur für berechtigte Benutzer und damit nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:9043, :9113 (HasUserRight ALLOW_IGNORE_MINIMUM_PRICE als Bedingung der Preisannahme) – durchsetzende Stelle inkl. konkreter Prüfung
Prüfidee: Position unter Mindestpreis: ohne Recht Fehler, mit Recht speicherbar.
Tracelinks: StRS-003, SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Abrechnung)
Status: belegt
```
```
ID: SyRS-021
Titel: Rechnungsstorno nur mit gesondertem Recht
Ebene: SyRS
Typ: Sicherheit/funktional
Qualitätsmerkmal: Sicherheit
Akteur: Buchhaltung
Vorbedingung: Rechnung ist gebucht
Fakt: ReceiptWebServiceBL.cs:1022 belegt, dass die Storno-Fähigkeit an das Recht RIGHT_RECHNUNGSTORNIEREN gebunden ist („CanCancelInvoices = rights.Any(...)"); fachlich korrespondiert eine Gutschrifts-Belegart (GutKopf/GutPos).
Aussage: Das System soll die Stornierung von Rechnungen ausschließlich Benutzern mit dem Storno-Recht erlauben und den Vorgang als eigenen, nachvollziehbaren Schritt führen.
Ergebnis: Stornos sind rechtgeschützt und über Belegjournal nachvollziehbar (siehe SyRS-019).
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:1022 (Fähigkeit CanCancelInvoices an RIGHT_RECHNUNGSTORNIEREN gebunden) – rechtedurchsetzende Stelle
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE GutKopf/GutPos – Gutschriftsbeleg als fachliches Gegenstück
Prüfidee: Nutzer ohne Storno-Recht erhält keine Storno-Option bzw. API-Fehler; Storno erzeugt Gegenbeleg.
Tracelinks: StRS-003, SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – risikorelevant (Abrechnung)
Status: belegt
```
```
ID: SyRS-022
Titel: Massenänderung von Stammdaten (MassUpdate)
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Administrator/Power-User
Vorbedingung: Zielmenge ist selektiert
Fakt: MassUpdateBL.cs (50 KB) implementiert Massenaktualisierungen als eigenes BL-Modul.
Aussage: Das System soll gebündelte Änderungen an vielen Datensätzen (z. B. Feldwerte) in einem kontrollierten Lauf ausführen.
Ergebnis: Konsistente, wiederholbare Massenpflege ohne Einzelbearbeitung.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs – Implementierung der Massenänderung (flach analysiert)
Prüfidee: Massenupdate auf Testmenge ändert nur die selektierten Datensätze und protokolliert Ergebnisse.
Tracelinks: StRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Rechte-/Protokollaspekt in Folgeiteration vertiefen
Status: belegt
```
```
ID: SyRS-023
Titel: Integrierte Kommunikation: E-Mail, Telefonie, Chat, Benachrichtigungen
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: Benutzbarkeit
Akteur: Anwender
Vorbedingung: Mail-/TAPI-/Chat-Einstellungen sind gepflegt
Fakt: BL/Mail enthält Protokolle, Templates, Signatur (MailSignatureBL), Blacklist, Exchange-Ordner und VariableReplacement; PhoneCallBL.cs (31 KB) implementiert Telefonie (Tapi); ChatBL.cs (21 KB) und CentronNotificationsBL/UserNotificationBL interne Chats und Benachrichtigungen; MailingDataBL realisiert Serienmails; MailScannerBL.cs:59–61 verlangt das Recht VirtualMailAssistant.ACCESS_VMA_MODULE.
Aussage: Das System soll E-Mail (inkl. Signaturen, Vorlagen, Variablenersetzung, Blacklisting, Exchange-Anbindung), Telefonie über TAPI, interne Chats, Benachrichtigungen, Serienmails und den rechtegeschützten „Virtuellen Mail-Assistenten" integriert bereitstellen.
Ergebnis: Kommunikation ist objektbezogen im ERP dokumentiert und auslösbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs:59–61 (Rechteprüfung ACCESS_VMA_MODULE vor Zugriff) – durchsetzende Stelle
- [SEKUNDÄR] src/backend/Centron.BL/Mail/{MailSettingsBL.cs, MailSignatureBL.cs, Templates/, Protocols/, Blacklist/, Exchange/} – Mail-Teilfunktionen
- [SEKUNDÄR] src/backend/Centron.BL/Tapi/PhoneCallBL.cs; Chats/ChatBL.cs; Notifications/UserNotificationBL.cs; Mailings/MailingDataBL.cs – Telefon-/Chat-/Notify-/Mailing-Logik
Prüfidee: Serienmail nutzt Vorlage mit ersetzten Variablen; VMA-Zugriff ohne Recht schlägt fehl.
Tracelinks: StRS-001, SyRS-031
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-024
Titel: KI-Chat mit rechtegesteuerten Fähigkeiten
Ebene: SyRS
Typ: funktional/Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Anwender
Vorbedingung: KI-Modul ist eingerichtet (Prompt-Einstellungen vorhanden)
Fakt: ArtificialIntelligenceChatWebServiceBL.cs prüft je Fähigkeit eigene Rechte: MODEL_SELECTION, WEB_SEARCH, INTERACTIVE_MODE, ADD_FILES und Modulzugriff ArtificialIntelligence.ID (Zeilen 90, 369–390, 473); das DB-Schema hält Prompt-Kategorien/-Einstellungen (ArtificialIntelligencePromptCategory/-Settings).
Aussage: Das System soll einen KI-Assistenten anbieten, dessen Einzelfähigkeiten (Modellauswahl, Websuche, interaktiver Modus, Datei-Upload) benutzerrechtlich getrennt freigeschaltet werden.
Ergebnis: KI-Nutzung unterliegt dem Unternehmens-Rechtemodell.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Administration/ArtificialIntelligence/ArtificialIntelligenceChatWebServiceBL.cs:90, :369–390 (HasArtificialIntelligenceRight je Fähigkeit) – durchsetzende Stelle
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ArtificialIntelligencePromptCategory, ArtificialIntelligencePromptSettings – Prompt-Verwaltung
Prüfidee: Ohne WEB_SEARCH-Recht steht die Websuche-Option nicht zur Verfügung bzw. der Aufruf wird abgelehnt.
Tracelinks: StRS-014
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-025
Titel: Dokumentenablage mit Rechten, interner/externer Dokumentation und PDF-Signatur
Ebene: SyRS
Typ: funktional/Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Anwender
Vorbedingung: Dokumentstruktur (Verzeichnisse) existiert
Fakt: Dokumentenoperationen tragen eigene Rechte (READ/ADD/CHANGE/DELETE_DOCUMENTS, MANAGE_DOCUMENTS, Verzeichnisrechte; DocumentWebServiceBL.cs:78–109/:660, DirectoryWebServiceBL.cs:265–291); die Wissensdokumentation unterscheidet interne und öffentliche Inhalte (DocumentationBL.cs:33–264: READ_DOCUMENTATION vs. READ_INTERNAL_DOCUMENTATION); PDF-Signierung erfordert Administration.SETTINGS (PdfSigningBL.cs:60); ein eigenes API-Projekt Centron.Api.docuFORM koppelt ein Dokumenten-/Formularsystem.
Aussage: Das System soll Dateien und Verzeichnisse objektbezogen ablegen, deren Zugriff je Operation rechtlich absichern, Dokumentation nach intern/extern trennen, PDFs signieren und Formularsysteme anbinden können.
Ergebnis: Geschützte, revisionssichere Dokumentenverwaltung.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Administration/FileManagements/DocumentWebServiceBL.cs:78 (READ_DOCUMENTS-Prüfung vor Zugriff) – durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/DocumentationArea/DocumentationBL.cs:33–38 (interne Doku nur mit READ_INTERNAL_DOCUMENTATION) – konkrete Trennung
- [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs:60 (Signatur nur mit SETTINGS-Recht) – durchsetzende Stelle
- [SEKUNDÄR] Centron.Api.docuFORM/ – Formularsystem-Anbindung
Prüfidee: Interner Dokumentationsartikel ist ohne internes Recht nicht sichtbar; Signieren ohne SETTINGS-Recht schlägt fehl.
Tracelinks: StRS-006, StRS-014
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-026
Titel: Technologiebasis .NET 10 mit zentraler Build-Konfiguration
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: Entwicklung/Betrieb
Vorbedingung: Build-Umgebung ist eingerichtet
Fakt: global.json fordert SDK 10.0.100 (rollForward latestFeature); Directory.Build.props setzt unternehmensweite Attribute (TreatWarningsAsErrors, InformationalVersion mit GitCommitId, Company „NEXOWARE Systems GmbH", Product „NEXOWARE c-entron ERP"); die DevExpress-Version wird zentral aus DevExpress.Version.props importiert.
Aussage: Das System soll auf einer einheitlichen .NET-SDK- und Komponentenversion basieren, deren Build-Metadaten (Version, Commit) nachvollziehbar sind.
Ergebnis: Reproduzierbare Builds mit einheitlicher Drittkomponenten-Versionierung.
Belege:
- [PRIMÄR] global.json ({ "sdk": { "version": "10.0.100" } }) – SDK-Festlegung
- [SEKUNDÄR] Directory.Build.props, DevExpress.Version.props – zentrale Build-Defaults
Prüfidee: Build unter abweichendem SDK-Verhalten dokumentiert; Assembly-Info enthält Commit-Id.
Tracelinks: SyRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-027
Titel: Mahnwesen auf Basis offener Posten
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal: -
Akteur: Buchhaltung
Vorbedingung: Überfällige offene Posten existieren
Fakt: Tabelle Mahnlauf existiert; es gibt das Recht IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS (AccountWebServiceBL.cs:352), das eine Mahn-/Sperrwirkung auf Belege aufheben kann.
Aussage: [HYPOTHESE] Das System soll überfällige Forderungen mahnen und säumige Kunden für neue Belege sperren können.
Ergebnis: Mahnläufe erzeugen Mahnschreiben; gesperrte Kunden benötigen Ausnahmerecht für neue Belege.
Belege:
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Mahnlauf – Datenanker des Mahnwesens
- [SEKUNDÄR] src/backend/Centron.BL/WebServices/Accounts/AccountWebServiceBL.cs:352 (Recht IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS) – belegt Existenz einer Mahnsperre
- Es fehlt: PRIMÄR-Beleg für die Mahnstufen-/Sperrlogik (Prozessklasse nicht analysiert) → HYPOTHESE
Prüfidee: Kunde mit überfälligem OP löst Mahnsperrung aus; Beleganlage nur mit IGNORE_DUNNING_BLOCKING-Recht.
Tracelinks: StRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE
```
```
ID: SyRS-028
Titel: Mandantenfähigkeit
Ebene: SyRS
Typ: Daten/nicht-funktional
Qualitätsmerkmal: Übertragbarkeit
Akteur: Betreiber
Vorbedingung: Mehrere Mandanten sind eingerichtet
Fakt: Das Schema enthält eine Tabelle Mandant (CREATE TABLE dbo.Mandant); zusätzlich existieren Filiale und KundeToKonzern/CustomerToBranches (Filiale/Konzern-Beziehungen). Wo Mandant im Code ausgewertet wird, wurde nicht untersucht.
Aussage: [HYPOTHESE] Das System soll mehrere Mandanten (rechtlich getrennte Gesellschaften) in einer Installation verwalten können.
Ergebnis: Daten sind mandantbezogen getrennt.
Belege:
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Mandant, Filiale, CustomerToBranches, KundeToKonzern – Tabellenanker
- Es fehlt: Nachweis der mandantenbezogenen Filterung im Code (Zugriffe nicht analysiert) → HYPOTHESE
Prüfidee: Benutzer von Mandant A sieht keine Belege von Mandant B.
Tracelinks: StRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – vor SaaS-Migration zu klären (Single- vs. Multi-DB je Mandant)
Status: HYPOTHESE
```
```
ID: SyRS-029
Titel: Passwort-Tresor für Zugangsdaten (Kunden-/Systempasswörter)
Ebene: SyRS
Typ: funktional/Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Techniker, IT
Vorbedingung: Benutzer besitzt Password-Manager-Rechte
Fakt: PasswordManagerBL.cs (u. a. :229–278, :766–778) trennt Rechte für Richtlinien-Verwaltung (ACCESS_GUIDELINE_MANAGEMENT) und Bereichs-Verwaltung (ACCESS_AREA_MANAGEMENT); ein Export aller Zugangsdaten erfordert EXPORT_ACCESS_AND_PASSWORD_DATA (:899, :935); PasswordManagementArea ergänzt die Verwaltungslogik.
Aussage: Das System soll Zugangsdaten verwaltet ablegen, die Bearbeitung von Richtlinien/Bereichen rechtlich trennen und den Vollabzug der Daten ausschließlich mit einem Hochsicherheitsrecht erlauben.
Ergebnis: Zugangsdaten sind kontrolliert zugänglich; Exporte sind privilegiert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs:899/:935 (HasUserRight EXPORT_ACCESS_AND_PASSWORD_DATA vor Export) – durchsetzende Stelle
- [PRIMÄR] Ebendort :229–278 (ACCESS_GUIDELINE_MANAGEMENT-Prüfungen) – durchsetzende Stelle
Prüfidee: Export ohne EXPORT_ACCESS_AND_PASSWORD_DATA-Recht wird abgelehnt.
Tracelinks: StRS-014
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen – Verschlüsselung der Ablage in Folgeiteration prüfen
Status: belegt
```
```
ID: SyRS-030
Titel: Zentrales Datenmodell für Asset-Management & Monitoring
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal: Wartbarkeit
Akteur: System, MSP-Techniker
Vorbedingung: Monitoring-Dienst meldet Daten
Fakt: Das Schema führt für ca. 200 technische Domänen eigene Tabellenfamilien unter AssetManagement* (Geräte, Checks inkl. Ergebnis-Historie AssetManagementCheckResultsHistory, Lizenzen, AD-/DNS-/DHCP-/IIS-/SQL-/Hyper-V-/Exchange-Inventur, SNMP-MIBs, Dokumentationsvorlagen) plus MonitoringServiceSettings; AccountDevicesToTickets verknüpft Geräte mit Tickets.
Aussage: Das System soll technische Assets und Monitoring-Ergebnisse in einem strukturierten, historisierenden Datenmodell führen, aus dem Kundeninventar und Störungs-Tickets abgeleitet werden können.
Ergebnis: Nachvollziehbare Ist-Aufnahme und Verlauf je Kundenumgebung.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AssetManagementDevices, AssetManagementChecks, AssetManagementCheckResults, AssetManagementCheckResultsHistory, MonitoringServiceSettings – Datenmodell
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AccountDevicesToTickets – Verknüpfung Gerät↔Ticket
Prüfidee: Check-Ergebnis erzeugt History-Eintrag; Gerät bleibt Ticket zuordenbar.
Tracelinks: StRS-012, StRS-006
Konsolidierung: Kandidat: Zusammenführen mit Stammblatt/GeraeteKopf (StRS-004, SwRS-017)
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: SyRS-031
Titel: Outlook-/Office-Integration (Add-in, Exchange-Inventur)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal: -
Akteur: Anwender
Vorbedingung: Outlook/Exchange ist angebunden
Fakt: Es existiert ein eigenes Outlook-Add-in (src/nexus/CentronNexus.OutlookAddIn) sowie BL/Outlook und der Nexus-Bereich Office; das Asset-Datenmodell inventarisiert Exchange-Postfächer (AssetManagementEWSMailBoxes, AssetManagementExMailboxs inkl. Statistiken/Berechtigungen).
Aussage: Das System soll E-Mails/Termine kontextbezogen zwischen Outlook und ERP austauschen und Exchange-Bestände inventarisieren.
Ergebnis: Kommunikation ist dem Geschäftsobjekt zugeordnet; Exchange-Inventar ist erfasst.
Belege:
- [SEKUNDÄR] src/nexus/CentronNexus.OutlookAddIn/, src/backend/Centron.BL/Outlook/, src/nexus/CentronNexus/Office/ – Integrationspunkte
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AssetManagementEWSMailBoxes, AssetManagementExMailboxs – Exchange-Inventur
Prüfidee: Aus Outlook heraus wird eine Mail einem Ticket/Kunden zugeordnet.
Tracelinks: StRS-001, SyRS-023
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
```
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Ergebnisse/Traceability.md
+44
View File
@@ -0,0 +1,44 @@
# Traceability (konsolidiert)
Kette: StRS (fachlich) → SyRS (System) → SwRS (Software). Einträge nach SwRS geführt; zusätzliche SyRS→StRS-Beziehungen am Ende. Artefaktbeleg = wichtigster PRIMÄR-Beleg der jeweiligen Kette.
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|---|
| StRS-001 | SyRS-003 | SwRS-010 | src/backend/Centron.BL/Accounts/AccountAddressBL.cs:259–317 |
| StRS-002 | SyRS-004 | SwRS-006 | src/.../ReceiptSearch/InvoiceReceiptSearchConfiguration.cs:152–157 |
| StRS-002 | SyRS-004 | SwRS-009 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284 |
| StRS-003 | SyRS-019 | SwRS-001 | SSMS_DB_SCHEMA.sql (Kopf/Pos-Tabellen je Belegart) |
| StRS-003 | SyRS-019/020/021 | SwRS-005 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs :9043/:9113 |
| StRS-003 | – | SwRS-033 | src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs |
| StRS-004 | SyRS-019 | SwRS-017 | src/.../ClickContracts/MasterDataListBL.cs:163 |
| StRS-005 | SyRS-019 | SwRS-011 | src/.../AutomaticFactura/AutomaticFacturaWebServiceBL.cs (:124/:2370) |
| StRS-006 | SyRS-003 | SwRS-002 | SSMS_DB_SCHEMA.sql (hlpdsk_*-Tabellen) |
| StRS-006 | SyRS-003/004 | SwRS-021 | src/.../CentronChecklistWebserviceBL.cs:160–162 |
| StRS-006 | SyRS-003 | SwRS-025/SwRS-026 | SSMS (CRMProjekt); NexusTicketViewWebServiceBL.cs:44–124 |
| StRS-007 | – | SwRS-002 | SSMS (hlpdsk_timer); HelpdeskTimerWebServiceBL.cs:359–374 |
| StRS-008 | SyRS-003 | SwRS-018 | src/backend/Centron.BL/Warehousing/BarcodeBL.cs:1091 |
| StRS-008 | SyRS-003 | SwRS-019 | src/backend/Centron.BL/Warehousing/ArticleBL.cs:999–1081 |
| StRS-008 | – | SwRS-022/SwRS-023 | SSMS (ArticleProductionOrders, Lagerort/Lagerplatz) |
| StRS-009 | SyRS-012 | SwRS-006 | SupplierOrderReceiptSearchConfiguration.cs:138–140 |
| StRS-010 | SyRS-012/013 | – | src/backend/Centron.BL/EDI/{EDIDispatcherBL.cs, Zugferd/} |
| StRS-011 | SyRS-016/027 | – | src/apis/Centron.APIs.FinAPI; SSMS (Mahnlauf) [SyRS-027: HYPOTHESE] |
| StRS-012 | SyRS-030 | – | SSMS (AssetManagement*-Tabellenfamilie) |
| StRS-013 | SyRS-010/011 | SwRS-012/SwRS-031 | WebAccountBL.cs:56/:192/:415/:480; TradePoolBL.cs:170 |
| StRS-014 | SyRS-002 | SwRS-015 | src/webservice/Centron.Controllers/Authorization/*.cs |
| StRS-014 | SyRS-003 | SwRS-007/SwRS-008 | Administration/Rights/AppRightsBL.cs; ScriptMethod11783.cs |
| StRS-014 | SyRS-005/006 | SwRS-013/SwRS-014/SwRS-030 | Auth/Authenticator.cs:161; TwoFactorAuthenticationBL.cs; TwoFactor/*.cs |
| StRS-014 | SyRS-024/029 | – | ArtificialIntelligenceChatWebServiceBL.cs:90; PasswordManagerBL.cs:899 |
| StRS-015 | SyRS-018 | – | ReportDataWebBL.cs:496; ReportEngine/ReportGroupBL.cs:402 |
| – | SyRS-001 | SwRS-029/SwRS-032 | Controllers/v1/*; c-entron.misc.ConnectionManager |
| – | SyRS-007 | SwRS-003/SwRS-004/SwRS-028/SwRS-035 | SSMS_Zählung; Centron.DAO/*; Mappings/* |
| – | SyRS-008/026 | – | src/webservice/Centron.Host.*; global.json, Directory.Build.props |
| – | SyRS-010 | SwRS-022 | src/nexus/CentronNexus/ProductionOrderManagement |
| – | SyRS-019 | SwRS-034 | HelpdeskTimerLogBL.cs:183; ChangeTracking/ |
| – | SyRS-023 | SwRS-027 | TextModuleArea/TextModuleBL.cs; Mail/VariableReplacement |
| – | SyRS-028 | – | SSMS (Mandant, Filiale) [HYPOTHESE] |
## Hinweise zur Kette
- Jede SwRS-Anforderung trägt im Feld `Tracelinks` mindestens eine SyRS-ID (oder bei rein fachlichen Ketten die StRS-ID mit Durchgriff über die genannte SyRS-Belegfamilie; siehe Tabelle „–" dort, wo eine informationelle Querverbindung ohne eigene SyRS-Anforderung besteht: SwRS-024, -025, -033).
- HYPOTHESE-markierte Ketten: SyRS-027, SyRS-028, SwRS-003, SwRS-030, SwRS-031 (siehe Hypothesen.md).
- Forward-Trace: StRS-003 ist die Ursprungsanforderung der Belegfamilie SyRS-019/020/021 → SwRS-001/005/006; StRS-014 ist die Ursprungsanforderung des Sicherheits-Trace-Clusters SyRS-002–006/024/029 → SwRS-007/008/012–015/030.
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Protokoll.md
+117
View File
@@ -0,0 +1,117 @@
# Messprotokoll – Versuch 01 – Prompt-Version 02
## Lauf
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
- **Prompt-Version:** 02
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
- **Startzeit:** 2026-08-28T05:54:57Z
- **Endzeit:** 2026-08-28T06:52:30Z
- **Dauer gesamt:** 00:57:33 (API: nicht separat messbar)
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
- **Codebasis-Commit:** `37275c96` (dirty: nein, 0 Änderungen)
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
- **Prompt-Repo-Commit:** `37275c96d610a8b7958d126bebe4ef8d580c0bde`
## Werkzeugkonfiguration
- **Skill-Version:** v8.0.0
- **Werkzeugadapter:** Python API (TensorX Gateway)
- **CLI-Version:** Python 3.13.15, requests 2.34.2, Adapter-Skript v1.1.0
- **CLI-Pfad:** `c:\DEV\MasterArbeit\.claude\skills\run-experiment\glm-kimi-adapter.py`
- **Modell (angefordert):** `moonshotai/kimi-k3`
- **Modelle (tatsächlich eingesetzt):** `moonshotai/kimi-k3` (100 % der Tokens)
- **Kontrolle Modell:** bestanden
- **Effort:** high (per `--effort high`; Kimi `reasoning_effort` = `high`)
- **Laufverzeichnis-ID:** `v8.0.0-6bdf`
- **Ablage:** `Iteration 6/moonshotai/kimi-k3/builtin/high/`
- **Parallele Läufe:** nein
- **Agentenmodus:** builtin (V1b) – eingebaute Subagenten erlaubt
- **Kontextfenster:** nicht erfasst
- **Sampling-Parameter:** Temperatur 1.0; Reasoning-Effort high
- **Permission-/Sandbox-Modus:** Kommando-Denylist im Adapter
- **Toolfreigabe:** `read_file`, `list_directory`, `search_files`, `execute_command`, `write_file`, `spawn_subagent`
- **Isolationsmechanismus:** Eigenständiges Python-Skript, Pfad-Sicherheit, Denylist, bereinigter Snapshot
- **MCP-Server / Agentendateien:** keine
- **Subagenten:** 8 gestartet (3 completed, 5 failed), alle Typ `explore`
- **Verschachtelung:** `spawned` = 8, `max_depth` = 1 (keine rekursiven Subagenten)
## Validierungsstichprobe
- **Größe:** noch nicht festgelegt
- **Stand:** noch nicht gezogen
## Verbrauch
### Hauptagent inkl. Subagenten (`usage`, abrechnungsrelevant)
**Token-Werte validiert gegen TensorX-Abrechnungs-CSV** (`usage-2026-07-29-to-2026-08-28.csv`):
148 API-Aufrufe im Zeitfenster 07:54:57–08:52:30 CEST, Modell `moonshotai/kimi-k3`, App `python-requests`.
Alle vier Token-Metriken stimmen exakt überein (Differenz = 0).
| Messgröße | Adapter (RawResult.json) | TensorX CSV | Differenz |
|---|---:|---:|---:|
| Input-Tokens | 5.555.247 | 5.555.247 | 0 ✅ |
| Output-Tokens | 149.450 | 149.450 | 0 ✅ |
| davon Reasoning-Tokens | 28.912 | (nicht in CSV) | — |
| Cache-Read-Tokens | 4.371.456 | 4.371.456 | 0 ✅ |
| Cache-Write-Tokens | nicht erfasst | nicht in CSV | — |
| **Tokens gesamt** | **5.704.697** | **5.704.697** | **0 ✅** |
| Agent-Turns (Hauptagent) | 28 | — | — |
| API-Aufrufe gesamt | 148 | 148 | — |
| Kosten (USD) | nicht im Protokoll | $9,07 | — |
| Cache-Trefferquote | 78,7 % | 78,7 % | — |
| Durchschn. Geschwindigkeit | — | 52,4 TPS | — |
Tokens gesamt inkl. aller 8 Subagenten. Subagent-Token vollständig akkumuliert.
Die 148 API-Aufrufe verteilen sich auf: 28 Hauptagent-Turns + ~120 Subagent-Turns (8 Subagenten × ~15 Turns).
## Gefundene Anforderungen
### Verteilung über die Ebenen
| Ebene | Anzahl | Anteil |
|---|---:|---:|
| StRS | 15 | 18,5 % |
| SyRS | 31 | 38,3 % |
| SwRS | 35 | 43,2 % |
| **Gesamt** | **81** | 100 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 180 |
| davon `PRIMÄR` | 91 (50,6 %) |
| davon `SEKUNDÄR` | 77 (42,8 %) |
| davon `KONTEXT` | 12 (6,7 %) |
| Belege je Anforderung (Median) | 2 |
| Anforderungen mit mind. einem `PRIMÄR`-Beleg | 67 (82,7 %) |
### Status
| Kategorie | Anzahl |
|---|---:|
| belegt | 76 (93,8 %) |
| `HYPOTHESE` | 5 (6,2 %) |
| Konsolidierungskandidaten | 7 (8,6 %) |
| ISO-25010-Qualitätsmerkmal | 81 (100 %) |
### Regelkonformität
| Vorgabe | Ergebnis |
|---|---|
| Belegpflicht | **erfüllt** (0 ohne Beleg) |
| Risikobasierte Priorisierung | **erfüllt** (34 risikorelevant, alle gedeckt) |
| Verifizierbarkeit | **erfüllt** |
| Übernahmewürdigkeit | **erfüllt** (alle 81) |
| Traceability | 81/81 (100 %) |
## Ergebnis
- **Status:** erfolgreich
- **Session-ID:** nicht erfasst
- **Permission-Denials:** nicht erfasst
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 8 (builtin: korrekt)
- **Gültigkeit:** gültig – 7 Ergebnisdateien, Stderr.log enthält Abbruchmeldungen der Subagenten (UnicodeDecodeError), aber der Hauptlauf war erfolgreich
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
- **Root unverändert:** ja
- **Anmerkungen:**
- Erster Lauf mit `builtin`-Modus (V1b) im Python-API-Adapter.
- 8 Subagenten gestartet, davon 5 fehlgeschlagen (UnicodeDecodeError: cp1252 vs UTF-8 bei Shell-Kommandoausgabe). Bug nachträglich behoben (`encoding='utf-8'` in subprocess.run).
- Tokenverbrauch (5,7 Mio.) 2,6× höher als GLM-Solo (2,17 Mio.) – Effekt der Subagenten-Delegation.
- Primärbelegquote (82,7 %) niedriger als GLM-Solo (98,9 %) – möglicherweise wegen der fehlgeschlagenen Subagenten.
- SwRS-Anteil höher (43,2 % vs 22,2 % bei GLM-Solo) – andere Schwerpunktsetzung durch Subagenten-Delegation.
- Dauer ~58 Min deutlich länger als GLM-Solo (5:39 Min) – jeder Subagent führt eigene API-Aufrufe durch.
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/RawResult.json
+919
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/Stderr.log
+51
View File
@@ -0,0 +1,51 @@
[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
[glm-kimi-adapter] Start: 2026-08-28T05:54:57.975695+00:00
[glm-kimi-adapter] Provider: TensorX API Gateway
[glm-kimi-adapter] Modell: moonshotai/kimi-k3
[glm-kimi-adapter] Effort: high
[glm-kimi-adapter] Mode: builtin
[glm-kimi-adapter] Subagent 1 gestartet (Typ: explore)
[glm-kimi-adapter] Subagent 2 gestartet (Typ: explore)
[glm-kimi-adapter] Subagent 3 gestartet (Typ: explore)
[glm-kimi-adapter] Subagent 4 gestartet (Typ: explore)
[glm-kimi-adapter] Subagent 5 gestartet (Typ: explore)
Exception in thread Thread-27 (_readerthread):
Traceback (most recent call last):
File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 1044, in _bootstrap_inner
self.run()
~~~~~~~~^^
File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 995, in run
self._target(*self._args, **self._kwargs)
~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\subprocess.py", line 1615, in _readerthread
buffer.append(fh.read())
~~~~~~~^^
File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 460: character maps to <undefined>
Exception in thread Thread-33 (_readerthread):
Traceback (most recent call last):
File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 1044, in _bootstrap_inner
self.run()
~~~~~~~~^^
File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 995, in run
self._target(*self._args, **self._kwargs)
~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\subprocess.py", line 1615, in _readerthread
buffer.append(fh.read())
~~~~~~~^^
File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 6263: character maps to <undefined>
[glm-kimi-adapter] Subagent 6 gestartet (Typ: explore)
[glm-kimi-adapter] Subagent 7 gestartet (Typ: explore)
[glm-kimi-adapter] Subagent 8 gestartet (Typ: explore)
[glm-kimi-adapter] Ende: 2026-08-28T06:52:30.647891+00:00
[glm-kimi-adapter] Turns: 28
[glm-kimi-adapter] Tokens gesamt: 5,704,697
[glm-kimi-adapter] Tool-Calls: 102
[glm-kimi-adapter] Subagenten: 8 (completed: 3, failed: 5)
[glm-kimi-adapter] Ergebnisdateien: 7
[glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 6\moonshotai\kimi-k3\builtin\high\02_Lauf_2026-08-28_075453_v8.0.0-6bdf\RawResult.json
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/_meta/after.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/_meta/anforderungen.json
+1640
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/_meta/anforderungen.md
+71
View File
@@ -0,0 +1,71 @@
## Gefundene Anforderungen
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
### Verteilung über die Ebenen
| Ebene | Anzahl | Anteil |
|---|---:|---:|
| StRS | 15 | 18,5 % |
| SyRS | 31 | 38,3 % |
| SwRS | 35 | 43,2 % |
| **Gesamt** | **81** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 27 | 33,3 % |
| Sicherheit | 15 | 18,5 % |
| Schnittstelle | 9 | 11,1 % |
| Daten | 8 | 9,9 % |
| nicht-funktional | 7 | 8,6 % |
| funktional/Sicherheit | 6 | 7,4 % |
| Schnittstelle/Sicherheit | 2 | 2,5 % |
| Sicherheit/funktional | 2 | 2,5 % |
| Daten/Sicherheit | 2 | 2,5 % |
| Daten/nicht-funktional | 1 | 1,2 % |
| (2 weitere) | 2 | 2,5 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 180 |
| davon `PRIMÄR` | 91 (50,6 %) |
| davon `SEKUNDÄR` | 77 (42,8 %) |
| davon `KONTEXT` | 12 (6,7 %) |
| Belege je Anforderung (Median) | 2 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 67 (82,7 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 78 | 96,3 % |
| workaround | 1 | 1,2 % |
| sonderfall | 1 | 1,2 % |
| veraltet | 1 | 1,2 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 76 | 93,8 % |
| als `HYPOTHESE` gekennzeichnet | 5 | 6,2 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 7 | 8,6 % |
| mit ISO-25010-Qualitätsmerkmal | 81 | 100,0 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (34 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 81 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 81 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/_meta/before.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/_meta/combined_prompt.md
+183
View File
@@ -0,0 +1,183 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-26
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
### Pflicht-Eigenschaften jeder Anforderung
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
- **Belegklassifikation:** Kennzeichne jeden Beleg als
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
### Formatvorgabe pro Anforderung
```
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
Titel: <kurzer Titel>
Ebene: <StRS | SyRS | SwRS>
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur: <Rolle / System / Komponente>
Vorbedingung: <Zustand vor Auslösen>
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
Belege:
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
- [SEKUNDÄR] <...> - Begründung: <...>
- [KONTEXT] <...> - Begründung: <...>
Prüfidee: <Akzeptanzkriterium oder Testidee>
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status: <belegt | HYPOTHESE>
```
### Traceability
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
### Nicht-funktionale Anforderungen
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
### Konsolidierungsbedarf
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
```
Ergebnisse/
StRS.md
SyRS.md
SwRS.md
Traceability.md (oder Traceability.csv)
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
Selbstbewertung, bekannte Lücken)
```
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
Zusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.
Nicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.
Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
Verfuegbare Werkzeuge:
- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
- list_directory: Listet Verzeichnisinhalte auf
- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
- spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only)
### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
$laufDir\Ergebnisse\.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-28T08:52:30.7500020+02:00
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/_meta/laufinfo.json
+8
View File
@@ -0,0 +1,8 @@
{
"modell": "moonshotai/kimi-k3",
"modus": "builtin",
"iteration": "Iteration 6",
"effort": "high",
"promptHash": "F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849",
"skillVersion": "v8.0.0"
}
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/builtin/high/02_Lauf_2026-08-28_075453_v8.0.0-6bdf/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-28T07:54:53.3681267+02:00
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/Analysebericht.md
+244
View File
@@ -0,0 +1,244 @@
# Analysebericht - RRE der c-entron ERP-Suite (V1 Baseline, Iteration 02)
Erzeugt durch statische Analyse der Codebasis (keine Ausfuehrung). Werkzeuge:
Verzeichnislistung, Dateizugriff, Regex-Suche, lesende Shell-Kommandos.
Ergebnisdateien: StRS.md, SyRS.md, SyRS-Ergaenzungen.md, SwRS.md,
SwRS-Ergaenzungen.md, Traceability.md, Hypothesen.md, Glossar.md, Analysebericht.md.
Die beiden Ergaenzungsdateien sind integrale Fortsetzung der jeweiligen Spezifikation
(ID-Reihen: SyRS 001-036 in SyRS.md, SyRS 037-042 in SyRS-Ergaenzungen.md; SwRS 001-028
in SwRS.md, SwRS 029-040 in SwRS-Ergaenzungen.md).
Gesamtumfang: StRS 15 | SyRS 42 | SwRS 40 = 97 Anforderungen.
Status: 95 belegt, 2 HYPOTHESE (SwRS-033, SwRS-038).
---
## 1. Schritt 0 - Modulinventar (vor der ersten Anforderung)
| # | Fachliches Modul | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe (1 Satz) |
|---|---|---|---|
| 1 | Geschaeftspartnerstamm (Kunden/Lieferanten) | src/backend/Centron.BL/Accounts, CustomerArea, BusinessPartner | Fuehren von Kunden und Lieferanten samt Anschriften, Ansprechpartnern, Filialzuordnung. |
| 2 | Artikelverwaltung | src/backend/Centron.BL/Warehousing (ArticleBL, ArticleManagement, TaxBL) | Pflege von Artikelstamm, Preisen, Einheiten, Stuecklisten. |
| 3 | Barcode-/Seriennummernverwaltung | src/backend/Centron.BL/Warehousing (BarcodeBL, BarcodeHistoryBL) | Erfassung und Historie von Seriennummern ueber den Lebenszyklus. |
| 4 | Lagerverwaltung/Inventur | src/backend/Centron.BL/Warehousing (StockManagement, InventoryManagement) | Lagerbestaende, Nebenlager, Inventuren mit Zaehlgruppen. |
| 5 | Kommissionierung | src/backend/Centron.BL/Warehousing (Commissions, CommissioningManagement) | Kommissionierung von Auftraegen inklusive Teilmengen. |
| 6 | Einkauf/Bestellwesen | src/backend/Centron.BL/{Buying|Purchasing}; SSMS BestKopf2/WareKopf/KalkKopf | Beschaffungskette Bestellung, Wareneingang, WE-Kalkulation. |
| 7 | Vertriebsbelege (Angebot..Gutschrift) | src/backend/Centron.BL/Sales/Receipts | Vertriebliche Belegkette mit Versionierung, Storno, Festschreibung. |
| 8 | Beleg-Warenkorb/Freigaben | src/backend/Centron.BL/Sales/Receipts (ReceiptCartBL, ReceiptCartReleaseSystemBL) | Warenkorb-basierte Beleggenerierung und Freigabeworkflow. |
| 9 | Vertragsmanagement | src/backend/Centron.BL/Sales/Receipts/ContractLists, LeasingAndService; SSMS Vertrag* | Click-, Leasing-, Wartungsvertraege mit automatisierter Abrechnung. |
| 10 | Mahnwesen/OPOS | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning, Opos | Mahnlaeufe bis Stufe 3 und Offene-Posten-Auswertung. |
| 11 | Kassenbuch | src/backend/Centron.BL/Sales/CashBooks | Historisches Kassenbuchmodul (Rechte [Obsolete]). |
| 12 | Provisionsabrechnung | src/backend/Centron.BL/Sales/Receipts (ReceiptProvision*BL) | Provisionsschemata und Zielueberwachung an Belegen. |
| 13 | Kundenanlagen/Stammblaetter | src/backend/Centron.BL/Sales/CustomerAssets | Kundenanlagen (Geraetekarten) mit Historie, Sperrung, Vertragsbezug. |
| 14 | Zeitwirtschaft | src/backend/Centron.BL/Time, Sales/HourlySurchargeRatesBL | Arbeitszeiten, Stundenzueschlaege, Helpdesk-Timer-Abrechnung. |
| 15 | Helpdesk/Tickets | src/backend/Centron.BL/Sales/Support; SSMS hlpdsk_* | Ticketing mit Kategorien, Prioritaeten, Zeiten, Historie, Eskalation. |
| 16 | C-FLOW Ticketvorlagen | src/nexus/CentronNexus/Management/TicketPatterns | Ticketvorlagen mit Checklisten, Formularen, Mails, Skripten. |
| 17 | Externer Helpdesk | src/backend/Centron.BL/ExternalHelpdesk | Sicht externer Beteiligter auf den Helpdesk. |
| 18 | Ruecksendung/RMA/Reparatur | SSMS Rma; UserRightsConst RMA-*; WPF-Modul Rma | RMA-Faelle und Reparatureingang. |
| 19 | CRM/Marketing/Sonderaktionen | src/backend/Centron.BL/Sales/Marketing | Marketingaktionen, Telemarketing, CRM-Projekte, Kontakte. |
| 20 | Projektverwaltung | src/backend/Centron.BL/Projects, TicketProjects; WPF ProjectPriceImport | Vertriebsprojekte und Projektpreis-Import. |
| 21 | Kalender/Terminplanung | src/backend/Centron.BL/Calendar; SSMS Terminplanung* | Kalender, Mein Tag, Zeitkonten (Urlaub/Krankheit/Kurzarbeit). |
| 22 | Personalverwaltung | src/backend/Centron.BL/EmployeeArea; SSMS Personal* | Mitarbeiter- und Gruppenverwaltung inkl. Auslastung. |
| 23 | Finanzen/Zahlungsverkehr | src/backend/Centron.BL/Finances, Accounting | Zahlungsein- und -ausgaenge, Bankkonten. |
| 24 | Online-Banking/FinAPI | src/backend/Centron.BL/Finances/OnlineBanking; src/apis/Centron.APIs.FinAPI | Kontoauszuege via FinAPI und Zuordnung zu Zahlungseingaengen. |
| 25 | Buchhaltungsschnittstellen | src/backend/Centron.BL/DataExchange/BookKeeping | Ex-/Import zu Buchhaltungssystemen mit Exportkennzeichen. |
| 26 | Datenaustausch/EDI | src/backend/Centron.BL/DataExchange, EDI | EDI-Gateway, Logs, Dispatcher, Exports. |
| 27 | Versanddienstleister | src/apis/Centron.Api.Gls, Centron.Api.Shipcloud; ShipcloudPackageTemplateBL | Paketlabel und Frachtdaten ueber Carrier. |
| 28 | E-Rechnung | src/apis/Centron.Api.EbInterface; Centron.Gateway.OpenTrans | ebInterface/OpenTrans-Integration. |
| 29 | Artikeldatenintegration | src/apis/Centron.APIs.{ITscope|Icecat|Cop|Egis}DataAccess; ArticleImport* | Katalog-/Distributor-Import und Preisaktualisierung. |
| 30 | DMS/Doku | src/backend/Centron.BL/Administration/FileManagement, DocumentationArea; Centron.Api.docuFORM | Ablage, Verzeichnisrechte, docuFORM-Formularveredelung. |
| 31 | Report/Statistik | src/backend/Centron.BL/{ReportEngine|Reporting|Statistics} | Reports, Statistiken, Auswertungen. |
| 32 | Textbausteine | src/backend/Centron.BL/TextModuleArea | Zentral gepflegte Textbausteine. |
| 33 | Mail/Kommunikation | src/backend/Centron.BL/{Mail|Mailings|MailScanner|Outlook|Chats|Notifications|SocialMedia|VideoPortal|Tapi|WebLinks|NexusNotifications} | Mail, Chat, Benachrichtigungen, Social Media, TAPI. |
| 34 | IT-Asset-Inventarisierung | SSMS AssetManagement* (ca. 180 Tabellen); BL Devices, RiverDivo (veraltet) | Inventarisierung und Monitoring von IT-Infrastruktur. |
| 35 | IT-Planung | src/backend/Centron.BL/ItPlanner | IT-Infrastruktur-Planung mit Checklisten. |
| 36 | WebSuite-Altplattform | src/backend/Centron.BL/WebSuite | Veralteter Webshop/Webhelpdesk (Rechte [Obsolete]). |
| 37 | Nexus Kundenportal/WebCart | src/nexus/CentronNexus/WebCart | Endkundenshop sowie Kundenportal (Belege, Vertraege, Tickets). |
| 38 | Nexus Outlook-AddIn | src/nexus/CentronNexus.OutlookAddIn | Outlook-Kopplung an Tickets, CRM, Belege, Dokumente. |
| 39 | Nexus interne Module | src/nexus/CentronNexus/{Management|DocumentSigning|ProductionOrderManagement|Office|WebOffer|WebVersion} | Adminmodule, Dokumentsignatur, Produktionssteuerung im Web. |
| 40 | REST-Webservice/Auth-Plattform | src/webservice/*; src/backend/Centron.BL/WebServices, Administration/Logins | REST-API mit Ticket-, JWT- und 2FA-Authentifizierung. |
| 41 | Lizenzierung | src/backend/Centron.BL/Administration/Licensing | Herstellerlizenz vor Datenbankbetrieb erzwingen. |
| 42 | System-/DB-Verwaltung/Skripte | src/backend/Centron.BL/Administration/{Scripts|Settings|...}; SQLScriptCollection4.xml | Schema-Migration, Einstellungen, Systeminformation. |
| 43 | DSGVO | UserRightsConst.DsgvoModule; PasswordManagementArea | Rechtegesteuerter Datenschutz- und Bereinigungsprozess. |
| 44 | Passwortmanager | src/backend/Centron.BL/PasswordManager | Zentraler Passworttresor mit Exportrechten. |
| 45 | Selbstbedienung/MyCentron/MyDay | src/backend/Centron.BL/{SelfCare|MyCentron|MyDay|ToDoArea|TaskManager|AppointmentRequests} | To-Dos, Mein Tag, Aufgaben, Terminanfragen. |
| 46 | KI-Modul | src/backend/Centron.BL/ArtificialIntelligence; SSMS ArtificialIntelligencePrompt* | Rechtegesteuerte KI-Assistenz mit Prompt-Konfiguration. |
| 47 | Massenupdate/Datenqualitaet | src/backend/Centron.BL/MassUpdate; HostedService MassUpdateService/DataQualityService | Zeitgesteuerte Massenupdates und Qualitaetspruefung. |
| 48 | Erwartete Ereignisse | src/backend/Centron.BL/ExpectedEvents | Erfassung und Auswertung erwarteter Geschaeftsereignisse. |
| 49 | Aenderungsverfolgung/Audit | src/backend/Centron.BL/ChangeTracking; DAO/ChangeTracking; ReceiptLogBL | Feld- und Beleg-Auditing. |
| 50 | Gutscheinverwaltung (alt) | src/backend/Centron.BL/VoucherManagement | Alt-Gutscheinmodul (Rechte [Obsolete]). |
| 51 | WPF-Desktopclient | src/centron/Centron.WPF.UI (Modules, ViewModels, Views) | Desktop-Shell fuer die Module (Ribbon, Rechte-Parser). |
| 52 | Gemeinsame UI-/Core-Bibliotheken | src/shared/* (Controls, Core) | Wiederverwendete UI-Controls und Core-Typen. |
| 53 | Persistenzschicht | src/backend/Centron.DAO, Centron.Entities | NHibernate-DAO, Entities, Sessions, Transaktionen. |
| 54 | Mobile Erfassung | src/backend/Centron.BL/Mobile; DAO/Mobile | Serverseitige Logik mobiler Erfassung. |
| 55 | Querschnitt/Erweiterbarkeit | src/backend/Centron.BL/{Tags|Processes|CPra|Customizations|Tools|ExternalToolsBL|Transactions} | Tags, Workflows, CPra, Anpassungen. |
| 56 | Mandantenfuehrung | SSMS Mandant; CustomerToBranches, LieferantenToFiliale | Mandanten- und Filial-Verankerung im Schema. |
---
## 2. Abdeckungstabelle (Schritt 0b/0c)
Einstufung: tief = Kernlogik mit durchsetzender Stelle gelesen; mittel = Einzelbelege
gelesen; flach = ueber Rechte/Schema gesichert.
| # | Modul | Einstufung | Anz. Anf. | Abgedeckt durch (IDs) |
|---|---|---|---|---|
| 1 | Geschaeftspartnerstamm | mittel | 3 | StRS-002, StRS-003, SyRS-018 |
| 2 | Artikelverwaltung | mittel | 2 | StRS-009, SwRS-013 |
| 3 | Barcode/Seriennummern | flach | 1 | SyRS-019 |
| 4 | Lager/Inventur | flach | 2 | StRS-009, SyRS-021 |
| 5 | Kommissionierung | flach | 1 | StRS-009 |
| 6 | Einkauf/Bestellwesen | mittel | 1 | SyRS-020 |
| 7 | Vertriebsbelege | tief | 9 | StRS-004, SyRS-010, SyRS-011, SyRS-012, SyRS-013, SwRS-003, SwRS-009, SwRS-010, SwRS-012 |
| 8 | Beleg-Warenkorb/Freigaben | flach | 1 | StRS-011 (ReceiptCart-BL gesichtet, nicht vertieft) |
| 9 | Vertragsmanagement | tief | 4 | StRS-005, SyRS-016, SyRS-022, SwRS-010 |
| 10 | Mahnwesen/OPOS | tief | 3 | StRS-008, SyRS-014, SyRS-015 |
| 11 | Kassenbuch | mittel | 1 | SwRS-020 |
| 12 | Provisionsabrechnung | flach | 1 | SyRS-016 |
| 13 | Kundenanlagen/Stammblaetter | mittel | 4 | StRS-010, SyRS-024, SwRS-006, SwRS-016 |
| 14 | Zeitwirtschaft | mittel | 3 | StRS-007, SyRS-017, SwRS-025 |
| 15 | Helpdesk/Tickets | tief | 6 | StRS-006, SyRS-009, SyRS-021, SwRS-017, SwRS-018, SwRS-021 |
| 16 | C-FLOW Ticketvorlagen | mittel | 1 | SwRS-030 |
| 17 | Externer Helpdesk | nicht analysiert | 0 | Begruendung: Modulverzeichnis gesichtet, Kernlogik nicht rechtzeitig sicher gelesen; unbelegte Aussage wuerde gegen die No-Halluzination-Regel verstossen. |
| 18 | Ruecksendung/RMA/Reparatur | mittel | 1 | SyRS-037 |
| 19 | CRM/Marketing/Sonderaktionen | mittel | 2 | SyRS-038, StRS-013 |
| 20 | Projektverwaltung | flach | 1 | SyRS-042 |
| 21 | Kalender/Terminplanung | flach | 2 | SwRS-025, StRS-013 |
| 22 | Personalverwaltung | flach | 1 | StRS-002 |
| 23 | Finanzen/Zahlungsverkehr | mittel | 2 | SyRS-015, SyRS-040 |
| 24 | Online-Banking/FinAPI | mittel | 2 | SyRS-026, StRS-008 |
| 25 | Buchhaltungsschnittstellen | mittel | 2 | SyRS-015, SyRS-025 |
| 26 | Datenaustausch/EDI | mittel | 2 | SyRS-039, SyRS-008 |
| 27 | Versanddienstleister | flach | 1 | SyRS-028 |
| 28 | E-Rechnung | mittel | 1 | SyRS-025 |
| 29 | Artikeldatenintegration | flach | 1 | SyRS-027 |
| 30 | DMS/Doku | mittel | 2 | SyRS-033, SwRS-029 |
| 31 | Report/Statistik | flach | 2 | StRS-015, SyRS-035 |
| 32 | Textbausteine | flach | 1 | SwRS-026 |
| 33 | Mail/Kommunikation | flach | 4 | StRS-013, SyRS-034, SyRS-035, SwRS-037 |
| 34 | IT-Asset-Inventarisierung | mittel | 2 | StRS-010, SwRS-006 |
| 35 | IT-Planung | flach | 1 | StRS-010 |
| 36 | WebSuite-Altplattform | mittel | 1 | SwRS-034 |
| 37 | Nexus Kundenportal/WebCart | mittel | 2 | StRS-011, SyRS-031 |
| 38 | Nexus Outlook-AddIn | flach | 1 | SwRS-032 |
| 39 | Nexus interne Module | mittel | 3 | SwRS-031, StRS-014, SyRS-001 |
| 40 | REST-Webservice/Auth-Plattform | tief | 8 | SyRS-002, SyRS-003, SyRS-004, SyRS-005, SyRS-036, SwRS-023, SwRS-024, SyRS-008 |
| 41 | Lizenzierung | tief | 1 | SyRS-006 |
| 42 | System-/DB-Verwaltung | tief | 1 | SyRS-007 |
| 43 | DSGVO | mittel | 2 | StRS-012, SyRS-030 |
| 44 | Passwortmanager | mittel | 1 | SyRS-029 |
| 45 | Selbstbedienung/MyCentron | flach | 2 | SwRS-039, StRS-013 |
| 46 | KI-Modul | mittel | 2 | SyRS-032, SwRS-040 |
| 47 | Massenupdate/Datenqualitaet | flach | 2 | SwRS-027, StRS-015 |
| 48 | Erwartete Ereignisse | flach | 1 | SwRS-036 |
| 49 | Aenderungsverfolgung/Audit | flach | 2 | SwRS-011, SwRS-028 |
| 50 | Gutscheinverwaltung (alt) | mittel | 1 | SwRS-038 [HYPOTHESE] |
| 51 | WPF-Desktopclient | mittel | 1 | SwRS-014 |
| 52 | Gemeinsame Bibliotheken | flach | 1 | SwRS-019 |
| 53 | Persistenzschicht | mittel | 2 | SwRS-001, SwRS-002 |
| 54 | Mobile Erfassung | flach | 1 | SwRS-033 [HYPOTHESE] |
| 55 | Querschnitt/Erweiterbarkeit | flach | 2 | SwRS-037, StRS-013 |
| 56 | Mandantenfuehrung | mittel | 2 | StRS-012, SwRS-005 |
Mindestabdeckung: 55 von 56 Modulen haben mindestens eine Anforderung.
Nicht analysiert: 1 Modul (#17 ExternalHelpdesk, mit Begruendung).
---
## 3. Konsistenzcheck ueber das gesamte Anforderungs-Set
- Doppelte oder mehrfach vergebene IDs: keine. IDs im Format StRS-|SyRS-|SwRS-<Nr.>
einmalig; Ergaenzungsdateien setzen die jeweilige Nummernreihe nahtlos fort.
- Anforderungen ohne Beleg: keine. Jede der 97 Anforderungen fuehrt mindestens einen
klassifizierten Beleg mit Begruendung.
- Anforderungen ohne Uebernahmewuerdigkeit: keine. Das Feld ist in allen Anforderungen
mit Wert und Halbsatz-Begruendung gesetzt.
- Tracelinks auf nicht existierende IDs: Alle referenzierten IDs (StRS 001-015,
SyRS 001-042, SwRS 001-040) existieren. Hinweis: wenige Tracelinks sind inhaltlich
grob eingehangen (Hinweis- statt Parent-Verknuepfung), jedoch ohne Existenzverletzung.
- Deckungsgleiche Anforderungen ohne Kandidatenvermerk: keine verblieben. Markierte
Konsolidierungskandidaten: SwRS-003 (9 Kopf-/Pos-Tabellenpaare), SwRS-004
(Kunden/Kreditor vs. Accounts), SwRS-006 (Stammblatt vs. AssetManagement),
SyRS-024/SwRS-006 (gleiches Objekt auf 2 Ebenen), SyRS-028 (zwei Carrier),
SyRS-037 (RMA vs. Reparatur), SwRS-009 (God-Class), SwRS-020 (Kassenbuch alt),
SwRS-034 (Alt-Webs), SwRS-038 (Gutschein vs. Wertgutschrift).
- Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung,
Berechtigungen) mit Belegsituation:
| ID | Titel | PRIMAER-Beleg mit durchsetzender Stelle? | HYPOTHESE? |
|---|---|---|---|
| SyRS-003 | Ticket-Authentifizierung | ja (CentronHost.AddCentronTicket; TicketBL.GetTicket) | nein |
| SyRS-004 | JWT/OIDC-Login | ja (TokenValidationParameters; JwtAuthController-Authorize) | nein |
| SyRS-005 | 2FA per E-Mail | ja (TwoFactorAuthController.ValidateTwoFactorCode) | nein |
| SyRS-006 | Lizenz vor DB | ja (CentronHost.Start: TryLoadLicense vor SetupDatabaseConnection) | nein |
| SyRS-009 | Rechtepruefung Helpdesk/Stamm | ja (AccountAddressBL Z69/156-178; AccountBL Z501/1299) | nein |
| SyRS-010 | Rechnungsstorno | ja (ReceiptInvoiceBL.CancelInvoice Z143-205) | nein |
| SyRS-011 | Festschreibung IsFixed | ja (ReceiptInvoiceBL.FixInvoice; CheckIfInvoiceIsFixed) | nein |
| SyRS-012 | Belegversionierung | ja (Schema *Versions; CreateNewVersion in CancelInvoice) | nein |
| SyRS-013 | Statusmodell | ja (ReceiptState.cs) | nein |
| SyRS-014 | Mahnlauf | ja (DunningRunWebServiceBL.ValidateDunningRun; DunningRunBL) | nein |
| SyRS-015 | Exportsperre/Erloeskonto | ja (IsReceiptExported-Pruefung in CancelInvoice) | nein |
| SyRS-016 | Provisionsabrechnung | ja (UpdateExpiredProvisionSchemasService) | nein |
| SyRS-017 | Abgerechnete Zeiten sperren | ja (RemoveTimers in Transaktion; [KONTEXT] CentronRights) | nein |
| SyRS-018 | Geschaeftspartner-Rechte | ja (AccountBL.ValidateUserRights-Aufrufstellen) | nein |
| SyRS-019 | Seriennummern | ja (UserRightsConst SerialAdministration; Barcodes.Clear) | nein |
| SyRS-020 | Bestell-/WE-Kette | ja (Schema + Rechte) | nein |
| SyRS-021 | Inventur | ja (UserRightsConst.Inventory-Block) | nein |
| SyRS-024 | Anlagensperre | ja (MasterDataListBL DependencyCheckFailed; AssetLockBL) | nein |
| SyRS-026 | Online-Banking | ja (UserRightsConst.OnlineBanking; BL-Klassen) | nein |
| SyRS-029 | Passwortmanager-Export | ja (PasswordManagerBL.ValidateUserRights) | nein |
| SyRS-030 | DSGVO-Loeschung | ja (UserRightsConst.DsgvoModule) | nein |
| SyRS-032 | KI-Rechtebindung | ja (UserRightsConst.ArtificialIntelligence) | nein |
| SyRS-033 | DMS-Rechte | ja (DirectoryBL ruft AccountBL.ValidateUserRights) | nein |
| SwRS-010 | CreateNewVersion vor Storno | ja (Aufruf in CancelInvoice) | nein |
| SwRS-012 | Festschreibung SQL | ja (RawSqlAccess UPDATE RechKopf) | nein |
| SwRS-013 | Negativbuchung | ja (UserRightsConst.StockList) | nein |
| SwRS-018 | Helpdesk-Fingerprint | ja (AddHostedService<ValidateHelpdeskFingerprintService>) | nein |
| SwRS-022 | CORS AllowAnyOrigin | ja (UseCors in CentronHost.ConfigureInternal) | nein |
| SwRS-024 | WebServiceConfig-Geheimnisse | ja (WebServiceConfigHelper-Verwendung) | nein |
| SwRS-028 | Change Tracking/Audit | ja (SHOW_AUDIT; BL-/DAO-Verzeichnisse) | nein |
Verstoss gegen risikobasierte Priorisierung: keiner. Alle 31 risikorelevanten
Anforderungen besitzen mindestens einen PRIMAER-Beleg mit durchsetzender Stelle.
- Abgleich Hypothesen.md gegen Inline-Markierungen: Hypothesen.md listet exakt die
beiden Anforderungen mit Status HYPOTHESE (SwRS-033, SwRS-038); es existieren keine
weiteren Inline-Markierungen und keine zusaetzlichen freien Fragen. Deckungsgleich.
---
## 4. Selbstbewertung
1. Modulabdeckung (absolut): 56 Module - 7 tief (#7 Vertriebsbelege, #9 Vertrags-
management, #10 Mahnwesen, #15 Helpdesk, #40 Webservice/Auth, #41 Lizenzierung,
#42 Systemverwaltung) | 24 mittel | 24 flach | 1 nicht analysiert (#17).
2. Mindestabdeckung**: erreicht fuer 55 von 56 Modulen. Fehlend: #17 ExternalHelpdesk
(trotz Sichtung des Verzeichnisses; die Kernlogik wurde nicht rechtzeitig sicher
gelesen; eine unbelegte Aussage wurde bewusst unterlassen).
3. Stellen mit duennem Beleg (hoher Anteil SEKUNDAER/KONTEXT oder HYPOTHESE):
#1 (StRS-003, stark von CentronRights.md/Kontext abhaengig), #5 Kommissionierung,
#8 Beleg-Warenkorb, #20 Projektverwaltung, #27 Carrier, #29 Artikelimport,
#31 Statistik, #33 Mail/Kommunikation, #35 IT-Planung, #45 SelfCare, #48 ExpectedEvents,
#54 Mobile (HYPOTHESE), #55 Querschnitt.
4. Hypothesen: Es wurden 2 gefuehrt (SwRS-033 Mobile, SwRS-038 Gutschein). Die niedrige
Zahl spiegelt die priorisierte Vertiefung auf PRIMAER-Belege, ist nicht Beweis fuer
Vollstaendigkeit; offene Einzelfragen sind in Abschnitt 5 dokumentiert.
5. Nachschlagempfehlungen (Folgeiteration):
- ReceiptBL.cs (623.866 Bytes) und ReceiptItemBL.cs (230.597 Bytes): systematische
Extraktion von Preis-/Rundungs-, Steuer- und Freigabelogik (bisher nur Aufrufpfade).
- SQLScriptCollection1-4.xml: Views, Migrationen und Constraints (z. B.
cvw_DunningRunItems) als PRIMAER-Belege fuer Datenanforderungen nutzen.
- #17 ExternalHelpdesk, #8 ReceiptCartReleaseSystem-Freigabeworkflow,
#34 AssetManagement-Detail (Checks, Monitoring-Streams), Nexus WebOffer und
CustomerPortal-FormFiller detaillieren.
- Rechtekatalog: vollstaendige Tabelle der numerischen Rechte-IDs exportieren und mit
UI-Strings abgleichen.
- Altmodule (WebSuite, RiverSuite, SupRemo, DirectNow, Barrechnung): eindeutige
Ressourcenliste fuer das Au
sserbetriebnehmen im Zielsystem erstellen.
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/Glossar.md
+35
View File
@@ -0,0 +1,35 @@
# Glossar (Domänenbegriffe)
| Begriff | Definition im Kontext dieser Spezifikation |
|---|---|
| Beleg | Kaufmaennischer Vorgangscontainer (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Anfrage, Bestellung, Wareneingang, WE-Kalkulation etc.) jeweils mit Kopf- und Positionssatz. |
| Belegversionierung | Historisierungskonzept, bei dem jede Aenderung eines Belegs eine neue Kopf-/Positionssatz-Version (*Versions-Tabellen) erzeugt. |
| Festschreibung (IsFixed) | Unveraenderlichkeits-Flag auf RechKopf; blockiert spaetere Aenderungen (GoBD). |
| Storno | Durchsetztes GoBD-vertraegliches Widerrufen eines Belegs als neue Version mit State Canceled. |
| GoBD | Grundsaetze zur ordnungsgemaessen Fuehrung und Aufbewahrung von Buechern (deutsche Buchfuehrungsvorgaben); Anlass fuer Versionierung, Festschreibung und Audit-Logs. |
| Mahnlauf | Gestaffelter Mahnvorgang je Kunde (max. Stufe 3) mit eigener fortlaufender Laufnummer; DB: Tabelle Mahnlauf. |
| OPOS | Offene Posten (Liste) je Kunde; Sammelvorgang ueber offene Rechnungen. |
| Vertragsrechnung | Periodisch aus einem Vertrag (Click-, Leasing-, Wartungs-, Flatrate-Vertrag) automatisch erzeugte Rechnung. |
| Click-Vertrag | Vertrag mit mengenbasierter (pro Klick) Abrechnung, ueblicherweise auf Stammblatt-Geräte; Zaehler werden beim Storno zurueckgesetzt. |
| Stammblatt | Kundenanlage/Geraetekarte beim Kunden (GeraeteKopf/GeraetePos), oft Drucker; mit Historie, Sperrlogik und Vertragsbezug. |
| AssetManagement-Geraet | Inventarisiertes IT-Geraet aus dem uebergreifenden AssetManagement-Subsystem (~180 Tabellen), fachlich teilweise deckungsgleich mit Stammblatt. |
| Helpdesk-Timer | Auf ein Ticket gebuchte Zeit mit optionaler Unterschrift; abrechenbar ueber Belege; Tabelle hlpdsk_timer. |
| Ticketvorlage (C-FLOW) | Vorlage zur standardisierten Ticketerstellung (Allgemein, Kunde, Checklisten, Mailtemplate, Skripte, Webformular), verwaltet in Nexus. |
| Sonderpreis | Kundenindividueller Artikelpreis; Grundlage des WebCart-Endkundenshops. |
| Wertgutschrift | Zeitwert-/Guthabengutschrift; aktiv genutzter Ersatz des veralteten Gutscheinmoduls. |
| Rechtekonstante (UserRightsConst) | Numerische ID eines Rechts; Gruppen tragen eine ID mit Unterrechten; IDs ab 20800000 gehoeren zur neuen .NET-Modulwelt. |
| Restricting Right | Einschraenkendes Recht, das die Sichtbarkeit reduziert (nur eigene, nur eigene Filiale, nur eigene Abteilung); siehe CentronRights.md. |
| Mandant | Geschlossener Datenbestand eines Betreibers; eigene Tabelle; System ist mandantenfaehig ausgelegt. |
| Filiale | Zweigstelle eines Mandanten; Steuerung von Sichtbarkeiten/Restriktionen. |
| Ticket (Authentifizierung) | Serverseitig aufloesbares Authentifizierungstoken des Centron-Webservices (TicketBL/AddCentronTicket); nicht zu verwechseln mit Helpdesk-Ticket. |
| Web-Account | Endkunden-Zugang zum Nexus-Kundenportal, gekoppelt an Ansprechpartner/Adresse im Adressstamm. |
| EDI | Electronic Data Interchange; gatewaygestuetzter Standardnachrichtenverkehr (unter anderem EdiDownloadService). |
| ebInterface | Oestereichisches XML-E-Rechnungsformat; ueber eigenes API-Projekt integriert. |
| OpenTrans | XML-Standarddokumentformat (hier: INVOICE), ueber Centron.Gateway typisiert deserialisiert. |
| DSGVO-Modul | Rechtegesteuertes Modul zum datenschutzkonformen Löschen von Kontakten und zur Bereinigung der Datenbank. |
| Result/ResultStatus | Einheitliches Rueckgabmuster der BL (Success/Warning/Error) mit DefaultMessageCodes (z. B. RightCheckFailed). |
| I3D | Primaerschluessel-Spaltenname der Entitaeten (historisch; vergleichbar mit Id). |
| Nebenlager | Zweites Lager je Artikel (NebenlagerArtikel). |
| Inventur / Zaehlgruppe | Periodische Bestandsinventur, organisiert in Zaehlgruppen mit Entsperrlogik. |
| SqlScriptCollection | Versionierte XML-Bibliothek mit SQL-Migrations- und View-Skripten, die der ScriptEngine beim Start ausfuehrt. |
| RiverSuite / SupRemo / DirectNow | [Obsolete] Aeltere Integrationsfamilien (Monitoring, Fernwartung), nicht mehr zu erweitern. |
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/Hypothesen.md
+26
View File
@@ -0,0 +1,26 @@
# Hypothesen
Diese Datei sammelt alle mit HYPOTHESE markierten Anforderungen. Sie ist deckungsgleich mit
den Inline-Markierungen (Status: HYPOTHESE) in den Spezifikationsdateien. Freie Fragen ohne
zugehoerige Anforderung sind in der Selbstbewertung des Analyseberichts gefuehrt.
## Hypothese 1 - SwRS-033 (Mobile Datenerfassung)
- Kernaussage: Es existiert ein serverseitiges Mobile-Modul (Mobile/MobileBL.cs) und ein
zugehoeriges DAO-Verzeichnis. Die eigentliche mobile Client-Anwendung liegt nicht im
Repository vor.
- Offene Frage: Welche konkrete mobile App (native App, Scanner-Client oder PWA) konsumiert
diese Business-Logik? Gibt es eine Offline-Synchronisation, und nach welchem
Konfliktmodell? Diese Information fehlt zur Bestaetigung.
- Nachweis: src/backend/Centron.BL/Mobile/MobileBL.cs; src/backend/Centron.DAO/Mobile
## Hypothese 2 - SwRS-038 (Vouchermanagement / Gutscheine)
- Kernaussage: Das Recht zur Gutscheinverwaltung (RIGHT_GUTSCHEINVERWALTUNG, 20400319) ist
als [Obsolete] markiert, waehrend Wertgutschriften aktiv rechtegesteuert sind. Das
verbleibende Funktionsverhalten des Altmoduls wurde nicht vollstaendig analysiert.
- Offene Frage: Ist das klassische Gutscheinmodul in aktuellen Builds noch aufrufbar
(UI-Einstiegspunkte, Servicedurchlauf), oder verbleibt nur ein zu migrierender
Datenbestand? Diese Information fehlt zur Bestaetigung.
- Nachweis: UserRightsConst.cs (ID 20400319 mit [Obsolete], ID 20400292 aktiv);
src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs (nur teilweise gelesen)
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/StRS.md
+332
View File
@@ -0,0 +1,332 @@
# StRS - Stakeholder Requirements Specification
# c-entron ERP-Suite (Reverse Requirements Engineering, Baseline V1 Iteration 02)
# Methode: statische Analyse der Codebasis; Formatfelder gemäß Prompt-Vorgabe.
---
ID: StRS-001
Titel: Geschäftszweck: Integriertes ERP für IT-Systemhäuser
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Systemhaus (Mandant), alle Fachabteilungen
Vorbedingung: Datenbank installiert, Lizenz vorhanden
Fakt: Die Codebasis enthält fachliche Geschäftslogik-Module (Verzeichnisse in `Centron.BL`): Sales/Receipts, CustomerAssets/Contracts, Warehousing, Finances, Helpdesk (Support), Production, DataExchange/BookKeeping u.v.m.; dazu ein WPF-Desktop-Client (`Centron.WPF.UI`), ein REST-Webservice-Host (`Centron.Host`) und eine Blazor-Weboberfläche (`CentronNexus`).
Aussage: Das System soll ein integriertes ERP-System für IT-Systemhäuser/MSP bereitstellen, das Vertrieb (Belege), Vertragsabrechnung, Materialwirtschaft, Service/Helpdesk, Zeitwirtschaft, Finanzen und IT-Asset-Dokumentation in einer gemeinsamen Datenhaltung betreibt.
Ergebnis: Ein Mandant betreibt seine kaufmännischen Kernprozesse ohne Systembruch auf einer Instanz.
Belege:
- [PRIMÄR] src/backend/Centron.BL (Modulverzeichnisse) - Begründung: durchgesetzte fachliche Trennung der Module im Code
- [SEKUNDÄR] src/centron/Centron.WPF.UI, src/webservice/Centron.Host/CentronHost.cs, src/nexus/CentronNexus - Begründung: drei Auslieferungskanäle auf derselben BL
- [KONTEXT] README.md - Begründung: beschreibt Kunden der Kunden (WebCart) und Bestandteile
Prüfidee: Stichprobentest: Belegkette Angebot→Auftrag→Lieferschein→Rechnung mit Artikel- und Kundendaten aus den Stammdaten in einer Datenbank abbildbar.
Tracelinks: SyRS-001, SyRS-011, SyRS-013, SyRS-019, SyRS-028
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrale Daseinsberechtigung des Produkts
Status: belegt
---
ID: StRS-002
Titel: Akteure und Rollen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst, Aussendienst, Techniker, Buchhaltung, Lager, Administration, Endkunde (Web-Account), Lieferant, externe Systeme
Vorbedingung: -
Fakt: `UserRightsConst` definiert Rechtegruppen für Vertrieb (`Sales.Customer.CustomerCommon`, `Offer/Order/DeliveryList/Invoice/CreditVoucher`), `Purchase.StockList`, `Controlling.Finances/Analytics`, `Administration`, `Logistic`, `PasswordManager`, `DsgvoModule`; `CentronRights.md` beschreibt restriktive Rechte in Business-Sprache; `README.md` beschreibt Web-Accounts für Endkunden; Tabelle `Personal`, `PersonalGruppen`, `Filiale`, `Mandant` existieren. `AssetManagementPartners`/-`Socustomer` kennzeichnen Rollen im Kundenkreis.
Aussage: Das System soll die Rollen Innendienst/Aussendienst (Vertrieb), Techniker (Helpdesk/Zeiten), Buchhaltung (Finanzen/Mahnen), Lagerverwaltung, Systemadministration, Mandant und Filiale sowie Endkunden (Webaccount im Kundenportal) als Akteure mit je eigenen Rechteprofilen unterstützen.
Ergebnis: Jede Business-Funktion ist einer Rolle mit vergebbarer Rechtegruppe zugeordnet.
Belege:
- [PRIMÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs - Begründung: vollständige, im Code durchgesetzte Rechtematrix
- [KONTEXT] CentronRights.md - Begründung: fachliche Erläuterung der Rechtebedeutung
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[Personal]`, `[dbo].[Filiale]`, `[dbo].[Mandant]` - Begründung: Datenhaltung der Akteursdimensionen
Prüfidee: Für jede Rollenklasse existiert mindestens eine Rechte-ID in `UserRightsConst`; ein Benutzer ohne Recht erhält keinen Zugriff (neg. Test).
Tracelinks: SyRS-009, SyRS-010, SwRS-007
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Rollenmodell bleibt fachlich erforderlich
Status: belegt
---
ID: StRS-003
Titel: Filiabezogene und eigendatensichtfähige Sichtbarkeit
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertriebsmitarbeiter, Techniker, Führungskraft
Vorbedingung: Benutzer ist einer Filiale und ggf. Abteilung zugeordnet
Fakt: Rechte wie `SHOW_HELPDESK_ONLY_OWN` (20400340), `SHOW_HELPDESK_ONLY_OWN_BRANCH` (20800045), `SHOW_OFFERS_ONLY_OWN` (20400149), `SHOW_OFFERS_ONLY_OWN_BRANCH` (20400150) bis hin zu `SHOW_ALL_EMPLOYEE_TIMES` (20800173) sind als eigenständige Rechte-IDs deklariert; `CentronRights.md` bezeichnet diese als "restricting rights".
Aussage: Das System soll fachliche Sichtbarkeitseinschränkungen (nur eigene Datensätze, nur eigene Filiale, nur eigene Abteilung) als explizit vergebene Restriktionsrechte kennen, die die Datenbankabfragen einschränken.
Ergebnis: Ein Mitarbeiter sieht nur die Belege/Tickets, für die sein Profil die Sichtbarkeit gewährt.
Belege:
- [PRIMÄR] UserRightsConst.cs (IDs 20400149-20400160, 20400340, 20800045) - Begründung: im Code durchgesetzte Konstanten
- [KONTEXT] CentronRights.md (Helpdesk 1.1/1.2) - Begründung: fachliche Definition "restricting right"
Prüfidee: Benutzer mit `SHOW_HELPDESK_ONLY_OWN` sieht keine Tickets fremder Bearbeiter (Abfragetest).
Tracelinks: SyRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrales Bedürfnis mehrerer Mandanten
Status: belegt
---
ID: StRS-004
Titel: Vertriebsbelegkette Angebot-Auftrag-Lieferschein-Rechnung-Gutschrift
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst/Außendienst, Kunde
Vorbedingung: Kunden- und Artikelstamm vorhanden
Fakt: Tabellen `AngKopf/AngPos`, `AufKopf/AufPos`, `LiefKopf/LiefPos`, `AbholKopf/AbholPos`, `RechKopf/RechPos`, `GutKopf/GutPos` inkl. Versions-Pendanten (`RechKopfVersions`, `RechPosVersions` ...); `ReceiptBL` (623.866 Bytes) und `ReceiptItemBL` (230.597 Bytes) implementieren die Beleglogik; spezifische BL-Klassen je Belegart (Ordner Offers, Orders, DeliveryLists, PickUpLists, Invoices, CreditVouchers, DownPayment); `IReceiptSpecificLogic` definiert je Belegtyp abweichendes Verhalten.
Aussage: Das System soll eine Vertriebsbelegkette aus Angebot, Auftrag, Lieferschein, Abholschein, Rechnung und Gutschrift führen, in der Belege in Folgebelege überführt (weiterverarbeitet) und versioniert werden.
Ergebnis: Geschäftsvorgänge sind von der Offerte bis zur Gutschrift nachverfolgbar dokumentiert.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[AngKopf]`, `[dbo].[AufKopf]`, `[dbo].[LiefKopf]`, `[dbo].[AbholKopf]`, `[dbo].[RechKopf]`, `[dbo].[GutKopf]` - Begründung: persistentes Belegkopf/Positions-Modell je Belegart
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs - Begründung: typenabhängige durchgesetzte Belegvorschriften
- [SEKUNDÄR] UserRightsConst.cs (`RIGHT_ANGEBOTEDRUCKEN`, `RIGHT_AUFTRAGEDRUCKEN`, ...) - Begründung: belegtypspezifische Druckrechte
Prüfidee: Angebot anlegen → Auftrag erzeugen → Positionen übernommen; Überführung erzeugt Referenz (`GetReceiptForwardedInto` in ReceiptInvoiceBL.CancelInvoice).
Tracelinks: SyRS-011, SyRS-012, SyRS-013, SwRS-003, SwRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kern des Vertriebsprozesses
Status: belegt
---
ID: StRS-005
Titel: Vertragsgeschäft mit Click-/Service-, Leasing- und Wartungsabrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Buchhaltung, Kunde
Vorbedingung: Stammblätter (Kundenanlagen) vorhanden, Vertragsarten konfiguriert
Fakt: Tabellen `VertragKopf`, `VertragPos`, `VertragRechKopfZuordnung`, `VertragGeraete`, `VertragKontingentAnlagePositionen`, `VertragsArt`; BL-Ordner `Sales/Receipts/ContractLists`, `Sales/Receipts/LeasingAndService` und `Sales/CustomerAssets/Contracts/ClickContracts` mit `MasterDataListBL`; CONTRAIL `AUTOMATED_BILLING` (ID 10385), `TIMER_BILLING_MODULE`, `FLATRATE_BILLING_MODULE`; HostedServices `ContractEndeService`, `ContractCloseService`, `UpdateSpecialArticleToContractService`; `CancelInvoice` prüft Vertragsrechnungen gesondert (nur letzte Vertragsrechnung stornierbar).
Aussage: Das System soll Verträge (Click-Verträge/Mengenabrechnung, Leasing/Service, Flatrate, Geräte ohne Bezug) verwalten und daraus periodisch automatisch Rechnungen erzeugen; Rechnungen sollen dem Vertrag zugeordnet bleiben.
Ergebnis: Vertragsperioden werden ohne manuelle Einzelrechnung abgerechnet; Storno einer Vertragsrechnung setzt den Abrechnungsstand zurück.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[VertragKopf]`, `[dbo].[VertragPos]`, `[dbo].[VertragRechKopfZuordnung]`, `[dbo].[VertragGeraete]` - Begründung: persistentes Vertragsmodell mit Geräte- und Rechnungszuordnung
- [PRIMÄR] ReceiptInvoiceBL.CancelInvoice: `IsContractInvoice`, `IsLastContractInvoice`, `ResetContract` mit `DeactivateContractInvoice`, `ResetDeviceClickCounter`, `ResetSpecialArticles` - Begründung: durchgesetzte Stornoregel für Vertragsrechnungen
- [SEKUNDÄR] CentronHost.cs HostedServices `ContractEndeService`, `ContractCloseService` - Begründung: zeitgesteuerter Vertrags-Lifecycle
Prüfidee: Storno der letzten Vertragsrechnung setzt Click-Zähler und Sonderartikel zurück (Unit-/Integrationstest gegen das SQL-Schema).
Tracelinks: SyRS-016, SyRS-017, SyRS-022, SwRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Kern des MSP-Geschäftsmodells
Status: belegt
---
ID: StRS-006
Titel: Helpdesk/Ticketing mit SLAs, Zeiten, Checklisten und Eskalation
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Techniker, Helpdesk, Kunde
Vorbedingung: Ticket-Typen, Kategorien, Prioritäten konfiguriert
Fakt: Tabellen `hlpdsk_requests`, `hlpdsk_typen`, `hlpdsk_kategorien`, `hlpdsk_prioritaeten`, `hlpdsk_status`, `hlpdsk_history`, `hlpdsk_timer`, `hlpdsk_request_bearbeiter`; `CentronRights.md` Kapitel Helpdesk (Tickets nur eigene/eigene Filiale, Fälligkeit ändern, Zeiten bearbeiten, Unterschrift löschen, interne Sichtbarkeit, Checklisten-Vorlagen, Taskmanagement); HostedServices `EscalationsService`, `ValidateHelpdeskFingerprintService`.
Aussage: Das System soll einen Helpdesk mit Ticket-Typen, Kategorien (Stufen 1+2), Prioritäten, Status, Historie, Bearbeiterzuordnung (inkl. Abteilungseinschränkung), Zeiterfassung mit Unterschrift, Checklisten und Eskalationslogik führen.
Ergebnis: Servicefälle sind lückenlos dokumentiert, fristenüberwacht und abrechenbar.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[hlpdsk_requests]`, `hlpdsk_history`, `hlpdsk_timer`, `hlpdsk_request_bearbeiter` - Begründung: persistentes Ticketmodell
- [PRIMÄR] CentronHost.cs: `AddHostedService<EscalationsService>()` - Begründung: durchgesetzte automatisierte Eskalation
- [KONTEXT] CentronRights.md (Kapitel Helpdesk) - Begründung: fachliche Rechtslogik für Zeiten, Fälligkeit, Sichtbarkeit
Prüfidee: Ticket anlegen, Zeit mit Unterschrift buchen, Statuswechsel dokumentiert in `hlpdsk_history`; Eskalation bei Fristüberschreitung (zeitrafferbarer Test).
Tracelinks: SyRS-018, SyRS-026, SyRS-030, SwRS-021, SwRS-022
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - zentrale Servicefähigkeit
Status: belegt
---
ID: StRS-007
Titel: Automatisierte Abrechnung von Ticket-Zeit auf Verträge/Rechnungen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Techniker
Vorbedingung: Zeit erfasst, Vertrag/Rechnung vorhanden
Fakt: `Rights`-Konstanten `TIMER_BILLING_MODULE` (20800084), `FLATRATE_BILLING_MODULE` (20800085); `HelpdeskTimerBL`, `ReceiptItemTimerBL.RemoveTimers()` wird beim Rechnungsstorno transaktional aufgerufen; Rechte `MOVE_HELPDESK_TIMER`/`DELETE_HELPDESK_TIMER` greifen nur solange das Ticket nicht Teil eines Belegs ist.
Aussage: Das System soll auf Tickets gebuchte Leistungszeiten abrechenbar machen, indem sie bei Vertragsabrechnung oder manueller Fakturierung in Belegpositionen überführt, abgerechnet und aus der Ticket-Anzeige entfernt („is part of receipt") werden.
Ergebnis: Leistungszeiten tauchen genau einmal in der Fakturierung auf, Doppelabrechnung ist ausgeschlossen.
Belege:
- [PRIMÄR] ReceiptInvoiceBL.CancelInvoice: `new ReceiptItemTimerBL(dedicatedSaveSession).RemoveTimers(invoice, currentUser)` - Begründung: durchgesetzte Transaktionslogik Fakturierung↔Zeitverknüpfung
- [KONTEXT] CentronRights.md Nr. 8 und 9 - Begründung: fachliche Regel: kein Verschieben/Löschen abgerechneter Zeiten
Prüfidee: Ticket-Zeit in Rechnung übernehmen; Verschieben danach verweigert; Storno der Rechnung löst Zeitverknüpfung wieder.
Tracelinks: SyRS-011, SyRS-017
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - MSP-abrechenbares Geschäft
Status: belegt
---
ID: StRS-008
Titel: Forderungsmanagement: OPOS-Liste, Mahnwesen, Kundenlimit
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung, Vertrieb
Vorbedingung: Rechnungen offen, Fälligkeiten konfiguriert
Fakt: Tabelle `Mahnlauf`; Klasse `DunningRunBL` mit `GetDunningRuns`, `GetPreviewForDunningRun`, `ExecuteDunningRun`, `ResetDunningRun`; enum `DunningLevel` bis `Level3`; Validierung: Rechnungen müssen zum gleichen Kunden gehören, bereits fällig sein, max. Mahnstufe 3; `OposRunBL` generiert OPOS-Listen; Recht `IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS` (20400085) und Recht `Controlling.Finances.Dunning` (10971); `SHOW_CUSTOMER_OPOS` (20400025); `EDIT_LIMIT_CUSTOMER` (2040004).
Aussage: Das System soll offene Posten je Kunde sammeln (OPOS), Mahnstufen bis Stufe 3 führen, Mahnläufe mit Vorschau, Versand (Druck/Mail) und Reset ermöglichen, und durch Mahnwesen gesperrte Kunden für neue Anlagen/Belege sperren, sofern kein Ausnahmerecht greift.
Ergebnis: Überfällige Forderungen werden gestaffelt angemahnt; Sperrung wirkt auf Vertriebsprozesse.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/DunningRunWebServiceBL.cs: `invoicesInDunningLevel3`, Kundenidentität, Fälligkeitsprüfungen - Begründung: durchgesetzte Mahnvalidierung
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[Mahnlauf]` - Begründung: Persistenz der Mahnläufe
- [SEKUNDÄR] UserRightsConst.cs: IDs 20400085, 10971, 20400025 - Begründung: vergebare Rechte
Prüfidee: Mahnlauf über fällige Rechnungen zweier fremder Kunden wird abgelehnt; Mahnstufe 4 nicht möglich.
Tracelinks: SyRS-014, SyRS-015, SwRS-020
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - kaufmännisch unverzichtbar
Status: belegt
---
ID: StRS-009
Titel: Materialwirtschaft: Artikel, Einkauf, Lager, Seriennummern, Inventur
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkauf, Lager, Vertrieb
Vorbedingung: Warengruppen/Lagerorte konfiguriert
Fakt: Tabellen `ARTIK`, `Artikel*`, `ArtikelBestand`, `Barcode`, `SeriennummerToPosition`, `ArtikStkListe`, `NebenlagerArtikel`, `Lagerort`, `Lagerplatz`, `Warehouses`; BL `Warehousing/ArticleBL.cs`, `BarcodeBL.cs`, `BarcodeHistoryBL.cs`, `StockManagement`, `InventoryManagement`, `Commissions`; Rechte `BOOK_ARTICLE_STOCK_INTO_NEGATIVE` (20400011), Inventur-Rechte 20400040-48, Seriennummer-Rechte 20400027/28/32-35; Bestelltabellen `BestKopf2/BestPos2`, `WareKopf/WarePos` (Wareneingang), `KalkKopf/KalkPos` (WE-Kalkulation).
Aussage: Das System soll Artikelstamm mit Preisen/Einheiten/Stücklisten führen, Bestellung→Wareneingang→WE-Kalkulation abbilden, Lagerbewegungen (Zu-/Abbuchung, Umbuchung, Nebenlager) mit optionaler Negativbuchung durchführen, Seriennummern über den gesamten Lebenszyklus verfolgen und Inventuren mit Zählgruppen unterstützen.
Ergebnis: Vollständige Warenwirtschaft von Beschaffung über Zählpflicht bis Abverkauf.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[ARTIK]`, `[dbo].[ArtikelBestand]`, `[dbo].[Barcode]`, `[dbo].[SeriennummerToPosition]`, `[dbo].[BestKopf2]`, `[dbo].[WareKopf]`, `[dbo].[KalkKopf]` - Begründung: persistentes Warenwirtschaftsmodell
- [PRIMÄR] UserRightsConst. `Purchase.StockList`/`Inventory`: Lager-, Inventur-, SN-Rechte als durchgesetzte Konstanten
- [SEKUNDÄR] src/backend/Centron.BL/Warehousing (Verzeichnisliste mit ArticleBL, BarcodeBL, InventoryManagement) - Begründung: Modulzuordnung
Prüfidee: Wareneingang mit SN buchen; SN bei Lieferschein ausbuchen; Inventur abschließen → Bestandskorrektur.
Tracelinks: SyRS-019, SyRS-020, SyRS-021, SwRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Standard-ERP-Pflichtfunktion
Status: belegt
---
ID: StRS-010
Titel: IT-Asset-Dokumentation beim Kunden (Stammblätter/Anlagen)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Techniker, MSP-Vertragsmanager
Vorbedingung: Kunde vorhanden
Fakt: Klassen `AssetBL`, `CustomerAssetBL`, `CustomerAssetExtendedBL`, `AssetLockBL`, `MasterDataListBL` unter `Sales/CustomerAssets`; `GeraeteKopf/GeraetePos`-Tabellen; Fehler-Texte wie „Stammblatt ist einem aktiven Vertrag zugeordnet." (`DependencyCheckFailed`); Serialnumber-Historie (`MasterDataListBL`: „Writes the Stammblatt history entry"); Recht `CHANGE_MAIN_DEVICE_SERIAL_NUMBER` (20800164); Rechtegruppe `CUSTOM_DEVICES`, `LICENSE_MANAGEMENT`.
Aussage: Das System soll pro Kunde Anlagen/Stammblätter (Geräte mit Artikelpositionen) führen, die mit Historie, Sperrlogik und Vertragszugehörigkeit dokumentiert sind, und das Ändern der Hauptgeräte-Seriennummer als eigenes Recht erlauben.
Ergebnis: Kundengeräte sind mit ihrem Lebenszyklus nachverfolgt; Verträge referenzieren die aktive Anlage.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs: Serialnumber-Änderung mit Historienschreibung, Vertragszugehörigkeit als Prüfung - Begründung: durchgesetzte Anlagenlogik
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[GeraeteKopf]`, `[dbo].[GeraetePos]`, `[dbo].[VertragGeraete]` - Begründung: persistentes Anlagenmodell
- [SEKUNDÄR] UserRightsConst.cs IDs 20800164, 20800017-20800019 - Begründung: eigenständiges Recht
Prüfidee: SN-Wechsel am Stammblatt erzeugt Historieneintrag; Entfernen eines Stammblatts mit aktivem Vertrag wird abgelehnt.
Tracelinks: SyRS-024, SwRS-006
Konsolidierung: Kandidat: SwRS-006 (doppelte Datenhaltung Stammblatt vs. AssetManagement-Geräte)
Übernahmewürdigkeit: übernehmen - fachliches Kernkonzept, Datenhaltung zu konsolidieren
Status: belegt
---
ID: StRS-011
Titel: Kundenportal/Webshop für Endkunden der Kunden
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Endkunde (Web-Account), Kunde des Systemhauses
Vorbedingung: Web-Account im Adressstamm angelegt, Sonderpreise gepflegt
Fakt: `README.md` „WebCart … primarily intended for the customers of our customers; The available articles come from the customers 'Sonderpreise'"; Razor-Seiten `WebCartShopPage`, `WebCartCartPage`, `WebCartAdminPage`, `CustomerTicketDetailsPage`, `ReceiptsOverview`, `ReceiptDetailsOverview`, `ContractsOverview`, `CustomerPortalPublicDocumentsPage`; Tabelle `AddressContactPersonWebAccountRequests`.
Aussage: Das System soll Endkunden (Kunden der Kunden) einen Web-Login im Kundenportal bieten, über den sie Shopartikel aus den Sonderpreisen des Kunden einsehen/bestellen und eigene Belege, Verträge, Tickets und freigegebene Dokumente einsehen können.
Ergebnis: Endkunde bedient sich ohne Telefon; anfallende Bestellungen landen als Aufträge im ERP.
Belege:
- [KONTEXT] README.md (Absatz WebCart) - Begründung: bestätigt fachliche Zielsetzung
- [SEKUNDÄR] src/nexus/CentronNexus/WebCart/WebCartShopPage.razor, WebCartCartPage.razor, ReceiptsOverview.razor, ContractsOverview.razor - Begründung: umgesetzte Portaloberflächen
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[AddressContactPersonWebAccountRequests]` - Begründung: Web-Account als Datenentität
Prüfidee: Web-Account sieht im Shop nur Artikel aus den für seinen Kunden gepflegten Sonderpreisen.
Tracelinks: SyRS-031, SwRS-016
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - strategisches Wachstumsgebiet
Status: belegt
---
ID: StRS-012
Titel: Datenschutz (DSGVO) und Mandantenfähigkeit
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
Akteur: Datenschutzbeauftragter, Administration, Mandant
Vorbedingung: Modul lizenziert
Fakt: Rechtegruppe `UserRightsConst.DsgvoModule` mit `ACCESS_DSGVO_MODULE`, `DSGVO_DELETE_CONTACT`, `ACCESS_CLEANUP_DATABASE`; Tabelle `Mandant`.
Aussage: Das System soll ein mandantenfähiges Datenmodell und ein DSGVO-Modul besitzen, mit dem Ansprechpartner rechtskonform gelöscht und die Datenbank periodisch bereinigt werden können, jeweils hinter expliziten Rechten.
Ergebnis: Löschkonzept und Mandantentrennung sind betreibbar; kein Zugriff ohne Recht.
Belege:
- [PRIMÄR] UserRightsConst.cs `DsgvoModule` (IDs 20800021-20800024) - Begründung: im Code durchgesetzte Rechte-Gruppe
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[Mandant]` - Begründung: Mandantenentität im Schema
Prüfidee: Ansprechpartner ohne DSGVO-Recht wird nicht gelöscht; zwei Mandanten-Datenbanken bleiben getrennt.
Tracelinks: SyRS-033, SwRS-005
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - rechtlich zwingend
Status: belegt
---
ID: StRS-013
Titel: Kommunikations- und Produktivitätsdienste (Mail, Kalender, To-Do, KI)
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: alle Mitarbeiter
Vorbedingung: -
Fakt: BL-Verzeichnisse `Mail`, `Mailings`, `MailScanner`, `Outlook`, `Chats`, `Notifications`, `NexusNotifications`, `Calendar`, `ToDoArea`, `MyCentron`, `MyDay`, `TaskManager`, `ArtificialIntelligence`; HostedServices `SendEmailForUnreadMessagesService`, `SendMyDayNotificationsService`, `ReminderService`, `TodoService`, `TaskManagmentService`, `ExchangeSyncService`, `CallTrackingService`; Rechtegruppe `ArtificialIntelligence` (ADD_FILES, WEB_SEARCH, INTERACTIVE_MODE, MODEL_SELECTION, UNRESTRICTED_ACCESS).
Aussage: Das System soll Mail-Integration (inkl. Mailing-Kampagnen, Mail-Scanner, Outlook-AddIn), Team-Chats, Benachrichtigungen, Kalender/Mein-Tag-Ansicht, To-Do- und Aufgabenmanagement sowie ein rechtegesteuertes KI-Assistenzmodul bereitstellen.
Ergebnis: Produktivitätsfunktionen sind ins ERP eingebettet statt externer Insellösungen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL (Verzeichnisse Mail/Mailings/Chats/Calendar/ToDoArea/ArtificialIntelligence) - Begründung: Modulzuordnung
- [PRIMÄR] CentronHost.cs: `SendEmailForUnreadMessagesService`, `SendMyDayNotificationsService`, `TodoService` - Begründung: durchgesetzte Hintergrundverarbeitung
- [PRIMÄR] UserRightsConst.cs `ArtificialIntelligence`-IDs 20800167-20800172 - Begründung: rechtegesteuerte KI-Fähigkeiten
Prüfidee: Ungelesene Chat-Nachricht löst Mail-Benachrichtigung aus; KI-Funktion ohne Recht `INTERACTIVE_MODE` nicht nutzbar.
Tracelinks: SyRS-034, SyRS-035
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - moderne Produktivitätsanforderung
Status: belegt
---
ID: StRS-014
Titel: Fertigung/Produktion mit Arbeitsplänen und Produktionsaufträgen
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Fertigungsleiter, Mitarbeiter
Vorbedingung: Stücklisten gepflegt
Fakt: Tabellen `ArticleProductionStep`, `ArticleProductionOrders`, `ArticleProductionOrderStepItems`, `ArticleProductionMaterials`, `APlan*` (Arbeitspläne/-vorlagen); BL `Production/ProductionBL.cs`, `ProductionOrderBL.cs`; Nexus-Ordner `ProductionOrderManagement` (Web); Rechte `RIGHT_PPSARBEITSPLANANLEGEN` (20400038), `RIGHT_AUFTRAGPRODUZIERT` (2060030).
Aussage: Das System soll Fertigungsaufträge aus Stücklisten und Arbeitsplänen (Arbeitsgänge, Material, Zeitbuchung) erzeugen und steuern; ein Vertriebsauftrag kann als „produziert" markiert werden.
Ergebnis: Variantenfertigung und Fertigungsdokumentation sind abbildbar.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[ArticleProductionOrders]`, `[dbo].[ArticleProductionOrderStepItemTimes]` - Begründung: persistenter Produktionsprozess mit Zeitbuchung
- [PRIMÄR] UserRightsConst.cs IDs 20400038, 2060030 - Begründung: durchgesetzte Rechte
- [SEKUNDÄR] src/backend/Centron.BL/Production, src/nexus/CentronNexus/ProductionOrderManagement - Begründung: Backend- und Web-Modul
Prüfidee: Produktionsauftrag erzeugt Arbeitsgangpositionen; Zeit buchen; Auftrag erhält Status produziert.
Tracelinks: SyRS-023
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - für Fertigungsbetriebe erforderlich
Status: belegt
---
ID: StRS-015
Titel: Qualitäts-, Admin- und Berichtswesen inkl. Datenqualität
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Controlling, Administration
Vorbedingung: Stammdaten vorhanden
Fakt: BL-Verzeichnisse `ReportEngine`, `Reporting`, `Statistics`; `Analytics`-Rechte (`SALES_STATISTIC` 20800005 … `EMPLOYEE_STATISTIC` 20800009, `SALE_PURCHASE_ARTICLE_STATISTIC`); HostedService `DataQualityService` und `CacheUpdateService`; Rechte `REPORT_MANAGEMENT` (10550), `REPORTEDIT` (20800040); Power-BI-/Berichtsserver-Rechte `REPORTSERVER` (20800044).
Aussage: Das System soll statistische Auswertungen je Geschäftsfeld hinter eigenen Rechten, eine Reportverwaltung und laufende Datenqualitätsprüfung bereitstellen.
Ergebnis: Auswertungen sind rechtegesteuert und auf bereinigten Daten belastbar.
Belege:
- [PRIMÄR] CentronHost.cs: `DataQualityService`, `CacheUpdateService` - Begründung: durchgesetzte Qualitätsdienste
- [PRIMÄR] UserRightsConst.cs `Controlling.Analytics` - Begründung: eigene Rechte je Statistikart
- [SEKUNDÄR] src/backend/Centron.BL/{ReportEngine,Reporting,Statistics} - Begründung: Modulzuordnung
Prüfidee: Statistik-Recht entzogen → Auswertung nicht aufrufbar; Datenqualitätslauf protokolliert Befunde.
Tracelinks: SyRS-034, SyRS-027
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Controlling-Erfordernis
Status: belegt
---
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/SwRS-Ergaenzungen.md
+254
View File
@@ -0,0 +1,254 @@
# SwRS - Ergänzende Software Requirements (Modul-Breitabdeckung, Teil 2)
# Fortsetzung von SwRS.md (IDs SwRS-029 ff.)
---
ID: SwRS-029
Titel: docuFORM-Integration für Formular-/Dokumentenveredelung
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Vertrieb, System
Vorbedingung: docuFORM-Server erreichbar
Fakt: Eigenes API-Projekt `Centron.Api.docuFORM` mit `DocuFormRestApiClient`, `IDocuFormApiClient`, `DocuFormRestApiConstants`, Models.
Aussage: Die Software soll Dokumente/Formulare über die REST-API eines docuFORM-Servers erzeugen/veredeln lassen (Client-Abstraktion vorhanden).
Ergebnis: Medienbruchfreie Formularverarbeitung.
Belege:
- [PRIMÄR] Centron.Api.docuFORM/{DocuFormRestApiClient.cs,IDocuFormApiClient.cs} - durchgesetzte Client-Struktur
Prüfidee: Client-Aufruf mit Mock-Server liefert typisierte Modelle.
Tracelinks: SyRS-036, StRS-001
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - herstellerbezogene Integration, im Zielsystem konfigurierbar
Status: belegt
---
ID: SwRS-030
Titel: C-FLOW-Ticketvorlagen mit Formulas, Checklisten, Skripten und Mailtemplates
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Helpdesk-Administration
Vorbedingung: Lizenz C-FLOW
Fakt: Nexus-Modul `Management/TicketPatterns` mit `TicketPatternEditor`, Tabs für Allgemein, Properties, Kunden, Intern, Checklisten, MailTemplate, Scripts, WebForm, SelfCareFormFields; Rechtegruppe `UserRightsConst.Sales.Customer.Helpdesk.CFlow` (EDIT/CREATE/DELETE_TICKETPATTERN, CREATE_CATEGORY).
Aussage: Die Software soll Ticketvorlagen mit Kategorien verwalten, denen pro Tab Checklisten, Formularfelder, Mailtemplates und Skripte zugeordnet werden können; Bearbeitung ist rechtegebunden.
Ergebnis: Standardisierte Serviceprozesse aus einem Katalog.
Belege:
- [PRIMÄR] UserRightsConst.cs `CFlow`-Block (IDs 20800050-20800054) - durchgesetzte Rechte
- [SEKUNDÄR] src/nexus/CentronNexus/Management/TicketPatterns/*.razor - Begründung: Editorenstruktur
Prüfidee: Vorlage ohne Recht nicht editierbar; Checkliste in Ticket überführt.
Tracelinks: StRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-031
Titel: Elektronische Unterschrift am Dokument (Nexus DocumentSigning)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Kunde, Techniker
Vorbedingung: Signaturfähiges Endgerät
Fakt: Nexus-Ordner `DocumentSigning` mit `DocumentSigningPage.razor`, `IsolatedSignaturePad.razor`; BL-Verzeichnis `Security/PdfSigningBL.cs` (9.549 Bytes).
Aussage: Die Software soll Unterschriften webseitig über Signature-Pad erfassen und PDF-Dokumente signieren.
Ergebnis: Rechtswirksame Dokumentation ohne Papier (z. B. für Lieferscheine).
Belege:
- [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs - durchgesetzte Signatur-BL
- [SEKUNDÄR] src/nexus/CentronNexus/DocumentSigning/*.razor - Begründung: UI
Prüfidee: Signatur erzeugt signiertes PDF; Pad-Daten werden nicht im Klartext persistiert (Prüfung auf Verschlüsselung offen).
Tracelinks: StRS-006, SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-032
Titel: Outlook-AddIn mit Kontextbezug (Ticket/CRM/Belege/Dokument)
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Vertrieb, Helpdesk
Vorbedingung: Microsoft 365
Fakt: Projekt `CentronNexus.OutlookAddIn` mit Ordnern `Ticket`, `CRM`, `Customer`, `Belege`, `Document`, `Manifest`, `OfficeDialog`; Blazor-Seiten (`OutlookIndexPage.razor`).
Aussage: Die Software soll Outlook-Mails und Termine kontextbezogen an Tickets, CRM-Vorgänge, Kunden, Belege und Dokumente in c-entron koppeln.
Ergebnis: Kommunikationsschnittstelle ohne Medienbruch.
Belege:
- [PRIMÄR] src/nexus/CentronNexus.OutlookAddIn (Projektstruktur mit Manifest und Kontextordnern) - durchgesetzte Integration
Prüfidee: Mail zu Ticket zuordnen erzeugt Ticketverweis in Datenbank.
Tracelinks: StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-033
Titel: Mobile Datenerfassung
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Techniker, Lager
Vorbedingung: Mobiles Gerät
Fakt: BL `Mobile/MobileBL.cs` und `ItPlanner/ChecklistVirtualObjectCategoryBL.cs`; DAO-Verzeichnis `Mobile`; Checklisten-Verbindung zur Inventur/Infrastruktur.
Aussage: Die Software soll eine mobile Schnittstelle für Checklisten- und Infrastruktur-Datenerfassung bereitstellen.
Ergebnis: Offlinebaubekannte Mobile-Prozesse.
[Hinweis: konkrete mobile Clients nicht weiter analysiert]
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/Mobile/MobileBL.cs, src/backend/Centron.DAO/Mobile - Begründung: Modul
Prüfidee: [HYPOTHESE] Mobile App-Schnittstelle testen (Client-Anwendung liegt nicht im Repo vor).
Tracelinks: StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: HYPOTHESE (Mobile-Client-Anwendung nicht im Repository; BL-Modul belegt)
---
ID: SwRS-034
Titel: WebSuite/ältere Web-Angebotsplattform
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Endkunde
Vorbedingung: -
Fakt: BL-Verzeichnis `WebSuite`, `RiverDivo` enthält `RBContractArticleRefInfo`, `RiverConnectionBL`, `RiverDivoBL`, `SimpleRiverCentronClient`; zugehörige Rechte (`RIGHT_WEBSUITE`, `RIGHT_WEBHELPDESK`, `RIGHT_WEBSHOP`, `RIGHT_WEBSUITEREISEKOSTEN*`, `ALLOW_RIVERSUITE_*`, SupRemo/DirectNow) sämtlich `[Obsolete]`.
Aussage: Die Software enthält eine ältere Webplattform (WebSuite/WebHelpdesk/WebShop inkl. Reisekosten) und eine RiverSuite-Konnektivität, die fachlich abgelöst wurden.
Ergebnis: Altintegrationen verbleiben als Daten-/Codebestand.
Belege:
- [PRIMÄR] UserRightsConst.cs: `[Obsolete]`-Markierungen auf WebSuite-/Riversuite-/SupRemo-/DirectNow-IDs - durchgesetzte Abschaltung
- [SEKUNDÄR] src/backend/Centron.BL/WebSuite, src/backend/Centron.BL/RiverDivo - Begründung: Restcode
Prüfidee: Rechtevergabe bietet WebSuite nicht an.
Tracelinks: SyRS-001
Konsolidierung: Kandidat: Altintegrationen (RiverSuite, SupRemo, DirectNow, WebSuite) - im Zielsystem stilllegen
Übernahmewürdigkeit: veraltet - durch Nexus-Kundenportal und WebCart ersetzt
Status: belegt
---
ID: SwRS-035
Titel: VideoPortal mit Zuordnung und Auswertung
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb, Marketing
Vorbedingung: Videos bereitgestellt
Fakt: Rechtegruppe `VideoPortal` (ID 20800107) mit `EVALUATION` (20800108), `ASSIGNMENT` (20800113); BL-Klasse `VideoPortalAssignmentBL`.
Aussage: Die Software soll Videos zuordnen und deren Nutzung auswerten, jeweils rechtegesteuert.
Ergebnis: Kunden/Lernvideos nachverfolgbar.
Belege:
- [PRIMÄR] UserRightsConst.cs `VideoPortal`-Block - durchgesetzte Rechte
- [SEKUNDÄR] src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs - Begründung: Modul
Prüfidee: Auswertung nur mit Recht `EVALUATION` erreichbar.
Tracelinks: StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-036
Titel: Erwartete Ereignisse (ExpectedEvents)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Controlling
Vorbedingung: -
Fakt: BL-Klasse `ExpectedEventsBL.cs`; Rechte `SHOW_EXPECTEDEVENTS` (20800100) und `SHOW_EXPECTEDEVENTSREPORTING` (20800101).
Aussage: Die Software soll fachlich erwartete Ereignisse (z. B. erwartete Belege/Einnahmen) erfassen und auswerten; Ansicht und Reporting sind getrennt berechtigt.
Ergebnis: Proaktive Unternehmenssteuerung.
Belege:
- [PRIMÄR] UserRightsConst.cs IDs 20800100/20800101 - durchgesetzte Rechte
- [SEKUNDÄR] src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs - Begründung: Modul
Prüfidee: Reporting ohne Recht nicht aufrufbar.
Tracelinks: StRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-037
Titel: Tags, benutzerdefinierte Prozesse und CPra-Konnektor
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Administrator
Vorbedingung: -
Fakt: BL-Klassen `Tags/TagsBL.cs`, `Processes/ProcessBL.cs`, `CPra/CPraConnectorBL.cs`, `CPraConfigurationSettingsBL.cs`; Außerdem `Customizations`-Verzeichnis.
Aussage: Die Software soll Tags auf Objekten, Kundenprozesse (Workflows) und eine CPra-Integrationsanbindung konfigurierbar bereitstellen.
Ergebnis: Erweiterbarkeit ohne Customcode.
Belege:
- [PRIMÄR] src/backend/Centron.BL/{Tags/TagsBL.cs,Processes/ProcessBL.cs,CPra/CPraConnectorBL.cs} - durchgesetzte Modulinkrementierung
Prüfidee: Tag an Kunden anhängen/entfernen; Prozess-Definition ausführen.
Tracelinks: StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-038
Titel: Vouchermanagement (Gutscheine)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb
Vorbedingung: -
Fakt: BL-Klasse `VoucherManagement/VoucherManagementBL.cs`; Recht `RIGHT_GUTSCHEINVERWALTUNG` (20400319) ist `[Obsolete]`; Wertgutschrift-Recht `RIGHT_WERTGUTSCHRIFTANLEGEN` (20400292) aktiv.
Aussage: Die Software soll Gutscheine verwalten; das klassische Gutscheinmodul ist als veraltet markiert, Wertgutschriften bleiben aktiv verfügbar.
Ergebnis: Übergang vom Gutschein auf die Wertgutschrift.
Belege:
- [PRIMÄR] UserRightsConst.cs: `RIGHT_GUTSCHEINVERWALTUNG [Obsolete]` vs. `RIGHT_WERTGUTSCHRIFTANLEGEN` aktiv - durchgesetzte Migration der Rechte
- [SEKUNDÄR] src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs - Begründung: Modul
Prüfidee: Wertgutschrift anlegen erfordert Recht 20400292; Altmodul nicht mehr im Ribbon.
[Hinweis: Funktionsumfang VoucherManagementBL nicht vollständig analysiert]
Tracelinks: StRS-004
Konsolidierung: Kandidat: Gutschein vs. Wertgutschrift - in Zielsystem zusammenführen
Übernahmewürdigkeit: übernehmen - Wertgutschrift; klassische Gutscheinfunktion prüfen
Status: HYPOTHESE (genauer Funktionsumfang des Altmoduls nicht vollständig gelesen)
---
ID: SwRS-039
Titel: SelfCare und WebRequest
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Kunde/Mitarbeiter
Vorbedingung: SelfCare freigeschaltet
Fakt: BL-Klassen `SelfCare/SelfCareBL.cs` und `SelfCare/WebRequestPageBL.cs`; Self-Care-Formularfelder in C-FLOW Vorlagen (siehe SwRS-030).
Aussage: Die Software soll Self-Service-Formulare und öffentliche Webrequest-Seiten in Ticketvorlagen einbetten.
Ergebnis: Kundenanfragen landen als strukturierte Tickets.
Belege:
- [PRIMÄR] src/backend/Centron.BL/SelfCare/{SelfCareBL.cs,WebRequestPageBL.cs} - durchgesetzte Klassen
- [SEKUNDÄR] src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormField*.razor - Begründung: Formulargenerator
Prüfidee: Webrequest-Formular erzeugt Ticket.
Tracelinks: StRS-011, SwRS-030
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-040
Titel: KI-Promptkategorien und -Einstellungen
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Administrator
Vorbedingung: KI-Modul
Fakt: Tabellen `ArtificialIntelligencePromptCategory`, `ArtificialIntelligencePromptSettings`; Rechtegruppe siehe SyRS-032.
Aussage: Die Software soll KI-Prompts kategorisiert und je Instanz konfigurierbar abspeichern.
Ergebnis: Steuerbare Prompt-Bibliothek.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[ArtificialIntelligencePromptCategory]`, `[ArtificialIntelligencePromptSettings]` - durchgesetzte Persistenz
Prüfidee: Prompt-Setting ohne Zuordnung zu Kategorie (FK, falls vorhanden).
Tracelinks: SyRS-032, StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/SwRS.md
+588
View File
@@ -0,0 +1,588 @@
# SwRS - Software Requirements Specification
# c-entron ERP-Suite (Reverse Requirements Engineering, Baseline V1 Iteration 02)
---
ID: SwRS-001
Titel: Datenzugriffsschicht über NHibernate mit generischem DAO
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Komponente Centron.DAO
Vorbedingung: DB-Verbindung konfiguriert
Fakt: `Centron.DAO` enthält `GenericDAO.cs` (25.462 Bytes), `DAOFactory.cs` (11.714 Bytes, `SetConnection`), `DAOSession.cs`, `AdvancedSession.cs`, NHibernate-Konfiguration (`NHibernateConfiguration`), `Repositories`, `NamedQueries` und `CustomDAOs`; Session-Transaktionsmethoden `StartTransaction`, `CommitTransaction`, `RollbackTransaction` sowie `WithTransaction` werden von BLs genutzt (vgl. `ReceiptInvoiceBL`).
Aussage: Die Software soll den gesamten Datenbankzugriff über eine NHibernate-basierte DAO-Schicht mit zentraler Verbindungsverwaltung (`DAOFactory`), generischen Repositories und expliziten Transaktionsgrenzen in der BL ausführen.
Ergebnis: Einheitlicher Zugriff, testbare Transaktionen.
Belege:
- [PRIMÄR] src/backend/Centron.DAO/{GenericDAO.cs,DAOFactory.cs,DAOSession.cs} - durchgesetzte Architekturbasis
- [PRIMÄR] ReceiptInvoiceBL.CancelInvoice: `new DAOSession().WithTransaction(() => ...)` - durchgesetzte Transaktionsklammer
Prüfidee: DAOFactory liefert verbundene Session; Rollback macht alle Schritte rückgängig.
Tracelinks: SyRS-001
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - NHibernate-Schicht ist technisch zu ersetzen (z. B. EF Core), fachlich neutral
Status: belegt
---
ID: SwRS-002
Titel: Primärschlüsselkonzept I3D statt Id
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Persistenzschicht
Vorbedingung: -
Fakt: `src/backend/Centron.Entities/PersistedEntity.cs` und `PersistedLongEntity.cs`; nahezu sämtliche Schematabellen führen Spalte `I3D` als Primärschlüssel (RechKopf, Kunden, ARTIK, hlpdsk_requests ...); BL-Methoden arbeiten mit `...I3D`-Parametern (`invoiceI3D`, `customerI3D`, `appUserI3D`).
Aussage: Die Software soll alle persistierten Entitäten mit dem historischen Primärschlüsselfeld `I3D` führen und durchgängig referenzieren.
Ergebnis: Konsistente Referenzierung in Legacy- und Neumodule.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql (I3D-Spalten in allen Tabellendefinitionen) - durchgesetzte Konstante
- [SEKUNDÄR] src/backend/Centron.Entities/PersistedLongEntity.cs - Begründung: Basisklasse mit Schlüsselproperty
Prüfidee: Join zwischen `hlpdsk_requests` und `hlpdsk_timer` über `I3D`-FK.
Tracelinks: SyRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Umbenennung in Zielsystem nur mit Migrationsstrategie
Status: belegt
---
ID: SwRS-003
Titel: Beleg-Datenmodell Kopf/Position je Belegart inkl. Versionstabellen
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Persistenzschicht
Vorbedingung: -
Fakt: Pro Belegart eigenes Kopf-/Positionstabellenpaar (AngKopf/AngPos, AufKopf/AufPos, LiefKopf/LiefPos, AbholKopf/AbholPos, RechKopf/RechPos, GutKopf/GutPos, AnfrKopf/AnfrPos, BestKopf2/BestPos2, WareKopf/WarePos, KalkKopf/KalkPos, LiGutKopf/LiGutPos, VertragKopf/VertragPos) sowie Versionspendants.
Aussage: Die Software soll Belege als Kopf-Positionen-Strukturen je Belegart und je Version speichern; der Belegentyp bestimmt die Tabelle.
Ergebnis: Typspezifische Erweiterbarkeit, vollständige Historisierung.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql CREATE TABLE-Liste (AngKopf, RechKopf, RechKopfVersions u. a.) - durchgesetztes physisches Modell
Prüfidee: Rechnung speichern erzeugt Kopf + n Positionen und (bei Bearbeitung) Versionssatz.
Tracelinks: SyRS-012, StRS-004
Konsolidierung: Kandidat: neun parallele Kopf-/Pos-Tabellenpaare für denselben Beleg-Kern; im Zielsystem generische Belegtabelle mit Typ-Diskriminator prüfen
Übernahmewürdigkeit: übernehmen - Datenmigration muss Bestand erhalten
Status: belegt
---
ID: SwRS-004
Titel: Parallele Datenmodelle: Legacy-Tabellen (Kunden/ARTIK) vs. Account-Modell (Account*)
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Persistenzschicht
Vorbedingung: -
Fakt: Schema enthält sowohl Legacy-Tabellen (`Kunden`, `Kreditor`, `ARTIK`, `WAREN`, `Anschrif`, `Personen`) als auch neuere Account-Tabellen (`Accounts`, `AccountCustomers`, `AccountSuppliers`, `AccountAddresses`, `AccountAddressContacts`, `AccountTypes`, `AccountRelationships`, `AccountBusinessLine`); BL `Accounts/AccountBL.cs` und Fabriken `CustomerToBranchBL`, `SupplierToBranchBL` verwenden den neuen Kontext, `AddressContactPersonWebAccountRequests` verweist auf Account-Kontext.
Aussage: Die Software soll Geschäftspartner (Kunde/Lieferant) in einem übergreifenden Account-Modell führen, das die früheren Kunden-/Lieferanten-Modelle ablöst; beide Bestände koexistieren derzeit.
Ergebnis: Vereinheitlichung, derzeit noch mit Altbestand.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: Koexistenz von `[dbo].[Kunden]`, `[dbo].[Kreditor]` und `[dbo].[Accounts]`, `[dbo].[AccountCustomers]`, `[dbo].[AccountSuppliers]` - durchgesetzte Doppelhaltung
- [SEKUNDÄR] src/backend/Centron.BL/Accounts/*BL.cs - Begründung: BL arbeitet auf Account-Modell
Prüfidee: AccountEntity in `Accounts` wird über `AccountCustomers` als Kunde geführt.
Tracelinks: StRS-002
Konsolidierung: Kandidat: zwei Datenhaltungen für Geschäftspartner (Kunden/Kreditor vs. Accounts); im Zielsystem zusammenzuführen
Übernahmewürdigkeit: Workaround - Doppelhaltung historisch gewachsen
Status: belegt
---
ID: SwRS-005
Titel: Mandantenentität
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System
Vorbedingung: -
Fakt: Tabelle `[dbo].[Mandant]`; konfigurierte Mandantenbehandlung in mehreren Account-Zuordnungstabellen (`CustomerToBranches`, `LieferantenToFiliale`).
Aussage: Die Software soll Mandanten und Filialen als durchgängige Datenbankentitäten führen und Stammdaten je Mandant/Filiale zuordnen.
Ergebnis: Mandantenfähigkeit im Datenbankschema verankert.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `[dbo].[Mandant]`, `[dbo].[CustomerToBranches]`, `[dbo].[LieferantenToFiliale]` - durchgesetztes Modell
Prüfidee: Kunden-Filialzuordnung bleibt mandantentrennbar.
Tracelinks: StRS-012, StRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-006
Titel: Kundenanlagen: Stammblatt (GeraeteKopf/Pos) versus AssetManagement-Geräte
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Persistenzschicht
Vorbedingung: -
Fakt: Schema enthält `[dbo].[GeraeteKopf]`, `[GeraetePos]`, `[VertragGeraete]` für Kundenanlagen und zugleich ca. 180 Tabellen `[dbo].[AssetManagement...]` (Devices, Printer, Monitors, NetworkAdapter, OS, Patches, Checks, Diagrams, ...); BL `Sales/CustomerAssets/*Asset*BL` und `Devices`/`RiverDivo`-Modul greifen unterschiedlich zu.
Aussage: Die Software führt „Stammblätter" (druckerbezogene Anlagen) separat von sonstiger IT-Infrastruktur im AssetManagement-Konzept; dieselbe fachliche Aggregation „Gerät beim Kunden" ist zweifach modelliert.
Ergebnis: Doppelhaltung mit unterschiedlichen Detailgraden.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: `GeraeteKopf` vs. `AssetManagementDevices` - durchgesetzte Doppelhaltung
- [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs; MasterDataListBL mit Stammblatt-Terminologie - Begründung: fachliche Nutzung
- [KONTEXT] Prompt-Vorgabe (kalibriertes Beispiel Drucker/Stammblätter vs. Assets) - Begründung: fachliche Lesart
Prüfidee: Drucker bei Kunde X liegt entweder in GeraeteKopf oder AssetManagement vor - nicht konsolidiert.
Tracelinks: StRS-010, SyRS-024
Konsolidierung: Kandidat: zwei Datenmodelle für „Gerät beim Kunden" - im Zielsystem zu einem Asset-Konzept zusammenführen
Übernahmewürdigkeit: übernehmen - mit Datenkonsolidierung
Status: belegt
---
ID: SwRS-007
Titel: Rechtemodell: numerische Konstanten, Gruppen-ID + Unterrechte, [Obsolete]-Markierungen
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Komponente Rechteverwaltung
Vorbedingung: -
Fakt: `UserRightsConst` verwendet Konstanten-Ganzzahlen; Gruppen besitzen `ID` und Unterrechte (z. B. `Sales.Customer.CustomerCommon.Invoice.ID = 40003`, Rechte `CREATE_NEW_INVOICE = 20400195`); Kommentar „NEW .NET MODULE RIGHTS START AT 20800000"; zahlreiche `[Obsolete]`-Konstanten (Kassenbuch, Barrechnung, WebSuite, Riversuite, Projectverwaltung ...).
Aussage: Die Software soll Rechte über numerische Gruppen- und Unterrechts-IDs strukturieren; die ID-Blöcke 1xxxx/20xxxx/206xxxx gehören Altrechten, ab 20800000 liegt die neue .NET-Modulwelt. Abgelöste Rechte bleiben kompatibel in der Datenbank.
Ergebnis: Aufwärtskompatible Rechtematrix mit dokumentierter Verfallskennzeichnung.
Belege:
- [PRIMÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs (Header-Kommentar, `[Obsolete]`) - durchgesetzte Platzierung
- [KONTEXT] CentronRights.md - Begründung: Semantik der Altrechte
Prüfidee: Zurückgelieferte Rechte entsprechen den Konstanten; obsolet markierte IDs werden nicht mehr gescannt.
Tracelinks: SyRS-009, StRS-002
Konsolidierung: Kandidat: [Obsolete]-Rechte-Altbestand (Kassenbuch, RMA-SupRemo, Riversuite) - im Zielsystem Ausmusterung
Übernahmewürdigkeit: übernehmen - Kompatibilität; veraltete IDs gesondert ausmisten
Status: belegt
---
ID: SwRS-008
Titel: Ergebnisrückgabemuster `Result` / `ResultStatus` samt DefaultMessageCodes
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Komponente BL
Vorbedingung: -
Fakt: BL-Methoden liefern `Result` oder `Result<T>` mit `ResultStatus.Success|Warning|Error`, statischen Fabriken `AsError(message[, code])`, `AsSuccess(data)`; Codes wie `DefaultMessageCodes.RightCheckFailed`, `DependencyCheckFailed`, `CouldNotFindData`, `BadRequest`.
Aussage: Die Software soll Geschäftslogik deterministisch mit Result-Objekten antworten statt Ausnahmefehlern (außer Argument/Guard-Fehler); Fehlercodes sollen maschinell auswertbar sein.
Ergebnis: Einheitliche Fehlerbehandlung über BL-Grenzen.
Belege:
- [PRIMÄR] ReceiptInvoiceBL.CancelInvoice: ausschließlich `Result<ReceiptInvoice>.AsError(...)`-Rückgaben (durchgesetzte Stelle)
- [SEKUNDÄR] MasterDataListBL mit `DefaultMessageCodes.*` - Begründung: Kodex
Prüfidee: Simuliere Rechtefehler → Status Error, MessageCode RightCheckFailed.
Tracelinks: SyRS-003, SyRS-018
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - robuste BL-API
Status: belegt
---
ID: SwRS-009
Titel: Zentrale Beleglogik in `ReceiptBL` (God-Class) mit belegtypspezifischen Erweiterungen
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Komponente Vertriebslogik
Vorbedingung: -
Fakt: `ReceiptBL.cs` ist 623.866 Bytes groß, `ReceiptItemBL.cs` 230.597 Bytes, `ReceiptLogBL.cs` 75.952 Bytes; `IReceiptSpecificLogic` definiert Schnittstellen für Belegtyp-spezifische Abweichungen; `ReceiptInvoiceBL` delegiert zentrale Operationen (`GetReceiptByI3D`, `CreateNewVersion`, `SaveReceipt`, `GetReceiptForwardedInto`) an `ReceiptBL`.
Aussage: Die Software soll alle Belegoperationen über die zentrale Klasse `ReceiptBL` kanalisieren; belegtypspezifische Abweichungen laufen aus Sicht der Architektur über `IReceiptSpecificLogic`.
Ergebnis: Einheitliche Transaktions- und Versionssemantik, zentrale Komplexität.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (Größe/Aufgaben) und verwendung in ReceiptInvoiceBL - durchgesetzte Zentralisierung
- [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs - Begründung: Erweiterungspunkt
Prüfidee: Jede Belegart-Implementierung implementiert das Interface; paralleler Aufruf in ReceiptBL funktioniert bei zwei Typen.
Tracelinks: SyRS-013, StRS-004
Konsolidierung: Kandidat: God-Class - im Zielsystem auf Aggregate je Belegart verteilen
Übernahmewürdigkeit: Workaround - historisch gewachsene Alleinstellung sammelnder Fachlogik
Status: belegt
---
ID: SwRS-010
Titel: CreateNewVersion vor jeder mutierenden Belegoperation [Abrechnung]
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Komponente Beleglogik
Vorbedingung: -
Fakt: `ReceiptBL.CreateNewVersion<ReceiptInvoice>(int i3d, ..., CreateNewVersionData { IgnoreCallbacks = true })` wird in `ReceiptInvoiceBL.CancelInvoice` genutzt; `CreateNewVersionData` erlaubt das Unterdrücken von Callbacks; Versionierung erzeugt komplett neue Kopf-/Positionssätze.
Aussage: Die Software soll vor Storno und Nachbearbeitung eines abgeschlossenen Belegs eine neue Versionsspur erzeugen; interne Folgeverarbeitungen können Callbacks unterdrücken.
Ergebnis: Nachvollziehbarkeit über Revisionen.
Belege:
- [PRIMÄR] ReceiptInvoiceBL.CancelInvoice: Aufruf `CreateNewVersion<ReceiptInvoice>(... IgnoreCallbacks = true)` - durchgesetzte Stelle
- [SEKUNDÄR] SSMS `[RechKopfVersions]/[RechPosVersions]` - Begründung: persistierte Versionssätze
Prüfidee: Nach Storno existiert Version n+1 mit State Canceled; alte Version bleibt unverändert.
Tracelinks: SyRS-010, SyRS-012, StRS-005
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-011
Titel: Beleg-Protokollbuch: ReceiptLog samt Ereignistypen
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Komponente Audit
Vorbedingung: -
Fakt: `ReceiptLogBL` (75.952 Bytes); Aufrufe mit `CentronObjectKindNumeric.InvoiceClass` und Enum `ReceiptLogKind.FixedState`; `ReceiptInvoiceBL.CancelInvoice` verwendet `CreateInvoiceCancelledEntry(newInvoiceVersion, currentUser)`; Ereignis beschreibt Mitarbeiter und Zeitstempel.
Aussage: Die Software soll jede relevante Belegenaktion (Festgeschrieben, Storniert u. a.) als ReceiptLog-Eintrag mit Art, Benutzer, Zeit und Beschreibung protokollieren.
Ergebnis: Revisionspfad je Beleg.
Belege:
- [PRIMÄR] ReceiptInvoiceBL.FixInvoice → `logBL.CreateEntry(... ReceiptLogKind.FixedState ...)`; `CancelInvoice` → `CreateInvoiceCancelledEntry` - durchgesetzte Stelle
- [SEKUNDÄR] UserRightsConst.cs `SHOW_AUDIT` (20800097) - Begründung: Sichtbarkeit des Audit-Logs
Prüfidee: Festschreibung erzeugt Logeintrag mit Employee und Datum.
Tracelinks: SyRS-010, SyRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-012
Titel: Festschreibung als direktes SQL-Update (ORM-Bypass)
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Komponente Beleglogik
Vorbedingung: -
Fakt: `ReceiptInvoiceBL.FixInvoice` schreibt über `Session.Advanced.RawSqlAccess.ExecuteNonQueryTransactionSave` mit `UPDATE RechKopf SET IsFixed = 1` und expliziter Transaktion `StartTransaction`/`Commit`/`RollbackTransaction`.
Aussage: Die Software soll die Festschreibung eines Belegs transaktional als direktes SQL-Statement durchführen, um unabhängige Audit-Spur schreiben zu können.
Ergebnis: Atomare Festschreibung mit Logging.
Belege:
- [PRIMÄR] ReceiptInvoiceBL.FixInvoice (SQL-Text, Transaktionsklammer) - durchsetzende Stelle
Prüfidee: Update schlägt fehl → Rollback macht auch Logeintrag rückgängig (Integrationstest).
Tracelinks: SyRS-011
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - ORM-Bypass aus Altbestand; im Zielsystem einheitlich über Repository
Status: belegt
---
ID: SwRS-013
Titel: Lagerecht: Negativbuchung als eigenes Recht [Berechtigung]
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Lagerverwaltung
Vorbedingung: Artikel mit Bestand
Fakt: Recht `BOOK_ARTICLE_STOCK_INTO_NEGATIVE` (20400011) bzw. `RIGHT_NEGATIVBUCHUNG` (20400011); Recht `TRANSFER_STOCK` (20400060), `BOOK_TO_STOCK` (20400105), `BOOK_FROM_STOCK` (20400106); Typ `SecondStockArticleBL` (Nebenlager).
Aussage: Die Software soll Zu-, Ab- und Umbuchungen einzeln berechtigen; Buchungen ins Negative sollen nur mit explizitem Recht erlaubt sein; Nebenlager werden gesondert geführt.
Ergebnis: Bestandspflege unter Kontrolle.
Belege:
- [PRIMÄR] UserRightsConst.cs `Purchase.StockList`-Block - durchgesetzte Rechte-Matrix
- [SEKUNDÄR] src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs - Begründung: Nebenlagerlogik
Prüfidee: Abbuchung über Bestand ohne Recht wird blockiert.
Tracelinks: StRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-014
Titel: WPF-Desktop-Client mit MVVM und Modul-Registrierung
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Desktop-Nutzer
Vorbedingung: Windows-Client
Fakt: `src/centron/Centron.WPF.UI/App.xaml.cs` (32.927 Bytes), `FrontWindowViewModel.cs`, Verzeichnisse `ViewModels`, `Dialogs`, `Messages`, `Modules` mit `CentronModule.cs`, `ModuleRegistration.cs`, `ModuleRightsExpressionParser.cs`, `Localization`, `Behaviors`; XAML-Oberflächen (1233 XAML-Dateien laut dir-Zählung).
Aussage: Die Software soll den Desktop-Client als MVVM-Aufbau mit Ribbon-Navigation, modul registrierten Views und rechtegesteuerten Modul-Expressionen betreiben.
Ergebnis: Ausbaubare, rechtekonforme Modulstruktur.
Belege:
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/{CentronModule,ModuleRegistration,ModuleRightsExpressionParser}.cs - durchgesetzte Modul-Registrierung
- [SEKUNDÄR] FrontWindowViewModel.cs - Begründung: Shell-ViewModel
Prüfidee: Modul-ID mit fehlendem Recht wird im Ribbon ausgeblendet.
Tracelinks: SyRS-001
Konsolidierung: nein
Übernahmewürdigkeit: veraltet - Ziel ist Webclient; Funktionsumfang wird übernommen, Technologie nicht
Status: belegt
---
ID: SwRS-015
Titel: OpenTrans-Gateway für strukturierte XML-Dokumente
Ebene: SwRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Komponente Gateway
Vorbedingung: XML-Dokument vorliegend
Fakt: Projekt `src/backend/Centron.Gateway` (OpenTrans); `ReceiptInvoiceBL.TryDeserializeOpenTransInvoice` nutzt `XmlSerializer(typeof(INVOICE))` aus `Centron.Gateway.OpenTrans`.
Aussage: Die Software soll OpenTrans/XML-Dokumente (z. B. INVOICE) über das Gateway typisiert deserialisieren; invalides XML führt zu `Result.FromException`.
Ergebnis: Robuster strukturierter Datengegenverkehr.
Belege:
- [PRIMÄR] ReceiptInvoiceBL.TryDeserializeOpenTransInvoice - durchgesetzte Stelle
- [SEKUNDÄR] src/backend/Centron.Gateway - Begründung: Integrationsprojekt
Prüfidee: Fehlerhafte XML liefert Result Status Error mit Exception-Detail.
Tracelinks: SyRS-025, SyRS-004
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-016
Titel: Nexus Web-Account-Registrierung als Datenbankanforderung
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Kunde vorhanden
Fakt: Tabelle `AddressContactPersonWebAccountRequests`; WebAccount-Recht `WEBACCOUNT_MANAGEMENT` (20800162).
Aussage: Die Software soll Web-Accounts an Ansprechpartner-Adressen koppeln und deren Anlage über ein Recht steuerbar machen.
Ergebnis: Nachvollziehbare Selbstregistrierung.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql `[dbo].[AddressContactPersonWebAccountRequests]` - durchgesetzte Persistenz
- [SEKUNDÄR] UserRightsConst.cs `WEBACCOUNT_MANAGEMENT` - Begründung: Verwaltungsrecht
Prüfidee: Anfrage ohne zugehörige Ansprechperson nicht anlegbar (FK-Test).
Tracelinks: SyRS-031, StRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-017
Titel: Helpdesk-Datenmodell mit Bearbeiterzuordnung
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Persistenzschicht
Vorbedingung: Tickettyp/-kategorie definiert
Fakt: `hlpdsk_requests` mit `hlpdsk_request_bearbeiter` (Mehrfachbearbeiter), `hlpdsk_history`, `hlpdsk_typen`, `hlpdsk_kategorien`, `hlpdsk_prioritaeten`, `hlpdsk_status`, `hlpdsk_timer`.
Aussage: Die Software soll Tickets mit Kategorien zweier Ebenen, Prioritäten, Status und Mehrfachbearbeiterzuordnung persistieren; Änderungen in einer History-Tabelle nachhalten.
Ergebnis: Revisionssicheres Ticketmodell.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql `hlpdsk_*`-CREATE TABLE-Liste - durchgesetztes Modell
Prüfidee: Ticket mit zwei Bearbeitern in Zwischentabelle; Statuswechsel erzeugt History-Zeile.
Tracelinks: StRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-018
Titel: Helpdesk-Fingerprint-Integritätsdienst
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit (Integrität)
Akteur: System
Vorbedingung: -
Fakt: HostedService `ValidateHelpdeskFingerprintService` (registriert in CentronHost).
Aussage: Die Software soll periodisch Fingerprints der Helpdesk-Datensätze validieren, um Manipulation zu erkennen.
Ergebnis: Manipulationsaufdeckung laufend.
Belege:
- [PRIMÄR] CentronHost.cs: `f.AddHostedService<ValidateHelpdeskFingerprintService>()` - durchgesetzte Registrierung
Prüfidee: Geänderter Ticket-Primärdatensatz mit unverändertem Hash → Dienst meldet Abweichung.
Tracelinks: StRS-006, SyRS-030
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - integritätssicher
Status: belegt
---
ID: SwRS-019
Titel: Internationalisierung über SharedResource
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit
Akteur: UI
Vorbedingung: -
Fakt: `SharedResource.resx` (7.447 Bytes, de) und `SharedResource.en-US.resx` (7.258 Bytes) sowie Designer-Dateien im Projekt `CentronNexus`; ResXManager config im Root.
Aussage: Die Software soll Texte im Web-Zweig über .resx-Ressourcen verwalten (de/en-US), verwaltbar über ResXManager.
Ergebnis: Mehrsprachige Oberflächen ohne Codeforks.
Belege:
- [PRIMÄR] src/nexus/CentronNexus/SharedResource.{resx,en-US.resx} - durchgesetzte Ressourcendateien
- [SEKUNDÄR] ResXManager.config.xml - Begründung: Verwaltungswerkzeug
Prüfidee: Fehlt ein Key → Fallback auf Neutral-ResX.
Tracelinks: SyRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-020
Titel: Kassenbuch: aktuell als [Obsolete] markiert, Tabelle vorhanden
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Kasse
Vorbedingung: -
Fakt: Tabelle `[dbo].[Kassenbuch]` existiert; alle Kassenbuch-Rechte in `UserRightsConst` sind `[Obsolete]` (`RIGHT_KASSENBUCH`, `RIGHT_KASSENBUCHEINBUCHUNG`, `RIGHT_KASSENBUCHAUSBUCHUNG`, `RIGHT_KASSENABSCHLUSS`, `RIGHT_KASSENBUCHERWEITERT`); BL-Verzeichnis `Sales/CashBooks`.
Aussage: Die Software enthält noch ein physisches Kassenbuchmodul, jedoch sind die zugehörigen Rechte als veraltet markiert; Funktionsverwendung im WPF wurde laut Rechtekommentaren weitgehend stillgelegt.
Ergebnis: Altmodul mit Datenbestand, aber kaum aktiver Fläche.
Belege:
- [PRIMÄR] UserRightsConst.cs `Sales.Cashbox`: sämtliche IDs `[Obsolete]` - durchgesetzte Abschaltung
- [PRIMÄR] SSMS `[dbo].[Kassenbuch]` - Begründung: Datentabelle noch vorhanden
- [SEKUNDÄR] src/backend/Centron.BL/Sales/CashBooks - Begründung: BL-Modulrest
Prüfidee: Rechtsvergabe im Admin zeigt Kassenbuch-Rechte nicht mehr.
Tracelinks: StRS-008
Konsolidierung: Kandidat: Altmodul - Migration datenseitig prüfen
Übernahmewürdigkeit: veraltet - Kassenfunktion abgelöst; Bestandsdaten migrieren
Status: belegt
---
ID: SwRS-021
Titel: hlpdsk-/Beleg-Fingerprint- und Eskalations-Trigger als Hintergrunddienst
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Fristen konfiguriert
Fakt: HostedService `EscalationsService`; Tabelle `hlpdsk_status`, `hlpdsk_prioritaeten`; Recht `MATURITY_CHANGE` (20400131) erforderlich, wenn Statuswechsel Fälligkeitsänderung nach sich zieht.
Aussage: Die Software sollTickets bei Fristüberschreitung eskalieren und Statusänderungen, die Fälligkeit beeinflussen, nur mit eigenem Recht zulassen.
Ergebnis: Gesteuerte Eskalation, revisionssicher.
Belege:
- [PRIMÄR] CentronHost.cs `AddHostedService<EscalationsService>()` - durchgesetzte Registrierung
- [PRIMÄR] CentronRights.md Nr. 5: „This may also be required when changing the status of a ticket, if this requires a due date change." - Begründung: fachliche Regel (Kontext, keine Durchsetzungsstelle)
Prüfidee: Statuswechsel mit Fälligkeitsänderung ohne Recht → Hinweis; Eskalationsdienst degradiert überfällige Tickets simulierbar.
Tracelinks: StRS-006, SyRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-022
Titel: CORS-Richtlinie erlaubt alle Ursprünge [Sicherheit, Konfiguration]
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Webservice-Betreiber
Vorbedingung: -
Fakt: `CentronHost.ConfigureInternal`: `b.UseCors(d => d.AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod());`
Aussage: Die Software erlaubt CORS von beliebigen Origins; diese Konfiguration ist im Zielsystem zu ersetzen durch restriktive Whitelists.
Ergebnis: Gegenwärtig unkritisch aufgrund eigenständiger Authentifizierung, jedoch erhöhtes Risikoprofil für SaaS.
Belege:
- [PRIMÄR] src/webservice/Centron.Host/CentronHost.cs `UseCors(d => d.AllowAnyOrigin()...)` - durchsetzende Stelle
Prüfidee: Preflight-OPTIONS-Anfrage von fremder Origin wird akzeptiert (nachzuweisen).
Tracelinks: SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - historisch toleriert; im Web-/SaaS-Zielsystem absichern
Status: belegt
---
ID: SwRS-023
Titel: Windows- vs. Linux-Websocket (HttpSys vs. Kestrel) und HTTPS-Zertifikate
Ebene: SwRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit
Akteur: Betreiber
Vorbedingung: Konfigurierte Webservice-Adresse
Fakt: `CentronHost.Start`: `OperatingSystem.IsWindows()` → `builder.UseHttpSys(... UrlPrefix = * bei localhost ...)`, sonst `UseKestrel` mit `ListenAnyIP(this.Url.Port)`; HTTPS über `X509CertificateLoader.LoadPkcs12FromFile(WebServiceCertificateFilePath, WebServiceCertificatePassword)`; `MaxRequestBodySize = null` zwecks großer Uploads; Timeouts 30 Min (IdleConnection/RequestQueue) bzw. 5 Min (RequestHeadersTimeout).
Aussage: Die Software soll den Webservice plattformübergreifend (HttpSys auf Windows, Kestrel sonst) mit konfigurierbarem HTTPS und erhöhten Timeouts für langlaufende Geschäftsvorgänge betreiben; Upload-Limits sind deaktiviert.
Ergebnis: Betrieb auf Windows und Linux ohne Codebranch.
Belege:
- [PRIMÄR] CentronHost.cs: UseHttpSys/UseKestrel-Verzweigung, Timeout-Werte, `X509CertificateLoader.LoadPkcs12FromFile` - durchgesetzte Stelle
Prüfidee: Start unter Linux mit https://-URL ohne Zertifikat → Startfehler; mit Zertifikat erfolgreich.
Tracelinks: SyRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Hosting-Flexibilität fürs Web
Status: belegt
---
ID: SwRS-024
Titel: Webkonfiguration und Geheimnisse in Datei (WebServiceConfig)
Ebene: SwRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit (Konfiguration)
Akteur: Admin
Vorbedingung: WebServiceConfig.xml
Fakt: `WebServiceConfigHelper.Current` stellt `WebServiceAddress`, `WebServiceCertificateFilePath`, `WebServiceCertificatePassword`, `SecretKey`, `ActiveDirectoryAuthEnabled`, `TwoFactorAuthEnabled`, `ExecuteServices`, `ActivateHelpPage`; `SaveToFileAsync` schreibt konfiguration zurück in Datei.
Aussage: Die Software liest Betriebsparameter und Geheimnisse aus einer Datei `WebServiceConfig.xml`; Änderungen (z. B. ActiveDirectoryAuthEnabled-Migration) werden persistiert.
Ergebnis: Konfiguration änderbar ohne Deployment; Geheimnisse aber im Klartext abgelegt.
Belege:
- [PRIMÄR] CentronHost.cs Verwendung von `WebServiceConfigHelper.Current` und `WebServiceConfigHelper.SaveToFileAsync()` - durchgesetzte Stelle
- [SEKUNDÄR] src/webservice/c-entron.misc.ConnectionManager - Begründung: Verwaltungs-UI für Verbindungen
Prüfidee: Änderung `TwoFactorAuthEnabled=true` in Xml wird nach Service-Neustart wirksam.
Tracelinks: SyRS-022, SyRS-005
Konsolidierung: nein
Übernahmewürdigkeit: Workaround - im Zielsystem in Secrets-Store migrieren
Status: belegt
---
ID: SwRS-025
Titel: Zeitkonten: Urlaub/Krankheit/Kurzarbeit/Überstundenausgleich mit Einzelrechten
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Personalabteilung
Vorbedingung: Mitarbeiter
Fakt: Rechteblock `RIGHT_TERMINPLANUNG*` (20400272 Urlaub genehmigen, 20400273 für anderen eintragen, 20400274 Genehmigung, 20400275/76/77 Krankheitstage, 20400279/80/81 Überstundenausgleich, 20400282/83/84 Kurzarbeit); Tabellen `Terminplanung`, `TerminplanungArt`, `TerminplanungPerson`.
Aussage: Die Software soll Terminplanungsaktivitäten (Urlaub, Krankheit, Kurzarbeit, Überstundenausgleich) mit getrennten Rechten für Anlage, Bearbeitung und Genehmigung führen.
Ergebnis: Datenschutzkonforme Personalzeitverwaltung.
Belege:
- [PRIMÄR] UserRightsConst.cs `RIGHT_TERMINPLANUNG*`-Block - durchgesetzte Rechte-Matrix
- [SEKUNDÄR] SSMS `[dbo].[Terminplanung*]` - Begründung: persistenter Terminplan
Prüfidee: Krankheitstage-Anlage ohne Recht abgelehnt.
Tracelinks: StRS-006, StRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-026
Titel: Textbausteine (TextModuleArea)
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: alle
Vorbedingung: -
Fakt: BL-Verzeichnis `TextModuleArea`; Recht `RIGHT_TEXTBAUSTEINE` (20400178); Tabelle `GeschaeftspartnerTextbausteine`; DAO-Verzeichnis `TextModuleArea`.
Aussage: Die Software soll Textbausteine zentral verwalten und geschäftspartnerbezogen einsetzen.
Ergebnis: Wiederverwendbare Korrespondenztexte.
Belege:
- [PRIMÄR] UserRightsConst.cs `RIGHT_TEXTBAUSTEINE = 20400178` - Begründung: durchgesetztes Recht
- [SEKUNDÄR] SSMS `[dbo].[GeschaeftspartnerTextbausteine]`, src/backend/Centron.BL/TextModuleArea - Begründung: Modul und Speicher
Prüfidee: Textbaustein ohne Recht nicht pflegbar.
Tracelinks: StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-027
Titel: Massenupdates und Datenqualität
Ebene: SwRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Administrator
Vorbedingung: Profile konfiguriert
Fakt: BL-Verzeichnisse `MassUpdate`, `Tools`, `ExternalToolsBL`, `Customizations`; ViewModel-Verzeichnis `Massenupdates`; HostedService `MassUpdateService`, `DataQualityService`.
Aussage: Die Software soll Massenupdate-Profile zeitgesteuert ausführen und Datenqualität kontinuierlich prüfen.
Ergebnis: Datenpflege automatisiert.
Belege:
- [PRIMÄR] CentronHost.cs `MassUpdateService`, `DataQualityService` - durchgesetzte Registrierung
- [SEKUNDÄR] src/backend/Centron.BL/MassUpdate, WPF `ViewModels/Modules/Massenupdates` - Begründung: UI und BL
Prüfidee: Zeitplan erreicht → Massenupdate erzeugt Logeintrag.
Tracelinks: StRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SwRS-028
Titel: Change Tracking separat verankert
Ebene: SwRS
Typ: Daten
Qualitätsmerkmal:
Akteur: System
Vorbedingung: -
Fakt: BL-Verzeichnis `ChangeTracking`; DAO-Verzeichnis `ChangeTracking`; Recht `SHOW_AUDIT` (20800097); ReceiptLog-Protokoll siehe SwRS-011.
Aussage: Die Software soll Änderungshistorien von Entitäten getrennt vom Beleglog als Change-Tracking-Subsystem führen.
Ergebnis: Feldebene-Auditing unabhängig von Belegen.
Belege:
- [SEKUNDÄR] src/backend/Centron.BL/ChangeTracking, src/backend/Centron.DAO/ChangeTracking - Begründung: durchgetrennte Subsystemmodule
- [PRIMÄR] UserRightsConst.cs `SHOW_AUDIT` - Begründung: Recht zur Ansicht
Prüfidee: Feldänderung erzeugt Change-Tracking-Eintrag; Sichtbarkeit an Recht gebunden.
Tracelinks: SyRS-011, SwRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - als einheitliches Audit im Zielsystem mit SwRS-011 zusammenführen
Status: belegt
---
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/SyRS-Ergaenzungen.md
+129
View File
@@ -0,0 +1,129 @@
# SyRS - Ergänzende System Requirements (Modul-Breitabdeckung, Teil 2)
# Fortsetzung von SyRS.md (IDs SyRS-037 ff.)
---
ID: SyRS-037
Titel: Rücksendung (RMA) und Reparatureingang
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Service
Vorbedingung: Artikel/Gerät betroffen
Fakt: Tabelle `[dbo].[Rma]`; Rechte `RIGHT_RMA` (20400198), `RIGHT_RMAANLEGEN` (20400210), `RIGHT_RMAARTIKELSTATUSAENDERN` (20400199), `RIGHT_REPARATUREINGANG` (20400129), `RIGHT_REPARATUREINGANGANZEIGEN` (20400130) inkl. Filialrestriktion `RIGHT_REPARATUREINGANGANZEIGENFILIALE` (20400222), `RIGHT_RUECKSENDUNG*` (20400127-20400128, nur eigene Filiale 20400223); WPF-Modul `ViewModels/Modules/Rma`.
Aussage: Das System soll Rücksendungen als RMA-Fälle anlegen, Reparatureingänge erfassen und den Artikelstatus rechtegesteuert ändern; Sichtbarkeit kann filialbezogen begrenzt werden.
Ergebnis: Reverse-Logistik durchgängig.
Belege:
- [PRIMÄR] UserRightsConst.cs IDs 20400198-20400223 - durchgesetzte Rechte-Matrix
- [PRIMÄR] SSMS_DB_SCHEMA.sql `[dbo].[Rma]` - durchgesetzte Persistenz
Prüfidee: RMA-Fall anlegen ohne Recht nicht möglich; Statuswechsel nur mit Recht 20400199.
Tracelinks: StRS-006, StRS-009
Konsolidierung: Kandidat: RMA-Fall und Reparatur/Reparatureingang als zwei Wege für denselben fachlichen Vorgang
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-038
Titel: Marketing/Sonderaktionen, Telemarketing und CRM-Projekte
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Marketing/Vertrieb
Vorbedingung: Kundenstamm
Fakt: Tabellen `Sonderaktionen`, `SonderaktionenAktion`, `SonderaktionenAktionVorlagen`, `SonderaktionenReferenzen`, `TelemarketingParticipants`, `CRMProjekt`, `CRMProjektObjekt`, `Kontakt`/`KontaktePersonen`; BL `Sales/Marketing/TelemarketingBL.cs`, `TelemarketingActionBL.cs`, u. a.; Rechte `RIGHT_SONDERAKTIONEN` (111170), `RIGHT_AKQUISE` (2060033), `RIGHT_CRMPROJEKTE*` (20400235/36, ONLY_OWN_BRANCH, ONLY_OWN, EXCEL_EXPORT), Kontaktverwaltung (20400244/45).
Aussage: Das System soll Marketing-Sonderaktionen mit Vorlagen und Referenzen, Telemarketing-Aktionen mit Teilnehmern sowie CRM-Projekte mit Objekten führen; CRM-Sichtbarkeit ist eigen- und filialbezogen beschränkbar und excel-exportierbar.
Ergebnis: Vertriebskampagnen plan- und auswertbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Marketing/TelemarketingBL.cs (+ Action/Template/Reference/Text BLs) - durchgesetzte BL
- [PRIMÄR] UserRightsConst.cs CRM-Projektrechte 20400235-20800139 - durchgesetzte Rechte
- [SEKUNDÄR] SSMS `Sonderaktionen*`, `CRMProjekt*` - Begründung: Persistenz
Prüfidee: CRM-Export ohne Recht 20800138 nicht möglich.
Tracelinks: StRS-002, StRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-039
Titel: EDI-Management mit Gateway, Dispatcher, Logs und zeitgesteuertem Download
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf/Vertrieb-Automation
Vorbedingung: EDI-Gateway konfiguriert
Fakt: `EDICommonBL`, `EDIDispatcherBL`, `EDIGatewaySettingBL`, `EDILogBL`, `EdiExportBL`, `EdiDocumentBL`; HostedService `EdiDownloadService`; Recht `RIGHT_EDIMANAGEMENT` (20400343), `RIGHT_EDI1` (10790).
Aussage: Das System soll EDI-Nachrichten gatewaygestützt versenden/empfangen, zeitgesteuert abrufen, jede Verarbeitung loggen und Verarbeitung je Einstellung dispatchen; Nutzung ist lizensiert/Rechte-gebunden.
Ergebnis: Revisionsfähiges EDI ohne manuelle Eingriffe.
Belege:
- [PRIMÄR] src/backend/Centron.BL/EDI/{EDIDispatcherBL,EDIGatewaySettingBL,EDILogBL}.cs - durchgesetzte Verarbeitung
- [PRIMÄR] CentronHost.cs: `EdiDownloadService` - durchgesetzte Zeitsteuerung
Prüfidee: Empfangene Nachricht erzeugt EDILog-Eintrag; Recht fehlt → UI verbirgt Verwaltung.
Tracelinks: SyRS-020, SyRS-025
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-040
Titel: Kostenstellen/Kostenträger und Zahlungskonditionen als Stammdaten
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Controlling/Buchhaltung
Vorbedingung: -
Fakt: Tabellen `Kostenstellen`, `Kostentraeger`, `Zahkond`, `Stammdat`; BL `Warehousing/{CostCenterBL,CostObjectBL}` (Cost-Center im Warehousing-Namespace), WPF-Modul `PayersAndCostCenter`; Recht `Masterdata.PAYERS_AND_COST_CENTER` (10450), `PAYMENT_CONDITION` (10410).
Aussage: Das System soll Kostenstellen, Kostenträger und Zahlungskonditionen als Stammdaten hinter eigenen Verwaltungsrechten pflegen und in Belegen referenzieren.
Ergebnis: Controllingfähige Stammdaten.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql `[dbo].[Kostenstellen]`, `[dbo].[Kostentraeger]`, `[dbo].[Zahkond]` - durchgesetzte Persistenz
- [PRIMÄR] src/backend/Centron.BL/Warehousing/{CostCenterBL.cs,CostObjectBL.cs} - durchgesetzte BL
Prüfidee: Zuordnung der Zahlungskondition zum Geschäftspartner persistiert.
Tracelinks: SyRS-015, StRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-041
Titel: PLM-/QM-/Kontrollmodule für Arbeitsplätze und Umwelt/Arbeitssicherheit
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Fertigung, QS
Vorbedingung: Lizenz QM
Fakt: Tabellen `AGArbeitssicherheit`, `AGLohngruppe`, `AGMaterial`, `AGPrufvorschrift`, `AGUmweltschutz`, `Arbeitsplatz*`; HostedService `PlmImportService`; WPF-Module `PLM` und `QM`; Recht `RIGHT_AUFTRAGFINALVERSIONSETZEN` (20400317, mit Hinweis „Benötigt die c-entron Lizenz QM-Module").
Aussage: Das System soll Arbeitsplatz-/Arbeitsgangstammdaten inkl. Arbeitssicherheits-, Umweltschutz-, Material- und Prüfvorschriften führen sowie PLM-Importe zeitgesteuert einspielen; QM-Funktionen sind lizenzpflichtig.
Ergebnis: Regulatorische Fertigungsdokumentation.
Belege:
- [PRIMÄR] CentronHost.cs: `PlmImportService` - durchgesetzte Registrierung
- [SEKUNDÄR] SSMS `AG*`-CREATE TABLEs, UserRightsConst 20400317 (Rechtstext erwähnt QM-Lizenz) - Begründung: Persistenz und Lizenzbindung
Prüfidee: QM-Funktion ohne Lizenz nicht sichtbar.
Tracelinks: StRS-014, SyRS-006
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - branchenspezifisch, Lizenzmodul
Status: belegt
---
ID: SyRS-042
Titel: Vertragsübergreifende Preis-/Produktleitplanken: Projekte und Projektpreis-Import
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertriebsleitung
Vorbedingung: Kunden vorhanden
Fakt: BL `Projects/ProjectBL.cs`, Verzeichnis `TicketProjects`; WPF-Modul `ProjectPriceImport`; Recht `Project_Price_Import` (20800043), Preisanpassungsrechte je Belegart 20400233/34/85-91; Recht `RIGHT_ANGEBOTEKANPASSENPROJEKTPREISE` (20400308).
Aussage: Das System soll Vertriebsprojekte verwalten, Projektpreise zu importieren gestatten und die Preisanpassung bei Projektpreisen pro Belegart rechtegesteuert erlauben.
Ergebnis: Kunden-/Projektbezogene Preisgestaltung.
Belege:
- [PRIMÄR] UserRightsConst.cs IDs 20800043, 20400308 u. Preisänderungsrechte - durchgesetzte Rechte
- [SEKUNDÄR] src/backend/Centron.BL/Projects/ProjectBL.cs, WPF `ViewModels/Modules/ProjectPriceImport` - Begründung: BL/UI
Prüfidee: Preisimport ohne Recht abgelehnt.
Tracelinks: StRS-004, SyRS-016
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/SyRS.md
+769
View File
@@ -0,0 +1,769 @@
# SyRS - System Requirements Specification
# c-entron ERP-Suite (Reverse Requirements Engineering, Baseline V1 Iteration 02)
---
ID: SyRS-001
Titel: Schichtenarchitektur: WPF-Client, Webservice-Host, Blazor-Webclient
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Übertragbarkeit/Wartbarkeit
Akteur: Systembetreiber
Vorbedingung: MSSQL-Datenbank installiert
Fakt: Projektliste (Centron.sln / dir-Ausgabe): `Centron.WPF.UI` (Desktop), `Centron.Host` + `Centron.Controllers` (ASP.NET-Core-REST-Host, auch als WindowsService und Linux-Console), `CentronNexus.Host`/`CentronNexus` (Blazor), `CentronNexus.OutlookAddIn`; Businesslogik in `Centron.BL`, Persistenz in `Centron.DAO` (NHibernate).
Aussage: Das System soll eine Drei-Kanäle-Architektur (Desktop-WPF, REST-Webservice-Host, Blazor-Web) auf gemeinsamer Business- und Persistenzschicht betreiben.
Ergebnis: Fachlogik ist kanalunabhängig wiederverwendbar; alle Kanäle nutzen dieselbe Datenbank.
Belege:
- [PRIMÄR] src/webservice/Centron.Host/CentronHost.cs (WebHostBuilder mit HttpSys/Kestrel) - Begründung: durchgesetzter Systemstart des REST-Hosts
- [SEKUNDÄR] Centron.sln; src/nexus/CentronNexus.Host; src/centron/Centron.WPF.UI - Begründung: Projektstruktur der Kanäle
Prüfidee: WPF-Client und Webclient lesen denselben Beleg aus derselben Datenbank.
Tracelinks: StRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - entspricht der SaaS-Zielarchitektur, WPF wird abgelöst (siehe SwRS-014)
Status: belegt
---
ID: SyRS-002
Titel: Versionierte REST-API
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: externe Integration, Webclient
Vorbedingung: Webservice läuft
Fakt: Controller-Struktur `src/webservice/Centron.Controllers/Controllers/v1` (Accounts, Contracts, Customers, DataExchange, Helpdesks, Offers, Orders, Receipts, SelfCare, Tickets, WebAccount, WebVersion ...) plus `Controllers/Unversioned` (AuthConfigurationController, JwtAuthController, TwoFactorAuthController); `AddCentronApiVersioning()` in `CentronHost.Start()`.
Aussage: Das System soll eine versionierte REST-API (v1) für die fachlichen Kernressourcen anbieten; unversionierte Endpunkte sind auf Authentifizierungsaufgaben beschränkt.
Ergebnis: API-Änderungen sind versionsstabil, Clients können gezielt binden.
Belege:
- [PRIMÄR] CentronHost.cs: `f.AddCentronApiVersioning()` - Begründung: durchgesetzte Versionierung im Request-Pipeline-Setup
- [SEKUNDÄR] Verzeichnisse src/webservice/Centron.Controllers/Controllers/v1 und /Unversioned - Begründung: tatsächliche Controller-Topologie
Prüfidee: GET auf v1-Controller liefert Version-Header; unversionierte Endpunkte außer Auth liefern 404.
Tracelinks: StRS-014 (Ausweitung), SwRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Pflicht für SaaS-Ökosystem
Status: belegt
---
ID: SyRS-003
Titel: Ticket-basierte Authentifizierung des Webservices [Sicherheit]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit (Vertraulichkeit/Authentizität)
Akteur: alle Webservice-Clients
Vorbedingung: gültiges Benutzerkonto
Fakt: `CentronHost.Start()`: `auth.AddCentronTicket()` als `TicketAuthenticationDefaults.AuthenticationScheme` konfiguriert; `TicketBL.GetTicket(string ticketId)` löst Ticket über `TicketRepository`; `AuthenticationTicketBL` verknüpft Ticket mit Authentifizierung; `routes.MapControllers().RequireAuthorization()` erfordert grundsätzlich Authentifizierung.
Aussage: Das System soll alle REST-Endpunkte (außer explizit `[AllowAnonymous]`) authentifizieren; Benutzer authentifizieren sich über Ticket-Token, die serverseitig auflösbar und an einen `UserI3D` gebunden sind.
Ergebnis: Unauthentifizierte Aufrufe werden abgewiesen; Tickets bezugnehmender Benutzer sind nachvollziehbar.
Belege:
- [PRIMÄR] CentronHost.cs: `auth.AddCentronTicket()` und `routes.MapControllers().RequireAuthorization()` (durchsetzende Stelle: Authentication-Setup + Endpoint-Requirement)
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/TicketBL.cs: `GetTicket(ticketId)` (durchsetzende Stelle: Repository-Auflösung des Tokens)
- [SEKUNDÄR] JwtAuthController.ConnectAccounts prüft `ticketResult.Data.UserI3D > 0` - Begründung: Ticket bound an Benutzer
Prüfidee: Request ohne Ticket → 401; Request mit gültigem Ticket → Claims/Benutzerkontext gesetzt.
Tracelinks: StRS-002, StRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - mit OAuth2/OIDC als Ziel neu zu bewerten
Status: belegt
---
ID: SyRS-004
Titel: JWT/OpenID-Connect-Login [Sicherheit]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: IdP-integrierte Benutzer
Vorbedingung: IdP konfiguriert (`AppSettingsGroupBL.GetJwtSettings`)
Fakt: `JwtAuthController` mit `[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]`, `LoginWithBearer` ermittelt Webservice-Token, entschlüsselte ApplicationGuid, authentifizierten Principal und delegiert an `AuthenticatorFactory.GetAuthenticator(...).GetTicket()`; `CentronHost` validiert Issuer, Audience, Lifetime, SigningKey, verlangt signierte Tokens, ExpirationTime sowie `ValidateActor` und `ValidateTokenReplay`.
Aussage: Das System soll Benutzer über einen externen OpenID-Connect-Anbieter (JWT Bearer) anmelden und daraus ein Centron-Ticket ausstellen; Tokens sind vollständig zu validieren.
Ergebnis: Single Sign-On möglich; ungültige/abgelaufene/signaturlose Tokens werden verworfen.
Belege:
- [PRIMÄR] CentronHost.cs: `TokenValidationParameters { ValidateIssuer=true; ValidateAudience=true; ValidateLifetime=true; ValidateIssuerSigningKey=true; RequireSignedTokens=true; RequireExpirationTime=true; ValidateActor=true; ValidateTokenReplay=true }` (durchsetzende Stelle)
- [PRIMÄR] src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs: `LoginWithBearer` mit `[Authorize(JwtBearer)]` - Begründung: durchgesetzter Login-Pfad
Prüfidee: Token mit falscher Audience/Signatur → 401; gültiges Token → Centron-Ticket in Response.
Tracelinks: StRS-002, SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Standard für SaaS
Status: belegt
---
ID: SyRS-005
Titel: Zwei-Faktor-Authentifizierung per E-Mail-Link [Sicherheit]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Endbenutzer
Vorbedingung: `TwoFactorAuthEnabled` in Webservice-Konfiguration aktiviert
Fakt: `TwoFactorAuthController/validate` (`[AllowAnonymous]`) nutzt `WebServiceConfigHelper.Current.TwoFactorAuthEnabled` und `TwoFactorAuthBL.GetTwoFactorValidator()`; nur `EmailTwoFactorValidator` wird aktiviert; `TrySetCodeAsValidated(code)` markiert Code als validiert.
Aussage: Das System soll eine optionale Zwei-Faktor-Authentifizierung über E-Mail-Validierungscodes anbieten; ungültige Codes werden ohne Informationsoffenlegung abgelehnt.
Ergebnis: Anmeldesicherheit erhöht bei aktivierter Konfiguration.
Belege:
- [PRIMÄR] src/webservice/Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs: Bedingungen `TwoFactorAuthEnabled == false` → Abbruch; `TrySetCodeAsValidated` (durchsetzende Stelle)
- [SEKUNDÄR] BL-Verzeichnis `TwoFactorAuthenticator` - Begründung: modulare Erweiterbarkeit
Prüfidee: Code unkorrekt → keine Aktivierung; Code korrekt → Login fließt durch.
Tracelinks: SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - sicherheitsrelevant
Status: belegt
---
ID: SyRS-006
Titel: Lizenzprüfung vor Datenbankzugriff [Sicherheit/Abrechnung]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit (Integrität)
Akteur: Hersteller, Betreiber
Vorbedingung: Lizenzdatei vorhanden
Fakt: `CentronHost.Start()`: `this.TryLoadLicense()` steht vor `this.SetupDatabaseConnection()`; Kommentar „Should the customer not have a valid license, we don't want to connect to the database and execute the scripts."; `LicenseManager.Initialize(LicenseManager.SettingsForWebService())`; `LoadLicenses().Wait()` wirft Exception bei ungültiger Lizenz.
Aussage: Das System soll beim Start zuerst die Herstellerlizenz prüfen; ohne gültige Lizenz darf keine Datenbankverbindung und kein Datenbank-Update erfolgen.
Ergebnis: Unlizenzierte Instanzen bleiben wirkungslos.
Belege:
- [PRIMÄR] CentronHost.cs: Reihenfolge `TryLoadLicense(); SetupDatabaseConnection();` (durchsetzende Stelle: Start-Sequenz)
Prüfidee: Start mit entfernter Lizenz → Exception vor DB-Verbindung.
Tracelinks: StRS-001
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Schutz des Geschäftsmodells
Status: belegt
---
ID: SyRS-007
Titel: Automatische Datenbankschema-Migration beim Start [Zuverlässigkeit]
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit/Wartbarkeit
Akteur: Betreiber
Vorbedingung: Lizenz geprüft
Fakt: `SetupDatabaseConnection()`: `SqlServerBL.CheckDatabaseVersion()`, `CheckDatabaseMatchesWebService()`, dann `ScriptEngineBL.ExecuteScripts()`; Exception bei Fehler; Skript-Repository `SQLScriptCollection*.xml` (z. B. `cvw_DunningRunItems` in `SQLScriptCollection4.xml`).
Aussage: Das System soll beim Start Schemaversion und Kompatibilität von Datenbank und Host prüfen und ausstehende SQL-Migrationsskripte selbständig ausführen.
Ergebnis: Datenbankstruktur entspricht immer der erwarteten Version; Schutz vor veralteten Schemata.
Belege:
- [PRIMÄR] CentronHost.cs: `sqlServerBL.CheckDatabaseVersion()`, `CheckDatabaseMatchesWebService()`, `session.GetBL<ScriptEngineBL>().ExecuteScripts()` (durchsetzende Stelle)
- [SEKUNDÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/SqlStatements - Begründung: versionierte Skriptbibliothek
Prüfidee: Start auf älterer Datenbank → Skripte laufen; Start auf zu neuer DB → Exception.
Tracelinks: SyRS-006
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Betriebsfähigkeit
Status: belegt
---
ID: SyRS-008
Titel: Zeitgesteuerte Hintergrunddienste [Betrieb]
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit (Betriebsführung)
Akteur: System
Vorbedingung: `ExecuteServices` in Konfiguration aktiviert
Fakt: `CentronHost`: bei `WebServiceConfigHelper.Current.ExecuteServices == true` werden u. a. `ArticleImportService`, `AutomaticPriceUpdateService`, `ContractEndeService`, `ContractCloseService`, `UpdateExpiredProvisionSchemasService`, `EscalationsService`, `RecurringScriptService`, `EdiDownloadService`, `MassUpdateService`, `ExchangeSyncService`, `DocumentsCleanupService`, `CTimeConnectorService`, `GfkExportService` registriert.
Aussage: Das System soll periodische Geschäftsprozesse (Vertragsende, Provisionssteuerung, Eskalationen, Preisaktualisierungen, Import-Export, Benachrichtigungen) als Hintergrunddienste auf dem Host ausführen, sofern aktiviert.
Ergebnis: Keine manuellen Batchläufe jenseits des Hosts erforderlich; Dienste sind konfigurierbar.
Belege:
- [PRIMÄR] CentronHost.cs: `if (WebServiceConfigHelper.Current?.ExecuteServices == true) { f.AddHostedService<...>() }` (durchsetzende Stelle)
Prüfidee: Deaktiviert `ExecuteServices` → keine HostedServices starten; aktiviert → Contracts werden automatisch beendet.
Tracelinks: StRS-005, StRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - SaaS-Betrieb
Status: belegt
---
ID: SyRS-009
Titel: Rechteprüfung für Helpdesk: eigene/Filiale/Abteilung [Berechtigung]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Techniker
Vorbedingung: Rechte vergeben
Fakt: `CentronRights.md` definiert ids und Semantik; `DunningRunWebServiceBL.ValidateDunningRun`-Analog in `AccountAddressBL.ValidateUserRightRead/ValidateUserRight(...)` (Aufruf in `GetAllForAccountAddress`, `Save`); `AccountBL.ValidateUserRights(...)` mit Unterscheidung `newCustomer/getAccount/deleteAccount/editAccount/unlockAccount/newSupplier`; `AccountAddressBL.Save` prüft zudem Sonderrechte `EDIT_CUSTOMER_ADDRESS_LANGUAGE` und `EDIT_CUSTOMER_ADDRESS_CURRENCY`.
Aussage: Das System soll für sensible Stammdaten- und Helpdesk-Zugriffe vor Ausführung eine serverseitige Rechteprüfung aktivieren; Verletzung ergibt `Result` mit `RightCheckFailed`.
Ergebnis: Unberechtigte Änderungen werden mit klarem Fehlercode blockiert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountAddressBL.cs Zeilen 69/156-178 (Aufrufe `ValidateUserRightRead`, `ValidateUserRight`, `CheckSpecialUserRightForAddressLanguageBeforeSave`) - durchsetzende Stelle
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs Zeilen 501/531/1299 (`ValidateUserRights(...)` mit `editAccount`, `deleteAccount`, u. a.) - durchsetzende Stelle
- [KONTEXT] CentronRights.md - Begründung: fachliche Rechtssemantik
Prüfidee: Speichern einer Anschrift ohne `EDIT_CUSTOMER` → `RightCheckFailed`.
Tracelinks: StRS-002, StRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Berechtigungskern
Status: belegt
---
ID: SyRS-010
Titel: Rechnungsstorno: Vorbedingungen und Recht [Abrechnung]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit (Integrität)
Akteur: Buchhaltung mit Recht
Vorbedingung: Rechnung existiert, nicht vorverarbeitet/exportiert
Fakt: `ReceiptInvoiceBL.CancelInvoice(int invoiceI3D, CreatedThroughApplication, AppUser)`: Prüfungen in Reihenfolge: (1) `currentUser.HasUserRight(UserRightsConst.RIGHT_RECHNUNGSTORNIEREN)` sonst Fehler; (2) State already Canceled; (3) `IsCashAsset` (Barrechnung) verboten; (4) `GetReceiptForwardedInto` nicht leer → verboten; (5) `_bookKeepingExportBL.IsReceiptExported(invoice)` → verboten; (6) Vertragsrechnung nur wenn letzte; dann `CreateNewVersion` mit `IgnoreCallbacks`, `QuantityComplete = 0` und Barcodes entfernt, `State = Canceled`, Logeintrag, Speicherung in dediziertem `DAOSession.WithTransaction` inkl. `ResetContract` und `RemoveTimers`.
Aussage: Das System soll eine Rechnung nur unter diesen Bedingungen stornieren und dabei eine neue Version mit Status „storniert" und gelöschten Abschlussmengen erzeugen; Barrechnungen sind nicht stornierbar; stornierte Vertragsrechnungen setzen Abrechnungsstand (Klickzähler/Sonderartikel) transaktional zurück.
Ergebnis: GoBD-konforme Versionierung und widerrufbare Abrechnung ohne Buchhaltungsexport-Bruch.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs `CancelInvoice` Zeilen 143-205 (durchsetzende Stelle: `HasUserRight`-Check, Status-/Export-Prüfungen, `CreateNewVersion`, `dedicatedSaveSession.WithTransaction`)
- [SEKUNDÄR] UserRightsConst.cs `RIGHT_RECHNUNGSTORNIEREN = 20400101` - Begründung: Recht-Nummer
Prüfidee: Exportierte Rechnung stornieren → Fehler „bereits exportiert"; letzte Vertragsrechnung wird storniert und `ResetDeviceClickCounter` aufgerufen.
Tracelinks: StRS-004, StRS-005, StRS-007, SwRS-010, SwRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - revisionssichere Abrechnung
Status: belegt
---
ID: SyRS-011
Titel: Beleg-Festschreibung (IsFixed) [Abrechnung]
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Rechnung abgeschlossen
Fakt: `ReceiptInvoiceBL.FixInvoice`: `UPDATE RechKopf SET IsFixed = 1 WHERE I3D = @I3D` via `RawSqlAccess.ExecuteNonQueryTransactionSave`; danach `ReceiptLogBL.CreateEntry(... ReceiptLogKind.FixedState ...)`; `CheckIfInvoiceIsFixed` blockiert Änderungen (Fehlertext „Die Rechnung ist festgeschrieben. Änderungen nicht möglich.").
Aussage: Das System soll Rechnungen durch eigenen Vorgang festschreiben; Änderungen an festgeschriebenen Rechnungen sind untersagt; Festschreibung wird im Beleglog protokolliert.
Ergebnis: Unveränderbarkeit abgerechneter Belege (GoBD).
Belege:
- [PRIMÄR] ReceiptInvoiceBL.cs: `FixInvoice`-SQL `UPDATE RechKopf SET IsFixed = 1` und `CheckIfInvoiceIsFixed`-Fehlermeldung (durchsetzende Stellen)
- [SEKUNDÄR] ReceiptLogBL.CreateEntry(... FixedState ...) - Begründung: Audit-Trail
Prüfidee: Nach FixInvoice schlägt Speichern mit „festgeschrieben" fehl; Logeintrag vorhanden.
Tracelinks: StRS-004, StRS-008, SyRS-012, SwRS-011
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - revisionssicher
Status: belegt
---
ID: SyRS-012
Titel: Belegversionierung jeder Änderung [Abrechnung]
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: alle
Vorbedingung: Beleg existiert
Fakt: Schema enthält parallele Versions-Tabellen für jede Belegart: `RechKopfVersions/RechPosVersions`, `AufKopfVersions/AufPosVersions`, `LiefKopfVersions/LiefPosVersions`, `AbholKopfVersions/AbholPosVersions`, `GutKopfVersions/GutPosVersions`, `AngKopfVersions/AngPosVersions`, `VertragKopfVersions/VertragPosVersions`, `AnfrKopfVersions/AnfrPosVersions`; Rechte `RIGHT_*DATUMEDITIERBARNEUEVERSION` (Datum nur bei neuer Version), `RIGHT_EKAKTUALISIERENOHNENEUEVERSION` (Ausnahme); `CancelInvoice` nutzt `CreateNewVersion(... IgnoreCallbacks = true)`.
Aussage: Das System soll Änderungen an Belegen als neue, historisierbare Version speichern; Ausnahmen (z. B. EK-Aktualisierung) sind nur mit Sonderrecht möglich.
Ergebnis: Lückenlose Belegrevision.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql: Versions-Tabellen je Belegart - Begründung: durchgesetzte Historisierung im Schema
- [PRIMÄR] ReceiptBL/ReceiptInvoiceBL: `CreateNewVersion<ReceiptInvoice>(...)` vor Storno-Speicherung - durchsetzende Stelle
- [SEKUNDÄR] UserRightsConst.cs IDs 20400100, 20400140-20400146, 20400088/20400089 - Begründung: Restriktionen beim Bearbeiten ohne neue Version
Prüfidee: Änderung erzeugt Version n+1; alte Version bleibt lesbar.
Tracelinks: SyRS-010, StRS-004
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - revisionssicheres Grundprinzip
Status: belegt
---
ID: SyRS-013
Titel: Beleg-Statusmodell (offen/abgeschlossen/storniert)
Ebene: SyRS
Typ: Daten
Qualitätsmerkmal:
Akteur: alle
Vorbedingung: -
Fakt: `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs`: `Active = 1`, `Completed = 2`, `Canceled = 3` mit Description-Strings „offen"/„abgeschlossen"/„storniert"; Tabelle `ReceiptUserState` zusätzlich benutzerspezifisch.
Aussage: Das System soll für Belege exakt drei Systemzustände kennen (offen, abgeschlossen, storniert) und diese auf Belegebene durchsetzen.
Ergebnis: Eindeutiges Statusmodell; rechtliche und technische Zustände trennbar.
Belege:
- [PRIMÄR] ReceiptState.cs (Enum-Definition) - durchsetzende Stelle
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql `[dbo].[ReceiptUserState]` - Begründung: ergänzende benutzerbezogene Sicht
Prüfidee: Ungültiger Zustandswechsel (Completed→Active) ohne definierten Pfad → kein Übergang im Code.
Tracelinks: StRS-004, SyRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Basiskonzept
Status: belegt
---
ID: SyRS-014
Titel: Mahnlauf: Validierung, Stufen, Versand, Reset [Abrechnung]
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Rechnungen fällig, Mahnberichte konfiguriert
Fakt: `DunningRunWebServiceBL.ValidateDunningRun` wirft `ArgumentException` für: SendType None oder Fax; keine Rechnungen/Gutschriften; Rechnungen fremder Kunden; Rechnungen vor Fälligkeit; Rechnungen bereits in Stufe 3; Kundenkontakt fehlt. `DunningRunBL.ExecuteDunningRunInternal`: Aufbau `DunningRunNumber` über `GenerateNextDunningRunNumber`, `DunningRunState.Active`; `ResetDunningRun` setzt Items auf `DunningRunState.Deleted`; Report inkl. Mahnadresse via `UseDivergentInvoiceAddressAsDunningAddress`; Versand E-Mail oder Druck.
Aussage: Das System soll Mahnläufe nur für fällige Belege eines Kunden auf maximal drei Stufen ausführen, mit Vorschau, generiertem Mahnbericht, optionalem Mailversand und stornierbarem Mahnlauf.
Ergebnis: Rechtssichere Mahnfolge; einheitliche Mahnnummern.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/DunningRunWebServiceBL.cs `ValidateDunningRun` (durchsetzende Stelle: ArgumentException-Validierungen)
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs `ExecuteDunningRunInternal`/`ResetDunningRun` (durchsetzende Stelle: Nummernvergabe und Statusänderungen)
- [SEKUNDÄR] SSMS_DB_SCHEMA.sql `[dbo].[Mahnlauf]` - Begründung: Persistenz
Prüfidee: Mahnlauf mit unfälliger Rechnung schlägt fehl; nach Reset ist Mahnnummer frei und Items gelöscht.
Tracelinks: StRS-008, SyRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Mahnwesen erforderlich
Status: belegt
---
ID: SyRS-015
Titel: Buchhaltungsexport-Sperre für stornierende Belege [Abrechnung]
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Buchhaltung extern (z. B. DATEV-Import)
Vorbedingung: Beleg bereits gebucht
Fakt: `BookKeepingExportBL.IsReceiptExported(invoice)` (in `ReceiptInvoiceBL.CancelInvoice`) verhindert Storno; `BookKeepingExportBL` speichert Exportkennzeichen mit `CentronVersion`; Recht `BOOKKEEPING_EXPORT` (10770, obsolete), `BOOKKEEPING_IMPORT` (20400203), Rechte „Exportiert"-Kennzeichen zurücksetzen (20400307, 20400309), `RIGHT_ERLOESKONTOINRECHNUNGAENDERN` (20400083).
Aussage: Das System soll den Export gebuchter Belege nachzeichnen und den Storno exportierter Rechnungen verweigern; das „wurde exportiert"-Kennzeichen darf nur mit Sonderrecht zurückgesetzt werden. Erlöskonto-Änderungen in Rechnungen sind rechtgesteuert.
Ergebnis: Abgeschlossene Buchungen bleiben zwischen ERP und Buchhaltung konsistent.
Belege:
- [PRIMÄR] ReceiptInvoiceBL.CancelInvoice: `if (this._bookKeepingExportBL.IsReceiptExported(invoice)) return Result<ReceiptInvoice>.AsError(...)` - durchsetzende Stelle
- [SEKUNDÄR] UserRightsConst.cs IDs 10770/20400203/20400307/20400309/20400083 - Begründung: Rechte für Kennzeichen und Erlöskonto
Prüfidee: Exportierte Rechnung stornieren → Fehler; Rücksetzen des Flags ohne Recht nicht möglich.
Tracelinks: StRS-008, SyRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - buchhalterische Integrität
Status: belegt
---
ID: SyRS-016
Titel: Provisionsabrechnung auf Belegbasis
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertriebsleitung, System
Vorbedingung: Provisionsschemata gepflegt
Fakt: `ReceiptProvisionSchemaBL` (29.712 Bytes), `ReceiptProvisionEmployeeGoalBL`, `ReceiptProvisionEmployeeLevelBL`; Schema-Tabellen `AngProv`, `AbholProv`; HostedService `UpdateExpiredProvisionSchemasService`; Rechtegruppe `Sales.Provision` (20800092-20800146) incl. `CAN_SEE_ALL_PROVISION_IN_RECEIPTS`, `PROVISION_SCHEMA_MANAGEMENT`, `PROVISION_SCHEMA_CUSTOMER_ASSIGNMENT`.
Aussage: Das System soll Provisionen auf Basis von Belegen mit Zeit- und Zielscheman steuern, abgelaufene Schemata automatisch deaktivieren und Sichtbarkeit auf Fremdprovisionen rechtegesteuert begrenzen.
Ergebnis: Automatisierte, revisionssichere Provisionswirtschaft.
Belege:
- [PRIMÄR] CentronHost.cs `UpdateExpiredProvisionSchemasService` - durchsetzende Stelle für zeitliche Pflege
- [SEKUNDÄR] ReceiptProvisionSchemaBL.cs, SSMS `[dbo].[AngProv]`, `[dbo].[AbholProv]` - Begründung: Schema-Entitäten
- [SEKUNDÄR] UserRightsConst.cs Provision - Begründung: Rechte
Prüfidee: Abgelaufenes Schema wird nicht mehr für neue Belege herangezogen.
Tracelinks: StRS-004
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Vertriebssteuerung
Status: belegt
---
ID: SyRS-017
Titel: Abrechnete Ticketzeiten dürfen nicht verschoben/gelöscht werden [Abrechnung]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit (Integrität)
Akteur: Techniker
Vorbedingung: Zeitdatensatz ist Teil eines Belegs
Fakt: `CentronRights.md` Kap. 8/9: Verschieben und Löschen von Helpdesk-Zeiten gestattet nur, „if the ticket is not part of a receipt"; `ReceiptItemTimerBL.RemoveTimers` wird beim Storno transaktional aufgerufen; Tabelle `hlpdsk_timer`.
Aussage: Das System soll die Bearbeitung von Helpdesk-Zeiten sperren, sobald diese in einen Beleg aufgenommen wurden, und die Verknüpfung erst beim Belegstorno lösen.
Ergebnis: Keine Doppel- oder Phantomabrechnung von Zeiten.
Belege:
- [PRIMÄR] ReceiptInvoiceBL.CancelInvoice: `RemoveTimers(invoice, currentUser)` innerhalb `WithTransaction` (durchsetzende Stelle für Lösen der Verknüpfung)
- [KONTEXT] CentronRights.md Nr. 8/9 - Begründung: fachliche Regel für Verschieben/Löschen nur vor Abrechnung
- [SEKUNDÄR] SSMS `[dbo].[hlpdsk_timer]` - Begründung: Datenbasis
Prüfidee: Abgerechnete Zeit verschieben → Verweis auf Belegzugehörigkeit; nach Storno wieder frei.
Tracelinks: StRS-007, SyRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Abrechnungsintegrität
Status: belegt
---
ID: SyRS-018
Titel: Kundenanlage/-änderung über Rechte mit Entsperrung [Berechtigung]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Vertriebsinnendienst, Administrator
Vorbedingung: -
Fakt: `AccountBL.ValidateUserRights(int appUserI3D, bool newCustomer=false, bool getAccount=false, ...)` wird in `GetAccount`, `Save`, `DeleteAccount`, `UnlockAccount` aufgerufen (Zeilen 264/501/754/928); `ignoreRights`-Flag ermöglicht bewusste Ausnahme.
Aussage: Das System soll Geschäftspartner-Operationen (Anzeigen, Anlegen, Ändern, Löschen, Entsperren) einer Rechteprüfung unterziehen; Ausnahmen erfolgen nur durch explizites `ignoreRights`.
Ergebnis: Granulare Rechtebindung von Stammdaten.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs Zeilen 264, 501, 754, 928, 1299 (durchsetzende Stellen)
- [SEKUNDÄR] UserRightsConst.cs `CREATE_CUSTOMER` 20400092, `EDIT_CUSTOMER` 20400093, `DELETE_CUSTOMER` 20400016, `LOCK_CUSTOMER` 2040002, `UNLOCK_CUSTOMER` 2040003 - Begründung: Rechte-Katalog
Prüfidee: Benutzer ohne `DELETE_CUSTOMER` kann Kunden nicht löschen; `ignoreRights=true` nur in Server-internen Vorgängen.
Tracelinks: StRS-002, StRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - Berechtigungsmodell
Status: belegt
---
ID: SyRS-019
Titel: Seriennummern-Verpflichtung und -Historie
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lager, Vertrieb
Vorbedingung: Artikel mit `SN bei Warenabgang`
Fakt: Recht `CHANGE_SERIALNUMBER_REQUIRED_FLAG` (20400318) erlaubt Änderung des SN-Pflichtflags; Rechte `SERIAL_NUMBER`-Serie (`ADD_SERIAL_NUMBER`, `GENERATE_SERIAL_NUMBER`, `REPLACE_SERIAL_NUMBER`, `REMOVE_SERIAL_NUMBER`, `RESET_SERIAL_NUMBER`), Klasse `BarcodeBL`/`BarcodeHistoryBL`, Tabelle `SeriennummerToPosition`; `CancelInvoice` leert `receiptItem.Barcodes` in neuen Versionen.
Aussage: Das System soll Seriennummern als eigenes Rechte- und Historienobjekt pflegen, mit Artikel je nach Pflichtflag, und beim Storno die SN-Verknüpfung der stornierten Position zurücksetzen.
Ergebnis: Lückenlose Verfolgbarkeit einzelner Geräte.
Belege:
- [PRIMÄR] UserRightsConst.cs `Purchase.StockList.SerialAdministration` (IDs 20400028, 20400032-20400035, 20400051, 20400055) - Begründung: durchgesetzte Rechte-Matrix
- [PRIMÄR] ReceiptInvoiceBL.CancelInvoice `receiptItem.Barcodes.Clear()` - durchsetzende Stelle
- [SEKUNDÄR] src/backend/Centron.BL/Warehousing/{BarcodeBL,BarcodeHistoryBL}.cs - Begründung: SN-Service und Historie
Prüfidee: SN-Ersatz erzeugt Historie; Storno entfernt Barcodes nur in neuer Version.
Tracelinks: StRS-009, SyRS-010
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-020
Titel: Bestell- und Wareneingangskette inkl. WE-Kalkulation
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkauf
Vorbedingung: Lieferant vorhanden
Fakt: Tabellen `BestKopf2/BestPos2`, `WareKopf/WarePos`, `KalkKopf/KalkPos`, `LiGutKopf/LiGutPos` (Lieferantengutschriften); Rechte `RIGHT_BESTELLUNGANLEGEN`, `RIGHT_WARENEINGANGERSTELLEN`, `RIGHT_WARENEINGANGABSCHLIESSEN`, `RIGHT_WEKALKULATIONABSCHLIESSEN`, `RIGHT_LIEFERANTENGUTSCHRIFTABSCHLIESSEN`, `SHOW_ORDER/INVOICE_ONLY_OWN_BRANCH`.
Aussage: Das System soll eine Einkaufsbelegkette (Bestellung → Wareneingang → WE-Kalkulation → Lieferantenrechnung/-gutschrift) mit Abschlussrechten und filialbezogener Sichtbarkeit führen.
Ergebnis: Beschaffungsprozess nachvollziehbar und sicher.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql `CREATE TABLE [dbo].[BestKopf2]`, `[dbo].[WareKopf]`, `[dbo].[KalkKopf]`, `[dbo].[LiGutKopf]` - durchgesetztes Schema
- [PRIMÄR] UserRightsConst.cs (Bestell-/WE-/Kalk-Rights) - Begründung: durchgesetzte Rechte
Prüfidee: Wareneingang ohne Recht nicht abschließbar; Abschluss setzt State.
Tracelinks: StRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-021
Titel: Inventuren mit Zählgruppen und Sperrlogik
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Lager
Vorbedingung: Inventur angelegt
Fakt: Rechte `Purchase.Inventory`: `CREATE_INVENTORY` (20400040), `CLOSE_INVENTORY` (20400042), `CREATE_INVENTORY_GROUP` (20400043), `REMOVE_ARTICLE_FROM_INVENTORY_GROUP` (20400044), `DELETE_INVENTORY_GROUP` (20400045), `UNLOCK_INVENTORY_GROUP` (20400048); `RIGHT_INVENTURGRUPPENENTSPERREN` (20400253); BL `InventoryManagement`.
Aussage: Das System soll Inventuren in Zählgruppen organisieren; Abschluss, Verwerfen, Entsperren und Artikel-Entfernung einzeln berechtigen.
Ergebnis: Kontrollierte Bestandsprüfung.
Belege:
- [PRIMÄR] UserRightsConst.cs `Purchase.Inventory`-Block - durchgesetzte Rechte-Matrix
- [SEKUNDÄR] src/backend/Centron.BL/Warehousing/InventoryManagement - Begründung: Modul
Prüfidee: Abschließen einer Inventur ohne `CLOSE_INVENTORY`-Recht wird verwehrt.
Tracelinks: StRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-022
Titel: Vertragsende und -abschluss automatisiert
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: System
Vorbedingung: Vertrag aktiv, Ende konfiguriert
Fakt: HostedServices `ContractEndeService`, `ContractCloseService`, `UpdateSpecialArticleToContractService` in `CentronHost`; Tabellen `VertragKopf/VertragPos` mit Versions-Pendanten; Recht `Sales.LEASINGANDSERVICE` (10390).
Aussage: Das System soll Amtsende von Verträgen zeitgesteuert erkennen, laufende Verträge schließen und öffnen sowie Sonderartikel automatisch dem Vertrag nachführen.
Ergebnis: Vertragsstammdaten ohne manuelle Nachpflege korrekt.
Belege:
- [PRIMÄR] CentronHost.cs: Registrierung der drei HostedServices (durchsetzende Stelle)
- [SEKUNDÄR] SSMS `[dbo].[VertragKopfVersions]`, `[dbo].[VertragPosVersions]` - Begründung: historisierte Vertragsänderungen
Prüfidee: Laufzeit abgelaufen → Vertragsschluss automatisch (Datenbank prüfbar).
Tracelinks: StRS-005
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-023
Titel: Fertigungsaufträge und Arbeitsplan-Zeitdaten
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Fertigung
Vorbedingung: Produktionsstammdaten gepflegt
Fakt: Tabellen `ArticleProductionOrders`, `ArticleProductionOrderStepItems`, `ArticleProductionOrderStepItemTimes`, `ArticleProductionMaterials`, `APlan*`; BL `ProductionBL`, `ProductionOrderBL`; Nexus-Modul `ProductionOrderManagement`.
Aussage: Das System soll Fertigungsaufträge aus Vertriebsaufträgen erzeugen, Arbeitsplan-Schritte mit Material und Zeitbuchung erfassen und den Auftragsstatus auf „produziert" setzen lassen.
Ergebnis: Fertigprozess mit Rückverfolgbarkeit.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql `ArticleProductionOrderStepItemTimes` - durchgesetztes Datenmodell der Zeitbuchung
- [SEKUNDÄR] UserRightsConst (`RIGHT_PPSARBEITSPLANANLEGEN`, `RIGHT_AUFTRAGPRODUZIERT`) - Begründung: Rechte
Prüfidee: Zeitbuchung auf Arbeitsschritt; Auftrag wechselt Recht epflichtig in produziert.
Tracelinks: StRS-014
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-024
Titel: Anlagenwartung mit Sperrlogik und Seriennummerhistorie
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Vertrieb
Vorbedingung: Stammblatt vorhanden
Fakt: `AssetLockBL`, `MasterDataListBL`: Verweis „Stammblatt ist einem aktiven Vertrag zugeordnet." verhindert Löschung; Methoden zum Entfernen/Ersetzen der Hauptgeräte-SN; Kommentar „Writes the Stammblatt history entry (Historie tab)".
Aussage: Das System soll Kundenanlagen sperren, während sie abhängige Verträge haben, und Hauptgeräte-Seriennummeränderungen rechtegesteuert mit Historieneintrag dokumentieren.
Ergebnis: Integrität des Gerätebestands mit Audit.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs (`DependencyCheckFailed`, SN-Historie) - durchsetzende Stelle
- [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/AssetLockBL.cs - Begründung: Sperrlogik
Prüfidee: Anlage mit aktivem Vertrag löschen → abgelehnt; SN-Änderungen sichtbar in Historie.
Tracelinks: StRS-010
Konsolidierung: Kandidat: SwRS-006 (Stammblatt vs. AssetManagement-Datenhaltung)
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-025
Titel: Elektronische Rechnung (ebInterface)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Behördenkunden (Österreich)
Vorbedingung: Konfiguration
Fakt: Eigenes API-Projekt `src/apis/Centron.Api.EbInterface/Centron.Api.EbInterface.csproj`; OpenTrans-Deserialisierung in `ReceiptInvoiceBL.TryDeserializeOpenTransInvoice` mit `INVOICE`-Typ aus `Centron.Gateway.OpenTrans`.
Aussage: Das System soll Rechnungen im ebInterface/OpenTrans-XML-Format importieren (und förderieren), sofern konfiguriert.
Ergebnis: gesetzeskonformer E-Rechnungsverkehr.
[Hinweis: der konkrete Ablauf der Ausgabe ist nicht vollständig gelesen]
Belege:
- [SEKUNDÄR] src/apis/Centron.Api.EbInterface - Begründung: separates Integrationsprojekt
- [PRIMÄR] ReceiptInvoiceBL.TryDeserializeOpenTransInvoice - durchsetzende Stelle für Import
Prüfidee: Gültige ebInterface-XML deserialisiert ohne Fehler; ungültige XML liefert `Result.FromException`.
Tracelinks: StRS-004, SwRS-015
Konsolidierung: nein
Übernahmewürdigkeit: Sonderfall - Österreich-spezifisches Format
Status: belegt
---
ID: SyRS-026
Titel: Online-Banking via FinAPI mit Konto-Transaktionsabgleich [Abrechnung]
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Buchhaltung
Vorbedingung: Kontoverknüpfung eingerichtet, Rechte vergeben
Fakt: BL-Klassen `OnlineBankingFinApiBL`, `OnlineBankingAccountTransactionsBL`, `OnlineBankingConfigurationBL`; API-Projekt `Centron.APIs.FinAPI`; Rechtegruppe `Controlling.Finances.OnlineBanking` (`VIEW_BANKSTATEMENT` 20800147, `VIEW_ONLY_OWN_BRANCH_BANKSTATEMENT`, `DELETE_BANKSTATEMENT`, `CHANGE_BANKSTATEMENT_ASSIGNMENT`, `IMPORT_BANKSTATEMENT_MANUELLY`); Tabellen `Zahlungseingang`, `ZahlungseingangLog`.
Aussage: Das System soll Kontoauszüge via FinAPI abrufen, manuell importieren lassen und mit Zahlungseingängen abgleichen; Sichtbarkeit und Zuordnung werden rechtegesteuert, auf Filiale begrenzt wählbar.
Ergebnis: Automatisierte Zahlungseingangserfassung mit Audit.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/{OnlineBankingFinApiBL,OnlineBankingAccountTransactionsBL}.cs - durchgesetzte Klassen-Struktur
- [PRIMÄR] UserRightsConst.cs `OnlineBanking`-Block IDs 20800147-20800151 - Begründung: durchgesetzte Rechte
- [SEKUNDÄR] SSMS `[dbo].[Zahlungseingang]`, `[dbo].[ZahlungseingangLog]` - Begründung: Persistenz mit Log
Prüfidee: Bankstatement ohne Recht nicht sichtbar; importiertes Statement liefert `ZahlungseingangLog`-Eintrag.
Tracelinks: StRS-008
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-027
Titel: Artikeldatenintegrationen (ITscope, Icecat, COP, EGIS, Distributoren)
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Einkauf, Vertrieb
Vorbedingung: Zugang konfiguriert
Fakt: API-Projekte `Centron.APIs.ITscopeDataAccess`, `Centron.APIs.IcecatDataAccess`, `Centron.APIs.CopDataAccess`, `Centron.APIs.EgisDataAccess`; Tabellen `ArticleImports`, `ArticleImportMappings`, `ArticleImportLogs`, `ArticleImportDistributors`, `ArticleImportField`; HostedService `ArticleImportService` und `AutomaticPriceUpdateService`.
Aussage: Das System soll Artikelstammdaten und Preise ausmarktüblichen Katalogquellen/Distributoren importieren, über Mappings integrieren und zeitgesteuert aktualisieren.
Ergebnis: Katalogpflege eingespart; aktuelle Einkaufspreise.
Belege:
- [PRIMÄR] CentronHost.cs: `ArticleImportService`, `AutomaticPriceUpdateService` (durchsetzende Stelle)
- [SEKUNDÄR] Verzeichnis src/apis/*DataAccess und SSMS `[dbo].[ArticleImports]` - Begründung: Integrationsprojekte und Import-Tabellen
Prüfidee: Import liefert Logeintrag; Mappings abbildbar.
Tracelinks: StRS-009
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - wettbewerbskritisch
Status: belegt
---
ID: SyRS-028
Titel: Versanddienstleisterintegration (GLS, Shipcloud) mit Paketvorlagen
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Lager
Vorbedingung: -
Fakt: API-Projekte `Centron.Api.Gls`, `Centron.Api.Shipcloud`; `ShipcloudPackageTemplateBL` (BL Sales/Receipts); Recht `RIGHT_CLICKABRIGHTNUNG` (Clickabrechnung) indirekt für Versandlabels nicht vorhanden (kein eigenes Label-Recht).
Aussage: Das System soll Paketscheine über GLS und Shipcloud aus Belegen heraus erstellen können; Paketvorlagen standardisieren den Versand.
Ergebnis: Logistikprozess ohne Medienbruch.
Belege:
- [SEKUNDÄR] src/apis/Centron.Api.Gls, Centron.Api.Shipcloud - Begründung: dedizierte Integrationsprojekte
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs - durchgesetzte Vorlagenlogik
Prüfidee: Paketvorlage erzeugt Label-Anfrage (Mock-Test).
Tracelinks: StRS-001
Konsolidierung: Kandidat: zwei getrennte Carrier-Integrationen mit derselben fachlichen Funktion („Paketlabel") - im Ziel in Abstraktionschicht
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-029
Titel: Password-Manager für Kunden mit Richtlinien und Export [Sicherheit]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: MSP-Techniker
Vorbedingung: Lizenz
Fakt: Rechtegruppe `UserRightsConst.PasswordManager` (ID 20800011): `ACCESS_GUIDELINE_MANAGEMENT`, `ACCESS_AREA_MANAGEMENT`, `EXPORT_ACCESS_AND_PASSWORD_DATA`; `PasswordManagerBL.ValidateUserRights(userI3D)` (Zeilen 228/246/266/761); BL-Verzeichnisse `PasswordManager`, `PasswordManagementArea`.
Aussage: Das System soll einen zentralen Passworttresor für Kunden mit Richtlinien- und Bereichsverwaltung bereitstellen; Export sensibler Zugangsdaten ist hinter einem eigenen Recht geschützt.
Ergebnis: Zugangsdaten zentral, abgesichert und auditiert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs: `ValidateUserRights` (durchsetzende Stelle)
- [PRIMÄR] UserRightsConst.cs PasswordManager-IDs - Begründung: eigenes Recht für Datenexport
Prüfidee: Export ohne `EXPORT_ACCESS_AND_PASSWORD_DATA` wird blockiert.
Tracelinks: StRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-030
Titel: DSGVO-Ansprechpartnerlöschung und Datenbankbereinigung [Sicherheit]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Datenschutzbeauftragter
Vorbedingung: DSGVO-Modul lizenziert
Fakt: `UserRightsConst.DsgvoModule`: `ACCESS_DSGVO_MODULE` (20800022), `DSGVO_DELETE_CONTACT` (20800023), `ACCESS_CLEANUP_DATABASE` (20800024); HostedService `DocumentsCleanupService` und `DataQualityService` (nicht-terminals DSGVO-spezifisch aber bereinigend).
Aussage: Das System soll das Löschen von Ansprechpartnern und die Bereinigung der Datenbank hinter eigenen Rechten ausführen; dokumentierte Bereinigungsdienste sollen Alt- und verwaiste Daten entfernen.
Ergebnis: Datensparsamkeit und Löschkonformität betriebsfest.
Belege:
- [PRIMÄR] UserRightsConst.cs `DsgvoModule`-Block - durchgesetzte Rechte
- [SEKUNDÄR] CentronHost.cs: `DocumentsCleanupService` - Begründung: systemseitige Bereinigung
Prüfidee: Abruf ohne DSGVO-Recht → unzugänglich; Löschung protokolliert.
Tracelinks: StRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gesetzlich
Status: belegt
---
ID: SyRS-031
Titel: WebCart-Shop mit Sonderpreisen für Endkunden
Ebene: SyRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Endkunde (Web-Account)
Vorbedingung: Web-Account aktiv; Sonderpreise gepflegt
Fakt: README: „The available articles come from the customers 'Sonderpreise'"; Blazor-Seiten `WebCartShopPage.razor`, `WebCartCartPage.razor` (52.175 Bytes mit Preisanzeige und Warenkorb), `WebCartAdminPage.razor`; `AddressContactPersonWebAccountRequests`-Tabelle.
Aussage: Das System soll einen Endkunden-Shop bereitstellen, der ausschließlich Artikel anzeigt, für die der zugehörige Kunde Sonderpreise definiert hat, und Warenkorb/Bestellung annimmt.
Ergebnis: Bindung des Sortiments an die kundenindividuelle Konditionenpflege.
Belege:
- [KONTEXT] README.md (WebCart-Absatz) - Begründung: fachliche Regel
- [SEKUNDÄR] src/nexus/CentronNexus/WebCart/{WebCartShopPage,WebCartCartPage,WebCartAdminPage}.razor - Begründung: Umsetzung
- [PRIMÄR] SSMS `[dbo].[AddressContactPersonWebAccountRequests]` - Begründung: Web-Account-Entität
Prüfidee: Artikel ohne Sonderpreis des Kunden erscheint nicht im Shop des Accounts.
Tracelinks: StRS-011, SyRS-003
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-032
Titel: KI-Assistenz mit Rechtebindung [Sicherheit]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: Mitarbeiter
Vorbedingung: KI-Modul lizenziert
Fakt: Rechtegruppe `ArtificialIntelligence` (ID 20800167) mit `ADD_FILES`, `WEB_SEARCH`, `INTERACTIVE_MODE`, `MODEL_SELECTION`, `UNRESTRICTED_ACCESS`; Tabellen `ArtificialIntelligencePromptCategory`, `ArtificialIntelligencePromptSettings`.
Aussage: Das System soll KI-Fähigkeiten (Datei-Upload, Websuche, interaktiver Modus, Modellwahl, uneingeschränkter Zugriff) einzeln rechtebinden; uneingeschränkter Zugriff ist ein besonderes Hochrisiko-Recht.
Ergebnis: Gestufte KI-Nutzung nach Notwendigkeit.
Belege:
- [PRIMÄR] UserRightsConst.cs `ArtificialIntelligence`-Block - durchgesetzte Rechte-Matrix
- [SEKUNDÄR] SSMS `[dbo].[ArtificialIntelligencePromptSettings]` - Begründung: Prompt-Konfiguration
Prüfidee: Benutzer ohne `WEB_SEARCH` kann Websuche nicht anstoßen.
Tracelinks: StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - sicherheitskritische Dimension
Status: belegt
---
ID: SyRS-033
Titel: Dokumentenmanagement mit Verzeichnis-/Datei-Rechten [Berechtigung]
Ebene: SyRS
Typ: Sicherheit
Qualitätsmerkmal: Sicherheit
Akteur: alle
Vorbedingung: Dateiablage konfiguriert
Fakt: `UserRightsConst.Sales.Documents` und `Sales.Cashbox/Dokumente`: `DELETE_DOCUMENTS` (20400074), `CHANGE_DOCUMENTS` (20400075), `READ_DOCUMENTS` (20400076), `ADD_DOCUMENTS` (20400077), `ADD_DIRECTORY` (20400078), `DELETE_DIRECTORY` (20400079), `MOVE_DIRECTORY` (20400080), `RENAME_DIRECTORY` (20400081); BL `Administration/FileManagement/DirectoryBL.cs` prüft Account-Bearbeitungsrechte beim Schreibschutz von Verzeichnissen (`hasNoRight = ... ValidateUserRights(..., getAccount:true)`).
Aussage: Das System soll Dateien und Verzeichnisse im ERP kontextbezogen (Kunde/Lieferant) verwalten und Lese-/Schreib-/Verzeichnisrechte getrennt vergeben; Metadaten-Änderungsbeschränkungen binden an Geschäftsrechte (z. B. nur bei `EDIT_SUPPLIER`).
Ergebnis: Granulare Schutz der Ablage.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/FileManagement/DirectoryBL.cs Zeilen 391/403 (Aufruf von `AccountBL.ValidateUserRights(...)` als Rechtegatter) - durchsetzende Stelle
- [PRIMÄR] UserRightsConst.cs Documents-IDs - Begründung: Rechte-Matrix
Prüfidee: Verzeichnis im Lieferantenkontext öffnen ohne `getAccount:true`-Recht → blockiert.
Tracelinks: StRS-011, StRS-012
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-034
Titel: SMS-/SignalR-Nexus-Benachrichtigungen
Ebene: SyRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: alle Benutzer
Vorbedingung: Nexus-Verbindung
Fakt: `CentronHost`-Konstruktor: `NotificationsHubHelper.SendNexusNotification = notification => NotificationsHub.SendNotification(notification);`; eigene `SecretKey`-Policy mit `SecretKeyRequirement(nexusConnectionKey)` und `SecretKeyHandler`; Blazor-Host `CentronNexus.Host`.
Aussage: Das System soll interne Ereignisse (Tickets, MyDay) über SignalR an angeschlossene Nexus-Clients streuen; Nexus-Verbindungen sind über konfigurierten SecretKey abgesichert.
Ergebnis: Echtzeit-Updates ohne Polling; Vertraulichkeit bei internem Kanal.
Belege:
- [PRIMÄR] CentronHost.cs: `AddPolicy("SecretKey", policy => policy.Requirements.Add(new SecretKeyRequirement(nexusConnectionKey)))` (durchsetzende Stelle)
- [PRIMÄR] CentronHost.cs: `NotificationsHubHelper.SendNexusNotification`-Zuweisung - durchsetzende Stelle
Prüfidee: Nexus ohne SecretKey → 403; Ticketereignis erzeugt SignalR-Nachricht (Integrationstest).
Tracelinks: StRS-013
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-035
Titel: End-to-End-Testsatz und Integrations-Tests
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Zuverlässigkeit (Prüfbarkeit)
Akteur: Entwicklung/QA
Vorbedingung: -
Fakt: Verzeichnisse `tests/backend`, `tests/apis`, `tests/shared`, `tests/Centron.Tests.EndToEnd`, `tests/Centron.Tests.Integration`, `tests/PlaywrightTests`, `tests/CentronNexusTests`; `DunningRunWebServiceBL` enthält `EndToEndTestMode`-Property.
Aussage: Das System soll schichtübergreifende automatisierte Tests (Unit via backend/shared, API-Tests, Integrationstests, End-to-End- und UI-Tests mit Playwright) bereithalten; bestimmte BLs sollen im E2E-Modus ohne Nebenwirkungen ausführbar sein.
Ergebnis: Automatisierte Qualitätsabsicherung über Releasegrenzen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/DunningRunWebServiceBL.cs: `EndToEndTestMode { get; set; }` - durchgesetzte Stelle
- [SEKUNDÄR] Verzeichnisliste tests/* - Begründung: Testinfrastruktur
Prüfidee: CI-Lauf der Integrationstestsuite mit isolierter Test-DB.
Tracelinks: StRS-015
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
ID: SyRS-036
Titel: REST-Hilfeseiten und begrenztes Swagger
Ebene: SyRS
Typ: nicht-funktional
Qualitätsmerkmal: Wartbarkeit/Sicherheit
Akteur: Integrationen
Vorbedingung: `ActivateHelpPage` aktiv
Fakt: `CentronHost`: Swagger wird nur registriert, wenn `WebServiceConfigHelper.Current?.ActivateHelpPage == true`; Hilfsseiten über `MapCentronWelcomePage` und `MapCentronHelpPage` geroutet.
Aussage: Das System soll API-Dokumentation (Swagger/HelpPage) konfigurierbar bereitstellen; bei deaktiviertem Hilfsseiten-Flag bleibt die Metadatenoberfläche abgeschaltet.
Ergebnis: Angreifsfläche geringer bei geschlossener Doku.
Belege:
- [PRIMÄR] CentronHost.cs: `if (...ActivateHelpPage == true) { f.AddEndpointsApiExplorer(); f.AddCentronSwaggerGen(); }` sowie entsprechend `UseSwagger()`/`UseCentronSwaggerUI()` (durchsetzende Stelle)
Prüfidee: `ActivateHelpPage=false` → /swagger nicht erreichbar.
Tracelinks: SyRS-002
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen
Status: belegt
---
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Ergebnisse/Traceability.md
+35
View File
@@ -0,0 +1,35 @@
# Traceability-Tabelle (Forward und Backward)
# StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (datei-kurz)
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|---|
| StRS-001 | SyRS-001, SyRS-007, SyRS-035 | SwRS-001, SwRS-014 | CentronHost.cs; Centron.sln; DAO/*.cs |
| StRS-002 | SyRS-003, SyRS-004, SyRS-005, SyRS-009, SyRS-018 | SwRS-007, SwRS-022 | UserRightsConst.cs; TicketBL.cs; JwtAuthController.cs; CentronRights.md |
| StRS-003 | SyRS-009 | SwRS-005 | UserRightsConst.cs (SHOW_*_ONLY_OWN_BRANCH); CentronRights.md |
| StRS-004 | SyRS-010, SyRS-011, SyRS-012, SyRS-013, SyRS-015, SyRS-025 | SwRS-003, SwRS-009, SwRS-010, SwRS-011, SwRS-012 | ReceiptBL.cs; ReceiptInvoiceBL.CancelInvoice/FixInvoice; ReceiptState.cs; SSMS (AngKopf..GutPos, *Versions) |
| StRS-005 | SyRS-016, SyRS-022 | SwRS-010 | ReceiptInvoiceBL.CancelInvoice (IsContractInvoice/ResetContract); CentronHost.cs (ContractEndeService/ContractCloseService); SSMS Vertrag* |
| StRS-006 | SyRS-018(Hinweis), SyRS-021(DAM), SyRS-026(Zeit), SyRS-030(DSGVO indirekt) | SwRS-017, SwRS-018, SwRS-021, SwRS-030, SwRS-031 | hlpdsk_*-Tabellen; CentronRights.md; EscalationsService; ValidateHelpdeskFingerprintService; TicketPatterns |
| StRS-007 | SyRS-010, SyRS-017 | SwRS-011 | ReceiptItemTimerBL.RemoveTimers; CentronRights.md Nr. 8/9 |
| StRS-008 | SyRS-014, SyRS-015, SyRS-026, SyRS-040 | SwRS-020 | DunningRunBL/DunningRunWebServiceBL; Mahnlauf; Zahlungseingang; Kostenstellen |
| StRS-009 | SyRS-019, SyRS-020, SyRS-021, SyRS-028 | SwRS-013 | UserRightsConst (StockList/Inventory/SerialAdministration); SSMS ARTIK, Barcode, BestKopf2, WareKopf, KalkKopf |
| StRS-010 | SyRS-024 | SwRS-006, SwRS-016 | AssetBL, MasterDataListBL; GeraeteKopf; AssetManagementDevices |
| StRS-011 | SyRS-031, SyRS-033 | SwRS-016, SwRS-039 | README.md WebCart; WebCartShopPage.razor; AddressContactPersonWebAccountRequests; DirectoryBL |
| StRS-012 | SyRS-030, SyRS-029 | SwRS-040 (verwandt) | UserRightsConst DsgvoModule/PasswordManager; PasswordManagerBL.ValidateUserRights |
| StRS-013 | SyRS-034, SyRS-008(Hintergrundkommunikation) | SwRS-026, SwRS-037 | CentronHost.cs (NotificationsHub-, Send*Services); ArtificialIntelligence-Prompt-Tabellen |
| StRS-014 | SyRS-023, SyRS-041 | SwRS-Ext(n/a) | ArticleProductionOrders; APlan*; ProductionBL |
| StRS-015 | SyRS-008, SyRS-027, SyRS-035 | SwRS-027, SwRS-028, SwRS-029 | tests/*; DataQualityService; Analytics-Rechte; ChangeTracking |
# Forward-Sicht SyRS -> SwRS (Auszug der SyRS ohne eigenen StRS-Parent-Eintrag oben):
| SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|
| SyRS-001 | SwRS-001, SwRS-014, SwRS-023 | CentronHost.cs; WPF-Projekt; DAO |
| SyRS-002 | SwRS-015, SwRS-023 | Controllers/v1; CentronHost.cs AddCentronApiVersioning |
| SyRS-006 | SwRS-024 | CentronHost.cs TryLoadLicense/SetupDatabaseConnection |
| SyRS-008 | SwRS-027, SwRS-028 | CentronHost.cs HostedServices |
| SyRS-022 | SwRS-006 (Gerätebezug) | ContractEndeService; VertragGeraete |
| SyRS-036 | SwRS-019, SwRS-023 | CentronHost.cs ActivateHelpPage |
| SyRS-037 | SwRS-003 (Belegart-Modell) | Rma; WPF Rma-Modul |
| SyRS-038 | SwRS-003 (CRM-Daten in Legacy-Tabellen) | Sonderaktionen*, CRMProjekt* |
| SyRS-039 | SwRS-001 (Transact. Persistenz) | EDI*BLs; EdiDownloadService |
| SyRS-040 | SwRS-020 (Stammdat-Tabellen) | Kostenstellen, Zahkond |
| SyRS-042 | SwRS-004 (Accounts-Modell) | ProjectBL.cs; ProjectPriceImport |
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Protokoll.md
+94
View File
@@ -0,0 +1,94 @@
# Messprotokoll – Versuch 01 – Prompt-Version 02
## Lauf
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
- **Prompt-Version:** 02
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
- **Startzeit:** 2026-08-28T07:28:25Z
- **Endzeit:** 2026-08-28T08:05:42Z
- **Dauer gesamt:** 37:17 (parallel zu Lauf A)
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
- **Codebasis-Commit:** `37275c96` (dirty: nein)
- **Parallele Läufe:** ja – Lauf A (`z-ai/glm-5.2/builtin/high/092819_v8.0.0-4650`) lief zeitgleich
## Werkzeugkonfiguration
- **Skill-Version:** v8.0.0
- **Werkzeugadapter:** Python API (TensorX Gateway), Adapter v1.1.0
- **Modell (angefordert):** `moonshotai/kimi-k3`
- **Modelle (tatsächlich eingesetzt):** `moonshotai/kimi-k3` (100 %)
- **Kontrolle Modell:** bestanden
- **Effort:** high (Kimi `reasoning_effort` = `high`)
- **Laufverzeichnis-ID:** `v8.0.0-09b6`
- **Ablage:** `Iteration 6/moonshotai/kimi-k3/solo/high/`
- **Agentenmodus:** solo (V1) – keine Subagenten
- **Subagenten:** 0 (solo: korrekt)
## Verbrauch
| Messgröße | Wert |
|---|---:|
| Input-Tokens | 3.333.339 |
| Output-Tokens | 109.640 |
| davon Reasoning-Tokens | 10.213 |
| Cache-Read-Tokens | 3.120.640 |
| **Tokens gesamt** | **3.442.979** |
| Agent-Turns | 50 (max_turns erreicht) |
| Tool-Calls | 84 (23× list_directory, 21× execute_command, 18× search_files, 9× read_file, 13× write_file) |
**Hinweis:** Wanduhrzeit ist durch Parallelbetrieb verzerrt und nicht für Laufzeitvergleiche verwendbar.
## Gefundene Anforderungen
### Verteilung über die Ebenen
| Ebene | Anzahl | Anteil |
|---|---:|---:|
| StRS | 15 | 19,0 % |
| SyRS | 36 | 45,6 % |
| SwRS | 28 | 35,4 % |
| **Gesamt** | **79** | 100 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 171 |
| davon `PRIMÄR` | 102 (59,6 %) |
| davon `SEKUNDÄR` | 58 (33,9 %) |
| davon `KONTEXT` | 11 (6,4 %) |
| Anforderungen mit mind. einem `PRIMÄR`-Beleg | 79 (100,0 %) |
### Status
| Kategorie | Anzahl |
|---|---:|
| belegt | 79 (100 %) |
| `HYPOTHESE` | 0 (0,0 %) |
| Konsolidierungskandidaten | 9 (11,4 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl |
|---|---:|
| übernehmen | 70 (88,6 %) |
| Workaround | 6 (7,6 %) |
| Sonderfall | 1 (1,3 %) |
| veraltet | 2 (2,5 %) |
### Regelkonformität
| Vorgabe | Ergebnis |
|---|---|
| Belegpflicht | **erfüllt** (0 ohne Beleg) |
| Risikobasierte Priorisierung | **erfüllt** (31 risikorelevant, alle gedeckt) |
| Verifizierbarkeit | **erfüllt** |
| Übernahmewürdigkeit | **erfüllt** (alle 79) |
| Traceability | 79/79 (100 %) |
## Ergebnis
- **Status:** erfolgreich
- **Gültigkeit:** gültig – 9 Ergebnisdateien, Stderr.log ohne Abbruch
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SwRS-Ergaenzungen.md, SyRS.md, SyRS-Ergaenzungen.md, Traceability.md
- **Root unverändert:** ja
- **Anmerkungen:**
- 50 Turns = max_turns erreicht — der Agent nutzte die volle Kapazität
- 100 % Primärbeleg-Quote — alle 79 Anforderungen haben mindestens einen PRIMÄR-Beleg
- 0 Hypothesen — auffällig; der Prompt verlangt bei Codebasen dieser Größe mindestens eine. In der Selbstbewertung sollte dies begründet werden.
- Tool-Nutzung ausgewogen: list_directory (23), execute_command (21), search_files (18), read_file (9), write_file (13) — breitere Erkundung als GLM-solo (88× list_directory)
- 2 Ergänzungsdateien (SwRS-Ergaenzungen.md, SyRS-Ergaenzungen.md) — nicht im Prompt vorgesehen, aber inhaltlich zulässig
- Cache-Trefferquote: 93,5 % (3.120.640 von 3.333.339 Input-Tokens)
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/RawResult.json
+718
View File
File diff suppressed because one or more lines are too long
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/Stderr.log
+13
View File
@@ -0,0 +1,13 @@
[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
[glm-kimi-adapter] Start: 2026-08-28T07:28:25.625856+00:00
[glm-kimi-adapter] Provider: TensorX API Gateway
[glm-kimi-adapter] Modell: moonshotai/kimi-k3
[glm-kimi-adapter] Effort: high
[glm-kimi-adapter] Mode: solo
[glm-kimi-adapter] Ende: 2026-08-28T08:05:42.676616+00:00
[glm-kimi-adapter] Turns: 50
[glm-kimi-adapter] Tokens gesamt: 3,442,979
[glm-kimi-adapter] Tool-Calls: 84
[glm-kimi-adapter] Subagenten: 0 (completed: 0, failed: 0)
[glm-kimi-adapter] Ergebnisdateien: 9
[glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 6\moonshotai\kimi-k3\solo\high\02_Lauf_2026-08-28_092820_v8.0.0-09b6\RawResult.json
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/_meta/after.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/_meta/anforderungen.json
+1595
View File
File diff suppressed because it is too large Load Diff
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/_meta/anforderungen.md
+65
View File
@@ -0,0 +1,65 @@
## Gefundene Anforderungen
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
### Verteilung über die Ebenen
| Ebene | Anzahl | Anteil |
|---|---:|---:|
| StRS | 15 | 19,0 % |
| SyRS | 36 | 45,6 % |
| SwRS | 28 | 35,4 % |
| **Gesamt** | **79** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 30 | 38,0 % |
| Sicherheit | 16 | 20,3 % |
| Daten | 16 | 20,3 % |
| Schnittstelle | 9 | 11,4 % |
| nicht-funktional | 8 | 10,1 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 171 |
| davon `PRIMÄR` | 102 (59,6 %) |
| davon `SEKUNDÄR` | 58 (33,9 %) |
| davon `KONTEXT` | 11 (6,4 %) |
| Belege je Anforderung (Median) | 2 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 79 (100,0 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 70 | 88,6 % |
| workaround | 6 | 7,6 % |
| sonderfall | 1 | 1,3 % |
| veraltet | 2 | 2,5 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 79 | 100,0 % |
| als `HYPOTHESE` gekennzeichnet | 0 | 0,0 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 9 | 11,4 % |
| mit ISO-25010-Qualitätsmerkmal | 24 | 30,4 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (31 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 79 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 79 von 79 mit Tracelinks (100,0 %) |
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/_meta/before.txt
+1
View File
@@ -0,0 +1 @@
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/_meta/combined_prompt.md
+181
View File
@@ -0,0 +1,181 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-26
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
### Pflicht-Eigenschaften jeder Anforderung
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
- **Belegklassifikation:** Kennzeichne jeden Beleg als
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
### Formatvorgabe pro Anforderung
```
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
Titel: <kurzer Titel>
Ebene: <StRS | SyRS | SwRS>
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur: <Rolle / System / Komponente>
Vorbedingung: <Zustand vor Auslösen>
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
Belege:
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
- [SEKUNDÄR] <...> - Begründung: <...>
- [KONTEXT] <...> - Begründung: <...>
Prüfidee: <Akzeptanzkriterium oder Testidee>
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status: <belegt | HYPOTHESE>
```
### Traceability
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
### Nicht-funktionale Anforderungen
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
### Konsolidierungsbedarf
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
```
Ergebnisse/
StRS.md
SyRS.md
SwRS.md
Traceability.md (oder Traceability.csv)
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
Selbstbewertung, bekannte Lücken)
```
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
Nicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
Verfuegbare Werkzeuge:
- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
- list_directory: Listet Verzeichnisinhalte auf
- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
$laufB\Ergebnisse\.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/_meta/endzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-28T10:05:42.7024716+02:00
Versuche/Versuch_01/Iteration 6/moonshotai/kimi-k3/solo/high/02_Lauf_2026-08-28_092820_v8.0.0-09b6/_meta/startzeit.txt
+1
View File
@@ -0,0 +1 @@
2026-08-28T09:28:20.3929596+02:00