Lots of runs
This commit is contained in:
Christoph Schwörer
+121
@@ -0,0 +1,121 @@
|
||||
# Analysebericht
|
||||
|
||||
**Lauf:** V1 Baseline (Prompt-only), Iteration 01 — 2026-08-25
|
||||
**Codebasis:** c-entron ERP-Suite, Commit 79c1142f48 (main), nur lesend analysiert.
|
||||
**Methode:** RRE-Schritte 2–6 (Artefakterhebung, technische Analyse, semantische Interpretation, Formalisierung, Traceability); statische Analyse ohne Ausführung. Die technische Analyse wurde über 13 parallel arbeitende Explorationsdurchgänge (Werkzeug-interne Subagenten der Claude-Code-Standardausstattung, keine benutzerdefinierten Agentendateien, keine MCP-Server) über die Fachdomänen gefahren; Konsolidierung und Formalisierung erfolgten zentral.
|
||||
|
||||
---
|
||||
|
||||
## 1. Quantitativer Überblick der Codebasis
|
||||
|
||||
| Kennzahl | Wert | Quelle |
|
||||
|---|---|---|
|
||||
| Projekte in Centron.sln | 82 | Centron.sln |
|
||||
| C#-Dateien (src) | 15.554 | Dateizählung |
|
||||
| XAML-Dateien / Razor-Komponenten | 1.233 / 491 | Dateizählung |
|
||||
| .NET-SDK / Version | 10.0.100 / 2.0.2611-alpha (Nerdbank) | global.json, version.json |
|
||||
| Commits (2014–2026) | ~52.000 | git log |
|
||||
| RPC-API-Endpunkte / REST-Aktionen | ~2.600 / 171 | ICentronRestService*, Centron.Controllers |
|
||||
| NHibernate-Mappings / Entities / Tabellen+Views | 882 / 1.163 / ~807 | Centron.DAO/Entities |
|
||||
| Migrationsskripte (aktuell/Legacy) | 764 / ~937+XML | Scripts-Verzeichnisse |
|
||||
| Rechtekonstanten-Katalog | ~2.800 Zeilen (UserRightsConst) | Centron.WebServices.Core |
|
||||
| Lizenz-GUIDs / ApplicationKinds | 159 / 48 | LicenseGuids.cs |
|
||||
| Hintergrunddienste | ~34 | Centron.Host\HostedServices |
|
||||
| E2E-Testklassen / Snapshots | 270 / 3.254 | tests\Centron.Tests.EndToEnd |
|
||||
|
||||
## 2. Modul-/Komponentenübersicht und Analysetiefe
|
||||
|
||||
Legende Analysetiefe: **T** = tief (Kernlogik gelesen, Regeln extrahiert), **S** = stichprobenhaft (Struktur + ausgewählte Dateien), **O** = nur Existenz/Überblick, **–** = nicht analysiert.
|
||||
|
||||
| Bereich | Wichtigste Artefakte | Tiefe | In Anforderungen |
|
||||
|---|---|---|---|
|
||||
| Belegwesen Verkauf (Sales/Receipts) | ReceiptBL (10k+ Z.), 12 SpecificLogics, DownPayment, ReceiptItem/Price/Account/BookingBL | T | SyRS-013…019, SwRS-016…030 |
|
||||
| Vertragsabrechnung | AutomaticFacturaBL.Contracts, ReceiptContractHelperBL, ContractArticleReferenzes | T | SyRS-025 |
|
||||
| Helpdesk/Tickets | HelpdeskBL/SearchBL/StatusBL, Escalation, Pattern, Checklists, TaskManager | T | SyRS-020…022 |
|
||||
| Zeiterfassung/Abrechnung | HelpdeskTimer(BL/WebServiceBL/Signature), TimerBilling, ReceiptItemTimerBL | T | SyRS-023/024 |
|
||||
| Einkauf/Lager/Logistik | Supplier-SpecificLogics, OrderSuggestionList, ArticleStock/Barcode/Inventory, Commission | T | SyRS-029…034 |
|
||||
| RMA/Werkstatt | RmaBL (2k Z.), TicketRma-/SendBack-/SendForth-ViewModels | T | SyRS-035 |
|
||||
| Finanzen | BookKeepingExport (DATEV ASCII/XML), BookKeepingImport, SEPA, Dunning/Opos, OnlineBanking, InvoiceZugferdBL, ebInterface | T | SyRS-016/017/019, 039–043 |
|
||||
| Sicherheit/AuthN/AuthZ/Lizenz | Auth\*, TicketBL, AccessTokenBL, TwoFactor, AppRightsBL, LicenseManager, Kryptoklassen | T | SyRS-006…012, 055 |
|
||||
| Nexus/Portal/Signatur | Index/Routing, PortAuth, ReceiptCart(+Release), SharedDocumentBL, WebReceipt, DsgvoBL, SelfCare | T | SyRS-026…028 |
|
||||
| Webservice/Host/API | CentronHost, WcfBridge+Interceptors, Controllers, ConnectionManager, Deployment | T | SyRS-001…005, 049, 060 |
|
||||
| Persistenz/Datenmodell | DAOFactory/DAOSession, Mappings, UserTypes, NamedQueries, ScriptEngine | T | SyRS-050, SwRS-061…065 |
|
||||
| Stammdaten | AccountBL/Repository, Address/ContactPerson, ArticleBL, EmployeeArticle, NumberGroup, Country | T | SyRS-069 |
|
||||
| Integrationen | EDI (SupplierEdi/Dispatcher), ITscope/EGIS/COP/Icecat, GLS/Shipcloud, docuFORM, finAPI, RMM/DocBee/TANSS/ES, Mail/Graph/EWS, Kalender-Sync, TAPI | T | SyRS-036…048 |
|
||||
| Querschnitt/NFR | Logging, Telemetrie, Settings, Lokalisierung, Reporting, Suche, KI, Customizations, Tests, CI | T | SyRS-049…063 |
|
||||
| Projekte/Planung | CrmProjectBL, TicketProject(+Webservice), Scheduler, Utilization | T | SyRS-062/065 |
|
||||
| Kalender/MyDay/Termine | ScheduleBL, CalendarBL, MyDayBL(+Notifications), AppointmentRequests | T | SyRS-045/066/067 |
|
||||
| Produktion | ProductionBL/OrderBL, Nexus-Werkeransicht | T | SyRS-064 |
|
||||
| Restmodule | QM, Survey/Audit, Statistics-Module, TelekomDive, PayersAndCostCenter, PLM, ProjectPriceImport, Dashboard, MyCentron-Inspectors, ExpectedEvents, Devices, DocuBoard | S–T | SyRS-068 u. StRS/Hypothesen |
|
||||
| WPF-UI-Fläche (1.233 XAML) | Views/ViewModels außerhalb der o. g. Regeln | S | punktuell als SEKUNDÄR-Belege |
|
||||
| Dokumentenmanagement (FileManagement/Directories) | DocumentBL, Verzeichnisse | S | indirekt (StRS-027, SyRS-027) |
|
||||
| ToDo/Notifications-Details, Chat, Mailings, SocialMedia, VideoPortal, Urls/WebLinks/Tags, TextModuleArea, CPra, DocumentationArea, MyCentron-Einzelseiten | BL-Ordner | O | nein (Lücke, s. u.) |
|
||||
| Reports-Inhalte (FastReport-Definitionen), NamedQueryPool-Einzelqueries (371), pain.008-Generatklassen, übrige 11 FiBu-Formate im Detail | – | O/– | als Grenze ausgewiesen |
|
||||
| VoucherManagement, CashBook, Provisionen (ReceiptProvisionBL nur gestreift), Mobile, IndexSearch-Dokumentteil, Outlook-AddIn-Innenleben, SupRemo, Buying/Storage-Legacy | – | O/– | nein (Lücke) |
|
||||
| Centron.Controls / Controls.Preview, Centron.Common-Utilities (außer Krypto/Logging/Settings) | – | O | nein |
|
||||
| tests\ (Inhalte einzelner E2E-Tests) | Infrastruktur gelesen, Fachtests nicht | S | SyRS-053 (Perf-Ziel) |
|
||||
|
||||
## 3. Ergebnisumfang
|
||||
|
||||
| Dokument | Anzahl Anforderungen | davon HYPOTHESE | davon „belegt; Workaround" |
|
||||
|---|---|---|---|
|
||||
| StRS.md | 27 | 1 (StRS-025, nur Zweck/Rechtsgrundlage) | 1 Abgrenzungsvermerk (Barbelege) |
|
||||
| SyRS.md | 70 | 1 (SyRS-056, nur Abschaltbarkeit/Zweck) | mehrere Migrationshinweise in Aussagen |
|
||||
| SwRS.md | 75 | 1 Teilmarkierung (SwRS-049 Rechtelücken-Intention) | 10 (SwRS-002, 018, 021, 022, 024, 030, 038, 045, 047, 051, 055, 064, 065, 069, 071 → 15 Kennzeichnungen) |
|
||||
| Hypothesen.md | 20 Hypothesen (H-01…H-20) | — | — |
|
||||
| Traceability.md | 71 Matrixzeilen | — | — |
|
||||
| Glossar.md | ~120 Begriffe | — | — |
|
||||
|
||||
Belegklassifikation (Stichprobe über alle Anforderungen): jede Anforderung führt ≥1 Beleg; >90 % der Anforderungen besitzen mindestens einen PRIMÄR-Beleg; ausschließlich SEKUNDÄR/KONTEXT-gestützt sind nur SwRS-001 (Architekturmuster, KONTEXT-Doku + durchgängiges Namensmuster) sowie Teile von SyRS-058/060 (Ressourcen-/Pipeline-Zählungen) — dort ist die Aussage entsprechend zurückhaltend formuliert.
|
||||
|
||||
## 4. Konsistenzcheck über das gesamte Anforderungs-Set
|
||||
|
||||
Durchgeführt nach Abschluss der Formalisierung (manuell-systematisch über die ID-Register und Tracelink-Felder):
|
||||
|
||||
1. **Doppelte/mehrfach vergebene IDs:** keine. StRS-001…027, SyRS-001…070, SwRS-001…075 sind lückenlos und eindeutig vergeben (fortlaufende Vergabe, per Registerabgleich geprüft).
|
||||
2. **Anforderungen ohne Beleg:** keine. Jede Anforderung führt mindestens einen klassifizierten Beleg mit Begründung; risikobehaftete Kategorien (Sicherheit, Abrechnung, Berechtigungen) führen durchgängig PRIMÄR-Belege.
|
||||
3. **Tracelinks auf nicht existierende IDs:** Beim Check wurden **zwei fehlerhafte Abwärtsverweise gefunden und vor Abgabe korrigiert** (SyRS-063 verwies auf SwRS-063 [tatsächlich Migrations-Engine], SyRS-066 auf SwRS-062 [tatsächlich NamedQueries]; beide SyRS sind jetzt explizit „ohne eigene SwRS-Verfeinerung" markiert). Nach Korrektur: alle StRS→SyRS-, SyRS→StRS-, SyRS→SwRS- und SwRS→SyRS-Verweise zeigen auf existierende IDs; die Traceability-Matrix ist deckungsgleich mit den Tracelink-Feldern.
|
||||
4. **Bidirektionalität:** Für jede in einem SyRS-Feld genannte SwRS-ID enthält die SwRS-Anforderung den Rückverweis (stichprobenartig vollständig gegengeprüft, 2 Korrekturen s. o.).
|
||||
5. **Bekannte Einschränkung:** Zeilennummern in Belegen sind „ca."-Angaben aus dem Analysezeitpunkt (Commit 79c1142f48); bei künftigen Ständen sind Klasse/Methode maßgeblich.
|
||||
|
||||
## 5. Selbstbewertung
|
||||
|
||||
### 5.1 Vollständig vs. stichprobenhaft vs. nicht analysiert
|
||||
- **Vollständig (regelextrahierend):** die 18 in Abschnitt 2 mit **T** markierten Kernbereiche — sie tragen die 172 Anforderungen.
|
||||
- **Stichprobenhaft:** WPF-UI-Fläche (nur als SEKUNDÄR-Belegquelle und für client-only-Regeln), Restmodule (RMA tief, QM/Survey/PLM u. a. mittel), Dokumentenmanagement, Testinhalte.
|
||||
- **Nicht analysiert:** VoucherManagement, CashBook, Provisionslogik im Detail, Chat/Mailings/SocialMedia/VideoPortal/TextModule/CPra/Urls/Tags, Mobile, Outlook-AddIn-Innenleben, SupRemo, Report-Definitionsinhalte, die 371 NamedQueries einzeln, 11 weitere FiBu-Exportformate im Detail, generierte SEPA-Klassen, Centron.Controls. Diese Bereiche sind im Anforderungs-Set entweder gar nicht oder nur als Systemkontext vertreten — das ist eine bekannte Abdeckungslücke, keine belegte Irrelevanz.
|
||||
|
||||
### 5.2 Wo der Beleg dünn ist
|
||||
- **Icecat** (nur Settings, SEKUNDÄR) und **Lokalisierungs-/CI-Zahlen** (SEKUNDÄR-Zählungen).
|
||||
- **Abwesenheitsbefunde** (kein Lockout, kein Passwortablauf, keine Mahngebühren, ungenutzte Rechte): methodisch als „Suche ohne Treffer" belegt — sie sollten in der Experten-Validierung bestätigt werden, da statische Suche Nebenpfade übersehen kann.
|
||||
- **Intentionsfragen** sind konsequent in Hypothesen.md ausgelagert (20 Stück) statt als Anforderungen behauptet.
|
||||
- **Client-only-Regeln** (Versand, Logistik-Settings, Produktion, zwei Helpdesk-Rechte): Ist-Verhalten PRIMÄR belegt, aber die Soll-Interpretation („serverseitig gewollt") ist Hypothese (H-03, H-12).
|
||||
|
||||
### 5.3 Zentrale Erkenntnisse für die Migrationsperspektive (Konsolidierungs-/Prüfschwerpunkte)
|
||||
1. **Doppelstrukturen als Hauptkonsolidierungsfelder:** Alt-/Neu-Stammdaten (Kunden/Anschrif vs. Accounts, Dual-Write), zwei API-Stile, zwei Belegart-Kodierungen, zwei Signaturstrecken, zwei 2FA-Welten, vier Krypto-Klassen, dreifach implementierte Ticket-Sichtbarkeitsfilter, zwei Settings-Kataloge, Lese-Views vs. deutsche Schreibtabellen (10-Stellen-Pflegeregel).
|
||||
2. **Sicherheits-Altlasten sind gut lokalisierbar** (SyRS-055/SwRS-014 als Ablösungskatalog) und stehen im Kontrast zu modernen Teilen (JWT-Validierung, Access-Tokens, Query-Level-RBAC).
|
||||
3. **Die eigentliche Fachlogik ist serverseitig erstaunlich konsequent durchgesetzt** (Rechte in Queries, Belegpipeline, Zeiten-Sperren) — mit klar benannten Ausnahmen (Client-only-Fälle), die als explizite Migrationsanforderungen formuliert wurden.
|
||||
4. **Gewachsene Zahlen-Toleranzen** (2,00 / 3,00 / 0,50 / 0,10 / 20) sind implizite Fachvorgaben und müssen fachlich bestätigt oder parametrisiert werden (H-17).
|
||||
|
||||
### 5.4 Empfohlener Nachschlag für Folge-Iterationen
|
||||
1. **Fehlende Fachbereiche heben:** VoucherManagement, CashBook, Provisionen, Dokumentenmanagement/DMS-Kern, ToDo/Erinnerungswesen, Chat/Kommunikationsmodule — gleiche Methodik, geschätzt je 15–30 weitere Anforderungen.
|
||||
2. **NamedQueryPool systematisch auswerten** (371 SQLs): dort stecken Reporting-/Buchhaltungsregeln, die bisher nur über ihre Aufrufer erfasst sind.
|
||||
3. **Belegdruck/Reportinhalte** (FastReport-Definitionen in DB-Backups) für Layout-/Pflichtangaben-Anforderungen (z. B. Rechnungspflichtfelder).
|
||||
4. **E2E-Testbestand als Anforderungsquelle** nutzen: 270 Tests + 3.254 Snapshots kodieren erwartetes Verhalten und eignen sich zur Verifikation der hier formalisierten Prüfideen.
|
||||
5. **Hypothesenliste (H-01…H-20) mit Fachexperten schließen** — insbesondere H-01 (Telemetrie/Datenschutz), H-02/H-03 (Rechte-Lücken) und H-17 (Toleranzwerte) vor Architekturentscheidungen des Zielsystems.
|
||||
6. **Delphi-Altanwendung** (nicht Teil dieser Codebasis) für die Barkassen-Funktion (H-08) und historische Datenkodierungen (UserTypes) hinzuziehen.
|
||||
|
||||
---
|
||||
|
||||
## 6. Dateiübersicht des Ergebnisses
|
||||
|
||||
```
|
||||
Ergebnisse/
|
||||
StRS.md 27 Stakeholder-Anforderungen
|
||||
SyRS.md 70 System-Anforderungen (inkl. ISO-25010-Zuordnung der NFAs)
|
||||
SwRS.md 75 Software-Anforderungen (Komponenten, Datenmodell, interne Regeln)
|
||||
Traceability.md Forward-/Backward-Matrix StRS↔SyRS↔SwRS mit Artefaktbelegen
|
||||
Hypothesen.md 20 Hypothesen mit offenen Validierungsfragen
|
||||
Glossar.md ~120 Domänenbegriffe
|
||||
Analysebericht.md dieses Dokument
|
||||
```
|
||||
+159
@@ -0,0 +1,159 @@
|
||||
# Glossar
|
||||
|
||||
Domänenbegriffe, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen, Tabellen, Spalten) in Originalschreibweise. Quelle in Klammern, wo der Begriff kodifiziert ist.
|
||||
|
||||
## Organisations- und Identitätsbegriffe
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Mandant (Mandator)** | Rechtliche Firmeneinheit mit eigenen Bank-/SEPA-/FiBu-Daten. Mehrere Mandanten einer Installation teilen die Datenbank; getrennte Firmen laufen über getrennte Datenbanken/Sub-Web-Services. |
|
||||
| **Filiale (Branch, Tabelle `Filiale`)** | Organisationseinheit unterhalb des Mandanten; steuert Nummernkreise, Rechte-Restriktionen („nur eigene Filiale"), Bundesland (Feiertage) und Auswertungssichten. |
|
||||
| **AppUser (Tabelle `Sichbenu`)** | Internes Benutzerkonto, 1:1 mit einem Mitarbeiter (`Personal`) verknüpft. |
|
||||
| **WebAccount** | Externes Portal-Benutzerkonto, an Ansprechpartner eines Kunden gebunden; eigenes Rechtesystem (`WebAccountRightsConst`). |
|
||||
| **Kunden-Administrator** | WebAccount mit Web-Recht CUSTOMERADMINISTRATOR; verwaltet Portalbenutzer des eigenen Kunden selbst. |
|
||||
| **Mitarbeiterartikel (EmployeeArticle)** | Dienstleistungsartikel, der einen Mitarbeiter für die Zeit-/Leistungsabrechnung repräsentiert (Stundensatz, Kostenstelle, Provision); definiert auch „eigene Zeit" (OWN_TIME_EDIT). |
|
||||
| **Restriktives Recht (restricting right)** | Recht, dessen **Besitz** die Sicht einschränkt (z. B. „Tickets anzeigen – nur eigene"); Nichtbesitz bedeutet Vollzugriff (dokumentiert in CentronRights.md). |
|
||||
| **Vertriebsgebiet (SalesArea)** | Mitarbeiter-Kunden-Zuordnung, die Beleg- und Ticketsichtbarkeit zusätzlich begrenzt. |
|
||||
| **ConnectionTicket** | Serverseitige Sitzungskennung (40-Hex), gleitend gültig (Default 30 min); Grundlage der Concurrent-Lizenzzählung. |
|
||||
| **Access-Token** | Persönliches API-Token für Maschinenzugriffe (Show-once, SHA-256-gespeichert, widerrufbar). |
|
||||
| **Lizenz-GUID** | Kennung eines lizenzierbaren Moduls/Produkts (159 Stück); „Concurrent-User" = Zählung aktiver ConnectionTickets je Anmeldelizenz. |
|
||||
|
||||
## Belegwesen
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Beleg (Receipt/Asset)** | Oberbegriff für Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag sowie die Lieferantenpendants (Anfrage, Bestellung, Wareneingang, WE-Kalkulation/Lieferantenrechnung, Lieferantengutschrift). Kodiert in `CentronObjectKindNumeric`. |
|
||||
| **Weiterverarbeitung (Forwarding)** | Erzeugen eines Folgebelegs aus einem Beleg entlang der festen Belegfluss-Matrix; Übernahme restmengenbasiert (Reference) oder vollständig (Copy). |
|
||||
| **Belegversion** | Vollständiger Snapshot eines Belegs je Änderung (`*Versions`-Tabellen); Belege werden nie überschrieben. |
|
||||
| **ReceiptState** | Belegzustand Active(1)/Completed(2)/Canceled(3); Completed wird restmengengetrieben automatisch gesetzt. |
|
||||
| **Festschreibung (IsFixed)** | GoBD-Unveränderlichkeitskennzeichen einer Rechnung; unabhängig vom Belegzustand. |
|
||||
| **Abholschein (PickupList)** | Rücknahmebeleg des Kunden (bestandserhöhend); Endpunkt der Kundenkette neben der Gutschrift. |
|
||||
| **WE-Kalkulation (SupplierInvoice)** | Lieferantenrechnung/Einstandskalkulation zum Wareneingang; bei Spätbuchung der bestandswirksame Beleg. |
|
||||
| **Spätbuchung (LateBooking, `SpaeteBuchung`)** | Prozessvariante, bei der erst die WE-Kalkulation (nicht der Wareneingang) den Bestand bucht. |
|
||||
| **Direktlieferung (IsDirectDeliveryPossible)** | Lieferantenlieferung direkt an den Endkunden; überträgt Liefertermine in den Kundenauftrag. |
|
||||
| **Anzahlungsrechnung / Schlussrechnung** | Rechnung mit Auftragsbezug über den konfigurierten Anzahlungsartikel; die Schlussrechnung zieht Anzahlungen als Negativpositionen ab. |
|
||||
| **Kundenrabatt-Position** | Automatisch berechnete Belegposition (Kind CustomerDiscount), die den prozentualen Kundenrabatt als negativen Betrag abbildet. |
|
||||
| **Positionsart (ReceiptItemArticlePositionKind)** | Kennzeichnung Default/Cargo/Alternativ/Optional/Informativ/„Auf Anfrage"/„Nach Aufwand"/„Keine Leistung"; nur Default/Cargo sind summenwirksam. |
|
||||
| **Titelposition** | Gliederungsposition, die in der E-Rechnung ihre Unterpositionen aggregiert. |
|
||||
| **Nummernkreis (NumberGroup)** | Konfigurierbarer Zähler je Belegart/Stammdatenart, filial-/mandantenabhängig aufgelöst; „InternalInvoice" = eigener Kreis für 0-€-Dienstleistungsrechnungen. |
|
||||
| **Ursprung (`UrsprungI3D`/`UrsprungArt`)** | Positionsverweis auf die Quellposition der Belegkette (eigene Kodierung `ReceiptItemOrigin`). |
|
||||
| **ConcurrencyControlGuid** | Optimistisches Sperrkennzeichen je Beleg; Abweichung beim Speichern signalisiert Parallelbearbeitung. |
|
||||
|
||||
## Preise/Konditionen
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Preisliste VK1–VK4** | Vier Verkaufspreisstufen am Artikel; Kundenzuordnung über `Customer.PriceList`. |
|
||||
| **Kunden-Sonderpreis (CustomerSpecialPrice/AccountSpecialPrice)** | Zeitraumgültige Kondition je Kunde auf Artikel oder Warengruppe(+Unterwarengruppe); definiert auch den WebCart-Katalog. |
|
||||
| **Vertrags-Sonderpreis (ContractSpecialPrice)** | Exklusive Preisregel eines Vertrags (5 Basen × Fest/Prozent; Werte invertiert gespeichert). |
|
||||
| **Staffelpreis (ArticleVolumePrices)** | Mengenabhängige Preisstufen inkl. eigenem EK; vertraglich abschaltbar. |
|
||||
| **Sondervereinbarung (SpecialAgreement)** | Projekt-/Rahmenkondition auf EK und/oder VK, kunden- oder belegartglobal. |
|
||||
| **Mindestpreis (MinPrice)** | Untergrenze des Positionspreises; Unterschreitung nur mit Sonderrecht oder Zweitfreigabe. |
|
||||
| **ActionPrice (`HerstellerArtikAktionspreis`)** | Befristeter Distributor-Aktionspreis; Anzeige im Preisspiegel, ohne automatische Belegpreiswirkung. |
|
||||
| **EVP / Listenpreis** | Empfohlener Verkaufspreis bzw. Herstellerlistenpreis als Konditionsbasen. |
|
||||
| **Preisspiegel** | Vergleichssicht der Einkaufsquellen (Lager-EK, Distributoren, Aktionspreise) je Artikel. |
|
||||
|
||||
## Steuern/Finanzen
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Steuerzone / Zielkategorie (AccountTargetKind)** | Klassifikation Inland/EU/Übersee/ReverseCharge/steuerfrei je Position; steuert Konto- und Steuerschlüsselwahl. |
|
||||
| **Reverse Charge (§13b UStG)** | Steuerschuldumkehr; wirksam nur mit USt-IdNr. des Partners und Steuersatz 0 (Code „AE"). |
|
||||
| **Erlös-/Aufwandskonto (ProfitAndLossAccount)** | Kontensatz je Artikel/Warengruppe/MwSt/Land mit acht Zielfeldern (Richtung × Zone). |
|
||||
| **BU-Schlüssel** | DATEV-Buchungsschlüssel (Steuerschlüssel) aus dem MwSt-Stamm (`TaxCode`/`PurchaseTaxCode`). |
|
||||
| **Splitbuchung** | Zerlegung eines Belegs in Buchungssätze je Konto/Steuersatz/Steuerschlüssel/Kostenstelle für den FiBu-Export. |
|
||||
| **OPOS** | Offene-Posten-Verwaltung; „OPOS-Import" = Rückübernahme von FiBu-Zahlungen, „OPOS-Auszug" = Kontoauszugsreport ohne Mahnwirkung. |
|
||||
| **Mahnstufe (DunningLevel)** | Eskalationsstufe 0–3 einer Rechnung; „Mahnsperre" = zeitfensterbasierter Ausschluss auf Kunden-/Rechnungsebene. |
|
||||
| **SEPA-Mandat** | Lastschrifterlaubnis je Bankverbindung (Mandatsreferenz `AuthorizationNumber`, Unterschriftsdatum, Sequenztyp First/Recurrent/Single/Last, CORE/B2B). |
|
||||
| **Gläubiger-ID (`SepaIdentificationNumber`)** | SEPA-Identifikation des Mandanten. |
|
||||
| **Leitweg-ID** | B2G-Empfängerkennung; ihr Vorhandensein schaltet die E-Rechnung auf XRechnung-Konformität. |
|
||||
| **ZUGFeRD / XRechnung** | Hybride PDF/A-3-Rechnung mit eingebettetem CII-XML bzw. deren B2G-Profil (EN 16931). |
|
||||
| **ebInterface** | Österreichisches E-Rechnungsformat (implementiert, derzeit nicht angebunden). |
|
||||
| **Festschreibungskennzeichen (Feld 114)** | DATEV-Feld „Buchung festschreiben"; standardmäßig 1. |
|
||||
| **Kontingent (Contingent)** | Vertraglich vereinbartes Stunden- oder Geldbudget, das über Ausgleichspositionen verbraucht und bei Rücknahmebelegen zurückgerollt wird. |
|
||||
| **Click-Vertrag / Klickabrechnung** | Abrechnung nach Gerätezählerständen (z. B. Druckseiten), Zähler u. a. via docuFORM. |
|
||||
| **RMM-Artikel** | Vertragsposition, deren Menge aus einem RMM-System gemessen und mit Fix-/Mindest-/Höchstmengen verrechnet wird (Platzhalter `@@RMMArtikel@@`). |
|
||||
| **Schweizer Rundung (CommercialRoundCH)** | 5-Rappen-Rundung des Bruttobetrags über eine Steuerkorrektur. |
|
||||
|
||||
## Service/Tickets/Zeiten
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Ticket/Helpdesk (Tabelle `hlpdsk_requests`)** | Servicevorgang mit konfigurierbarem Status-Stamm (`HelpdeskState`), Priorität, Kategorien, Bearbeitern und Verantwortlichem. |
|
||||
| **Geschlossen-Status (HelpdeskClosedState)** | Der eine, per Einstellung bestimmte Status, der als „abgeschlossen" gilt; Setzen erfordert CLOSE_REQUEST. |
|
||||
| **Fälligkeit (DueDate)** | Aus der Priorität und Geschäftszeiten berechneter Reaktionstermin; Änderung erfordert MATURITY_CHANGE und setzt die Eskalation zurück. |
|
||||
| **Eskalationsstufe (EscalationLevel)** | Stufe 1–3 aus dem arbeitszeitbasierten Eskalationsmodell mit Empfängerkreisen je Stufe. |
|
||||
| **Intern-Kennzeichnung (IsOnlyInternalVisible)** | Ticket-Flag, das Portalnutzern die Sicht entzieht. |
|
||||
| **Freigabewesen (Portal-Tickets)** | Kundeninterner Genehmigungsschritt neuer Portal-Tickets; wartende Tickets tragen keinen Status. |
|
||||
| **Timer / Helpdesk-Zeit (Tabelle `hlpdsk_timer`)** | Erfasste Servicezeit (Start/Stop, berechenbar-Flag, geplant-Flag) mit Belegpositions-Verweisen nach Abrechnung. |
|
||||
| **IsAssignedToAsset** | „Zeit ist abgerechnet" (Auftrag, Lieferschein oder Rechnung) → Änderungssperre. |
|
||||
| **Zeiten-Signatur** | Kundenunterschrift auf geleisteten Zeiten; einmalig, Entfernen nur mit DELETE_HELPDESK_SIGNATURE + Protokoll. |
|
||||
| **Timer-Billing** | Abrechnungslauf, der berechenbare, unzugeordnete Zeiten in Belege überführt; optional mit automatischem Ticketabschluss. |
|
||||
| **C-FLOW / TicketPattern** | Ticketvorlagen mit Vollausprägung (Kategorien, Checklisten, Formulare, Portal-Sichtbarkeit). |
|
||||
| **Checkliste (CentronChecklist)** | Aus Vorlagen instanziierte Abarbeitungsliste am Ticket (8 Item-Status inkl. Misserfolgsarten). |
|
||||
| **Taskmanagement** | Scheduler für wiederkehrende Serviceaufgaben inkl. automatischer Ticketerzeugung mit Vertretungsregelung. |
|
||||
| **MyDay** | Persönliche Tagesrekonstruktion aus Terminen/Anrufen/Sessions mit abteilungsweiser Abschlusspflicht. |
|
||||
| **ExpectedEvents** | Überwachung erwarteter wiederkehrender Kundenmeldungen (z. B. Backup-Reports) mit Textklassifikation. |
|
||||
| **Stammblatt (MasterDataList, `GeraeteKopf`)** | Gerätelebenslauf-Akte (Seriennummernbezug), u. a. bei RMA/Verschrottung fortgeschrieben. |
|
||||
| **Ticket-Fingerprint** | Gesalzener Hash über das Änderungsdatum eines Tickets zur Manipulationserkennung. |
|
||||
|
||||
## Lager/Logistik/RMA
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Hauptlager / Nebenlager (`Nebenlager`)** | Bestandsführende Lager; Hauptlager mit Kennung I3D=-1, Struktur Lager → Lagerort (`Lagerplatz`) → Lagerbereich. |
|
||||
| **StockKind** | Lagertyp Default/RmaOwn/RmaCustomer/StockTransfer(Transit)/RepairAndLend. |
|
||||
| **Seriennummer/Barcode** | Physische Einheit mit 25-Zustands-Lebenszyklus (`BarcodeState`); bestandsdefinierend für SN-Artikel (Zustände 1,2,8,9). |
|
||||
| **SN-Pflicht (`Artik.BarcodeScanen`)** | Artikelflag „Seriennummern erforderlich"; schaltet die Bestandsdefinition auf SN-Zählung um. |
|
||||
| **Exklusivbindung (BarcodeToPosition2)** | Eine SN ist zu jedem Zeitpunkt höchstens einer aktiven Belegposition zugeordnet. |
|
||||
| **InIntake** | SN-Zustand „im Wareneingang erfasst, noch nicht gebucht" (nicht bestandswirksam). |
|
||||
| **Zulauf (Intake)** | Materialisierter Cache bestellter/avisierter Mengen für den Bestellvorschlag. |
|
||||
| **Bestellvorschlag (BVL)** | Automatische Bedarfsermittlung: Auftragsbedarf + Mindestbestand − Bestand − Zulauf, mit ABC-Lieferantenwahl. |
|
||||
| **ABC-Lieferant (`ALieferantI3D`…)** | Priorisierte Bezugsquellen je Artikel für den Bestellvorschlag. |
|
||||
| **Kommissionierung (QuantityPicked)** | Bereitstellung je Auftragsposition; bei SN-Artikeln zählt die gescannte SN-Menge; Teilkommissionierung über Packvorgänge (`PartialCommissionOrderState`). |
|
||||
| **Inventurverlust (LostAtStocktaking)** | SN-Zustand für bei Inventurabschluss nicht gescannte Einheiten. |
|
||||
| **Lagerumbuchung (TRANSFER_STOCK)** | Rechtepflichtige Bestandsverschiebung mit doppelter Log-Spur (`ARTIKlog`, `StockRebookLog`). |
|
||||
| **Negativbuchung (RIGHT_NEGATIVBUCHUNG)** | Warenausgang in negativen Bestand; ohne Recht Vier-Augen-Fremdfreigabe. |
|
||||
| **RMA (Eigen-/Kunden-/Fremdware)** | Werkstatt-/Reklamationsfall, zwingend ticketgebunden; Fremdware = Ware ohne eigene Beleghistorie (erhält neue SN im Sperrlager). |
|
||||
| **Vorabtausch (AdvanceDeliveryList)** | Ersatzlieferung an den Kunden vor Abschluss der Lieferantenabwicklung (auch als Leihvariante). |
|
||||
| **RmaForthAction** | Werkstattentscheidung je Position (1:1-Tausch, Fremdtausch, Reparatur, vor Ort, Verschrottung …). |
|
||||
| **EK-Fortschreibung** | Gleitender Durchschnitt oder Letztpreis beim Wareneingang inkl. Fracht/Versicherung × Kalkulationsfaktor. |
|
||||
|
||||
## Portal/Web/Signatur
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **Nexus** | Blazor-Weboberfläche (Mitarbeiter-ServiceBoard + Kundenportal in einer Anwendung, port-trennbar). |
|
||||
| **ServiceBoard** | Mitarbeiter-Sicht in Nexus (Tickets, Kanban, Scheduler, Statistik). |
|
||||
| **WebCart** | Kundenportal-Shop auf Basis der Kunden-Sonderpreise mit Prüfer/Besteller-Freigabewesen (`ReceiptCartState`). |
|
||||
| **WebOffer / WebReceipt** | Tokenbasiert veröffentlichtes interaktives Angebot (`WebReceiptState`) mit Annahme-/Änderungs-/Ablehnfunktionen. |
|
||||
| **SharedDocument („C-Sign")** | Tokenbasierter Signaturvorgang mit interner Freigaberunde, Signaturerfassung und automatischer Angebots-zu-Auftrags-Wandlung. |
|
||||
| **OnlinePdfDocument** | Zweiter GUID-Signaturkanal für AVV-Verträge und SEPA-Mandate. |
|
||||
| **SelfCare/WebForm** | Formularbaukasten inkl. anonymer öffentlicher Formularseite (`/webform/{Guid}`). |
|
||||
| **WebAccountAccessType** | Portal-Belegsichtbarkeit je Belegart: Never/Always/UseWebAccountRight/OnlyBillable. |
|
||||
| **Nexus-Notification** | Persistente Echtzeit-Benachrichtigung (Ticket-/Termin-/Erwähnungsereignisse). |
|
||||
|
||||
## Plattform/Betrieb
|
||||
|
||||
| Begriff | Definition |
|
||||
|---|---|
|
||||
| **I3D** | Universeller Integer-Surrogatschlüssel (IDENTITY) aller Kern-Entitäten. |
|
||||
| **cvw_-View** | Schreibgeschützte Datenbank-Lesesicht für Listen/Suchen (CQRS-artiges Lesemodell). |
|
||||
| **NamedQuery** | In `NamedQueryPool.xml` versioniertes SQL-Statement mit typisiertem Zugriff. |
|
||||
| **ScriptMethod / DBUpdate** | Nummeriertes C#-Migrationsskript bzw. dessen Journaltabelle (Status 2 = ausgeführt). |
|
||||
| **ManagedBackgroundService** | Basisklasse aller Hintergrunddienste (DB-Flag, Backoff, Lebenszeichen). |
|
||||
| **ExecuteServices** | Konfigurationsschalter „diese Instanz führt die fachlichen Hintergrunddienste aus" (Single-Leader). |
|
||||
| **Connection Manager** | Windows-Werkzeug für Dienstinstallation, Verbindungs-/AD-/2FA-Konfiguration und Sub-Web-Services. |
|
||||
| **WebServiceConfig.xml** | Zentrale Dienstkonfiguration (teil-AES-verschlüsselt, SecretKey für Nexus-Push). |
|
||||
| **Interceptor-Kette** | Priorisierte Querschnittspipeline der RPC-API (Logging→Auth→Telemetrie→Trimming). |
|
||||
| **TrimResponse** | Clientgesteuerte Antwortreduktion (voll / nur I3D / leer). |
|
||||
| **VMA / MailScanner** | „Virtual Mail Assistant": extern laufender Maildienst, der über konfigurierte Workflows Tickets erzeugt. |
|
||||
| **EDI** | Elektronischer Belegaustausch mit Distributoren (Also, Herweck, Komsa, Alltron, OpenTrans, ZUGFeRD) direkt oder über Broker (ITscope, EGIS, Concerto). |
|
||||
| **ITscope / EGIS / COP / Icecat** | Distributions-/Katalogplattformen: Handel+Deals (ITscope), Bestell-Broker (EGIS), SOAP-Katalog (COP), Produktcontent (Icecat). |
|
||||
| **docuFORM** | MPS-Dienst für Druckerzählerstände (OAuth2/PKCE). |
|
||||
| **finAPI** | PSD2-Bankaggregator für Kontoumsätze/Bankverbindungen. |
|
||||
| **RiverDivo / RMM-Schnittstelle** | Eingehende Monitoring-Integration (Riverbird u. a.) mit Access-Key: Tickets, Kundensync, Dokumente. |
|
||||
| **TAPI** | Telefonie-Anbindung über einen dedizierten TapiServer-Client mit SignalR-Ereignisverteilung. |
|
||||
| **Telemetrie-Bucket** | 15-Minuten-Aggregat der Nutzungsmessung (API/KI/Module) für den Hersteller-Upload. |
|
||||
| **DSGVO-Cleanup** | Rechte-/lizenzgeschützter Löschlauf mit standardisiertem Löschvermerk. |
|
||||
| **Hardware-ID** | Geräte-Fingerprint für Lizenzbindung und Telemetrie (im Container per Umgebungsvariable setzbar). |
|
||||
+130
@@ -0,0 +1,130 @@
|
||||
# Hypothesen
|
||||
|
||||
Sammlung aller mit `[HYPOTHESE]` markierten bzw. nicht eindeutig belegbaren Aussagen, jeweils mit offener Frage für die Experten-Validierung (Schritt 7 der RRE-Methodenkette). Sortiert nach Risiko/Relevanz.
|
||||
|
||||
---
|
||||
|
||||
## H-01 — Zweck und Rechtsgrundlage der Hersteller-Telemetrie
|
||||
**Bezug:** StRS-025, SyRS-056, SwRS-067
|
||||
**Belegte Fakten:** Upload personenbeziehbarer Nutzungsdaten (UserID, Hardware-Fingerprint, Methodenname, Lizenzart, CustomerNumber, DatabaseGuid) an „c-entron Office"; Client-Analytics mit Modulnutzungsdauer je Mitarbeiter. [PRIMÄR] HttpTelemetryUploadClient.cs Z.57–141; CentronAnalyticsManager.cs Z.54–127.
|
||||
**Hypothese:** Zweck ist Lizenz-/Produktsteuerung des Herstellers; eine Betreiber-Abschaltmöglichkeit existiert nicht.
|
||||
**Offene Frage:** Vertragliche Grundlage (AVV/EULA)? Ist ein Opt-out vorgesehen oder vorhanden (ggf. außerhalb des Codes, z. B. Firewall-Vorgabe)? Muss das Zielsystem eine Abschaltung/Anonymisierung anbieten?
|
||||
|
||||
## H-02 — Recht CHANGE_VISIBILITY ohne Durchsetzung
|
||||
**Bezug:** SyRS-022/SwRS-031 (Umfeld)
|
||||
**Belegte Fakten:** Recht 20400341 „Sichtbarkeit von Tickets bearbeiten" ist definiert und in CentronRights.md dokumentiert, wird aber weder in UI noch REST geprüft (UI-Checkbox ungefiltert, Endpunkt HelpdeskUpdateIsOnlyInternalVisible ohne Prüfung). [PRIMÄR, Abwesenheitsbefund] UserRightsConst.cs Z.1993; TicketDetailView.xaml Z.378–382; CentronRestService.Helpdesk.cs Z.652–656.
|
||||
**Hypothese:** Die Durchsetzung war beabsichtigt und ist eine vergessene Implementierung (Soll-Anforderung ohne Ist).
|
||||
**Offene Frage:** Soll das Ändern der Intern-Kennzeichnung im Zielsystem rechtepflichtig sein?
|
||||
|
||||
## H-03 — Nur clientseitig geprüfte Rechte (CREATE_HELPDESK_ONLY_OWN_BRANCH, MOVE_HELPDESK_TIMER)
|
||||
**Bezug:** SyRS-020, SyRS-023
|
||||
**Belegte Fakten:** Beide Rechte werden ausschließlich im WPF-Client ausgewertet; die Server-Pfade (HelpdeskBL.CheckUserRigths, MoveTimerToTicket) prüfen sie nicht. [PRIMÄR/SEKUNDÄR] TicketDetailViewModel.cs Z.1586–1588, 3713–3784.
|
||||
**Hypothese:** Serverseitige Durchsetzung war intendiert (Muster der übrigen Rechte) und fehlt.
|
||||
**Offene Frage:** Verbindlichkeit dieser Rechte im Zielsystem?
|
||||
|
||||
## H-04 — Inventur-Abschlussrecht CLOSE_INVENTORY ungenutzt
|
||||
**Bezug:** SwRS-049
|
||||
**Belegte Fakten:** Konstante 20400042 (und PRINT_INVENTORY_STATISTIC 20400046) definiert, keine Prüfstelle. [PRIMÄR, Abwesenheitsbefund] UserRightsConst.cs Z.1786–1799.
|
||||
**Hypothese:** Der Inventurabschluss sollte rechtegeschützt sein.
|
||||
**Offene Frage:** Rechtepflicht des Abschlusses im Zielsystem?
|
||||
|
||||
## H-05 — Vertragsende `null` („nobody knows")
|
||||
**Bezug:** SyRS-025, SwRS-024
|
||||
**Belegte Fakten:** GetContractLastDay liefert bei ContractEnd==null DateTime.MinValue; Kommentar: Verhalten wird nur „wie früher" repliziert, fachlich ungeklärt. [PRIMÄR+KONTEXT] AutomaticFacturaBL.Contracts.cs Z.1343–1353.
|
||||
**Hypothese:** Verträge ohne Enddatum sollten wie automatisch verlängerte behandelt werden (unbegrenzt).
|
||||
**Offene Frage:** Fachlich korrekte Semantik für Verträge ohne Enddatum?
|
||||
|
||||
## H-06 — ActionPrice bewusst keine Verkaufspreisquelle
|
||||
**Bezug:** SyRS-015, SwRS-024
|
||||
**Belegte Fakten:** Aktionspreise erscheinen laut Doku nur im Preisspiegel; die Belegpreisfindung greift nachweislich nicht darauf zu. [KONTEXT] actionprice-system.md; [PRIMÄR Gegenprobe] ReceiptItemPriceBL Z.154–387.
|
||||
**Hypothese:** Informations-/Einkaufsentscheidungswerkzeug, bewusst ohne automatische Preiswirkung.
|
||||
**Offene Frage:** Soll das Zielsystem Aktionspreise weiterhin nur anzeigen oder optional preiswirksam machen?
|
||||
|
||||
## H-07 — Mahnzinsen/-gebühren bewusst nicht implementiert
|
||||
**Bezug:** SyRS-043
|
||||
**Belegte Fakten:** Keine Berechnungslogik auffindbar; DATEV-Mahnfelder werden leer exportiert. [PRIMÄR, Abwesenheitsbefund] DunningBL/DatevAscii Felder 232–254.
|
||||
**Hypothese:** Gebühren-/Zinsberechnung ist außerhalb des Produkts (FiBu/Steuerberater) angesiedelt.
|
||||
**Offene Frage:** Anforderung an das Zielsystem (insb. §288 BGB-Verzugspauschalen)?
|
||||
|
||||
## H-08 — Barbelege: nicht migrierte Delphi-Funktion
|
||||
**Bezug:** StRS-Abgrenzung, SwRS-016
|
||||
**Belegte Fakten:** Datenstrukturen (IsCashAsset, Nummernkreise CashInvoice/CashOffer) existieren; Speichern blockiert mit „Aktuell werden leider noch keine Bar-Belege unterstützt." [PRIMÄR] ReceiptBL.cs Z.3763–3765.
|
||||
**Hypothese:** Kassenfunktion lebt (noch) in der Delphi-Altanwendung; Migration geplant, nicht erfolgt.
|
||||
**Offene Frage:** Ist eine Kassen-/Barverkaufsfunktion (inkl. TSE) Zielscope?
|
||||
|
||||
## H-09 — ebInterface (AT) vorbereitet, aber nicht angebunden
|
||||
**Bezug:** SyRS-040
|
||||
**Belegte Fakten:** Vollständige 4p3-Erzeugung ohne einen einzigen Aufrufer (nur auskommentierte Referenz). [PRIMÄR] EbInterfaceLogic.cs; BBGExport.cs Z.16.
|
||||
**Hypothese:** Für den österreichischen Markt vorbereitet und nie produktiv geschaltet (bzw. abgelöst).
|
||||
**Offene Frage:** AT-E-Rechnung im Zielscope (ebInterface vs. Peppol)?
|
||||
|
||||
## H-10 — Ticket-/Kampagnenprozess-Engine unfertig deaktiviert
|
||||
**Bezug:** SwRS-069
|
||||
**Belegte Fakten:** IsTicketProcessAvailable => Debugger.IsAttached; IsCampaignProcessAvailable => false; vollständige Fachlogik vorhanden. [PRIMÄR] ModuleFeatures.cs Z.26–27.
|
||||
**Hypothese:** Feature wurde zurückgestellt; grafische Ticketprozesse sind eine geplante, nicht abgeschlossene Produktfunktion.
|
||||
**Offene Frage:** Zielscope grafischer Ticket-Workflows?
|
||||
|
||||
## H-11 — Produktions-Wartezustand ausgespart
|
||||
**Bezug:** SyRS-064
|
||||
**Belegte Fakten:** Enum-Wert WaitingForOtherPartsToFinish auskommentiert („ignored for now"); keine Teilmengenrückmeldung. [PRIMÄR] ProductionOrderItemState.cs Z.15–18.
|
||||
**Hypothese:** Abhängigkeitssteuerung zwischen Arbeitsschritten war geplant.
|
||||
**Offene Frage:** Bedarf an Schrittabhängigkeiten/Teilmengen in der Zielfertigung?
|
||||
|
||||
## H-12 — Logistik-Einstellungen ohne Serverdurchsetzung
|
||||
**Bezug:** SyRS-034 (Umfeld), SwRS-052
|
||||
**Belegte Fakten:** IsTargetStorageMandatory, ClearStorageSpace, RebookStorage werden nur im WPF-Client ausgewertet. [PRIMÄR/SEKUNDÄR] LogisticSettingsBL.cs Z.26–112 + Client-ViewModels.
|
||||
**Hypothese:** Serverseitige Durchsetzung ist beabsichtigtes Soll (analog übriger Pflichtregeln).
|
||||
**Offene Frage:** Verbindlichkeitsgrad dieser Einstellungen im Zielsystem?
|
||||
|
||||
## H-13 — TradePool: mandantenübergreifender Marktpreis-Pool
|
||||
**Bezug:** StRS-008 (Umfeld)
|
||||
**Belegte Fakten:** Eigener XML-Import, eigene Benutzerverwaltung (TradeCustomerLogin mit CentronProductId), Min/Max-Spannenberechnung; keine Rechteprüfung; teils toter Code. [PRIMÄR] TradePoolBL.cs.
|
||||
**Hypothese:** Herstellerbetriebener Preisvergleich zwischen c-entron-Kunden; Modul wenig gepflegt/auslaufend.
|
||||
**Offene Frage:** Zielscope TradePool (weiterführen/abkündigen)?
|
||||
|
||||
## H-14 — WebOffer-Ablehnstatus „SendToCustomerDeclined" ungenutzt
|
||||
**Bezug:** SyRS-027
|
||||
**Belegte Fakten:** Enum-Wert 3 mit Kommentar „not used right now"; Acceptance-Seite enthält Platzhaltertexte („Bla bla bla..."). [PRIMÄR/SEKUNDÄR] SharedDocumentState.cs; SharedDocumentAcceptancePage.razor Z.35–36.
|
||||
**Hypothese:** Kundenseitiger Ablehnpfad des Signaturprozesses ist unfertig.
|
||||
**Offene Frage:** Soll der Kunde einen formalen Ablehnweg (mit Begründung) erhalten?
|
||||
|
||||
## H-15 — Filiallandbezug der Steuerwährung/Inlandsermittlung
|
||||
**Bezug:** SyRS-016, SwRS-055
|
||||
**Belegte Fakten:** GetInlandCountry nutzt nur das Standard-Mandantenland (TODO-Kommentar); ZUGFeRD-TaxCurrency stammt immer aus dem Standardland. [PRIMÄR+KONTEXT] CountryBL.cs Z.190–195; InvoiceZugferdBL.cs Z.296–301.
|
||||
**Hypothese:** Für Filialen in anderen Ländern (AT/CH-Niederlassungen) ist die Steuerlogik unvollständig.
|
||||
**Offene Frage:** Muss das Zielsystem filiallandabhängige Inlands-/Währungslogik unterstützen?
|
||||
|
||||
## H-16 — Freigabewesen-Tickets („Status null") als bewusstes Zustandsmodell
|
||||
**Bezug:** SyRS-028, SwRS-034
|
||||
**Belegte Fakten:** Portal-Tickets ohne Freigabe tragen HelpdeskState=null und werden intern ausgeblendet; Kommentar „normal flow of rejecting or accepting". [PRIMÄR] HelpdeskCustomerBL.cs Z.466–493.
|
||||
**Hypothese:** „Kein Status" ist die bewusste Repräsentation „wartet auf Kundenfreigabe" (statt eigener Statuswert).
|
||||
**Offene Frage:** Soll das Zielsystem dafür einen expliziten Status einführen?
|
||||
|
||||
## H-17 — Wertgrenzen/Heuristiken als Fachvorgaben
|
||||
**Bezug:** SyRS-039, SyRS-040, SyRS-042
|
||||
**Belegte Fakten (jeweils PRIMÄR):** FiBu-Differenzabbruch ≥ 2,00; ZUGFeRD-Selbstheilung < 3,00; Zahlungsabgleich ±0,50 (Einzel) und 0,10 (Erledigt-Toleranz); Teilsummen-Limit 20 Rechnungen.
|
||||
**Hypothese:** Diese Konstanten sind gewachsene Praxiswerte, keine dokumentierten Fachvorgaben.
|
||||
**Offene Frage:** Bestätigung/Parametrisierung der Toleranzen im Zielsystem?
|
||||
|
||||
## H-18 — Zwei parallele Signaturstrecken als Übergangszustand
|
||||
**Bezug:** SyRS-027 (Konsolidierung)
|
||||
**Belegte Fakten:** shareddocuments/{Token} (Belege) und contractmanagement?Guid= (AVV/SEPA) mit getrennten Datenmodellen (SharedDocument vs. OnlinePdfDocument, letzteres löscht nach Abschluss). [PRIMÄR] SharedDocumentBL.cs; DsgvoBL.cs Z.116–212.
|
||||
**Hypothese:** Historisch getrennt entstanden; fachlich ein Prozess.
|
||||
**Offene Frage:** Zusammenführung im Zielsystem (ein Signaturdienst)?
|
||||
|
||||
## H-19 — „C-Sign" als Produktname
|
||||
**Bezug:** StRS-004
|
||||
**Belegte Fakten:** Begriff nur in Commit-Messages (89ccfd650d, cf27c00580), nicht im Code. [KONTEXT]
|
||||
**Hypothese:** Marketingname des SharedDocument-/WebOffer-Prozesses.
|
||||
**Offene Frage:** Verbindliche Produkt-/Feature-Nomenklatur fürs Glossar.
|
||||
|
||||
## H-20 — SAP-Export als Individualentwicklung
|
||||
**Bezug:** SyRS-039
|
||||
**Belegte Fakten:** SAP-Exportformat nur für Lizenz-Kundennummer 13293 („marienhaus") bzw. intern sichtbar. [PRIMÄR] BookKeepingExportTypes.cs Z.62–84.
|
||||
**Hypothese:** Kundenindividuelle Sonderlösung, nicht Produktstandard.
|
||||
**Offene Frage:** Übernahme in das Zielsystem oder Sondervertrag?
|
||||
|
||||
---
|
||||
|
||||
### Hinweis zur risikobasierten Priorisierung
|
||||
Alle Anforderungen der Kategorien Sicherheit, Abrechnung/Fakturierung und Berechtigungen in StRS/SyRS/SwRS führen mindestens einen PRIMÄR-Beleg und sind daher **nicht** als HYPOTHESE eingestuft; die vorstehenden Hypothesen betreffen Zweck-/Intentions- oder Abwesenheitsfragen, nicht die belegten Regeln selbst.
|
||||
+583
@@ -0,0 +1,583 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
|
||||
**System:** c-entron ERP-Suite (c-entron.NET WPF-Client, c-entron Web-Service, c-entron Nexus Web)
|
||||
**Erstellt durch:** Reverse Requirements Engineering (statische Analyse der Codebasis, Stand Commit 79c1142f48, 2026-08-25)
|
||||
**Normbezug:** ISO/IEC/IEEE 29148:2018 (Stakeholder-Ebene)
|
||||
**Hinweis:** Alle Anforderungen sind aus Artefakten der Codebasis rückgewonnen ("Soll" = rekonstruiertes fachliches Soll, das das Ist-System implementiert). Jede Anforderung führt Belege mit Klassifikation `PRIMÄR`/`SEKUNDÄR`/`KONTEXT`. Nicht eindeutig belegbare Aussagen sind mit `[HYPOTHESE]` markiert.
|
||||
|
||||
---
|
||||
|
||||
## 1. Zweck und Systemkontext
|
||||
|
||||
Die Codebasis implementiert ein ERP-System für IT-Systemhäuser und Managed Service Provider im deutschsprachigen Markt: Handelsgeschäft (Angebot bis Gutschrift, Distributorenanbindung), Servicegeschäft (Tickets, Zeiterfassung, Verträge/wiederkehrende Abrechnung, RMA/Werkstatt) und Finanzprozesse (FiBu-Export, E-Rechnung, SEPA, Zahlungsabgleich, Mahnwesen), ergänzt um ein Kundenportal (Nexus) und ein Web-Shop-/Freigabemodul (WebCart).
|
||||
|
||||
### Stakeholder/Akteure (aus Artefakten abgeleitet)
|
||||
|
||||
| Akteur | Beleg |
|
||||
|---|---|
|
||||
| Interner Mitarbeiter (AppUser, verknüpft mit Personalstamm `Personal`) | `Centron.Entities\Entities\Administration\AppUser.cs` (Employee-Referenz) [PRIMÄR] |
|
||||
| Administrator (Gruppe „Administratoren", I3D=6) | `Centron.BL\Administration\Rights\AppRightsBL.cs` Z.348–374 [PRIMÄR] |
|
||||
| Endkunden-Benutzer (WebAccount am Ansprechpartner) | `Centron.Entities\Entities\Administration\Logins\WebAccount.cs` Z.6–35 [PRIMÄR] |
|
||||
| Kunden-Administrator (Web-Recht CUSTOMERADMINISTRATOR, Self-Administration) | `src\nexus\CentronNexus\WebCart\WebCartAdminPage.razor` Z.3–4 [PRIMÄR] |
|
||||
| Prüfer/Besteller im Kunden-Freigabewesen | `Centron.Interfaces\Sales\Receipts\ReceiptCartState.cs` [PRIMÄR] |
|
||||
| Externer Signatur-Empfänger (tokenbasiert, ohne Login) | `Centron.BL\Administration\FileManagement\SharedDocumentBL.cs` Z.116–157 [PRIMÄR] |
|
||||
| Betreiber/IT-Administrator (Connection Manager, WebServiceConfig) | `src\webservice\c-entron.misc.ConnectionManager\*` [PRIMÄR] |
|
||||
| Hersteller (c-entron/NEXOWARE; Lizenzserver „c-entron Office", Telemetrie-Empfänger) | `src\webservice\Centron.Host\AspNetCore\Telemetry\HttpTelemetryUploadClient.cs` Z.57–74 [PRIMÄR] |
|
||||
| Fremdsysteme (Distributoren-EDI, RMM/Riverbird, DocBee, TANSS, ElectronicSales, finAPI, GLS/Shipcloud, docuFORM, DATEV) | `src\apis\*`, `Centron.BL\EDI\*`, `Centron.BL\RiverDivo\*` [PRIMÄR] |
|
||||
|
||||
---
|
||||
|
||||
## 2. Anforderungen
|
||||
|
||||
```
|
||||
ID: StRS-001
|
||||
Titel: Zielsystem für IT-Systemhaus-/MSP-Geschäft
|
||||
Ebene: StRS
|
||||
Typ: funktional (Geschäftsziel)
|
||||
Akteur: Systemhaus (Organisation)
|
||||
Vorbedingung: –
|
||||
Fakt: Die Codebasis vereint Handelsbelegwesen (Angebot/Auftrag/Lieferschein/Rechnung/Gutschrift, EDI-Distributoren), Servicegeschäft (Helpdesk-Tickets hlpdsk_requests, Zeiterfassung hlpdsk_timer, Verträge mit RMM-Mengenabrechnung), RMA/Werkstatt und Finanzprozesse in einer Lösung; Modul- und Lizenzkatalog (159 Lizenz-GUIDs, 48 ApplicationKinds) adressiert Systemhaus-Produkte (ServiceBoard, RMAWorkshop, OnlineBanking_FinApi, PLM …).
|
||||
Aussage: Das System soll den durchgängigen Geschäftsbetrieb eines IT-Systemhauses/MSP abdecken: Vertrieb und Handel, Serviceerbringung mit Abrechnung, Reparaturabwicklung sowie vorbereitende Finanzbuchhaltung.
|
||||
Ergebnis: Alle Kerngeschäftsprozesse laufen in einem integrierten System mit gemeinsamer Datenbasis (eine MSSQL-Datenbank).
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.Interfaces\CentronObjectKindNumeric.cs (Belegarten inkl. Helpdesk=10, Contract=22, RMA) – Begründung: Der zentrale Objektkatalog kodiert Handels-, Service- und Werkstattobjekte gleichrangig.
|
||||
- [PRIMÄR] src\backend\Centron.Interfaces\Administration\Logins\LicenseGuids.cs (159 Modul-Lizenzen) – Begründung: Produktzuschnitt und Zielgruppe sind im Lizenzkatalog ablesbar.
|
||||
- [KONTEXT] README.md (WebCart „for the customers of our customers") – Begründung: bestätigt B2B2C-Systemhaus-Kontext.
|
||||
Prüfidee: Walkthrough: Ein Vorgang Angebot→Auftrag→Lieferschein→Rechnung→FiBu-Export sowie Ticket→Zeit→Abrechnung ist ohne Systemwechsel durchführbar.
|
||||
Tracelinks: SyRS-001, SyRS-013, SyRS-020, SyRS-025, SyRS-035, SyRS-039
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-002
|
||||
Titel: Getrennte Identitäten für Mitarbeiter und Endkunden
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Interner Mitarbeiter; Endkunden-Benutzer (WebAccount)
|
||||
Vorbedingung: –
|
||||
Fakt: Es existieren zwei getrennte Identitätstypen mit eigenen Entitäten (AppUser in Sichbenu; WebAccount am Ansprechpartner), eigenen Rechtesystemen (UserRightsConst vs. WebAccountRightsConst) und getrennten Login-Pfaden (/auth vs. /auth/customer); Benutzernamen teilen sich einen gemeinsamen Namensraum.
|
||||
Aussage: Das System soll interne Mitarbeiter und externe Kundenbenutzer als getrennte Identitätstypen mit jeweils eigenem Berechtigungsmodell führen; ein Kundenbenutzer ist stets an einen Ansprechpartner eines Geschäftspartners gebunden.
|
||||
Ergebnis: Kein Kundenbenutzer kann interne Funktionen nutzen; Mitarbeiter und Kundenkonten sind organisatorisch getrennt administrierbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.Entities\Entities\Administration\Logins\WebAccount.cs Z.6–35 – Begründung: eigener Identitätstyp mit Kunden-/Kontaktbindung und eigener Rechteliste.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Logins\WebAccountBL.cs Z.637–650 (CheckDuplicateUsername gegen AppUser.Name) – Begründung: gemeinsamer Namensraum ist durchgesetzt.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs Z.666–691 (HasWebAccountRight) – Begründung: getrenntes Rechtesystem.
|
||||
Prüfidee: Test: WebAccount-Login gegen eine interne Funktion (z. B. Belegsuche) liefert Ablehnung („Web-Benutzer haben keine Berechtigung Belege einzusehen“) bzw. nur portalzulässige Daten.
|
||||
Tracelinks: SyRS-006, SyRS-009, SyRS-010, SyRS-028
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-003
|
||||
Titel: Durchgängiges, nachvollziehbares Belegwesen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertrieb/Innendienst
|
||||
Vorbedingung: Kundenstammsatz vorhanden
|
||||
Fakt: Der Belegfluss ist als fest verdrahteter Graph implementiert (Angebot→{Auftrag,LS,Rechnung}; Auftrag→{LS,Rechnung,Vertrag}; LS→{Abholschein,Rechnung}; Rechnung→{Gutschrift}; Vertrag→{Rechnung}); jede Änderung erzeugt eine neue Belegversion mit Snapshot; Restmengenlogik schließt Belege automatisch.
|
||||
Aussage: Das System soll den Verkaufsprozess als lückenlose Belegkette mit kontrollierter Weiterverarbeitung, Versionierung jeder Änderung und automatischem Abschluss vollständig verarbeiteter Belege abbilden.
|
||||
Ergebnis: Jeder Folgebeleg ist auf seinen Ursprung rückführbar; Mengen können nicht unbemerkt doppelt oder über den Ursprung hinaus verarbeitet werden.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Offers\OfferSpecificLogic.cs Z.314 u. a. (CanBeForwardedInto je Belegart) – Begründung: erlaubter Belegfluss ist Code-Matrix.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs Z.2462–2860 (ValidateReceiptForwarding) – Begründung: Weiterverarbeitung wird serverseitig validiert.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs Z.3081–3141 (CreateNewVersion) – Begründung: Versionierungspflicht.
|
||||
Prüfidee: Testfälle: (a) unzulässige Weiterverarbeitung (z. B. Gutschrift→Auftrag) wird abgewiesen; (b) Reduktion einer bereits weiterverarbeiteten Menge wird abgewiesen; (c) vollständige Verarbeitung schließt den Beleg automatisch.
|
||||
Tracelinks: SyRS-013, SyRS-014, SyRS-015, SyRS-017, SyRS-018, SyRS-038
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-004
|
||||
Titel: Online-Angebotsannahme mit elektronischer Signatur und interner Freigabe
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Kunde (tokenbasiert), Vertriebsmitarbeiter, interne Freigeber
|
||||
Vorbedingung: Angebot existiert; Nexus-URL und Signaturdokument konfiguriert
|
||||
Fakt: Der Prozess WebOffer (tokenbasiertes interaktives Angebot mit Mengen-/Positionsartänderung) mündet in SharedDocument-Signatur (Zeichnen/Tippen/Hochladen); vorgelagert ist eine Mitarbeiter-Freigaberunde (Acceptance, alle müssen zustimmen); die Kundensignatur eines Angebots wandelt es automatisch in einen Auftrag und der Button trägt die Beschriftung „Kostenpflichtig bestellen".
|
||||
Aussage: Das System soll Angebote elektronisch zur Annahme bereitstellen, optional eine interne Mehr-Augen-Freigabe vor dem Kundenversand erzwingen, die rechtssichere Annahme (Buttonlösung, signiertes PDF-Gesamtdokument) protokollieren und aus der Annahme automatisch den Auftrag inklusive Folgeprozessen erzeugen.
|
||||
Ergebnis: Angenommene Angebote werden ohne Medienbruch zu Aufträgen; der Signaturvorgang ist tokenbasiert, befristet, einmalig und vollständig protokolliert (SharedDocumentLog).
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\FileManagement\SharedDocumentBL.cs Z.496–678 (SignSharedDocument inkl. ForwardOfferToOrderAndSave) – Begründung: Annahme→Auftrag ist durchgesetzte Logik.
|
||||
- [PRIMÄR] src\nexus\CentronNexus\Office\SharedDocumentSignPage.razor Z.225 (ButtonText „Kostenpflichtig bestellen" bei OfferClass) – Begründung: Buttonlösung ist implementiert.
|
||||
- [PRIMÄR] src\webservice\Centron.WebServices.Core\Entities\Administration\FileManagement\SharedDocuments\SharedDocumentState.cs Z.6–21 – Begründung: Freigabe- und Signaturzustände.
|
||||
- [KONTEXT] Commit 89ccfd650d „C-Sign (WebOffer & Acceptance)" – Begründung: Produktname des Prozesses.
|
||||
Prüfidee: E2E-Test: Angebot versenden → ein Freigeber lehnt ab → kein Kundenversand; alle stimmen zu → Kunde signiert → Auftrag existiert, signiertes PDF „_Signed.pdf" liegt im Belegverzeichnis, Log-Einträge vorhanden.
|
||||
Tracelinks: SyRS-027
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-005
|
||||
Titel: Servicegeschäft über Tickets mit SLA-Steuerung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Servicemitarbeiter, Dispatcher, Kunde
|
||||
Vorbedingung: Kunde vorhanden
|
||||
Fakt: Tickets besitzen konfigurierbare Status, Prioritäten mit Fälligkeitsableitung (DueDateDelayInHours unter Berücksichtigung von Geschäftszeiten/Wochenenden), ein dreistufiges zeitgesteuertes Eskalationsmodell mit Empfängerkreisen sowie Kategorien/Typen, Checklisten, Vorlagen (C-FLOW/TicketPattern) und automatische Erzeugung (Taskmanagement, Belege, RMM, MailScanner, Portal).
|
||||
Aussage: Das System soll Serviceanfragen als Tickets mit kundenkonfigurierbarem Lebenszyklus verwalten, Reaktions-/Fälligkeitstermine aus Prioritäten und Arbeitszeiten ableiten und überfällige Tickets stufenweise eskalieren.
|
||||
Ergebnis: Fälligkeit und Eskalationsstufe jedes Tickets sind systemseitig berechnet und nachvollziehbar; Ticketentstehung ist aus mehreren Kanälen möglich.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs Z.786–827 (GetDueDateFromPriority) – Begründung: SLA-Terminableitung ist Code.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\Escalation\EscalationBL.cs Z.300–426, 913–929 – Begründung: dreistufige Eskalation wird durchgesetzt und persistiert.
|
||||
- [PRIMÄR] src\backend\Centron.Entities\Entities\CustomerArea\Support\HelpdeskState.cs – Begründung: Status als konfigurierbare Stammdaten.
|
||||
Prüfidee: Test: Priorität mit 4h-Frist, Büroschluss 17:00 → Ticket um 16:00 erzeugt → Fälligkeit am Folgearbeitstag; Eskalationslauf setzt Stufe 1..3 mit Benachrichtigung.
|
||||
Tracelinks: SyRS-020, SyRS-021, SyRS-022, SyRS-051, SyRS-068
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-006
|
||||
Titel: Zeiterfassung mit revisionssicherer Leistungsabrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Servicemitarbeiter, Abrechner, Kunde (Unterschrift)
|
||||
Vorbedingung: Ticket vorhanden; Mitarbeiter besitzt Mitarbeiterartikel
|
||||
Fakt: Zeiten (HelpdeskTimer) referenzieren nach Abrechnung die Belegposition (Order/DeliveryList/InvoiceAssetItemI3D) und sind dann weder änder-, lösch- noch verschiebbar; Kundenunterschriften auf Zeiten sind einmalig und nur mit Sonderrecht entfernbar (mit Protokoll); die Abrechnung (Timer-Billing) schließt geplante und bereits zugeordnete Zeiten aus; MyDay rekonstruiert Arbeitstage aus Fremdquellen und erzwingt abteilungsweise einen Tagesabschluss mit Eskalation an Teamleiter.
|
||||
Aussage: Das System soll erbrachte Servicezeiten je Ticket erfassen, gegen Doppel- und Nachtragsmanipulation nach Abrechnung sperren, Kundenquittierung per Unterschrift unterstützen und die vollständige Tageserfassung organisatorisch durchsetzen.
|
||||
Ergebnis: Abgerechnete Zeiten sind eingefroren; jede Zeit ist höchstens einmal fakturiert; Erfassungslücken werden erkannt und eskaliert.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs Z.327–346, 591–608 – Begründung: Abrechnungs-Sperren sind mehrfach durchgesetzt.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskTimerSignatureBL.cs Z.132–206 – Begründung: Signatur- und Löschregeln mit Protokoll.
|
||||
- [PRIMÄR] src\backend\Centron.BL\MyDay\MyDayNotificationsBL.cs Z.115–231 – Begründung: Tagesabschluss-Pflicht mit Eskalation.
|
||||
Prüfidee: Test: Zeit einer fakturierten Position löschen/verschieben → Ablehnung; Timer-Billing derselben Zeit zweimal → zweiter Lauf enthält sie nicht.
|
||||
Tracelinks: SyRS-023, SyRS-024, SyRS-066
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-007
|
||||
Titel: Vertragsgeschäft mit wiederkehrender, mengenbasierter Abrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertragsverwalter, Abrechnungslauf (System), RMM-System
|
||||
Vorbedingung: Vertrag mit Abrechnungsparametern
|
||||
Fakt: Verträge werden automatisch (vor-/nachschüssig, Intervalle mit Proration und Nachholung versäumter Perioden), nach Bedarf (Click/Kontingent) oder manuell abgerechnet; RMM-gemessene Mengen werden mit Vertragsmengen (Fix/Min/Max) verrechnet; bei nicht erreichbarem RMM-Dienst wird die Rechnungserstellung abgebrochen; Stunden-/Geldkontingente werden über Ausgleichspositionen verbraucht und bei Rücknahmebelegen zurückgerollt; nur die jeweils letzte Vertragsrechnung ist stornierbar.
|
||||
Aussage: Das System soll wiederkehrende Leistungen vertragsbasiert automatisch fakturieren, dabei gemessene Nutzungsmengen (RMM, Zählerstände) mit vertraglichen Unter-/Obergrenzen verrechnen und die Abrechnungshistorie strikt sequenziell (LIFO-Storno) halten.
|
||||
Ergebnis: Vertragsrechnungen entstehen ohne manuelle Positionierung; Nutzungsdaten fehlerhafter Quellen führen zu keiner (statt einer falschen) Rechnung.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\CustomerAssets\AutomaticFactura\AutomaticFacturaBL.Contracts.cs Z.1885–2019 (InvoicePeriodCalculate) – Begründung: Intervall-/Prorationslogik.
|
||||
- [PRIMÄR] src\backend\Centron.Entities\Entities\Sales\CustomerAssets\Contracts\ContractArticleReferenzes.cs Z.27–39 – Begründung: Min-/Max-/Fixmengenregel.
|
||||
- [PRIMÄR] src\backend\Centron.BL\WebServices\Sales\CustomerAssets\AutomaticFactura\AutomaticFacturaWebServiceBL.cs Z.721–823 (RMMServiceUnavailableException) – Begründung: Fail-Fast-Abrechnungsschutz.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\ReceiptInvoiceBL.cs Z.236–249 – Begründung: LIFO-Storno der Vertragsrechnungen.
|
||||
Prüfidee: Test: Vertrag monatlich, 2 Monate nicht abgerechnet → ein Lauf erzeugt eine Rechnung über 2 Intervalle; RMM-Ausfall → Lauf bricht für diesen Vertrag mit Fehler ab.
|
||||
Tracelinks: SyRS-025, SyRS-047, SyRS-048
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-008
|
||||
Titel: Einkauf mit Distributorenanbindung und Bedarfsermittlung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Einkäufer; Distributoren (EDI/API)
|
||||
Vorbedingung: Lieferanten-/Artikelstamm gepflegt
|
||||
Fakt: Bestellungen entstehen u. a. aus einem Bestellvorschlag (Bedarf = Auftragsbedarf + Mindestbestand − Bestand − Zulauf, mit ABC-Lieferantenlogik und Lieferantenkonditionen); Bestellungen gehen elektronisch an Distributoren (OpenTrans u. a., direkt oder über ITscope/EGIS/Concerto); Auftragsbestätigungen, Lieferavis und Rechnungen der Distributoren werden automatisch importiert (30-Minuten-Batch, Duplikat- und Fehlerdatei-Schutz); Katalog-/Preis-/Verfügbarkeitsdaten kommen aus ITscope/EGIS/COP/Importlisten, Produktcontent aus Icecat.
|
||||
Aussage: Das System soll den Einkaufsprozess von der automatischen Bedarfsermittlung über die elektronische Bestellung bis zum automatisierten Import der Distributoren-Belege unterstützen.
|
||||
Ergebnis: Bestellungen und Wareneingänge entstehen weitgehend ohne manuelle Doppelerfassung; auftragsbezogener Einkauf schreibt Bestell-/Buchungsmengen in den Kundenauftrag zurück.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Purchasing\OrderSuggestionList\OrderSuggestionListBL.cs Z.87–483 – Begründung: Bedarfsformel implementiert.
|
||||
- [PRIMÄR] src\backend\Centron.BL\EDI\SupplierEDI\SupplierEdiBL.cs Z.1364–1414 – Begründung: automatischer Belegimport je Distributorformat.
|
||||
- [PRIMÄR] src\backend\Centron.BL\EDI\EDIDispatcherBL.cs Z.56–288 – Begründung: elektronischer Bestellversand inkl. Broker.
|
||||
Prüfidee: Test: Auftrag mit Bestellbedarf → Bestellvorschlag enthält Position mit korrekter Menge; simulierte Distributor-Antwortdatei erzeugt Wareneingangsbeleg genau einmal.
|
||||
Tracelinks: SyRS-029, SyRS-030, SyRS-036, SyRS-037
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-009
|
||||
Titel: Bestandsführung mit Seriennummern-Rückverfolgbarkeit
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Lagerist, Logistik, Inventurteam
|
||||
Vorbedingung: Artikel-/Lagerstamm gepflegt
|
||||
Fakt: Seriennummernpflichtige Artikel werden bestandsseitig über die Anzahl ihrer Seriennummern in definierten Zuständen geführt (statt Mengenzähler); jede Seriennummer ist exklusiv genau einem aktiven Beleg zugeordnet und trägt Zustands- und Historienmodell (25 Zustände, BarcodeHistory, ARTIKlog); Warenausgang bucht beim Lieferschein, Rücknahmen beim Abholschein/Gutschrift; Inventur korrigiert Bestände lagerweise mit Verlustkennzeichnung nicht gescannter Seriennummern; Umbuchungen sind rechte- und protokollpflichtig, Negativbuchungen im Warenausgang genehmigungspflichtig (Vier-Augen-Fremdanmeldung).
|
||||
Aussage: Das System soll Lagerbestände mengen- und seriennummerngenau führen, jede physische Einheit lückenlos über ihren Lebenszyklus verfolgen und Bestandskorrekturen (Inventur, Umbuchung, Negativbuchung) kontrolliert und auditierbar abwickeln.
|
||||
Ergebnis: Zu jeder Seriennummer ist Standort/Belegbindung/Historie jederzeit ermittelbar; Bestandsabweichungen entstehen nur über protokollierte Vorgänge.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Scripts\ScriptMethods\Scripts\ScriptMethod11482.cs Z.25–54 (cvw_ArticleCount/cvw_BarcodeCount) – Begründung: SN-basierte Bestandsdefinition ist DB-seitig verankert.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptBarcodeBL.cs Z.554–879 – Begründung: Exklusivbindung SN↔Belegposition.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryBL.cs Z.797–944 (CloseStorages) – Begründung: Inventurabschluss als kontrollierte Bestandskorrektur.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptArticleBookingBL.cs Z.357–424 – Begründung: Vier-Augen-Regel Negativbuchung.
|
||||
Prüfidee: Test: SN in Lieferschein → zweite Zuordnung in anderem Beleg wird abgewiesen; Inventur ohne Scan einer SN → Status „Inventurverlust"; Umbuchung ohne Recht TRANSFER_STOCK → Ablehnung.
|
||||
Tracelinks: SyRS-031, SyRS-032, SyRS-033, SyRS-034
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-010
|
||||
Titel: RMA-/Werkstattprozess für Eigen-, Kunden- und Fremdware
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Service-Annahme, Werkstatt, Lieferant, Kunde
|
||||
Vorbedingung: RMA-Lager konfiguriert
|
||||
Fakt: RMA-Fälle sind zwingend an ein Ticket gebunden, unterscheiden Eigen-/Kunden-/Fremdware mit unterschiedlicher Bestands-/Belegbehandlung, durchlaufen einen 19-stufigen Positionsstatus (Rücksendung, Vorabtausch, Leihgerät, Gutschrift, Verschrottung …) mit LIFO-Storno und dürfen erst geschlossen werden, wenn für jede Kundenposition ein Ausgangsbeleg (Lieferschein oder Gutschrift) existiert; Tausch-Seriennummern werden in die Ursprungsrechnung rückgebucht (Gewährleistungsnachweis).
|
||||
Aussage: Das System soll Reklamations- und Werkstattfälle vollständig abbilden – von der Annahme (inkl. Fremdware ohne eigene Beleghistorie) über Lieferantenrücksendung und Ersatzlieferung bis zu Kundenbeleg und Abschluss – und dabei Bestands-, Seriennummern- und Gewährleistungsdaten konsistent halten.
|
||||
Ergebnis: Kein RMA-Abschluss ohne Kundenbeleg; jede Werkstattaktion ist über Nummernkreise (RMA/Rücksendung/Reparatureingang) und Historien nachvollziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\CustomerArea\RmaBL.cs Z.352–353, 932–1258, 1916–1996 – Begründung: Ticketpflicht, Statusfluss, Lagerlogik je RMA-Art.
|
||||
- [PRIMÄR] src\centron\Centron.WPF.UI\Modules\Helpdesk\TicketDetails\Rma\TicketRmaViewModel.cs Z.855–921 (CanClose/CanStornoHistory) – Begründung: Abschluss-/Stornoregeln.
|
||||
- [PRIMÄR] src\backend\Centron.BL\CustomerArea\RmaBL.cs Z.142–183 (RebookForChange) – Begründung: Gewährleistungs-Rückbuchung der Tausch-SN.
|
||||
Prüfidee: Test: Kunden-RMA ohne Lieferschein/Gutschrift schließen → Ablehnung; Fremdware-Position erzeugt neue SN im RMA-Kundenlager; Storno eines Schritts mit Folgeschritt → Ablehnung.
|
||||
Tracelinks: SyRS-035
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-011
|
||||
Titel: Vorbereitende Finanzbuchhaltung und Zahlungsverkehr
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Buchhaltung, Steuerberater/DATEV, Bank
|
||||
Vorbedingung: Kontenrahmen/Steuersätze gepflegt
|
||||
Fakt: Belege werden in 13 FiBu-Formate exportiert (führend DATEV ASCII EXTF 700 und DATEV-XML-Online) mit Splitbuchungen je Konto/Steuerschlüssel/Kostenstelle; Zahlungsrückläufe werden als OPOS-Import verarbeitet; SEPA-Lastschriften (bis pain.008.001.08) mit vollständiger Mandatsverwaltung; Bankumsätze via finAPI mit dreistufigem automatischem Zahlungsabgleich; Mahnwesen mit 3 Stufen und Mahnsperren; exportierte Rechnungen sind storno-gesperrt.
|
||||
Aussage: Das System soll die vorbereitende Buchhaltung vollständig bedienen: steuerlich korrekte Buchungssatz-Erzeugung für Fremd-FiBu-Systeme, Lastschrifteinzug mit SEPA-Mandaten, automatischen Zahlungseingangsabgleich und gestuftes Mahnwesen.
|
||||
Ergebnis: Rechnungswesen-Daten fließen ohne Doppelerfassung an die FiBu; offene Posten werden systemgestützt ausgeglichen und gemahnt.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.Gateway\DataExchange\BookKeeping\DatevAscii\BookKeepingExportDatevAscii.cs Z.551–1033 – Begründung: DATEV-Buchungssatz vollständig implementiert.
|
||||
- [PRIMÄR] src\backend\Centron.Gateway\DataExchange\PaymentTransactions\Sepa\SepaFileGeneratorV2.cs Z.32–364 – Begründung: SEPA pain.008.001.08 mit Mandatslogik.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingAccountTransactionsBL.cs Z.581–1086 – Begründung: automatischer Zahlungsabgleich.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs Z.200–315 – Begründung: 3-stufiges Mahnwesen.
|
||||
Prüfidee: Abnahmetest je Teilprozess: DATEV-Datei gegen DATEV-Prüfprogramm; SEPA-Datei gegen Bank-Validator; Zahlungsabgleich mit exaktem/abweichendem Betrag (<0,50 €) und Sammelzahlung.
|
||||
Tracelinks: SyRS-016, SyRS-019, SyRS-039, SyRS-040, SyRS-041, SyRS-042, SyRS-043
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-012
|
||||
Titel: Kundenportal mit Self-Service und Beschaffungs-Freigabewesen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Endkunden-Benutzer, Kunden-Administrator
|
||||
Vorbedingung: WebAccount vorhanden; Lizenz (CentronNexus/WebCart2)
|
||||
Fakt: Das Nexus-Kundenportal bietet Ticketanlage/-einsicht (inkl. optionalem kundeninternem Freigabewesen für neue Tickets), Beleg-/Vertragseinsicht (pro Belegart konfigurierbar), Dokumente, Formulare und einen Shop (WebCart), dessen Artikelumfang ausschließlich aus den Kunden-Sonderpreisen stammt und dessen Bestellungen ein zweistufiges Prüfer/Besteller-Freigabewesen durchlaufen; Kunden-Administratoren verwalten Portalbenutzer und deren Rechte selbst; Mandantentrennung ist serverseitig in den Abfragen erzwungen.
|
||||
Aussage: Das System soll Endkunden einen abgesicherten Selbstbedienungszugang zu ihren Service- und Handelsvorgängen bieten, einschließlich eines kundenindividuellen Beschaffungskatalogs mit unternehmensinternem Genehmigungsworkflow und delegierter Benutzerverwaltung.
|
||||
Ergebnis: Kunden sehen ausschließlich eigene Daten; Shop-Bestellungen erreichen das ERP erst nach kundeninterner Freigabe als regulärer Auftrag.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs Z.128–241 (Sonderpreis-Katalog) – Begründung: Katalogumfang ist durchgesetzt.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartReleaseSystemBL.cs Z.65–283 – Begründung: Freigabewesen serverseitig.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskSearchBL.cs Z.536–565 – Begründung: serverseitige Mandantentrennung im Portal.
|
||||
- [PRIMÄR] src\backend\Centron.Interfaces\CustomerPortal\WebAccountAccessType.cs – Begründung: konfigurierbare Belegsichtbarkeit.
|
||||
Prüfidee: Test: WebAccount ohne Sonderpreise sieht leeren Shop; Bestellfreigabe ohne WEBRIGHT_WEBCART2_ORDER_CART → Ablehnung; Ticket eines fremden Kunden per ID abrufen → „nicht gefunden".
|
||||
Tracelinks: SyRS-026, SyRS-028, SyRS-010
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-013
|
||||
Titel: Feingranulares Berechtigungssystem mit einschränkenden Rechten
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Akteur: Administrator, alle Benutzer
|
||||
Vorbedingung: Benutzer in Rechtegruppen
|
||||
Fakt: Rechte sind hierarchische Integer-Konstanten (~2.800 Zeilen UserRightsConst), werden ausschließlich über Gruppen zugewiesen (Sichmemb/Sichtrus) und serverseitig geprüft – auch als Datenfilter in Abfragen (nur eigene Kunden/Tickets, nur eigene Filiale, Vertriebsgebiete); es existiert die dokumentierte Sonderklasse „restricting rights" (Besitz schränkt ein); Rechtevergaben werden vollständig auditiert (AppRightLog); die Admin-Gruppe ist gegen Löschung/Fehlkonfiguration geschützt.
|
||||
Aussage: Das System soll Funktions- und Datenzugriff rollenbasiert steuern, wobei Datenrestriktionen (eigene Datensätze, eigene Filiale, Vertriebsgebiet) serverseitig in den Abfragen und nicht nur in der Oberfläche wirken, und jede Änderung an Berechtigungen revisionssicher protokollieren.
|
||||
Ergebnis: Zugriffsentscheidungen sind clientunabhängig durchgesetzt und nachvollziehbar; ein Aussperren aller Administratoren ist verhindert.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs Z.644–664, 762–857 – Begründung: zentrale Prüfung + Audit.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Accounts\AccountSearchBL.cs Z.331–344; src\backend\Centron.BL\Sales\Support\HelpdeskSearchBL.cs Z.324–391 – Begründung: Query-Level-Durchsetzung.
|
||||
- [KONTEXT] CentronRights.md (Konzept „restricting right") – Begründung: dokumentierte invertierte Semantik.
|
||||
Prüfidee: Test je restriktivem Recht: Nutzer mit SHOW_HELPDESK_ONLY_OWN erhält per API (nicht nur UI) ausschließlich eigene Tickets.
|
||||
Tracelinks: SyRS-006, SyRS-007, SyRS-008, SyRS-009, SyRS-010, SyRS-011, SyRS-055
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-014
|
||||
Titel: Modul- und Concurrent-User-Lizenzierung
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Produktsteuerung)
|
||||
Akteur: Hersteller, Betreiber
|
||||
Vorbedingung: Signierte Lizenzdatei
|
||||
Fakt: 159 Lizenz-GUIDs steuern Modul-Freischaltung serverseitig in der BL (nicht nur UI); Anmeldelizenzen werden concurrent gegen aktive Session-Tickets gezählt (PerUserAndPerMachine bzw. PerUser); die Lizenz ist kryptographisch signiert, hardwaregebunden und harte Startvoraussetzung des Web-Service; Modulsichtbarkeit im Client = Recht × Lizenz (ModuleRegistration).
|
||||
Aussage: Das System soll Funktionsumfang und Nutzerzahl über signierte, hardwaregebundene Lizenzen steuern; Lizenzprüfungen müssen serverseitig erfolgen und die gleichzeitige Nutzung begrenzen.
|
||||
Ergebnis: Nicht lizenzierte Module sind auch per API nicht nutzbar; Überschreitung der Nutzerzahl verhindert weitere Anmeldungen (LicenseMaximumReached).
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs Z.219–302 – Begründung: Start-Gate + Concurrent-Zählung.
|
||||
- [PRIMÄR] src\backend\Centron.DAO\Repositories\Administration\Logins\TicketRepository.cs Z.95–119 – Begründung: Zählmodi.
|
||||
- [PRIMÄR] src\centron\Centron.WPF.UI\Modules\ModuleRegistration.cs Z.486–889 – Begründung: Recht×Lizenz-Freischaltmuster.
|
||||
Prüfidee: Test: Lizenz-Count n, n+1 parallele Logins → letzter abgelehnt; BL-Aufruf eines unlizenzierten Moduls → LicenseNotFound.
|
||||
Tracelinks: SyRS-012, SyRS-007
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-015
|
||||
Titel: Mehrfilial- und Mehrfirmenbetrieb
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Organisation mit Filialen/Mandanten
|
||||
Vorbedingung: Filial-/Mandantenstamm
|
||||
Fakt: Filiale (Filiale) und Mandant (Mandator) sind Querschnittsdimensionen: Nummernkreise je Filiale/Mandant, Belegrechte „nur eigene Filiale" serverseitig erzwungen, Management-Info/Bankauszüge filialbeschränkbar, Buchhaltungs-/Bankdaten je Mandant; echte Mandantentrennung mehrerer Firmen erfolgt über getrennte Datenbanken/Sub-Web-Services (Connection Manager).
|
||||
Aussage: Das System soll den Betrieb mehrerer Filialen innerhalb einer Firma (gemeinsame Datenbank, filialabhängige Nummern/Rechte/Auswertungen) sowie mehrerer Firmen (getrennte Datenbanken mit je eigenem Dienst) unterstützen.
|
||||
Ergebnis: Filialbenutzer arbeiten nur in ihrem Filialkontext; getrennte Firmen teilen keine Daten.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs Z.55–112 – Begründung: Nummernkreisauflösung Filiale>Mandant.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs Z.10251–10295 – Begründung: Filial-Isolation bei Belegen.
|
||||
- [PRIMÄR] src\webservice\c-entron.misc.ConnectionManager\Dialogs\AdditionalServiceViewModel.cs Z.22–97 – Begründung: Sub-Web-Services je Datenbank.
|
||||
Prüfidee: Test: Benutzer mit „nur eigene Filiale" legt Beleg für fremde Filiale an → Ablehnung; zwei Filialen ziehen getrennte Rechnungsnummernkreise.
|
||||
Tracelinks: SyRS-009, SyRS-014, SyRS-060
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-016
|
||||
Titel: Compliance: Unveränderlichkeit, Nachvollziehbarkeit, DSGVO
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Compliance)
|
||||
Akteur: Buchhaltung, Datenschutzbeauftragter, Prüfer
|
||||
Vorbedingung: –
|
||||
Fakt: Rechnungen sind festschreibbar (IsFixed) und nach FiBu-Export storno-gesperrt; Belege werden versioniert statt überschrieben; zahlreiche fachliche Log-/Historientabellen (61 *Log/*History-Entities: Rechte, Passwörterzugriffe, Bestände, Belege, Geräte, Produktion) dokumentieren Änderungen mit Nutzer/Zeit; ein DSGVO-Modul löscht auf Anfrage mit protokolliertem Marker („DSGVO: Auf Anfrage gelöscht …"); ein AV-/SEPA-Online-Signaturkanal existiert.
|
||||
Aussage: Das System soll steuer- und datenschutzrechtliche Anforderungen unterstützen: Unveränderlichkeit festgeschriebener/exportierter Rechnungen, versionierte Änderungshistorie der Belege, auditierbare Protokolle sicherheits- und abrechnungsrelevanter Vorgänge sowie eine kontrollierte, selbst protokollierte DSGVO-Datenlöschung.
|
||||
Ergebnis: Prüfrelevante Vorgänge sind rekonstruierbar; Löschpflichten sind erfüllbar, ohne die Nachweisbarkeit der Löschung selbst zu verlieren.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\ReceiptInvoiceBL.cs Z.86–206 – Begründung: Festschreibung + Stornosperren.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs Z.26–69 – Begründung: DSGVO-Cleanup mit Marker, Recht + Lizenz.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs Z.762–857; src\backend\Centron.BL\PasswordManagementArea\PasswordManagementKeywordBL.cs Z.21–36 – Begründung: Audit-Trails sicherheitsrelevanter Aktionen.
|
||||
Prüfidee: Test: festgeschriebene Rechnung ändern → Ablehnung; DSGVO-Lauf entfernt inaktive Kundendaten und hinterlässt Löschmarker.
|
||||
Tracelinks: SyRS-011, SyRS-017, SyRS-057
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-017
|
||||
Titel: Integration in die Kommunikationsumgebung (E-Mail, Kalender, Outlook, Telefonie)
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Akteur: Alle Mitarbeiter
|
||||
Vorbedingung: Mail-/Graph-/TAPI-Konfiguration
|
||||
Fakt: Mailversand über SMTP, Exchange-EWS oder Microsoft Graph (App-only) mit objektbezogenen Vorlagen; bidirektionaler Kalenderabgleich mit Exchange/Microsoft 365 (Delta-Sync, Datenschutz privater Termine, Serienbehandlung); Outlook-Web-Add-in ordnet Mails Tickets/Kunden/Belegen zu; Telefonie über TAPI und Teams-Anrufprotokolle mit Anruferauflösung; Terminanfragen an Kunden mit Annahme-/Ablehnungslink; Echtzeit-Benachrichtigungen (SignalR) inkl. @-Erwähnungen.
|
||||
Aussage: Das System soll in die vorhandene Microsoft-Kommunikationsumgebung integriert sein, sodass E-Mails, Termine und Anrufe ohne Medienbruch mit ERP-Vorgängen verknüpft werden.
|
||||
Ergebnis: Kommunikationsereignisse sind Vorgängen zugeordnet; Termine sind in beiden Welten konsistent, private Termininhalte bleiben geschützt.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Mail\Factory\CentronMailFactory.cs Z.29–53 – Begründung: drei Transportwege.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Calendar\ScheduleBL.cs Z.1052–1700 – Begründung: Delta-Sync inkl. Privatsphäre-Regeln.
|
||||
- [PRIMÄR] src\webservice\Centron.Host\RealTimeServices\TapiClientHub.cs Z.9–66; src\backend\Centron.BL\Tapi\PhoneCallBL.cs Z.283–352 – Begründung: Telefonie-Kanäle.
|
||||
- [SEKUNDÄR] src\nexus\CentronNexus.OutlookAddIn\Manifest\Manifest.xml – Begründung: Outlook-Add-in-Funktionsumfang.
|
||||
Prüfidee: Test: privater Outlook-Termin erscheint im ERP nur als „Privater Termin"; Ticket-Termin-Zeitänderung in Outlook wird nicht ins ERP übernommen (Nexus source of truth).
|
||||
Tracelinks: SyRS-044, SyRS-045, SyRS-046, SyRS-052, SyRS-067, SyRS-004
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-018
|
||||
Titel: Führungsinformationen und Leistungscontrolling
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Geschäftsführung, Teamleitung, Controlling
|
||||
Vorbedingung: Rechte (MANAGEMENT_INFO bzw. RIGHT_MITARBEITERAUSLASTUNG)
|
||||
Fakt: „Management Info" liefert Kennzahlen (Auftrags-/Angebotsbestand, Deckungsbeitrag, Lieferrückstand, Lagerwert, offene Posten, Umsatz/Gewinn im Zeitverlauf) filial-/produktgruppenfiltert; „Leistungsnachweise" berechnet je Mitarbeiter/Tag fakturierbare, fakturierte und nicht fakturierbare Stunden inkl. Feiertags-/Abwesenheitslogik; Fremd-Auslastung wird ohne Sonderrecht maskiert.
|
||||
Aussage: Das System soll Geschäftsleitungs-Kennzahlen und die Fakturierbarkeitsquote der Mitarbeiter auswertbar machen, mit rechtegesteuerter Sicht (nur eigene Filiale, nur eigene Auslastung).
|
||||
Ergebnis: Steuerungsrelevante Kennzahlen sind ohne Export in Drittwerkzeuge verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Statistics\Sales\ManagementInfo\ManagementInfoBL.cs Z.24–445 – Begründung: Kennzahlenumfang.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Statistics\Administration\Employees\EmployeeUtilizationBL.cs Z.32–278 – Begründung: Auslastungsrechnung + Maskierung.
|
||||
Prüfidee: Vergleichsrechnung einer Beispielwoche gegen manuell ermittelte Stundenwerte.
|
||||
Tracelinks: SyRS-062, SyRS-061
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-019
|
||||
Titel: Kundenspezifische Anpassbarkeit ohne Programmierung
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Anpassbarkeit)
|
||||
Akteur: Key-User/Administrator des Kunden
|
||||
Vorbedingung: Administrationsrechte
|
||||
Fakt: Frei definierbare Zusatzfelder je Objektart (ModuleCustomProperty inkl. Pflichtfeld/Maske/Suche), freie Tabellen (CustomTables), in der Datenbank gespeicherte und anpassbare Reports (FastReport, Import/Export), ~1.200 Systemeinstellungen (zwei Settings-Kataloge), Mail-/Textvorlagen, vorlagenbasierte Massenänderung von Belegpositionen (MassUpdate, asynchron).
|
||||
Aussage: Das System soll durch Kunden ohne Codeänderung anpassbar sein: eigene Felder, eigene Auswertungen/Belegdrucke, umfangreiche Parametrisierung und Massenpflege.
|
||||
Ergebnis: Kundenindividuelle Anforderungen sind konfigurativ lösbar; Reports sind ohne Release austauschbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.Entities\Entities\Administration\Customization\ModuleCustomProperty.cs Z.9–19 – Begründung: Custom-Felder inkl. IsMandatory.
|
||||
- [PRIMÄR] src\backend\Centron.Entities\Entities\ReportEngine\Base\ReportDataBase.cs Z.8–22 – Begründung: Reports als DB-Inhalt.
|
||||
- [PRIMÄR] src\backend\Centron.BL\MassUpdate\MassUpdateBL.cs Z.60–160 – Begründung: Massenpflege über 6 Belegarten.
|
||||
Prüfidee: Test: Pflicht-Zusatzfeld an Kunde definieren → Anlage ohne Wert wird abgewiesen; Reportänderung wirkt ohne Neuinstallation.
|
||||
Tracelinks: SyRS-063, SyRS-061
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-020
|
||||
Titel: Betriebs- und Bereitstellungsmodelle (On-Premises, Linux/Container, Web)
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Übertragbarkeit/Betrieb)
|
||||
Akteur: Betreiber
|
||||
Vorbedingung: –
|
||||
Fakt: Der Web-Service läuft als Windows-Dienst (HTTP.sys) und unter Linux/Docker (Kestrel, Alpine-Container, TLS per PFX); Nexus als Windows-Dienst (MSI) und Container; der WPF-Client benötigt Windows; DB-Schema-Migration erfolgt automatisch beim Dienststart; Hintergrunddienste sind einzeln per DB-Flag deaktivierbar und überwacht; Builds sind signiert (Azure Trusted Signing) und versionsrückverfolgbar (Nerdbank GitVersioning).
|
||||
Aussage: Das System soll wahlweise On-Premises unter Windows oder containerisiert unter Linux betreibbar sein, sich beim Update selbst migrieren und betreibbar/überwachbar sein (steuerbare Hintergrunddienste, signierte Artefakte, eindeutige Versionszuordnung).
|
||||
Ergebnis: Ein Update besteht aus Dienst-Austausch; die Datenbank wird automatisch, transaktional und idempotent aktualisiert.
|
||||
Belege:
|
||||
- [PRIMÄR] src\webservice\Centron.Host\CentronHost.cs Z.100–151, 366–417 – Begründung: OS-abhängiges Hosting + Migrations-Start.
|
||||
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\HostedServices\ManagedBackgroundService.cs Z.23–157 – Begründung: steuer-/überwachbare Dienste.
|
||||
- [SEKUNDÄR] docker\c-entron-webservice\Dockerfile; .github\workflows\build.yml Z.184–334 – Begründung: Container-Weg + Signaturpflicht.
|
||||
Prüfidee: Betriebstest: Dienststart gegen ältere DB führt Skripte aus und startet erst bei Erfolg; Dienst-Deaktivierung per DB-Flag stoppt Ausführung binnen 60 s.
|
||||
Tracelinks: SyRS-001, SyRS-049, SyRS-050, SyRS-053, SyRS-054, SyRS-060
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-021
|
||||
Titel: Deutschsprachiger Zielmarkt mit englischer Zweitsprache
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Lokalisierung)
|
||||
Akteur: Alle Benutzer
|
||||
Vorbedingung: –
|
||||
Fakt: Deutsch ist Basissprache (Resource-Fallback, deutsche Fehlermeldungen in BL), Englisch die einzige Zusatzsprache (resx `.en`, Nexus de-DE/en-US); die Entwicklungsrichtlinie schreibt German-First vor; steuerliche Logik (DATEV, XRechnung, §13b-Texte, CH-Rundung, AT-ebInterface) adressiert DACH.
|
||||
Aussage: Das System soll primär den deutschsprachigen Markt (DE/AT/CH inkl. länderspezifischer Steuer-/Rundungsregeln) bedienen; alle Benutzertexte liegen deutsch vor, englisch als Zweitsprache.
|
||||
Ergebnis: Deutsche Benutzerführung vollständig; englische weitgehend (WPF ca. 90 % übersetzt).
|
||||
Belege:
|
||||
- [KONTEXT] docs\getting-started\general-structure.md Z.114–141 (German-First-Policy) – Begründung: dokumentierte Vorgabe.
|
||||
- [SEKUNDÄR] src\centron\Centron.WPF.UI\Resources\LocalizedStrings.resx / .en.resx (2812/2522 Einträge) – Begründung: Ist-Stand Übersetzungsumfang.
|
||||
- [PRIMÄR] src\nexus\CentronNexus\Shared\Services\CultureService.cs Z.15–29 – Begründung: unterstützte Kulturen de-DE/en-US.
|
||||
Prüfidee: UI-Durchsicht in EN: keine leeren Texte; Fallback auf Deutsch dokumentieren.
|
||||
Tracelinks: SyRS-058
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-022
|
||||
Titel: KI-Assistenz mit kundenseitiger Anbieterwahl
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Servicemitarbeiter; Betreiber (Konfiguration)
|
||||
Vorbedingung: KI-Anbieter/Key konfiguriert
|
||||
Fakt: Sieben produktive KI-Aktionen (Ticket-Titel/-Beschreibung/-Kommentar, Zeiterfassungstext, E-Mail-Text, Übersetzung, Kategorisierung) plus Chat/Tool-Calling; Anbieter je Installation wählbar (OpenAI, IONOS, OpenAI-kompatibel, Tensorx, ClaudeCode, Mistral, Google); Prompts deutsch mit Anti-Halluzinations-Regeln; Nutzung wird telemetriert.
|
||||
Aussage: Das System soll KI-gestützte Textassistenz im Service-Alltag bereitstellen, wobei der Kunde den KI-Anbieter (inkl. EU-/Self-Hosted-Optionen) selbst bestimmt.
|
||||
Ergebnis: Textqualität und Erfassungsgeschwindigkeit werden unterstützt, ohne Anbieter-Lock-in.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\ArtificialIntelligence\ApiClientFactory.cs Z.11–55 – Begründung: Multi-Provider.
|
||||
- [PRIMÄR] src\backend\Centron.BL\ArtificialIntelligence\Prompts\AiActionId.cs Z.8–22 – Begründung: Funktionsumfang.
|
||||
Prüfidee: Test: Anbieterwechsel per Einstellung ohne Codeänderung; Aktion „Ticket-Beschreibung verbessern" liefert Text.
|
||||
Tracelinks: SyRS-059
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-023
|
||||
Titel: Projekt- und Einsatzplanung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Projektleiter, Dispatcher
|
||||
Vorbedingung: –
|
||||
Fakt: CRM-Projekte bündeln Vertrieb (Plan-/Angebots-/Auftragsvolumen mit Erreichungsgraden), Tickets (Fortschritt aus Zeiten, Gantt mit Fälligkeits-Meilensteinen) und Ablage; Ticket-Projekte bieten Aufgabenbäume mit Verantwortlichen, Netzplan-Abhängigkeiten (4 Typen) und personalisierte Änderungs-Sammelmails; der Einsatzplan überlagert Projekte, Tickets, Zeiten und Termine rechtegefiltert.
|
||||
Aussage: Das System soll Projekte vertrieblich und operativ planbar machen (Budgetverfolgung, Aufgabenstruktur, Terminabhängigkeiten, Einsatzübersicht) und Beteiligte automatisch über Änderungen informieren.
|
||||
Ergebnis: Projektfortschritt und Ressourcennutzung sind aus operativen Daten (Tickets/Zeiten) abgeleitet statt separat gepflegt.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Customers\CrmProjects\CrmProjectBL.cs Z.105–863 – Begründung: CRM-Projekt inkl. Fortschritt/Gantt.
|
||||
- [PRIMÄR] src\backend\Centron.BL\WebServices\TicketProjects\TicketProjectWebserviceBL.cs Z.331–660 – Begründung: Aufgaben-Änderungslog + Sammelmail.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskSchedulerBL.cs Z.35–212 – Begründung: Einsatzplan-Aggregation.
|
||||
Prüfidee: Test: Terminänderung an Aufgabe → Log-Eintrag; Sammelmail an Verantwortliche mit markierten Änderungen.
|
||||
Tracelinks: SyRS-065
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-024
|
||||
Titel: Auftragsbezogene Produktion mit Werkerführung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Fertigungsplaner, Werker
|
||||
Vorbedingung: Lizenz ProductionManagement; Auftragsposition mit Produktionsartikel
|
||||
Fakt: Fertigungsaufträge entstehen ausschließlich aus Auftragspositionen mit Produktionsartikel; sie bestehen aus Arbeitsschritten (Dauer, Arbeitsplatztyp, Maße), die Werker im Web übernehmen (Doppelbelegungsschutz) und fertigmelden; 26 Log-Ereignistypen protokollieren feldgenau.
|
||||
Aussage: Das System soll kundenauftragsbezogene Fertigung (make-to-order) mit schrittweiser Werkerführung, Arbeitsplatz-/Maschinenzuordnung und lückenloser Änderungshistorie unterstützen.
|
||||
Ergebnis: Fertigungsfortschritt je Auftragsposition ist in Echtzeit sichtbar; kein Arbeitsschritt wird doppelt bearbeitet.
|
||||
Belege:
|
||||
- [PRIMÄR] src\centron\Centron.WPF.UI\Modules\Production\ProductionOrder\AddProductionOrder\AddProductionOrderViewModel.cs Z.111–137 – Begründung: Anlage nur aus Produktionsartikel-Position.
|
||||
- [PRIMÄR] src\nexus\CentronNexus\ProductionOrderManagement\Components\WorkStepTemplateComponent.razor Z.134–188 – Begründung: Übernahme-/Fertigmeldelogik.
|
||||
- [PRIMÄR] src\backend\Centron.Interfaces\Production\ProductionOrderLogKind.cs Z.9–76 – Begründung: Protokollpflicht.
|
||||
Prüfidee: Test: zwei Werker übernehmen denselben Schritt → zweiter erhält Hinweis; Fertigmeldung setzt ProducedAmount.
|
||||
Tracelinks: SyRS-064
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-025
|
||||
Titel: Nutzungsdatenübermittlung an den Hersteller (Transparenz-/Steuerungsanforderung)
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Datenschutz/Vertrag)
|
||||
Akteur: Hersteller; Betreiber; betroffene Mitarbeiter
|
||||
Vorbedingung: Lizenz geladen
|
||||
Fakt: Jede Installation aggregiert API-/KI-/Modulnutzung in 15-Minuten-Buckets je Benutzer, Gerät (Hardware-Fingerprint) und Lizenzart und lädt sie komprimiert an den Hersteller-Dienst „c-entron Office" hoch (inkl. DatabaseGuid, DatabaseName, CustomerNumber); zusätzlich meldet ein Analytics-Kanal Modulnutzungsdauern je Mitarbeiter; ein Endnutzer-Opt-out ist im Code nicht erkennbar.
|
||||
Aussage: Das System soll Produktnutzungsdaten an den Hersteller übermitteln. [HYPOTHESE] Zweck ist Lizenz-/Produktsteuerung; für ein Zielsystem ist die datenschutzrechtliche Grundlage (AVV, Betriebsvereinbarung, Opt-out) als Stakeholder-Anforderung explizit zu klären, da personenbeziehbare Verhaltensdaten übermittelt werden.
|
||||
Ergebnis: Nutzungsdaten liegen dem Hersteller pro Kunde/Benutzer/Gerät vor.
|
||||
Belege:
|
||||
- [PRIMÄR] src\webservice\Centron.Host\AspNetCore\Telemetry\HttpTelemetryUploadClient.cs Z.33–141 – Begründung: Upload-Inhalt und Empfänger.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Telemetry\TelemetryBL.cs Z.36–194 – Begründung: erfasste Dimensionen inkl. UserID.
|
||||
- [PRIMÄR] src\centron\Centron.WPF.UI\Managers\CentronAnalyticsManager.cs Z.54–127 – Begründung: Modulnutzungsdauer je Mitarbeiter.
|
||||
Prüfidee: Netzwerkmitschnitt einer Installation: Upload-Frequenz (15 min) und Payload-Felder verifizieren; Prüfung auf Abschaltbarkeit.
|
||||
Tracelinks: SyRS-056
|
||||
Konsolidierung: nein
|
||||
Status: HYPOTHESE (Zweck/Rechtsgrundlage; die Übermittlung selbst ist belegt)
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-026
|
||||
Titel: Verwaltung von Kundenzugangsdaten (Passwortmanager) mit Zugriffsnachweis
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Akteur: Servicemitarbeiter (Hotline), Kunde (Datengeber)
|
||||
Vorbedingung: Lizenz PasswordManager
|
||||
Fakt: Ein Passwortmanager-Modul speichert Fremdzugangsdaten der Kunden verschlüsselt (AES mit installationsspezifischem Masterkey), steuert Sichtbarkeit/Bearbeitung feingranular je (Kunde, Mitarbeiter) über Richtlinien-Flags inkl. Versiegelung/Siegelbruch und optionaler TOTP-PIN-Abfrage vor Anzeige, und protokolliert jede Entschlüsselung (PasswordManagementAccessLog).
|
||||
Aussage: Das System soll Zugangsdaten der betreuten Kunden verschlüsselt verwalten, den Zugriff je Kunde und Mitarbeiter steuern (inkl. Vier-Augen-/Versiegelungskonzept und Zweitfaktor vor Einsichtnahme) und jede Einsichtnahme revisionssicher nachweisen.
|
||||
Ergebnis: Kundenpasswörter sind nie im Klartext gespeichert; jeder Zugriff ist einem Mitarbeiter und Zeitpunkt zuordenbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs Z.92–188, 525–528, 700, 1051–1052 – Begründung: Verschlüsselung, Richtlinien-Flags, Feld-Nullung bei API-Abruf.
|
||||
- [PRIMÄR] src\backend\Centron.BL\PasswordManagementArea\PasswordManagementKeywordBL.cs Z.21–36 – Begründung: Zugriffsprotokoll bei Entschlüsselung.
|
||||
- [PRIMÄR] src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs Z.43–54 – Begründung: TOTP-PIN vor Anzeige.
|
||||
Prüfidee: Test: Anzeige eines versiegelten Zugangsdatums erfordert Siegelbruch + erzeugt Logeintrag; DB-Inspektion zeigt nur Chiffretext.
|
||||
Tracelinks: SyRS-070
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-027
|
||||
Titel: Zentrale Stammdatenverwaltung (Geschäftspartner, Artikel, Mitarbeiter)
|
||||
Ebene: StRS
|
||||
Typ: funktional (Daten)
|
||||
Akteur: Stammdatenpfleger, Vertrieb, Einkauf
|
||||
Vorbedingung: –
|
||||
Fakt: Geschäftspartner werden als Account mit Rollen (Kunde/Lieferant/Kontakt/Kundenarten) und Hierarchie Anschrift→Ansprechpartner geführt (genau eine Standardanschrift/-kontakt erzwungen; Löschschutz bei offenen Vorgängen); der Artikelstamm trägt flagbasierte Artikelarten, vier Preislisten, Staffeln, Stücklisten, GS1-EAN-Prüfziffernvalidierung und Eindeutigkeitsregeln; Mitarbeiter sind über „Mitarbeiterartikel" mit der Leistungsabrechnung verknüpft; Nummernkreise decken auch Stammdaten ab; bei Anlage entstehen automatisch DMS-Ordnerstrukturen.
|
||||
Aussage: Das System soll Geschäftspartner-, Artikel- und Mitarbeiterstammdaten zentral, validiert und rollenfähig verwalten; Stammdaten sind führend für Preisfindung, Steuerlogik, Abrechnung und Dokumentablage.
|
||||
Ergebnis: Alle Bewegungsprozesse greifen auf konsistente, validierte Stammdaten zu; Deaktivierung (z. B. Mitarbeiteraustritt) zerstört keine historische Abrechenbarkeit.
|
||||
Belege:
|
||||
- [PRIMÄR] src\backend\Centron.BL\Accounts\AccountBL.cs Z.490–803 (Rollenrechte, Löschschutz) – Begründung: Kernvalidierungen Geschäftspartner.
|
||||
- [PRIMÄR] src\backend\Centron.BL\Warehousing\ArticleBL.cs Z.1330–1567 (ValidateArticleBeforeSave inkl. EAN-Prüfziffer) – Begründung: Artikelvalidierung.
|
||||
- [PRIMÄR] src\backend\Centron.BL\EmployeeArea\EmployeeArticleBL.cs Z.23–61 (EOL statt Löschen) – Begründung: Abrechenbarkeit bleibt erhalten (Commit 644e5cc068).
|
||||
Prüfidee: Test: Artikel mit falscher EAN-Prüfziffer → Ablehnung; Kunde mit offener Rechnung löschen → Ablehnung; deaktivierter Mitarbeiter: alte Zeiten bleiben abrechenbar.
|
||||
Tracelinks: SyRS-069
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Abgrenzung / bewusste Nicht-Ziele (aus Code ableitbar)
|
||||
|
||||
- **Keine eigene Finanzbuchhaltung:** Es gibt Export/Import zu Fremd-FiBu (DATEV u. a.), aber keine Hauptbuchführung. Beleg: `BookKeepingExportBL` (nur Export/OPOS-Import) [PRIMÄR].
|
||||
- **Keine Mahnzinsen/-gebührenberechnung:** Im Mahnwesen ist keine Zins-/Gebührenlogik implementiert; DATEV-Mahnfelder werden leer exportiert. Beleg: `DunningBL`/`DatevAscii` Felder 232–254 leer [PRIMÄR, Abwesenheitsbefund].
|
||||
- **Keine Chargenverwaltung:** Rückverfolgung nur über Einzel-Seriennummern. Beleg: `BarcodeState.cs`, keine Chargen-Entität [PRIMÄR, Abwesenheitsbefund].
|
||||
- **Barbelege im .NET-Stack blockiert:** trotz vorhandener Datenstrukturen („Aktuell werden leider noch keine Bar-Belege unterstützt."). Beleg: `ReceiptBL.cs` Z.3763–3765 [PRIMÄR]; Status: belegt; Workaround (Delphi-Altfunktion nicht migriert).
|
||||
+1385
File diff suppressed because it is too large
Load Diff
+1377
File diff suppressed because it is too large
Load Diff
+86
@@ -0,0 +1,86 @@
|
||||
# Traceability-Matrix (StRS ↔ SyRS ↔ SwRS)
|
||||
|
||||
Forward-Traceability: StRS → SyRS → SwRS (eine Zeile je SyRS-Anforderung, gruppiert nach StRS).
|
||||
Backward-Traceability ist in den Dokumenten selbst enthalten (Feld `Tracelinks` jeder SyRS-/SwRS-Anforderung).
|
||||
Der `Artefaktbeleg` nennt je Zeile einen repräsentativen PRIMÄR-Beleg; vollständige Beleglisten stehen in den Einzelanforderungen.
|
||||
`–` = keine eigene SwRS-Verfeinerung (Systemanforderung direkt belegt).
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID(s) | Artefaktbeleg (repräsentativ) |
|
||||
|---|---|---|---|
|
||||
| StRS-001 | SyRS-001 | SwRS-001 | src\webservice\Centron.Host\CentronHost.cs Z.274–282 |
|
||||
| StRS-001, StRS-003 | SyRS-013 | SwRS-016, SwRS-017, SwRS-018, SwRS-019, SwRS-020, SwRS-021, SwRS-022 | Centron.BL\Sales\Receipts\ReceiptBL.cs Z.3535–3950 |
|
||||
| StRS-001, StRS-005 | SyRS-020 | SwRS-031, SwRS-034, SwRS-038, SwRS-039, SwRS-069 | Centron.BL\Sales\Support\HelpdeskBL.cs Z.418–466 |
|
||||
| StRS-001, StRS-007 | SyRS-025 | SwRS-024, SwRS-026, SwRS-027 | AutomaticFacturaBL.Contracts.cs Z.1885–2019 |
|
||||
| StRS-001, StRS-010 | SyRS-035 | SwRS-051 | Centron.BL\CustomerArea\RmaBL.cs Z.352–1996 |
|
||||
| StRS-001, StRS-011 | SyRS-039 | SwRS-053, SwRS-054 | BookKeepingExportDatevAscii.cs Z.551–844 |
|
||||
| StRS-002, StRS-013 | SyRS-006 | SwRS-006, SwRS-007 | Auth\AuthenticatorFactory.cs Z.54–140 |
|
||||
| StRS-002, StRS-013, StRS-015 | SyRS-009 | SwRS-011, SwRS-032 | AppRightsBL.cs Z.644–664 |
|
||||
| StRS-002, StRS-012, StRS-013 | SyRS-010 | SwRS-012 | WebRightsVisibility.cs Z.10–59 |
|
||||
| StRS-002, StRS-012 | SyRS-028 | SwRS-012, SwRS-015, SwRS-043 | HelpdeskSearchBL.cs Z.536–565 |
|
||||
| StRS-003 | SyRS-014 | SwRS-023 | NumberGroupBL.cs Z.62–134 |
|
||||
| StRS-003, StRS-007 | SyRS-015 | SwRS-024, SwRS-025, SwRS-026, SwRS-030 | ReceiptItemPriceBL.cs Z.154–286 |
|
||||
| StRS-003, StRS-011, StRS-016 | SyRS-017 | SwRS-020 | ReceiptInvoiceBL.cs Z.86–206 |
|
||||
| StRS-003 | SyRS-018 | SwRS-028 | DownPaymentBL.cs Z.82–343 |
|
||||
| StRS-003, StRS-008 | SyRS-038 | SwRS-017 | Centron.Api.Gls\CentronGlsLogic.cs Z.15–58 |
|
||||
| StRS-004 | SyRS-027 | SwRS-040, SwRS-041 | SharedDocumentBL.cs Z.496–678 |
|
||||
| StRS-005 | SyRS-021 | SwRS-033 | Escalation\EscalationBL.cs Z.313–426 |
|
||||
| StRS-005, StRS-013 | SyRS-022 | SwRS-031, SwRS-032 | HelpdeskBL.cs Z.233–291 |
|
||||
| StRS-005 | SyRS-051 | SwRS-068 | IndexSearchBL.cs Z.49–73 |
|
||||
| StRS-005, StRS-007 | SyRS-068 | SwRS-066 | ExpectedEventsBL.cs Z.22–213 |
|
||||
| StRS-006, StRS-013 | SyRS-023 | SwRS-035, SwRS-036, SwRS-073 | HelpdeskTimerWebServiceBL.cs Z.327–381 |
|
||||
| StRS-006 | SyRS-024 | SwRS-036, SwRS-037 | ReceiptItemTimerBL.cs Z.390–497 |
|
||||
| StRS-006 | SyRS-066 | – | MyDayNotificationsBL.cs Z.115–231 |
|
||||
| StRS-007 | SyRS-047 | SwRS-052 | RiverDivoBL.cs Z.86–441 |
|
||||
| StRS-007 | SyRS-048 | SwRS-052 | DocuFormRestApiClient.cs Z.48–110 |
|
||||
| StRS-008 | SyRS-029 | SwRS-017, SwRS-019, SwRS-046 | SupplierDeliveryListSpecificLogic.cs Z.148–374 |
|
||||
| StRS-008 | SyRS-030 | SwRS-047 | OrderSuggestionListBL.cs Z.87–242 |
|
||||
| StRS-008 | SyRS-036 | SwRS-052 | SupplierEdiBL.cs Z.1364–1414 |
|
||||
| StRS-008 | SyRS-037 | SwRS-052 | ITscopeExternalArticleSearchProvider.cs Z.45–225 |
|
||||
| StRS-009 | SyRS-031 | SwRS-044, SwRS-045, SwRS-046 | ScriptMethod11482.cs Z.25–54 (cvw_ArticleCount) |
|
||||
| StRS-009 | SyRS-032 | SwRS-048 | ReceiptBarcodeBL.cs Z.85–122 |
|
||||
| StRS-009 | SyRS-033 | SwRS-049 | InventoryBL.cs Z.797–944 |
|
||||
| StRS-009 | SyRS-034 | SwRS-050 | SecondStockArticleBL.cs Z.101–130 |
|
||||
| StRS-011 | SyRS-016 | SwRS-026, SwRS-027 | ReceiptItemAccountBL.cs Z.115–189 |
|
||||
| StRS-011 | SyRS-019 | SwRS-029 | ReceiptBL.cs Z.8636–8690, 10205–10244 |
|
||||
| StRS-011 | SyRS-040 | SwRS-055 | InvoiceZugferdBL.cs Z.124–217 |
|
||||
| StRS-011 | SyRS-041 | SwRS-056 | SepaFileGeneratorV2.cs Z.99–289 |
|
||||
| StRS-011 | SyRS-042 | SwRS-057 | OnlineBankingAccountTransactionsBL.cs Z.581–1086 |
|
||||
| StRS-011 | SyRS-043 | SwRS-058 | DunningRunBL.cs Z.200–315 |
|
||||
| StRS-012 | SyRS-026 | SwRS-042 | ReceiptCartReleaseSystemBL.cs Z.65–283 |
|
||||
| StRS-013, StRS-014 | SyRS-007 | SwRS-008, SwRS-009 | TicketBL.cs Z.26–170; AccessTokenBL.cs Z.457–488 |
|
||||
| StRS-013 | SyRS-008 | SwRS-010 | TwoFactorAuthBL.cs Z.82–135 |
|
||||
| StRS-013, StRS-016 | SyRS-011 | SwRS-011 | AppRightsBL.cs Z.762–857 |
|
||||
| StRS-013 | SyRS-055 | SwRS-006, SwRS-007, SwRS-010, SwRS-014 | SHA1Decoder.cs Z.9–17; AESCryptoLogic.cs Z.77–92 |
|
||||
| StRS-014 | SyRS-012 | SwRS-013, SwRS-075 | LicenseManager.cs Z.219–302 |
|
||||
| StRS-015, StRS-020 | SyRS-060 | SwRS-066 | .github\workflows\build.yml Z.313–334; CentronHost.cs Z.114–151 |
|
||||
| StRS-016 | SyRS-057 | SwRS-064 | DataSecurityBL.cs Z.26–69 |
|
||||
| StRS-017 | SyRS-004 | SwRS-003 | CentronSignalR.cs Z.9–15 |
|
||||
| StRS-017 | SyRS-044 | SwRS-059 | CentronMailFactory.cs Z.29–53 |
|
||||
| StRS-017 | SyRS-045 | SwRS-060 | ScheduleBL.cs SyncByGraphV2 Z.1052–1204 |
|
||||
| StRS-017 | SyRS-046 | SwRS-003 | TapiClientHub.cs Z.9–66 |
|
||||
| StRS-017 | SyRS-052 | SwRS-003 | NexusNotificationsBL.cs Z.35–405 |
|
||||
| StRS-017 | SyRS-067 | SwRS-060 | AppointmentRequestBL.cs Z.29–114 |
|
||||
| StRS-018 | SyRS-062 | SwRS-011 | ManagementInfoBL.cs Z.24–445 |
|
||||
| StRS-018, StRS-019 | SyRS-061 | SwRS-064 | ReportDataBase.cs Z.8–22; PdfStrategies.cs Z.23–147 |
|
||||
| StRS-019 | SyRS-063 | – | ModuleCustomPropertyBL.cs Z.20–83; MassUpdateBL.cs Z.60–160 |
|
||||
| StRS-020 | SyRS-002 | SwRS-002, SwRS-003, SwRS-004 | CentronWcfBridge.cs Z.35–81 |
|
||||
| StRS-020 | SyRS-003 | SwRS-005 | RegisterCentronApiVersioning.cs Z.9–23 |
|
||||
| StRS-020 | SyRS-005 | SwRS-004 | TryCatchInterceptor.cs Z.19–41 |
|
||||
| StRS-020 | SyRS-049 | SwRS-066 | ManagedBackgroundService.cs Z.23–157 |
|
||||
| StRS-020 | SyRS-050 | SwRS-021, SwRS-061, SwRS-062, SwRS-063, SwRS-064 | ScriptEngineBL.cs Z.40–177 |
|
||||
| StRS-020 | SyRS-053 | SwRS-004, SwRS-065 | WebServiceConfigDAOConnection.cs Z.8–19 |
|
||||
| StRS-020 | SyRS-054 | SwRS-065, SwRS-066 | DAOFactory.cs Z.212–273 |
|
||||
| StRS-021 | SyRS-058 | SwRS-001 | CultureService.cs Z.15–29; LocalizedStrings*.resx |
|
||||
| StRS-022 | SyRS-059 | SwRS-067 | ApiClientFactory.cs Z.11–55 |
|
||||
| StRS-023 | SyRS-065 | SwRS-069 | TicketProjectWebserviceBL.cs Z.331–425 |
|
||||
| StRS-024 | SyRS-064 | SwRS-070 | WorkStepTemplateComponent.razor Z.134–188 |
|
||||
| StRS-025 | SyRS-056 | SwRS-067 | HttpTelemetryUploadClient.cs Z.57–74 |
|
||||
| StRS-026 | SyRS-070 | SwRS-074, SwRS-014 | PasswordManagerBL.cs Z.92–188 |
|
||||
| StRS-027 | SyRS-069 | SwRS-071, SwRS-072, SwRS-073 | AccountRepository.cs Z.904–1005; ArticleBL.cs Z.1330–1567 |
|
||||
|
||||
## Abdeckungsübersicht
|
||||
|
||||
- **StRS-Abdeckung:** Alle 27 StRS-Anforderungen sind durch mindestens eine SyRS-Anforderung verfeinert.
|
||||
- **SyRS-Abdeckung:** Alle 70 SyRS-Anforderungen referenzieren mindestens eine StRS-Anforderung (Backward). 68 von 70 besitzen SwRS-Verfeinerungen; SyRS-063 und SyRS-066 sind bewusst ohne eigene SwRS-Ebene (Systemanforderung direkt implementierungsbelegt, siehe Vermerk in den Anforderungen).
|
||||
- **SwRS-Abdeckung:** Alle 75 SwRS-Anforderungen referenzieren mindestens eine existierende SyRS-Anforderung.
|
||||
- **Mehrfachzuordnungen** (eine SwRS unter mehreren SyRS) sind beabsichtigt (Querschnittskomponenten, z. B. SwRS-003 Interceptor-Kette, SwRS-052 Integrationskatalog, SwRS-066 Dienstbasisklasse).
|
||||
+206
@@ -0,0 +1,206 @@
|
||||
# Messprotokoll – V1b-Fable (builtin, `claude-fable-5`, Effort `high`) – Prompt-Version 01, Lauf 24 (Lauf R)
|
||||
|
||||
> ## ⚠ Bedingungsverletzung: Die Subagenten liefen auf einem anderen Modell
|
||||
>
|
||||
> `--model claude-fable-5` steuerte nur den **Hauptagenten**. Die 13 Subagenten liefen auf
|
||||
> **`claude-opus-5[1m]`** – dem in `~/.claude/settings.json` hinterlegten Standardmodell
|
||||
> (`"model": "opus[1m]"`). Auf sie entfallen **136.694.206 von 150.340.866 Tokens (91 %)**.
|
||||
>
|
||||
> **Der Lauf ist damit keine Fable-Messung**, sondern ein Mischbetrieb: Fable als Hauptagent,
|
||||
> Opus mit 1-Mio.-Kontext als Analysemodell. Für den Modellvergleich der Reihe ist er **nicht
|
||||
> verwendbar**. Als Beleg für das Verhalten von Claude Code ist er dagegen wertvoll – siehe
|
||||
> Anmerkung 1.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `Versuche/Versuch_01/01_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `1B0DB06B8E0A5B92A5EFBDBEC5A0C554351FC928A16AEF34AAD9EAA0893C02FF`
|
||||
(identisch zu allen bisherigen Läufen)
|
||||
- **Startzeit:** 2026-08-25T22:07:48+02:00
|
||||
- **Endzeit:** 2026-08-25T23:10:36+02:00
|
||||
- **Dauer gesamt:** 01:02:48 (Wanduhr) bzw. 00:51:56 (`duration_ms`) — API: 03:11:37
|
||||
- **Parallelbetrieb:** **nein** – der Lauf lief allein auf der Maschine. Die Zeitangaben sind
|
||||
damit erstmals seit Lauf 6 wieder für Laufzeitvergleiche brauchbar.
|
||||
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||
- **Codebasis-Commit:** `79c1142f489a32ba6a4a4cb043fd7f8550a9f257` (dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: **ja** (strenge Prüfung: 0 Treffer);
|
||||
Remote entkoppelt: **ja**
|
||||
- **Prompt-Repo-Commit:** `0ec86aed8cb8781054c86cbe0dd9f5eb0f7e5f05`
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Laufverzeichnis-ID:** `v3.7.0-15db`
|
||||
- **Ablage:** `Iteration 1/claude-fable-5/builtin/high/`
|
||||
- **Parallele Läufe:** nein
|
||||
- **Skill-Version:** `3.7.0` (erster Lauf mit Effort im Verzeichnisnamen)
|
||||
- **Claude-Code-Version:** 2.1.245
|
||||
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.245-win32-x64\resources\native-binary\claude.exe`
|
||||
- **Agentenmodus:** `builtin` (V1b) – eingebaute Subagenten zugelassen
|
||||
- **Effort:** `high` – explizit per `--effort` gesetzt; Gegenprobe im Transkript: 104
|
||||
Nachrichten, durchgängig `high`
|
||||
- **Modell (angefordert):** `claude-fable-5`
|
||||
- **Modelle (tatsächlich eingesetzt):**
|
||||
- `claude-fable-5` – Hauptagent, 13.642.444 Tokens (9 %)
|
||||
- **`claude-opus-5[1m]`** – Subagenten, 136.694.206 Tokens (91 %) — **nicht angefordert**
|
||||
- `claude-haiku-4-5-20251001` – interne Hilfsaufrufe, 4.216 Tokens
|
||||
- **Permission-Mode:** `acceptEdits`
|
||||
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"`; `--disallowedTools` mit 33 Einträgen
|
||||
- **Isolationsmechanismus:** eingefrorener Codebasis-Snapshot ohne KI-Konfigurationen,
|
||||
zusätzlich `--safe-mode` und `--strict-mcp-config`
|
||||
- **MCP-Server / Agentendateien:** keine
|
||||
- **Subagenten:** **13** (alle `Explore`); 0 fehlgeschlagen
|
||||
- **Verschachtelung:** `spawned` = 13, `spawned_by_subagents` = 0, `max_depth` = 1
|
||||
- **Fast-Mode:** aus
|
||||
|
||||
## Verbrauch
|
||||
|
||||
### Hauptagent (`usage`)
|
||||
| Messgröße | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 46 |
|
||||
| Output-Tokens | 275.863 (davon 22.340 Thinking-Tokens) |
|
||||
| Cache-Write-Tokens | 627.458 |
|
||||
| Cache-Read-Tokens | 11.734.030 |
|
||||
| Agent-Turns | 28 |
|
||||
|
||||
### Gesamtlauf inkl. aller Subagenten (`modelUsage`)
|
||||
| Messgröße | `claude-fable-5` | `claude-opus-5[1m]` | `claude-haiku-4-5` | Summe |
|
||||
|---|---:|---:|---:|---:|
|
||||
| Input-Tokens | 76 | 1.784 | 4.196 | 6.056 |
|
||||
| Output-Tokens | 298.603 | 619.711 | 20 | 918.334 |
|
||||
| Cache-Write-Tokens | 713.252 | 2.938.430 | 0 | 3.651.682 |
|
||||
| Cache-Read-Tokens | 12.630.513 | 133.134.281 | 0 | 145.764.794 |
|
||||
| Tokens gesamt | 13.642.444 | **136.694.206** | 4.216 | **150.340.866** |
|
||||
|
||||
**Tokens gesamt: 150.340.866** — mit Abstand der höchste Wert der gesamten Reihe. Der bisherige
|
||||
Höchstwert lag bei 65.101.243 (Lauf J, V1b Sonnet); dieser Lauf übertrifft ihn um Faktor 2,3.
|
||||
Ursache ist ausschließlich das Fremdmodell in den Subagenten.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** erfolgreich (`is_error: false`, `terminal_reason: "completed"`,
|
||||
`stop_reason: "end_turn"`, Exit-Code 0, `Stderr.log` leer)
|
||||
- **Session-ID:** `9bfd8e6e-018e-4179-a426-75d86a14912e`
|
||||
- **Permission-Denials:** **0**
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 13 (Modus `builtin`, erwartungskonform)
|
||||
- **Kontrolle Modell:** **fehlgeschlagen** – `modelUsage` enthält ein nicht angefordertes Modell
|
||||
- **Subagenten-Prompts:** `_meta\subagenten.md`, 13 von 13 Aufrufen erfasst (keine Verschachtelung)
|
||||
- **Erzeugte Dateien:** alle 7 geforderten Artefakte in `Ergebnisse\`, **keine Fremddateien**
|
||||
|
||||
| Datei | Größe | Inhalt |
|
||||
|---|---:|---|
|
||||
| `StRS.md` | 52.997 B | 27 Anforderungen |
|
||||
| `SyRS.md` | 111.376 B | 70 Anforderungen |
|
||||
| `SwRS.md` | 89.020 B | 75 Anforderungen |
|
||||
| `Traceability.md` | 7.215 B | konsolidierte Tabelle |
|
||||
| `Hypothesen.md` | 10.288 B | Sammlung der `[HYPOTHESE]`-Aussagen |
|
||||
| `Glossar.md` | 16.477 B | Domänenbegriffe |
|
||||
| `Analysebericht.md` | 12.269 B | Modulabdeckung, Konsistenzcheck, Selbstbewertung |
|
||||
|
||||
Summe: **172 Anforderungen** über drei Ebenen.
|
||||
- **Root unverändert:** ja. `git status --porcelain` vor und nach dem Lauf leer, HEAD `79c1142`.
|
||||
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
|
||||
|
||||
## 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 | 27 | 15,7 % |
|
||||
| SyRS | 70 | 40,7 % |
|
||||
| SwRS | 75 | 43,6 % |
|
||||
| **Gesamt** | **172** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 79 | 45,9 % |
|
||||
| Sicherheit | 23 | 13,4 % |
|
||||
| Schnittstelle | 19 | 11,0 % |
|
||||
| Daten | 9 | 5,2 % |
|
||||
| funktional (Daten) | 4 | 2,3 % |
|
||||
| funktional (Komponente) | 4 | 2,3 % |
|
||||
| nicht-funktional (Produktsteuerung) | 2 | 1,2 % |
|
||||
| funktional / Sicherheit | 2 | 1,2 % |
|
||||
| Schnittstelle (Zahlungsverkehr) | 2 | 1,2 % |
|
||||
| funktional (Geschäftsziel) | 1 | 0,6 % |
|
||||
| (27 weitere) | 27 | 15,7 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 331 |
|
||||
| davon `PRIMÄR` | 314 (94,9 %) |
|
||||
| davon `SEKUNDÄR` | 5 (1,5 %) |
|
||||
| davon `KONTEXT` | 12 (3,6 %) |
|
||||
| Belege je Anforderung (Median) | 2,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 172 (100,0 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
**nicht erhoben** – das Feld `Übernahmewürdigkeit` wurde erst mit der Prompt-Fassung vom 2026-08-26 eingeführt und liegt für diesen Lauf nicht vor. Hinweise auf Workarounds stecken ersatzweise im Feld `Status`.
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 169 | 98,3 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 3 | 1,7 % |
|
||||
| als Workaround vermerkt | 15 | 8,7 % |
|
||||
| Konsolidierungskandidaten | 17 | 9,9 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 0 | 0,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** (58 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | *nicht erhoben* (Feld erst ab Prompt-Fassung 2026-08-26) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 172 von 172 mit Tracelinks (100,0 %) |
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
1. **`--model` steuert nur den Hauptagenten, nicht zwingend die Subagenten.** Das ist der
|
||||
zentrale Befund dieses Laufs. Eine Gegenprüfung über alle 24 Läufe zeigt, dass der Effekt
|
||||
**ausschließlich hier** auftritt:
|
||||
|
||||
| Kombination | Läufe | Modelle in `modelUsage` |
|
||||
|---|---:|---|
|
||||
| Sonnet + `builtin` | 11 | nur `claude-sonnet-5` (+ Haiku) |
|
||||
| Sonnet + `solo` | 5 | nur `claude-sonnet-5` (+ Haiku) |
|
||||
| Opus + `solo` | 5 | nur `claude-opus-5` (+ Haiku) |
|
||||
| Fable + `solo` | 2 | nur `claude-fable-5` (+ Haiku) |
|
||||
| **Fable + `builtin`** | **1** | **Fable + `claude-opus-5[1m]`** |
|
||||
|
||||
Sonnet und Opus werden also an die Subagenten durchgereicht, Fable nicht. Statt dessen greift
|
||||
das in `~/.claude/settings.json` hinterlegte Standardmodell `opus[1m]`. Die naheliegende
|
||||
Erklärung: Fable steht als Subagenten-Modell nicht zur Verfügung, und Claude Code fällt auf
|
||||
die Sitzungsvorgabe zurück statt auf den `--model`-Wert. **`--safe-mode` verhindert das
|
||||
nicht** – es deaktiviert Customizations, nicht die Modellwahl.
|
||||
|
||||
2. **Konsequenz für die Versuchsanordnung:** Bei Modus `builtin` ist das Modell **nicht allein
|
||||
durch `--model` festgelegt**. Es genügt nicht, den Flag-Wert ins Protokoll zu schreiben; die
|
||||
tatsächlich eingesetzten Modelle müssen nach jedem Lauf aus `modelUsage` gegengeprüft werden.
|
||||
Enthält es ein nicht angefordertes Modell, ist die Bedingung verletzt und der Lauf für
|
||||
Modellvergleiche unbrauchbar. Diese Prüfung wird als Pflichtschritt in den Skill aufgenommen.
|
||||
|
||||
3. **Alle bisherigen Läufe sind nicht betroffen.** Die Gegenprüfung ergab für die 23 Vorläufe
|
||||
ausschließlich das jeweils angeforderte Modell plus Haiku. Die bisherigen Ergebnisse und
|
||||
Vergleiche bleiben gültig.
|
||||
|
||||
4. **Der Lauf zeigt beiläufig, was Opus mit Subagenten leistet.** 172 Anforderungen (27/70/75)
|
||||
bei 13 `Explore`-Subagenten und nur 28 Hauptagent-Turns. Zum Vergleich: Der Sonnet-V1b-Block
|
||||
F–J erreichte 113 bis 246 Anforderungen. Der Wert liegt also im erwarteten Bereich – erkauft
|
||||
mit dem 2,3-fachen Tokenverbrauch des bisherigen Maximums.
|
||||
|
||||
5. **Erstmals seit Lauf 6 wieder eine belastbare Zeitmessung.** Der Lauf lief allein; Wanduhrzeit
|
||||
(01:02:48) und `duration_ms` (00:51:56) sind nicht parallelbetriebsverzerrt. Die API-Zeit von
|
||||
03:11:37 bei 13 nebenläufigen Subagenten ergibt ein Verhältnis `api/wall` von 3,05.
|
||||
|
||||
6. **Manuelle Eingriffe während des Laufs:** keine.
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"is_error":false,"duration_api_ms":11496687,"num_turns":28,"stop_reason":"end_turn","session_id":"9bfd8e6e-018e-4179-a426-75d86a14912e","total_cost_usd":142.2647820000002,"usage":{"input_tokens":46,"cache_creation_input_tokens":627458,"cache_read_input_tokens":11734030,"output_tokens":275863,"output_tokens_details":{"thinking_tokens":22340},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":627458,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1199,"cache_read_input_tokens":712846,"cache_creation_input_tokens":406,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":406},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":4196,"outputTokens":20,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.004296,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty"},"claude-fable-5":{"inputTokens":76,"outputTokens":298603,"cacheReadInputTokens":12630513,"cacheCreationInputTokens":713252,"webSearchRequests":0,"costUSD":41.826463000000004,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty"},"claude-opus-5[1m]":{"inputTokens":1784,"outputTokens":619711,"cacheReadInputTokens":133134281,"cacheCreationInputTokens":2938430,"webSearchRequests":0,"costUSD":100.43402300000021,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-opus-5","provider":"firstParty"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","origin":{"kind":"task-notification"},"subagent_stats":{"spawned":13,"requested":{"background":0,"foreground":0,"unset":13},"started_in_background":13,"max_depth":1,"spawned_by_subagents":0,"completed":13,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"Explore":13}},"subtype":"success","api_error_status":null,"result":"Der Lauf ist abgeschlossen. Alle sieben Ergebnisdateien liegen im vorgegebenen Verzeichnis, die analysierte Codebasis ist unverändert (git status leer).\n\n## Ergebnis\n\n**Spezifikation (172 Anforderungen, durchgängig im vorgegebenen Format mit Fakt/Aussage-Trennung und klassifizierten Belegen):**\n- **StRS.md** – 27 Stakeholder-Anforderungen inkl. Akteurstabelle und belegter Abgrenzungen (z. B. keine Mahngebühren, Barbelege blockiert)\n- **SyRS.md** – 70 System-Anforderungen (Architektur/APIs, Sicherheit, Belegwesen, Service, Lager/RMA, Finanzen, Integrationen; NFAs mit ISO-25010-Zuordnung, u. a. ein konsolidierter Härtungskatalog SyRS-055)\n- **SwRS.md** – 75 Software-Anforderungen (Schichtenmodell, Persistenzkonventionen, Statusmaschinen, Rechenkerne, 15 als `belegt; Workaround` markierte historische Sonderlösungen)\n- **Traceability.md** – vollständige Matrix StRS↔SyRS↔SwRS mit je einem repräsentativen PRIMÄR-Beleg pro Zeile\n- **Hypothesen.md** – 20 Hypothesen mit offenen Validierungsfragen (u. a. Hersteller-Telemetrie/Datenschutz, nie geprüftes Recht CHANGE_VISIBILITY, gewachsene Toleranzwerte 2,00/3,00/0,50 €)\n- **Glossar.md** – ~120 Domänenbegriffe\n- **Analysebericht.md** – Modulübersicht mit Analysetiefe, Konsistenzcheck und Selbstbewertung\n\n**Vorgehen:** Nach Struktur- und Doku-Sichtung habe ich die technische Analyse über 13 parallele Explorationsdurchgänge (Claude-Code-Standard-Subagenten, keine Agentendateien/MCP) über die Fachdomänen gefahren, deren belegte Findings im Scratchpad gesichert und zentral zu den drei Ebenen formalisiert.\n\n**Konsistenzcheck (im Analysebericht dokumentiert):** IDs eindeutig und lückenlos; keine Anforderung ohne Beleg; beim Check fand ich zwei fehlerhafte Abwärts-Tracelinks (SyRS-063, SyRS-066) und habe sie vor Abgabe korrigiert — danach zeigen alle Verweise auf existierende IDs.\n\n**Ehrliche Grenzen:** Nicht analysiert blieben u. a. VoucherManagement, CashBook, Provisionsdetails, die 371 NamedQueries einzeln, Reportinhalte und mehrere Nebenmodule (Chat, Mailings, Mobile) — im Analysebericht als Abdeckungslücken mit konkreten Nachschlag-Empfehlungen für Folge-Iterationen ausgewiesen. Zeilenangaben in Belegen sind „ca.\"-Angaben zum Commit-Stand 79c1142f48; maßgeblich sind Klasse/Methode.","ttft_ms":8554,"ttft_stream_ms":2530,"time_to_request_ms":18,"type":"result","duration_ms":3116319,"uuid":"65721d91-e638-4715-b901-58210d3aa500","queued_turn_count":0}
|
||||
+3085
File diff suppressed because it is too large
Load Diff
+66
@@ -0,0 +1,66 @@
|
||||
## 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 | 27 | 15,7 % |
|
||||
| SyRS | 70 | 40,7 % |
|
||||
| SwRS | 75 | 43,6 % |
|
||||
| **Gesamt** | **172** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 79 | 45,9 % |
|
||||
| Sicherheit | 23 | 13,4 % |
|
||||
| Schnittstelle | 19 | 11,0 % |
|
||||
| Daten | 9 | 5,2 % |
|
||||
| funktional (Daten) | 4 | 2,3 % |
|
||||
| funktional (Komponente) | 4 | 2,3 % |
|
||||
| nicht-funktional (Produktsteuerung) | 2 | 1,2 % |
|
||||
| funktional / Sicherheit | 2 | 1,2 % |
|
||||
| Schnittstelle (Zahlungsverkehr) | 2 | 1,2 % |
|
||||
| funktional (Geschäftsziel) | 1 | 0,6 % |
|
||||
| (27 weitere) | 27 | 15,7 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 331 |
|
||||
| davon `PRIMÄR` | 314 (94,9 %) |
|
||||
| davon `SEKUNDÄR` | 5 (1,5 %) |
|
||||
| davon `KONTEXT` | 12 (3,6 %) |
|
||||
| Belege je Anforderung (Median) | 2,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 172 (100,0 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
**nicht erhoben** – das Feld `Übernahmewürdigkeit` wurde erst mit der Prompt-Fassung vom 2026-08-26 eingeführt und liegt für diesen Lauf nicht vor. Hinweise auf Workarounds stecken ersatzweise im Feld `Status`.
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 169 | 98,3 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 3 | 1,7 % |
|
||||
| als Workaround vermerkt | 15 | 8,7 % |
|
||||
| Konsolidierungskandidaten | 17 | 9,9 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 0 | 0,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** (58 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | *nicht erhoben* (Feld erst ab Prompt-Fassung 2026-08-26) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 172 von 172 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+132
@@ -0,0 +1,132 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 01
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 01 (Initial-Prompt, zu Versuchsbeginn neu formuliert)
|
||||
- **Werkzeugkonfiguration:** Claude Code, keine Agentendateien, keine MCP-Server
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Modell:** Claude (Claude Code)
|
||||
- **Zeitstempel:** 2026-08-25
|
||||
- **Änderungsgrund:** Initial-Prompt für V1 Baseline (kein Vorgänger). Vor Erstlauf überarbeitet: Abgleich mit Kap. 4 (RRE-Methodenkette, Evaluationsrahmen) und Kap. 2 (Prozesskontrollen); mit der Vorfassung fand kein Lauf statt.
|
||||
|
||||
---
|
||||
|
||||
## 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). Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung; nutze nur, was als Datei lesbar ist.
|
||||
|
||||
### 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. Priorisiere die Analysetiefe selbstständig, dokumentiere aber im `Analysebericht.md`, welche Bereiche wie tief analysiert wurden.
|
||||
|
||||
### 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):
|
||||
|
||||
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). Anforderungen ohne Beleg sind unzulässig. Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt.
|
||||
- **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.
|
||||
- **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.
|
||||
- **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.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
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>>
|
||||
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).
|
||||
- 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.
|
||||
|
||||
### 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 (Modul-/Komponentenübersicht, abgedeckte Bereiche, bekannte Lücken)
|
||||
```
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs benannt. 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 nicht vorhandener Tools.** Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist die Aussage als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Wenn eine Implementierung erkennbar ein historischer Workaround oder Sonderfall ist, vermerke das im Feld `Status` (`belegt; Workaround`), damit es in der späteren Validierung priorisiert geprüft werden kann.
|
||||
- **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
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Welche Module wurden vollständig analysiert, welche nur stichprobenhaft, welche gar nicht?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`c:\DEV\MasterArbeit\Versuche\Versuch_01\01_Lauf_2026-08-25_220735_fable5_builtin_ehigh_v3.7.0-15db\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-25T23:10:36.1728701+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-25T22:07:48.6486301+02:00
|
||||
+129
@@ -0,0 +1,129 @@
|
||||
# Analysebericht – RRE-Lauf V1/Iteration 01
|
||||
|
||||
**Untersuchungsgegenstand:** Gesamte Codebasis `C:\DEV\MasterArbeit\QuellCode\CentronERP` (Branch main, Commit 79c1142f48, Arbeitsstand 2026-08-25)
|
||||
**Methode:** Statische Analyse ohne Ausführung, RRE-Methodenkette Schritte 2–6 (Scope in Schritt 1 vorgegeben: gesamte Codebasis; Schritt 7 Validierung erfolgt extern)
|
||||
**Werkzeug:** Claude Code ohne Agentendateien/MCP (Prompt-only-Baseline)
|
||||
|
||||
---
|
||||
|
||||
## 1. Systemsteckbrief (Ergebnis der Artefakterhebung, Schritt 2)
|
||||
|
||||
| Merkmal | Befund | Beleg |
|
||||
|---|---|---|
|
||||
| Produkt | „NEXOWARE c-entron ERP" (c-entron.NET), Hersteller NEXOWARE Systems GmbH | Directory.Build.props |
|
||||
| Version | 2.0.2611-alpha (Nerdbank GitVersioning) | version.json |
|
||||
| Plattform | .NET 10 (SDK 10.0.100); WPF-Client net10.0-windows; WebService net10.0 (Windows HTTP.sys / Linux Kestrel, Docker vorhanden) | global.json, csproj-Dateien, docker/ |
|
||||
| UI-Technologie | WPF mit DevExpress (Client), Blazor mit DevExpress (Nexus) | DevExpress.Version.props, README.md |
|
||||
| Persistenz | MSSQL; NHibernate; Legacy-Tabellen deutsch (AufKopf, RechPos, Kunden, hlpdsk_requests …), moderne Views englisch; Migration über 764 nummerierte C#-Skripte | docs/reference/receipts/receipts-backend-architecture.md, ScriptMethods/ |
|
||||
| Umfang | 15.554 C#-Dateien, 1.233 XAML-Dateien, 491 Razor-Dateien; 97 BL-Fachbereiche; 88 Entitäts-Fachordner | Zählung per find/ls |
|
||||
| Schnittstellen | RPC-Dienst ICentronRestService (29 Teilbereiche), REST-API v1 (41 Controller), 4 SignalR-Hubs, ~40 anmeldefähige Anwendungen | Centron.Host/Services, Centron.Controllers, ApplicationKind.cs |
|
||||
| Externe Anbindungen | GLS, Shipcloud, FinAPI, ITscope, Icecat, ebInterface, EGIS, COP, docuFORM, EDI-Distributoren (ALSO, Alltron, Herweck, Komsa, OpenTrans), DATEV, Exchange, TAPI, RMM (NAble, GFIMax u. a.), DocBee, TANSS | src/apis, ApplicationKind.cs, edi-architecture.md |
|
||||
| Berechtigungen | ~750 Rechtekonstanten, Gruppenmodell, einschränkende Rechte („nur eigene [Filiale]") | UserRightsConst.cs, CentronRights.md |
|
||||
| Lizenzierung | GUID-Lizenzen mit count/valid-until/version; Modul- und Login-Gates; Startabbruch ohne Lizenz | licensing-system.md, ModuleRegistration.cs, CentronHost.cs |
|
||||
| Konfiguration | ~500 ApplicationSettings, 91 Einstellungsseiten, persönliche Einstellungen | ApplicationSettingID.cs, ModuleRegistration.cs |
|
||||
| Sprachen | Deutsch führend, Englisch als Zweitsprache (resx-Paare); DACH-Spezifika (ESR Schweiz, ebInterface AT, XRechnung DE) | general-structure.md, resx-Dateien |
|
||||
|
||||
## 2. Vorgehensdokumentation (Schritte 2–6)
|
||||
|
||||
- **Schritt 2 – Artefakterhebung:** Repositorystruktur, Projektdateien, 55 Doku-Dateien unter docs/ (Architektur-, DB-, Sicherheits-, Feature-Dokumentation), CentronRights.md, README, Build-/Deploy-Artefakte (azure/, docker/, deployment/), Git-Historie (jüngste Commits als KONTEXT-Belege). Keine SQL-Dateien im Repo – Schema ergibt sich aus Skriptsystem, Mappings und Doku.
|
||||
- **Schritt 3 – Technische Analyse:** Modulinventar aus ModuleRegistration.cs (84 Registrierungseinträge, davon 1 Testmodul, 1 auskommentiert „Reisekosten"); Statusmaschinen (ReceiptState, WebReceiptState, BarcodeState, DunningLevel, EDI-/RMA-/Produktions-Status, konfigurierbare Helpdesk-Status); Validierungslogik (SaveReceipt-Pipeline mit >30 benannten Prüfungen); Berechtigungsprüfungen (UI-Gate, BL-Prüfmuster, API-Attribute); Abhängigkeiten (Schichtenmodell, Dual-Access BL/WS).
|
||||
- **Schritt 4 – Semantische Interpretation:** Technische Beobachtungen wurden in fachliche Soll-Aussagen überführt (Feld `Fakt` → Feld `Aussage` je Anforderung); Beispiele: Negativbuchungs-Login → Vier-Augen-Freigabe; InternalInvoice-Nummernkreis → getrennte 0,00-Dienstleistungsrechnungen; GetClosedHelpdeskState → konfigurierbare Abschlusssemantik.
|
||||
- **Schritt 5 – Formalisierung:** 207 Anforderungen im vorgegebenen Format (35 StRS, 84 SyRS, 88 SwRS) mit Vorbedingung, Fakt, Aussage, Ergebnis, Prüfidee.
|
||||
- **Schritt 6 – Traceability:** Vollständige Aufwärtsverkettung (SwRS→SyRS→StRS) in den Dokumenten; konsolidierte Matrix in Traceability.md inkl. Lückenliste (27 SyRS ohne SwRS-Verfeinerung).
|
||||
|
||||
## 3. Modul-/Komponentenübersicht mit Analysetiefe
|
||||
|
||||
Legende Tiefe: **T** = tief (Kernlogik gelesen), **S** = stichprobenhaft (Signaturen/Struktur/Doku), **E** = nur Existenz erfasst, **–** = nicht analysiert.
|
||||
|
||||
| Fachbereich / Komponente | Tiefe | Bemerkung |
|
||||
|---|---|---|
|
||||
| Belegwesen-Kern (ReceiptBL: Speicherpipeline, Nummern, Versionen, Storno, Kreditlimit, Sperren, Ordner) | T | ca. 800 von 11.441 Zeilen gezielt gelesen; Prüfkatalog vollständig erfasst |
|
||||
| Bestands-/Artikelbuchung, Negativbuchung (ReceiptArticleBookingBL) | T | Entscheidungskette vollständig |
|
||||
| Seriennummern/Barcodes (BarCode, BarcodeState, ReceiptBarcodeBL-Aufrufe) | T/S | Statusmodell vollständig; ReceiptBarcodeBL selbst nur über Aufrufstellen |
|
||||
| Nummernkreise (NumberGroupEnum/BL) | T | inkl. Eindeutigkeitsprüfung |
|
||||
| Rechte-/Lizenzsystem, Modulregistrierung | T | Rechtekatalog strukturell, 84 Modul-Gates vollständig |
|
||||
| Authentifizierung (Host-Auth, Tickets, JWT/OIDC, 2FA, Passwörter) | T | UsersBL/TwoFactorBL/JwtAuthController gelesen; Authenticator-Pipeline nicht (H-12) |
|
||||
| Verträge & automatische Abrechnung (ReceiptContract, AutomaticFacturaBL) | T/S | Datenmodell+Doku tief, BL auf API-Ebene; Berechnungsinnereien nicht |
|
||||
| Vereinfachte Ticketabrechnung (TimerBillingBL) | S | API-Ebene, Rechteprüfung verifiziert |
|
||||
| Helpdesk (Entitäten, Close, Historie), Eskalation | T | CloseBL und EscalationBL gelesen |
|
||||
| Zeiterfassung (HelpdeskTimerBL) | T | Speicherlogik inkl. KI-Kopplung |
|
||||
| Mahnwesen (DunningBL) | T/S | Stopp-/Einstellungslogik gelesen; DunningRunBL nicht |
|
||||
| OPOS, Zahlungseingang, SEPA | S | Struktur/Module/Konditionen; Lauflogik nicht |
|
||||
| Online-Banking (FinAPI) | S | Methodenkatalog vollständig, Interna nicht |
|
||||
| FIBU-Export/DATEV, Kontenfindung | S | Exportstatus + Aufrufstellen |
|
||||
| E-Rechnung ZUGFeRD/XRechnung | S | Doku (Feldmapping) + Dateibestand; XML-Code nicht gelesen |
|
||||
| EDI Distributoren | S | Architektur-Doku + Statusenums; Parser (Gateway) nicht |
|
||||
| Einkauf (Lieferantenbelege, Bestellvorschlag) | S | Nummernkreise, BL-Ordner, Vorschlags-API |
|
||||
| Lager (Stock/StorageArea), Inventur, Kommissionierung | S | Inventur-API gelesen; Buchungsdetails über ReceiptArticleBookingBL |
|
||||
| Versand GLS/Shipcloud | S | API-Projekte + Einstellungen |
|
||||
| Kassenbuch/Barverkauf | S | Buchungs-API; Blockade im neuen Speicherweg verifiziert |
|
||||
| Provisionen | S | Datenmodell vollständig, Berechnung nicht |
|
||||
| Nexus ServiceBoard/Kundenportal/WebCart/WebOffer | S | vollständige Routeninventur; einzelne Komponenten (SignaturePad) identifiziert |
|
||||
| WebAccounts | S | BL-Struktur + Passwortpfad |
|
||||
| REST-API | S | Controllerliste vollständig; 2 Controller im Detail |
|
||||
| RPC-Dienst (ICentronRestService) | E | 29 Teilbereiche inventarisiert, Methoden nicht |
|
||||
| Mail/Vorlagen, MailScanner, Kalender/Exchange, TAPI | S/E | Vorlagenmodell tief (Dunning), Scanner/Sync nur strukturell |
|
||||
| Projekte (CRM/Ticket), Produktion, MSP/RMM, DSGVO | S/E | Struktur, Statusenums, Module |
|
||||
| Reporting/Statistiken, ReportEngine, Reportserver | E | Module+BL-Existenz |
|
||||
| Change-Tracking/Logs (ChangeLog, AnlageLog, ReceiptLog, TimerLog) | T/S | Datenmodelle + Schreibstellen |
|
||||
| Einstellungen (Settings-System) | S | Katalogumfang; einzelne Settings punktuell |
|
||||
| Tests (EndToEnd/Integration/Playwright) | E | als Verifikationsquelle notiert, Inhalte nicht analysiert |
|
||||
| DocuBoard, Chats, SocialMedia, VideoPortal, Riversuite-Familie, PasswordManager-Interna, TradePool, VoucherManagement, IndexSearch, MassUpdate, Mobile-Altmodelle, Tags, WebLinks, SelfCare, ExternalHelpdesk | E/– | nur Namensinventar; keine Anforderungen abgeleitet (bewusste Lücke) |
|
||||
| XAML-Masken des WPF-Clients (1.233 Dateien), Reports/Drucklayouts | – | nicht analysiert; für maskenbezogene Pflichtfeld-/Redundanzanalyse erforderlich |
|
||||
| Gateway-Bibliotheken (EDI-Parser), assemblies/, nugets/ | – | Binär-/Fremdanteile |
|
||||
|
||||
## 4. Konsistenzcheck über das Anforderungs-Set (Ergebnis)
|
||||
|
||||
Durchgeführt per Skriptprüfung über die erzeugten Dokumente (2026-08-25):
|
||||
|
||||
| Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| Doppelte oder mehrfach vergebene IDs | **0 Duplikate** (35 StRS + 84 SyRS + 88 SwRS = 207 eindeutige IDs) |
|
||||
| Anforderungen ohne Beleg | **0** (207/207 mit Belege-Abschnitt; 336 Einzelbelege) |
|
||||
| Anforderungen ohne Prüfidee/Status/Tracelinks/Konsolidierung | **0** (je 207/207) |
|
||||
| Tracelinks auf nicht existierende IDs | **0** (alle referenzierten StRS-/SyRS-/SwRS-IDs liegen in den gültigen Bereichen; geprüft über alle 5 Dokumente inkl. Traceability und Hypothesen) |
|
||||
| Referenzierte Hypothesen-IDs | alle definiert (H-02, H-03, H-04, H-08, H-12 referenziert; H-01…H-16 vorhanden) |
|
||||
| Forward-Traceability StRS→SyRS | vollständig (alle 35 StRS haben mindestens eine SyRS-Verfeinerung) |
|
||||
| Forward-Traceability SyRS→SwRS | 57 von 84 SyRS verfeinert; 27 offene in Traceability.md Abschnitt 2 ausgewiesen |
|
||||
|
||||
## 5. Kennzahlen des Anforderungs-Sets
|
||||
|
||||
| Kennzahl | Wert |
|
||||
|---|---|
|
||||
| Anforderungen gesamt | 207 (StRS 35, SyRS 84, SwRS 88) |
|
||||
| Einzelbelege | 336 – davon PRIMÄR 299 (89 %), SEKUNDÄR 30 (9 %), KONTEXT 7 (2 %) |
|
||||
| Status „belegt" ohne Einschränkung | 189 |
|
||||
| Status „belegt" mit Einschränkungsvermerk | 13 |
|
||||
| Status „belegt; Workaround" | 4 (SHA1-Hashing, Barbeleg-Blockade, Doppel-Speicherweg, StRS-032) |
|
||||
| Status „HYPOTHESE" | 1 (SyRS-009 Kontosperrung – Durchsetzung unbelegt) |
|
||||
| Externe Hypothesen (Hypothesen.md) | 16 (H-01…H-16) |
|
||||
| Konsolidierungskandidaten | 17 markierte Felder (u. a. Adressstamm vs. CRM; Kunden- vs. Accounts-Modell; drei Abrechnungswege; RPC vs. REST; WPF-Ticketliste vs. ServiceBoard; SHA1-Ablösung; Doppel-Speicherweg; WebPassword vs. WebAccount; CRM- vs. Ticket-Projekte; Rechtekonstanten-Ablageort) |
|
||||
|
||||
## 6. Selbstbewertung
|
||||
|
||||
### 6.1 Was wurde vollständig, was stichprobenhaft, was gar nicht analysiert?
|
||||
|
||||
- **Tief analysiert** (Kernlogik gelesen, PRIMÄR-Belege auf Methodenebene): Belegwesen-Speicherweg inkl. aller Prüfungen, Bestands-/Seriennummernbuchung, Nummernvergabe, Rechnungsstorno, Kreditlimit, Beleg-Sperren/-Versionierung, Rechte-/Lizenz-Gates, Anmeldeverfahren (ohne Authenticator-Pipeline), Passwort-/2FA-Logik, Helpdesk-Abschluss, Eskalation, Zeiterfassung, Mahnstopplogik, Vertrags-/Zählerabrechnungs-API, Host-/Startsequenz, Migrations- und Einstellungssystem.
|
||||
- **Stichprobenhaft:** Einkauf, Lager-Randprozesse (Inventur, Kommissionierung), Finanzen-Läufe (OPOS/SEPA/Zahlungseingang), E-Rechnung, EDI, Versand, Provisionen, Portale (Routen statt Verhalten), REST-API (2 von 41 Controllern), Kassenbuch, Projekte, MSP, DSGVO, Kalender/TAPI/MailScanner.
|
||||
- **Gar nicht:** WPF-XAML-Masken (1.233 Dateien) und damit die maskenspezifische Feld-/Pflichtfeld-Redundanz; Reports/Drucklayouts; RPC-Methodeninventar; Gateway-EDI-Parser; Randmodule (DocuBoard, SocialMedia, VideoPortal, Riversuite-Familie, PasswordManager-Interna, TradePool, VoucherManagement u. a.); Testinhalte; DB-Instanz selbst (kein Zugriff – Schemaaussagen stützen sich auf Code/Doku).
|
||||
|
||||
### 6.2 Wo war der Beleg dünn?
|
||||
|
||||
- **KONTEXT-/SEKUNDÄR-lastig:** WebCart-Sortimentsregel (nur README), Timer-Billing-Datumsrecht (nur Commit-Message), automatische Ticketerstellung (Feature-Doku + Entität), C-Sign-Zusammenhang (Commit + Enum + UI-Dateien).
|
||||
- **Struktur- statt Verhaltensbelege:** MailScanner, Exchange-Sync, Produktion, DSGVO-Umfang, MSP-Collector, Provisionsberechnung, OutlookAddIn – hier belegen Dateien/Module die Existenz, nicht die Regeln (entsprechende Einschränkungsvermerke im Status bzw. Hypothesen H-05…H-15).
|
||||
- **Herabgestuft:** SyRS-009 (Kontosperrung) auf HYPOTHESE, da die Durchsetzung im Login nicht nachgewiesen ist (Sicherheitsanforderung ohne PRIMÄR-Beleg der Prüfung).
|
||||
- **Bekannte Beleg-Grenze:** Zeilenangaben referenzieren den analysierten Commit-Stand; die Doku-Dateien unter docs/ sind teils KI-generiert entstanden (Hinweis „ai-codebase-navigation.md" im Repo) – wo möglich wurden Doku-Aussagen gegen Code verifiziert (z. B. Belegarchitektur, Lizenzsystem), sonst als SEKUNDÄR eingestuft.
|
||||
|
||||
### 6.3 Erkenntnisse für eine Folge-Iteration (priorisiert)
|
||||
|
||||
1. **SwRS-Verfeinerung der 27 offenen SyRS** (Traceability Abschnitt 2), vorrangig Finanzen-Läufe (OPOS/Dunning-Run/SEPA), EDI-Verarbeitung und E-Rechnungs-Import (Abrechnungs-/Compliance-Risiko).
|
||||
2. **Hypothesenklärung H-01…H-16**, vorrangig H-02 (Salt), H-03 (GoBD-Festschreibung), H-12 (Kontosperrungs-Durchsetzung), H-16 (REST vs. RPC-Abdeckung) – alle sicherheits- bzw. architekturentscheidend für die SaaS-Neuimplementierung.
|
||||
3. **Maskeninventar WPF (XAML) + ICentronRestService-Methodeninventar** maschinell erzeugen, um (a) die im Prompt vermutete maskenbezogene Redundanz systematisch zu finden und (b) das API-Zielbild zu dimensionieren.
|
||||
4. **Preisfindung als eigener Analyseblock** (ActionPriceBL, ArticleVolumePrices, Sonderpreise, Projektpreise, ReceiptPriceHelperBL, CalculationUtils): hohe fachliche Dichte, bisher nur gestreift – für ein Verkaufssystem zentral.
|
||||
5. **End-to-End-Tests als Verhaltensorakel** auswerten (tests/Centron.Tests.EndToEnd): Sie führen laut Doku DB-Skripte aus, speichern über ReceiptWebServiceBL und prüfen Legacy-Tabellenwerte – ideale Quelle zur Verifikation der hier formulierten Prüfideen.
|
||||
6. **Datenmodell-Gesamtkatalog** aus Centron.DAO-Mappings generieren (Tabellen-/Spalteninventar), um Datenanforderungen vollständig und DB-unabhängig zu belegen.
|
||||
7. **Konsolidierungsentscheidungen vorbereiten:** Die 17 markierten Kandidaten (insb. drei Abrechnungswege, zwei Kundenmodelle, zwei API-Kanäle, zwei Ticket-Frontends) sind Architekturentscheidungen der Neuimplementierung und sollten vor weiterer Detailspezifikation fachlich entschieden werden.
|
||||
|
||||
### 6.4 Einschätzung der Belastbarkeit
|
||||
|
||||
Das Set deckt die abrechnungs-, sicherheits- und berechtigungskritischen Kernpfade mit PRIMÄR-Belegen auf Code-Zeilenebene ab (89 % PRIMÄR-Anteil) und erfüllt die Konsistenzkriterien vollständig. Für eine Web-/SaaS-Neuimplementierung ist es als Ausgangsbasis belastbar; die ausgewiesenen Lücken (Abschnitt 6.1/6.3) und Hypothesen sind explizit und adressierbar. Nicht geeignet ist der Stand als abschließende Spezifikation für die dort genannten Randmodule und für maskengebundene Detailregeln.
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
# Glossar
|
||||
|
||||
Domänenbegriffe der c-entron ERP-Suite, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen, Tabellen, Spalten) bleiben in Originalsprache. Jeder Begriff ist mit dem Artefakt belegt, aus dem er abgeleitet wurde.
|
||||
|
||||
| Begriff | Definition | Artefaktbezug |
|
||||
|---|---|---|
|
||||
| **Beleg (Receipt)** | Oberbegriff für kaufmännische Dokumente der Verkaufs- und Einkaufskette (Angebot, Auftrag, Lieferschein, Rechnung, Abholschein, Gutschrift, Vertrag sowie Lieferanten-Pendants). Alle Belege erben von `ReceiptBase`. | `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs` |
|
||||
| **Belegkopf / Belegposition** | Zweiteilige Belegstruktur: Kopftabelle (`*Kopf`, z. B. `AufKopf`) mit Metadaten und Positionstabelle (`*Pos`, z. B. `AufPos`) mit Einzelpositionen. | `docs/reference/receipts/receipts-backend-architecture.md` |
|
||||
| **Belegversion** | Vollständiger Schnappschuss eines Belegs (Kopf und Positionen) in `*KopfVersions`/`*PosVersions`-Tabellen; jede inhaltliche Änderung erzeugt eine neue Version mit fortlaufender Versionsnummer. | `ReceiptBL.SaveReceipt` (Versionsnummernprüfung), `docs/reference/receipts/receipts-backend-architecture.md` |
|
||||
| **Belegstatus** | Zustand eines Belegs: `offen` (Active=1), `abgeschlossen` (Completed=2), `storniert` (Canceled=3). | `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs` |
|
||||
| **Belegweitergabe (Forwarding)** | Überführung eines Belegs in einen Folgebeleg (z. B. Auftrag → Lieferschein → Rechnung); Positionen tragen dazu einen Ursprungsverweis (`IReceiptItemWithOrigin`). | `ReceiptBL.GetReceiptForwardedInto`, `ReceiptArticleBookingBL.UpdateOrigin` |
|
||||
| **Nummernkreis (NumberGroup)** | Konfigurierbarer Zahlenbereich zur Vergabe fortlaufender Nummern je Belegart bzw. Objekt (31 definierte Kreise, u. a. Angebot, Auftrag, Rechnung, Kunde, Helpdesk), optional filialspezifisch. | `src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs`, `NumberGroupBL.GetNextNumber` |
|
||||
| **I3D** | Standard-Primärschlüsselspalte aller Tabellen (`int IDENTITY(1,1)`, „ID 3develop"); Fremdschlüssel enden auf `...I3D`. | `docs/guides/database/database-conventions.md` |
|
||||
| **Mandant (Mandator)** | Oberste Organisationseinheit (rechtliche Firma) des Systems; Filialen sind Mandanten zugeordnet. | `src/backend/Centron.Entities/Entities/Administration/Company/Mandator.cs`, `Branch.MandatorI3D` |
|
||||
| **Filiale (Branch)** | Organisatorische Untereinheit eines Mandanten mit eigener Adresse, Buchhaltungsnummer und optional eigenen Nummernkreisen; viele Rechte kennen „nur eigene Filiale"-Einschränkungen. | `src/backend/Centron.Entities/Entities/BranchArea/Branch.cs`, `CentronRights.md` |
|
||||
| **Recht (UserRight)** | Ganzzahlig identifizierte Berechtigung (ca. 750 Konstanten), die Benutzern über Gruppen zugeordnet wird; es existieren gewährende und **einschränkende Rechte** („nur eigene", „nur eigene Filiale"). | `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, `CentronRights.md` |
|
||||
| **Lizenz (License)** | Per GUID identifiziertes, kundenbezogenes Freischaltmerkmal mit optionalem `count`, `valid until date`, `valid until version`; steuert Sichtbarkeit von Modulen und Anmeldefähigkeit von Anwendungen. | `docs/reference/security/licensing-system.md`, `LicenseManager` |
|
||||
| **Anwendung (ApplicationKind)** | Am WebService anmeldefähige Client-Anwendung (z. B. c-entron ERP, c-entron Nexus, Service-Board, Outlook Add-In, MailScanner, WebCart); je Anwendung Lizenz-GUID, Ablaufverhalten und ggf. erforderliches/verbietendes Recht. | `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs` |
|
||||
| **Helpdesk / Ticket** | Servicevorgang (Störung, Anfrage) zu einem Kunden mit konfigurierbarem Status, Priorität, Kategorie, Typ, Fälligkeit, Bearbeitern und Historie; Tabelle `hlpdsk_requests`. | `src/backend/Centron.Entities/Entities/CustomerArea/Support/Helpdesk.cs`, `NumberGroupEnum.Helpdesk` |
|
||||
| **Helpdesk-Zeit (HelpdeskTimer)** | Auf ein Ticket erfasste Arbeitszeit mit Start/Stopp, Pausenzeit, Zeittyp, Abrechenbarkeit (`Calculable`), Abrechnungsstatus und optionaler Kundensignatur. | `src/backend/Centron.Entities/Entities/Sales/Support/HelpdeskTimerArea/HelpdeskTimer.cs` |
|
||||
| **Eskalation** | Zeitgesteuerte, bis zu dreistufige Benachrichtigung zu offenen Vorgängen unter Berücksichtigung von Arbeitszeitfenstern und Wochenendregeln. | `src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs` |
|
||||
| **Vertrag (ReceiptContract)** | Beleg für wiederkehrende Leistungen mit Abrechnungsintervall (`BillingIntervalKind/Duration`), automatischer Abrechnung, Kontingenten, Zählern und Laufzeit-/Kündigungsfeldern; Tabellen `VertragKopf`/`VertragPos`. | `docs/reference/receipts/contracts-backend.md` |
|
||||
| **Kontingent** | In einem Vertrag vereinbartes Stunden- oder Wertbudget, dessen Verbrauch fortgeschrieben und ggf. über einen Ausgleichsartikel abgerechnet wird. | `ReceiptContract`-Felder `ContingentUsed*`, `ReceiptContractBL.ContractContingentBalanceCalculation` |
|
||||
| **Zähler-/Klickabrechnung** | Verbrauchsabrechnung (z. B. Drucker-Klicks) über Zählerstände je Gerät mit Freimengen und Staffelpreisen. | `AutomaticFacturaBL.Contracts.cs` (`GetCounterFreeCount`, `GetCounterScalePrices`) |
|
||||
| **Stammblatt (MasterDataList)** | Kundenbezogene Geräte-/Bestandsliste, u. a. zur Verknüpfung von Geräten mit Verträgen. | `UserRightsConst.Sales.Customer.CustomerCommon.SHOW_MASTERDATALIST`, `AutomaticFacturaBL.GetMasterDataList` |
|
||||
| **Barcode / Seriennummer** | Einzelstück-Identifikation eines Artikels mit eigenem Lebenszyklusstatus (`BarcodeState`, z. B. InStock, InOrder, InInvoice, Scrapped) und Verweisen auf Belegpositionen. | `src/backend/Centron.Entities/Entities/Warehousing/BarCode.cs`, `src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs` |
|
||||
| **Negativbuchung** | Lagerbuchung, die den Bestand unter null senkt; nur mit Recht `RIGHT_NEGATIVBUCHUNG` bzw. Freigabe durch berechtigten Kollegen zulässig. | `ReceiptArticleBookingBL.UpdateStock` |
|
||||
| **OPOS** | Offene-Posten-Verwaltung (unbezahlte Rechnungen/Gutschriften) als Grundlage von Zahlungszuordnung und Mahnwesen. | `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs` |
|
||||
| **Mahnstufe (DunningLevel)** | Eskalationsstufe des Mahnwesens: None, Level1–Level3; je Kunde/Beleg per Mahnstopp (befristbar) aussetzbar. | `src/backend/Centron.Interfaces/Sales/Receipts/Invoices/Dunning/DunningLevel.cs`, `DunningBL.GetDunningStopActive` |
|
||||
| **Zahlungskondition (AssetCondition)** | Konfigurierbare Zahlungsbedingung mit bis zu drei Skontostufen, Fälligkeitsregeln (`DueKind`, `DuePlusDays`, `DueAtDay`, `DuePlusMonths`) und Zuordnung zu Belegarten. | `src/backend/Centron.Entities/Entities/Administration/MasterData/AssetCondition.cs` |
|
||||
| **Skonto** | Prozentualer Preisnachlass bei Zahlung innerhalb einer Frist (bis zu 3 Stufen je Zahlungskondition). | `AssetCondition.Skonto1OffDay/Skonto1Percent` u. a. |
|
||||
| **SEPA-Mandat** | Einzugsermächtigung eines Kunden für SEPA-Lastschriften; Belege können ein Mandat referenzieren (`MandatI3D`), Pflicht abhängig von Zahlungskondition. | `ReceiptBL.CheckIfMandatIsNeeded`, `docs`-Modul „SEPA" (`PaymentTransactionAppModuleController`) |
|
||||
| **FIBU-Export** | Übergabe von Belegen an die Finanzbuchhaltung (u. a. DATEV Belegtransfer); exportierte Belege gelten als „an die Buchhaltung übergeben". | `src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs` |
|
||||
| **E-Rechnung (ZUGFeRD/XRechnung)** | Strukturierte elektronische Rechnung; Erzeugung in ZUGFeRD 1.0/2.0/2.1 bzw. XRechnung bis 3.0.1 aus Rechnungs-/Gutschriftsdaten. | `docs/reference/zugferd-field-mapping.md`, `InvoiceZugferdBL.cs` |
|
||||
| **EDI** | Elektronischer Belegaustausch mit Distributoren (ALSO, Alltron, Herweck, Komsa, OpenTrans): Bestellungen, Auftragsbestätigungen, Lieferavis, Rechnungen. | `docs/reference/edi/edi-architecture.md`, `SupplierEdiBL.*` |
|
||||
| **WebAccount** | Anmeldekonto eines Endkunden für Web-Angebote (Kundenportal, WebCart); getrennt vom internen `AppUser`. | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `README.md` (WebCart) |
|
||||
| **WebOffer / C-Sign** | Web-basierte Bereitstellung eines Angebots an Endkunden inkl. Annahme, Änderungswünschen, Ablehnung und digitaler Signatur; Statusmodell `WebReceiptState`. | `src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs`, `src/nexus/CentronNexus/WebOffer/` |
|
||||
| **ServiceBoard (Nexus)** | Blazor-Weboberfläche für Servicemitarbeiter (Ticketlisten, Kanban, Planung, Kundencockpit, Zeiterfassung). | `src/nexus/CentronNexus/ServiceBoard/` (Routen `/serviceboard/...`) |
|
||||
| **Kundenportal (Customer Portal)** | Nexus-Bereich für Endkunden: eigene Tickets, Belege, Dokumente, Formulare. | Routen `/customerportal/...` in `src/nexus/CentronNexus` |
|
||||
| **MyDay** | Persönliche Tages-/Auslastungsplanung der Mitarbeiter mit Import aus Zeiterfassung. | `MyDayEditorAppModuleController`, `MyDayBL.TryUpdateWorkItemFromHelpdeskTimer` |
|
||||
| **Erwartete Events (Expected Events)** | Überwachungsmodul, das das Eintreten erwarteter Ereignisse (z. B. Datenlieferungen) prüft und auswertet. | `ExpectedEventsAppModuleController`, `src/backend/Centron.BL/ExpectedEvents/` |
|
||||
| **MSP** | Managed-Service-Provider-Geschäft; Module MSP-Collector/-Auswertung/-Dashboard aggregieren Abrechnungsdaten externer RMM-/Cloud-Dienste zur Vertragsabrechnung. | `MspCollectorAppModuleController`, `AutomaticFacturaBL.CreateSpecialArticleToContractFromMspEvaluation` |
|
||||
| **RMM** | Remote Monitoring & Management; externe Systeme, deren Nutzungsdaten (z. B. Gerätezahlen) in Vertragsabrechnungen einfließen. | `docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md`, `RmmController.cs` |
|
||||
| **RMA** | Rücksendungs-/Reparaturabwicklung (Werkstatt) mit eigenen Nummernkreisen (RMA, Reparatur, Reparatureingang, Rücksendung). | `NumberGroupEnum` (RMANumber, Repairing, RepairEntrance, Reshipment), `RmaOverviewAppModulController` |
|
||||
| **Kommissionierung** | Zusammenstellung bestellter Ware zu Aufträgen im Lager; Teil-Kommissionierungsaufträge mit eigenem Status. | `PartialCommissionOrderState.cs`, `OrderCommissionAppModuleController` |
|
||||
| **Inventur** | Bestandsaufnahme je Lager mit Inventurgruppen, Lagerabschluss und Verlustbuchung von Seriennummern. | `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs` |
|
||||
| **Kassenbuch** | Erfassung von Barzahlungsvorgängen; Zahlungskonditionen können Kassenbuchwirkung haben (`ChangesCashBook`). | `src/backend/Centron.BL/Sales/CashBooks/`, `AssetCondition.ChangesCashBook` |
|
||||
| **Provisionsschema** | Regelwerk zur Ermittlung von Vertriebsprovisionen mit Kundenzuordnung, Mitarbeiterzielen und -stufen. | `ReceiptProvisionSchema*.cs`, `ProvisionSchemaManagementAppModuleController` |
|
||||
| **Belegsperre (AssetLock)** | Pessimistische Sperre eines Belegs durch das Kurzzeichen des bearbeitenden Mitarbeiters (`Lockuser`), um parallele Bearbeitung zu verhindern. | `src/backend/Centron.BL/Sales/CustomerAssets/AssetLockBL.cs` |
|
||||
| **ConcurrencyControlGuid** | GUID je Belegversion zur optimistischen Konfliktkontrolle beim Speichern. | `ReceiptBase.ConcurrencyControlGuid`, `ReceiptBL` (Vergleich beim Speichern) |
|
||||
| **ChangeLog** | Objektbezogenes Änderungsprotokoll mit Eigenschaft, Alt-/Neuwert, Benutzer und Zeitpunkt. | `src/backend/Centron.Entities/Entities/ChangeTracking/ChangeLog.cs` |
|
||||
| **AnlageLog** | Gemeinsames Belegprotokoll aller Belegarten, unterschieden per `AnlageArt` (1=Angebot … 22=Vertrag). | `docs/reference/receipts/receipts-backend-architecture.md` |
|
||||
| **ObjectKind (CentronObjectKindNumeric)** | Systemweite numerische Typkennung für Objektarten (214 Einträge), verwendet für polymorphe Verweise (`ObjectI3D` + `ObjectKind`). | `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs` |
|
||||
| **Skript (ScriptMethod)** | Nummeriertes Datenbank-Migrationsskript in C# (`ScriptMethod<Nr>`), das beim Start des WebService ausgeführt wird; 764 Skripte im Stand der Analyse. | `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/`, `docs/guides/database/create-scripts.md` |
|
||||
| **Einstellung (ApplicationSetting)** | Zentral verwaltete Konfigurationswerte (ca. 500 IDs) für fachliche und technische Optionen. | `src/backend/Centron.Interfaces/Administration/Settings/ApplicationSettingID.cs` |
|
||||
| **Sonderpreis (SpecialPrice/Sonderpreise)** | Kundenindividuelle Artikelpreise; im WebCart bestimmen sie das für den Endkunden sichtbare Sortiment. | `README.md` (WebCart), `CustomerSpecialArticleBL.cs` |
|
||||
| **Textbaustein** | Wiederverwendbarer Textblock für Belege und Kommunikation. | `TextBlockManagementAppModuleController` |
|
||||
| **Vereinfachte Ticketabrechnung (TimerBilling)** | Modul zur gesammelten Abrechnung erfasster Ticketzeiten in Rechnungen/Lieferscheine ohne Einzelbelegpflege. | `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs` |
|
||||
| **Pauschalabrechnung (FlatRate)** | Abrechnung von Projekten/Leistungen zu Pauschalen. | `FlatRateProjectAppModuleController` |
|
||||
| **DATEV Belegtransfer** | Übertragung von Belegdaten/-bildern an DATEV Online. | `DatevOnlineAppModuleController`, `Modules.DataExchange.DatevOnline2020` |
|
||||
| **DSGVO-Modul** | Funktionen zur Erfüllung von Datenschutzanforderungen (z. B. Auskunft/Löschung, Auftragsverarbeitungsverträge). | `CentronDataSecurityAppModuleController`, `OrderProcessingContractState.cs` |
|
||||
| **Zwei-Faktor-Authentifizierung (2FA)** | Zusätzliche PIN-Prüfung je Benutzer mit hinterlegtem Geheimschlüssel und Gültigkeitsdauer in Tagen. | `TwoFactorAuthenticationBL.cs`, `AppUser.UseTwoFactorAuthentication` |
|
||||
| **Access Token** | Persönlicher API-Zugriffsschlüssel eines Benutzers; Erstellung/Einsicht rechtegebunden. | `UserRightsConst.Administration.AccessTokens`, `AccessTokensController.cs` |
|
||||
+101
@@ -0,0 +1,101 @@
|
||||
# Hypothesen
|
||||
|
||||
Sammlung aller Aussagen, die sich aus den Artefakten nicht eindeutig belegen ließen. Jede Hypothese nennt die betroffenen Anforderungen, die fehlende Information und den vorgeschlagenen Klärungsweg (Schritt 7 der RRE-Methodenkette: Validierung durch Fachexperten).
|
||||
|
||||
---
|
||||
|
||||
## H-01 – Semantik der Eskalations-Selektionskriterien
|
||||
**Betroffene Anforderungen:** SyRS-039, SwRS-068
|
||||
**Aussage [HYPOTHESE]:** Die Filterbedingungen `e.ObArt = 2` und `e.status < 2` in der Eskalations-SQL selektieren „offene ToDo-Objekte vom Typ Ticket"; `et.Status = 1` bedeutet „Eskalationstyp aktiv".
|
||||
**Fehlende Information:** Die Wertebedeutung von `ObArt` und `status` ist im gelesenen Code nicht als Enum/Konstante dokumentiert; die Interpretation stützt sich nur auf Kontext (TDLKind, ToDoType-Cast in EscalationBL.cs:275).
|
||||
**Klärungsweg:** Fachexperten-Review der Escalations-Tabelle bzw. Nachverfolgung der ToDoType-Enumeration.
|
||||
|
||||
## H-02 – Passworthashes ohne Salt
|
||||
**Betroffene Anforderungen:** SwRS-022, SyRS-008
|
||||
**Aussage [HYPOTHESE]:** Die SHA1-Passworthashes werden ohne benutzerindividuelles Salt gebildet; identische Passwörter erzeugen identische Hashwerte.
|
||||
**Fehlende Information:** Die Implementierung von `SHA1Decoder.GetDecodedSHA1String` wurde nicht gelesen; ein internes statisches Salt/Pepper ist nicht ausgeschlossen.
|
||||
**Klärungsweg:** Code-Review von SHA1Decoder (Centron.BL/Core/CryptoUtils.cs bzw. zugehörige Klasse) und Stichprobe zweier Konten mit gleichem Passwort in einer Testdatenbank.
|
||||
|
||||
## H-03 – Keine harte Festschreibung nach FIBU-Export (GoBD)
|
||||
**Betroffene Anforderungen:** SyRS-031, SwRS-043, StRS-025
|
||||
**Aussage [HYPOTHESE]:** Das System kennt keine harte Festschreibung („Unveränderbarkeit") exportierter oder gebuchter Rechnungen; die Warnung mit Bestätigungsmöglichkeit (HandleIsAlreadyExported) ist der einzige Schutzmechanismus. GoBD-konforme Unveränderbarkeit wird über die Versionshistorie, nicht über ein Änderungsverbot angestrebt.
|
||||
**Fehlende Information:** Es wurde nicht die gesamte Codebasis auf weitere Sperrmechanismen (z. B. in BookKeepingExportBL, Perioden-/Abschlusslogik) durchsucht.
|
||||
**Klärungsweg:** Fachexperteninterview zur GoBD-Strategie; gezielte Suche nach Periodensperren/Abschlussdatum-Prüfungen.
|
||||
|
||||
## H-04 – Keine Kassen-Fiskalisierung (TSE)
|
||||
**Betroffene Anforderungen:** SyRS-064, StRS-032
|
||||
**Aussage [HYPOTHESE]:** Das Kassenbuch/der Barverkauf besitzt keine Anbindung an eine technische Sicherheitseinrichtung (TSE) oder andere Fiskalisierungslösungen (Suchbegriffe „TSE", „Fiskal", „fiscal" ohne Treffer in den Kassen-BL-Dateien).
|
||||
**Fehlende Information:** Vollständige Suche über alle Projekte (inkl. Reports/Gateway) steht aus; ggf. erfolgt Fiskalisierung außerhalb der analysierten Codebasis.
|
||||
**Klärungsweg:** Befragung, ob Barverkauf im Produkteinsatz KassenSichV-relevant ist; ggf. bewusste Ausklammerung dokumentieren.
|
||||
|
||||
## H-05 – Bedeutung von HelpdeskStateBase.State
|
||||
**Betroffene Anforderungen:** SwRS-066, SyRS-037
|
||||
**Aussage [HYPOTHESE]:** Das int-Feld `State` an HelpdeskState kodiert eine Basiskategorie des Status (z. B. offen/geschlossen-artig), während der konkrete Abschlussstatus über die Einstellung `GetClosedHelpdeskState` bestimmt wird.
|
||||
**Fehlende Information:** Wertebereich und Auswertungsstellen von `HelpdeskStateBase.State` wurden nicht erhoben.
|
||||
**Klärungsweg:** Verwendungssuche von `.State` auf HelpdeskState-Objekten; Abgleich mit Einstellungsseite „Status".
|
||||
|
||||
## H-06 – WebCart-Bestellweg in die Belegkette
|
||||
**Betroffene Anforderungen:** SyRS-067, StRS-021
|
||||
**Aussage [HYPOTHESE]:** Eine WebCart-Bestellung erzeugt serverseitig einen Verkaufsbeleg (Auftrag oder Web-Beleg mit Überführung), der im WPF-Client weiterbearbeitet wird.
|
||||
**Fehlende Information:** Der konkrete Erzeugungspfad (ReceiptCartBL → Belegart, Statuskette ReceiptCartState) wurde nicht analysiert.
|
||||
**Klärungsweg:** Analyse von ReceiptCartBL/ReceiptCartReleaseSystemBL und ReceiptCartState (inkl. Freigabesystem).
|
||||
|
||||
## H-07 – Währungsbehandlung der Kreditlimitprüfung
|
||||
**Betroffene Anforderungen:** SyRS-023, SwRS-038
|
||||
**Aussage [HYPOTHESE]:** Die Kreditlimitprüfung rechnet implizit in Hauswährung (Anzeige mit `defaultCountry.CurrencySymbol`); Fremdwährungsbelege werden über CurrencyFactor einbezogen. Eine explizite Umrechnungsprüfung war im gelesenen Ausschnitt nicht sichtbar.
|
||||
**Fehlende Information:** Implementierung von GetUsedLimitAmount je Belegart (Fremdwährungsumrechnung) nicht gelesen.
|
||||
**Klärungsweg:** Review der GetUsedLimitAmount-Implementierungen in den SpecificLogic-Klassen.
|
||||
|
||||
## H-08 – Funktionsumfang des DSGVO-Moduls
|
||||
**Betroffene Anforderungen:** SyRS-080, StRS-026
|
||||
**Aussage [HYPOTHESE]:** Das DSGVO-Modul umfasst über die AV-Vertragsverwaltung hinaus weitere Funktionen (z. B. Auskunfts-/Löschprozesse), die hier nicht erhoben wurden.
|
||||
**Fehlende Information:** Inhalt von Modules.Administration.DSGVO (WPF) wurde nicht gelesen.
|
||||
**Klärungsweg:** UI-/Code-Sichtung des DSGVO-Moduls; Abgleich mit Datenschutz-Anforderungen des Zielsystems.
|
||||
|
||||
## H-09 – Führendes Kundendatenmodell (Kunden vs. Accounts)
|
||||
**Betroffene Anforderungen:** StRS-001, SwRS-053
|
||||
**Aussage [HYPOTHESE]:** Das modernere Accounts-Modell (Accounts/AccountCustomer, cvw_AccountSearchAcc) ist das strategisch führende Kundenmodell; die Legacy-Tabelle `Kunden` (Customer-Entität) bleibt aus Kompatibilität parallel bestehen und wird synchron gehalten (Indiz: AccountBL.ExistsAccountForOldCustomer, „IsAccountManagementActive"-Umschaltung).
|
||||
**Fehlende Information:** Synchronisationsmechanik und Migrationsstand zwischen beiden Modellen wurden nicht analysiert.
|
||||
**Klärungsweg:** Fachexperteninterview; Analyse von AccountBL/AdressstammReplacementBL.
|
||||
|
||||
## H-10 – Pausenzeit-Verrechnung in der Zeitdauer
|
||||
**Betroffene Anforderungen:** SwRS-069, SyRS-040
|
||||
**Aussage [HYPOTHESE]:** Die persistierte Dauer `Timer` enthält die Pause noch (Timer = Stop − Start); `LunchTime` wird erst bei Auswertung/Abrechnung abgezogen.
|
||||
**Fehlende Information:** Abrechnungsseitige Verwendung von LunchTime nicht verfolgt.
|
||||
**Klärungsweg:** Analyse der Abrechnungs-/Statistikpfade (TimerBilling, EmployeeHelpdeskTimerStatisticBL) auf LunchTime-Abzug.
|
||||
|
||||
## H-11 – Tiefe des Produktionsmoduls
|
||||
**Betroffene Anforderungen:** SyRS-081, StRS-029
|
||||
**Aussage [HYPOTHESE]:** Das Produktionsmodul deckt einfache Konfektionierung (Stücklisten, Statusverfolgung, Maschinenzuordnung) ab, ohne Kapazitäts-/Terminplanung oder Rückmeldewesen.
|
||||
**Fehlende Information:** ProductionBL/ProductionOrderBL wurden nur oberflächlich gesichtet.
|
||||
**Klärungsweg:** Detailanalyse der Produktions-BL in einer Folgeiteration.
|
||||
|
||||
## H-12 – Durchsetzungsort der Kontosperrfelder
|
||||
**Betroffene Anforderungen:** SyRS-009
|
||||
**Aussage [HYPOTHESE]:** Die Felder IsAccountDisabled/AccountDisabledFrom-/ToDate werden im Anmeldeprozess (Authenticator) ausgewertet und verhindern die Anmeldung im Sperrfenster.
|
||||
**Fehlende Information:** Der Authenticator-Code (AuthenticatorFactory/BasicAuth-Pfad) wurde nicht gelesen.
|
||||
**Klärungsweg:** Review der Authentifizierungs-Pipeline (Centron.WebServices.Core/Interception, AuthenticateAttribute).
|
||||
|
||||
## H-13 – Schweizer ESR-/QR-Zahlteil-Formatstand
|
||||
**Betroffene Anforderungen:** SwRS-059
|
||||
**Aussage [HYPOTHESE]:** Die ESR-Logik entspricht dem klassischen ESR-Verfahren; ob die aktuelle Schweizer QR-Rechnung unterstützt wird, ist unklar.
|
||||
**Fehlende Information:** ReceiptEsrBL und Switzerland-Ordner wurden nicht im Detail gelesen.
|
||||
**Klärungsweg:** Detailanalyse Switzerland-BL; fachliche Prüfung gegen SIX-Spezifikation.
|
||||
|
||||
## H-14 – Zuordnungsregeln des MailScanners
|
||||
**Betroffene Anforderungen:** SyRS-074
|
||||
**Aussage [HYPOTHESE]:** Der MailScanner ordnet eingehende Mails über Ticketnummer im Betreff bzw. Absenderadresse bestehenden Tickets zu und erzeugt sonst neue Tickets gemäß Postfachkonfiguration.
|
||||
**Fehlende Information:** MailScannerBL wurde nicht gelesen (nur Existenz und Konfigurationsseiten belegt).
|
||||
**Klärungsweg:** Codeanalyse MailScannerBL in Folgeiteration.
|
||||
|
||||
## H-15 – Konfliktverhalten der Exchange-Synchronisation
|
||||
**Betroffene Anforderungen:** SyRS-075
|
||||
**Aussage [HYPOTHESE]:** Die Kalender-Synchronisation ist bidirektional mit Konfliktauflösung zugunsten der zuletzt geänderten Quelle.
|
||||
**Fehlende Information:** Synchronisationscode nicht analysiert; das dokumentierte „Bugprotokoll" (docs/features/exchange-sync-bugprotokoll.md) deutet auf komplexe Randfälle.
|
||||
**Klärungsweg:** Analyse der Sync-BL und des Bugprotokolls; Fachexperteninterview.
|
||||
|
||||
## H-16 – Vollständigkeit der REST-API gegenüber dem RPC-Dienst
|
||||
**Betroffene Anforderungen:** SyRS-003, SwRS-088
|
||||
**Aussage [HYPOTHESE]:** Die REST-v1-API deckt nur eine Teilmenge der Fachfunktionen ab; der klassische ICentronRestService (29 Teilbereiche) ist der funktional vollständige Kanal, den WPF-Client und Altintegrationen nutzen.
|
||||
**Fehlende Information:** Methodenzählung/Abgleich beider Kanäle wurde nicht durchgeführt.
|
||||
**Klärungsweg:** Generierter Abgleich der Methodenlisten beider Schnittstellen (Basis für API-Zielbild der Neuimplementierung).
|
||||
+717
@@ -0,0 +1,717 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
|
||||
**System:** NEXOWARE c-entron ERP-Suite (Reverse Requirements Engineering aus Codebasis)
|
||||
**Norm-Bezug:** ISO/IEC/IEEE 29148:2018, Kap. 9.4 (StRS-Informationsgehalt)
|
||||
**Erhebungsstand:** 2026-08-25, Commit 79c1142f48 (Branch main)
|
||||
|
||||
## 1. Zweck und Systemkontext
|
||||
|
||||
Die c-entron ERP-Suite ist ein Warenwirtschafts- und Servicemanagementsystem für IT-Systemhäuser und Managed-Service-Provider im deutschsprachigen Markt (Hersteller: NEXOWARE Systems GmbH, Produktname `NEXOWARE c-entron ERP` laut `Directory.Build.props`). Sie umfasst Verkaufs- und Einkaufsbelegwesen, Vertrags- und Ticketabrechnung, Helpdesk, Lager/Logistik, Finanzen (OPOS, Mahnwesen, SEPA, FIBU-Export, E-Rechnung), Webportale für Endkunden sowie zahlreiche Integrationen (EDI-Distributoren, RMM, Banken, Versanddienste, Telefonie).
|
||||
|
||||
**Identifizierte Akteure (aus Rechten, Modulen und UI abgeleitet):**
|
||||
|
||||
| Akteur | Ableitung |
|
||||
|---|---|
|
||||
| Vertriebsmitarbeiter (Innendienst/Außendienst) | Belegwesen, `SalesRepresentativeI3D`/`OfficeStaffI3D` in `ReceiptContract`; Provisionsmodule |
|
||||
| Servicemitarbeiter / Techniker | Helpdesk-Rechte (`CentronRights.md`), ServiceBoard-Web-UI, Zeiterfassung |
|
||||
| Lagermitarbeiter | Module Inventur, Kommissionierung, Artikelverwaltung (`ModuleRegistration.cs`) |
|
||||
| Einkäufer | Bestellvorschlagsliste, EDI-Verwaltung, Lieferantenbelege (`UserRightsConst.Purchase`) |
|
||||
| Buchhalter / Finanzverantwortlicher | Module Mahnung, OPOS, SEPA, Zahlungseingang, Buchhaltungsexport (`ModuleRegistration.cs` Region „Buchhaltung/Finanzen") |
|
||||
| Controller / Geschäftsführung | Module Analytics, Management Info, Vertragsauswertung |
|
||||
| Administrator | Rechteverwaltung, Mandanten, Mitarbeiter, Einstellungen, SQL-Manager |
|
||||
| Endkunde (des Systemhauses) | WebAccount-Login, Kundenportal-/WebCart-/WebOffer-Routen in `CentronNexus` |
|
||||
| Externe Anwendungen/Partner | `ApplicationKind.cs` (ca. 40 anmeldefähige Anwendungen, u. a. RMM-Konnektoren, DocBee, TANSS) |
|
||||
|
||||
**Hinweis zur Methodik:** Alle Anforderungen sind aus statischer Analyse der Codebasis abgeleitet. `Fakt` = belegte technische Beobachtung; `Aussage` = fachliche Interpretation. Anforderungen ohne PRIMÄR-Beleg in risikobehafteten Bereichen (Sicherheit, Abrechnung, Berechtigungen) sind als `[HYPOTHESE]` markiert.
|
||||
|
||||
---
|
||||
|
||||
## 2. Stakeholder-Anforderungen
|
||||
|
||||
```
|
||||
ID: StRS-001
|
||||
Titel: Einheitliche Kunden- und Adressverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertriebsmitarbeiter, Servicemitarbeiter
|
||||
Vorbedingung: Benutzer ist angemeldet und besitzt Kundenstamm-Rechte
|
||||
Fakt: Es existieren zwei registrierte Adressmodule (AccountManagementAppModuleController und CrmAppModuleController), umgeschaltet über die Einstellung CrmSettings.IsAccountManagementActive; die Customer-Entität führt Zahlungskonditionen je Belegart, Kreditlimit, Preisliste, Bankverbindungen und Dokumentordner je Belegart.
|
||||
Aussage: Das System soll einen zentralen Adress-/Kundenstamm bereitstellen, in dem alle kundenbezogenen Stammdaten (Ansprechpartner, Zahlungs-/Lieferkonditionen, Kreditlimit, Preisfindung, Bankdaten, Dokumente) gepflegt werden und der von allen Modulen (Belege, Tickets, Verträge) referenziert wird.
|
||||
Ergebnis: Jeder Geschäftsvorgang (Beleg, Ticket, Vertrag) ist eindeutig einem Kunden zugeordnet; Konditionen werden automatisch aus dem Kundenstamm übernommen.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/CustomerArea/Customer.cs (PaymentCondition*I3D je Belegart, CreditLimit, PriceList, Bank*) – Begründung: Datenmodell erzwingt kundenbezogene Konditionen als Quelle der Belegerstellung.
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:522-531 – Begründung: Registrierung Adressstamm/CRM inkl. Rechteprüfung UserRightsConst.Sales.Customer.CustomerCommon.ID belegt das Modul als zentralen Einstieg.
|
||||
- [KONTEXT] README.md („create one in c-entron.NET Adressstamm") – Begründung: Bestätigt den Adressstamm als führendes Stammdatenmodul.
|
||||
Prüfidee: Neuanlage eines Kunden mit abweichender Rechnungs-Zahlungskondition; anschließende Rechnungserstellung muss diese Kondition vorbelegen.
|
||||
Tracelinks: SyRS-018, SyRS-022, SyRS-023, SyRS-066
|
||||
Konsolidierung: Kandidat: Doppelstruktur Adressstamm vs. CRM-Modul (per Einstellung umgeschaltet) sowie Legacy-Tabelle Kunden vs. Accounts-Datenmodell – im Zielsystem zu einem Kundenstamm zusammenführen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-002
|
||||
Titel: Durchgängige Verkaufsbelegkette
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertriebsmitarbeiter
|
||||
Vorbedingung: Kunde ist angelegt; Benutzer besitzt Belegrechte
|
||||
Fakt: Die Codebasis implementiert die Belegarten Angebot, Auftrag, Lieferschein, Rechnung, Abholschein, Gutschrift, Vertrag als Ableitungen von ReceiptBase mit Weitergabe-Mechanik (Origin-Verweise) und Statusfortschreibung der Vorgängerbelege.
|
||||
Aussage: Das System soll den Verkaufsprozess als durchgängige Belegkette unterstützen: Angebote können in Aufträge, Aufträge in Lieferscheine/Rechnungen und Lieferscheine in Rechnungen überführt werden, ohne Daten neu zu erfassen.
|
||||
Ergebnis: Folgebelege übernehmen Positionen und Konditionen des Vorgängers; verarbeitete Mengen werden am Ursprungsbeleg fortgeschrieben.
|
||||
Belege:
|
||||
- [PRIMÄR] docs/reference/receipts/receipts-backend-architecture.md (Belegartentabelle AngKopf/AufKopf/LiefKopf/RechKopf/AbholKopf/GutKopf/VertragKopf) – Begründung: dokumentiert die vollständige Belegartenlandschaft mit Tabellenzuordnung; Verzeichnisstruktur src/backend/Centron.Entities/Entities/Sales/Receipts bestätigt sie im Code.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptArticleBookingBL.cs (UpdateOrigin, AddOriginReceiptItemForQuantityProcessedUpdate) – Begründung: Verarbeitete Mengen werden am Ursprungsbeleg fortgeschrieben, was die Kettenlogik durchsetzt.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:3686 (CheckIfItemQuantitiesHaveChangedAlthoughTheItemsHaveBeenForwarded) – Begründung: Änderungsverbot weitergegebener Mengen erzwingt Konsistenz der Kette.
|
||||
Prüfidee: Auftrag mit 2 Positionen in Lieferschein überführen; Ursprungsauftrag muss die verarbeitete Menge ausweisen und eine Mengenreduktion unter die gelieferte Menge ablehnen.
|
||||
Tracelinks: SyRS-018, SyRS-021
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-003
|
||||
Titel: Rechnungsstellung mit Storno und Gutschrift
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Buchhalter, Vertriebsmitarbeiter
|
||||
Vorbedingung: Rechnung existiert
|
||||
Fakt: ReceiptInvoiceBL.CancelInvoice erzwingt für Stornierungen ein eigenes Recht sowie fachliche Vorbedingungen (nicht bereits storniert, keine Barrechnung, nicht weiterverarbeitet, nicht exportiert, bei Vertragsrechnungen nur die letzte); Gutschriften existieren als eigene Belegart (GutKopf).
|
||||
Aussage: Das System soll Rechnungen erzeugen, deren nachträgliche Korrektur nur kontrolliert erfolgt: per berechtigungspflichtigem Storno unter definierten Vorbedingungen oder per Gutschrift.
|
||||
Ergebnis: Stornierte Rechnungen bleiben als neue, als „storniert" gekennzeichnete Version erhalten; die Buchhaltungsintegrität bleibt gewahrt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:143-206 (CancelInvoice) – Begründung: Codifizierte Vorbedingungen und Rechteprüfung RIGHT_RECHNUNGSTORNIEREN setzen die Regel durch.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs (Canceled=3, „storniert") – Begründung: Statusmodell enthält Storno als eigenen Zustand.
|
||||
Prüfidee: Stornoversuch einer bereits an die FIBU exportierten Rechnung muss mit Fehlermeldung abgelehnt werden; Storno einer offenen Rechnung erzeugt neue Version mit Status „storniert".
|
||||
Tracelinks: SyRS-027, SyRS-018
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-004
|
||||
Titel: Wiederkehrende Vertragsabrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Buchhalter, Vertriebsmitarbeiter, MSP-Betreiber
|
||||
Vorbedingung: Vertrag mit Abrechnungsintervall und Positionen existiert
|
||||
Fakt: ReceiptContract führt BillingIntervalKind/-Duration, AutomatedBilling, Kontingent- und Zählerfelder; AutomaticFacturaBL erzeugt Rechnungen aus Verträgen, protokolliert Abrechnungsläufe (StoreBillingResult/LoadBillingResult) und verarbeitet Zählerstände, Freimengen und Staffelpreise.
|
||||
Aussage: Das System soll wiederkehrende Leistungen (Wartung, Miete, MSP-Services, Klick-/Zählerabrechnung) vertragsbasiert in konfigurierbaren Intervallen automatisch fakturieren, inklusive Kontingentverrechnung und nachvollziehbarem Abrechnungsprotokoll.
|
||||
Ergebnis: Je Abrechnungslauf entstehen Rechnungen mit Vertragsbezug; Vertragszähler, Kontingente und „zuletzt abgerechnet"-Daten werden fortgeschrieben.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs (SearchBillingContracts, StoreInvoiceToContract, StoreBillingResult, GetCounterFreeCount, GetCounterScalePrices) – Begründung: implementiert Suche abrechenbarer Verträge, Rechnungszuordnung und Laufprotokoll.
|
||||
- [PRIMÄR] docs/reference/receipts/contracts-backend.md (Billing Configuration, Automated Billing Process) – Begründung: dokumentiert Intervalle (Daily/Monthly/Quarterly/Yearly), AutomatedBilling-Flag und Ablauf; Felder in ReceiptContract.cs nachgewiesen.
|
||||
- [KONTEXT] docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md – Begründung: beschreibt RMM-Artikel-Logik als Teil der Vertragsabrechnung.
|
||||
Prüfidee: Vertrag mit Monatsintervall und Zählerposition anlegen; Abrechnungslauf simulieren und prüfen, dass Freimenge abgezogen, Staffelpreis angewendet und ein Abrechnungsergebnis-Datensatz geschrieben wird.
|
||||
Tracelinks: SyRS-032, SyRS-033, SyRS-034, SyRS-035, SyRS-036
|
||||
Konsolidierung: Kandidat: drei Abrechnungswege (Vertragsabrechnung, vereinfachte Ticketabrechnung, Pauschalabrechnung) mit überlappender Funktion – im Zielsystem als eine Abrechnungs-Engine konsolidierbar.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-005
|
||||
Titel: Ticketbasierter Kundenservice (Helpdesk)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Servicemitarbeiter, Support-Leitung, Endkunde
|
||||
Vorbedingung: Benutzer besitzt Helpdesk-Rechte bzw. Endkunde hat Portalzugang
|
||||
Fakt: Das Helpdesk-Modul umfasst Tickets (hlpdsk_requests) mit konfigurierbaren Status, Prioritäten, Kategorien (Haupt-/Unterkategorien), Typen, Fälligkeit, Bearbeitern, Historie, Verknüpfung zu Geräten, Verträgen und Belegen; Rechte differenzieren Sehen/Anlegen/Bearbeiten/Schließen inkl. „nur eigene"/„nur eigene Filiale".
|
||||
Aussage: Das System soll Servicefälle als Tickets führen, mit konfigurierbarem Statusmodell, Priorisierung, Kategorisierung, Zuständigkeiten, Fälligkeiten und vollständiger Historie, und den Zugriff feingranular nach Rolle, Besitz und Filiale steuern.
|
||||
Ergebnis: Servicefälle sind lückenlos dokumentiert und über Listen (Ticket-Liste, ServiceBoard, Kanban) bearbeitbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/CustomerArea/Support/Helpdesk.cs und HelpdeskState/Priority/Category/Type-Entitäten – Begründung: Datenmodell der Ticketverwaltung mit konfigurierbaren Steuerungsobjekten.
|
||||
- [PRIMÄR] src/webservice/.../Rights/UserRightsConst.cs:1952-2016 (Klasse Helpdesk mit SHOW_HELPDESK, SHOW_HELPDESK_ONLY_OWN, SHOW_HELPDESK_ONLY_OWN_BRANCH, CLOSE_REQUEST u. a.) – Begründung: Rechtekonstanten erzwingen die abgestufte Zugriffssteuerung.
|
||||
- [SEKUNDÄR] CentronRights.md Abschnitt „Helpdesk" – Begründung: dokumentiert die fachliche Bedeutung jedes Helpdesk-Rechts.
|
||||
Prüfidee: Benutzer mit SHOW_HELPDESK_ONLY_OWN darf nur Tickets sehen, in denen er Bearbeiter oder Verantwortlicher ist (Listen- und Detailzugriff testen).
|
||||
Tracelinks: SyRS-037, SyRS-038, SyRS-039, SyRS-069
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-006
|
||||
Titel: Leistungserfassung und Ticketabrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Servicemitarbeiter, Buchhalter
|
||||
Vorbedingung: Ticket existiert; Mitarbeiter hat Zeiterfassungsrechte
|
||||
Fakt: HelpdeskTimer erfasst Start/Stopp/Pause, Zeittyp, Abrechenbarkeit (Calculable), Abrechnungsstatus (BillingStateI3D), Vertragskontext, Kundensignatur (IsSigned) und Referenzen auf Auftrag/Lieferschein/Rechnung; TimerBillingBL und CreateReceiptForHelpdeskTimers erzeugen Belege aus Zeiten; Zuschläge über HourlySurchargeRates.
|
||||
Aussage: Das System soll auf Tickets erfasste Arbeitszeiten (inkl. Anfahrten, Zuschlägen, Pausen, Kundensignatur) verwalten und diese gesammelt in Rechnungen oder Lieferscheine überführen, wobei der Abrechnungsstatus jeder Zeit nachvollziehbar bleibt.
|
||||
Ergebnis: Abgerechnete Zeiten sind mit Belegpositionen verknüpft und gegen unberechtigte Änderung geschützt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Support/HelpdeskTimerArea/HelpdeskTimer.cs (Calculable, BillingStateI3D, IsSigned, OrderAssetItemI3D/DeliveryListAssetItemI3D/InvoiceAssetItemI3D) – Begründung: Datenmodell verankert Abrechnungszustand und Belegverknüpfung je Zeit.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs (SearchTimers, SaveTimer mit ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers, UpdateOrderItems) – Begründung: Abrechnungsmodul mit Rechteprüfung implementiert den Prozess.
|
||||
- [SEKUNDÄR] CentronRights.md („Zeiten bearbeiten", „nur eigene Zeiten", „Unterschrift aus Zeit löschen", „Helpdeskzeiten verschieben… nur wenn nicht Teil eines Belegs") – Begründung: beschreibt die fachlichen Einschränkungen der Zeitbearbeitung.
|
||||
Prüfidee: Zeit mit Signatur erfassen, in Rechnung abrechnen; anschließender Verschiebe-/Löschversuch der Zeit muss abgelehnt werden, Signaturlöschung nur mit Spezialrecht möglich sein.
|
||||
Tracelinks: SyRS-040, SyRS-041, SyRS-042
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-007
|
||||
Titel: Eskalation von Servicefällen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Support-Leitung, Servicemitarbeiter
|
||||
Vorbedingung: Eskalationstypen sind konfiguriert und aktiv
|
||||
Fakt: EscalationBL implementiert bis zu drei Eskalationsstufen mit Wartezeiten (Stunden1-3), Arbeitszeitfenster (WorkTimeFrom/To), Samstag-/Sonntagsschaltern und Mailversand über Vorlagen; Läufe werden protokolliert (EscalationsLog).
|
||||
Aussage: Das System soll überfällige Vorgänge automatisch und mehrstufig eskalieren, dabei Arbeitszeiten und Wochenenden berücksichtigen und jede Eskalation protokollieren, damit Service-Zusagen überwacht werden können.
|
||||
Ergebnis: Verantwortliche werden stufenweise benachrichtigt; Eskalationshistorie ist auswertbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs:223-345 (DoEscalation, ShouldEscalated, SetNextEscDay) – Begründung: implementiert Stufenlogik, Zeitfenster und Wochenendregeln.
|
||||
- [PRIMÄR] EscalationBL.cs:937-994 (WriteLOG, GetEscalationsLog) – Begründung: Protokollierung der Eskalationsläufe ist codiert.
|
||||
Prüfidee: Eskalationstyp mit Stufe 1 = 4 h Wartezeit und Arbeitszeit 8–17 Uhr konfigurieren; Testlauf (TestEscalation) muss außerhalb des Zeitfensters keine, innerhalb eine Stufe-1-Eskalation liefern.
|
||||
Tracelinks: SyRS-039
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-008
|
||||
Titel: Einkaufsabwicklung mit Lieferantenbelegen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Einkäufer, Buchhalter
|
||||
Vorbedingung: Lieferant ist angelegt
|
||||
Fakt: Nummernkreise und Entitäten existieren für Anfrage (AnfrKopf), Bestellung (BestKopf2), Wareneingang (WareKopf), Lieferantenrechnung/Kalkulation (KalkKopf), Lieferantengutschrift (LiGutKopf); BL-Ordner SupplierOrders/SupplierDeliveryLists/SupplierInvoices/SupplierCreditVouchers; Rechteklassen Purchase.Supplier.Offer/Order/DeliveryList/Invoice/CreditVoucher/Contract.
|
||||
Aussage: Das System soll den Einkaufsprozess mit eigener Belegkette (Anfrage, Bestellung, Wareneingang, Lieferantenrechnung, Lieferantengutschrift) und lieferantenbezogenen Rechten unterstützen.
|
||||
Ergebnis: Einkaufsvorgänge sind je Lieferant dokumentiert; Wareneingänge aktualisieren Bestände und Kalkulationen.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs:40-55 (Inquiry→AnfrKopf, PurchaseOrder→BestKopf2, Intake→WareKopf, VendorInvoice→KalkKopf, SupplierCreditVoucher→LiGutKopf) – Begründung: Nummernkreis-Tabellenzuordnung weist die Einkaufsbelegarten nach.
|
||||
- [PRIMÄR] src/webservice/.../UserRightsConst.cs:1801-1845 (Purchase.Supplier.* Rechteklassen) – Begründung: Rechtekonstanten je Einkaufsbelegart belegen die geforderte Zugriffssteuerung.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/SupplierOrders u. a. Ordner – Begründung: eigenständige Geschäftslogik je Lieferantenbelegart existiert.
|
||||
Prüfidee: Bestellung anlegen, Wareneingang buchen; Bestand und Bestellstatus müssen fortgeschrieben werden (Intake-Update in SaveReceipt-Pipeline).
|
||||
Tracelinks: SyRS-046, SyRS-019
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-009
|
||||
Titel: Bestellvorschläge und Distributorenpreisvergleich
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Einkäufer
|
||||
Vorbedingung: Artikelstamm und Distributorendaten vorhanden
|
||||
Fakt: OrderSuggestionList-BL liefert Vorschläge nach Artikel, Auftrag und Lager, Distributorenlisten und eine Preismatrix je EAN/Herstellercode; ITscope- und Icecat-API-Projekte existieren unter src/apis.
|
||||
Aussage: Das System soll Bestellvorschläge aus Bedarfen (Aufträge, Mindestbestände) erzeugen und Preise/Verfügbarkeiten mehrerer Distributoren vergleichbar machen, um die Beschaffung wirtschaftlich zu steuern.
|
||||
Ergebnis: Einkäufer erhalten priorisierte Bestellvorschläge mit Bezugsquellenvergleich.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/*.cs (GetOrderSuggestionArticle/Order/WH, GetDistributors, GetPriceMatrixFromDB) – Begründung: implementiert Vorschlags- und Vergleichslogik.
|
||||
- [PRIMÄR] src/apis/Centron.APIs.ITscopeDataAccess, src/apis/Centron.APIs.IcecatDataAccess – Begründung: Anbindung externer Produkt-/Preisdatenquellen ist als eigene Projekte nachgewiesen.
|
||||
Prüfidee: Artikel mit Unterschreitung des Mindestbestands anlegen; Bestellvorschlagsliste muss den Artikel mit Distributorenpreisen anzeigen.
|
||||
Tracelinks: SyRS-047, SyRS-048
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-010
|
||||
Titel: Lagerführung mit Seriennummernverfolgung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Lagermitarbeiter, Servicemitarbeiter
|
||||
Vorbedingung: Artikel und Läger sind angelegt
|
||||
Fakt: Bestände werden je Artikel und Lager geführt (ArticleStock/SecondaryStock); Belege buchen Bestände automatisch (BookArticles/UnBookArticles); Seriennummern (BarCode) haben einen Lebenszyklusstatus über 28 Zustände und Verweise auf Auftrags-/Liefer-/Rechnungs-/Gerätepositionen.
|
||||
Aussage: Das System soll Lagerbestände artikel- und lagergenau führen, Belegbewegungen automatisch buchen und serialisierte Artikel über ihren gesamten Lebenszyklus (Wareneingang bis Verkauf/RMA/Verschrottung) einzeln verfolgen.
|
||||
Ergebnis: Bestände und Seriennummernstatus sind jederzeit konsistent zur Belegkette.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptArticleBookingBL.cs (UpdateStock; IncrementsStock je Belegart) – Begründung: automatische Bestandsbuchung bei Belegspeicherung ist codiert.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs (28 Statuswerte) und src/backend/Centron.Entities/Entities/Warehousing/BarCode.cs (AufPosI3D, LiefPosI3D, RechPosI3D…) – Begründung: Seriennummern-Lebenszyklus und Belegverweise sind im Datenmodell verankert.
|
||||
Prüfidee: Serialisierten Artikel per Lieferschein ausbuchen; BarCode.State muss auf InDeliveryList/AssignedToDeliveryList wechseln und der Lagerbestand sinken.
|
||||
Tracelinks: SyRS-050, SyRS-051, SyRS-052
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-011
|
||||
Titel: Inventur
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Lagermitarbeiter
|
||||
Vorbedingung: Recht Purchase.Inventory; Läger vorhanden
|
||||
Fakt: InventoryBL implementiert Inventuren mit/ohne Seriennummern, Inventurgruppen, Lagerabschluss (CloseStorages), Zählmengenerfassung (AddArticle) und Verlust-Kennzeichnung von Seriennummern (VerlustInventurI3D, BarcodeState.LostAtStocktaking).
|
||||
Aussage: Das System soll Inventuren je Lager unterstützen: Zählmengen erfassen, Läger für die Zählung abschließen, Differenzen (inkl. verlorener Seriennummern) dokumentieren.
|
||||
Ergebnis: Nach Inventurabschluss sind Bestände korrigiert und Verluste nachvollziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs (AddInventory, CreateInventoryGroup, CloseStorages, IsStockClosed) – Begründung: Inventurprozess vollständig implementiert.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs (LostAtStocktaking=10) – Begründung: Verlustzustand für Seriennummern existiert im Statusmodell.
|
||||
Prüfidee: Inventur ohne Seriennummern anlegen, Lager abschließen; weitere Zählungen auf dem geschlossenen Lager müssen abgelehnt werden.
|
||||
Tracelinks: SyRS-053
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-012
|
||||
Titel: Kommissionierung und Versand
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Lagermitarbeiter
|
||||
Vorbedingung: Auftrag mit lieferbaren Positionen existiert
|
||||
Fakt: Kommissionierungsmodul (OrderCommission) mit PartialCommissionOrderState; Versandanbindungen GLS und Shipcloud als API-Projekte mit Einstellungsseiten und Pakettemplates (ShipcloudPackageTemplate); SaveReceipt aktualisiert referenzierte Kommissionieraufträge.
|
||||
Aussage: Das System soll die Kommissionierung von Aufträgen (auch in Teilaufträgen) unterstützen und Versandaufträge inklusive Paketdaten an Versanddienstleister (GLS, Shipcloud) übergeben.
|
||||
Ergebnis: Gelieferte Mengen und Kommissionierstatus werden fortgeschrieben; Versandlabels können erzeugt werden.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Warehousing/Commissions/PartialCommissionOrderState.cs und ReceiptBL.cs:3849 (UpdatePartialCommissionOrderFromReceipt) – Begründung: Statusmodell und Fortschreibung aus Belegen sind codiert.
|
||||
- [PRIMÄR] src/apis/Centron.Api.Gls, src/apis/Centron.Api.Shipcloud; src/backend/.../ShipcloudPackageTemplateBL.cs – Begründung: Versand-APIs und Paketvorlagen sind implementiert.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs (GlsSettingController, ShipcloudSettingController, OrderCommissionAppModuleController mit Recht Logistic.Commissioning) – Begründung: UI-Module und Rechte bestätigen den Prozessumfang.
|
||||
Prüfidee: Teilkommissionierung eines Auftrags durchführen; Lieferschein-Erstellung muss die kommissionierte Menge übernehmen und den Kommissionierauftragsstatus aktualisieren.
|
||||
Tracelinks: SyRS-054, SyRS-055
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-013
|
||||
Titel: Offene Posten und Mahnwesen
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Buchhalter
|
||||
Vorbedingung: Rechnungen mit Zahlungszielen existieren
|
||||
Fakt: OposBL/OposRunBL und DunningBL/DunningRunBL implementieren OPOS-Listen und Mahnläufe mit drei Mahnstufen, kundenspezifischem Zustellweg (DunningSendType), abweichender Mahnadresse, befristbarem Mahnstopp je Kunde oder Beleg und Mailtext-Variablen.
|
||||
Aussage: Das System soll offene Posten überwachen und ein mehrstufiges Mahnwesen (3 Stufen) bereitstellen, mit kundenindividuellen Zustellwegen, Mahnstopps (befristbar, je Kunde oder Einzelbeleg) und vorlagenbasierten Mahnschreiben.
|
||||
Ergebnis: Überfällige Forderungen werden systematisch angemahnt; Ausnahmen sind dokumentiert.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs (GetDunningStopActive mit Begin/End, UpdateDunningStopAndInfo, UpdateDunningSettingsForCustomer, ThrowIfUserHasInsufficentRights) – Begründung: Mahnstopp-, Einstellungs- und Rechtelogik sind codiert.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/Invoices/Dunning/DunningLevel.cs (None, Level1-3) – Begründung: dreistufiges Mahnstufenmodell.
|
||||
Prüfidee: Kunde mit aktivem, befristetem Mahnstopp: Mahnlauf innerhalb des Zeitraums darf keine Mahnung erzeugen, danach schon.
|
||||
Tracelinks: SyRS-056, SyRS-057
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-014
|
||||
Titel: Zahlungsverkehr und Bankabgleich
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Buchhalter
|
||||
Vorbedingung: Bankverbindungen/Mandate gepflegt
|
||||
Fakt: Module SEPA (PaymentTransaction), Zahlungseingang (Payments), Online-Banking mit FinAPI-Anbindung (Kontoumsätze laden, automatisch zuordnen, Beträge auf Belege buchen, Buchung rückgängig machen, Inspector-Prüfungen); Zahlungskonditionen kennen Lastschrift (DTADebit) und SEPA-Mandatspflicht (CheckIfMandatIsNeeded).
|
||||
Aussage: Das System soll den Zahlungsverkehr unterstützen: SEPA-Lastschriften/-Überweisungen auf Basis von Mandaten, manuelle Zahlungseingangserfassung sowie automatischen Abgleich importierter Bankumsätze mit offenen Posten.
|
||||
Ergebnis: Zahlungen werden Belegen zugeordnet; Zahlungsstatus (PaidFC) und OPOS werden fortgeschrieben.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs (AutoCompleteAccountTransacitons, BookAmountsForAccountTransacitons, UndoBookingForAccountTransaciton) – Begründung: Bankabgleich mit Auto-Zuordnung und Buchung ist implementiert.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:3744 (CheckIfMandatIsNeeded – „Abhängig: Zahlungskondition, Mandat") – Begründung: Mandatspflicht wird beim Belegspeichern durchgesetzt.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs:617-624 (SEPA- und Zahlungseingangs-Module mit Recht INCOMING_PAYMENT_TRANSACTIONS) – Begründung: Modulzuschnitt und Berechtigungen.
|
||||
Prüfidee: Bankumsatz mit Verwendungszweck = Rechnungsnummer importieren; Auto-Zuordnung muss die Rechnung vorschlagen und Buchung den offenen Posten ausgleichen.
|
||||
Tracelinks: SyRS-058, SyRS-059, SyRS-060
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-015
|
||||
Titel: Buchhaltungsübergabe und E-Rechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional, Schnittstelle
|
||||
Akteur: Buchhalter, Endkunde (Rechnungsempfänger), Behörden (XRechnung)
|
||||
Vorbedingung: Abrechnungsdaten vorhanden
|
||||
Fakt: BookKeepingExport/-Import inkl. DATEV-Belegtransfer-Modul; InvoiceZugferdBL erzeugt ZUGFeRD 1.0/2.0/2.1 bzw. XRechnung bis 3.0.1; ZugferdImportController für eingehende E-Rechnungen; ebInterface-API-Projekt (Österreich) vorhanden.
|
||||
Aussage: Das System soll Rechnungsdaten an Finanzbuchhaltungen exportieren (u. a. DATEV) und elektronische Rechnungen in den normierten Formaten ZUGFeRD/XRechnung erzeugen und importieren können.
|
||||
Ergebnis: Formatkonforme E-Rechnungen und FIBU-Übergaben ohne manuelle Doppelerfassung.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs (+ .Zugferd10.cs, XInvoiceVersion3.cs) – Begründung: Formatimplementierung im Code.
|
||||
- [PRIMÄR] src/webservice/Centron.Controllers/Controllers/.../ZugferdImportController.cs – Begründung: Import-Endpunkt existiert.
|
||||
- [SEKUNDÄR] docs/reference/zugferd-field-mapping.md (Versionsliste, Feldzuordnung) – Begründung: dokumentiert unterstützte Versionen und Feld-Mapping.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs:589-599 (Buchhaltungsexport/-import, Datev Belegtransfer mit Rechten DataExchange.BOOKKEEPING_EXPORT/IMPORT) – Begründung: Module und Rechte.
|
||||
Prüfidee: Rechnung als XRechnung 3.0.1 exportieren und mit KOSIT-Validator prüfen (Validator-Referenz in docs/guides/development/xrechnung.md).
|
||||
Tracelinks: SyRS-061, SyRS-062, SyRS-063
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-016
|
||||
Titel: Provisionsabrechnung für den Vertrieb
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertriebsleitung, Buchhalter
|
||||
Vorbedingung: Provisionsschemata definiert
|
||||
Fakt: Entitäten ReceiptProvisionSchema, -SchemaItem, -SchemaCustomerAssignment, -EmployeeGoal, -EmployeeLevel; Module Provisionsauswertung, Provisionsschemas verwalten, Kundenzuordnung mit getrennten Rechten und Lizenzen.
|
||||
Aussage: Das System soll Vertriebsprovisionen regelbasiert ermitteln: Schemata mit Positionen, Kundenzuordnungen, Mitarbeiterzielen und -stufen sowie eine Auswertung je Mitarbeiter.
|
||||
Ergebnis: Nachvollziehbare Provisionsberechnung auf Basis von Belegumsätzen.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptProvisionSchema*.cs, ReceiptProvisionEmployeeGoal.cs, ReceiptProvisionEmployeeLevel.cs – Begründung: vollständiges Datenmodell der Provisionslogik.
|
||||
- [PRIMÄR] ModuleRegistration.cs:426-438 (drei Provisionsmodule mit Rechten PROVISION_EVALUATION_MODULE, PROVISION_SCHEMA_MANAGEMENT, PROVISION_SCHEMA_CUSTOMER_ASSIGNMENT) – Begründung: Modul- und Rechtezuschnitt.
|
||||
Prüfidee: Schema mit Kundenzuordnung anlegen, Beleg fakturieren, Provisionsauswertung muss den Umsatz dem zugeordneten Mitarbeiter zurechnen.
|
||||
Tracelinks: SyRS-065
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-017
|
||||
Titel: Rollenbasierte Zugriffssteuerung mit Besitz- und Filialbezug
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Akteur: Administrator, alle Benutzer
|
||||
Vorbedingung: Benutzer und Gruppen sind angelegt
|
||||
Fakt: Ca. 750 Rechte-IDs (UserRightsConst) werden Benutzern über Gruppen (AppGroup) zugeordnet; Rechteprüfung erfolgt in UI (Modulregistrierung), BL (AppRightsBL.CheckRightsFromUser) und REST-API (Authorize-Attribute); es existieren einschränkende Rechte („nur eigene", „nur eigene Filiale") und eine Administratorengruppe (ADMIN_ACCOUNT = "Administratoren").
|
||||
Aussage: Das System soll den Funktions- und Datenzugriff über ein zentral gepflegtes Rechtesystem steuern, das Rechte in Gruppen bündelt, sowohl gewährende als auch einschränkende Rechte (Besitz-/Filialbezug) kennt und auf allen Ebenen (UI, Geschäftslogik, API) durchgesetzt wird.
|
||||
Ergebnis: Benutzer sehen und bearbeiten ausschließlich die ihren Rechten entsprechenden Module, Funktionen und Datenmengen.
|
||||
Belege:
|
||||
- [PRIMÄR] src/webservice/.../Rights/UserRightsConst.cs (750 Konstanten, Hierarchie nach Fachgebieten) – Begründung: vollständiger Rechtekatalog im Code.
|
||||
- [PRIMÄR] docs/guides/development/check-userrights.md mit AppRightsBL.CheckRightsFromUser-Beispiel aus AccountBL.cs – Begründung: dokumentiertes, im Code verwendetes BL-Prüfmuster.
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs (Rechteprüfung je Modul) – Begründung: UI-Durchsetzung.
|
||||
- [SEKUNDÄR] CentronRights.md – Begründung: fachliche Beschreibung inkl. Konzept „restricting right".
|
||||
Prüfidee: Benutzer ohne CREATE_CUSTOMER erhält beim Anlegen eines Kunden die Fehlermeldung „Fehlende Rechte…" (BL-seitig, auch bei API-Aufruf).
|
||||
Tracelinks: SyRS-006, SyRS-003
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-018
|
||||
Titel: Lizenzbasierte Modul- und Funktionsfreischaltung
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Produktstrategie), Sicherheit
|
||||
Akteur: Hersteller (NEXOWARE), Administrator
|
||||
Vorbedingung: Lizenzdatei/-server verfügbar
|
||||
Fakt: Jedes WPF-Modul wird nur registriert, wenn eine Lizenz-GUID vorliegt (LicenseManager.HasLicense); Anwendungs-Logins validieren count/valid-until/version; der WebService verweigert den Start ohne gültige Lizenz vor dem DB-Verbindungsaufbau.
|
||||
Aussage: Das System soll sämtliche Module und anmeldefähigen Anwendungen über Lizenzen (GUID, Anzahl, Ablaufdatum, Versionsgrenze) freischalten, sodass der Funktionsumfang je Kunde vertragsgemäß steuerbar ist.
|
||||
Ergebnis: Nicht lizenzierte Funktionen sind unsichtbar bzw. nicht anmeldefähig.
|
||||
Belege:
|
||||
- [PRIMÄR] src/webservice/Centron.Host/CentronHost.cs:102-105 (TryLoadLicense vor SetupDatabaseConnection, mit Kommentar) – Begründung: Startabbruch ohne Lizenz ist codiert.
|
||||
- [PRIMÄR] ModuleRegistration.cs (durchgängig LicenseManager.Instance.HasLicense je Modul) – Begründung: Lizenz-Gate je Modul.
|
||||
- [SEKUNDÄR] docs/reference/security/licensing-system.md – Begründung: dokumentiert Lizenzmodell (GUID, count, valid until date/version).
|
||||
Prüfidee: Ohne PasswordManager-Lizenz dürfen die Passwort-Manager-Module nicht in der Modulliste erscheinen.
|
||||
Tracelinks: SyRS-005, SyRS-011
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-019
|
||||
Titel: Mandanten- und Filialorganisation
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Administrator, Geschäftsführung
|
||||
Vorbedingung: Lizenz für Mandanten-/Filialfunktion
|
||||
Fakt: Mandator- und Branch-Entitäten (Branch.MandatorI3D, BookKeepingNumber, eigene Adresse); Nummernkreise optional je Filiale; Belege tragen BranchI3D und BranchOrigin (Ersteller/Betreuer); zahlreiche Rechte mit „nur eigene Filiale"; ZUGFeRD-Verkäuferdaten stammen aus Branch oder Mandator.
|
||||
Aussage: Das System soll mehrere Mandanten mit untergeordneten Filialen abbilden; Belege werden einer Filiale zugeordnet (Regelherkunft: Ersteller oder Vertriebsbetreuer), Nummernkreise und Absenderdaten können je Filiale abweichen, und der Datenzugriff kann auf die eigene Filiale beschränkt werden.
|
||||
Ergebnis: Organisationseinheiten arbeiten getrennt, aber im selben System; Auswertungen sind je Filiale/Mandant möglich.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/BranchArea/Branch.cs (MandatorI3D, BookKeepingNumber) – Begründung: Organisationsmodell im Datenmodell.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:7265-7284 (UpdateReceiptNumber mit branch-spezifischem NumberGroup) und :7309-7340 (GetBranchForNewReceipt nach BranchOrigin) – Begründung: filialabhängige Nummernvergabe und Filialermittlung sind codiert.
|
||||
- [SEKUNDÄR] CentronRights.md (mehrere „nur eigene Filiale"-Rechte) – Begründung: fachliche Filialbeschränkungen.
|
||||
Prüfidee: Zwei Filialen mit getrennten Rechnungsnummernkreisen konfigurieren; Rechnungen beider Filialen müssen aus dem jeweils richtigen Kreis nummeriert werden.
|
||||
Tracelinks: SyRS-013, SyRS-019
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-020
|
||||
Titel: Kundenportal für Endkunden
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Endkunde, Servicemitarbeiter
|
||||
Vorbedingung: Endkunde besitzt WebAccount
|
||||
Fakt: Nexus-Routen /customerportal/... bieten Tickets (Anlage über Formulare/Patterns, Details, Historie, Zeiten, Dokumente), Belege (Liste, Details, PDF-Vorschau, Verträge) und Dokumente; Authentifizierung über eigenen Auth-Pfad /auth/customer; Verwaltung der WebAccounts im Modul management/webaccounts.
|
||||
Aussage: Das System soll Endkunden ein Webportal bieten, in dem sie eigene Tickets erstellen und verfolgen, eigene Belege (inkl. Verträge) einsehen und Dokumente abrufen können, getrennt vom internen Benutzerkreis.
|
||||
Ergebnis: Endkunden-Self-Service reduziert interne Aufwände; Datenzugriff ist auf den jeweiligen Kunden beschränkt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/nexus/CentronNexus Routen (@page "/customerportal/tickets/...", "/customerportal/receipts/...", "/customerportal/documents", "/auth/customer") – Begründung: implementierte Portalfunktionen.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs – Begründung: eigener Kontotyp für Endkunden.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs (HelpdeskCustomerAccessSettingsController) – Begründung: Einstellungen für Kundenzugriff auf Helpdesk.
|
||||
Prüfidee: WebAccount-Login darf nur Tickets/Belege des eigenen Kunden listen (Zugriff auf fremde ticketId per URL muss verweigert werden).
|
||||
Tracelinks: SyRS-066, SyRS-004
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-021
|
||||
Titel: Web-Shop für Endkunden (WebCart)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Endkunde, Vertriebsmitarbeiter
|
||||
Vorbedingung: WebAccount mit Sonderpreisen existiert; WebCart-Lizenz
|
||||
Fakt: Nexus-Routen /webcart (Shop, Warenkorb, Belege inkl. Verträge, Admin); README beschreibt: Sortiment stammt aus den „Sonderpreisen" des Kunden; ApplicationKind.WebCart mit eigener Lizenz und Ablauf aus Einstellungen.
|
||||
Aussage: Das System soll Endkunden einen Web-Shop bieten, dessen Sortiment und Preise aus den kundenindividuellen Sonderpreisen stammen, mit Warenkorb und Bestellauslösung in die Belegkette des Systemhauses.
|
||||
Ergebnis: Endkundenbestellungen entstehen ohne Medienbruch als Belege im ERP.
|
||||
Belege:
|
||||
- [PRIMÄR] src/nexus/CentronNexus/WebCart (Routen /webcart/shop, /webcart/cart/..., /webcart/receipts/...) – Begründung: Shop-Funktionalität implementiert.
|
||||
- [KONTEXT] README.md Abschnitt „WebCart" („available articles come from the customers ‚Sonderpreise'") – Begründung: dokumentiert die Sortimentsregel; Herkunft der Preise ist im Code (CustomerSpecialArticleBL) plausibilisiert, Detailregel dort nicht einzeln verifiziert.
|
||||
Prüfidee: WebAccount ohne Sonderpreise sieht leeren Shop; nach Anlage eines Sonderpreises erscheint der Artikel im Shop.
|
||||
Tracelinks: SyRS-067
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-022
|
||||
Titel: Digitale Angebotsannahme mit Signatur (WebOffer/C-Sign)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Endkunde, Vertriebsmitarbeiter
|
||||
Vorbedingung: Angebot wurde als WebOffer bereitgestellt (Token-Link)
|
||||
Fakt: WebReceiptState kennt SendToCustomer, FirstLoaded, AcceptFullWebReceipt, AcceptWebReceiptWithChangeRequests, Rejected, WebOfferSign, WebOfferSignedWithoutSignature, WebReceiptShutDown; Nexus-Seiten /weboffer/{Token} mit PDF-Vorschau und Signatur-Pad (DocumentSigning/IsolatedSignaturePad.razor); Commit „Ticket 168496 & 169060 - C-Sign (WebOffer & Acceptance)".
|
||||
Aussage: Das System soll Angebote per geschütztem Link an Endkunden ausliefern, deren Reaktion (vollständige Annahme, Annahme mit Änderungswünschen, Ablehnung) erfassen und eine digitale Unterschrift des Kunden aufnehmen; der Bearbeitungsstand ist für den Vertrieb sichtbar.
|
||||
Ergebnis: Angebotsannahme ist ohne Papier dokumentiert; der Angebotsstatus spiegelt die Kundenreaktion.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs – Begründung: Statusmodell der Web-Angebotsannahme inkl. Signaturzustände.
|
||||
- [PRIMÄR] src/nexus/CentronNexus/WebOffer/*, DocumentSigning/IsolatedSignaturePad.razor, Route /weboffer/{Token} und /shareddocuments/{Token}/sign – Begründung: implementierte Kunden-UI inkl. Signatur.
|
||||
- [KONTEXT] Git-Commit 89ccfd650d „C-Sign (WebOffer & Acceptance)" – Begründung: bestätigt Feature-Zuschnitt und Namen.
|
||||
Prüfidee: Angebot als WebOffer versenden, im Browser annehmen und signieren; Status muss auf WebOfferSign wechseln und die Signatur am Vorgang gespeichert sein.
|
||||
Tracelinks: SyRS-068
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-023
|
||||
Titel: Objektbezogene Dokumentenverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: alle internen Benutzer
|
||||
Vorbedingung: Objekt (Kunde, Beleg, Ticket) existiert
|
||||
Fakt: Kunden führen Ordnerverweise je Belegart (RootDir, OrderDir, InvoiceDir, HelpdeskDir …); ReceiptBL.EnsureReceiptDirectoryExists erzeugt beim Speichern automatisch einen Ordner „<Belegart> <Nummer>" unterhalb des passenden Elternordners; Directory-Provider existieren für Helpdesk/Checklisten; DocSync-Modul für Dokumentsynchronisation.
|
||||
Aussage: Das System soll zu jedem Geschäftsobjekt (Kunde, Beleg, Ticket) automatisch eine strukturierte Dokumentenablage bereitstellen, in der zugehörige Dateien (Belege-PDF, Mails, Anhänge) auffindbar sind.
|
||||
Ergebnis: Dokumente sind über die Objektakte auffindbar; Ordner entstehen ohne manuelles Zutun.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:9765-9803 (EnsureReceiptDirectoryExists) – Begründung: automatische Ordnererzeugung je Beleg ist codiert.
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/CustomerArea/Customer.cs:52-66 (Directory-Verweise je Belegart) – Begründung: kundenbezogene Ablagestruktur im Datenmodell.
|
||||
Prüfidee: Neuen Auftrag speichern; im Kunden-Auftragsordner muss ein Unterordner „Auftrag <Nummer>" entstehen und am Beleg (DirectoryI3D) verknüpft sein.
|
||||
Tracelinks: SyRS-071
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-024
|
||||
Titel: Auswertungen und Reporting
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Controller, Geschäftsführung, Vertriebsleitung
|
||||
Vorbedingung: entsprechende Rechte/Lizenzen
|
||||
Fakt: Module Analytics (SaleStatistics), Management Info, Vertragsauswertung, Leistungsnachweise, Mitarbeiterauslastung, MSP-Dashboard; ReportEngine mit Reportverwaltung und Reportserver (zeitgesteuerte Berichte); Excel-/PDF-Export in ReceiptBL.
|
||||
Aussage: Das System soll betriebswirtschaftliche Auswertungen (Umsatz-, Vertrags-, Mitarbeiter-, MSP-Kennzahlen) sowie konfigurierbare Berichte mit zeitgesteuerter Erzeugung bereitstellen.
|
||||
Ergebnis: Entscheidungsrelevante Kennzahlen sind rechtegeschützt abrufbar.
|
||||
Belege:
|
||||
- [PRIMÄR] ModuleRegistration.cs Region „Controlling/Analytics" und :579-581 (ReportServerAppModuleController), :868-870 (ReportEngineAppModuleController) – Begründung: Module inkl. Rechten (z. B. Controlling.Analytics.ID, Administration.REPORTSERVER).
|
||||
- [PRIMÄR] src/backend/Centron.BL/ReportEngine, src/backend/Centron.BL/Statistics – Begründung: Auswertungs-Geschäftslogik vorhanden.
|
||||
Prüfidee: Benutzer ohne Controlling-Rechte darf Management-Info nicht öffnen; Reportserver erzeugt einen geplanten Report zur konfigurierten Zeit.
|
||||
Tracelinks: SyRS-077
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-025
|
||||
Titel: Nachvollziehbarkeit und Revisionsfähigkeit
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Zuverlässigkeit/Compliance)
|
||||
Akteur: Geschäftsführung, Wirtschaftsprüfer, Administrator
|
||||
Vorbedingung: —
|
||||
Fakt: Jede Belegänderung erzeugt eine vollständige Version (Kopf+Positionen) in *Versions-Tabellen; ChangeLog protokolliert Feldänderungen mit Alt-/Neuwert und Benutzer; AnlageLog protokolliert Belegereignisse; Belege tragen CreatedBy/ChangedBy inkl. erzeugender Anwendung und Programmversion; Rechnungsstorno hinterlässt Logeintrag.
|
||||
Aussage: Das System soll alle geschäftsrelevanten Änderungen lückenlos nachvollziehbar machen: vollständige Belegversionshistorie, feldgenaues Änderungsprotokoll, Ereignisprotokolle und Urheber-/Versionskennzeichnung an jedem Datensatz.
|
||||
Ergebnis: Jeder frühere Belegstand ist rekonstruierbar; Änderungen sind personenbezogen zuordenbar.
|
||||
Belege:
|
||||
- [PRIMÄR] docs/reference/receipts/receipts-backend-architecture.md (Version Tables 1:1, SaveAssetVersion-SQL) und ReceiptBL.SaveReceipt (Versionspflicht, WriteReceiptLogs) – Begründung: Versionsmechanik ist Kernbestandteil des Speicherwegs.
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/ChangeTracking/ChangeLog.cs – Begründung: feldgenaues Änderungsprotokoll als Entität.
|
||||
- [PRIMÄR] ReceiptBase.cs:46-52 (CreatedAt/-By, ChangedAt/-By, *ThroughApplicationVersion, ChangedThroughApplication) – Begründung: Urheberkennzeichnung im Datenmodell.
|
||||
Prüfidee: Beleg zweimal ändern; es müssen zwei Versionsdatensätze existieren und der Ursprungszustand vollständig rekonstruierbar sein.
|
||||
Tracelinks: SyRS-020, SyRS-072, SyRS-031
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-026
|
||||
Titel: Datenschutz-Unterstützung (DSGVO)
|
||||
Ebene: StRS
|
||||
Typ: funktional, Sicherheit
|
||||
Akteur: Datenschutzbeauftragter, Administrator
|
||||
Vorbedingung: DSGVO-Lizenz und Recht ACCESS_DSGVO_MODULE
|
||||
Fakt: Eigenes DSGVO-Modul (CentronDataSecurityAppModuleController) mit Recht DsgvoModule.ACCESS_DSGVO_MODULE; Entität OrderProcessingContractState (Auftragsverarbeitungsverträge); Einstellungsseite für AV-Verträge.
|
||||
Aussage: Das System soll Datenschutzprozesse unterstützen, mindestens die Verwaltung von Auftragsverarbeitungsverträgen und einen rechtegeschützten DSGVO-Arbeitsbereich.
|
||||
Ergebnis: Datenschutzrelevante Vorgänge sind zentral und zugriffsgeschützt verwaltbar.
|
||||
Belege:
|
||||
- [PRIMÄR] ModuleRegistration.cs:460-462 (DSGVO-Modul mit Recht und Lizenz) – Begründung: Modulzugang ist rechte- und lizenzgeschützt.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Administration/Documents/Dsgvo/OrderProcessingContractState.cs – Begründung: AV-Vertragsstatus im Code.
|
||||
Prüfidee: Benutzer ohne ACCESS_DSGVO_MODULE sieht das DSGVO-Modul nicht.
|
||||
Tracelinks: SyRS-080
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-027
|
||||
Titel: Kommunikationsintegration (E-Mail, Telefonie, Kalender)
|
||||
Ebene: StRS
|
||||
Typ: funktional, Schnittstelle
|
||||
Akteur: alle internen Benutzer
|
||||
Vorbedingung: Konten/TAPI konfiguriert
|
||||
Fakt: Mail-BL mit Vorlagen und Variablenersetzung; MailScanner-Anwendung (eigene ApplicationKind) und Virtual Mail Assistant-Rechte; TAPI-Server-Anwendung, TapiClientHub (SignalR), Telefonate-Modul; Kalender-Synchronisation (Exchange-Sync-Doku, CalendarSynchronizationSettings); Outlook Add-In als eigene Anwendung.
|
||||
Aussage: Das System soll E-Mail (Versand über Vorlagen, automatisierte Eingangsverarbeitung), Telefonie (Anrufprotokolle, TAPI-Anbindung) und Kalender (Exchange-Synchronisation, Outlook-Integration) in die Vorgangsbearbeitung integrieren.
|
||||
Ergebnis: Kommunikation wird am Vorgang (Ticket/Kunde) dokumentiert; Anrufe und Termine sind mit Stammdaten verknüpft.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs (MailScanner, MailScannerNET, TapiServer, CentronOutlookAddInPro) – Begründung: Integrationen als anmeldefähige Anwendungen.
|
||||
- [PRIMÄR] src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs – Begründung: Telefonie-Echtzeitkanal implementiert.
|
||||
- [SEKUNDÄR] docs/features/exchange-sync-bugprotokoll.md, docs/reference/architecture/tapi.md – Begründung: dokumentierte Exchange-/TAPI-Architektur.
|
||||
Prüfidee: Eingehender Anruf mit bekannter Rufnummer öffnet/protokolliert den Kundenbezug im Telefonate-Modul.
|
||||
Tracelinks: SyRS-073, SyRS-074, SyRS-075, SyRS-076
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-028
|
||||
Titel: Elektronischer Datenaustausch mit Distributoren (EDI)
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Akteur: Einkäufer, Distributor (extern)
|
||||
Vorbedingung: EDI-Konfiguration je Lieferant
|
||||
Fakt: SupplierEdiBL mit herstellerspezifischen Teilimplementierungen (ALSO, ALSO CH, Alltron, Herweck, Komsa, OpenTrans 2.1); Ablauf: FTP/SFTP-Abruf, Formaterkennung, Parsing, Auftragszuordnung, Persistierung, EDI-Log.
|
||||
Aussage: Das System soll Belege (Bestellbestätigungen, Lieferavis, Rechnungen) führender IT-Distributoren automatisiert abrufen, den eigenen Bestellungen zuordnen und verbuchen, mit vollständigem Verarbeitungsprotokoll.
|
||||
Ergebnis: Lieferanten-Belege fließen ohne manuelle Erfassung in die Einkaufsbelegkette.
|
||||
Belege:
|
||||
- [PRIMÄR] docs/reference/edi/edi-architecture.md (Klassenliste SupplierEdiBL.Also/.Alltron/.Herweck/.Komsa/.Opentrans, Ablaufdiagramm, ApplyDistriToCentron) – Begründung: dokumentierte, im Code vorhandene Architektur (Gateway-Projekte Centron.Gateway.EDI_*).
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/EDI/EDILogState.cs, EDIHeadState.cs – Begründung: Verarbeitungsstatusmodell existiert.
|
||||
Prüfidee: Test-EDI-Datei (OpenTrans-Rechnung) einspielen; System muss sie der Bestellung zuordnen und einen EDI-Log-Eintrag mit Status erzeugen.
|
||||
Tracelinks: SyRS-048
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-029
|
||||
Titel: Produktionsaufträge
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Produktionsmitarbeiter
|
||||
Vorbedingung: Produktions-Lizenz
|
||||
Fakt: Module Maschinenverwaltung und Produktionsaufträge (Lizenz ProductionManagement, ohne Rechteprüfung); ProductionOrderBL, ProductionOrderItemState; Nexus-Seite /production/overview.
|
||||
Aussage: Das System soll einfache Produktionsaufträge (Zusammenbau/Konfektionierung) mit Maschinenbezug und Positionsstatus verwalten.
|
||||
Ergebnis: Produktionsvorgänge sind planbar und im Web einsehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs, src/backend/Centron.Interfaces/Production/ProductionOrderItemState.cs – Begründung: Geschäftslogik und Statusmodell vorhanden.
|
||||
- [PRIMÄR] ModuleRegistration.cs:824-832 – Begründung: Modulregistrierung mit Lizenz ProductionManagement.
|
||||
Prüfidee: Produktionsauftrag anlegen; Positionsstatuswechsel müssen den definierten Enum-Werten folgen.
|
||||
Tracelinks: SyRS-081
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-030
|
||||
Titel: Projektverwaltung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Projektleiter, Vertriebsmitarbeiter
|
||||
Vorbedingung: Projektrechte
|
||||
Fakt: CRM-Projekte (CRMProjekt-Nummernkreis, ProjectsAppModuleController) und Ticket-Projekte (TicketProjects-Nummernkreis, TicketProjectBL) existieren; Belege können Projektnummern tragen (CheckIfProjectNumberIsNeeded, CheckCrmProjectShouldBeSet); Projektpreis-Import-Modul.
|
||||
Aussage: Das System soll Projekte führen (Vertriebs-/CRM-Projekte und Abwicklungs-/Ticketprojekte), Belege Projekten zuordnen (auf Wunsch verpflichtend) und projektspezifische Preise unterstützen.
|
||||
Ergebnis: Umsätze und Aufwände sind projektbezogen auswertbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:3717,3732 (CheckCrmProjectShouldBeSet, CheckIfProjectNumberIsNeeded) – Begründung: Projektzuordnung wird beim Belegspeichern geprüft.
|
||||
- [PRIMÄR] NumberGroupEnum (CRMProject=24, TicketProject=29) – Begründung: eigenständige Projektnummernkreise.
|
||||
- [PRIMÄR] ModuleRegistration.cs:539-541, 863-865 (Projekte, Projektpreis-Import) – Begründung: Module inkl. Rechten.
|
||||
Prüfidee: Einstellung „Projektnummer erforderlich" aktivieren; Belegspeicherung ohne Projektnummer muss eine Rückfrage/Fehlermeldung erzeugen.
|
||||
Tracelinks: SyRS-082, SyRS-022
|
||||
Konsolidierung: Kandidat: zwei Projektwelten (CRM-Projekte vs. Ticket-Projekte) – fachliche Zusammenführung im Zielsystem prüfen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-031
|
||||
Titel: Deutschsprachiger Markt und Zweisprachigkeit
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Benutzbarkeit)
|
||||
Akteur: alle Benutzer
|
||||
Vorbedingung: —
|
||||
Fakt: Entwicklungsrichtlinie: alle Benutzertexte deutsch, Ressourcen in LocalizedStrings.resx (de) und .en.resx (en); Fehlermeldungen in BL sind deutsch; Schweiz-spezifische Einstellungen (SwitzerlandSettings, ESR-Felder) und Österreich-Format (ebInterface) existieren.
|
||||
Aussage: Das System soll primär deutschsprachig sein (alle Benutzertexte, Fehlermeldungen), Englisch als zweite Oberflächensprache anbieten und länderspezifische Besonderheiten für DACH (Schweiz: ESR/QR-Zahlteil; Österreich: ebInterface) unterstützen.
|
||||
Ergebnis: Benutzer arbeiten in Deutsch oder Englisch; DACH-Zahlungs-/Rechnungsformate sind verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] docs/getting-started/general-structure.md („German-First Language Policy", resx-Struktur) – Begründung: verbindliche Richtlinie; resx-Dateien im Code vorhanden (z. B. CentronNexus SharedResource.resx/.en-US.resx).
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Switzerland, ReceiptBL.FillEsrFields; src/apis/Centron.Api.EbInterface – Begründung: DACH-Sonderlogik implementiert.
|
||||
Prüfidee: Umschalten der Oberflächensprache auf Englisch; Nexus-Oberflächentexte müssen aus .en-US.resx geladen werden.
|
||||
Tracelinks: SyRS-015
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-032
|
||||
Titel: Barverkauf und Kassenbuch
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertriebsmitarbeiter (Theke), Buchhalter
|
||||
Vorbedingung: Kassenbuch-Rechte
|
||||
Fakt: Nummernkreise Barangebot/Barrechnung; Rechteklassen Sales.Cashbox.BarInvoice/Accountingbook; CashBookBL/CashBookBookingBL verbuchen Zahlungen aus Belegen ins Kassenbuch; der neue SaveReceipt-Weg lehnt Bar-Belege derzeit ab („Aktuell werden leider noch keine Bar-Belege unterstützt.").
|
||||
Aussage: Das System soll Barverkäufe (Barrechnung/Barangebot) und ein Kassenbuch mit automatischer Verbuchung von Barzahlungen unterstützen.
|
||||
Ergebnis: Barzahlungen sind im Kassenbuch dokumentiert und mit Belegen verknüpft.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/CashBooks/CashBookBookingBL.cs (UpdateCashBookBookingFromAsset) – Begründung: Kassenbuchbuchung aus Belegen ist codiert.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:3764-3765 (Ablehnung von IsCashAsset im neuen Speicherweg) – Begründung: belegt Übergangszustand der Barbeleg-Unterstützung.
|
||||
- [SEKUNDÄR] UserRightsConst.Sales.Cashbox (BarInvoice, Accountingbook) – Begründung: Rechtezuschnitt Kasse.
|
||||
Prüfidee: Barrechnung im Altweg erzeugen; Kassenbuch muss die Zahlung ausweisen. Im neuen Speicherweg muss die dokumentierte Ablehnungsmeldung erscheinen.
|
||||
Tracelinks: SyRS-064
|
||||
Konsolidierung: nein
|
||||
Status: belegt; Workaround (Bar-Belege im modernisierten Speicherweg blockiert – Altweg/WPF-Spezialmasken erforderlich)
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-033
|
||||
Titel: Sichere Benutzeranmeldung
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Akteur: alle Benutzer, Administrator
|
||||
Vorbedingung: Benutzerkonto existiert
|
||||
Fakt: AppUser unterstützt Passwort-Anmeldung (SHA1-gehasht), Mindestlänge und Gültigkeitsdauer je Benutzer, zeitfensterbasierte Kontodeaktivierung, 2FA (UseTwoFactorAuthentication, TwoFactorValidDurationInDays, PIN-Validierung) und OpenID-Connect-Anmeldung (OpenIdConnectSubjectIdentifier, EntraIDUsersBL, „Anmelden mit Microsoft"-Doku); Login-Metadaten (Maschine, IP, Zeit) werden gespeichert.
|
||||
Aussage: Das System soll die Anmeldung interner Benutzer absichern: Passwortrichtlinien (Mindestlänge, Ablauf), optionale Zwei-Faktor-Authentifizierung je Benutzer, alternative Anmeldung über OpenID Connect (Microsoft Entra ID) sowie Protokollierung der Anmeldungen.
|
||||
Ergebnis: Nur authentifizierte Benutzer erhalten Zugriff; Anmeldungen sind nachvollziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Administration/AppUser.cs:20-62 (PasswordMinLength, PasswordValidDurationDays, IsAccountDisabled, UseTwoFactorAuthentication, OpenIdConnectSubjectIdentifier, Login*-Felder) – Begründung: Sicherheitsattribute im Datenmodell.
|
||||
- [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs (ValidateAuthenticationPin) – Begründung: 2FA-Prüfung implementiert.
|
||||
- [PRIMÄR] src/webservice/Centron.Host/CentronHost.cs:186-205 (JWT-Bearer mit vollständiger Token-Validierung) – Begründung: OIDC-Tokenprüfung serverseitig.
|
||||
- [SEKUNDÄR] docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md – Begründung: dokumentierter Microsoft-Login.
|
||||
Prüfidee: Benutzer mit aktivierter 2FA muss nach Passwort eine gültige PIN eingeben; abgelaufenes Passwort (PasswordValidDurationDays) muss zum Wechsel zwingen.
|
||||
Tracelinks: SyRS-004, SyRS-007, SyRS-008, SyRS-009
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-034
|
||||
Titel: Persönliche Arbeitsorganisation und Automatisierung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: alle internen Benutzer, Support-Leitung
|
||||
Vorbedingung: —
|
||||
Fakt: Module Mein Tag (MyDay), Todo-Liste, Dashboard, Taskmanagement (Boards), Ticketprozess-Vorlagen, Erwartete Events (+Auswertung), Reportserver; Zeiterfassung erzeugt automatisch Zeitplan-Einträge (CreateOrUpdateTimeSchedule).
|
||||
Aussage: Das System soll persönliche Arbeitssteuerung (Tagesplan, Aufgaben, Dashboards) und teamübergreifendes Taskmanagement inklusive automatischer Ereignisüberwachung (erwartete Events) bereitstellen.
|
||||
Ergebnis: Mitarbeiter sehen Aufgaben/Termine gebündelt; ausbleibende erwartete Ereignisse werden erkannt.
|
||||
Belege:
|
||||
- [PRIMÄR] ModuleRegistration.cs (MyDayEditor, TodoList, CentronDashboard, TaskManagment mit SHOW_TASKMANAGEMENT, ExpectedEvents mit SHOW_EXPECTEDEVENTS) – Begründung: Modulbestand und Rechte.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs:411-419 (ScheduleBL.CreateOrUpdateTimeSchedule) – Begründung: automatische Verzahnung Zeiterfassung → Planung.
|
||||
Prüfidee: Zeiterfassung anlegen; im MyDay-/Planungsbereich muss der zugehörige Zeitplan-Eintrag erscheinen.
|
||||
Tracelinks: SyRS-078, SyRS-069
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-035
|
||||
Titel: MSP-Geschäft mit RMM-Datenintegration
|
||||
Ebene: StRS
|
||||
Typ: funktional, Schnittstelle
|
||||
Akteur: MSP-Betreiber, Buchhalter, externe RMM-Systeme
|
||||
Vorbedingung: MSP-Lizenz; RMM-Konnektoren konfiguriert
|
||||
Fakt: Anmeldefähige Monitoring-Konnektoren (NAble, GFIMax, InvenigateConnector mit ExpirationKind.MonitoringConnector); RmmController/RmmConnectionSettingsController; MSP-Collector/-Comparer/-Dashboard-Module; AutomaticFacturaBL.CreateSpecialArticleToContractFromMspEvaluation überführt MSP-Auswertungsdaten in Vertragspositionen.
|
||||
Aussage: Das System soll Nutzungsdaten externer RMM-/Monitoring-Systeme entgegennehmen, je Kunde auswerten (Collector/Vergleich) und automatisiert in die Vertragsabrechnung überführen.
|
||||
Ergebnis: MSP-Leistungen werden datenbasiert und periodengerecht fakturiert.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs:129-147 (CreateSpecialArticleToContractFromMspEvaluation) – Begründung: Übergabe MSP-Auswertung → Vertrag ist codiert.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs (NAble, GFIMax, InvenigateConnector) – Begründung: RMM-Konnektoren als Anwendungen.
|
||||
- [KONTEXT] docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md – Begründung: dokumentierte RMM-Abrechnungslogik.
|
||||
Prüfidee: MSP-Auswertungsposition erzeugen und in Vertrag überführen; Folgeabrechnung muss die Position fakturieren.
|
||||
Tracelinks: SyRS-036, SyRS-084
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
+1628
File diff suppressed because it is too large
Load Diff
+1626
File diff suppressed because it is too large
Load Diff
+141
@@ -0,0 +1,141 @@
|
||||
# Traceability-Matrix
|
||||
|
||||
Konsolidierte Nachverfolgbarkeit über die drei Ebenen. Regeln:
|
||||
- Jede SwRS-Anforderung referenziert (mindestens) eine SyRS-Anforderung; jede SyRS-Anforderung referenziert (mindestens) eine StRS-Anforderung.
|
||||
- Die Tabelle in Abschnitt 1 zeigt je SwRS die **primäre** Kette (erstgenannter Tracelink); weitere Querbezüge stehen in den Anforderungsdokumenten selbst.
|
||||
- Abschnitt 2 listet SyRS-Anforderungen, die in dieser Iteration noch **ohne SwRS-Verfeinerung** sind (bekannte Lücken, siehe Analysebericht).
|
||||
- Backward-Traceability ergibt sich durch Lesen der Tabelle von rechts nach links.
|
||||
|
||||
## 1. Kette StRS → SyRS → SwRS (je SwRS eine Zeile)
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (primär) |
|
||||
|---|---|---|---|
|
||||
| StRS-017 | SyRS-001 | SwRS-001 | docs/getting-started/general-structure.md (Schichtenmodell) |
|
||||
| StRS-017 | SyRS-001 | SwRS-002 | docs/getting-started/general-structure.md (ClassContainer/ILogic) |
|
||||
| StRS-017 | SyRS-001 | SwRS-003 | Result<T>-Signaturen, z. B. ReceiptBL.SaveReceipt |
|
||||
| StRS-017 | SyRS-002 | SwRS-004 | src/webservice/Centron.Host/CentronHost.cs:100-151 |
|
||||
| StRS-033 | SyRS-004 | SwRS-005 | CentronHost.cs:155-205 (JWT-Validierung) |
|
||||
| StRS-033 | SyRS-004 | SwRS-006 | Centron.BL/Administration/Logins/TicketBL.cs:37-247 |
|
||||
| StRS-033 | SyRS-004 | SwRS-007 | CentronHost.cs:207-216; SecretKeyHandler.cs |
|
||||
| StRS-017 | SyRS-003 | SwRS-008 | Centron.Controllers/Configuration/Routing/KebabCaseTransformer.cs |
|
||||
| StRS-027 | SyRS-010 | SwRS-009 | Centron.Host/RealTimeServices/*.cs (4 Hubs) |
|
||||
| StRS-002 | SyRS-018 | SwRS-010 | docs/reference/receipts/receipts-backend-architecture.md:174-255 |
|
||||
| StRS-025 | SyRS-012 | SwRS-011 | docs/guides/database/database-conventions.md |
|
||||
| StRS-025 | SyRS-012 | SwRS-012 | ScriptMethods/Scripts (764 Dateien); ScriptMethod11820.cs |
|
||||
| StRS-017 | SyRS-014 | SwRS-013 | Centron.Interfaces/Administration/Settings/ApplicationSettingID.cs |
|
||||
| StRS-031 | SyRS-015 | SwRS-014 | LocalizedStrings*.resx; SharedResource*.resx |
|
||||
| StRS-025 | SyRS-016 | SwRS-015 | docs/reference/security/developer-security.md |
|
||||
| StRS-002 | SyRS-018 | SwRS-016 | Centron.Interfaces/CentronObjectKindNumeric.cs |
|
||||
| StRS-017 | SyRS-006 | SwRS-017 | UserRightsConst.cs:10-31 (ID-Räume) |
|
||||
| StRS-017 | SyRS-006 | SwRS-018 | docs/guides/development/check-userrights.md |
|
||||
| StRS-018 | SyRS-005 | SwRS-019 | Centron.WPF.UI/Modules/ModuleRegistration.cs:414-907 |
|
||||
| StRS-018 | SyRS-005 | SwRS-020 | docs/reference/security/licensing-system.md (LicenseManager-API) |
|
||||
| StRS-018 | SyRS-005 | SwRS-021 | Centron.Interfaces/Administration/Logins/ApplicationKind.cs |
|
||||
| StRS-033 | SyRS-008 | SwRS-022 | UsersBL.cs:65-107 (SHA1Decoder) |
|
||||
| StRS-033 | SyRS-008 | SwRS-023 | UsersBL.cs:56-131 (ChangeOwnPassword) |
|
||||
| StRS-033 | SyRS-007 | SwRS-024 | TwoFactorAuthenticationBL.cs:16-43 |
|
||||
| StRS-033 | SyRS-004 | SwRS-025 | JwtAuthController.cs:23-53 |
|
||||
| StRS-033 | SyRS-004 | SwRS-026 | AppUser.cs:38-48; TicketBL.SetLoginIP |
|
||||
| StRS-002 | SyRS-018 | SwRS-027 | ReceiptBase.cs:11-71 |
|
||||
| StRS-002 | SyRS-018 | SwRS-028 | Centron.Interfaces/Sales/Receipts/ReceiptState.cs |
|
||||
| StRS-001 | SyRS-022 | SwRS-029 | ReceiptBL.cs:3535-3900 (SaveReceipt-Pipeline) |
|
||||
| StRS-001 | SyRS-022 | SwRS-030 | ReceiptBL.cs:3562-3566 (Datumspflicht) |
|
||||
| StRS-025 | SyRS-020 | SwRS-031 | ReceiptBL.cs:3568-3578 (Versionsvalidierung) |
|
||||
| StRS-025 | SyRS-020 | SwRS-032 | receipts-backend-architecture.md:147-204 (Versionstabellen) |
|
||||
| StRS-017 | SyRS-006 | SwRS-033 | ReceiptBL.cs:3603-3627 (Rechteprüfungen) |
|
||||
| StRS-002 | SyRS-019 | SwRS-034 | ReceiptBL.cs:7265-7285; NumberGroupBL.cs:50-127 |
|
||||
| StRS-002 | SyRS-019 | SwRS-035 | InvoiceSpecificLogic.cs:104-135 |
|
||||
| StRS-002 | SyRS-030 | SwRS-036 | ReceiptBL.cs:3586-3593; ReceiptBase.cs:65 |
|
||||
| StRS-001 | SyRS-022 | SwRS-037 | ReceiptBL.cs:3703-3761 (Prüfkatalog) |
|
||||
| StRS-001 | SyRS-023 | SwRS-038 | ReceiptBL.cs:8636-8710 (Kreditlimit) |
|
||||
| StRS-002 | SyRS-024 | SwRS-039 | ReceiptBL.cs:3692-3698 (Preisschutz) |
|
||||
| StRS-002 | SyRS-029 | SwRS-040 | ReceiptBL.cs:8600-8634 (Kundenrabatt) |
|
||||
| StRS-002 | SyRS-025 | SwRS-041 | ReceiptBL.cs:9753-9763; AssetCondition.ConcludeImmediatelyTheInvoice |
|
||||
| StRS-023 | SyRS-071 | SwRS-042 | ReceiptBL.cs:9765-9803 (Belegordner) |
|
||||
| StRS-025 | SyRS-031 | SwRS-043 | ReceiptBL.cs:8478-8498 (Exportwarnung) |
|
||||
| StRS-002 | SyRS-026 | SwRS-044 | AssetLockBL.cs:27-104 |
|
||||
| StRS-002 | SyRS-026 | SwRS-045 | ReceiptBL.cs:4808-4890 (ConcurrencyControlGuid) |
|
||||
| StRS-003 | SyRS-027 | SwRS-046 | ReceiptInvoiceBL.cs:143-206 (CancelInvoice) |
|
||||
| StRS-002 | SyRS-021 | SwRS-047 | ReceiptBL.cs:3676-3688, 3741, 3754 |
|
||||
| StRS-032 | SyRS-064 | SwRS-048 | ReceiptBL.cs:3763-3765 (Barbeleg-Blockade) |
|
||||
| StRS-025 | SyRS-072 | SwRS-049 | ReceiptLogBL.cs; AnlageArt-Wertetabelle |
|
||||
| StRS-019 | SyRS-013 | SwRS-050 | ReceiptBL.cs:7309-7340 (BranchOrigin) |
|
||||
| StRS-001 | SyRS-022 | SwRS-051 | ReceiptBL.cs:7287-7307 (Firmengruppen-SQL) |
|
||||
| StRS-002 | SyRS-025 | SwRS-052 | AssetCondition.cs:13-55 |
|
||||
| StRS-001 | SyRS-022 | SwRS-053 | Customer.cs:32-144 |
|
||||
| StRS-013 | SyRS-057 | SwRS-054 | DunningBL.cs:160-182 (Mahnstopp) |
|
||||
| StRS-013 | SyRS-057 | SwRS-055 | DunningBL.cs:341-806 (Zustellprofil/Variablen) |
|
||||
| StRS-014 | SyRS-060 | SwRS-056 | OnlineBankingAccountTransactionsBL.cs:75-1345 |
|
||||
| StRS-015 | SyRS-061 | SwRS-057 | BookKeepingExportBL.cs:201-209 |
|
||||
| StRS-015 | SyRS-062 | SwRS-058 | InvoiceZugferdBL.cs; zugferd-field-mapping.md |
|
||||
| StRS-014 | SyRS-059 | SwRS-059 | ReceiptBL.cs:3822-3826 (ESR) |
|
||||
| StRS-004 | SyRS-032 | SwRS-060 | ReceiptContract.cs (contracts-backend.md:42-127) |
|
||||
| StRS-004 | SyRS-033 | SwRS-061 | AutomaticFacturaBL.Contracts.cs:2101-2120 |
|
||||
| StRS-004 | SyRS-034 | SwRS-062 | AutomaticFacturaBL.Contracts.cs:504-786 |
|
||||
| StRS-004 | SyRS-035 | SwRS-063 | ReceiptBL.cs:3781-3788 (Kontingente) |
|
||||
| StRS-004 | SyRS-036 | SwRS-064 | AutomaticFacturaBL.cs:129-427 |
|
||||
| StRS-005 | SyRS-037 | SwRS-065 | Helpdesk.cs:17-72 |
|
||||
| StRS-005 | SyRS-037 | SwRS-066 | HelpdeskStateBase.cs; HelpdeskCloseBL.cs:112 |
|
||||
| StRS-005 | SyRS-038 | SwRS-067 | HelpdeskCloseBL.cs:108-157 |
|
||||
| StRS-007 | SyRS-039 | SwRS-068 | EscalationBL.cs:215-345 |
|
||||
| StRS-006 | SyRS-040 | SwRS-069 | HelpdeskTimerBL.cs:353-429 |
|
||||
| StRS-006 | SyRS-041 | SwRS-070 | HelpdeskTimer.cs (+Base) |
|
||||
| StRS-006 | SyRS-040 | SwRS-071 | HelpdeskTimerBL.cs:173-235 (Zuschläge) |
|
||||
| StRS-006 | SyRS-042 | SwRS-072 | TimerBillingBL.cs:451-476 |
|
||||
| StRS-005 | SyRS-044 | SwRS-073 | HelpdeskCreationTemplate.cs |
|
||||
| StRS-010 | SyRS-050 | SwRS-074 | ReceiptArticleBookingBL.cs:296-366 |
|
||||
| StRS-010 | SyRS-051 | SwRS-075 | ReceiptArticleBookingBL.cs:366-404 |
|
||||
| StRS-010 | SyRS-052 | SwRS-076 | BarcodeState.cs; BarCode.cs |
|
||||
| StRS-010 | SyRS-052 | SwRS-077 | ReceiptBL.cs:3667-3674, 3767-3771, 3873-3884 |
|
||||
| StRS-011 | SyRS-053 | SwRS-078 | InventoryBL.cs:75-797 |
|
||||
| StRS-012 | SyRS-054 | SwRS-079 | ReceiptBL.cs:3848-3851 |
|
||||
| StRS-022 | SyRS-068 | SwRS-080 | WebReceiptState.cs |
|
||||
| StRS-020 | SyRS-066 | SwRS-081 | Nexus-@page-Routen (Routenbäume) |
|
||||
| StRS-020 | SyRS-066 | SwRS-082 | WebAccountBL.cs; UsersBL.cs:56-75 |
|
||||
| StRS-027 | SyRS-073 | SwRS-083 | MailTemplateReferences.cs; DunningBL.cs:485 |
|
||||
| StRS-034 | SyRS-079 | SwRS-084 | HelpdeskTimerBL.cs:421-466 (KI-Bewertung) |
|
||||
| StRS-025 | SyRS-072 | SwRS-085 | ChangeLog.cs |
|
||||
| StRS-017 | SyRS-003 | SwRS-086 | HelpdesksController.cs:16-67 |
|
||||
| StRS-025 | SyRS-072 | SwRS-087 | ReceiptBL.cs:3616-3633 (Aktivitäten) |
|
||||
| StRS-017 | SyRS-003 | SwRS-088 | Controllers/v1-Dateiliste; KebabCaseTransformer.cs |
|
||||
|
||||
## 2. SyRS-Anforderungen ohne SwRS-Verfeinerung (bekannte Lücken dieser Iteration)
|
||||
|
||||
Diese Systemanforderungen sind belegt, aber noch nicht auf Software-/Komponentenebene verfeinert. Sie sind Kandidaten für die nächste Iteration (siehe Analysebericht, Abschnitt Selbstbewertung).
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (primär) |
|
||||
|---|---|---|---|
|
||||
| StRS-018 | SyRS-011 | – (nur Startsequenz in SwRS-004) | CentronHost.cs:102-108 |
|
||||
| StRS-033 | SyRS-009 | – (Feldmodell in SwRS-026) | AppUser.cs:28-32 |
|
||||
| StRS-018 | SyRS-017 | – | CentronHost.cs OS-Weiche; docker/; deployment/ |
|
||||
| StRS-002 | SyRS-028 | – (Teilabdeckung im Prüfkatalog SwRS-037) | ReceiptBL.cs:3703, 3745-3746 |
|
||||
| StRS-005 | SyRS-043 | – | UserRightsConst.…Checklists; CentronChecklistItemState.cs |
|
||||
| StRS-005 | SyRS-045 | – | NumberGroupEnum (RMA*); RmaClosedState.cs |
|
||||
| StRS-008 | SyRS-046 | – | Supplier*-BL-Ordner; NumberGroupEnum:40-55 |
|
||||
| StRS-009 | SyRS-047 | – | OrderSuggestionList-BL:589-1088 |
|
||||
| StRS-028 | SyRS-048 | – | docs/reference/edi/edi-architecture.md |
|
||||
| StRS-008 | SyRS-049 | – | SupplierPdfScanConfigs.cs |
|
||||
| StRS-012 | SyRS-055 | – | Centron.Api.Gls; Centron.Api.Shipcloud |
|
||||
| StRS-013 | SyRS-056 | – | OposBL.cs; OposRunBL.cs |
|
||||
| StRS-014 | SyRS-058 | – | IncomingPaymentBL.cs |
|
||||
| StRS-015 | SyRS-063 | – | ZugferdImportController.cs |
|
||||
| StRS-016 | SyRS-065 | – | ReceiptProvision*-Entitäten |
|
||||
| StRS-021 | SyRS-067 | – | Nexus /webcart-Routen; README.md |
|
||||
| StRS-027 | SyRS-070 | – | CentronNexus.OutlookAddIn |
|
||||
| StRS-027 | SyRS-074 | – | MailScannerBL.cs |
|
||||
| StRS-027 | SyRS-075 | – | Centron.BL/Calendar; AppointmentRequestState.cs |
|
||||
| StRS-027 | SyRS-076 | – | TapiClientHub.cs; ApplicationKind.TapiServer |
|
||||
| StRS-024 | SyRS-077 | – | ModuleRegistration.cs:631-668; Statistics-BL |
|
||||
| StRS-034 | SyRS-078 | – | Centron.BL/ExpectedEvents |
|
||||
| StRS-026 | SyRS-080 | – | ModuleRegistration.cs:460-462; OrderProcessingContractState.cs |
|
||||
| StRS-029 | SyRS-081 | – | ProductionOrderBL.cs; ProductionOrderItemState.cs |
|
||||
| StRS-030 | SyRS-082 | – | TicketProjectBL.cs; NumberGroupEnum (Projekte) |
|
||||
| StRS-025 | SyRS-083 | – | DataQualityService.md; HelpdeskTimerBL.cs:468 |
|
||||
| StRS-035 | SyRS-084 | – | ModuleRegistration.cs:651-663; UserRightsConst.MspCollector |
|
||||
|
||||
## 3. Abdeckungsübersicht
|
||||
|
||||
- **StRS:** 35 Anforderungen; alle 35 durch mindestens eine SyRS-Anforderung verfeinert (vollständige Forward-Traceability StRS→SyRS).
|
||||
- **SyRS:** 84 Anforderungen; 57 mit mindestens einer SwRS-Verfeinerung, 27 nur auf Systemebene (Tabelle Abschnitt 2; Zählung inkl. Teilabdeckungen konservativ).
|
||||
- **SwRS:** 88 Anforderungen; jede referenziert mindestens eine existierende SyRS-ID (geprüft, siehe Analysebericht Konsistenzcheck).
|
||||
- Jede Zeile in Abschnitt 1 nennt einen konkreten Artefaktbeleg; die vollständigen Beleglisten (inkl. Klassifikation PRIMÄR/SEKUNDÄR/KONTEXT) stehen in den Anforderungsdokumenten.
|
||||
+208
@@ -0,0 +1,208 @@
|
||||
# Messprotokoll – V1-Fable (solo, `claude-fable-5`, Effort `max`) – Prompt-Version 01, Lauf 22 (Lauf P)
|
||||
|
||||
> **Neue Messreihe mit zwei geänderten Variablen.** Gegenüber allen 21 Vorläufen wechseln
|
||||
> **gleichzeitig Modell und Effort**: `claude-fable-5` statt Sonnet/Opus, `max` statt `high`.
|
||||
> Ein Unterschied im Ergebnis lässt sich deshalb **nicht eindeutig** einer der beiden Ursachen
|
||||
> zuschreiben. Für eine kausale Trennung fehlt der Zwischenpunkt Fable auf `high`.
|
||||
>
|
||||
> **Parallelbetrieb:** zwei gleichzeitige Läufe (P, Q). **Wanduhrzeit, `duration_ms` und
|
||||
> `duration_api_ms` sind verzerrt.** Tokenverbrauch, Anforderungsanzahl und Denials sind
|
||||
> unverzerrt.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `Versuche/Versuch_01/01_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `1B0DB06B8E0A5B92A5EFBDBEC5A0C554351FC928A16AEF34AAD9EAA0893C02FF`
|
||||
(identisch zu allen bisherigen Läufen)
|
||||
- **Startzeit:** 2026-08-25T21:09:18+02:00
|
||||
- **Endzeit:** 2026-08-25T21:58:44+02:00
|
||||
- **Dauer gesamt:** 00:49:26 (Wanduhr, **parallelbetriebsbedingt verzerrt**) bzw. 00:49:23 (`duration_ms`) — API: 00:46:57
|
||||
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||
- **Codebasis-Commit:** `79c1142f489a32ba6a4a4cb043fd7f8550a9f257` (dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: **ja** (strenge Prüfung: 0 Treffer);
|
||||
Remote entkoppelt: **ja**
|
||||
- **Prompt-Repo-Commit:** `0ec86aed8cb8781054c86cbe0dd9f5eb0f7e5f05`
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Laufverzeichnis-ID:** `v3.6.0-7adf`
|
||||
- **Ablage:** `Iteration 1/claude-fable-5/solo/max/`
|
||||
- **Parallele Läufe:** ja – `fable5_solo_v3.6.0-58d2`
|
||||
- **Skill-Version:** `3.6.0`
|
||||
- **Claude-Code-Version:** 2.1.245
|
||||
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.245-win32-x64\resources\native-binary\claude.exe`
|
||||
- **Agentenmodus:** `solo` (V1) – erzwungen über `--disallowedTools Task Agent Workflow`
|
||||
- **Effort:** **`max`** – explizit per `--effort` gesetzt; Gegenprobe im Transkript: 235
|
||||
Nachrichten, durchgängig `max`. **Erster Block, der vom bisherigen `high` abweicht.**
|
||||
- **Modell:** `claude-fable-5` (vom Versuchsleiter vor dem Lauf gewählt); zusätzlich
|
||||
`claude-haiku-4-5-20251001` für interne Hilfsaufrufe (4.193 Input-/22 Output-Tokens)
|
||||
- **Permission-Mode:** `acceptEdits`
|
||||
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"`; `--disallowedTools` mit 36 Einträgen
|
||||
(22 × `Bash(...)`, 11 × `PowerShell(...)`, 3 × Agentenwerkzeuge)
|
||||
- **Isolationsmechanismus:** eingefrorener Codebasis-Snapshot ohne KI-Konfigurationen,
|
||||
zusätzlich `--safe-mode` und `--strict-mcp-config`
|
||||
- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
|
||||
- **Subagenten:** **0** (durch die Versuchsbedingung ausgeschlossen)
|
||||
- **Verschachtelung:** `spawned` = 0, `spawned_by_subagents` = 0, `max_depth` = 0
|
||||
- **Fast-Mode:** aus
|
||||
|
||||
## Verbrauch
|
||||
|
||||
### Hauptagent (`usage`)
|
||||
| Messgröße | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 270 |
|
||||
| Output-Tokens | 230.990 (davon 35.220 Thinking-Tokens) |
|
||||
| Cache-Write-Tokens | 427.305 |
|
||||
| Cache-Read-Tokens | 23.562.775 |
|
||||
| Agent-Turns | 152 |
|
||||
|
||||
### Gesamtlauf (`modelUsage`)
|
||||
| Messgröße | `claude-fable-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||
|---|---:|---:|---:|
|
||||
| Input-Tokens | 270 | 4.193 | 4.463 |
|
||||
| Output-Tokens | 230.990 | 22 | 231.012 |
|
||||
| Cache-Write-Tokens | 427.305 | 0 | 427.305 |
|
||||
| Cache-Read-Tokens | 23.562.775 | 0 | 23.562.775 |
|
||||
| Tokens gesamt | 24.221.340 | 4.215 | **24.225.555** |
|
||||
|
||||
**Tokens gesamt: 24.225.555** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
|
||||
Ohne Subagenten sind Haupt- und Gesamtwerte für `claude-fable-5` identisch.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** erfolgreich (`is_error: false`, `terminal_reason: "completed"`,
|
||||
`stop_reason: "end_turn"`, Exit-Code 0, `Stderr.log` leer)
|
||||
- **Session-ID:** `5155f938-271d-4e03-85fc-002f1702c15d`
|
||||
- **Permission-Denials:** **1** – 1 × `Read` (ohne Kommandoangabe im Datensatz). Folgenlos, alle 7 Artefakte entstanden.
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = **0** – die Sperre hat gegriffen,
|
||||
der Lauf ist als V1-Messung gültig
|
||||
- **Subagenten-Prompts:** entfällt (Modus `solo`)
|
||||
- **Erzeugte Dateien:** alle 7 geforderten Artefakte in `Ergebnisse\`, **keine Fremddateien**
|
||||
|
||||
| Datei | Größe | Inhalt |
|
||||
|---|---:|---|
|
||||
| `StRS.md` | 59.716 B | 35 Anforderungen |
|
||||
| `SyRS.md` | 118.720 B | 84 Anforderungen |
|
||||
| `SwRS.md` | 98.672 B | 88 Anforderungen |
|
||||
| `Traceability.md` | 10.513 B | konsolidierte Tabelle |
|
||||
| `Hypothesen.md` | 9.138 B | Sammlung der `[HYPOTHESE]`-Aussagen |
|
||||
| `Glossar.md` | 13.918 B | Domänenbegriffe |
|
||||
| `Analysebericht.md` | 14.508 B | Modulabdeckung, Konsistenzcheck, Selbstbewertung |
|
||||
|
||||
Summe: **207 Anforderungen** über drei Ebenen.
|
||||
- **Root unverändert:** ja. `git status --porcelain` vor und nach dem Lauf leer, HEAD `79c1142`.
|
||||
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
|
||||
|
||||
## 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 | 35 | 16,9 % |
|
||||
| SyRS | 84 | 40,6 % |
|
||||
| SwRS | 88 | 42,5 % |
|
||||
| **Gesamt** | **207** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 86 | 41,5 % |
|
||||
| Daten | 18 | 8,7 % |
|
||||
| Sicherheit | 17 | 8,2 % |
|
||||
| Schnittstelle | 15 | 7,2 % |
|
||||
| funktional (Abrechnung) | 9 | 4,3 % |
|
||||
| funktional / Daten | 8 | 3,9 % |
|
||||
| funktional / Schnittstelle | 5 | 2,4 % |
|
||||
| Architektur-Constraint | 4 | 1,9 % |
|
||||
| Daten / funktional | 4 | 1,9 % |
|
||||
| funktional, Schnittstelle | 3 | 1,4 % |
|
||||
| (29 weitere) | 38 | 18,4 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 336 |
|
||||
| davon `PRIMÄR` | 299 (89,0 %) |
|
||||
| davon `SEKUNDÄR` | 30 (8,9 %) |
|
||||
| davon `KONTEXT` | 7 (2,1 %) |
|
||||
| Belege je Anforderung (Median) | 1 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 207 (100,0 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
**nicht erhoben** – das Feld `Übernahmewürdigkeit` wurde erst mit der Prompt-Fassung vom 2026-08-26 eingeführt und liegt für diesen Lauf nicht vor. Hinweise auf Workarounds stecken ersatzweise im Feld `Status`.
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 203 | 98,1 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 4 | 1,9 % |
|
||||
| als Workaround vermerkt | 4 | 1,9 % |
|
||||
| Konsolidierungskandidaten | 17 | 8,2 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 0 | 0,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** (68 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | *nicht erhoben* (Feld erst ab Prompt-Fassung 2026-08-26) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 207 von 207 mit Tracelinks (100,0 %) |
|
||||
|
||||
## Fable-Block (P, Q)
|
||||
|
||||
| Messgröße | **Lauf P** | **Lauf Q** |
|
||||
|---|---:|---:|
|
||||
| Anforderungen | 207 | 148 |
|
||||
| — StRS / SyRS / SwRS | 35/84/88 | 26/56/66 |
|
||||
| Tokens gesamt | 24.225.555 | 31.073.793 |
|
||||
| Thinking-Tokens | 35.220 | 39.609 |
|
||||
| Agent-Turns | 152 | 162 |
|
||||
| Denials / Subagenten | 1 / 0 | 0 / 0 |
|
||||
|
||||
## Vergleich der drei Solo-Reihen
|
||||
|
||||
| | **Fable, `max`** (2 Läufe) | Opus, `high` (5 Läufe) | Sonnet, `high` (5 Läufe) |
|
||||
|---|---|---|---|
|
||||
| Anforderungen | 148 – 207 | 71 – 182 (Median 114) | 42 – 82 (Median 67) |
|
||||
| Tokens gesamt | 24,22 – 31,07 Mio. | 13,56 – 24,86 Mio. (Median 22,76) | 4,36 – 12,60 Mio. (Median 5,05) |
|
||||
| Thinking-Tokens | 35.220 – 39.609 | 11.239 – 24.179 | 10.470 – 22.957 |
|
||||
| Agent-Turns | 152 – 162 | 116 – 195 | 67 – 107 |
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
1. **Der höchste Solo-Verbrauch der gesamten Reihe – vom sparsamsten Modell.** Mit 24,22 und
|
||||
31,07 Mio. Tokens übertrifft der Fable-Block sogar den teuersten Opus-Lauf (24,86 Mio.).
|
||||
Da Fable als das schnellere und günstigere Modell gilt, ist der plausibelste Treiber der auf
|
||||
`max` gesetzte Effort – bestätigen lässt sich das aus diesen Daten jedoch **nicht**, weil
|
||||
Modell und Effort gleichzeitig gewechselt wurden.
|
||||
|
||||
2. **Deutlichster Hinweis auf den Effort: die Thinking-Tokens.** Mit 35.220 und 39.609 liegen
|
||||
sie über allen 21 Vorläufen – der bisherige Höchstwert lag bei 24.179 (Opus, `high`), der
|
||||
Sonnet-Solo-Median bei rund 12.000. Thinking-Tokens sind die unmittelbarste Wirkung der
|
||||
Effort-Stufe, und sie steigen hier um Faktor 1,5 bis 3 gegenüber `high`. Das stützt die
|
||||
Vermutung aus Anmerkung 1, ersetzt aber den fehlenden Kontrollpunkt nicht.
|
||||
|
||||
3. **Hohe Ausbeute bei den Anforderungen.** 148 und 207 Anforderungen liegen über dem
|
||||
Opus-Median (114) und weit über dem Sonnet-Median (67) – bei einem Modell, das von den dreien
|
||||
das schwächste ist. Die Anforderungsanzahl misst allerdings nur Menge, nicht Belegqualität;
|
||||
eine inhaltliche Bewertung steht aus.
|
||||
|
||||
4. **Konsistent über beide Läufe.** Anforderungen 148 gegenüber 207 (Faktor 1,4), Tokens 24,22
|
||||
gegenüber 31,07 Mio. (Faktor 1,3), Turns 152 gegenüber 162. Bei nur zwei Messpunkten ist das
|
||||
keine belastbare Streuungsaussage, fügt sich aber in das Bild der übrigen Solo-Reihen ein,
|
||||
die alle unter Faktor 3 bleiben.
|
||||
|
||||
5. **Was zur kausalen Trennung fehlt:** ein Fable-Block auf `high`. Er würde zeigen, ob der
|
||||
Sprung im Verbrauch vom Modell oder vom Effort kommt. Alternativ ein Sonnet- oder Opus-Block
|
||||
auf `max` – dann ließe sich der Effort-Effekt bei bekanntem Modell isolieren.
|
||||
|
||||
6. **Manuelle Eingriffe während des Laufs:** keine.
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"is_error":false,"duration_api_ms":2816620,"num_turns":152,"stop_reason":"end_turn","session_id":"5155f938-271d-4e03-85fc-002f1702c15d","total_cost_usd":43.66537800000002,"usage":{"input_tokens":270,"cache_creation_input_tokens":427305,"cache_read_input_tokens":23562775,"output_tokens":230990,"output_tokens_details":{"thinking_tokens":35220},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":427305,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1603,"cache_read_input_tokens":426879,"cache_creation_input_tokens":426,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":426},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":4193,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.0043029999999999995,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty"},"claude-fable-5":{"inputTokens":270,"outputTokens":230990,"cacheReadInputTokens":23562775,"cacheCreationInputTokens":427305,"webSearchRequests":0,"costUSD":43.66107500000002,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty"}},"permission_denials":[{"tool_name":"Read","tool_use_id":"toolu_01W6E1Yo6fxnq1K4j83jcDDL","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\5155f938-271d-4e03-85fc-002f1702c15d\\tasks\\bm3b61zcw.output"}}],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"Der RRE-Lauf ist abgeschlossen. Alle sieben Ergebnisdokumente liegen im Zielverzeichnis `...\\01_Lauf_2026-08-25_210903_fable5_solo_v3.6.0-7adf\\Ergebnisse\\`; die analysierte Codebasis blieb unverändert (git status leer).\n\n**Ergebnisübersicht**\n\n| Datei | Inhalt |\n|---|---|\n| `StRS.md` | 35 Stakeholder-Anforderungen (Akteure, Geschäftsziele je Fachdomäne) |\n| `SyRS.md` | 84 Systemanforderungen in 8 Blöcken (Architektur/Betrieb, Belegwesen, Verträge, Helpdesk, Einkauf/Lager, Finanzen, Portale, Querschnitt) |\n| `SwRS.md` | 88 Software-Anforderungen auf Komponenten-/Algorithmusebene (u. a. SaveReceipt-Pipeline, Storno-Algorithmus, Nummernvergabe, Negativbuchungs-Freigabe, Eskalationsberechnung) |\n| `Traceability.md` | Vollständige Kette StRS→SyRS→SwRS (88 Zeilen) plus Lückenliste: 27 SyRS noch ohne SwRS-Verfeinerung |\n| `Hypothesen.md` | 16 Hypothesen mit fehlender Information und Klärungsweg |\n| `Glossar.md` | ~55 Domänenbegriffe, jeweils mit Artefaktbezug |\n| `Analysebericht.md` | Systemsteckbrief, Analysetiefe je Modul, Konsistenzcheck, Kennzahlen, Selbstbewertung |\n\n**Kennzahlen:** 207 Anforderungen, 336 Einzelbelege (89 % PRIMÄR, 9 % SEKUNDÄR, 2 % KONTEXT), 17 Konsolidierungskandidaten, 4 dokumentierte Workarounds, 1 Anforderung als HYPOTHESE herabgestuft (SyRS-009 Kontosperrung — Sicherheitsaussage ohne belegten Durchsetzungsort).\n\n**Konsistenzcheck (skriptgeprüft):** keine ID-Duplikate, keine Anforderung ohne Beleg/Prüfidee/Tracelink, keine Verweise auf nicht existierende IDs; alle 35 StRS sind durch SyRS verfeinert.\n\n**Fachlich bemerkenswerte Befunde:** Passwörter werden als ungesalzene SHA1-Hashes gespeichert (Ablösung im Zielsystem als zwingend markiert); nach FIBU-Export existiert nur eine Änderungs*warnung*, keine harte GoBD-Festschreibung; Barbelege sind im modernisierten Speicherweg blockiert („Aktuell werden leider noch keine Bar-Belege unterstützt\"); es bestehen deutliche Doppelstrukturen (Kunden- vs. Accounts-Modell, drei Abrechnungswege, RPC- vs. REST-API, WPF-Ticketliste vs. ServiceBoard), die als Konsolidierungskandidaten für die SaaS-Neuimplementierung ausgewiesen sind.\n\n**Bewusste Lücken dieser Iteration** (im Analysebericht priorisiert): XAML-Masken (1.233 Dateien) und damit maskenspezifische Pflichtfeld-Redundanz, Preisfindung im Detail, Finanzen-Läufe (OPOS/SEPA/Mahnlauf-Interna), RPC-Methodeninventar sowie Randmodule (DocuBoard, Riversuite-Familie u. a.).","ttft_ms":7306,"ttft_stream_ms":1604,"time_to_request_ms":34,"type":"result","duration_ms":2963099,"uuid":"f07f1199-716b-438d-98f8-e8f745ff49db","queued_turn_count":0}
|
||||
+3650
File diff suppressed because it is too large
Load Diff
+66
@@ -0,0 +1,66 @@
|
||||
## 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 | 35 | 16,9 % |
|
||||
| SyRS | 84 | 40,6 % |
|
||||
| SwRS | 88 | 42,5 % |
|
||||
| **Gesamt** | **207** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 86 | 41,5 % |
|
||||
| Daten | 18 | 8,7 % |
|
||||
| Sicherheit | 17 | 8,2 % |
|
||||
| Schnittstelle | 15 | 7,2 % |
|
||||
| funktional (Abrechnung) | 9 | 4,3 % |
|
||||
| funktional / Daten | 8 | 3,9 % |
|
||||
| funktional / Schnittstelle | 5 | 2,4 % |
|
||||
| Architektur-Constraint | 4 | 1,9 % |
|
||||
| Daten / funktional | 4 | 1,9 % |
|
||||
| funktional, Schnittstelle | 3 | 1,4 % |
|
||||
| (29 weitere) | 38 | 18,4 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 336 |
|
||||
| davon `PRIMÄR` | 299 (89,0 %) |
|
||||
| davon `SEKUNDÄR` | 30 (8,9 %) |
|
||||
| davon `KONTEXT` | 7 (2,1 %) |
|
||||
| Belege je Anforderung (Median) | 1 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 207 (100,0 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
**nicht erhoben** – das Feld `Übernahmewürdigkeit` wurde erst mit der Prompt-Fassung vom 2026-08-26 eingeführt und liegt für diesen Lauf nicht vor. Hinweise auf Workarounds stecken ersatzweise im Feld `Status`.
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 203 | 98,1 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 4 | 1,9 % |
|
||||
| als Workaround vermerkt | 4 | 1,9 % |
|
||||
| Konsolidierungskandidaten | 17 | 8,2 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 0 | 0,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** (68 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | *nicht erhoben* (Feld erst ab Prompt-Fassung 2026-08-26) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 207 von 207 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+132
@@ -0,0 +1,132 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 01
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 01 (Initial-Prompt, zu Versuchsbeginn neu formuliert)
|
||||
- **Werkzeugkonfiguration:** Claude Code, keine Agentendateien, keine MCP-Server
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Modell:** Claude (Claude Code)
|
||||
- **Zeitstempel:** 2026-08-25
|
||||
- **Änderungsgrund:** Initial-Prompt für V1 Baseline (kein Vorgänger). Vor Erstlauf überarbeitet: Abgleich mit Kap. 4 (RRE-Methodenkette, Evaluationsrahmen) und Kap. 2 (Prozesskontrollen); mit der Vorfassung fand kein Lauf statt.
|
||||
|
||||
---
|
||||
|
||||
## 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). Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung; nutze nur, was als Datei lesbar ist.
|
||||
|
||||
### 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. Priorisiere die Analysetiefe selbstständig, dokumentiere aber im `Analysebericht.md`, welche Bereiche wie tief analysiert wurden.
|
||||
|
||||
### 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):
|
||||
|
||||
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). Anforderungen ohne Beleg sind unzulässig. Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt.
|
||||
- **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.
|
||||
- **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.
|
||||
- **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.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
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>>
|
||||
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).
|
||||
- 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.
|
||||
|
||||
### 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 (Modul-/Komponentenübersicht, abgedeckte Bereiche, bekannte Lücken)
|
||||
```
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs benannt. 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 nicht vorhandener Tools.** Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist die Aussage als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Wenn eine Implementierung erkennbar ein historischer Workaround oder Sonderfall ist, vermerke das im Feld `Status` (`belegt; Workaround`), damit es in der späteren Validierung priorisiert geprüft werden kann.
|
||||
- **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
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Welche Module wurden vollständig analysiert, welche nur stichprobenhaft, welche gar nicht?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`c:\DEV\MasterArbeit\Versuche\Versuch_01\01_Lauf_2026-08-25_210903_fable5_solo_v3.6.0-7adf\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-25T21:58:44.1855405+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-25T21:09:18.7866475+02:00
|
||||
+123
@@ -0,0 +1,123 @@
|
||||
# Analysebericht
|
||||
|
||||
**Lauf:** V1 Baseline (Prompt-only), Iteration 01 – 2026-08-25
|
||||
**Gegenstand:** Gesamte Codebasis `C:\DEV\MasterArbeit\QuellCode\CentronERP` (c-entron ERP-Suite)
|
||||
**Methode:** Statische Artefaktanalyse (RRE-Schritte 2–6), keine Ausführung, keine externen Werkzeuge/Agenten. Die Codebasis wurde ausschließlich gelesen.
|
||||
|
||||
---
|
||||
|
||||
## 1 Vorgehen (RRE-Schritte 2–6)
|
||||
|
||||
| Schritt | Umsetzung in diesem Lauf |
|
||||
|---|---|
|
||||
| 2 Artefakterhebung | Verzeichnis-/Mengengerüst (Dateizählung je Projekt), Solution-Struktur, Projekt-Doku (`docs/`, 56 Dateien), `README.md`, `CentronRights.md`, Konfigurationsdateien (`appsettings.json`, `WebServiceConfig`-Modell, `global.json`, `version.json`), DB-Migrationsbestand (764 Skriptmethoden), CI-Pipelines (`azure/`), Deployment (`deployment/`, `docker/`), Commit-Messages der jüngsten Historie. |
|
||||
| 3 Technische Analyse | Modulkarten (WPF-Modulregistrierung, Nexus-Routen, REST-Interface-Partitionen, 36 Hintergrunddienste); Tiefenlesen der zentralen BL-Klassen (ReceiptBL ≈ 11.400 Zeilen partiell, ReceiptItemBL, AutomaticFacturaWebServiceBL, DunningRunBL, PaymentTransactionBL, BookKeepingExportBL, TicketBL, Authenticator-Familie, TwoFactorAuthBL, AccessTokenBL, ArticleStockBL, OrderSuggestionListBL, EscalationBL, HelpdeskBL, DsgvoBL, WebAccountBL, ReceiptPriceHelper); Entitätsmodelle (ReceiptBase/ReceiptContract, Helpdesk, HelpdeskTimer, Article, Customer); Statusmaschinen (ReceiptState, WebReceiptState, DunningLevel, Mahnstufen); Rechtekatalog (UserRightsConst-Struktur). |
|
||||
| 4 Semantische Interpretation | Ableitung fachlicher Regeln aus Implementierung (z. B. Weiterverarbeitungsmatrix → Belegkette; DueKind-Formeln → Zahlungsziele; Limitberechnung → Kreditrisiko-Politik; Ticket-/Lizenzlogik → Sicherheits-/Kommerzmodell). Trennung Fakt/Aussage in jeder Anforderung. |
|
||||
| 5 Formalisierung | 148 Anforderungen im vorgegebenen Format (26 StRS, 56 SyRS, 66 SwRS) mit Vorbedingung, Fakt, Soll-Aussage, Ergebnis, Prüfidee. |
|
||||
| 6 Traceability | Bidirektionale Verlinkung StRS↔SyRS↔SwRS in jedem Anforderungsblock plus konsolidierte Matrix (`Traceability.md`, eine Zeile je SwRS mit primärem Pfad und Artefaktbeleg). |
|
||||
|
||||
Belegklassifikation: PRIMÄR = durchgesetzte Regel im Code/DB-Struktur; SEKUNDÄR = UI-/Modul-/Konfigurationsartefakt; KONTEXT = Doku/Kommentar/Commit. Risikobereiche (Sicherheit, Abrechnung, Berechtigungen) wurden nur mit PRIMÄR-Beleg als Anforderung aufgenommen (automatisiert geprüft, siehe Abschnitt 4); Unsicheres steht ausschließlich in `Hypothesen.md` (18 Hypothesen).
|
||||
|
||||
## 2 Artefaktinventar (Auszug)
|
||||
|
||||
- **Quellcode:** ~17.000 Quelldateien (cs/xaml/razor). Größte Projekte: Centron.WPF.UI (6.321), Centron.WebServices.Core (2.530), Centron.BL (2.068), CentronNexus (1.222), Centron.Entities (1.185), Centron.DAO (1.131).
|
||||
- **Backend:** Centron.BL (≈90 Fachbereiche), Centron.DAO (NHibernate-Mappings, Repositories, TemporaryEntities), Centron.Entities, Centron.Interfaces, Centron.Gateway, Centron.Common.
|
||||
- **Clients:** WPF (DevExpress), Blazor „Nexus" (ServiceBoard/Kundenportal/WebCart/WebOffer/Signing), Outlook-Add-In.
|
||||
- **Dienste:** Centron.Host (ASP.NET Core, REST + WCF-Bridge + SignalR + Swagger), 36 Hintergrunddienste, Windows-Service/Console/Linux/Docker-Hosting.
|
||||
- **Integrationen:** apis/ (ITscope, Icecat, COP, EGIS, FinAPI, GLS, Shipcloud, EbInterface), EDI-Gateways (ALSO, ALSO CH, Alltron, Herweck, Komsa, OpenTrans), docuFORM (Root).
|
||||
- **DB-Migrationen:** 764 ScriptMethod-Klassen (Nr. 10184–11820) + Legacy-XAML-Skriptsammlungen + RecurringScriptMethods.
|
||||
- **Doku:** docs/ mit Architektur-, Datenbank-, Rechte-, Sicherheits-, EDI-, Beleg- und ZUGFeRD-Referenzen; CentronRights.md (159 Zeilen Rechtesemantik Helpdesk).
|
||||
- **Build/Release:** Azure-Pipelines (build/tests/regression/docker/analyze), Nerdbank.GitVersioning, WixSharp-Installer, StrongNaming.
|
||||
- **Tests:** Centron.Tests.EndToEnd, .Integration, CentronNexusTests, PlaywrightTests, backend-/shared-/apis-Tests.
|
||||
|
||||
## 3 Modul-/Komponentenübersicht mit Analysetiefe
|
||||
|
||||
Legende: **V** = vertieft (Kernlogik gelesen, Regeln extrahiert) · **T** = teilweise (Struktur + Stichproben) · **S** = strukturell (nur Existenz/Einordnung) · **N** = nicht analysiert
|
||||
|
||||
| Bereich | Tiefe | Ergebnis im Anforderungs-Set |
|
||||
|---|---|---|
|
||||
| Belegwesen Verkauf (Angebot→Gutschrift, Vertrag) | **V** | SyRS-001…015, SwRS-005…025; SaveReceipt-Pipeline, Weiterverarbeitung, Versionierung, Nummern, Sperren |
|
||||
| Preisberechnung/Rundung | **V** | SyRS-013, SwRS-019 (Formeln inkl. CH-Rundung) |
|
||||
| Preisfindung/Preismatrix/Aktionspreise | **V** | SyRS-046/056, SwRS-055/065 |
|
||||
| Vertragsabrechnung (Intervall, Zähler, RMM, Sammelrechnung, Importe) | **V** | SyRS-016…019, SwRS-026…030 |
|
||||
| Mahnwesen | **V** | SyRS-020, SwRS-031 |
|
||||
| FiBu-Export (DATEV/Abacus/custom) | **V** (Kernpfade) | SyRS-021, SwRS-032 |
|
||||
| E-Rechnung ZUGFeRD/XRechnung | **T** | SyRS-022, SwRS-033; Versionsstand als H-13 offen |
|
||||
| SEPA/Zahlungseingang/OPOS | **V** | SyRS-023/024, SwRS-034 |
|
||||
| Authentifizierung/2FA/Tickets/Lizenzen/AccessTokens | **V** | SyRS-025…031, SwRS-035…041 |
|
||||
| Rechteverwaltung (Katalog + Durchsetzung) | **V** | SyRS-029, SwRS-039/022; Katalog vollständig gesichtet, Einzelrechte nur exemplarisch |
|
||||
| Webservice-Infrastruktur (REST/WCF/SignalR/Versionierung) | **T** | SyRS-032, SwRS-042 |
|
||||
| Hintergrunddienste | **T** (Katalog + 3 Dienste vertieft) | SyRS-033, SwRS-043 |
|
||||
| Helpdesk/Tickets | **V** (Modell, Rechte, Eskalation) | SyRS-034/035, SwRS-044/045 |
|
||||
| Zeiterfassung/TimerBilling | **V** (Modell) / **T** (Abrechnungsdetails) | SyRS-036/037, SwRS-046 |
|
||||
| Lager/Bestand/EK-Fortschreibung/Seriennummern | **V** | SyRS-038…040, SwRS-047…049 |
|
||||
| Bestellvorschlag | **V** (SQL) | SyRS-041, SwRS-050 |
|
||||
| Einkaufsbelege/Lieferantenkette | **T** | SyRS-004, SwRS-009/023 |
|
||||
| Nexus Web (Routen, Konfiguration) | **T** | SyRS-042, SwRS-051 |
|
||||
| WebCart | **T** | SyRS-043, SwRS-052 |
|
||||
| WebOffer/C-Sign | **V** (Zustandslogik) | SyRS-044, SwRS-053 |
|
||||
| Lieferanten-EDI | **T** (Architektur + Dienst) | SyRS-045, SwRS-054 |
|
||||
| DSGVO/SEPA-Online-Dokumente | **V** | SyRS-047, SwRS-056 |
|
||||
| Protokollierung/ChangeTracking | **V** | SyRS-048, SwRS-057 (Befund: Feld-Audit ungenutzt) |
|
||||
| Lokalisierung | **T** | SyRS-049, SwRS-058 |
|
||||
| Betrieb/Konfiguration/Migrationen | **V** | SyRS-050/051, SwRS-004/059/060/066 |
|
||||
| Mailversand | **T** | SyRS-052, SwRS-061 |
|
||||
| Reporting/FastReport | **T** | SyRS-053, SwRS-062 |
|
||||
| Provisionen | **S** | SyRS-054, SwRS-063 (nur Komponentenebene) |
|
||||
| Produktion | **S** | SyRS-055, SwRS-064 |
|
||||
| CRM/Kampagnen/Umfragen | **S** | in StRS-010 subsumiert |
|
||||
| Statistik/Management-Info/MSP-Dashboards | **S** | StRS-022; Kennzahlformeln offen (H-16) |
|
||||
| Inventur, Kommissionierung | **S** | in StRS-008 subsumiert; Detailregeln offen |
|
||||
| TAPI/Telefonie | **N** (nur Existenz) | H-17 |
|
||||
| Exchange-Sync/Kalender | **N** (nur Existenz + Bugprotokoll) | H-18 |
|
||||
| MailScanner, DocuBoard, PasswordManager, VideoPortal, SocialMedia, TradePool, ItPlanner, Chats, KI-Module, MyDay/MyCentron, TaskManager, Checklisten, RMA-Details, Import-Framework, IndexSearch, Customizations/CustomTables, MassUpdate, Mobile, Kalender | **N**/**S** | nicht anforderungsseitig erfasst (siehe 5.3) |
|
||||
| Externe APIs FinAPI (Onlinebanking), GLS/Shipcloud (Versand), EbInterface (AT), Icecat | **S** | nur als Integrationsinventar (SwRS-066/SyRS-046) |
|
||||
| Kassenmodul (Barrechnung/Kassenbuch) | **T** | bewusst als Hypothese H-01 (Obsolete-Widerspruch) |
|
||||
|
||||
## 4 Konsistenzcheck über das gesamte Anforderungs-Set
|
||||
|
||||
Automatisierte Prüfung (Textanalyse über StRS.md, SyRS.md, SwRS.md) am Ende des Laufs:
|
||||
|
||||
| Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| Doppelte oder mehrfach vergebene IDs | **0 Befunde** (26 StRS, 56 SyRS, 66 SwRS, alle eindeutig) |
|
||||
| Anforderungen ohne Beleg | **0 Befunde** (jede Anforderung ≥ 1 klassifizierter Beleg) |
|
||||
| Tracelinks auf nicht existierende IDs | **0 Befunde** (alle referenzierten IDs existieren) |
|
||||
| Formatvollständigkeit (13 Pflichtfelder je Anforderung) | **0 Befunde** (alle Felder in allen 148 Anforderungen vorhanden) |
|
||||
| Ebenen-Traceability (SyRS→StRS, SwRS→SyRS, StRS→SyRS) | **0 Befunde** (bidirektional vollständig) |
|
||||
| Risikoregel: Typ „Sicherheit" ohne PRIMÄR-Beleg | **0 Befunde** |
|
||||
| Risikoregel: Abrechnungs-/Preis-/Rechte-/Lizenzbezug ohne PRIMÄR-Beleg | **0 Befunde** |
|
||||
| Statusverteilung | 140 × `belegt`, 8 × `belegt; Workaround`, 0 × `HYPOTHESE` in den Spezifikationen (18 Hypothesen separat in Hypothesen.md) |
|
||||
|
||||
Während der Erstellung wurden fünf Tracelink-Asymmetrien gefunden und korrigiert (StRS-011, StRS-022, StRS-023, StRS-026, SyRS-004), bevor der finale Check lief.
|
||||
|
||||
## 5 Selbstbewertung
|
||||
|
||||
### 5.1 Was wurde vollständig, was stichprobenhaft, was gar nicht analysiert?
|
||||
|
||||
- **Vollständig (für Spezifikationszwecke):** Die Kern-Wertschöpfung – Belegkette inkl. aller Speicher-Validierungen, Preisfindung/-berechnung, Vertrags-/Zähler-/RMM-Abrechnung, Mahnwesen, SEPA, FiBu-Export-Kernpfade, Authentifizierung/Sitzungen/2FA/Lizenzen/Rechte-Durchsetzung, Lagerbewertung, Bestellvorschlag, Eskalation, Online-Annahme (C-Sign), DSGVO-Dokumente, Betriebs-/Migrationsmodell. Diese Bereiche tragen 90 % der Anforderungen und nahezu alle PRIMÄR-Belege mit Zeilenangaben.
|
||||
- **Stichprobenhaft:** Nexus-Web (über Routen und Konfiguration, nicht je Seite), REST-API (Muster statt Methodenvollständigkeit), Hintergrunddienste (3 von 36 vertieft), EDI (Architektur + Dienst, nicht je Lieferantenparser), Reporting (Pipeline, nicht Reportinhalte), Einkaufsbelege (Kette + Dubletten, nicht alle Detailregeln), E-Rechnung (Erzeugungspfad, nicht Feld-für-Feld).
|
||||
- **Gar nicht / nur Existenz:** TAPI, Exchange-Sync, MailScanner, DocuBoard, PasswordManager-Innenleben, VideoPortal, SocialMedia, TradePool, ItPlanner, KI-Module, MyDay/TaskManager/Checklisten im Detail, RMA-Werkstattprozesse, IndexSearch, CustomTables/Customizations, Mobile, Statistik-Kennzahlformeln, Versand-APIs (GLS/Shipcloud), FinAPI-Onlinebanking, Icecat-Katalogdaten. Der WPF-UI-Layer (6.321 Dateien) wurde bewusst nur über Modulregistrierung und gezielte Belege erfasst, nicht maskenweise.
|
||||
|
||||
### 5.2 Wo war der Beleg dünn?
|
||||
|
||||
- **StRS-Ebene systembedingt interpretativ:** Geschäftsziele sind Rückschlüsse aus Implementierung + Doku; alle StRS stützen sich aber auf mindestens einen PRIMÄR-Beleg der zugehörigen Systemfunktion.
|
||||
- **SEKUNDÄR-/KONTEXT-lastig:** SwRS-001/002 (Architekturmuster – Hauptquelle Doku, PRIMÄR nur exemplarisch), SwRS-004 (DB-Konventionen – Doku + Beispiel-DDL), SyRS-045-Teilaspekte (185-Tage-Bereinigung nur aus Doku), SwRS-038 (ApplicationKind-Inhalte primär aus Doku, Datei selbst nicht geöffnet), H-13/H-14 (E-Rechnungs-Versionsstand, Lizenzbezug). Diese Stellen sind in den Belegen entsprechend gekennzeichnet.
|
||||
- **Nicht verifizierte Kataloginhalte:** LicenseGuids.cs/ApplicationKind.cs wurden über Verwendungsstellen und Doku belegt, nicht Zeile für Zeile gelesen; ebenso die vollständige Rechteliste (nur Struktur + Einzelrechte).
|
||||
- **Workaround-Kennzeichnungen (8):** SwRS-002 (Doppelimplementierung), SwRS-005 (TemporaryEntities-Speicherpfad), SwRS-015 (Mindestpreis-Re-Auth inkompatibel mit Entra-Login), SwRS-022 (Client-Trust bei Neubelegen), SwRS-033 (ZUGFeRD-Eigenimplementierung), SwRS-035 (SHA-1 ungesalzen), SwRS-057 (ungenutztes Feld-Audit), SwRS-060 (Excel-Nummernreservierung). Diese sind für die Migrationsvalidierung priorisiert zu prüfen.
|
||||
|
||||
### 5.3 Erkenntnisse für Folge-Iterationen
|
||||
|
||||
1. **Sicherheits-/Compliance-Klärung zuerst:** H-01 (Kasse/TSE), H-02 (GoBD), H-06 (Preisrechte-Lücke), SwRS-035 (SHA-1) – Abrechnungs- und Compliance-Risiken mit direktem Einfluss auf die Zielarchitektur.
|
||||
2. **Portal-Berechtigungen für Belege** (H-15): gezielte Analyse der CustomerPortal-Belegabfragen in Nexus/WebServiceBL.
|
||||
3. **Kennzahl-Reverse-Engineering** (H-16): Statistik-NamedQueries extrahieren und als testbare Kennzahldefinitionen formalisieren.
|
||||
4. **Nicht erfasste Nebenmodule** (TAPI, Exchange-Sync, MailScanner, RMA, PasswordManager, MyDay/TaskManager, CustomTables): je Modul eine Kurz-Iteration nach dem Muster dieses Laufs; erst danach ist „gesamte Codebasis" auch anforderungsseitig abgedeckt.
|
||||
5. **Katalog-Extraktion automatisieren:** Vollständige Listen (alle ~1.000 Rechte-IDs, alle LicenseGuids, alle AppSettings-Konstanten, NumberGroup-Arten, ReceiptLogKind-Werte) sind mechanisch extrahierbar und würden die SwRS-Datenanhänge präzisieren.
|
||||
6. **End-to-End-Tests als Anforderungsorakel nutzen:** tests/Centron.Tests.EndToEnd speichert Belege über die reale Pipeline und vergleicht Legacy-Tabellenwerte – wertvolle Quelle zur Verifikation der SwRS-Formeln (z. B. SwRS-016/019) in einer Folge-Iteration.
|
||||
7. **Konsolidierungsentscheidungen vorbereiten:** Die im Feld `Konsolidierung` markierten Kandidaten (mehrfache Abrechnungswege, mehrfache Preisquellen, doppelte Ticket-UIs, Doppel-Zugriffspfad BL/WS, mehrere Protokollmechanismen, Pflichtfeld-Mechanismen) sollten vor der Zielarchitektur als eigene Entscheidungsliste aufbereitet werden.
|
||||
|
||||
### 5.4 Grenzen dieses Laufs
|
||||
|
||||
- Aussagen beruhen ausschließlich auf statischer Analyse; Laufzeitverhalten (z. B. tatsächliche Dialogfolgen, Performanz) wurde nicht beobachtet.
|
||||
- Zeilenangaben beziehen sich auf den analysierten Commit-Stand (Branch main, letzter Commit 79c1142f48 „Versuchsbasis: KI-Assistenz-Konfigurationen entfernt").
|
||||
- Die deutschsprachigen Soll-Aussagen sind Interpretationen; die Validierung durch Fachexperten (RRE-Schritt 7) steht aus und ist über die Prüfideen je Anforderung vorbereitet.
|
||||
+77
@@ -0,0 +1,77 @@
|
||||
# Glossar
|
||||
|
||||
Domänenbegriffe der c-entron-Codebasis, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen, Tabellen, Spalten) bleiben in Originalsprache. Jeder Begriff nennt die Artefaktquelle, aus der er abgeleitet wurde.
|
||||
|
||||
| Begriff | Definition | Artefaktquelle |
|
||||
|---|---|---|
|
||||
| **Beleg** | Oberbegriff für Vertriebs- und Einkaufsdokumente (Angebot, Auftrag, Lieferschein, Rechnung, Abholschein, Gutschrift, Vertrag sowie Lieferanten-Pendants). Technisch: Ableitungen von `ReceiptBase`. | `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs`; `docs/reference/receipts/receipts-backend-architecture.md` |
|
||||
| **Belegkette / Weiterverarbeitung** | Überführung eines Belegs in einen Folgebeleg (z. B. Angebot → Auftrag → Lieferschein → Rechnung) unter Übernahme der Positionen mit Herkunftsreferenz (`OriginReceiptI3D`). Englisch im Code: *Forwarding*. | `ReceiptBL.ForwardReceipt`, `IReceiptSpecificLogic.CanBeForwardedInto()` |
|
||||
| **Kopf / Position (Pos)** | Ein Beleg besteht aus einem Kopfdatensatz (`*Kopf`-Tabelle, z. B. `AufKopf`) und Positionsdatensätzen (`*Pos`-Tabelle, z. B. `AufPos`). | `docs/reference/receipts/receipts-backend-architecture.md` |
|
||||
| **I3D** | Namenskonvention für Primärschlüssel („ID 3develop"): Spalte `I3D` als `int IDENTITY(1,1)`; Fremdschlüssel enden auf `...I3D`. | `docs/guides/database/database-conventions.md` |
|
||||
| **Versionstabelle** | 1:1-Kopie einer Beleg-Tabelle (`*KopfVersions`, `*PosVersions`), in die bei jeder neuen Belegversion der vorherige Stand kopiert wird (Audit-Trail). | `docs/reference/receipts/receipts-backend-architecture.md`; `AssetHeadDAO.SaveAssetVersion` |
|
||||
| **Belegversion** | Fortlaufende Versionsnummer eines Belegs (`ReceiptBase.Version`); Änderungen an Belegen erzeugen neue Versionen statt den Bestand zu überschreiben. | `ReceiptBL.CreateNewVersion` |
|
||||
| **Belegstatus** | Zustand eines Belegs: `offen` (1), `abgeschlossen` (2), `storniert` (3). | `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs` |
|
||||
| **Nummernkreis (NumberGroup)** | Konfigurierbarer Zähler zur Vergabe fortlaufender Belegnummern, differenzierbar je Belegart und Filiale. | `ReceiptBL.UpdateReceiptNumber`, `NumberGroupBL.GetNextNumber` |
|
||||
| **Filiale (Branch)** | Organisationseinheit; Belege, Mitarbeiter und Rechte können filialbezogen sein (`BranchI3D`). | `ReceiptBL.GetBranchForNewReceipt`; `UserRightsConst` (…ONLY_OWN_BRANCH-Rechte) |
|
||||
| **Mandant (Mandator)** | Übergeordnete Firmen-/Buchungseinheit mit eigenen Bankdaten; verwaltet im Modul „Mandanten". | `ModuleRegistration.cs` (MandatorManagementAppModuleController); `MandatorBL.GetMandatorBankInfo` |
|
||||
| **Zahlungskondition (PaymentCondition / AssetCondition)** | Stammdatum, das Fälligkeit (`DueKind`: sofort / +X Tage / Tag X des Folgemonats), Skonto und Zuordnung zu Belegarten definiert. | `ReceiptBL.UpdatePaymentDueDate`; `AssetConditionBL` |
|
||||
| **Skonto-Ausschluss** | Artikelkennzeichen `NoEarlyPaymentDiscountAllowed`: Position ist von Skonto ausgenommen; wird in der Preisberechnung separat summiert. | `ReceiptPriceHelper.cs` (NotDiscountable…-Felder) |
|
||||
| **Kreditlimit** | Kundenstammwert `CreditLimit` mit Berechnungsart `CreditLimitCalculationKind` (1 = netto, 2 = deaktiviert, sonst brutto); wird beim Belegspeichern gegen offene Belege geprüft. | `Customer.cs`; `ReceiptBL.CheckIfCustomerLimitIsReached` |
|
||||
| **Mindestpreis (MinPrice)** | Artikelstammwert, den der Netto-Verkaufspreis einer Position nicht unterschreiten darf, außer ein Benutzer mit dem Recht `ALLOW_IGNORE_MINIMUM_PRICE` gibt frei. | `Article.MinPrice`; `ReceiptBL.CheckArticleMinPrices` |
|
||||
| **Preisliste 1–4** | Vier Verkaufspreisfelder am Artikel (`Price1`–`Price4`); die Kundeneigenschaft `PriceList` (0–3) wählt den anzuwendenden Preis. | `Article.GetPrice(int pricelist)`; `Customer.PriceList` |
|
||||
| **Staffelpreis (VolumePrices)** | Mengenabhängige Artikelpreise (`ArticleVolumePrices`), berücksichtigt bei der Preisfindung über die Menge. | `Article.VolumePrices`; `ArticleVolumePricesBL.cs` |
|
||||
| **Sonderabsprache (SpecialAgreement)** | Kunden-/vertragsbezogene Preisvereinbarung, die bei Preisfindung Vorrang hat und die EK-Fortschreibung im Artikelstamm unterdrückt. | `PriceBL.GetSpecialAgreement`; `ArticleStockBL.UpdateArticlePurchasePrice` (Frühausstieg) |
|
||||
| **Sonderpreis (AccountSpecialPrice)** | Kundenspezifischer Artikelpreis am Adressstamm; Grundlage des WebCart-Sortiments. | `AccountSpecialPrice.cs`; `README.md` (WebCart) |
|
||||
| **Aktionspreis (ActionPrice)** | Zeitlich befristeter Einkaufs-Aktionspreis eines Distributors (`HerstellerArtikAktionspreis`), sichtbar in der Preismatrix. | `docs/reference/receipts/actionprice-system.md`; `ActionPriceBL.cs` |
|
||||
| **Preismatrix (Preisspiegel)** | Vergleichsansicht paralleler Preisquellen je Artikel (ITscope, Artikelimport, COP, NEOS, TradersGuide, EGIS, Aktionspreise). | `docs/reference/receipts/actionprice-system.md`; `PriceMatrixViewModel.cs` |
|
||||
| **Gleitender EK / Misch-EK** | Fortschreibung des Artikel-Einkaufspreises beim Wareneingang als gewichteter Durchschnitt; Alternativen je Artikel: letzter EK oder Fest-EK (`PurchasePriceAsKind`). | `ArticleStockBL.UpdateArticlePurchasePrice` |
|
||||
| **Wareneingang (Intake)** | Zugangsbuchung in die Tabelle `Intake`; auch als Artikel-Kennzahl „unterwegs/eingebucht". | `OrderSuggestionListBL.cs` (Intake-Joins); `Article.Intake` |
|
||||
| **Nebenlager (SecondaryStock)** | Zusätzliche Lagerorte neben dem Hauptlager, mit eigenem Bestand und eigenem EK je Artikel (`SecondaryStockArticle`). | `Article.SecondaryStocks`; `ArticleStockBL` |
|
||||
| **Bestellvorschlag** | Ermittlung des Beschaffungsbedarfs aus Auftragsbedarf + Mindestbestand − Bestand − offenen Zugängen (inkl. Konsignation und Sonderabsprachen). | `OrderSuggestionListBL.cs` (SQL-Bedarfsformel) |
|
||||
| **Seriennummer / Barcode** | Gerätebezogene Identifikation; seriennummernpflichtige Artikel (`ScanBarcode`) erfordern Erfassung, aktive Seriennummern blockieren Versionsrücknahme. | `BarcodeBL.cs`; `ReceiptBL.CreateNewVersion` (Prüfung „Seriennummern aktiv") |
|
||||
| **Helpdesk / Ticket** | Serviceanfrage-Datensatz (`Helpdesk`, Tabelle `hlpdsk_requests`) mit konfigurierbaren Status, Prioritäten, Typen, Kategorien und Bearbeitern. | `Centron.Entities/.../Support/Helpdesk.cs`; `EscalationBL.cs` (SQL auf `hlpdsk_requests`) |
|
||||
| **Eskalationsstufe** | Mehrstufige, arbeitszeitbewusste Eskalation überfälliger Objekte (Tickets, Liefertermine u. a.) mit Mailbenachrichtigung; Stufe wird am Ticket gespeichert (`EscalationLevel`). | `EscalationBL.cs`; `EscalationsService.cs` |
|
||||
| **Timer (HelpdeskTimer)** | Zeiterfassungssatz zu einem Ticket (Start/Stopp, Pause, abrechenbar-Kennzeichen `Calculable`, Abrechnungsartikel, Zuschläge). | `HelpdeskTimer.cs` |
|
||||
| **Leistungsnachweis** | Auswertung/Beleg der erfassten Zeiten; Timer tragen Kennzeichen `IsPrinted`, `IsSigned`, `SentAt`. | `HelpdeskTimer.cs`; Modul „Leistungsnachweise" in `ModuleRegistration.cs` |
|
||||
| **TimerBilling („Vereinfachte Ticketabrechnung")** | Modul zur Überführung erfasster Ticketzeiten in Belege. | `ModuleRegistration.cs`; `ReceiptBL.CreateNewReceiptForHelpdekTimers` |
|
||||
| **Vertragsabrechnung** | Periodische Erzeugung von Rechnungen aus Verträgen (`VertragKopf`/`VertragPos`) gemäß Abrechnungsintervall, inkl. Sammelrechnung mehrerer Verträge. | `AutomaticFacturaWebServiceBL.CreateInvoiceToContractComplete` |
|
||||
| **Abrechnungsintervall** | `BillingIntervalKind` (täglich/monatlich/quartalsweise/jährlich) × `BillingIntervalDuration`; wirkt als Mengenmultiplikator bei der Abrechnung. | `docs/reference/receipts/contracts-backend.md`; `AutomaticFacturaWebServiceBL` (InvoiceIntervalCount) |
|
||||
| **Kontingent** | Vertragsguthaben in Stunden oder Betrag (`ContingentUsedHours`, `ContingentLimitValue` …), das durch Leistungen verbraucht und überwacht wird. | `docs/reference/receipts/contracts-backend.md`; `ReceiptContractBL.ContractContingentBalanceCalculation` |
|
||||
| **Klick-/Zählerabrechnung** | Abrechnung von Geräten (Drucker/Kopierer) nach Zählerständen inkl. Freikopien und Staffelpreisen. | `AutomaticFacturaBL.Contracts.cs` (Counter-Methoden); Modul „Klick-Zählerverwaltung" |
|
||||
| **Stammblatt (MasterDataList)** | Geräte-/Datenliste, die einem Vertrag zugeordnet wird (z. B. Geräte mit Zählern). | `ReceiptContractBL.AddMasteDateListsToContract`; `MasterDataListOverviewAppModuleController` |
|
||||
| **RMM** | Remote Monitoring & Management; externes System (z. B. „Riverbird"), dessen Nutzungsdaten über `RiverConnectionBL` abgerufen und fakturiert werden. | `docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md` |
|
||||
| **MSP** | Managed Services Provider; MSP-Collector/-Auswertung aggregieren nutzungsbasierte Daten zur Abrechnung und Auswertung. | `MspCollectorsBL.cs`; Module „MSP-…" in `ModuleRegistration.cs` |
|
||||
| **Sammelrechnung** | Eine Rechnung für mehrere Verträge desselben Kunden/Konzerns in einem Abrechnungslauf. | `AutomaticFacturaWebServiceBL.CreateInvoiceToContractComplete` (billingParams.Count > 1) |
|
||||
| **Mahnstufe / Mahnlauf** | Dreistufiges Mahnwesen (`DunningLevel` 1–3) mit je Stufe gespeichertem Datum/Bearbeiter; Mahnläufe sind fortlaufend nummeriert (`DunningRunNumber`). | `DunningRunBL.UpdateInvoice`, `SaveDunningRun` |
|
||||
| **OPOS** | Offene-Posten-Verwaltung (Modul „OPOS"). | `ModuleRegistration.cs` (OposOverviewAppModuleController) |
|
||||
| **SEPA-Mandat** | Lastschriftmandat des Kunden (`MandatI3D` am Vertrag, `AuthorizationNumber` am Bankkonto); online bestätigbar als SEPA-Vertrag. | `contracts-backend.md`; `DsgvoBL.ConfirmOnlinePdfDocument` |
|
||||
| **PAIN-Format** | XML-Format für SEPA-Lastschriftdateien; unterstützte Varianten: PAIN 008.001.01 (STUZZA), 008.003.02, 008.001.02, 008.001.02 GBIC 3, 008.001.08 GBIC 4. | `PaymentTransactionBL.cs` |
|
||||
| **FiBu-Export** | Übergabe von Stammdaten/Bewegungsdaten an Finanzbuchhaltungssysteme (DATEV ASCII, DATEV XML Online 2020, Abacus, kundenspezifische Schnittstellen). | `BookKeepingExportBL.cs`; Gateways `DatevAscii`, `DatevXmlOnline2020` |
|
||||
| **ZUGFeRD / XRechnung** | Strukturierte E-Rechnungsformate; eigene Implementierung mit Feldzuordnung, Datei wird als Mailanhang der Rechnung erzeugt; Leitweg-ID identifiziert Behördenempfänger. | `InvoiceZugferdBL.cs`; `docs/reference/zugferd-field-mapping.md`; `ReceiptBL.GetLeitwegID` |
|
||||
| **Reverse Charge** | Umkehr der Steuerschuld; Artikelkennzeichen `IsReversecharge` wird in Positionen übernommen. | `Article.IsReversecharge`; `ReceiptItemBL.UpdateReceiptItemWithArticleInfo` |
|
||||
| **WEEE** | Elektro-Altgeräte-Registrierungsnummer am Artikel; für bestimmte Belegarten Pflicht (`IsWeeeRequired`, z. B. Abholscheine). | `Article.WEEE`; `PickupListSpecificLogic.IsWeeeRequired()` |
|
||||
| **AppUser** | Interner Benutzer des Systems (Tabelle `Sichbenu`), verknüpft mit einem Mitarbeiter (`Personal`). | `AppUserMaps.cs` (Table("Sichbenu")) |
|
||||
| **WebAccount** | Zugangskonto für Endkunden (Portal/WebCart), verknüpft mit einer Kontaktperson eines aktiven Kunden. | `WebAccountBL.LoginWithWebAccount` |
|
||||
| **Recht / Rechtegruppe** | RBAC-Modell: Rechte (IDs in `UserRightsConst`) werden über Gruppen an Benutzer vergeben; Prüfung per `AppRightsBL.CheckRightsFromUser`. | `UserRightsConst.cs`; `docs/guides/development/check-userrights.md` |
|
||||
| **Einschränkendes Recht** | Recht, das Sichtbarkeit/Aktionen reduziert statt erweitert (z. B. „Tickets anzeigen – nur eigene"). | `CentronRights.md`; `HelpdeskBL` (ShowHelpdeskRight) |
|
||||
| **Lizenz (LicenseGuid)** | Feature-/Produktfreischaltung als GUID mit optionalem Count, Ablaufdatum und Maximalversion; Quelle ist der Lizenzserver. | `docs/reference/security/licensing-system.md`; `LicenseGuids.cs` |
|
||||
| **ApplicationKind** | Katalog der Anwendungen, die sich am Webservice anmelden dürfen; definiert je Anwendung Pflicht-/Sperr-Rechte und Ticket-Ablaufart. | `ApplicationKind.cs`; `Authenticator.ValidateRights` |
|
||||
| **Sitzungs-Ticket** | Serverseitige Sitzungskennung nach Login (nicht zu verwechseln mit Helpdesk-„Ticket"); Standardablauf 30 Minuten, gleitend verlängert. | `TicketBL.cs` (TicketExpireInMinutes) |
|
||||
| **Access-Token** | Persönlicher API-Schlüssel (SHA-256-gehasht gespeichert) mit Ablaufdatum, Aktivierung/Deaktivierung und Zugriffsprotokoll. | `AccessTokenBL.cs` |
|
||||
| **ConcurrencyControlGuid** | GUID-Feld am Beleg für optimistische Nebenläufigkeitskontrolle. | `ReceiptBase` (Systemfelder laut `receipts-backend-architecture.md`); Parameter in `ReceiptBL.Update…`-Methoden |
|
||||
| **AnlageLog / ReceiptLog** | Zentrales Belegprotokoll (Tabelle `AnlageLog`) mit `AnlageArt` = Belegart (1 Angebot … 22 Vertrag); erfasst Druck/Mail/EDI/Zahlungs-Ereignisse. | `receipts-backend-architecture.md`; `ReceiptLogBL.cs` |
|
||||
| **ChangeLog** | Feldbezogene Änderungshistorie (alt/neu) über NHibernate-PreUpdate-Listener; Infrastruktur attributgesteuert. | `ChangeTrackingEventListener.cs`; `ChangeLog.cs` |
|
||||
| **Soft Delete** | Löschkennzeichnung per `IsDeleted`/`DeletedByI3D`/`DeletedDate` statt physischem Löschen (Konvention für neue Tabellen). | `docs/guides/database/database-conventions.md` |
|
||||
| **TemporaryEntities** | Legacy-Persistenzpfad: Beim Speichern werden moderne Beleg-Entities in Entities der deutschen Originaltabellen (`RechKopf`, `RechPos` …) synchronisiert. | `receipts-backend-architecture.md` („Critical Save Warning"); `Centron.DAO/Mappings/TemporaryEntities` |
|
||||
| **ServiceBoard** | Web-Oberfläche (Blazor „Nexus") für Ticketbearbeitung (Kanban, MyDay, Suche, Zeiten, Planung). | `src/nexus/CentronNexus` (Routen `/serviceboard/...`) |
|
||||
| **Kundenportal** | Web-Self-Service für Endkunden: Tickets, Dokumente, Belege, Formulare. | Routen `/customerportal/...` in `CentronNexus` |
|
||||
| **WebCart** | B2B-Shop für Endkunden der Systemhäuser; Sortiment aus Kunden-Sonderpreisen. | `README.md` (Contributing/WebCart); Routen `/webcart/...` |
|
||||
| **WebOffer / C-Sign / SharedDocument** | Online-Bereitstellung von Belegen per Token-Link zur Ansicht, Annahme (mit/ohne Signatur), Änderungswunsch oder Ablehnung. | `ReceiptBL.ChangeWebReceiptState`; `WebReceiptState.cs`; Routen `/weboffer/{Token}`, `/shareddocuments/{Token}/sign` |
|
||||
| **Leitweg-ID** | Empfänger-Routing-Kennung für XRechnung an öffentliche Auftraggeber; je Kunde hinterlegt. | `ReceiptBL.GetLeitwegID` |
|
||||
| **EDI** | Elektronischer Belegaustausch mit Lieferanten (ALSO, ALSO CH, Alltron, Herweck, Komsa, OpenTrans 2.1) über FTP/SFTP/FTPS. | `docs/reference/edi/edi-architecture.md`; `SupplierEdiBL.*` |
|
||||
| **Eskalationsserver** | Lizenzpflichtiger Serverdienst, der Eskalationen alle 15 Minuten prüft. | `EscalationsService.cs`; `LicenseGuids.EscalationsServer` |
|
||||
| **Skriptmethode** | Versioniertes Datenbank-Migrationsartefakt (`ScriptMethod<Nr>.cs`), das SQL-Änderungen idempotent ausführt; Nummern werden zentral reserviert. | `docs/guides/database/create-scripts.md`; `Centron.BL/Administration/Scripts/ScriptMethods/Scripts` |
|
||||
| **Nexus** | Interner Name der Blazor-Webanwendung („c-entron Nexus aka c-entron Web"). | `README.md` |
|
||||
| **DevExpress / FastReport** | Eingesetzte UI- bzw. Reporting-Komponenten (WPF-Controls, Blazor-Komponenten; Berichtserzeugung). | `Centron.BL.csproj` (FastReport.*, DevExpress.*); `README.md` |
|
||||
| **Barrechnung / Kassenbuch** | Historische Kassenmodule; zugehörige Rechte sind im Code als `[Obsolete]` markiert (Status siehe Hypothesen). | `UserRightsConst.cs` (RIGHT_BARRIGHT_NUNG, RIGHT_KASSENBUCH mit `[Obsolete]`) |
|
||||
| **IsCashAsset** | Kennzeichen „Barbeleg"; beeinflusst Preisberechnung (Bruttorechnung) und blockiert Weiterverarbeitung einer Barrechnung in eine Gutschrift über die UI. | `ReceiptPriceHelper` (isCashAsset-Parameter); `InvoiceSpecificLogic.CanBeForwardedIntoForUIOverwrite` |
|
||||
+130
@@ -0,0 +1,130 @@
|
||||
# Hypothesen
|
||||
|
||||
Sammlung aller Aussagen, die sich aus den Artefakten **nicht eindeutig** ableiten ließen. Jede Hypothese nennt die vorhandenen Indizien (mit Belegklasse), die fehlende Information und den empfohlenen Klärungsweg (Schritt 7 der RRE-Methodenkette: Validierung durch Fachexperten).
|
||||
|
||||
---
|
||||
|
||||
## H-01 [HYPOTHESE] Status des Kassenmoduls (Barrechnung/Kassenbuch)
|
||||
**Vermutung:** Die Kassenfunktionen (Barrechnung, Kassenbuch) sind fachlich noch relevant, aber technisch teilweise stillgelegt oder im Umbau; eine TSE-Anbindung (Kassensicherungsverordnung, § 146a AO) existiert nicht.
|
||||
**Indizien:**
|
||||
- [PRIMÄR] `UserRightsConst.cs` Zeilen 62–69: `RIGHT_BARRIGHT_NUNG` und `RIGHT_KASSENBUCH` sind `[Obsolete]` markiert; gleichzeitig existiert die Rechteklasse `Sales.Cashbox` mit Unterklassen `BarInvoice` und `Accountingbook` (Zeilen 1903–1938) ohne Obsolete-Markierung.
|
||||
- [PRIMÄR] `InvoiceSpecificLogic.CanBeForwardedIntoForUIOverwrite` behandelt `IsCashAsset` (Barrechnungen) aktiv.
|
||||
- Suche nach „TSE" / „Kassensich" im BL-Quellbaum ohne Treffer.
|
||||
**Fehlende Information:** Produktentscheidung zum Kassenmodul; rechtliche Bewertung, ob Bargeschäfte über c-entron als „elektronisches Aufzeichnungssystem" i. S. d. KassenSichV laufen.
|
||||
**Klärungsweg:** Fachexperten-Interview Produktmanagement; falls Kasse produktiv: TSE-Pflicht im Zielsystem als Anforderung ergänzen.
|
||||
|
||||
## H-02 [HYPOTHESE] GoBD-Konformität ist beabsichtigt, aber nicht als geschlossenes Konzept belegt
|
||||
**Vermutung:** Versionstabellen, Beleg-Logs und Export-Schutz dienen (auch) der GoBD-Konformität (Unveränderbarkeit, Nachvollziehbarkeit); ein vollständiges GoBD-Konzept (Festschreibung, Verfahrensdokumentation, Datenzugriff Z1–Z3) ist im Code nicht nachweisbar.
|
||||
**Indizien:**
|
||||
- [PRIMÄR] Versionstabellen (`*KopfVersions`), `HandleIsAlreadyExported`, `ReceiptLogBL` (siehe SyRS-006, SyRS-021, SyRS-048).
|
||||
- [KONTEXT] Kein Vorkommen von „GoBD"/„GDPdU" im Quellbaum (Suchbefund).
|
||||
**Fehlende Information:** Ob und wie Festschreibungspflichten (z. B. unveränderliche Rechnungsnummern-/Inhalte nach Festschreibung) formell erfüllt werden; existiert eine Verfahrensdokumentation außerhalb des Repos?
|
||||
**Klärungsweg:** Compliance-Verantwortliche befragen; für das Zielsystem GoBD-Anforderungen explizit spezifizieren (risikobehaftet, da Abrechnungsdomäne).
|
||||
|
||||
## H-03 [HYPOTHESE] Kein systematisches DSGVO-Lösch-/Anonymisierungskonzept für personenbezogene Daten
|
||||
**Vermutung:** Es existiert kein automatisierter Lösch-/Anonymisierungsprozess für personenbezogene Daten nach Aufbewahrungsfristen; Löschungen erfolgen manuell.
|
||||
**Indizien:**
|
||||
- [PRIMÄR] `DocumentsCleanupService.cs` (Dokumentbereinigung) und EDI-Log-Bereinigung nach 185 Tagen sind die einzigen gefundenen automatischen Löschroutinen.
|
||||
- [PRIMÄR] Soft-Delete-Konvention (`IsDeleted`) hält Daten physisch vor (database-conventions.md).
|
||||
- [SEKUNDÄR] DSGVO-Modul adressiert AVV/SEPA-Dokumente, nicht Betroffenenrechte (Löschung/Auskunft).
|
||||
**Fehlende Information:** Prozesse für Art. 17 DSGVO (Löschung), Auskunftsexporte, Aufbewahrungsfristen je Objektart.
|
||||
**Klärungsweg:** Datenschutzbeauftragten einbinden; im Zielsystem Lösch-/Anonymisierungsanforderungen definieren.
|
||||
|
||||
## H-04 [HYPOTHESE] Keine quantifizierten Performance-/Lastanforderungen
|
||||
**Vermutung:** Es gibt keine dokumentierten Antwortzeit- oder Durchsatzziele; Dimensionierung erfolgt erfahrungsbasiert.
|
||||
**Indizien:**
|
||||
- [PRIMÄR] Nur qualitative Mechanismen: `PerformanceTracer` in der Vertragsabrechnung, Batch-Größe 2000 (`AutomaticFacturaBL.SearchSpecialArticleToContractHead`), DB-Pool max 200 (`WebServiceConfig`), `TicketCache.MaxClosedTickets` 300.000 (Nexus), Performance-Test-Entities (`Entities/Administration/PerformanceTests`).
|
||||
**Fehlende Information:** Zielwerte (Nutzerzahlen, Belegvolumen, Antwortzeiten), die eine SaaS-Neuimplementierung dimensionieren müssten.
|
||||
**Klärungsweg:** Betriebsdaten von Bestandskunden erheben (Belege/Jahr, parallele Sessions); NFR-Workshop.
|
||||
|
||||
## H-05 [HYPOTHESE] Datensicherung/Wiederherstellung liegt vollständig außerhalb des Systems
|
||||
**Vermutung:** Backup/Restore und Desaster-Recovery werden den MSSQL-Bordmitteln bzw. dem Kunden überlassen; das System selbst enthält keine Sicherungsfunktionen.
|
||||
**Indizien:** Keine Backup-/Restore-Artefakte im Quellbaum (Suchbefund); Betriebsdoku (docs/operations) behandelt nur Build/Release.
|
||||
**Fehlende Information:** Vertragliche/organisatorische Vorgaben zur Sicherung; RPO/RTO-Erwartungen der Kunden.
|
||||
**Klärungsweg:** Betriebshandbuch/Onboarding-Unterlagen des Herstellers sichten; für SaaS-Zielbild sind RPO/RTO zwingend zu definieren.
|
||||
|
||||
## H-06 [HYPOTHESE] Preisrechte-Härtung hat bei Neubelegen eine ausnutzbare Lücke
|
||||
**Vermutung:** Benutzer ohne Preisänderungsrecht könnten bei komplett neuen Belegen (ohne Vorversion/Ursprungsbeleg) über einen manipulierten Client abweichende Preise speichern.
|
||||
**Indizien:**
|
||||
- [PRIMÄR] `ReceiptBL.cs` Zeile 8105–8110: Kommentar „…So for now, we trust the client to not give us stupid prices when saving a completely new receipt" – der Rückfallpfad übernimmt den Client-Preis.
|
||||
**Fehlende Information:** Ob kompensierende Kontrollen existieren (z. B. UI-seitige Sperren genügen nicht; ggf. nachgelagerte Prüfprozesse).
|
||||
**Klärungsweg:** Sicherheitsbewertung mit Hersteller; im Zielsystem serverseitige Preisermittlung für Neubelege ohne Recht erzwingen. (Referenziert aus SyRS-029.)
|
||||
|
||||
## H-07 [HYPOTHESE] Generisches Feld-Audit wurde nie produktiv aktiviert
|
||||
**Vermutung:** Die ChangeTracking-Infrastruktur (Attribut-gesteuertes Feld-Audit) wurde gebaut, aber nie auf Entities angewendet; feldgenaue Änderungsnachweise existieren nur dort, wo Spezial-Logs implementiert sind.
|
||||
**Indizien:**
|
||||
- [PRIMÄR] `ChangeTrackingEventListener.cs` vollständig implementiert; Suchbefund: keine Entity referenziert `ChangeTrackingConfigurationAttribute`/`TrackChangesAttribute`.
|
||||
**Fehlende Information:** Historie der Entscheidung; ob Kunden Feld-Audits erwarten (z. B. Kundenstamm-Änderungen).
|
||||
**Klärungsweg:** Entwicklerteam befragen; Audit-Anforderungen im Zielsystem explizit festlegen (siehe SwRS-057).
|
||||
|
||||
## H-08 [HYPOTHESE] Mandantenfähigkeit ist funktional begrenzt (kein strikt getrenntes Multi-Tenant-Modell)
|
||||
**Vermutung:** „Mandanten" strukturieren Bankdaten/Zuordnungen innerhalb EINER Datenbank; eine harte Datentrennung (je Mandant eigene Daten-/Rechteräume) besteht nicht – mehrere Gesellschaften werden eher über Filialen abgebildet.
|
||||
**Indizien:**
|
||||
- [PRIMÄR] `MandatorBL.GetMandatorBankInfo` (Mandant über Mitarbeiter aufgelöst, für SEPA); Modul „Mandanten"; keine mandantenbezogenen Filter in den analysierten Suchpfaden (im Gegensatz zu Filialfiltern/-rechten).
|
||||
**Fehlende Information:** Fachliche Definition „Mandant" im Produkt; Anforderungen an Mandantentrennung im SaaS-Zielbild.
|
||||
**Klärungsweg:** Produktmanagement; für SaaS ist ein explizites Tenant-Modell zu spezifizieren.
|
||||
|
||||
## H-09 [HYPOTHESE] SLA-Fristen werden über Prioritäten/Eskalationstypen abgebildet, nicht über Verträge
|
||||
**Vermutung:** Reaktions-/Lösungszeiten sind nicht je Servicevertrag hinterlegt, sondern ergeben sich aus Ticketpriorität + konfigurierten Eskalationstypen; ein vertragsindividuelles SLA-Modell fehlt.
|
||||
**Indizien:**
|
||||
- [PRIMÄR] `EscalationBL` verknüpft Eskalationstypen mit `TicketPriorityI3D`; Vertragsentity ohne SLA-Fristfelder (ReceiptContract.cs, Befund).
|
||||
**Fehlende Information:** Ob Kunden vertragliche SLAs anders pflegen (z. B. über Prioritätszuordnung je Kunde).
|
||||
**Klärungsweg:** Fachexperten Service; im Zielsystem SLA-Modell (je Vertrag/Kunde) entscheiden.
|
||||
|
||||
## H-10 [HYPOTHESE] Produktabgrenzung Riverbird / RiverSuite / RiverDivo / SupRemo
|
||||
**Vermutung:** „Riverbird" ist das RMM-Partnerprodukt (Nutzungsdaten, Webservice-Login-Variante), „RiverSuite"/„RiverDivo"/„SupRemo" sind weitere Integrations- bzw. Schwesterprodukte mit eigenen Rechtebereichen; die genaue Produktlandschaft ist aus dem Code nicht ableitbar.
|
||||
**Indizien:** [PRIMÄR] Namespaces/Ordner `RiverDivo`, `Riversuite`, `SupRemo`, `RiverConnectionBL`, `deployment/riverbird`; [KONTEXT] licensing-system.md erwähnt „Riverbird Web-Service".
|
||||
**Fehlende Information:** Produkt-/Vertriebssicht der Integrationen; welche sind im Zielsystem fortzuführen?
|
||||
**Klärungsweg:** Produktmanagement-Interview; Integrationsinventar priorisieren.
|
||||
|
||||
## H-11 [HYPOTHESE] docuFORM-Anbindung ist eine aktive Spezialintegration
|
||||
**Vermutung:** `Centron.Api.docuFORM` (Root-Verzeichnis) bindet die docuFORM-Druckerverwaltung (MPS) an, vermutlich für Zählerdaten; Nutzungsgrad unklar.
|
||||
**Indizien:** [PRIMÄR] Verzeichnis `Centron.Api.docuFORM` existiert auf Repo-Ebene; `DocuForm`-Ordner in `Centron.BL/DataExchange`.
|
||||
**Fehlende Information:** Kundennutzung, Datenfluss, Relevanz fürs Zielsystem.
|
||||
**Klärungsweg:** Herstellerbefragung; ggf. in Folge-Iteration Code-Analyse dieses Moduls.
|
||||
|
||||
## H-12 [HYPOTHESE] Kein Offline-Betrieb des Desktop-Clients
|
||||
**Vermutung:** Der WPF-Client benötigt stets eine Verbindung (direkt zur DB oder zum Webservice); ein Offline-Modus mit Synchronisation existiert nicht.
|
||||
**Indizien:** [PRIMÄR] Nur zwei ConnectionTypes (SqlServer, CentronWebServices) in der Architekturdoku; keine lokale Persistenz-/Sync-Infrastruktur gefunden.
|
||||
**Fehlende Information:** Bestätigung, dass kein Offline-Szenario (z. B. Techniker vor Ort) unterstützt werden muss.
|
||||
**Klärungsweg:** Anwenderbefragung Servicetechnik.
|
||||
|
||||
## H-13 [HYPOTHESE] E-Rechnungs-Versionsstand entspricht ZUGFeRD 2.1.1 und ist ggf. nicht auf aktuellem XRechnung-Stand
|
||||
**Vermutung:** Die Eigenimplementierung basiert auf ZUGFeRD 2.1.1 (plus 1.0-Altpfad); neuere Normversionen (XRechnung 3.x, ZUGFeRD 2.3) sind möglicherweise nicht abgedeckt.
|
||||
**Indizien:** [PRIMÄR] Eingebettete Spezifikation „ZUGFeRD-2.1.1 - Spezifikation_TA (1).pdf" im BL-Quellbaum; Partialklasse `InvoiceZugferdBL.Zugferd10.cs`; [KONTEXT] xrechnung.md verweist auf KOSIT-Werkzeuge und empfiehlt Bibliothekswechsel.
|
||||
**Fehlende Information:** Tatsächlich erzeugte Profilversionen; Validierungsstand gegen aktuelle KOSIT-Regeln.
|
||||
**Klärungsweg:** Datei-Erzeugung gegen KOSIT-Validator testen (dokumentierte Prüfidee SyRS-022); Normstand für Zielsystem festlegen.
|
||||
|
||||
## H-14 [HYPOTHESE] Lizenzdaten werden nicht zur Laufzeit vom Lizenzserver bezogen
|
||||
**Vermutung:** Die Lizenzprüfung arbeitet gegen lokal (in der Kundendatenbank/-installation) hinterlegte Lizenzdaten; der Lizenzserver des Herstellers ist nur Quelle bei Ausstellung („c-entron Office"-Tool), nicht Laufzeitabhängigkeit.
|
||||
**Indizien:** [KONTEXT] licensing-system.md: „single source of truth … license-server", zugleich Prüfung via lokalem `LicenseManager`; keine Online-Lizenzabruf-Logik im Anmeldepfad gefunden.
|
||||
**Fehlende Information:** Wie Lizenzen zum Kunden gelangen (Datei? DB-Eintrag?) und wie Entzug wirkt.
|
||||
**Klärungsweg:** Herstellerprozess erfragen; SaaS-Zielbild: Lizenzierung neu konzipieren.
|
||||
|
||||
## H-15 [HYPOTHESE] Beleg-Sichtbarkeit im Kundenportal folgt der WebAccount-Kundenzuordnung ohne feineres Rechtemodell
|
||||
**Vermutung:** Portalnutzer sehen alle Belege „ihres" Kunden (Zuordnung über Kontaktperson→Adresse→Kunde); ein feingranulares Belegarten-/Belegebenen-Rechtemodell wie bei Tickets (WebRights) existiert für Belege nicht.
|
||||
**Indizien:** [PRIMÄR] WebAccount-Validierung über Kundenkette (`WebAccountBL.LoginWithWebAccount`); WebRights-Konstanten betreffen Tickets (SHOWONLYOWNREQUESTS …); Portalrouten für Belege ohne erkennbare Rechteparameter.
|
||||
**Fehlende Information:** Detailprüfung der Portal-Belegabfragen (nicht vollständig analysiert).
|
||||
**Klärungsweg:** Folge-Iteration: `CustomerPortal`-Belegabfragen im Nexus-/WebServiceBL-Code analysieren.
|
||||
|
||||
## H-16 [HYPOTHESE] Kennzahldefinitionen der Statistik-/Managementmodule sind implizit
|
||||
**Vermutung:** Die Kennzahlen (Analytics, Management Info, MSP-Dashboard, Vertragsauswertung) sind ausschließlich in SQL/Code definiert; es existiert keine fachliche Kennzahlenspezifikation.
|
||||
**Indizien:** [PRIMÄR] Statistik-Namespaces mit NamedQueries; keine Kennzahl-Doku in docs/.
|
||||
**Fehlende Information:** Verbindliche Definitionen (z. B. „Umsatz" brutto/netto, Stichtagslogik) für die Migration.
|
||||
**Klärungsweg:** Folge-Iteration mit gezielter Analyse der Statistik-Queries + Fachabnahme.
|
||||
|
||||
## H-17 [HYPOTHESE] Telefonie-Integration (TAPI) ist funktional relevant, aber ungeprüft
|
||||
**Vermutung:** TAPI-Server/Client-Integration (Anrufprotokoll, Telefonate-Modul, PhoneMondo) ist produktiv im Einsatz; Verhalten und Anforderungen wurden in dieser Iteration nicht analysiert.
|
||||
**Indizien:** [PRIMÄR] `Entities/Tapi`, `TapiServer`, Modul „Telefonate", `ICentronRestService.PhoneMondo.cs`; [KONTEXT] docs/reference/architecture/tapi.md.
|
||||
**Fehlende Information:** Fachliche Anforderungen der Telefonie.
|
||||
**Klärungsweg:** Folge-Iteration.
|
||||
|
||||
## H-18 [HYPOTHESE] Exchange-/Kalender-Synchronisation hat bekannte Stabilitätsprobleme
|
||||
**Vermutung:** Die Exchange-Synchronisation (Termine/Mails) ist fehleranfällig und wird über ein Bug-Protokoll nachgehalten; für das Zielsystem ist eine robuste Neukonzeption nötig.
|
||||
**Indizien:** [KONTEXT] docs/features/exchange-sync-bugprotokoll.md (eigenes Bugprotokoll als Doku-Artefakt); [PRIMÄR] `ExchangeSyncService.cs`, EWS-Helper.
|
||||
**Fehlende Information:** Aktueller Fehlerstand, fachlicher Soll-Umfang der Synchronisation.
|
||||
**Klärungsweg:** Bugprotokoll auswerten, Anwenderinterviews.
|
||||
|
||||
---
|
||||
|
||||
**Verwendungshinweis:** Hypothesen sind KEINE Anforderungen. Vor Übernahme in eine Spezifikationsversion müssen sie durch Fachexperten bestätigt oder verworfen werden (RRE-Schritt 7). Risikoreiche Bereiche (H-01, H-02, H-06) sollten priorisiert geklärt werden, da sie Abrechnung/Compliance betreffen.
|
||||
+544
@@ -0,0 +1,544 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
|
||||
**System:** c-entron ERP-Suite (Reverse Requirements Engineering aus Codebasis `CentronERP`)
|
||||
**Norm-Referenz:** ISO/IEC/IEEE 29148:2018, Informationselement StRS
|
||||
**Erhebungsmethode:** Statische Analyse der Codebasis (Quellcode, Konfiguration, UI-Ressourcen, Projekt-Dokumentation). Keine Ausführung, keine Stakeholder-Interviews – alle Aussagen sind aus Artefakten rückgeschlossen.
|
||||
|
||||
## Zweck und Systemkontext
|
||||
|
||||
c-entron ist ein Warenwirtschafts- und Servicemanagement-System für IT-Systemhäuser im deutschsprachigen Markt (Hersteller: c-entron software gmbh / NEXOWARE). Es umfasst Vertrieb (Belegkette), Vertrags- und Serviceabrechnung (MSP-Geschäft), Helpdesk/Ticketing, Lager/Einkauf, Forderungsmanagement und Finanzbuchhaltungs-Anbindung. Der klassische Client ist eine Windows-WPF-Anwendung mit zentralem Webservice und MSSQL-Datenbank (On-Premises); ergänzend existiert die Web-Anwendung „Nexus" (ServiceBoard, Kundenportal, WebCart, Online-Signatur).
|
||||
|
||||
## Stakeholder (aus Artefakten abgeleitet)
|
||||
|
||||
| Stakeholder | Ableitung aus Artefakt |
|
||||
|---|---|
|
||||
| Vertriebsinnendienst / Verkauf | Rechtegruppen `UserRightsConst.Sales.*`, Belegmodule |
|
||||
| Servicetechniker / Support-Mitarbeiter | Helpdesk-Module, ServiceBoard, `HelpdeskTimer` |
|
||||
| Buchhaltung | Module Mahnung, OPOS, SEPA, Zahlungseingang, FiBu-Export |
|
||||
| Lager-/Logistikmitarbeiter | Module Inventur, Kommissionierung, Wareneingang |
|
||||
| Einkäufer | Lieferantenbelege, Bestellvorschlag, EDI, Preismatrix |
|
||||
| Systemadministrator (des Kunden) | Rechteverwaltung, Mandanten, Einstellungen, ConnectionManager |
|
||||
| Geschäftsführung | Module Management Info, Analytics, Provisionsauswertung |
|
||||
| Endkunde des Systemhauses | Kundenportal, WebCart, WebOffer/C-Sign, WebAccounts |
|
||||
| Lieferanten/Distributoren | EDI-Anbindungen, Preismatrix-APIs |
|
||||
| Softwarehersteller (c-entron/NEXOWARE) | Lizenzsystem, Telemetrie, Versionierung |
|
||||
| Steuerberater / Finanzverwaltung (mittelbar) | DATEV-Export, ZUGFeRD/XRechnung, Leitweg-ID |
|
||||
|
||||
---
|
||||
|
||||
## Anforderungen
|
||||
|
||||
```
|
||||
ID: StRS-001
|
||||
Titel: Durchgängige Vertriebs-Belegkette
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertriebsinnendienst
|
||||
Vorbedingung: Kunde ist im Adressstamm angelegt.
|
||||
Fakt: Die Codebasis implementiert sieben Kundenbelegarten (Angebot, Auftrag, Lieferschein, Rechnung, Abholschein, Gutschrift, Vertrag) mit gemeinsamer Basisklasse und Weiterverarbeitungslogik zwischen den Belegarten.
|
||||
Aussage: Das System soll den Vertriebsprozess als durchgängige Belegkette abbilden: Vom Angebot über Auftrag und Lieferschein bis zur Rechnung und ggf. Gutschrift, ohne dass Daten manuell neu erfasst werden müssen.
|
||||
Ergebnis: Folgebelege übernehmen Positionen und Konditionen des Ursprungsbelegs; die Herkunft bleibt nachvollziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (ForwardReceipt, Zeile ~1548) – Begründung: implementiert die Überführung von Belegen in Folgebelege inkl. Positionsübernahme.
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs – Begründung: gemeinsame Basisklasse aller Belegarten belegt das einheitliche Belegkonzept.
|
||||
- [KONTEXT] docs/reference/receipts/receipts-backend-architecture.md – Begründung: beschreibt die Belegtypen-Hierarchie und deren Tabellen explizit.
|
||||
Prüfidee: Ein Angebot mit 3 Positionen in einen Auftrag weiterverarbeiten; erwartet: Auftrag enthält die Positionen mit Referenz auf das Angebot (OriginReceiptI3D).
|
||||
Tracelinks: SyRS-001, SyRS-002, SyRS-003, SyRS-005, SyRS-006, SyRS-007, SyRS-010, SyRS-011, SyRS-012, SyRS-013, SyRS-014, SyRS-015, SyRS-053
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-002
|
||||
Titel: Automatisierte wiederkehrende Vertragsabrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Buchhaltung / Vertragsverwaltung
|
||||
Vorbedingung: Verträge mit Abrechnungsintervall und Positionen sind angelegt.
|
||||
Fakt: Es existiert ein Abrechnungszentrum („Vertragsabrechnung"/AutomatedBilling), das aus Verträgen periodisch Rechnungen erzeugt, inkl. Intervall-Multiplikation, Sammelrechnungen und Versand.
|
||||
Aussage: Das System soll wiederkehrende Leistungen (Wartungs-, Service-, Mietverträge) automatisiert und periodengerecht in Rechnungen überführen, um manuellen Abrechnungsaufwand zu minimieren.
|
||||
Ergebnis: Je Abrechnungslauf entstehen Rechnungen mit korrektem Leistungszeitraum, die dem Vertrag zugeordnet und versendet/gedruckt werden.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs (CreateInvoiceToContractComplete, Zeile 1699) – Begründung: vollständiger Abrechnungsprozess Vertrag→Rechnung implementiert.
|
||||
- [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/ – Begründung: eigenes UI-Modul „Vertragsabrechnung" belegt den Geschäftsprozess.
|
||||
- [KONTEXT] docs/reference/receipts/contracts-backend.md – Begründung: beschreibt Billing-Intervalle und automatisierte Abrechnung als Vertragszweck.
|
||||
Prüfidee: Vertrag mit Monatsintervall und 1 Position abrechnen; erwartet: Rechnung mit Position, Leistungszeitraum = Abrechnungsperiode, Vertragszuordnung gespeichert.
|
||||
Tracelinks: SyRS-016, SyRS-017, SyRS-019
|
||||
Konsolidierung: Kandidat: Abrechnungswege Vertragsabrechnung, TimerBilling (StRS-004), Pauschalabrechnung (FlatRateProject) und „Automatische Faktura" überschneiden sich fachlich (Erzeugung von Rechnungen aus Quellobjekten) und sollten im Zielsystem vereinheitlicht werden.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-003
|
||||
Titel: Ticketbasierter Kundenservice mit Eskalation
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Servicetechniker, Support-Leitung
|
||||
Vorbedingung: Kunde existiert; Servicemeldung geht ein (Telefon, Mail, Portal).
|
||||
Fakt: Umfangreiches Helpdesk-Subsystem (52 BL-Klassen) mit Ticket-Entity, konfigurierbaren Status/Prioritäten/Kategorien, Bearbeitern, Fälligkeit, Eskalationslevel und einem 15-minütigen Eskalationsdienst.
|
||||
Aussage: Das System soll Serviceanfragen als Tickets erfassen, priorisieren, Verantwortlichen zuweisen und bei Überschreitung von Fälligkeiten mehrstufig eskalieren, damit Servicezusagen gegenüber Kunden eingehalten werden.
|
||||
Ergebnis: Tickets durchlaufen einen kontrollierten Lebenszyklus bis zum Abschluss; Überfälligkeiten lösen Benachrichtigungen aus.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/CustomerArea/Support/Helpdesk.cs – Begründung: Ticket-Datenmodell mit DueDate, EscalationLevel, Status, Prioritäten.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs (DoEscalation) – Begründung: implementierte mehrstufige Eskalation mit Mailversand.
|
||||
- [KONTEXT] CentronRights.md (Abschnitt Helpdesk) – Begründung: dokumentiert die fachlich gewollten Ticket-Rechte und -Abläufe.
|
||||
Prüfidee: Ticket mit Priorität und Fälligkeit in der Vergangenheit anlegen; erwartet: Eskalationsdienst erhöht EscalationLevel und versendet Mail an konfigurierte Empfänger.
|
||||
Tracelinks: SyRS-034, SyRS-035
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-004
|
||||
Titel: Erfassung und Abrechnung von Servicezeiten
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Servicetechniker, Buchhaltung
|
||||
Vorbedingung: Ticket existiert.
|
||||
Fakt: Zeiterfassung erfolgt als Timer am Ticket (Start/Stopp, Pause, abrechenbar-Flag, Abrechnungsartikel, Vertrag-Zuordnung); ein Abrechnungsmodul überführt Timer in Belege und verknüpft sie mit Auftrag/Lieferschein/Rechnung.
|
||||
Aussage: Das System soll geleistete Servicezeiten tickets- und mitarbeiterbezogen erfassen und wahlweise über Verträge (Kontingente) oder als Einzelleistung fakturieren.
|
||||
Ergebnis: Erfasste Zeiten sind lückenlos einem Ticket zugeordnet und entweder abgerechnet, in einem Kontingent verbraucht oder als nicht abrechenbar gekennzeichnet.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/Support/HelpdeskTimerArea/HelpdeskTimer.cs – Begründung: Datenmodell mit Calculable, Contract, OrderAssetItemI3D/InvoiceAssetItemI3D (Abrechnungsreferenzen).
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (CreateNewReceiptForHelpdekTimers, Zeile 5295) – Begründung: erzeugt Belege aus Ticket-Timern.
|
||||
- [KONTEXT] Commit baa9e7bd9b „rights check for editing invoice or delivery list date in the settings of timer billing" – Begründung: aktive Weiterentwicklung des Timer-Billing-Prozesses.
|
||||
Prüfidee: Zwei abrechenbare Timer zu einem Ticket erfassen und über TimerBilling fakturieren; erwartet: Rechnung mit Zeitpositionen, Timer erhalten InvoiceAssetItemI3D.
|
||||
Tracelinks: SyRS-036, SyRS-037
|
||||
Konsolidierung: Kandidat: siehe StRS-002 (mehrere Abrechnungswege).
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-005
|
||||
Titel: Forderungsmanagement
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Buchhaltung
|
||||
Vorbedingung: Offene Rechnungen existieren.
|
||||
Fakt: Module für Mahnung (3 Stufen, Mahnläufe), OPOS, Zahlungseingang und SEPA-Lastschriftexport sind implementiert; Zahlungsziel wird aus Zahlungskonditionen berechnet.
|
||||
Aussage: Das System soll offene Forderungen überwachen, Zahlungseingänge zuordnen, Lastschriften einziehen und säumige Kunden gestuft mahnen.
|
||||
Ergebnis: Offene Posten sind jederzeit auswertbar; jede Mahn- und Zahlungsaktion ist protokolliert und rückholbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs (ExecuteDunningRun) – Begründung: implementiertes Mahnwesen mit Stufen und Läufen.
|
||||
- [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs – Begründung: SEPA-Export inkl. Rechnungs-Schließung und Rücknahme.
|
||||
- [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs (Module „Mahnung", „OPOS", „SEPA", „Zahlungseingang") – Begründung: eigenständige Module belegen den Geschäftsprozess in der Benutzeroberfläche.
|
||||
Prüfidee: Überfällige Rechnung mahnen; erwartet: DunningLevel 1 mit Datum/Bearbeiter, Mahnlauf-Nummer vergeben, Mahnschreiben erzeugt.
|
||||
Tracelinks: SyRS-010, SyRS-020, SyRS-023, SyRS-024
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-006
|
||||
Titel: Übergabe an die Finanzbuchhaltung
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Akteur: Buchhaltung, Steuerberater (extern)
|
||||
Vorbedingung: Abgeschlossene Belege und gepflegte Konten (Kontenrahmen) liegen vor.
|
||||
Fakt: Export von Personenkonten und Buchungsdaten in DATEV ASCII, DATEV XML Online (2020), Abacus und kundenspezifische Formate; exportierte Belege werden markiert und gegen unbemerkte Änderung geschützt.
|
||||
Aussage: Das System soll Rechnungs- und Stammdaten periodisch an die Finanzbuchhaltung übergeben, sodass die Buchführung ohne Doppelerfassung erfolgen kann.
|
||||
Ergebnis: Übergabedateien im Zielformat; übergebene Belege sind als exportiert gekennzeichnet.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs – Begründung: implementiert Export von Kunden-/Lieferanten- und Buchungsdaten inkl. Formatwahl.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (HandleIsAlreadyExported, Zeile 8478) – Begründung: erzwingt Rückfrage bei Änderung bereits exportierter Belege.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs (Module „Buchhaltungsexport/-import", „Datev Belegtransfer", „Kontenrahmen") – Begründung: UI-Module für den Prozess.
|
||||
Prüfidee: Rechnung exportieren und anschließend neue Version anlegen; erwartet: Dialog „Dieser Beleg wurde bereits an die Buchhaltung übergeben…".
|
||||
Tracelinks: SyRS-021
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-007
|
||||
Titel: Elektronische Rechnungsstellung (ZUGFeRD/XRechnung)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Buchhaltung, Endkunde/Behörde als Rechnungsempfänger
|
||||
Vorbedingung: Rechnung ist erstellt; Kunde hat ggf. Leitweg-ID.
|
||||
Fakt: Eigene ZUGFeRD-Implementierung (InvoiceZugferdBL, Spezifikation 2.1.1 als PDF im Repo), Leitweg-ID-Ermittlung je Kunde, ZUGFeRD-Dateiname als Mailanhang der Vertragsabrechnung.
|
||||
Aussage: Das System soll Rechnungen zusätzlich als strukturierte E-Rechnung (ZUGFeRD/XRechnung) erzeugen und versenden können, um gesetzliche Anforderungen öffentlicher und privater Empfänger zu erfüllen.
|
||||
Ergebnis: Zur Rechnung existiert eine standardkonforme XML-/Hybrid-Datei; Behördenempfänger werden über die Leitweg-ID adressiert.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs – Begründung: Implementierung der ZUGFeRD-Erzeugung.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (GetLeitwegID, Zeile 3417; GetLocalZUGFeRDSetting, Zeile 3438) – Begründung: kunden-/belegbezogene E-Rechnungs-Steuerung.
|
||||
- [KONTEXT] docs/reference/zugferd-field-mapping.md, docs/guides/development/xrechnung.md – Begründung: dokumentierte Feldzuordnung und Normbezug.
|
||||
Prüfidee: Rechnung mit aktivierter ZUGFeRD-Einstellung versenden; erwartet: Mailanhang mit ZUGFeRD-Datei (Name gemäß GetZugferdFileName).
|
||||
Tracelinks: SyRS-022
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-008
|
||||
Titel: Bestands-, Beschaffungs- und Fertigungssteuerung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Lagermitarbeiter, Einkäufer, Fertigung
|
||||
Vorbedingung: Artikelstamm mit Beständen und Mindestbeständen ist gepflegt.
|
||||
Fakt: Bestandsführung über Haupt-/Nebenläger mit Bedarfsrechnung (Bestellvorschlag), EK-Fortschreibung beim Wareneingang, Seriennummern-/Barcodeverwaltung, Inventurmodul, Kommissionierung und Produktionsaufträgen.
|
||||
Aussage: Das System soll Lagerbestände über mehrere Läger führen, Beschaffungsbedarf automatisch ermitteln und Kommissionierung, Inventur sowie einfache Fertigungsaufträge unterstützen.
|
||||
Ergebnis: Bestände, Bedarf und Seriennummern sind konsistent; Bestellvorschläge decken Unterdeckungen ab.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs – Begründung: implementierte Bedarfsformel (Auftragsbedarf + Mindestbestand − Bestand − offene Zugänge).
|
||||
- [PRIMÄR] src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs – Begründung: Bestandsführung und EK-Fortschreibung.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs (Module „Inventur", „Kommissionierung", „Produktionsaufträge", „Artikelverwaltung") – Begründung: Module belegen die Prozesse.
|
||||
Prüfidee: Artikel mit Mindestbestand 5 und Bestand 2 anlegen; erwartet: Artikel erscheint im Bestellvorschlag mit Bedarf ≥ 3.
|
||||
Tracelinks: SyRS-038, SyRS-039, SyRS-040, SyRS-041, SyRS-055
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-009
|
||||
Titel: Einkaufsabwicklung mit Lieferantenbelegkette
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Einkäufer
|
||||
Vorbedingung: Lieferant ist angelegt.
|
||||
Fakt: Eigene Lieferantenbelegarten (Bestellung, Wareneingang/Lieferschein, Eingangsrechnung, Lieferantengutschrift) mit eigener Weiterverarbeitungskette und Prüfung doppelter externer Rechnungsnummern.
|
||||
Aussage: Das System soll den Einkaufsprozess von der Bestellung über den Wareneingang bis zur Eingangsrechnung als Belegkette abbilden und typische Fehler (z. B. doppelt erfasste Lieferantenrechnungen) verhindern.
|
||||
Ergebnis: Einkaufsbelege sind verkettet; doppelte externe Rechnungsnummern werden erkannt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/SupplierOrders/SupplierOrderSpecificLogic.cs (CanBeForwardedInto → SupplierDeliveryList) und SupplierDeliveryLists/SupplierInvoices/SupplierCreditVouchers-Pendants – Begründung: implementierte Lieferantenkette.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (CheckExternalInvoiceNumberAlreadyUsed, Zeile 4182; GetDuplicateSupplierExternalInvoiceReceiptDescription, Zeile 5095) – Begründung: Dublettenprüfung externer Rechnungsnummern.
|
||||
- [SEKUNDÄR] UserRightsConst.cs (Klasse Purchase.Supplier mit Offer/Order/DeliveryList/Invoice/CreditVoucher/Contract) – Begründung: Rechtekatalog spiegelt die Einkaufsbelegarten.
|
||||
Prüfidee: Zwei Eingangsrechnungen mit identischer externer Rechnungsnummer erfassen; erwartet: Warnung/Hinweis auf vorhandenen Beleg.
|
||||
Tracelinks: SyRS-004
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-010
|
||||
Titel: Zentrale Kunden- und Adressverwaltung mit CRM
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertrieb, Service, Buchhaltung
|
||||
Vorbedingung: —
|
||||
Fakt: Adressstamm (Accounts) mit Ansprechpartnern, Adressen, Bankverbindungen, kundenindividuellen Konditionen (Zahlungskonditionen je Belegart, Preisliste, Rabatt, Kreditlimit, Mahnparameter) sowie CRM-Aktivitäten, Kampagnen und Umfragen.
|
||||
Aussage: Das System soll Kunden mit allen vertriebs- und abrechnungsrelevanten Konditionen zentral führen, sodass Belege, Service und Mahnwesen dieselbe Datenbasis nutzen.
|
||||
Ergebnis: Kundenkonditionen wirken automatisch in allen Prozessen (Belegerstellung, Preisfindung, Mahnwesen).
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/CustomerArea/Customer.cs – Begründung: Kundenentity mit PaymentCondition*I3D je Belegart, PriceList, CreditLimit, Dunning-Feldern.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs (Module „Adressstamm", „CRM", „Kampagnen/Mailing") – Begründung: Module für Pflege und CRM.
|
||||
- [KONTEXT] README.md („create one in c-entron.NET Adressstamm") – Begründung: Adressstamm als zentrale Anlaufstelle dokumentiert.
|
||||
Prüfidee: Kunde mit Zahlungskondition „30 Tage" für Rechnungen anlegen und Rechnung erstellen; erwartet: Fälligkeitsdatum = Rechnungsdatum + 30 Tage.
|
||||
Tracelinks: SyRS-010, SyRS-042
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-011
|
||||
Titel: Artikelstamm und regelbasierte Preisfindung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertrieb, Einkauf, Produktmanagement
|
||||
Vorbedingung: Artikel sind angelegt oder werden aus Distributorenkatalogen übernommen.
|
||||
Fakt: Artikelstamm mit 4 Preislisten, Staffelpreisen, Mindestpreis, Listenpreis/EVP, kundenspezifischen Sonderpreisen/Sonderabsprachen, Aktionspreisen und einer Preismatrix mit externen Distributorenquellen; Preisfindung beim Positionseinfügen berücksichtigt Kunde, Vertrag, Menge und Sonderabsprachen.
|
||||
Aussage: Das System soll Verkaufspreise regelbasiert aus Kundenzuordnung, Vereinbarungen, Menge und aktuellen Einkaufsquellen ermitteln, sodass Positionen ohne manuelle Preisrecherche korrekt bepreist werden.
|
||||
Ergebnis: Beim Einfügen eines Artikels in einen Beleg werden VK, EK, Rabatt und MwSt automatisch korrekt vorbelegt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptItemBL.cs (UpdateReceiptItemWithArticleInfo, Zeile 3958, Region „Price Calculation") – Begründung: implementierte Preisfindungskaskade.
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/Warehousing/StockManagement/Article.cs (Price1–4, GetPrice, VolumePrices, MinPrice-Nutzung) – Begründung: Preisdatenmodell.
|
||||
- [KONTEXT] docs/reference/receipts/actionprice-system.md – Begründung: dokumentiert Preismatrix und Aktionspreise.
|
||||
Prüfidee: Kunde mit Preisliste 2 und Artikel mit abweichendem Price2 anlegen; erwartet: Belegposition übernimmt Price2 als Basispreis.
|
||||
Tracelinks: SyRS-009, SyRS-046, SyRS-056
|
||||
Konsolidierung: Kandidat: Sonderpreise existieren mehrfach (AccountSpecialPrice am Konto, AddressSpecialArticle an der Adresse, SpecialAgreement, Vertragspreise) – im Zielsystem zu einem Preisregelwerk zusammenführen.
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-012
|
||||
Titel: Begrenzung des Kreditrisikos
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Vertrieb, Buchhaltung, Geschäftsführung
|
||||
Vorbedingung: Kunde hat Kreditlimit > 0 und aktive Berechnungsart.
|
||||
Fakt: Beim Speichern limitrelevanter Belege wird das Kreditlimit gegen die Summe offener Belege (netto oder brutto) geprüft; Überschreitung erzeugt einen Warndialog mit Detailaufstellung und erfordert bewusste Bestätigung.
|
||||
Aussage: Das System soll verhindern, dass Aufträge das eingeräumte Kreditlimit eines Kunden unbemerkt überschreiten.
|
||||
Ergebnis: Limitüberschreitungen werden vor dem Speichern angezeigt; das verfügbare Limit wird am Kunden fortgeschrieben.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (CheckIfCustomerLimitIsReached, Zeile 8636) – Begründung: vollständige Limitprüfung mit Dialogtext „Das Limit von … wurde um … überschritten".
|
||||
- [PRIMÄR] src/backend/Centron.Entities/Entities/CustomerArea/Customer.cs (CreditLimit, CreditLimitAvailable, CreditLimitCalculationKind) – Begründung: Datenmodell der Limitsteuerung.
|
||||
Prüfidee: Kunde mit Limit 1.000 € (brutto) und offenem Auftrag über 900 €; neuen Auftrag über 200 € speichern; erwartet: Warndialog mit Differenz 100 €.
|
||||
Tracelinks: SyRS-008
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-013
|
||||
Titel: Rollenbasierte Zugriffskontrolle mit Eigentums- und Filialbeschränkung
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Akteur: Systemadministrator (des Kunden), alle Benutzer
|
||||
Vorbedingung: Benutzer und Rechtegruppen sind angelegt.
|
||||
Fakt: Feingranularer Rechtekatalog (UserRightsConst, > 2800 Zeilen) mit Modulen, Aktionen und „einschränkenden Rechten" (nur eigene Objekte, nur eigene Filiale); Prüfungen erfolgen in UI, Modulregistrierung und Business-Logik.
|
||||
Aussage: Das System soll Funktionen und Datensichten rollenbasiert steuern und dabei auch Einschränkungen auf eigene Objekte bzw. die eigene Filiale durchsetzen.
|
||||
Ergebnis: Benutzer sehen und bearbeiten nur die Objekte, für die ihre Rechtegruppen sie autorisieren.
|
||||
Belege:
|
||||
- [PRIMÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs – Begründung: zentraler Rechtekatalog.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs (Zeile 269–291, ShowHelpdeskRight) – Begründung: implementierte Durchsetzung einschränkender Rechte (nur eigene / nur eigene Filiale).
|
||||
- [KONTEXT] CentronRights.md; docs/guides/development/check-userrights.md – Begründung: dokumentierte Rechtesemantik und Prüfmuster.
|
||||
Prüfidee: Benutzer mit SHOW_HELPDESK + SHOW_HELPDESK_ONLY_OWN meldet sich an; erwartet: Ticketliste enthält nur Tickets, in denen er Bearbeiter oder Verantwortlicher ist.
|
||||
Tracelinks: SyRS-029
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-014
|
||||
Titel: Nachvollziehbarkeit und Revisionsfähigkeit
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (ISO 25010: Funktionale Eignung/Verlässlichkeit; Compliance-Ziel)
|
||||
Akteur: Buchhaltung, Wirtschaftsprüfer (mittelbar), Support-Leitung
|
||||
Vorbedingung: —
|
||||
Fakt: Belege werden versioniert (Versionstabellen als 1:1-Kopien), jede Belegaktion (Druck, Mail, Storno, Zahlungsmarkierung, EDI) wird im AnlageLog protokolliert; Anlage-/Änderungs-Metadaten (CreatedBy/ChangedBy) sind Tabellenkonvention; Login-IP und Anmeldungen werden gespeichert.
|
||||
Aussage: Das System soll Änderungen an geschäftskritischen Objekten so aufzeichnen, dass frühere Zustände rekonstruierbar sind und Aktionen einem Benutzer und Zeitpunkt zugeordnet werden können.
|
||||
Ergebnis: Für jeden Beleg existiert eine lückenlose Versions- und Ereignishistorie.
|
||||
Belege:
|
||||
- [PRIMÄR] docs/reference/receipts/receipts-backend-architecture.md i. V. m. Centron.DAO (AssetHeadDAO.SaveAssetVersion, Versionstabellen `*KopfVersions`) – Begründung: implementiertes Versionierungsschema.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs – Begründung: Protokollierung von Belegereignissen inkl. Benutzer und Zeit.
|
||||
- [SEKUNDÄR] docs/guides/database/database-conventions.md (CreatedByI3D/ChangedByI3D/IsDeleted) – Begründung: Konvention für Nachvollziehbarkeit auf Datensatzebene.
|
||||
Prüfidee: Beleg zweimal ändern; erwartet: zwei Einträge in der Versionstabelle mit OriginalI3D-Referenz; ReceiptLog enthält die Aktionen.
|
||||
Tracelinks: SyRS-006, SyRS-048
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-015
|
||||
Titel: Kundenportal-Self-Service
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Endkunde des Systemhauses
|
||||
Vorbedingung: Endkunde besitzt einen aktiven WebAccount.
|
||||
Fakt: Blazor-Webanwendung mit Kundenportal-Routen: Tickets (anlegen, Verlauf, Zeiten, Dokumente), Belege einsehen (inkl. PDF-Vorschau, Verträge), Dokumente, Formulare; Portal-Rechte pro WebAccount (nur eigene / alle Anfragen, Kundenadministrator).
|
||||
Aussage: Das System soll Endkunden einen Web-Zugang bieten, über den sie Tickets eröffnen und verfolgen sowie ihre Belege und Dokumente einsehen können, ohne den Support telefonisch zu kontaktieren.
|
||||
Ergebnis: Endkunden bedienen Standardanliegen selbstständig; Sichtbarkeit folgt den Portal-Rechten.
|
||||
Belege:
|
||||
- [PRIMÄR] src/nexus/CentronNexus (Routen /customerportal/tickets, /customerportal/receipts/…, /customerportal/documents) – Begründung: implementierte Portalfunktionen.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs (Zeile 240–266, WebAccountRightsConst-Auswertung) – Begründung: Portal-Sichtbarkeitsrechte durchgesetzt.
|
||||
Prüfidee: WebAccount mit SHOWONLYOWNREQUESTS meldet sich im Portal an; erwartet: nur selbst gemeldete Tickets sichtbar.
|
||||
Tracelinks: SyRS-042
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-016
|
||||
Titel: Digitale Angebotsannahme und Signatur
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Endkunde, Vertrieb
|
||||
Vorbedingung: Beleg wurde als Web-Dokument mit Token-Link bereitgestellt.
|
||||
Fakt: WebOffer/C-Sign: Belege werden per Token-URL bereitgestellt; Zustände InProcess, AcceptFullWebReceipt, AcceptWebReceiptWithChangeRequests, Rejected, SendToCustomer; Annahme mit/ohne Unterschrift, Änderungswünsche je Position, Ablehnung mit Benachrichtigung des Bearbeiters.
|
||||
Aussage: Das System soll Kunden ermöglichen, Angebote online einzusehen, anzunehmen (auch rechtsverbindlich mit Unterschrift), Änderungswünsche zu äußern oder abzulehnen, und den Vertrieb über das Ergebnis informieren.
|
||||
Ergebnis: Der Angebotsstatus ist ohne Medienbruch dokumentiert; angenommene Angebote können direkt weiterverarbeitet werden.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (ChangeWebReceiptState, Zeile 5903; AcceptWebReceipt/RejectedWebReceipt, Zeilen 6256–6436) – Begründung: implementierter Annahme-/Ablehnungsprozess.
|
||||
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs – Begründung: Statusmodell der Online-Annahme.
|
||||
- [KONTEXT] Commit 89ccfd650d „Ticket 168496 & 169060 - C-Sign (WebOffer & Acceptance)" – Begründung: Feature-Zuordnung und Aktualität.
|
||||
Prüfidee: Angebot per Token öffnen und mit Unterschrift annehmen; erwartet: Status AcceptFullWebReceipt, signiertes PDF archiviert, Bearbeiter benachrichtigt.
|
||||
Tracelinks: SyRS-044
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-017
|
||||
Titel: B2B-Webshop (WebCart)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Endkunde des Systemhauses
|
||||
Vorbedingung: WebAccount vorhanden; Sonderpreise für den Kunden gepflegt.
|
||||
Fakt: WebCart-Bereich in Nexus (Shop, Warenkorb, Belegübersicht); Sortiment stammt laut Projekt-README aus den Sonderpreisen des Kunden.
|
||||
Aussage: Das System soll Endkunden einen Webshop mit ihrem individuell bepreisten Sortiment bieten, aus dem Bestellungen in die Belegverarbeitung des Systemhauses einfließen.
|
||||
Ergebnis: Bestellungen aus dem Shop erscheinen als Belege beim Systemhaus; Preise entsprechen den Kundenvereinbarungen.
|
||||
Belege:
|
||||
- [PRIMÄR] src/nexus/CentronNexus/WebCart (Routen /webcart/shop, /webcart/cart, /webcart/receipts/…) – Begründung: implementierter Shop.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs (GetSpecialPricesWithArticles, Zeile 228) – Begründung: Sortiment aus AccountSpecialPrice.
|
||||
- [KONTEXT] README.md Abschnitt „WebCart" – Begründung: dokumentiert Zielgruppe („customers of our customers") und Sonderpreis-Basis.
|
||||
Prüfidee: Kunde mit 2 Sonderpreisen meldet sich im Shop an; erwartet: genau diese Artikel mit Sonderpreisen sichtbar.
|
||||
Tracelinks: SyRS-043
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-018
|
||||
Titel: Automatisierter Lieferanten-EDI
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Akteur: Einkäufer, Lieferanten/Distributoren
|
||||
Vorbedingung: EDI-Konfiguration je Lieferant ist hinterlegt.
|
||||
Fakt: EDI-Downloaddienst (alle 30 Minuten) holt Auftragsbestätigungen, Lieferavis und Rechnungen per FTP/SFTP/FTPS von Distributoren (ALSO, ALSO CH, Alltron, Herweck, Komsa, OpenTrans 2.1) und verarbeitet sie in Belege; Log-Bereinigung nach 185 Tagen.
|
||||
Aussage: Das System soll Belege der Distributoren automatisch abholen und den Einkaufsbelegen zuordnen, um manuelle Erfassung und Übertragungsfehler zu vermeiden.
|
||||
Ergebnis: Lieferantenbelege entstehen bzw. aktualisieren sich ohne manuelle Erfassung; Verarbeitung ist protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/EdiDownloadService.cs (Intervall 30 min, Zeile 35–38) – Begründung: implementierter automatischer Abruf.
|
||||
- [PRIMÄR] src/backend/Centron.BL/EDI/SupplierEDI/ (SupplierEdiBL.*-Partialklassen) – Begründung: lieferantenspezifische Verarbeitung.
|
||||
- [KONTEXT] docs/reference/edi/edi-architecture.md, docs/reference/edi/edi-import-rules.md – Begründung: dokumentierte Architektur und Ablauf.
|
||||
Prüfidee: EDI-Testdatei eines unterstützten Lieferanten bereitstellen; erwartet: Beleg wird importiert, EDI-Log-Eintrag entsteht.
|
||||
Tracelinks: SyRS-045
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-019
|
||||
Titel: Lizenzbasierte Steuerung des Funktionsumfangs
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (Herstellerziel; ISO 25010: Funktionale Eignung)
|
||||
Akteur: Softwarehersteller, Systemadministrator
|
||||
Vorbedingung: Lizenzdaten des Kunden liegen vor (Lizenzserver).
|
||||
Fakt: Lizenzen sind GUIDs mit Count, Gültigkeitsdatum und Maximalversion; Anmeldungen je Anwendung werden gegen Lizenz-Count geprüft; Einzelfeatures (z. B. Eskalationsserver, Passwort-Manager, MyDay-Importe) werden per LicenseManager ein-/ausgeblendet.
|
||||
Aussage: Das System soll den nutzbaren Funktionsumfang und die Anzahl gleichzeitiger Anmeldungen je Anwendung anhand der erworbenen Lizenzen begrenzen.
|
||||
Ergebnis: Nicht lizenzierte Funktionen sind nicht nutzbar; Lizenzüberschreitungen verhindern die Anmeldung.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs (AuthenticateUser: LicenseManager.CheckLicense vor Ticketvergabe) – Begründung: Lizenzprüfung im Anmeldefluss.
|
||||
- [PRIMÄR] src/webservice/Centron.Host/AspNetCore/HostedServices/EscalationsService.cs (HasLicense(LicenseGuids.EscalationsServer)) – Begründung: featurebezogene Lizenzprüfung.
|
||||
- [KONTEXT] docs/reference/security/licensing-system.md – Begründung: dokumentiertes Lizenzmodell.
|
||||
Prüfidee: Anmeldeversuch, wenn Lizenz-Count erschöpft ist; erwartet: Fehlermeldung, kein Sitzungs-Ticket.
|
||||
Tracelinks: SyRS-028
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-020
|
||||
Titel: Mehrfilial- und Mandantenfähigkeit
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Geschäftsführung, Systemadministrator
|
||||
Vorbedingung: Filialen/Mandanten sind angelegt.
|
||||
Fakt: Filialen mit eigenen Nummernkreisen, filialbezogene Belege (BranchI3D aus Ersteller oder Betreuer), filialbeschränkende Rechte, „Kalkulation pro Filiale"; Mandantenverwaltung mit eigenen Bankdaten pro Mandant.
|
||||
Aussage: Das System soll mehrere Filialen (und Mandanten) einer Unternehmensgruppe abbilden, mit getrennten Nummernkreisen, filialbezogener Sichtbarkeit und mandantenbezogenen Zahlungsdaten.
|
||||
Ergebnis: Belege und Auswertungen sind filial-/mandantenbezogen korrekt getrennt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (UpdateReceiptNumber mit branch-spezifischer NumberGroup, Zeile 7265; GetBranchForNewReceipt, Zeile 7309) – Begründung: filialbezogene Nummern und Filialermittlung.
|
||||
- [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs (GetMandatorBankInfo über Mitarbeiter→Mandant) – Begründung: mandantenbezogene Bankdaten im Zahlungsverkehr.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs (Modul „Mandanten", „Kalkulation pro Filiale") – Begründung: eigene Verwaltungsmodule.
|
||||
Prüfidee: Zwei Filialen mit getrennten Rechnungs-Nummernkreisen; je eine Rechnung erstellen; erwartet: Nummern aus dem jeweiligen Filialkreis.
|
||||
Tracelinks: SyRS-005, SyRS-029
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-021
|
||||
Titel: DSGVO-Prozessunterstützung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Systemhaus (Verantwortlicher), Endkunde
|
||||
Vorbedingung: AVV-Vorlagen sind gepflegt.
|
||||
Fakt: DSGVO-Modul mit Auftragsverarbeitungsvertrags-Vorlagen, Online-Bereitstellung von PDF-Dokumenten zur Bestätigung/Unterschrift oder Ablehnung (mit Grund) sowie online bestätigbaren SEPA-Mandaten (Bankname, BIC, IBAN, Unterschrift).
|
||||
Aussage: Das System soll den Abschluss von Auftragsverarbeitungsverträgen und SEPA-Mandaten digital unterstützen, inklusive Nachweis von Ort, Datum und Unterschrift.
|
||||
Ergebnis: Bestätigte AVV/SEPA-Dokumente liegen signiert und dem Kunden zugeordnet vor.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Documents/Dsgvo/DsgvoBL.cs (ConfirmOnlinePdfDocument mit signPlace/signDate/signature; DeclineOnlinePdfDocument) – Begründung: implementierter Bestätigungsprozess.
|
||||
- [SEKUNDÄR] UserRightsConst.cs (Klasse DsgvoModule) – Begründung: eigener Rechtebereich für das DSGVO-Modul.
|
||||
Prüfidee: AVV-Dokument online bestätigen; erwartet: Signatur, Ort und Datum gespeichert; Dokument dem Kundenkonto zugeordnet.
|
||||
Tracelinks: SyRS-047
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-022
|
||||
Titel: Auswertungen und Provisionsabrechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: Geschäftsführung, Vertriebsleitung
|
||||
Vorbedingung: Bewegungsdaten (Belege, Zeiten, Verträge) liegen vor.
|
||||
Fakt: Statistik-/Auswertungsmodule (Analytics, Management Info, Vertragsauswertung, Leistungsnachweise, Mitarbeiterauslastung, MSP-Dashboard) sowie Provisionsschemata mit Kundenzuordnung und Provisionsauswertung.
|
||||
Aussage: Das System soll Führungskennzahlen (Umsatz, Verträge, Auslastung, MSP-Kennzahlen) bereitstellen und Vertriebsprovisionen nach konfigurierbaren Schemata ermitteln.
|
||||
Ergebnis: Auswertungen sind ohne Datenexport im System abrufbar; Provisionen sind nachvollziehbar berechnet.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs, ReceiptProvisionEmployeeGoalBL.cs, ReceiptProvisionEmployeeLevelBL.cs – Begründung: implementierte Provisionslogik.
|
||||
- [SEKUNDÄR] ModuleRegistration.cs (Module „Analytics", „Management Info", „Provisionsauswertung", „Provisionsschemas verwalten", „Vertragsauswertung", „MSP-Dashboard") – Begründung: Auswertungsmodule.
|
||||
Prüfidee: Provisionsschema einem Kunden zuordnen und Rechnung fakturieren; erwartet: Provisionsauswertung weist die Rechnung dem Mitarbeiter mit Schema-Satz zu.
|
||||
Tracelinks: SyRS-053, SyRS-054
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-023
|
||||
Titel: Ausrichtung auf den deutschsprachigen Markt mit DACH-Besonderheiten
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (ISO 25010: Funktionale Eignung / Übertragbarkeit)
|
||||
Akteur: Alle Benutzer, Behörden (AT/CH-Formate)
|
||||
Vorbedingung: —
|
||||
Fakt: Deutsch ist Pflichtsprache der UI (dokumentierte „German-First"-Policy, deutsche Basis-RESX, englische .en-RESX); Schweizer Rappenrundung als Einstellung; österreichisches SEPA-Format (STUZZA); Fremdwährungen mit Kursfaktor.
|
||||
Aussage: Das System soll primär deutschsprachig sein (Englisch als Zweitsprache) und die abrechnungsrelevanten Besonderheiten von Deutschland, Österreich und der Schweiz (Rundung, SEPA-Formate, Währungen) unterstützen.
|
||||
Ergebnis: UI-Texte und Belege erscheinen deutsch; CH-Belege runden auf 5 Rappen; AT-SEPA-Dateien sind STUZZA-konform.
|
||||
Belege:
|
||||
- [PRIMÄR] src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs (0.05-Rundung bei switzerlandRounding) – Begründung: implementierte CH-Rundung.
|
||||
- [PRIMÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs (PAIN 008.001.01 STUZZA) – Begründung: AT-Format implementiert.
|
||||
- [KONTEXT] docs/getting-started/general-structure.md („German-First Language Policy") – Begründung: dokumentierte Sprachpolitik.
|
||||
Prüfidee: Beleg mit aktivierter CH-Rundung: Bruttosumme 100,02 CHF; erwartet: Rundung auf 100,00 CHF (5-Rappen-Schritt).
|
||||
Tracelinks: SyRS-012, SyRS-013, SyRS-014, SyRS-049
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-024
|
||||
Titel: On-Premises-Betrieb beim Systemhaus mit Web-Erweiterung
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional (ISO 25010: Übertragbarkeit / Betreibbarkeit)
|
||||
Akteur: Systemadministrator
|
||||
Vorbedingung: Windows-Server mit MSSQL; optional Linux für den Webservice.
|
||||
Fakt: Verteilung als Windows-Installer (WixSharp), Webservice als Windows-Dienst/Konsole, dokumentierter Linux-Betrieb, Docker-Images, zentrale XML-Konfiguration (WebServiceConfig.xml) über ein ConnectionManager-Tool, MSSQL als einzige Datenbank.
|
||||
Aussage: Das System soll beim Kunden (Systemhaus) selbst betrieben werden können: Windows-basierte Installation, zentraler Webservice vor einer MSSQL-Datenbank, konfigurierbar ohne Quellcodeeingriff; die Web-Anwendung ergänzt den Desktop-Client.
|
||||
Ergebnis: Ein Administrator installiert und konfiguriert das System mit Herstellerwerkzeugen; Web-Clients verbinden sich über den Webservice.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/WebServiceConfiguration/WebServiceConfig.cs – Begründung: zentrale Betriebskonfiguration (DB, TLS, Proxy, 2FA).
|
||||
- [PRIMÄR] deployment/WixSharpInstaller, src/webservice/Centron.Host.WindowsService, docker/ – Begründung: Installations- und Betriebsartefakte.
|
||||
- [KONTEXT] docs/guides/services/web-service-on-linux.md – Begründung: dokumentierter Linux-Betrieb.
|
||||
Prüfidee: Installation per Setup, Konfiguration per ConnectionManager, Start des Dienstes; erwartet: Webservice erreichbar, Clients können sich anmelden.
|
||||
Tracelinks: SyRS-050, SyRS-051, SyRS-032, SyRS-033, SyRS-052
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-025
|
||||
Titel: Nutzungsbasierte Abrechnung aus RMM-/MSP-Daten
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Akteur: MSP-Verantwortlicher, Buchhaltung
|
||||
Vorbedingung: Vertrag ist als RMM-Vertrag konfiguriert; RMM-System (z. B. Riverbird) liefert Nutzungsdaten.
|
||||
Fakt: Bei der Vertragsabrechnung werden Nutzungsmengen aus dem RMM-System abgerufen und als Positionen eingefügt; bei Nichterreichbarkeit des RMM-Service wird die Rechnungserstellung abgebrochen, um Falschabrechnung zu verhindern; MSP-Collector/-Auswertung aggregieren Kennzahlen.
|
||||
Aussage: Das System soll verbrauchsabhängige Managed-Services-Leistungen automatisch aus dem Monitoring-System abrechnen und unvollständige Abrechnungen technisch verhindern.
|
||||
Ergebnis: Rechnungen enthalten die tatsächlichen Nutzungsmengen der Abrechnungsperiode oder werden nicht erstellt.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs (CheckRMMArticle, Zeile 721; RMMServiceUnavailableException, Zeile 2414) – Begründung: Abrechnung inkl. Abbruchgarantie implementiert.
|
||||
- [KONTEXT] docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md – Begründung: dokumentierter Fachprozess inkl. Fehlerverhalten.
|
||||
Prüfidee: Vertragsabrechnung bei abgeschaltetem RMM-Service starten; erwartet: Abbruch mit Meldung „…RMM-Service nicht erreichbar", keine Rechnung.
|
||||
Tracelinks: SyRS-018
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
|
||||
```
|
||||
ID: StRS-026
|
||||
Titel: Sichere Anmeldung und Identitätsintegration
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Akteur: Alle Benutzer, Systemadministrator
|
||||
Vorbedingung: Benutzerkonto existiert.
|
||||
Fakt: Anmeldeverfahren: Benutzername/Passwort, Active Directory, Microsoft Entra ID (OpenID Connect), WebAccounts; optionale Zwei-Faktor-Authentifizierung (RADIUS oder E-Mail-Link) mit konfigurierbarer Gültigkeitsdauer; zeitgesteuerte Kontodeaktivierung; Sitzungs-Tickets mit Ablauf.
|
||||
Aussage: Das System soll Benutzer sicher authentifizieren, bestehende Unternehmens-Identitäten (AD/Entra ID) integrieren und eine Zwei-Faktor-Absicherung anbieten.
|
||||
Ergebnis: Nur berechtigte, aktive Benutzer erhalten Sitzungen; 2FA ist je Benutzer erzwingbar.
|
||||
Belege:
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/ (BasicAuthenticator, ActiveDirectoryAuthenticator, OpenIdConnectAuthenticator, WebAccountAuthenticator) – Begründung: implementierte Verfahren.
|
||||
- [PRIMÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs – Begründung: 2FA-Logik mit Gültigkeitsdauer.
|
||||
- [KONTEXT] docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md – Begründung: dokumentierter Entra-ID-Fluss.
|
||||
Prüfidee: Benutzer mit aktivierter 2FA meldet sich nach Ablauf der Gültigkeitsdauer an; erwartet: zweiter Faktor wird erneut verlangt.
|
||||
Tracelinks: SyRS-025, SyRS-026, SyRS-027, SyRS-030, SyRS-031, SyRS-032
|
||||
Konsolidierung: nein
|
||||
Status: belegt
|
||||
```
|
||||
+1252
File diff suppressed because it is too large
Load Diff
+1101
File diff suppressed because it is too large
Load Diff
+79
@@ -0,0 +1,79 @@
|
||||
# Traceability-Matrix
|
||||
|
||||
Konsolidierte Forward-/Backward-Traceability über die drei Ebenen. Eine Zeile pro SwRS-Anforderung (unterste Ebene); die Spalten StRS/SyRS zeigen die übergeordnete Kette. SyRS-Anforderungen mit mehreren StRS-Bezügen erscheinen mit ihrem primären StRS-Bezug; vollständige Mehrfachbezüge stehen in den Tracelinks der Einzelanforderungen (StRS.md/SyRS.md/SwRS.md).
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (primär) |
|
||||
|---|---|---|---|
|
||||
| StRS-024 | SyRS-032 | SwRS-001 | docs/getting-started/general-structure.md; Centron.BL/BaseBL.cs |
|
||||
| StRS-024 | SyRS-032 | SwRS-002 | docs/getting-started/general-structure.md (BL/WS-Logic-Muster) |
|
||||
| StRS-024 | SyRS-032 | SwRS-003 | Centron.BL/Administration/Logins/Auth/Authenticator.cs (Result/MessageCodes) |
|
||||
| StRS-024 | SyRS-051 | SwRS-004 | docs/guides/database/database-conventions.md |
|
||||
| StRS-001 | SyRS-001 | SwRS-005 | docs/reference/receipts/receipts-backend-architecture.md („Critical Save Warning"); Centron.DAO/Mappings/TemporaryEntities |
|
||||
| StRS-001 | SyRS-006 | SwRS-006 | receipts-backend-architecture.md (Versionstabellen); AssetHeadDAO.SaveAssetVersion |
|
||||
| StRS-001 | SyRS-001 | SwRS-007 | Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs; SpecificLogics.cs |
|
||||
| StRS-001 | SyRS-002 | SwRS-008 | Centron.Interfaces/Sales/Receipts/ReceiptState.cs |
|
||||
| StRS-001 | SyRS-003 | SwRS-009 | */[Typ]SpecificLogic.cs (CanBeForwardedInto) |
|
||||
| StRS-001 | SyRS-003 | SwRS-010 | ReceiptBL.cs ValidateReceiptForwarding (Z. 2462) |
|
||||
| StRS-001 | SyRS-005 | SwRS-011 | ReceiptBL.cs UpdateReceiptNumber (Z. 7265) |
|
||||
| StRS-001 | SyRS-007 | SwRS-012 | ReceiptBL.cs CreateLock/RemoveLock (Z. 3160–3175) |
|
||||
| StRS-001 | SyRS-006 | SwRS-013 | ReceiptBL.cs CreateNewVersion (Z. 3068) |
|
||||
| StRS-012 | SyRS-008 | SwRS-014 | ReceiptBL.cs CheckIfCustomerLimitIsReached (Z. 8636) |
|
||||
| StRS-011 | SyRS-009 | SwRS-015 | ReceiptBL.cs CheckArticleMinPrices (Z. 9036) |
|
||||
| StRS-005 | SyRS-010 | SwRS-016 | ReceiptBL.cs UpdatePaymentDueDate (Z. 8189) |
|
||||
| StRS-001 | SyRS-011 | SwRS-017 | ReceiptBL.cs UpdateReceiptStateFromPaymentCondition (Z. 8336) |
|
||||
| StRS-023 | SyRS-012 | SwRS-018 | ReceiptBL.cs UpdateCurrencyFactor (Z. 8359) |
|
||||
| StRS-023 | SyRS-013 | SwRS-019 | Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs |
|
||||
| StRS-001 | SyRS-014 | SwRS-020 | ReceiptItemBL.cs (Z. 4088–4098, Steuersatz-Stichtag) |
|
||||
| StRS-001 | SyRS-015 | SwRS-021 | ReceiptBL.cs SaveReceipt-Pipeline (Z. 3535 ff.) |
|
||||
| StRS-013 | SyRS-029 | SwRS-022 | ReceiptBL.cs UpdateArticlePositions…Right… (Z. 8030) |
|
||||
| StRS-009 | SyRS-004 | SwRS-023 | ReceiptBL.cs CheckExternalInvoiceNumberAlreadyUsed (Z. 4182) |
|
||||
| StRS-001 | SyRS-001 | SwRS-024 | ReceiptItemBL.cs (Positions-Erzeuger, Z. 157–1832) |
|
||||
| StRS-001 | SyRS-001 | SwRS-025 | ReceiptBL.cs EnsureReceiptDirectoryExists (Z. 9765) |
|
||||
| StRS-002 | SyRS-016 | SwRS-026 | Centron.Entities/.../ContractLists/ReceiptContract.cs |
|
||||
| StRS-002 | SyRS-016 | SwRS-027 | AutomaticFacturaWebServiceBL.cs CreateInvoiceToContractComplete (Z. 1699) |
|
||||
| StRS-002 | SyRS-017 | SwRS-028 | AutomaticFacturaBL.Contracts.cs (Zählerlogik) |
|
||||
| StRS-025 | SyRS-018 | SwRS-029 | AutomaticFacturaWebServiceBL.cs CheckRMMArticle (Z. 721) |
|
||||
| StRS-002 | SyRS-019 | SwRS-030 | AutomaticFacturaBL.cs CreateSpecialArticleToContract (Z. 149) |
|
||||
| StRS-005 | SyRS-020 | SwRS-031 | DunningRunBL.cs UpdateInvoice/SaveDunningRun (Z. 248/277) |
|
||||
| StRS-006 | SyRS-021 | SwRS-032 | BookKeepingExportBL.cs (Formate, IsReceiptExported) |
|
||||
| StRS-007 | SyRS-022 | SwRS-033 | InvoiceZugferdBL.cs; docs/reference/zugferd-field-mapping.md |
|
||||
| StRS-005 | SyRS-023 | SwRS-034 | PaymentTransactionBL.cs InvoiceExportDone/Reset… (Z. 233/296) |
|
||||
| StRS-026 | SyRS-025 | SwRS-035 | BasicAuthenticator.cs (SHA1, TODO-Salz-Kommentar) |
|
||||
| StRS-026 | SyRS-026 | SwRS-036 | TwoFactorAuthBL.cs HasToValidateTwoFactor (Z. 82) |
|
||||
| StRS-026 | SyRS-027 | SwRS-037 | TicketBL.cs (Ablauf 30 min, Salt, Refresh) |
|
||||
| StRS-019 | SyRS-028 | SwRS-038 | Authenticator.cs GetTicket; docs/reference/security/licensing-system.md |
|
||||
| StRS-013 | SyRS-029 | SwRS-039 | docs/guides/development/check-userrights.md; HelpdeskBL.cs (Z. 276) |
|
||||
| StRS-026 | SyRS-030 | SwRS-040 | Authenticator.cs ValidateAppUser (Z. 157–218) |
|
||||
| StRS-026 | SyRS-031 | SwRS-041 | AccessTokenBL.cs (SHA-256, Protokolle) |
|
||||
| StRS-024 | SyRS-032 | SwRS-042 | Centron.Host/Services + AspNetCore (Swagger, WCF-Bridge, SignalR) |
|
||||
| StRS-024 | SyRS-033 | SwRS-043 | Centron.Host/AspNetCore/HostedServices (36 Dienste) |
|
||||
| StRS-003 | SyRS-034 | SwRS-044 | Centron.Entities/.../Support/Helpdesk.cs; EscalationBL.cs (hlpdsk_requests) |
|
||||
| StRS-003 | SyRS-035 | SwRS-045 | EscalationBL.cs DoEscalation (Z. 223) |
|
||||
| StRS-004 | SyRS-036/037 | SwRS-046 | HelpdeskTimer.cs; ReceiptBL.cs CreateNewReceiptForHelpdekTimers (Z. 5295) |
|
||||
| StRS-008 | SyRS-038 | SwRS-047 | ArticleStockBL.cs; Article.cs (SecondaryStocks) |
|
||||
| StRS-008 | SyRS-039 | SwRS-048 | ArticleStockBL.cs UpdateArticlePurchasePrice (Z. 74) |
|
||||
| StRS-008 | SyRS-040 | SwRS-049 | ReceiptItemBL.cs (Z. 4002); ReceiptBL.cs (Z. 3106); BarcodeBL.cs |
|
||||
| StRS-008 | SyRS-041 | SwRS-050 | OrderSuggestionListBL.cs (Bedarfs-SQL, Z. 89 ff.) |
|
||||
| StRS-015 | SyRS-042 | SwRS-051 | CentronNexus.Host/appsettings.json; Nexus-Routen |
|
||||
| StRS-017 | SyRS-043 | SwRS-052 | ReceiptCartBL.cs (Z. 228); README.md WebCart |
|
||||
| StRS-016 | SyRS-044 | SwRS-053 | ReceiptBL.cs ChangeWebReceiptState (Z. 5903); WebReceiptState.cs |
|
||||
| StRS-018 | SyRS-045 | SwRS-054 | SupplierEdiBL.*-Partialklassen; EdiDownloadService.cs |
|
||||
| StRS-011 | SyRS-046 | SwRS-055 | ActionPriceBL.cs; docs/reference/receipts/actionprice-system.md |
|
||||
| StRS-021 | SyRS-047 | SwRS-056 | DsgvoBL.cs ConfirmOnlinePdfDocument (Z. 182) |
|
||||
| StRS-014 | SyRS-048 | SwRS-057 | ReceiptLogBL.cs; ChangeTrackingEventListener.cs (ungenutzt) |
|
||||
| StRS-023 | SyRS-049 | SwRS-058 | LocalizedStrings.resx/.en.resx; general-structure.md |
|
||||
| StRS-024 | SyRS-050 | SwRS-059 | WebServiceConfig.cs; c-entron.misc.ConnectionManager |
|
||||
| StRS-024 | SyRS-051 | SwRS-060 | ScriptMethods/Scripts (764 Klassen); create-scripts.md |
|
||||
| StRS-024 | SyRS-052 | SwRS-061 | CentronMailFactory.cs; developer-security.md |
|
||||
| StRS-001 | SyRS-053 | SwRS-062 | ReceiptBL.cs CreateFullReportForReceipt (Z. 3221) |
|
||||
| StRS-022 | SyRS-054 | SwRS-063 | ReceiptProvisionSchemaBL.cs u. a.; UpdateExpiredProvisionSchemasService.cs |
|
||||
| StRS-008 | SyRS-055 | SwRS-064 | ProductionOrderBL.cs; ProductionOrderOverView.razor |
|
||||
| StRS-011 | SyRS-056 | SwRS-065 | ReceiptItemBL.cs UpdateReceiptItemWithArticleInfo (Z. 3958) |
|
||||
| StRS-024 | SyRS-050 | SwRS-066 | global.json; Centron.BL.csproj; version.json; azure/ |
|
||||
|
||||
## Abdeckungsübersicht
|
||||
|
||||
- **StRS-Ebene:** 26 Anforderungen (StRS-001 … StRS-026); alle mit mindestens einer SyRS-Verfeinerung.
|
||||
- **SyRS-Ebene:** 56 Anforderungen (SyRS-001 … SyRS-056); alle mit StRS-Aufwärtslink und mindestens einem SwRS-Abwärtslink.
|
||||
- **SwRS-Ebene:** 66 Anforderungen (SwRS-001 … SwRS-066); alle mit SyRS-Aufwärtslink.
|
||||
- StRS-Anforderungen mit mehreren SyRS-Kindern (z. B. StRS-001, StRS-008, StRS-026) sind in den jeweiligen `Tracelinks`-Feldern vollständig aufgeführt; diese Tabelle listet je SwRS nur den primären Pfad.
|
||||
+208
@@ -0,0 +1,208 @@
|
||||
# Messprotokoll – V1-Fable (solo, `claude-fable-5`, Effort `max`) – Prompt-Version 01, Lauf 23 (Lauf Q)
|
||||
|
||||
> **Neue Messreihe mit zwei geänderten Variablen.** Gegenüber allen 21 Vorläufen wechseln
|
||||
> **gleichzeitig Modell und Effort**: `claude-fable-5` statt Sonnet/Opus, `max` statt `high`.
|
||||
> Ein Unterschied im Ergebnis lässt sich deshalb **nicht eindeutig** einer der beiden Ursachen
|
||||
> zuschreiben. Für eine kausale Trennung fehlt der Zwischenpunkt Fable auf `high`.
|
||||
>
|
||||
> **Parallelbetrieb:** zwei gleichzeitige Läufe (P, Q). **Wanduhrzeit, `duration_ms` und
|
||||
> `duration_api_ms` sind verzerrt.** Tokenverbrauch, Anforderungsanzahl und Denials sind
|
||||
> unverzerrt.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `Versuche/Versuch_01/01_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `1B0DB06B8E0A5B92A5EFBDBEC5A0C554351FC928A16AEF34AAD9EAA0893C02FF`
|
||||
(identisch zu allen bisherigen Läufen)
|
||||
- **Startzeit:** 2026-08-25T21:09:30+02:00
|
||||
- **Endzeit:** 2026-08-25T21:55:21+02:00
|
||||
- **Dauer gesamt:** 00:45:51 (Wanduhr, **parallelbetriebsbedingt verzerrt**) bzw. 00:45:49 (`duration_ms`) — API: 00:44:54
|
||||
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||
- **Codebasis-Commit:** `79c1142f489a32ba6a4a4cb043fd7f8550a9f257` (dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: **ja** (strenge Prüfung: 0 Treffer);
|
||||
Remote entkoppelt: **ja**
|
||||
- **Prompt-Repo-Commit:** `0ec86aed8cb8781054c86cbe0dd9f5eb0f7e5f05`
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Laufverzeichnis-ID:** `v3.6.0-58d2`
|
||||
- **Ablage:** `Iteration 1/claude-fable-5/solo/max/`
|
||||
- **Parallele Läufe:** ja – `fable5_solo_v3.6.0-7adf`
|
||||
- **Skill-Version:** `3.6.0`
|
||||
- **Claude-Code-Version:** 2.1.245
|
||||
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.245-win32-x64\resources\native-binary\claude.exe`
|
||||
- **Agentenmodus:** `solo` (V1) – erzwungen über `--disallowedTools Task Agent Workflow`
|
||||
- **Effort:** **`max`** – explizit per `--effort` gesetzt; Gegenprobe im Transkript: 271
|
||||
Nachrichten, durchgängig `max`. **Erster Block, der vom bisherigen `high` abweicht.**
|
||||
- **Modell:** `claude-fable-5` (vom Versuchsleiter vor dem Lauf gewählt); zusätzlich
|
||||
`claude-haiku-4-5-20251001` für interne Hilfsaufrufe (4.193 Input-/17 Output-Tokens)
|
||||
- **Permission-Mode:** `acceptEdits`
|
||||
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"`; `--disallowedTools` mit 36 Einträgen
|
||||
(22 × `Bash(...)`, 11 × `PowerShell(...)`, 3 × Agentenwerkzeuge)
|
||||
- **Isolationsmechanismus:** eingefrorener Codebasis-Snapshot ohne KI-Konfigurationen,
|
||||
zusätzlich `--safe-mode` und `--strict-mcp-config`
|
||||
- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
|
||||
- **Subagenten:** **0** (durch die Versuchsbedingung ausgeschlossen)
|
||||
- **Verschachtelung:** `spawned` = 0, `spawned_by_subagents` = 0, `max_depth` = 0
|
||||
- **Fast-Mode:** aus
|
||||
|
||||
## Verbrauch
|
||||
|
||||
### Hauptagent (`usage`)
|
||||
| Messgröße | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 292 |
|
||||
| Output-Tokens | 215.446 (davon 39.609 Thinking-Tokens) |
|
||||
| Cache-Write-Tokens | 449.566 |
|
||||
| Cache-Read-Tokens | 30.404.279 |
|
||||
| Agent-Turns | 162 |
|
||||
|
||||
### Gesamtlauf (`modelUsage`)
|
||||
| Messgröße | `claude-fable-5` | `claude-haiku-4-5-20251001` | Summe |
|
||||
|---|---:|---:|---:|
|
||||
| Input-Tokens | 292 | 4.193 | 4.485 |
|
||||
| Output-Tokens | 215.446 | 17 | 215.463 |
|
||||
| Cache-Write-Tokens | 449.566 | 0 | 449.566 |
|
||||
| Cache-Read-Tokens | 30.404.279 | 0 | 30.404.279 |
|
||||
| Tokens gesamt | 31.069.583 | 4.210 | **31.073.793** |
|
||||
|
||||
**Tokens gesamt: 31.073.793** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
|
||||
Ohne Subagenten sind Haupt- und Gesamtwerte für `claude-fable-5` identisch.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** erfolgreich (`is_error: false`, `terminal_reason: "completed"`,
|
||||
`stop_reason: "end_turn"`, Exit-Code 0, `Stderr.log` leer)
|
||||
- **Session-ID:** `8ee7b6a1-a203-4eca-a710-f1bf60405551`
|
||||
- **Permission-Denials:** **0** – —
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = **0** – die Sperre hat gegriffen,
|
||||
der Lauf ist als V1-Messung gültig
|
||||
- **Subagenten-Prompts:** entfällt (Modus `solo`)
|
||||
- **Erzeugte Dateien:** alle 7 geforderten Artefakte in `Ergebnisse\`, **keine Fremddateien**
|
||||
|
||||
| Datei | Größe | Inhalt |
|
||||
|---|---:|---|
|
||||
| `StRS.md` | 42.674 B | 26 Anforderungen |
|
||||
| `SyRS.md` | 87.720 B | 56 Anforderungen |
|
||||
| `SwRS.md` | 97.327 B | 66 Anforderungen |
|
||||
| `Traceability.md` | 7.202 B | konsolidierte Tabelle |
|
||||
| `Hypothesen.md` | 13.808 B | Sammlung der `[HYPOTHESE]`-Aussagen |
|
||||
| `Glossar.md` | 15.807 B | Domänenbegriffe |
|
||||
| `Analysebericht.md` | 13.651 B | Modulabdeckung, Konsistenzcheck, Selbstbewertung |
|
||||
|
||||
Summe: **148 Anforderungen** über drei Ebenen.
|
||||
- **Root unverändert:** ja. `git status --porcelain` vor und nach dem Lauf leer, HEAD `79c1142`.
|
||||
- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
|
||||
|
||||
## 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 | 26 | 17,6 % |
|
||||
| SyRS | 56 | 37,8 % |
|
||||
| SwRS | 66 | 44,6 % |
|
||||
| **Gesamt** | **148** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 78 | 52,7 % |
|
||||
| Sicherheit | 10 | 6,8 % |
|
||||
| Schnittstelle | 9 | 6,1 % |
|
||||
| Daten | 8 | 5,4 % |
|
||||
| Architektur-Constraint | 5 | 3,4 % |
|
||||
| funktional / Schnittstelle | 4 | 2,7 % |
|
||||
| Sicherheit / Daten | 3 | 2,0 % |
|
||||
| funktional / Sicherheit | 2 | 1,4 % |
|
||||
| Schnittstelle / funktional | 2 | 1,4 % |
|
||||
| funktional / nicht-funktional (ISO 25010: Zuverlässigkeit) | 2 | 1,4 % |
|
||||
| (22 weitere) | 25 | 16,9 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 292 |
|
||||
| davon `PRIMÄR` | 226 (77,4 %) |
|
||||
| davon `SEKUNDÄR` | 16 (5,5 %) |
|
||||
| davon `KONTEXT` | 50 (17,1 %) |
|
||||
| Belege je Anforderung (Median) | 2,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 148 (100,0 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
**nicht erhoben** – das Feld `Übernahmewürdigkeit` wurde erst mit der Prompt-Fassung vom 2026-08-26 eingeführt und liegt für diesen Lauf nicht vor. Hinweise auf Workarounds stecken ersatzweise im Feld `Status`.
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 148 | 100,0 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 0 | 0,0 % |
|
||||
| als Workaround vermerkt | 8 | 5,4 % |
|
||||
| Konsolidierungskandidaten | 15 | 10,1 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 0 | 0,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** (42 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | *nicht erhoben* (Feld erst ab Prompt-Fassung 2026-08-26) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 148 von 148 mit Tracelinks (100,0 %) |
|
||||
|
||||
## Fable-Block (P, Q)
|
||||
|
||||
| Messgröße | **Lauf P** | **Lauf Q** |
|
||||
|---|---:|---:|
|
||||
| Anforderungen | 207 | 148 |
|
||||
| — StRS / SyRS / SwRS | 35/84/88 | 26/56/66 |
|
||||
| Tokens gesamt | 24.225.555 | 31.073.793 |
|
||||
| Thinking-Tokens | 35.220 | 39.609 |
|
||||
| Agent-Turns | 152 | 162 |
|
||||
| Denials / Subagenten | 1 / 0 | 0 / 0 |
|
||||
|
||||
## Vergleich der drei Solo-Reihen
|
||||
|
||||
| | **Fable, `max`** (2 Läufe) | Opus, `high` (5 Läufe) | Sonnet, `high` (5 Läufe) |
|
||||
|---|---|---|---|
|
||||
| Anforderungen | 148 – 207 | 71 – 182 (Median 114) | 42 – 82 (Median 67) |
|
||||
| Tokens gesamt | 24,22 – 31,07 Mio. | 13,56 – 24,86 Mio. (Median 22,76) | 4,36 – 12,60 Mio. (Median 5,05) |
|
||||
| Thinking-Tokens | 35.220 – 39.609 | 11.239 – 24.179 | 10.470 – 22.957 |
|
||||
| Agent-Turns | 152 – 162 | 116 – 195 | 67 – 107 |
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
1. **Der höchste Solo-Verbrauch der gesamten Reihe – vom sparsamsten Modell.** Mit 24,22 und
|
||||
31,07 Mio. Tokens übertrifft der Fable-Block sogar den teuersten Opus-Lauf (24,86 Mio.).
|
||||
Da Fable als das schnellere und günstigere Modell gilt, ist der plausibelste Treiber der auf
|
||||
`max` gesetzte Effort – bestätigen lässt sich das aus diesen Daten jedoch **nicht**, weil
|
||||
Modell und Effort gleichzeitig gewechselt wurden.
|
||||
|
||||
2. **Deutlichster Hinweis auf den Effort: die Thinking-Tokens.** Mit 35.220 und 39.609 liegen
|
||||
sie über allen 21 Vorläufen – der bisherige Höchstwert lag bei 24.179 (Opus, `high`), der
|
||||
Sonnet-Solo-Median bei rund 12.000. Thinking-Tokens sind die unmittelbarste Wirkung der
|
||||
Effort-Stufe, und sie steigen hier um Faktor 1,5 bis 3 gegenüber `high`. Das stützt die
|
||||
Vermutung aus Anmerkung 1, ersetzt aber den fehlenden Kontrollpunkt nicht.
|
||||
|
||||
3. **Hohe Ausbeute bei den Anforderungen.** 148 und 207 Anforderungen liegen über dem
|
||||
Opus-Median (114) und weit über dem Sonnet-Median (67) – bei einem Modell, das von den dreien
|
||||
das schwächste ist. Die Anforderungsanzahl misst allerdings nur Menge, nicht Belegqualität;
|
||||
eine inhaltliche Bewertung steht aus.
|
||||
|
||||
4. **Konsistent über beide Läufe.** Anforderungen 148 gegenüber 207 (Faktor 1,4), Tokens 24,22
|
||||
gegenüber 31,07 Mio. (Faktor 1,3), Turns 152 gegenüber 162. Bei nur zwei Messpunkten ist das
|
||||
keine belastbare Streuungsaussage, fügt sich aber in das Bild der übrigen Solo-Reihen ein,
|
||||
die alle unter Faktor 3 bleiben.
|
||||
|
||||
5. **Was zur kausalen Trennung fehlt:** ein Fable-Block auf `high`. Er würde zeigen, ob der
|
||||
Sprung im Verbrauch vom Modell oder vom Effort kommt. Alternativ ein Sonnet- oder Opus-Block
|
||||
auf `max` – dann ließe sich der Effort-Effekt bei bekanntem Modell isolieren.
|
||||
|
||||
6. **Manuelle Eingriffe während des Laufs:** keine.
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"is_error":false,"duration_api_ms":2693800,"num_turns":162,"stop_reason":"end_turn","session_id":"8ee7b6a1-a203-4eca-a710-f1bf60405551","total_cost_usd":50.17509700000001,"usage":{"input_tokens":292,"cache_creation_input_tokens":449566,"cache_read_input_tokens":30404279,"output_tokens":215446,"output_tokens_details":{"thinking_tokens":39609},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":449566,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1863,"cache_read_input_tokens":469657,"cache_creation_input_tokens":849,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":849},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":4193,"outputTokens":17,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.004278,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty"},"claude-fable-5":{"inputTokens":292,"outputTokens":215446,"cacheReadInputTokens":30404279,"cacheCreationInputTokens":449566,"webSearchRequests":0,"costUSD":50.17081900000001,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-fable-5","provider":"firstParty"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"Der Lauf ist abgeschlossen. Alle sieben Ergebnisdateien liegen im vorgegebenen Verzeichnis `…\\01_Lauf_2026-08-25_210904_fable5_solo_v3.6.0-58d2\\Ergebnisse\\`, die analysierte Codebasis blieb unverändert (git status leer).\n\n**Ergebnis in Zahlen:**\n\n| Artefakt | Inhalt |\n|---|---|\n| StRS.md | 26 Stakeholder-Anforderungen (Geschäftsziele, 11 Stakeholder-Rollen) |\n| SyRS.md | 56 System-Anforderungen (Belegwesen, Abrechnung, Sicherheit, Schnittstellen, Betrieb; NFRs nach ISO 25010 zugeordnet) |\n| SwRS.md | 66 Software-Anforderungen (Komponenten, Datenmodelle, Algorithmen mit Zeilenangaben) |\n| Traceability.md | Durchgängige Matrix StRS→SyRS→SwRS, eine Zeile je SwRS mit Artefaktbeleg |\n| Hypothesen.md | 18 explizit gekennzeichnete Hypothesen mit offener Frage und Klärungsweg |\n| Glossar.md | ~70 Domänenbegriffe mit Artefaktquellen |\n| Analysebericht.md | Vorgehen, Modulabdeckung, Konsistenzcheck, Selbstbewertung |\n\n**Wesentliche inhaltliche Befunde:** Die Kern-Wertschöpfung (Belegkette Angebot→Rechnung mit vollständiger Speicher-Validierungspipeline, Vertrags-/Zähler-/RMM-Abrechnung, Mahnwesen, SEPA in 5 PAIN-Formaten, DATEV-Export, Preisfindungskaskade, Rechte-/Lizenz-/2FA-Modell) ist durchgängig mit PRIMÄR-Belegen spezifiziert. Acht Anforderungen tragen den Status `belegt; Workaround` als priorisierte Migrationspunkte — darunter ungesalzene SHA-1-Passwörter (mit TODO-Kommentar im Code), der doppelte Persistenzpfad über TemporaryEntities in deutsche Legacy-Tabellen, die dokumentierte Client-Trust-Lücke bei Preisrechten für Neubelege und die nie aktivierte Feld-Audit-Infrastruktur.\n\n**Konsistenzcheck (automatisiert, dokumentiert im Analysebericht):** keine ID-Duplikate, keine Anforderung ohne Beleg, keine toten Tracelinks, alle 13 Formatfelder in allen 148 Anforderungen vollständig, alle Sicherheits-/Abrechnungsanforderungen mit PRIMÄR-Beleg. Fünf Tracelink-Asymmetrien wurden während der Erstellung gefunden und vor dem Finalcheck korrigiert.\n\n**Grenzen (im Bericht offengelegt):** Randmodule wie TAPI, Exchange-Sync, MailScanner, RMA-Details und die Statistik-Kennzahlformeln sind nur strukturell bzw. gar nicht erfasst und als Kandidaten für Folge-Iterationen benannt; risikopriorisiert sind die Klärungen zu Kasse/TSE, GoBD und der Preisrechte-Lücke (H-01, H-02, H-06).\n\nFalls du die Spezifikation zusätzlich als teilbare Webseite (Artifact) haben möchtest, sag kurz Bescheid — ich habe darauf verzichtet, um die Baseline „nur Dateien im Ausgabeverzeichnis\" nicht zu verfälschen.","ttft_ms":14383,"ttft_stream_ms":1920,"time_to_request_ms":48,"type":"result","duration_ms":2749461,"uuid":"f696c90a-3905-44fb-8c87-9715bc7b3905","queued_turn_count":0}
|
||||
+2662
File diff suppressed because it is too large
Load Diff
+66
@@ -0,0 +1,66 @@
|
||||
## 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 | 26 | 17,6 % |
|
||||
| SyRS | 56 | 37,8 % |
|
||||
| SwRS | 66 | 44,6 % |
|
||||
| **Gesamt** | **148** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 78 | 52,7 % |
|
||||
| Sicherheit | 10 | 6,8 % |
|
||||
| Schnittstelle | 9 | 6,1 % |
|
||||
| Daten | 8 | 5,4 % |
|
||||
| Architektur-Constraint | 5 | 3,4 % |
|
||||
| funktional / Schnittstelle | 4 | 2,7 % |
|
||||
| Sicherheit / Daten | 3 | 2,0 % |
|
||||
| funktional / Sicherheit | 2 | 1,4 % |
|
||||
| Schnittstelle / funktional | 2 | 1,4 % |
|
||||
| funktional / nicht-funktional (ISO 25010: Zuverlässigkeit) | 2 | 1,4 % |
|
||||
| (22 weitere) | 25 | 16,9 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 292 |
|
||||
| davon `PRIMÄR` | 226 (77,4 %) |
|
||||
| davon `SEKUNDÄR` | 16 (5,5 %) |
|
||||
| davon `KONTEXT` | 50 (17,1 %) |
|
||||
| Belege je Anforderung (Median) | 2,0 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 148 (100,0 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
**nicht erhoben** – das Feld `Übernahmewürdigkeit` wurde erst mit der Prompt-Fassung vom 2026-08-26 eingeführt und liegt für diesen Lauf nicht vor. Hinweise auf Workarounds stecken ersatzweise im Feld `Status`.
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 148 | 100,0 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 0 | 0,0 % |
|
||||
| als Workaround vermerkt | 8 | 5,4 % |
|
||||
| Konsolidierungskandidaten | 15 | 10,1 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 0 | 0,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** (42 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | *nicht erhoben* (Feld erst ab Prompt-Fassung 2026-08-26) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 148 von 148 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+132
@@ -0,0 +1,132 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 01
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 01 (Initial-Prompt, zu Versuchsbeginn neu formuliert)
|
||||
- **Werkzeugkonfiguration:** Claude Code, keine Agentendateien, keine MCP-Server
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Modell:** Claude (Claude Code)
|
||||
- **Zeitstempel:** 2026-08-25
|
||||
- **Änderungsgrund:** Initial-Prompt für V1 Baseline (kein Vorgänger). Vor Erstlauf überarbeitet: Abgleich mit Kap. 4 (RRE-Methodenkette, Evaluationsrahmen) und Kap. 2 (Prozesskontrollen); mit der Vorfassung fand kein Lauf statt.
|
||||
|
||||
---
|
||||
|
||||
## 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). Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung; nutze nur, was als Datei lesbar ist.
|
||||
|
||||
### 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. Priorisiere die Analysetiefe selbstständig, dokumentiere aber im `Analysebericht.md`, welche Bereiche wie tief analysiert wurden.
|
||||
|
||||
### 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):
|
||||
|
||||
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). Anforderungen ohne Beleg sind unzulässig. Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt.
|
||||
- **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.
|
||||
- **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.
|
||||
- **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.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
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>>
|
||||
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).
|
||||
- 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.
|
||||
|
||||
### 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 (Modul-/Komponentenübersicht, abgedeckte Bereiche, bekannte Lücken)
|
||||
```
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs benannt. 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 nicht vorhandener Tools.** Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist die Aussage als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Wenn eine Implementierung erkennbar ein historischer Workaround oder Sonderfall ist, vermerke das im Feld `Status` (`belegt; Workaround`), damit es in der späteren Validierung priorisiert geprüft werden kann.
|
||||
- **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
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Welche Module wurden vollständig analysiert, welche nur stichprobenhaft, welche gar nicht?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`c:\DEV\MasterArbeit\Versuche\Versuch_01\01_Lauf_2026-08-25_210904_fable5_solo_v3.6.0-58d2\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-25T21:55:21.3589944+02:00
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-25T21:09:30.2840156+02:00
|
||||
Reference in New Issue
Block a user