Lokaler LM-Studio-Adapter fuer Gemma und Qwen (Skill 10.1.0)

Der TensorX-Wrapper wird providerneutral: opencode-tensorx-adapter.py heisst
jetzt opencode-adapter.py und waehlt ueber --provider {tensorx,lmstudio}
Gateway und Modellvorlage. Der TensorX-Pfad bleibt unveraendert; die vier
bestehenden Regressionstests laufen durch.

Neu fuer den lokalen Betrieb:
- opencode-lmstudio.json fuer google/gemma-4-e4b und qwen/qwen3.8-27b
- Preflight ueber /api/v0/models: Servererreichbarkeit, Modellverfuegbarkeit,
  tool_use-Faehigkeit, geladenes Kontextfenster (--min-context, Standard 32768)
  und genau eine geladene Instanz; --lmstudio-autoload stellt das selbst her
- local_runtime in RawResult.json (Quantisierung, Architektur, Runtime,
  lms-Version, Instanzbezeichner, Kontextfenster) fuer Kap. 4.3
- effort_applied, da der lokale Endpunkt keinen Thinking-Level annimmt

Drei Befunde aus der Inbetriebnahme, alle im Adapter abgefangen: LM Studio
laedt standardmaessig nur 8192 Kontexttokens; ein erneutes lms load erzeugt
eine zweite Instanz und macht das Routing mehrdeutig; Effort ist lokal
wirkungslos. Dazu zwei Korrekturen am gemeinsamen Pfad (Abbruchgrund nur
einmal in errors, saubere lms-Versionskennung).

Enthaelt ausserdem die bislang nicht committeten Laeufe der Iterationen 8
und 9 sowie Versuch 2 (Iterationen 1 bis 3). Der laufende Lauf unter
Iteration 10 ist bewusst nicht enthalten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Christoph Schwörer
2026-08-31 20:19:33 +02:00
co-authored by Claude Opus 5
parent b369e6115e
commit 611fd0a80c
132 changed files with 83432 additions and 204 deletions
@@ -0,0 +1,189 @@
# Glossar
c-entron ERP-Suite — Begriffsbestimmungen zur Spezifikation nach ISO/IEC/IEEE 29148:2018.
Das Glossar bestimmt die Begriffe, die in `StRS.md`, `SyRS.md` und `SwRS.md` verwendet werden. Fachbegriffe sind so bestimmt, wie die Codebasis sie tatsächlich verwendet — nicht wie sie in einem Lehrbuch stehen; wo der Sprachgebrauch der Codebasis vom üblichen abweicht, ist das vermerkt. Technische Bezeichner (Klassen, Methoden, Spalten) stehen in ihrer Originalsprache.
Die Angabe in Klammern nennt den technischen Bezeichner oder die Fundstelle, an der der Begriff im Bestand verankert ist. Verweise der Form `StRS-004` benennen die Anforderung, die den Begriff tragend verwendet.
---
## 1 Aufbau der Spezifikation
**StRS — Stakeholder Requirements Specification.** Ebene 1 nach ISO/IEC/IEEE 29148. Beschreibt den fachlichen Bedarf einer Rolle im Unternehmen, ohne Aussage darüber, wie das System ihn erfüllt. Enthält keine Klassen-, Methoden- oder Spaltennamen im Feld `Aussage`; die Belege sind gleichwohl technisch.
**SyRS — System Requirements Specification.** Ebene 2. Beschreibt beobachtbares Verhalten an der Systemgrenze: Schnittstellen, Zustandsmodelle, Prüfungen, Leistungs- und Sicherheitseigenschaften. Der Bezugspunkt ist, was ein Beobachter von außen feststellen kann.
**SwRS — Software Requirements Specification.** Ebene 3. Beschreibt Komponenten, Datenmodelle und softwareinterne Regeln: konkrete Formeln, Bedingungen, Constraints, Schreibpfade. Jeder Block trägt den Modulmarker des Inventars (`[BE-17]`, `[UI-95]`, `[SV-49]`, `[OP-15]`).
**Beleg (Evidence) und Belegklassifikation.** `PRIMÄR` bezeichnet eine im Code durchgesetzte Regel oder einen Datenbank-Constraint — die Stelle, die das beschriebene Verhalten erzwingt. `SEKUNDÄR` bezeichnet UI-Beschriftungen, Fehlermeldungen, Berichtslayouts, Zuordnungstabellen und Konfigurationsschalter. `KONTEXT` bezeichnet Kommentare, Commit-Nachrichten und Ticketverweise. Nicht zu verwechseln mit dem kaufmännischen *Beleg* (siehe dort).
**Durchsetzende Stelle.** Die Datei, Klasse und Methode samt der konkreten Prüfung, Bedingung oder Zuweisung, die eine Regel wirksam macht. Ein bloßer Dateiverweis ist keine durchsetzende Stelle.
**Fakt gegenüber Aussage.** `Fakt` gibt die belegte technische Beobachtung wieder (Statusübergang, Constraint, Prüfung). `Aussage` gibt die fachliche Auslegung als Soll-Satz wieder. Beide Felder sind bewusst getrennt.
**Status gegenüber Übernahmewürdigkeit.** `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`). `Übernahmewürdigkeit` beschreibt die fachliche Zukunft bei einer Neuimplementierung (`übernehmen`, `Workaround`, `Sonderfall`, `veraltet`). Beide Angaben sind voneinander unabhängig: eine gut belegte Regel kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
**Konsolidierungskandidat.** Zwei oder mehr getrennte Implementierungen desselben fachlichen Gegenstands — etwa zwei Datenhaltungen für dasselbe Geschäftsobjekt. Zwei Anforderungen, die dieselbe Sache auf verschiedenen Ebenen beschreiben, sind *kein* Konsolidierungsfall; dafür bestehen Tracelinks.
---
## 2 Kaufmännische Grundbegriffe
**Beleg.** Kaufmännisches Dokument eines Geschäftsvorfalls mit Kopf- und Positionsdaten. Der Bestand kennt sieben Kundenbelegarten (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag) und die entsprechenden Lieferantenbelegarten. Technisch als `RechKopf`/`RechPos` und Ableitungen geführt; die Belegart als `CentronObjectKindNumeric`. Siehe StRS-006, SyRS-001.
**Belegart.** Fachliche Gattung eines Belegs. Jede Belegart trägt eine eigene Strategieklasse (`…SpecificLogic`), die ihre Regeln festlegt: zulässige Weiterverarbeitung, Teilnahme an der Limitrechnung, Nummernkreis, Änderbarkeit von Mengen. Siehe SwRS-002.
**Belegkette.** Die Folge zulässiger Übergänge von einer Belegart in die nächste — Angebot in Auftrag, Auftrag in Lieferschein, Lieferschein in Rechnung, Rechnung in Gutschrift. Abholschein und Gutschrift sind Endpunkte. Das Mischen von Kunden- und Lieferantenbelegen in einem Vorgang ist verboten. Siehe StRS-006, SyRS-002, SyRS-004.
**Weiterverarbeitung.** Das Erzeugen eines Folgebelegs aus einem oder mehreren Ursprungsbelegen unter Übernahme der Positionen und der Kopfdaten. Bei der Sammelweiterverarbeitung stammen die Kopfdaten aus dem ersten Ursprungsbeleg. Siehe SwRS-010.
**Belegversion.** Eine neue Fassung desselben Belegs. Der Bestand löscht Belege nicht, sondern versioniert sie; das Storno erzeugt eine eigene Version. Siehe SyRS-006.
**Nummernkreis** (`Nummernkreis`, `NumberGroupBL`). Ein je Belegart und optional je Filiale geführter fortlaufender Zähler, aus dem die Belegnummer vergeben wird. Die Nummer wird erst beim verbindlichen Speichern vergeben, nicht bei einer Vorschau. Die gepflegten Bereichsgrenzen `BereichVon`/`BereichBis` werden bei der Ermittlung nicht ausgewertet. Siehe StRS-007, SwRS-004.
**Festschreibung** (`IsFixed`). Kennzeichen an einer Rechnung, das sie gegen inhaltliche Änderung sperrt. Wird in eigener Transaktion gesetzt und protokolliert; eine festgeschriebene Rechnung kann nicht erneut festgeschrieben werden. Die Sperrwirkung ist im Bestand nur im Windows-Client durchgesetzt. Siehe StRS-009, SyRS-011.
**Storno.** Aufhebung einer Rechnung durch Erzeugung einer neuen Belegversion mit Menge 0 auf allen Artikel- und Rabattpositionen und Belegstatus „storniert". Kein Löschen. Unzulässig unter anderem, wenn die Rechnung bereits an die Buchhaltung exportiert wurde. Siehe StRS-009, SwRS-012.
**Anzahlungsrechnung.** Eigenständige Rechnung mit Auftragsbezug über genau eine Position mit dem konfigurierten Anzahlungsartikel. In der Schlussrechnung werden die geleisteten Anzahlungen als zusätzliche Positionen mit negiertem Basispreis abgezogen — eine Positionsnegation, keine Zahlungsverbuchung. Siehe StRS-010, SwRS-017.
**Kreditlimit.** Der für einen Kunden vereinbarte Höchstbetrag ausstehender Forderungen. Bei Überschreitung erfolgt kein Abbruch, sondern eine überstimmbare Rückfrage; über rückfragefreie Aufrufpfade entfällt die Prüfung. Angebot, Abholschein, Gutschrift und Vertrag nehmen an der Limitrechnung nicht teil. Siehe StRS-004, SyRS-013.
**Mahnstufe.** Der erreichte Grad des Mahnverfahrens zu einer Rechnung: keine, Stufe 1, Stufe 2, Stufe 3. Ein Mahnlauf erhöht sie um genau eine Stufe; Stufe 3 ist die Obergrenze. Siehe StRS-016, SyRS-022.
**Mahnstopp** (`MahnStop`). Belegbezogenes Kennzeichen, das eine Rechnung vom Mahnverfahren ausnimmt. Nur für Rechnungen setzbar.
**Sperrstufe / Belegsperre.** Die je Belegart am Kundenstamm gepflegte Mahnstufe, ab der für diesen Kunden keine neuen Belege dieser Art mehr angelegt werden dürfen. Lieferantenbelege sind strukturell ausgenommen. Siehe StRS-003, SyRS-014.
**Offener Posten (OP, OPOS).** Eine noch nicht ausgeglichene Forderung. Der offene Mahnbetrag ergibt sich als Bruttobetrag abzüglich gezahltem Betrag und abzüglich Gutschriftbetrag. Siehe SwRS-018.
**Skonto.** Preisnachlass bei Zahlung innerhalb einer vereinbarten Frist. Im Bestand ist keine serverseitige Ermittlungsstelle auffindbar; die einzige belegte Anwendung liegt im Windows-Client und greift nur, wenn noch nichts bezahlt wurde. Als Hypothese geführt: StRS-018, SyRS-027.
**SEPA-Mandat.** Die vom Kunden erteilte Einzugsermächtigung. Durchläuft die Zustände erstellt, versendet, angenommen, abgelehnt und „Link abgelaufen". Voraussetzung des Lastschrifteinzugs. Siehe StRS-019.
**Kassenbuch** (`Kassenbuch`). Die je Filiale geführte Aufzeichnung der Barbewegungen. Buchungen aus Belegen entstehen nur bei kassenwirksamer Zahlungsbedingung und werden je Steuersatz gruppiert. Ein Eintrag mit gesetztem Abschlussdatum ist unveränderlich. Siehe StRS-015, SwRS-043.
**Provisionsschema.** Die Regelmenge, aus der die Vertriebsprovision eines Belegs ermittelt wird. Wird dreistufig aufgelöst: Zuordnung Kunde und Filiale, Schema am Kundenstamm, globales Schema. Siehe StRS-014, SwRS-007.
**Reverse Charge.** Umkehr der Steuerschuldnerschaft auf den Leistungsempfänger. Für die Bagatellgrenze zählt nur die Nettosumme der reverse-charge-pflichtigen Positionen der Positionsarten Default und Cargo. Siehe SwRS-200.
**Einstandspreis.** Der fortgeschriebene Beschaffungspreis eines Artikels, Grundlage der Ertragsrechnung. Siehe StRS-024, SwRS-035.
---
## 3 Preis- und Konditionsbegriffe
**Preisliste.** Eine von vier am Artikel geführten Verkaufspreisstufen (VK1 bis VK4). Welche gilt, entscheidet die am Kunden hinterlegte Preisliste; jeder unbekannte Wert fällt auf VK1 zurück. Siehe SwRS-005.
**Sonderpreis.** Ein für einen bestimmten Kunden vereinbarter Preis, wirksam nur im Gültigkeitszeitraum. Greift dreistufig: artikelgenau, dann Warengruppe mit Untergruppe, dann Warengruppe. Verdrängt die Mengenstaffel vollständig.
**Staffelpreis (Mengenstaffel).** Ein mengenabhängiger Preis. Wird nur herangezogen, wenn kein Kunden-Sonderpreis besteht, eine Menge übergeben wurde und der Vertrag Staffelpreise zulässt.
**Sondervereinbarung / Projektpreis.** Eine befristete, zustandsgebundene Konditionsvereinbarung. Die kundenbezogene Vereinbarung geht der belegartweiten globalen Vereinbarung vor. Ein Projektpreis ist zusätzlich an Kundenzugehörigkeit, Filialfreigabe und Projektlaufzeit gebunden — alle drei müssen gleichzeitig erfüllt sein. Siehe SwRS-188.
**Preisfindungskaskade.** Die feste Rangfolge, in der der Basispreis einer Position ermittelt wird: Vertrags-Sonderpreis, Kunden-Sonderpreis, Staffelpreis, Standard-Verkaufspreis. Ein Aktionspreis ist in der Kette nicht enthalten. Siehe StRS-005, SyRS-038, SwRS-005.
**Kundenrabatt.** Ein belegweiter prozentualer Nachlass, der als eigene negative Position mit Menge 1 eingesetzt wird. Auf zwei Nachkommastellen kaufmännisch von null weg gerundet. Siehe SwRS-200.
---
## 4 Vertrags-, Service- und Anlagenbegriffe
**Vertrag.** Eine wiederkehrend abzurechnende Vereinbarung mit Abrechnungsintervall (täglich, monatlich, quartalsweise, jährlich), Berechnungsart (automatisch, bedarfsabhängig, manuell — kombinierbar) und Abrechnungszeitpunkt (vor- oder nachschüssig). Siehe StRS-011, SyRS-020.
**Kontingent.** Die vertraglich vereinbarte Leistungsmenge eines Abrechnungszeitraums. Das gebuchte Kontingent ergibt sich aus Kontingentwert mal Intervallanzahl; Intervallbeginne sind kalenderfest. Eine prozentuale oder absolute Schwelle löst Abrechnungsbedarf aus. Siehe SyRS-021, SwRS-023.
**Automatikverlängerung** (`AutomatedProlongation`). Kennzeichen, dass sich ein Vertrag ohne Zutun verlängert. Ein solcher Vertrag läuft nicht ab und erzeugt daher keine Ablauf-Wiedervorlage. Siehe StRS-012.
**Stammblatt** (`GeraeteKopf`/`GeraetePos`, Sicht `MasterDataList`). Die Geräteakte einer beim Kunden betriebenen technischen Anlage: genau ein Hauptgerät mit Positionen, Kunde, Anschrift, Seriennummer und Vertragsbezug; genau eine Hauptposition mit Menge 1. Nicht deaktivierbar, solange einer Position eines aktiven Vertrags zugeordnet. Siehe StRS-013, SwRS-026.
**Zählerstand / Klick.** Der von einer technischen Anlage gemeldete Nutzungszähler, Grundlage der nutzungsabhängigen Abrechnung. Ein importierter Stand kleiner als der gespeicherte wird abgewiesen; der Vorwert wandert in die Historie. Siehe SwRS-027.
**Asset / Anlage.** Fachlich dasselbe Geschäftsobjekt, im Bestand aber in drei getrennten Datenhaltungen geführt: als Belegposition beim Kunden, als Stammblatt und als überwachtes Gerät (`AssetManagementDevices`). Die Trennung ist nirgends durchgesetzt; das naheliegende Kennzeichen `ClickGeraet` ist gemappt, wird aber nicht ausgewertet. Der wichtigste Konsolidierungskandidat des Bestands. Siehe StRS-013.
**Ticket / Helpdesk.** Ein Servicevorgang mit datengetriebenem Statusmodell und genau einem Abschlussstatus. Siehe StRS-026, SyRS-033.
**Eskalation.** Die dreistufige Fristüberwachung eines Tickets, gerechnet in Arbeitsstunden. Siehe SwRS-030.
**RMA.** Reklamations- und Rücksendevorgang, je Ticket genau einmal anlegbar, mit zwei getrennten Zustandsachsen je Position. Siehe StRS-028, SyRS-035, SwRS-134.
**Massenupdate.** Eine Vorlage, die eine gleichartige Änderung auf viele Datensätze anwendet. Positionsweise und idempotent: bereits erfolgreich verarbeitete Positionen werden bei einem Wiederholungslauf übersprungen. Siehe SwRS-186.
---
## 5 Organisations- und Berechtigungsbegriffe
**Mandant.** Eine rechtlich eigenständige Einheit innerhalb einer Installation. Daten, Nummernkreise und Auswertungen sind zu trennen. Siehe SyRS-069.
**Filiale** (`BranchI3D`). Eine organisatorische Untereinheit eines Mandanten. Wirkt auf Nummernkreise, Kassenbuch, Statistiksichtbarkeit und Provisionsschema-Auflösung. Siehe SyRS-070.
**Vertriebsgebiet.** Regionale Zuständigkeitszuordnung eines Mitarbeiters. Ein Mitarbeiter ohne jede Zuordnung gilt als für *alle* Gebiete zuständig — eine implizite Semantik, die in den Daten nicht gekennzeichnet ist. Siehe SwRS-195.
**Anmeldetyp.** Das Merkmal, das Mitarbeiter-, Kunden- und Add-In-Zugang unterscheidet. Trägt im Bestand die Trennung von Mitarbeiter- und Kundenzugang. Siehe StRS-034, SyRS-060.
**Rechtegruppe.** Der einzige vorgesehene Weg der Berechtigungsvergabe; Einzelrechte werden über die Gruppenmitgliedschaft aufgelöst. Siehe SyRS-055, SwRS-047.
**Einschränkendes Recht.** Ein Recht, dessen Besitz nicht erweitert, sondern begrenzt — etwa die Beschränkung der Provisionsanzeige auf die eigenen Provisionen. Eigene Kategorie im Rechtemodell. Siehe SyRS-056.
**Portalkonto / Web-Recht** (`WebRights`, `WebAccountsRights`). Das vom Mitarbeiter-Rechtemodell getrennte Berechtigungsmodell der Kunden- und Partnerzugänge. Zweites, nicht deckungsgleiches Modell neben dem Rechtebaum. Siehe SyRS-057.
**Fail-closed / fail-open.** Verhalten einer Prüfung, wenn die Entscheidungsgrundlage fehlt. *Fail-closed* verweigert im Zweifel (Zielzustand), *fail-open* gewährt im Zweifel. Der Bestand enthält beides nebeneinander, teils innerhalb derselben Komponente. Siehe SyRS-077, SyRS-078, SwRS-197.
**Lizenz.** Die vertraglich freigeschaltete Funktions- und Benutzermenge einer Installation, hardwaregebunden geprüft. Siehe SyRS-071, SyRS-072.
---
## 6 Technische Begriffe der Codebasis
**I3D.** Der durchgängig verwendete technische Primärschlüssel der Datensätze; Fremdschlüsselspalten tragen das Suffix `…I3D`. Kein fachlicher Identifikator — die fachliche Identität ist etwa die Kundennummer oder die Belegnummer.
**BL — Business Logic** (`Centron.BL`). Die serverseitige Geschäftslogikschicht. Regeln, die hier durchgesetzt werden, gelten für alle Zugangswege; Regeln nur im Windows-Client gelten nur dort.
**DAO / Mapping** (`Centron.DAO`). Die Persistenzschicht auf Basis von NHibernate und Fluent-NHibernate; bildet Entitäten auf Tabellen und Sichten ab.
**DTO.** Datentransferobjekt der Außenschnittstellen. Der Bestand kennt Fälle, in denen ein DTO Geheimnisse im Klartext an den Client zurückgibt. Siehe SwRS-400.
**SpecificLogic.** Die je Belegart implementierte Strategieklasse, die belegartabhängige Regeln festlegt (Weiterverarbeitungsziele, Mengenänderbarkeit, Limitteilnahme, Nummernkreis). Siehe SwRS-002.
**WCF-Brücke.** Der Weiterbetrieb der Legacy-WCF-Schnittstelle über ASP.NET Core. Standardverhalten fail-open: geschützt nur dort, wo `[Authenticate]` ausdrücklich gesetzt ist. Siehe SyRS-078.
**REST v1.** Die neuere HTTP-Schnittstelle des Web Service mit globaler Autorisierungsvorgabe (fail-closed). Siehe SyRS-077, SwRS-226.
**Nexus.** Die Blazor-basierte Weboberfläche der Suite, betrieben als Windows-Dienst oder Containerimage. Enthält Mitarbeiter- und Kundenbereich; die Trennung erfolgt über getrennte Lauschports und den Anmeldetyp. Siehe SyRS-085.
**ServiceBoard.** Der Arbeitsbereich des Servicebetriebs innerhalb von Nexus. Vier registrierte Routen sind Platzhalter ohne Funktion, darunter der Kennwortmanager.
**WebCart.** Der Web-Warenkorb mit eigener Freigabekette als Zustandsautomat. Siehe SyRS-019, SwRS-317.
**Zugriffstoken / Sitzungsticket.** Die beiden Ausweismittel der Zugangskanäle. Sitzungstickets tragen eine anwendungsabhängige Ablauffrist, Zugriffstoken einen erzwungenen Ablauf und einen begrenzten Geltungsbereich. Siehe SyRS-050, SyRS-051.
**Anonymer Token-Zugang.** Ein ohne Anmeldung nutzbarer, tokengebundener Außenzugang für Angebote, Dokumente und Webformulare. Siehe SyRS-063, SyRS-087.
**Zusatzfeld (Custom Property).** Ein je Objektart frei definierbares Feld mit Sichtbarkeits-, Versiegelungs- und Pflichtkennzeichen. Ein leeres Pflicht-Zusatzfeld sperrt den Speichern-Befehl. Siehe SwRS-194.
**Positionsart.** Die Rolle einer Belegposition in der Summenbildung: Default und Cargo zählen, informative, alternative und optionale Positionen sowie aufgeklappte Stücklistenköpfe zählen nicht. Siehe SwRS-199.
**Rundungsdifferenz-Position.** Eine automatisch eingefügte Ausgleichsposition bei Stücklistenköpfen mit mehr als zwei Nachkommastellen im Einzelpreis. Idempotent berechnet. Siehe SwRS-200.
---
## 7 Angebundene Fremdsysteme und Formate
**finAPI.** Bankdatendienst für den Abruf von Kontoumsätzen; Test- und Produktivbetrieb umschaltbar, lizenzgebunden. Siehe SyRS-091, SwRS-266.
**GLS, Shipcloud.** Die beiden parallel betriebenen Versanddienstleisteranbindungen mit unterschiedlichen Mengengrenzen. Siehe SyRS-093.
**ITscope, Icecat, EGIS, COP.** Externe Produkt-, Distributions- und Lieferantendatenquellen, im Bestand als austauschbare Suchanbieter geführt. Siehe SyRS-094.
**docuFORM.** Managed-Print-Anbindung für den unbeaufsichtigten Abruf von Gerätezählerständen. Im Bestand das positive Gegenbeispiel der Geheimnisverwaltung: PKCE, verschlüsseltes Geheimnis und Refresh-Token, an ein Recht gebunden. Siehe SyRS-096, SwRS-275, SwRS-399.
**EDI.** Der elektronische Austausch von Geschäftsnachrichten mit Lieferanten. Siehe SyRS-090, SwRS-360.
**DATEV.** Das Ausgabeformat der Buchhaltungsübergabe an die Steuerberatung. Siehe SwRS-044.
**ZUGFeRD, XRechnung, ebInterface.** Formate der elektronischen Rechnungsstellung; ebInterface ist ein reines Exportformat ohne Netzwerkanbindung. Siehe StRS-022, SyRS-092.
**FastReport.** Die eingesetzte Berichtsmaschine.
**WiX / WixSharp, Bullseye.** Die beiden Installertechnologien mit gegenläufigen Upgrade-Regeln beziehungsweise die Zielbeschreibung der Build-Skripte. Siehe SyRS-099, SyRS-102.
@@ -0,0 +1,265 @@
# Hypothesen
c-entron ERP-Suite — Anforderungen, deren Aussage sich aus den vorliegenden Artefakten nicht abschließend belegen ließ.
Diese Datei ist aus dem zusammengeführten Bestand erzeugt und mit den Inline-Markierungen in `StRS.md`, `SyRS.md` und `SwRS.md` abgeglichen. Sie enthält genau die dort als `Status: HYPOTHESE` geführten Anforderungen — keine weiteren offenen Fragen. Offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
Eine Hypothese ist keine Vermutung ins Blaue: Der Sachverhalt ist jeweils bis zu dem Punkt belegt, an dem die Artefakte nicht weiter tragen. Das Feld *Fehlende Information* benennt, was zur Auflösung erhoben werden müsste. Die `Übernahmewürdigkeit` ist davon unabhängig und bleibt gültig.
| Ebene | Anforderungen gesamt | davon Hypothese | Anteil |
|---|---|---|---|
| StRS | 53 | 3 | 5.7 % |
| SyRS | 149 | 6 | 4.0 % |
| SwRS | 404 | 20 | 5.0 % |
| **gesamt** | **606** | **29** | **4.8 %** |
---
## StRS (Stakeholder-Ebene) — 3 Hypothesen
### StRS-002 — Dublettenfreiheit im Geschäftspartnerstamm
**Vermutete Anforderung:** Das System soll bei der Neuanlage eines Geschäftspartners auf bereits vorhandene, gleichartige Geschäftspartner hinweisen, damit derselbe Kunde oder Lieferant nicht mehrfach geführt wird.
**Fehlende Information:** Eine Dublettenprüfung für Kunden, Accounts oder Ansprechpartner ist im erhobenen Ausschnitt nicht auffindbar;
**Übernahmewürdigkeit:** übernehmen - fachlich erforderlich, im Bestand aber nicht realisiert; bei der Migration als Neuanforderung zu behandeln.
### StRS-018 — Skontogewährung beim Ausgleich offener Forderungen
**Vermutete Anforderung:** Das System soll beim Ausgleich einer Forderung innerhalb der vereinbarten Skontofrist den zulässigen Skontobetrag ermitteln, ihn der Buchhaltung zur Bestätigung vorlegen und die Forderung nach Anrechnung von Zahlung und Skonto als vollständig ausgeglichen führen.
**Fehlende Information:** Fehlende Information: die Stelle, an der der Skontoabzug fachlich ermittelt und auf die Forderung angerechnet wird - vermutet werden Webservice- oder Frontendpfade außerhalb des erhobenen Ausschnitts.
**Übernahmewürdigkeit:** übernehmen - kaufmännisch unverzichtbar; die Regel ist im Bestand nur clientseitig und unvollständig vorhanden und bei der Migration serverseitig zu verankern.
### StRS-052 — Getrennte Datenhaltung mehrerer Mandanten
**Vermutete Anforderung:** Das System soll mehrere rechtlich getrennte Einheiten in einer Installation so führen, dass ein Benutzer Stammdaten, Belege, Nummernkreise und Auswertungen ausschließlich derjenigen Einheit sieht und verändert, der er zugeordnet ist, und dass eine Auswertung oder eine Nummernvergabe niemals Daten mehrerer Einheiten vermischt.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - Der Bedarf mehrerer rechtlich getrennter Einheiten besteht fachlich; die vorhandene Umsetzung trägt ihn nicht und ist beim Nachbau als durchgängige Systemeigenschaft neu zu entwerfen.
---
## SyRS (System-Ebene) — 6 Hypothesen
### SyRS-027 — Skontoabzug beim Abgleich einer Zahlung mit einem offenen Posten
**Vermutete Anforderung:** Das System soll bei einem Zahlungseingang innerhalb der vereinbarten Skontofrist den zulässigen Skontobetrag ermitteln, den Restbetrag der Rechnung entsprechend ausgleichen und den gewährten Skonto getrennt ausweisen.
**Fehlende Information:** Eine durchsetzende Stelle für einen Skontoabzug beim Zahlungsabgleich ist nicht auffindbar: Eine Volltextsuche nach `Skonto|CashDiscount` über `Centron.BL/Finances`, `Centron.BL/Accounting` und `Centron.Gateway/OnlineBanking` liefert keine Stelle, die einen Skontoabzug beim Abgleich einer Zahlung mit einem offenen Posten berechnet oder prüft;
**Übernahmewürdigkeit:** übernehmen - Die Regel ist fachlich erforderlich, im erhobenen Ausschnitt aber nicht durchgesetzt; sie ist beim Umbau serverseitig zu verankern.
### SyRS-040 — Rechteprüfung beim Erzeugen und Verwalten von Berichten
**Vermutete Anforderung:** Das System soll den Abruf, die Erzeugung und die Verwaltung von Berichten an ein Benutzerrecht binden und dabei sicherstellen, dass ein Bericht keine Daten ausgibt, die der abrufende Benutzer nach dem Rechtemodell nicht sehen darf.
**Fehlende Information:** **Fehlende Information:** ob eine serverseitige Rechteprüfung in der Aufruferkette vor der Berichtsmaschine liegt (Webservice-Fassade, Nexus, Hostdienst);
**Übernahmewürdigkeit:** übernehmen - Die Anforderung ist fachlich erforderlich; ob sie derzeit an der Systemgrenze erfüllt wird, ist ohne die Aufruferkette nicht entscheidbar.
### SyRS-067 — Rechteprüfung und Parametersicherheit der Berichtserzeugung
**Vermutete Anforderung:** Das System soll jeden Bericht mit einer Berechtigungsprüfung des ausführenden Benutzers erzeugen, ändern, löschen und verschieben, dabei sämtliche Parameterwerte ausschließlich als gebundene Datenbankparameter übergeben und die freie Abfrageausführung an ein eigenes, protokolliertes administratives Recht binden.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - Rechteprüfung und gebundene Parameter sind für das Zielsystem verbindlich zu erbringen.
### SyRS-110 — Einschränkung des Mehrinstanzbetriebs durch prozesslokale Zustände
**Vermutete Anforderung:** Das System soll in einem Mehrinstanzbetrieb hinter einem Lastverteiler betreibbar sein; alle Zustände, die über einen einzelnen Aufruf hinaus gelten — Echtzeitverbindungszuordnung, gemeinsame Zwischenspeicher, Dienstsperren —, sollen instanzübergreifend geteilt werden, damit ein Anwender unabhängig von der bedienenden Instanz dasselbe Verhalten erfährt.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - Sofern der Mehrinstanzbetrieb Ziel ist, sind Backplane, geteilter Zwischenspeicher und eine datenbankgestützte Dienstsperre bei einer Migration einzuführen.
### SyRS-119 — Versandkostenermittlung über die Gewichtsstaffel
**Vermutete Anforderung:** Das System soll die Versandkosten eines Belegs aus dem Gesamtgewicht der versandrelevanten Positionen und der zur gewählten Versandart hinterlegten Gewichtsstaffel eindeutig ermitteln und eine Staffel, die für das ermittelte Gewicht keinen oder mehr als einen Treffer liefert, als Konfigurationsfehler melden statt einen beliebigen Satz zu verwenden.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - gewichtsabhängige Versandkosten sind fachlich erforderlich; die Umsetzung ist vor der Migration erst zu belegen.
### SyRS-139 — Antwortzeitverhalten der Stammdatensuche
**Vermutete Anforderung:** Das System soll eine Stammdatensuche über Kunden-, Artikel- und Mitarbeiterbestände so beantworten, dass die erste Ergebnisseite innerhalb einer festgelegten, messbaren Höchstdauer beim Anwender sichtbar ist, und diese Höchstdauer als konfigurierten Sollwert führen sowie Überschreitungen protokollieren.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - eine messbare Antwortzeitvorgabe fehlt heute und ist für die Zielarchitektur festzulegen.
---
## SwRS (Software-Ebene) — 20 Hypothesen
### SwRS-073 — Filterbedingung für gesperrte Konten in der erweiterten Adresssuche
**Vermutete Anforderung:** Das System soll bei aktivem Filterknoten „gesperrte Konten" die Ergebnismenge der erweiterten Adresssuche auf Konten mit gesetztem Sperrkennzeichen einschränken.
**Fehlende Information:** Fehlende Information: die Stelle, an der der Filterknoten in ein Suchprädikat umgesetzt wird.
**Übernahmewürdigkeit:** übernehmen - Filterung nach Sperrstatus ist fachlich erforderlich, die Umsetzung ist noch zu belegen.
### SwRS-079 — Rechteprüfung beim Löschen eines SEPA-Mandats
**Vermutete Anforderung:** Das System soll das Löschen eines produktiven SEPA-Mandats an ein ausdrückliches Löschrecht binden, analog zum Löschen eines Auftragsverarbeitungsvertrags.
**Fehlende Information:** Fehlende Information: eine durchsetzende Stelle, die das Löschen eines Mandats an ein Recht bindet - weder im Client noch als serverseitige Prüfung ist eine solche Stelle in dieser Faktenbasis nachgewiesen.
**Übernahmewürdigkeit:** Workaround - der heutige Zustand ist eine ungewollte Rechtelücke und darf nicht unverändert übernommen werden.
### SwRS-080 — Formatprüfung der IBAN am SEPA-Mandat
**Vermutete Anforderung:** Das System soll die IBAN der einem SEPA-Mandat zugeordneten Bankverbindung vor dem Speichern auf gültiges Format und gültige Prüfziffer prüfen und das Speichern bei Verstoß abweisen.
**Fehlende Information:** Fehlende Information: ob die IBAN serverseitig geprüft wird - die zugehörige Backend-Logik ist in dieser Faktenbasis nicht enthalten.
**Übernahmewürdigkeit:** übernehmen - eine IBAN-Prüfung ist für den Lastschrifteinzug erforderlich und im Zielsystem vorzusehen.
### SwRS-083 — Serverseitige Nachprüfung der im Client durchgesetzten Schreibschutz-, Rechte- und Preisregeln
**Vermutete Anforderung:** Das System soll jede im Client durchgesetzte Schreibschutz-, Rechte- und Preisregel der Belegerfassung beim Speichern serverseitig erneut prüfen und eine Anforderung abweisen, die gegen sie verstößt.
**Fehlende Information:** Fehlende Information: ob die zugehörige serverseitige Logik dieselben Bedingungen erneut prüft - aus diesem Ausschnitt ist das nicht belegbar;
**Übernahmewürdigkeit:** übernehmen - die serverseitige Nachprüfung ist im Zielsystem verbindlich vorzusehen; der heutige Nachweis fehlt.
### SwRS-085 — Rechteprüfung der Container des Beleg-Dashboards
**Vermutete Anforderung:** Das System soll jede Dashboard-Kachel, die Vertrags-, Umsatz- oder Projektzahlen anzeigt, nur Benutzern zugänglich machen, die das Recht auf die zugrunde liegenden Daten besitzen.
**Fehlende Information:** Fehlende Information: ob die Sichtbarkeit der Kacheln zentral über die Kachel- bzw.
**Übernahmewürdigkeit:** übernehmen - eine rechteabhängige Kachelanzeige ist im Zielsystem vorzusehen; der heutige Durchsetzungsort ist offen.
### SwRS-090 — Eindeutigkeit von Barcode- und Seriennummernwerten
**Vermutete Anforderung:** Das System soll die Eindeutigkeit eines Barcode- bzw. Seriennummernwerts im vorgesehenen Gültigkeitsbereich durchsetzen und die Anlage eines bereits vergebenen Werts abweisen.
**Fehlende Information:** Fehlende Information: ob eine Eindeutigkeitsprüfung in der Geschäftslogik (`IBarcodeLogic`) besteht - diese liegt außerhalb dieses Ausschnitts.
**Übernahmewürdigkeit:** übernehmen - Seriennummern-Eindeutigkeit ist im Zielsystem datenbankseitig zu verankern.
### SwRS-102 — Ausschluss werbegesperrter Adressen aus Kampagnen- und Mailingläufen
**Vermutete Anforderung:** Das System soll jede Adresse mit gesetztem Kennzeichen `AdvertisingNotAllowed` aus der Empfängermenge jedes Kampagnen- und Mailinglaufs ausschließen.
**Fehlende Information:** Fehlende Information: eine durchsetzende Stelle, die werbegesperrte Adressen aus der Empfängermenge entfernt - weder im Client noch als belegte serverseitige Selektion.
**Übernahmewürdigkeit:** übernehmen - eine gepflegte Werbesperre ohne durchsetzende Stelle ist im Zielsystem zwingend zu schließen.
### SwRS-118 — Eindeutigkeit der Belegnummer von Lieferantenbelegen
**Vermutete Anforderung:** Das System soll die Eindeutigkeit einer Belegnummer je Lieferant und Belegart persistenzseitig sicherstellen und eine bewusst zugelassene Dublette als ausdrücklich bestätigten Sonderfall kennzeichnen.
**Fehlende Information:** Fehlende Information: ein eindeutiger Datenbankindex auf die Belegnummer ist in dieser Faktenbasis nicht nachgewiesen;
**Übernahmewürdigkeit:** übernehmen - die Prüfung ist zu erhalten und um eine persistenzseitige Absicherung zu ergänzen.
### SwRS-149 — Serverseitige Rechteprüfung der über den SQL-Manager abgesetzten Abfragen
**Vermutete Anforderung:** Das System soll jede über den SQL-Manager abgesetzte Abfrage serverseitig erneut gegen das Recht `Administration.SQL_MANAGER` prüfen und auf lesende Anweisungen beschränken.
**Fehlende Information:** Fehlende Information: die serverseitige Implementierung selbst.
**Übernahmewürdigkeit:** Sonderfall - freier Abfragezugang ist im Zielsystem auf eine geprüfte, lesende Schnittstelle zu begrenzen.
### SwRS-163 — Rechteprüfung des Rechnungs-PDF-Exports
**Vermutete Anforderung:** Das System soll den Export von Rechnungen als PDF an ein eigenes, an der Aufrufstelle geprüftes Benutzerrecht binden.
**Fehlende Information:** Fehlende Information: die Aufrufstelle von `DataExportViewModel`.
**Übernahmewürdigkeit:** übernehmen - das Recht ist im Zielsystem ausdrücklich zu definieren.
### SwRS-172 — Serverseitige Kennwortregeln bei der Kennwortänderung
**Vermutete Anforderung:** Das System soll Mindestlänge, Zeichenkomplexität und eine Wiederverwendungssperre für Kennwörter serverseitig durchsetzen und dem Client nur die Rückmeldung überlassen.
**Fehlende Information:** Fehlende Information: die serverseitige Implementierung der Kennwortänderung.
**Übernahmewürdigkeit:** übernehmen - Kennwortregeln gehören verbindlich auf die Serverseite.
### SwRS-256 — Clientseitiger Pfad zur Abschaltung der Systemauthentifizierung
**Vermutete Anforderung:** Das System soll die Umstellung des systemweiten Anmeldeverfahrens, insbesondere die Abschaltung der Authentifizierung, serverseitig an ein benanntes Administrationsrecht binden, den Vorgang mit Benutzer und Zeitpunkt protokollieren und im Fehlerfall keine unveränderten Antwortinhalte des Gegenübers an den Aufrufer weitergeben.
**Fehlende Information:** fehlende Information: die durchsetzende Stelle am Endpunkt `config/authentication` für den Zweig „keine Authentifizierung".
**Übernahmewürdigkeit:** übernehmen - die Funktion wird benötigt, die Absicherung ist zu belegen und gegebenenfalls nachzurüsten.
### SwRS-355 — Kebab-Case-Pflicht für Dokumentationsdateien ohne maschinelle Durchsetzung
**Vermutete Anforderung:** Das System soll die Einhaltung von Verzeichnisstruktur und Kebab-Case-Namensregel für Dokumentationsdateien in einem Pipelineschritt prüfen und Verstöße als Fehler melden.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - die Regel ist sinnvoll, aber erst mit einer Prüfung wirksam.
### SwRS-359 — Gestaffelte Auditspalten und logische Löschung für neue Domänentabellen
**Vermutete Anforderung:** Das System soll jede neue Domänentabelle mit den Anlage- und Löschauditspalten ausstatten, Änderungsauditspalten nur bei änderbaren Zeilen führen, Datensätze ausschließlich logisch über `IsDeleted` löschen und auf SQL-Defaults verzichten.
**Fehlende Information:** Fehlende Information: eine durchsetzende Stelle (Analyzer, Schematest oder generierende Hilfsmethode), die das Vorhandensein der fünf Pflichtspalten und das Fehlen von SQL-Defaults auf neuen Domänentabellen tatsächlich erzwingt;
**Übernahmewürdigkeit:** übernehmen - logische Löschung und Auditspalten sind Grundlage der Nachvollziehbarkeit.
### SwRS-361 — Zeitlich befristete Aktionspreise in HerstellerArtikAktionspreis
**Vermutete Anforderung:** Das System soll für einen Artikel innerhalb des hinterlegten Gültigkeitszeitraums den Aktionspreis anstelle des regulären Preises verwenden.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** Sonderfall - Datenhaltung vorhanden, Wirksamkeit in der Preisfindung ungeklärt.
### SwRS-362 — Umleitung externer E-Mail-Adressen in DEBUG-Builds
**Vermutete Anforderung:** Das System soll den Versand an Empfängeradressen außerhalb der Domäne `nexoware.com` in Entwicklungs- und Testständen unterbinden und stattdessen an eine feste Sammeladresse zustellen; die Steuerung soll an der Betriebsumgebung und nicht an der Buildkonfiguration hängen.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - Schutzmechanismus notwendig, Kopplung an die Umgebung statt an die Buildkonfiguration zu ändern.
### SwRS-363 — Unterstützte ZUGFeRD- und XRechnung-Fassungen mit fester Business-Process-ID
**Vermutete Anforderung:** Das System soll elektronische Rechnungen in genau diesen vier Fassungen erzeugen und bei der Fassung XRechnung 3.0.1 die genannte Business-Process-ID unverändert eintragen.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - abrechnungsrelevantes Ausgabeformat, gesetzlich gefordert.
### SwRS-364 — Skriptnummernvergabe außerhalb des Repositories ohne Kollisionsschutz
**Vermutete Anforderung:** Das System soll die Vergabe der Skriptnummer im Repository nachvollziehbar führen und kollidierende Nummern beim Bau erkennen, statt sie einer Datei außerhalb der Versionsverwaltung zu überlassen.
**Fehlende Information:** Fehlende Information: Die maßgebliche Nummernliste liegt außerhalb des Repositories und ist im Rahmen dieser Erhebung nicht einsehbar;
**Übernahmewürdigkeit:** Workaround - Verfahren außerhalb der Versionsverwaltung, im Zielsystem zu ersetzen.
### SwRS-380 — Frontend-Abhängigkeiten nur über LibMan oder CDN mit Integrity-Hash
**Vermutete Anforderung:** Das System soll externe Skript- und Stilressourcen nur mit hinterlegtem Integrity-Hash laden oder im Repository vorhalten und die Einhaltung dieser Regel maschinell prüfen.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - Subresource Integrity ist sinnvoll, aber erst mit Prüfung wirksam.
### SwRS-385 — Einschränkende Rechte verringern die Sichtbarkeit
**Vermutete Anforderung:** Das System soll die Rechtelogik so auswerten, dass der Besitz eines als einschränkend gekennzeichneten Rechts den Sichtbarkeitsumfang verringert, und abgerechnete Helpdeskzeiten unabhängig vom Rechtebesitz gegen Verschieben und Löschen sperren.
**Fehlende Information:** siehe Feld `Fakt` der Anforderung; der Beleg der durchsetzenden Stelle steht aus.
**Übernahmewürdigkeit:** übernehmen - der Katalog ist unvollständig, die beschriebene Logik jedoch tragend.
---
## Abgleich mit den Inline-Markierungen
Deckungsgleich: jede hier aufgeführte Anforderung trägt im jeweiligen Ebenendokument sowohl `Status: HYPOTHESE` als auch das Titelpräfix `[HYPOTHESE]`; umgekehrt ist keine so gekennzeichnete Anforderung hier ausgelassen.
@@ -0,0 +1,652 @@
# Traceability
c-entron ERP-Suite — Verfolgbarkeit zwischen den drei Ebenen der Spezifikation nach ISO/IEC/IEEE 29148:2018.
Die Verknüpfungen stammen aus dem Feld `Tracelinks` der Anforderungen und sind beidseitig ausgewertet: eine Verknüpfung, die eine SwRS auf ihre SyRS setzt, erscheint auch in der Rückwärtssicht der SyRS. Die Spalte `Artefaktbeleg` nennt den ersten `PRIMÄR`-Beleg der jeweils tiefsten Anforderung der Zeile; die vollständige Belegliste steht am Anforderungsblock selbst.
| Ebene | Anforderungen | mit Verknüpfung nach oben | mit Verknüpfung nach unten |
|---|---|---|---|
| StRS | 53 | 0 | 53 |
| SyRS | 149 | 140 | 129 |
| SwRS | 404 | 403 | 0 |
---
## 1 Konsolidierte Tabelle StRS — SyRS — SwRS
Eine Zeile je SwRS-Anforderung. `StRS-ID` ist über die SyRS-Kette aufgelöst; wo eine SwRS unmittelbar auf eine StRS verweist, steht diese ebenfalls. Ein Strich bedeutet, dass auf dieser Ebene keine Verknüpfung besteht — diese Fälle sind in Abschnitt 4 aufgeführt.
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
|---|---|---|---|
| StRS-006 | SyRS-001, SyRS-002 | SwRS-001 | `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs:273-301` — `IsCustomerReceipt`/`IsSupplierRecei... |
| StRS-006 | SyRS-001, SyRS-002, SyRS-004, SyRS-005 | SwRS-002 | `Centron.BL/Sales/Receipts/SpecificLogics.cs:46-59` (Registrierung) und `:123-139` (`Execute<T>`), Zitat `I... |
| StRS-006, StRS-007, StRS-052 | SyRS-007, SyRS-114 | SwRS-003 | `ReceiptBL.cs:8573-8576` (`ShouldUpdateNumberOnSave`), Zitat `return isNewReceipt && data.IsOnlyForReportPr... |
| StRS-007, StRS-052 | SyRS-007, SyRS-008 | SwRS-004 | `Centron.BL/Administration/Company/NumberGroupBL.cs:62-92`, Zitat `.Where(f => f.I3D == numberGroupObject.I... |
| StRS-005 | SyRS-038 | SwRS-005 | `Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs:154-286` (`GetBasePrice`, Verzweigungen `:169`, `... |
| StRS-005 | SyRS-038 | SwRS-006 | `ReceiptItemPriceBL.cs:235-257`, Zitat `case SpecialPriceKind.SurchargePurchasePrice: basePrice = purchaseB... |
| StRS-014 | SyRS-116 | SwRS-007 | `Centron.BL/Sales/Receipts/Internal/ReceiptProvisionBL.cs:579-582` (`CalculateProvisionAmount`), Zitat `var... |
| StRS-007, StRS-052 | SyRS-007 | SwRS-008 | `Centron.BL/Sales/Receipts/Offers/OfferSpecificLogic.cs:113`, Zitat `public NumberGroupEnum GetNumberGroup(... |
| StRS-049 | SyRS-019 | SwRS-009 | `Centron.BL/Sales/Receipts/ReceiptCartBL.cs:903-916` (`SetCartDefaultProperties`), Zitat `newCart.IsCart = ... |
| StRS-006 | SyRS-004 | SwRS-010 | `ReceiptBL.cs:1578-1638`, Zitat `createReceiptResult.Data.Receipt.BranchI3D = receiptsToForward.Count == 1 ... |
| StRS-007, StRS-052 | SyRS-007 | SwRS-011 | `Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs:104-141`, Zitat `if (receiptNetPrice == 0) { … ... |
| StRS-006, StRS-009 | SyRS-005, SyRS-009 | SwRS-012 | `Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:143-187` (`CancelInvoice`), Zitat `if (this._bookKe... |
| StRS-006, StRS-009 | SyRS-005, SyRS-009 | SwRS-013 | `ReceiptInvoiceBL.cs:86-141` (`FixInvoice`) und `:273-291` (`CheckIfInvoiceIsFixed`) |
| StRS-008 | SyRS-112 | SwRS-014 | `src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs:202-213` und `:215-230`, Zitat `var r... |
| StRS-008 | SyRS-112 | SwRS-015 | `ReceiptPriceHelper.cs:232-242`, Zitat `return CalculateNetPrice(basePrice, precision, discount, currencyFa... |
| StRS-008 | SyRS-112 | SwRS-016 | `ReceiptPriceHelper.cs:37-41`, Zitat `TaxPrice = taxPriceSum - (switzerlandRounding == false ? 0m : netPric... |
| StRS-010 | SyRS-016 | SwRS-017 | `Centron.BL/Sales/Receipts/DownPayment/DownPaymentBL.cs:82-165`, Bedingung `:124-125`, Zitat `?? throw new ... |
| StRS-016 | SyRS-022, SyRS-023 | SwRS-018 | `Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs:248-275` und `:277-303`, Zitat `case DunningLev... |
| StRS-011, StRS-027 | SyRS-021 | SwRS-019 | `Centron.BL/Sales/Receipts/Internal/ReceiptContractHelperBL.cs:162-168` (`UsedContingent`), Zitat `this.Ses... |
| StRS-025 | SyRS-017 | SwRS-020 | `DeliveryListSpecificLogic.cs:185, 188, 326` und `PickupListSpecificLogic.cs:195, 198, 312` |
| StRS-024 | SyRS-032 | SwRS-021 | `SupplierOrderSpecificLogic.cs:683-686`, `SupplierDeliveryListSpecificLogic.cs:625-628`, `SupplierInvoiceSp... |
| StRS-011, StRS-012, StRS-027 | SyRS-020, SyRS-021 | SwRS-022 | `src/backend/Centron.Interfaces/Sales/BillingCenter/Contracts/ContractCalculationKind.cs:7-18`, Typ `Contra... |
| StRS-011, StRS-027 | SyRS-021 | SwRS-023 | `Centron.BL/Sales/Receipts/Internal/ReceiptContractHelperBL.cs:88-104` (`ThresholdContingent.ToBilling`), Z... |
| StRS-011, StRS-012 | SyRS-020 | SwRS-024 | `Centron.BL/Sales/Receipts/ContractLists/ReceiptContractBL.cs:579-620` (`GetContractTodoDate`), Zitat `case... |
| StRS-011, StRS-012 | SyRS-020 | SwRS-025 | `Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs:829-830`, Zitat `(filter.Calculation... |
| StRS-013 | SyRS-037 | SwRS-026 | `Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:94-101` (`SaveMasterDataList`), Zitat `i... |
| StRS-013 | SyRS-037 | SwRS-027 | `Sales/CustomerAssets/Contracts/ClickContracts/DeviceClickCounterBL.cs:250-257` (`GetAndUpdateDeviceClickCo... |
| StRS-007 | SyRS-070 | SwRS-028 | `Sales/Support/HelpdeskBL.cs:269-291` (`GetLoggedInUserShowHelpdeskRight`), Durchsetzung `:148-231`, Zitat ... |
| StRS-007 | SyRS-070 | SwRS-029 | `Sales/Support/HelpdeskBL.cs:122-133` (`GetHelpdeskRequest`), Zitat `if (salesAreaI3Ds.Any() && salesAreaI3... |
| StRS-026 | SyRS-033 | SwRS-030 | `Sales/Support/Escalation/EscalationBL.cs:393-398` (`CheckEskalationStage`), `:313-388` (`ShouldEscalated`)... |
| StRS-005 | SyRS-038 | SwRS-031 | `Warehousing/ArticleVolumePricesBL.cs:88-97` (`GetVolumePrice`), Zitat `return volumePrices.OrderByDescendi... |
| StRS-005 | SyRS-038 | SwRS-032 | `ReceiptItemPriceBL.cs:482-496` (`GetSellPriceForCustomer`), Zitat `switch (priceList ?? 0) { case 0: retur... |
| StRS-008 | SyRS-111 | SwRS-033 | `Warehousing/TaxBL.cs:206-238` (`GetTaxRateForReceiptItem`), Zitat `bool previousTaxRateWasActiveForReceipt... |
| StRS-025 | SyRS-017 | SwRS-034 | `Centron.DAO/Repositories/Warehousing/StockManagement/ArticleStockRepository.cs:122-145` und `:147-161`, Zi... |
| StRS-024, StRS-025 | SyRS-120 | SwRS-035 | `Warehousing/StockManagement/ArticleStockBL.cs:74-148` (`UpdateArticlePurchasePrice`), Zitat `newPurchasePr... |
| StRS-023 | SyRS-031 | SwRS-036 | `Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs:86-160` (Feld `_sqlArticle`), Zitat `INNER JOIN cv... |
| — | SyRS-126 | SwRS-037 | `Centron.Interfaces/Production/ProductionOrderItemState.cs:7-22` und Mapping `Centron.DAO/Mappings/Producti... |
| StRS-001, StRS-002 | SyRS-036 | SwRS-038 | `Accounts/AccountBL.cs:137-145` (`GetNewAccount`), Zitat `defaultAddress.Data.IsDefault = true;` / `default... |
| — | SyRS-127 | SwRS-039 | `Accounts/Campaigns/CampaignBL.cs:421-452` (`CanEditCampaign`/`CanOpenCampaign`), Zitat `if (user == null \|... |
| StRS-017 | SyRS-024, SyRS-025 | SwRS-040 | `Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs:342-360` (`CheckForCompleted`, Auf... |
| StRS-017 | SyRS-024 | SwRS-041 | `OnlineBankingAccountTransactionsBL.cs:581-617` (`AutoCompleteSingleAccountTransaciton`), Bedingungen `:599... |
| StRS-017 | SyRS-024 | SwRS-042 | `OnlineBankingAccountTransactionsBL.cs:1042-1086` (`BookAmountToAssignedInvoice`), `:1048-1050`, `:1058-106... |
| StRS-015 | SyRS-115 | SwRS-043 | `Centron.BL/Sales/CashBooks/CashBookBL.cs:34-58` (`GetCurrentSequenceNumber`), Zuweisung `:22`, Zitat `if (... |
| StRS-021 | SyRS-018 | SwRS-044 | `Centron.Gateway/DataExchange/BookKeeping/DatevAscii/BookKeepingExportDatevAscii.cs:936-978` (`ValidateDate... |
| StRS-030 | SyRS-040 | SwRS-045 | `src/backend/Centron.BL/Statistics/SaleStatistics/CacheSalesStatisticsBL.cs:22-34`, Zitat `if (!loggedInUse... |
| StRS-031 | SyRS-041 | SwRS-046 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs:46-50` (`AuthenticateInternal`) un... |
| StRS-034, StRS-037 | SyRS-055 | SwRS-047 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644-664`, Zitat `var rights = this.Session.Adv... |
| StRS-034 | SyRS-055 | SwRS-048 | `SSMS_DB_SCHEMA.sql:51267-51275`, Zitat `CREATE TABLE [dbo].[Sichtrus]( [I3D] [int] IDENTITY(1,1) NOT NULL,... |
| StRS-031, StRS-036, StRS-051 | SyRS-041, SyRS-087 | SwRS-049 | `Administration/AccessTokens/AccessTokenBL.cs:457-488` (`GenerateSecureToken`, `HashToken`) |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-050 | `src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs:77-92` (`GetKeyAndIV`), Zitat `private const strin... |
| StRS-033 | SyRS-073 | SwRS-051 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs:849-887` (`GetAvailableGuidelinesForEmployee`)... |
| StRS-007, StRS-052 | SyRS-007, SyRS-069 | SwRS-052 | `Administration/Mandatory/MandatoryBL.cs:85-111`, Altvariante `:114-157`, Umschaltung `:57-80`, Zitat `WHER... |
| StRS-051 | SyRS-131 | SwRS-053 | `SSMS_DB_SCHEMA.sql`, Tabelle `[dbo].[Personal]` ab Z. 4319, berechnete Spalte `IsActive`, Zitat `[IsActive... |
| StRS-029 | SyRS-143 | SwRS-054 | `src/backend/Centron.Entities/Entities/ScheduleArea/Schedule.cs` (`ScheduleOld.HalfDay`/`HalfDayAM`/`HalfDa... |
| StRS-011, StRS-029 | SyRS-109 | SwRS-055 | `src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs:43-47` und `:210-213`, Zitat `var handler = thi... |
| StRS-029 | SyRS-125 | SwRS-056 | `SSMS_DB_SCHEMA.sql:47084-47112`, Tabelle `[dbo].[Projekt]`, Zitat `[Name] [varchar](50) NULL, [Beschreibun... |
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-057 | `Centron.BL/EDI/SupplierEDI/SupplierEdiBL.cs:1364-1415` (`ApplyDistriToCentron`), `:1389-1395`, Zitat `case... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-058 | `Centron.BL/WebServices/EDI/SupplierEDI/SupplierEdiConfigurationsWebServiceBL.cs:74` und `SupplierEdiBL.cs:... |
| StRS-022, StRS-047 | SyRS-092 | SwRS-059 | `Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs:1033-1060`, Konstante `:64`, Zitat `private c... |
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-060 | `Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs:174-185` (`CreateReference`), Typkonstant... |
| StRS-050 | SyRS-140, SyRS-141 | SwRS-061 | `Centron.Common/DeveloperSecurity.cs:14,18,22,30-44` (`DeveloperSecurity.Email.ValidateAddress`), Zitat `pu... |
| StRS-051 | SyRS-066, SyRS-131 | SwRS-062 | `Centron.BL/Administration/FileManagement/DirectoryBL.cs:300-308` (`CheckUserHasDirectoryRight`), Aufrufer ... |
| StRS-036, StRS-051 | SyRS-066, SyRS-129 | SwRS-063 | `Centron.BL/Administration/FileManagement/SharedDocumentBL.cs:115-155` (`GenerateTokenForDocument`), Doppel... |
| StRS-026 | SyRS-034 | SwRS-064 | `Centron.BL/CheckListArea/UpdateChecklistBL.cs:72-107` (`UpdateItemState`), `:109-125` (`UpdateParentItems`... |
| StRS-006, StRS-030 | SyRS-040, SyRS-114 | SwRS-065 | `Centron.BL/ReportEngine/ReportDataBL.cs:194-236` und `:1633-1667` sowie `Centron.DAO/Reporting/NativeSqlDA... |
| StRS-042 | SyRS-099 | SwRS-066 | `Centron.BL/Administration/Scripts/ScriptEngineBL.cs:118-123` (`DoExecuteScriptMethodSet`) und `:222-225` (... |
| StRS-034, StRS-049 | SyRS-061 | SwRS-067 | `Centron.BL/Administration/Rights/UserRightsExt.cs:34-47`, Aufrufer `Sales/Support/HelpdeskBL.cs:472,478,48... |
| StRS-037 | SyRS-075 | SwRS-068 | `Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs:19`, `:63-83` (`OnPreUpdate`), `:183-195` und `C... |
| StRS-011, StRS-029 | SyRS-109 | SwRS-069 | `src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs:32-92`, `:23`, `:98-133`... |
| — | SyRS-137 | SwRS-070 | `Centron.BL/GUI/Profiles/UiProfileBL.cs:46-61` (`SaveProfile`), Zitat `if (profile.IsGlobal && currentUser.... |
| StRS-001, StRS-002 | SyRS-036 | SwRS-071 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmMainViewModel.cs:2751-2873` (`CheckMandadatory`) - „if ... |
| StRS-034 | SyRS-068 | SwRS-072 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:522-530` - „() => !CentronCache.Instance.CrmSetti... |
| StRS-001, StRS-002 | SyRS-036 | SwRS-073 | — |
| StRS-001, StRS-002 | SyRS-036 | SwRS-074 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/Settings/Requirements and preassignments/RequirementsAndPr... |
| StRS-001 | SyRS-132 | SwRS-075 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/Hotline/HotlineManagementViewModel.cs:104-107` (`CanSave`)... |
| StRS-034 | SyRS-055 | SwRS-076 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/Dsgvo/ManageOrderProcessingContractsViewModel.cs:124-131` ... |
| StRS-005 | SyRS-038 | SwRS-077 | `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs:235-257`, Zitat `switch (specialPrice... |
| StRS-019 | SyRS-117 | SwRS-078 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SepaContracts/AddSepaContract/AddSepaContractViewModel.cs:... |
| StRS-034 | SyRS-055 | SwRS-079 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SepaContracts/ManageSepaContractsViewModel.cs:122-125` (`C... |
| StRS-017 | SyRS-024 | SwRS-080 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SepaContracts/AddSepaContract/AddSepaContractViewModel.cs:... |
| — | — | SwRS-081 | `src/shared/Centron.Controls/AccountContracts/AccountContractDetailsViewModel.cs:328-357` - „this.CanSaveAc... |
| StRS-009 | SyRS-011 | SwRS-082 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ReceiptViewModel.cs:2519-2540` - „if (this.IsReadOnly... |
| StRS-034 | SyRS-077 | SwRS-083 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Suppliers/SupplierReceiptViewModel.cs:2721-2737` - „i... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-084 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Settings/GLS/GlsSettingViewModel.cs:83,88-94` - „this... |
| StRS-034 | SyRS-055 | SwRS-085 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Dashboard/**/*.cs` (20 Dateien, Volltextsuche ohne Tr... |
| StRS-046 | SyRS-094 | SwRS-086 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ArticleSearch/SearchArticlesHelper.cs:109` |
| StRS-007 | SyRS-070 | SwRS-087 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision/SchemaReceivers/ProvisionReceiverGridViewMo... |
| StRS-021 | SyRS-018 | SwRS-088 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Suppliers/SupplierReceiptViewModel.cs:2721-2737` - „i... |
| StRS-036, StRS-051 | SyRS-087 | SwRS-089 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/EditSharedDocumentLink/EditSharedDocumentLinkViewMode... |
| StRS-025 | SyRS-030 | SwRS-090 | `SSMS_DB_SCHEMA.sql:10077-10116,58653-58720` - „[Barcode] [varchar](200) NULL," und „CREATE NONCLUSTERED IN... |
| StRS-025 | SyRS-030 | SwRS-091 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ScanBarcodes/ScanBarcodesViewModel.cs:604-621` (`Show... |
| StRS-046 | SyRS-094 | SwRS-092 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ContentImport/ContentImportViewModel.cs:83-89` (`Load... |
| StRS-011, StRS-027 | SyRS-021 | SwRS-093 | `src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractsManagementViewModel.cs:1669-1759` (`CheckCa... |
| StRS-011, StRS-012 | SyRS-020 | SwRS-094 | `src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/Pages/OverviewWizardPageViewModel.cs:1607-164... |
| StRS-011, StRS-027 | SyRS-021 | SwRS-095 | `src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/ViewModel/FlatRateProjectViewModel.cs:952-966`... |
| StRS-034 | SyRS-055 | SwRS-096 | `src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling/Pages/TimerBillingTimerSelectionPageViewModel.cs:... |
| StRS-003, StRS-016 | SyRS-022 | SwRS-097 | `src/centron/Centron.WPF.UI/Modules/Finances/Dunning/DunningOverviewViewModel.cs:145-160` (`Validate`) - „i... |
| StRS-016 | SyRS-023 | SwRS-098 | `src/centron/Centron.WPF.UI/Modules/Finances/Opos/Pages/OposRunPreviewViewModel.cs:261-264` (`CanExecuteOpo... |
| StRS-017 | SyRS-026 | SwRS-099 | `src/centron/Centron.WPF.UI/Modules/Finances/Payments/IncomingPayments/IncomingPaymentsViewModel.cs:545-556... |
| StRS-013 | SyRS-037 | SwRS-100 | `src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter/DeviceClickCounterView.xaml.cs:31-46` (`New... |
| StRS-030 | SyRS-040 | SwRS-101 | `src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluationOld/ContractEvaluationOldAppModuleController... |
| — | SyRS-127 | SwRS-102 | `SSMS_DB_SCHEMA.sql:3441` (`CREATE TABLE [dbo].[Accounts]`) - „[AdvertisingNotAllowed] [bit] NOT NULL," |
| StRS-007 | SyRS-070 | SwRS-103 | `src/centron/Centron.WPF.UI/Modules/Finances/Projects/ProjectsAppModuleControllerViewModel.cs:198-200`, Kon... |
| StRS-013 | SyRS-037 | SwRS-104 | `src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists/MasterDataListViewModel.cs:771-776` (`CanChang... |
| StRS-034 | SyRS-068 | SwRS-105 | `src/centron/Centron.WPF.UI/Modules/PLM/PlmAppModuleController.cs:13` - „public class PlmAppModuleControlle... |
| StRS-025, StRS-030 | SyRS-133, SyRS-134 | SwRS-106 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/ViewModel/EditArticle/EditArticleView.Art... |
| StRS-005 | SyRS-038 | SwRS-107 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/ViewModel/EditArticle/Article/ArticleVolu... |
| StRS-025 | SyRS-029 | SwRS-108 | `src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/ViewModels/WizardViewModels/ResultViewModel.cs:10... |
| StRS-021 | SyRS-039 | SwRS-109 | `src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement/Class/BranchRevenueAndExpenseAccoun... |
| StRS-005 | SyRS-038 | SwRS-110 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/ViewModel/EditArticle/EditArticleViewMode... |
| StRS-046 | SyRS-094, SyRS-128 | SwRS-111 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/ArticleImport/ArticleImportViewModel.cs:2... |
| StRS-025 | SyRS-017 | SwRS-112 | `src/centron/Centron.WPF.UI/Modules/Warehousing/Commissions/CommissionOrders/CommissionOrderItemViewModel.c... |
| — | SyRS-139 | SwRS-113 | `src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle/ViewModel/SearchArticleViewModel.cs:130-144` |
| StRS-025 | SyRS-030 | SwRS-114 | `src/centron/Centron.WPF.UI/Modules/Warehousing/BarcodeManagement/GenerateBarcode/ViewModel/GenerateBarcode... |
| StRS-021 | SyRS-039 | SwRS-115 | `src/centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems/BookKeepingAccountSystemViewModel.cs:112-125` |
| StRS-001 | SyRS-132 | SwRS-116 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleUnitManagement/ViewModel/ArticleUnitManagementViewMo... |
| StRS-024 | SyRS-003 | SwRS-117 | `src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/OutgoingPaymentsViewModel.cs:750-795`, Me... |
| StRS-007 | SyRS-008 | SwRS-118 | `src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/OutgoingPaymentsViewModel.cs:799-827` |
| StRS-023 | SyRS-031 | SwRS-119 | `src/centron/Centron.WPF.UI/Modules/Purchasing/Others/SuggestionQuantity.cs:117,125-131,165-169` - „var new... |
| StRS-023 | SyRS-031 | SwRS-120 | `src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/OrderSuggestionListViewModel.cs:956-959`... |
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-121 | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SupplierEDI/SupplierEdiConfigurationViewModel.cs:340-346,4... |
| StRS-034 | SyRS-068 | SwRS-122 | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/Controller/ArticleManagementAppModuleCont... |
| StRS-020 | SyRS-121 | SwRS-123 | `src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/ViewModels/TransactionDetailViewModel.cs:157-1... |
| StRS-026, StRS-027 | SyRS-034 | SwRS-124 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/CloseHelpdesk/CloseHelpdeskHelper.cs:58` und `..... |
| StRS-034 | SyRS-055 | SwRS-125 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketList/TicketListViewModel.cs:897-908` |
| StRS-026 | SyRS-124 | SwRS-126 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:786-815` (`GetDueDateFromPriority`) |
| StRS-030 | SyRS-040 | SwRS-127 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/RecordedTimes/TicketRecordedTimeContainerViewModel.c... |
| StRS-011, StRS-029 | SyRS-109 | SwRS-128 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents/ViewModels/ExpectedEventsMainViewModel.cs:111-1... |
| StRS-026 | SyRS-033 | SwRS-129 | `src/centron/Centron.WPF.UI/Processes/Ticket/TicketProcessExecutor.cs:22-28` |
| StRS-011, StRS-029 | SyRS-109 | SwRS-130 | `src/shared/Centron.Controls/TaskManagement/TaskManagmentViewModel.cs:240-298` |
| StRS-026 | SyRS-034 | SwRS-131 | `src/backend/Centron.BL/WebServices/CheckListArea/CentronChecklistWebserviceBL.cs:155-190` - „if (checklist... |
| StRS-026 | SyRS-034 | SwRS-132 | `src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskWebServiceBL.cs:283-308` - „var checklistsToCheck... |
| StRS-036, StRS-051 | SyRS-087 | SwRS-133 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/SendSelfCareForm/SendSelfCareViewModel.cs:167-221` |
| StRS-028 | SyRS-035 | SwRS-134 | `SSMS_DB_SCHEMA.sql:4145-4179` - „CREATE UNIQUE CLUSTERED INDEX [CI_RMA_HelpdeskI3D] ON [dbo].[Rma]([Helpde... |
| StRS-026, StRS-029 | SyRS-125, SyRS-144 | SwRS-135 | `src/centron/Centron.WPF.UI/Modules/ProjectManagement/EmployeeProjectWorkloadInfoViewModel.cs:242-252`, Met... |
| StRS-034 | SyRS-055 | SwRS-136 | `src/centron/Centron.WPF.UI/Modules/Administration/RightsManagement/RightsManagmentViewModel.cs:867-871` (`... |
| StRS-031 | SyRS-047 | SwRS-137 | `src/shared/Centron.Controls/EmployeeManagement/EmployeeManagementViewModel.cs:230`: `new DelegateCommand(t... |
| StRS-052 | SyRS-069 | SwRS-138 | `src/centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs:479-48... |
| StRS-034 | SyRS-055 | SwRS-139 | `src/centron/Centron.WPF.UI/Modules/Administration/Settings/SettingsContainerViewModel.cs:209-215` (`LoadAl... |
| StRS-032 | SyRS-051 | SwRS-140 | `src/centron/Centron.WPF.UI/Modules/Administration/Settings/AccessTokens/AccessTokenSettingsViewModel.cs:92... |
| — | SyRS-147 | SwRS-141 | `src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityViewModel.cs:158-159`: `private... |
| StRS-034 | SyRS-145 | SwRS-142 | `src/centron/Centron.WPF.UI/Modules/Administration/TextBlockManagement/TextBlockManagementView.ArtificialIn... |
| StRS-034 | SyRS-068 | SwRS-143 | `src/centron/Centron.WPF.UI/Modules/Administration/MailTemplates/MailTemplatesAppModuleController.cs:46-52`... |
| StRS-026 | SyRS-033 | SwRS-144 | `src/centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings/EscalationType/EscalationTypeViewMod... |
| StRS-027 | SyRS-122 | SwRS-145 | `src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates/ViewModels/HourlySurchargeRateViewM... |
| StRS-018 | SyRS-027 | SwRS-146 | `src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/ReceiptConditionViewModel.cs:241-277`,... |
| StRS-005 | SyRS-123 | SwRS-147 | `src/centron/Centron.WPF.UI/Modules/Administration/ServiceAndLeasing/ServiceLeasingViewModel.cs:176-231`, `... |
| StRS-032 | SyRS-107 | SwRS-148 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:272` - bedingungslose Aufnahme des Controllers in... |
| StRS-032 | SyRS-107 | SwRS-149 | `src/centron/Centron.WPF.UI/Modules/Administration/SqlManagers/SqlManagerViewModel.cs:76-100` (`DoExecuteQu... |
| StRS-043 | SyRS-106 | SwRS-150 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:737-739` - Registrierung des Log-Moduls mit `Help... |
| StRS-036 | SyRS-129 | SwRS-151 | `src/centron/Centron.WPF.UI/Modules/Administration/PdfSigning/PdfSigningSettingsViewModel.cs:109-167` (`DoA... |
| StRS-001 | SyRS-132 | SwRS-152 | `src/centron/Centron.WPF.UI/Modules/Administration/CountryManagement/CountryViewModel.cs:67-79`: `if (previ... |
| StRS-046 | SyRS-095 | SwRS-153 | `src/centron/Centron.WPF.UI/Modules/ExternalTool/ExternalToolPreviewViewModel.cs:113-135` (`StartExternalPr... |
| StRS-033 | SyRS-043 | SwRS-154 | `src/centron/Centron.WPF.UI/Modules/ExternalTool/ExternalToolPreviewViewModel.cs:90-101`: `variableData.Web... |
| StRS-046 | SyRS-095 | SwRS-155 | `SSMS_DB_SCHEMA.sql:39695 ff.`: `[Path] [varchar](400) NULL,` / `[CommandLineArguments] [varchar](400) NOT ... |
| StRS-029 | SyRS-084 | SwRS-156 | `src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony/TelephonyConnector.cs:85-89`: `var hasRights = Cent... |
| StRS-029 | SyRS-084 | SwRS-157 | `src/centron/Centron.WPF.UI/Modules/Administration/Services/CentronNotifications/CentronNotificationsSettin... |
| StRS-030 | SyRS-040 | SwRS-158 | `src/shared/Centron.Controls/Reports/ReportManagement/ViewModels/ReportEngine/MainReportWindowViewModel.cs:... |
| StRS-021 | SyRS-018 | SwRS-159 | `src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping/ExportKinds/BookKeepingExportDataCustomerRecei... |
| StRS-021 | SyRS-018 | SwRS-160 | `src/centron/Centron.WPF.UI/Modules/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs:706-722`: `if (str... |
| StRS-019 | SyRS-118 | SwRS-161 | `src/centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions/PaymentTransactionViewModel.cs:434-465... |
| StRS-046 | SyRS-128 | SwRS-162 | `src/centron/Centron.WPF.UI/Modules/DataExchange/DataImport/AccountImport/IbanValidation.cs:18-32`: `return... |
| StRS-021 | SyRS-018 | SwRS-163 | `src/centron/Centron.WPF.UI/Modules/DataExchange/DataExport/InvoiceExport/Exports/DataExportInvoiceAppModul... |
| StRS-007 | SyRS-070 | SwRS-164 | `src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch/SupplierOrderPerBranchViewModel.cs:... |
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-165 | `src/centron/Centron.WPF.UI/Modules/DataExchange/DocuForm/Authorization/DocuFormTokenHelper.cs:36-68`: `ret... |
| StRS-017 | SyRS-024 | SwRS-166 | `src/centron/Centron.WPF.UI/Modules/OnlineBanking/AccountTransactions/OnlineBankingAccountTransactionsViewM... |
| StRS-030 | SyRS-040 | SwRS-167 | `src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/DataSources/StatisticDataSourceFactory.cs:27-... |
| StRS-007 | SyRS-070 | SwRS-168 | `src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs:186-192`: `activeB... |
| StRS-011, StRS-027 | SyRS-021 | SwRS-169 | `src/centron/Centron.WPF.UI/Modules/Global/MSPLicensesCompare/Wizard/MSPComparerViewModel.cs:987-997`: `if ... |
| StRS-007 | SyRS-070 | SwRS-170 | `src/shared/Centron.Controls/EmployeeAnalytics/EmployeeAnalyticsViewModel.cs:292`, `:337-341`: `if (this._o... |
| StRS-011, StRS-027 | SyRS-021 | SwRS-171 | `src/shared/Centron.Controls/MyDay/Controls/MyDayWorkItemConflictHelper.cs:21-22` (`CalculateConflicts`): `... |
| StRS-033 | SyRS-043 | SwRS-172 | `src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings/PasswordChange/PersonalPasswordChangeViewMod... |
| StRS-030 | SyRS-040 | SwRS-173 | `src/shared/Centron.Controls/AutomateDashboard/AutomateDashboardViewModel.cs:63-101`: `Task.Run(() => SaveS... |
| StRS-007 | SyRS-070 | SwRS-174 | `src/centron/Centron.WPF.UI/Modules/MyCentron/TodoList/TodoListViewModel.cs:234-235`, Filter `:319-321`: `t... |
| StRS-031 | SyRS-146 | SwRS-175 | `src/centron/Centron.WPF.UI/Modules/MyCentron/Supremo/SupremoSettingsViewModel.cs:25`, `:30-33`: `this.Supr... |
| StRS-033 | SyRS-073 | SwRS-176 | `src/shared/Centron.Controls/PasswordManager/PasswordGenerator.cs:58` (NET6+) bzw. `:60-63` (Legacy), `:68-... |
| StRS-033 | SyRS-073 | SwRS-177 | `src/shared/Centron.Controls/PasswordManager/AutoType.cs:123-142` (`LoseFocus`): `if (IsWindowVisible(nextH... |
| StRS-031, StRS-037 | SyRS-075, SyRS-146 | SwRS-178 | `src/shared/Centron.Controls/PasswordManager/AccessManagementViewModel.cs:588-596`, `:671-682`, `:686-693`,... |
| StRS-033 | SyRS-073 | SwRS-179 | `src/backend/Centron.Interfaces/PasswordManager/PasswordManagerGuidelineRights.cs:5-16` |
| StRS-031 | SyRS-047 | SwRS-180 | `src/shared/Centron.Core/GoogleAuthenticator/TwoFactorAuthenticator.cs:14`: `private const int _allowedTime... |
| StRS-031 | SyRS-047 | SwRS-181 | `src/shared/Centron.Core/GoogleAuthenticator/TwoFactorAuthenticator.cs:61`, `:68-77`, `:23-24`: `var hmacsh... |
| StRS-031 | SyRS-047 | SwRS-182 | `src/shared/Centron.Core/TotpAuth/Totp.cs:14`, `:34-42`; `src/shared/Centron.Core/TotpAuth/VerificationWind... |
| StRS-037 | SyRS-075 | SwRS-183 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:533-535` - Modulgate `Sales.Customer.CustomerComm... |
| StRS-034, StRS-044, StRS-045, StRS-046 | SyRS-090, SyRS-145 | SwRS-184 | `src/backend/Centron.BL/Administration/ArtificialIntelligence/ArtificialIntelligenceBL.cs:145-161` (`CheckA... |
| StRS-011, StRS-029 | SyRS-109 | SwRS-185 | `src/webservice/Centron.Host/AspNetCore/HostedServices/MassUpdateService.cs:44-65`: `default: throw new Arg... |
| StRS-011, StRS-029 | SyRS-109 | SwRS-186 | `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs:250`, `:387-388`, `:403-407`, `:411-418` (analog `:446-4... |
| — | SyRS-126 | SwRS-187 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:824-831` |
| StRS-005 | SyRS-038 | SwRS-188 | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ProjectPriceMatrix/ProjectPriceModel.cs:86-105` (`Upd... |
| StRS-050 | SyRS-142 | SwRS-189 | `src/centron/Centron.WPF.UI/Modules/Calendar/Settings/Synchronization/CalendarSynchronizationSettingsViewMo... |
| StRS-030 | SyRS-133 | SwRS-190 | `SSMS_DB_SCHEMA.sql:5673-5678`, `:5905-5915`: `[KostentraegerI3D] [int] NULL, [Nummer] [varchar](50) NULL, ... |
| — | SyRS-119 | SwRS-191 | `src/centron/Centron.WPF.UI/Modules/Logistic/ShippingMethodSettings/ShippingMethodSettingsViewModel.cs:19`,... |
| StRS-024 | SyRS-149 | SwRS-192 | `src/centron/Centron.WPF.UI/Modules/QM/Settings/QmSettingsViewModel.cs:69-80`, `:83-94`: `this.SupplierInvo... |
| StRS-053 | SyRS-071 | SwRS-193 | `src/centron/Centron.WPF.UI/Modules/Global/VideoPortal/LicenseInfo.cs:23-31`, `:34-45`: `var iSeminarDirect... |
| — | SyRS-135 | SwRS-194 | `src/shared/Centron.Controls/CustomProperties/CustomPropertiesGrid/CustomPropertiesGridViewModel.cs:219-239... |
| StRS-007 | SyRS-070 | SwRS-195 | `src/shared/Centron.Controls/SalesAreaManagement/SalesAreasManagementViewModel.cs:106-124`, `:147-152`: `if... |
| StRS-043 | SyRS-106 | SwRS-196 | `src/centron/Centron.WPF.UI/Modules/Global/NetworkDiagnostics/NetworkDiagnosticsViewModel.cs:778-794` (`Che... |
| StRS-051 | SyRS-066 | SwRS-197 | `src/shared/Centron.Controls/CentronFileSystem/CentronFileSystemViewModel.cs:376-386` (`GetUserRights`), `:... |
| StRS-024 | SyRS-130 | SwRS-198 | `src/shared/Centron.Controls/PdfScanning/PdfScanner.cs:61-99` (`TryFindValue`): `var normalizedNumber = Num... |
| StRS-008 | SyRS-112 | SwRS-199 | `src/shared/Centron.Controls/PositionGrid/ViewModels/ReceiptArticleGridViewModel.cs:1392-1397` (`Recalculat... |
| StRS-008 | SyRS-112, SyRS-113 | SwRS-200 | `src/shared/Centron.Controls/PositionGrid/ViewModels/ReceiptArticleGridViewModel.cs:1460-1478`: `var accoun... |
| StRS-005 | SyRS-038 | SwRS-201 | `Modules/Finances/Receipts/PriceMatrix/PriceMatrixViewModel.cs:242-245`, `:259-265`, `:282-285`: `.Where(f ... |
| StRS-046 | SyRS-128 | SwRS-202 | `Modules/Sales/SpecialArticleToContractImport/SpecialArticleToContractImportViewModel.cs:1073-1083`: `if (r... |
| — | SyRS-137 | SwRS-203 | `Modules/Gui/Profiles/ManageUiProfileViewModel.cs:24-27`; `Modules/Gui/Profiles/ManageUiProfileView.xaml:37... |
| StRS-006 | SyRS-114 | SwRS-204 | `Modules/Finances/Receipts/AutoPreview/LivePreviewViewModel.cs:25`, `:111-153`: `public const int RefreshIn... |
| StRS-051 | SyRS-066 | SwRS-205 | `src/centron/Centron.WPF.UI/Start/CommandPalette/Provider/DocumentSearchCommandProvider.cs:81-96`, auskomme... |
| StRS-034, StRS-053 | SyRS-068 | SwRS-206 | `Modules/ModuleRegistration.cs:916-951`: `this._parsedRightsCheck = ModuleRightsExpressionParser.Parse(righ... |
| StRS-042 | SyRS-099 | SwRS-207 | `Services/Container/ClassContainerExtensions.cs:7-19`: `try { return action(instance); } finally { ClassCon... |
| StRS-011, StRS-029 | SyRS-109 | SwRS-208 | `Processes/ProcessExecutor.cs:30-33`, `:59-68`: `return this._handlers[step.Kind].Invoke(this.Process, step... |
| StRS-034 | SyRS-068 | SwRS-209 | `src/centron/Centron.WPF.UI.Extension/Modules/ICentronAppModuleController.cs:11-71` |
| StRS-033, StRS-042 | SyRS-043, SyRS-148 | SwRS-210 | `src/shared/Centron.Controls.Preview/DataProviders/WebServiceConnectionProvider.cs:5-18`: `// this class is... |
| StRS-031 | SyRS-041 | SwRS-211 | `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs:57-59` (`JwtAuthController... |
| StRS-031 | SyRS-047 | SwRS-212 | `src/webservice/Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs:15-21` (`TwoFactorAu... |
| StRS-034 | SyRS-055 | SwRS-213 | `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs:38-55` (`UserRightAuthoriz... |
| StRS-034 | SyRS-055 | SwRS-214 | `src/webservice/Centron.Controllers/Authorization/AuthorizeAnyUserRightAttribute.cs:49-53` - „if (_required... |
| StRS-043 | SyRS-080 | SwRS-215 | `src/webservice/Centron.Controllers/Configuration/GlobalExceptionFilter.cs:10-23` (`GlobalExceptionFilter.O... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-216 | `src/webservice/Centron.Controllers/Utils/ApplicationGuidHelper.cs:38-46` (`ApplicationGuidHelper.DecryptTe... |
| StRS-024 | SyRS-032 | SwRS-217 | `src/webservice/Centron.Controllers/Controllers/v1/Orders/OrdersController.cs:17-23` - „[Authorize] public ... |
| StRS-007 | SyRS-070 | SwRS-218 | `src/webservice/Centron.Controllers/Controllers/v1/Customers/CustomersController.cs:14-139` - kein Authoriz... |
| — | SyRS-137 | SwRS-219 | `src/webservice/Centron.Controllers/Controllers/v1/Administration/ThemesController.cs:14-128` - „[Authorize... |
| StRS-032 | SyRS-051 | SwRS-220 | `src/backend/Centron.BL/WebServices/Administration/AccessTokens/AccessTokenWebServiceBL.cs:49` - „if (!isOw... |
| StRS-034 | SyRS-055 | SwRS-221 | `src/webservice/Centron.Controllers/Controllers/v1/Tickets/HelpdeskTimersController.cs:15-16` - „[Authorize... |
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-222 | `src/webservice/Centron.Controllers/Controllers/v1/Integrations/RmmController.cs:23-399` - kein Authorize-/... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-223 | `src/webservice/Centron.Controllers/Controllers/v1/DataExchange/RmmConnectionSettingsController.cs:26-48` -... |
| StRS-030 | SyRS-040 | SwRS-224 | `src/webservice/Centron.Controllers/Controllers/v1/Nexoware/NexowareController.cs:9-13`, `.../Nexoware/Stat... |
| StRS-036, StRS-051 | SyRS-087 | SwRS-225 | `src/webservice/Centron.Controllers/Controllers/v1/WebAccount/WebAccountController.cs:11-165` - kein Author... |
| StRS-034 | SyRS-062 | SwRS-226 | `src/webservice/Centron.Host/CentronHost.cs:280-281` - „routes.MapControllers().RequireAuthorization();" |
| StRS-035 | SyRS-064 | SwRS-227 | `src/webservice/Centron.Host/CentronHost.cs:266` - „b.UseCors(d => d.AllowAnyOrigin().AllowAnyHeader().Allo... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-228 | `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs:104-121` (`TicketAuthenticationHandl... |
| StRS-035 | SyRS-083 | SwRS-229 | `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs:147-165` (`GetClientIpAddress`) - „v... |
| StRS-034 | SyRS-062 | SwRS-230 | `src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/AttributeBasedInterceptor.cs:10... |
| StRS-043 | SyRS-080 | SwRS-231 | `src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/TryCatchInterceptor.cs:19-39` (... |
| StRS-034 | SyRS-062 | SwRS-232 | `src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Setup/ServiceInstanceProvider.cs:39` - „this... |
| StRS-011, StRS-029 | SyRS-109 | SwRS-233 | `src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs:59-79` - „bool isEnabled... |
| StRS-011, StRS-029 | SyRS-109 | SwRS-234 | `src/webservice/Centron.Host/AspNetCore/HostedServices/UpdateArticleAndMaterialGroupTaxRatesService.cs:38-6... |
| StRS-048 | SyRS-096 | SwRS-235 | `src/webservice/Centron.Host/AspNetCore/HostedServices/TelemetryUploadService.cs:82-99,183-190` - „if (!too... |
| StRS-036 | SyRS-065 | SwRS-236 | `src/webservice/Centron.Host/RealTimeServices/SecretKeyHandler.cs:11-30` - „var secretKey = authHeader[bear... |
| StRS-036 | SyRS-065 | SwRS-237 | `src/webservice/Centron.Host/RealTimeServices/NotificationsHub.cs:14` - „[Authorize(Policy = \"SecretKey\")]" |
| StRS-043 | SyRS-106 | SwRS-238 | `src/webservice/Centron.Host/AspNetCore/Logging/LoggingJwtBearerEvents.cs:11-46` - „logger.Warn(\"JWT token... |
| StRS-046 | SyRS-088 | SwRS-239 | `src/webservice/Centron.Host/HelpPage/CentronHelpPage.cs:14-30` - „if (WebServiceConfigHelper.Current.Activ... |
| StRS-042 | SyRS-081 | SwRS-240 | `src/webservice/Centron.Host/AspNetCore/WcfBridge/CentronWcfBridge.cs:35-81` - „var duplicateUris = methods... |
| StRS-009 | SyRS-006 | SwRS-241 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Transactions.cs:41-49` - „... |
| StRS-034 | SyRS-077 | SwRS-242 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.ArticleManagement.cs:88` -... |
| StRS-017 | SyRS-026 | SwRS-243 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Finances.cs:38-47` - „var ... |
| StRS-034 | SyRS-055 | SwRS-244 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Accounts.cs:595-618` - Auf... |
| StRS-034 | SyRS-062 | SwRS-245 | `src/webservice/Centron.Host/Services/ICentronRestService.cs:289-296,340-343` - „[WebInvoke(Method = \"POST... |
| StRS-026 | SyRS-034 | SwRS-246 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Helpdesk.cs:415-436` - „ig... |
| StRS-029 | SyRS-084 | SwRS-247 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Chat.cs:31-32` - „if (this... |
| StRS-031 | SyRS-079 | SwRS-248 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.RMM.cs:22-38` - „RiverDivo... |
| StRS-052 | SyRS-069 | SwRS-249 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Statistics.cs:31-45` - Auf... |
| StRS-034, StRS-043 | SyRS-080, SyRS-145 | SwRS-250 | `src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.ArtificialIntelligence.cs:... |
| StRS-053 | SyRS-072 | SwRS-251 | `src/webservice/Centron.Host/CentronHost.cs:99-110` - „this.TryLoadLicense();" / „// Progress only after th... |
| StRS-042 | SyRS-099 | SwRS-252 | `src/webservice/Centron.Host.Console/Program.cs:19-60` - „HardwareIdGenerator.GetReplaceableHardwareId = ()... |
| StRS-034, StRS-046 | SyRS-077, SyRS-082 | SwRS-253 | `src/webservice/Centron.WebServices.Core/Entities/BaseDTO.cs:5-10`; Beispiel `Entities/Accounts/AccountAddr... |
| StRS-034 | SyRS-077 | SwRS-254 | `src/webservice/Centron.WebServices.Core/RestRequests/AccessTokens/AccessTokenLogsRequest.cs:8-22` - Aufbau... |
| StRS-042 | SyRS-081 | SwRS-255 | `src/webservice/Centron.WebServices.Core/Connections/Serializer/ContentType.cs:53-64` - Auswahl der vier Au... |
| StRS-031 | SyRS-041 | SwRS-256 | `src/webservice/Centron.WebServices.Core/HttpClients/ConfigurationClient.cs:10-18,28-50` - „Task<Authentica... |
| StRS-046 | SyRS-082 | SwRS-257 | `src/webservice/Centron.WebServices.Core/Messages/StatusCode.cs:11-16` - genau drei Statuswerte |
| StRS-032 | SyRS-052 | SwRS-258 | `src/webservice/Centron.WebServices.Core/Interception/Interceptors/AuthenticateAttribute.cs:8-27` - drei Ko... |
| StRS-008 | SyRS-112 | SwRS-259 | `src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs:200-231` - „var withDiscount = rounde... |
| StRS-042 | SyRS-081 | SwRS-260 | `src/webservice/Centron.WebServices.Core/MultiTargetingWorkaround/WebInvokeAttribute.cs:1-12` - eigener Typ... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-261 | `src/webservice/c-entron.misc.ConnectionManager/Helpers/SqlHelper.cs:25-47`; `ConnectionManagerViewModel.cs... |
| StRS-053 | SyRS-072 | SwRS-262 | `src/webservice/c-entron.misc.ConnectionManager/Dialogs/LicenseViewModel.cs:20-37` - Anzeige nur bei `HasLi... |
| StRS-031 | SyRS-048 | SwRS-263 | `src/webservice/c-entron.misc.ConnectionManager/ConnectionManagerViewModel.cs:641-647` gegen `:637-641` - „... |
| StRS-042 | SyRS-110 | SwRS-264 | `src/webservice/c-entron.misc.ConnectionManager/Dialogs/AdditionalServiceViewModel.cs:443-462` - Anlage ein... |
| StRS-043 | SyRS-106 | SwRS-265 | `src/webservice/c-entron.misc.ConnectionManager/SQLServerCheckTool/SQLServerCheckToolViewModel.cs:100-155` ... |
| StRS-017, StRS-044 | SyRS-091 | SwRS-266 | `src/apis/Centron.APIs.FinAPI/RestClient/RestClientBase.cs:137-156` (`GetJsonWebToken`) - „{ "client_id", t... |
| StRS-022, StRS-047 | SyRS-092 | SwRS-267 | `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs:303-341` (`ValidateValues`) - „if (String.IsNullOrWhi... |
| StRS-045 | SyRS-093 | SwRS-268 | `src/apis/Centron.Api.Gls/CentronGlsLogic.cs:123-130` (`GetResponse`) - „if (isTest) { request.Credentials ... |
| StRS-045 | SyRS-093 | SwRS-269 | `src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs:14-27` (Konstruktor) - „var tokenBytes = Encoding.... |
| StRS-046 | SyRS-094 | SwRS-270 | `src/apis/Centron.APIs.ITscopeDataAccess/ITscopeApi.cs:23-27` (Konstruktor `ITscopeApi(string userMail, str... |
| StRS-046 | SyRS-094 | SwRS-271 | `src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs:17-21,57-68` (Konstruktor, `SendRequestAsync`) - „stri... |
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-272 | `src/apis/Centron.APIs.CopDataAccess/SoapTemplates/SoapRequestFactory.cs:22-39` (`CreateGetArticlesRequest`... |
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-273 | `src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:1033-1039` - „result.CopPassword ... |
| StRS-046 | SyRS-094 | SwRS-274 | `src/apis/Centron.APIs.EgisDataAccess/EgisApi.cs:23-37` (`CanSearchArticles`, `Create`) - „string.Equals(th... |
| StRS-048 | SyRS-096 | SwRS-275 | `src/backend/Centron.BL/DataExchange/DocuForm/DocuFormApiSettingsBL.cs:29-33`, `:56-60`, Zitat `if (this._a... |
| StRS-042 | SyRS-097 | SwRS-276 | `src/apis/Centron.APIs.FinAPI/RestClient/RestClientBase.cs:42-51` (Konstruktor, kein `Timeout`-Property ges... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-277 | `src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs:41-46`; `src/apis/Centron.Api.Gls/C... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-278 | `src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:1026` - „result.ItScopeApiKey = s... |
| — | SyRS-136 | SwRS-279 | `src/nexus/CentronNexus.Host/Program.cs:242` (Aktivierung der Lokalisierung) |
| StRS-032 | SyRS-107 | SwRS-280 | `src/nexus/CentronNexus.Host/Program.cs:170-182` - „services.ConfigureWritable<CentronWebServiceConfig>(con... |
| StRS-051 | SyRS-066 | SwRS-281 | `src/nexus/CentronNexus/Controllers/FilesController.cs:10-41` - „[Authorize]" / „_cachedDataService.AddTemp... |
| StRS-034 | SyRS-060 | SwRS-282 | `src/nexus/CentronNexus/Shared/Auth/AuthService.cs:49-71` - „// We don't care about the web-service error i... |
| StRS-007 | SyRS-070 | SwRS-283 | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs:33-63`; `src/nexus/CentronNexus/Shared/Auth/Tick... |
| StRS-050 | SyRS-086 | SwRS-284 | `src/nexus/CentronNexus/Shared/CustomMiddleware/UseOutlookCookiePolicyMiddleware.cs:17-25`, Klasse `Outlook... |
| StRS-034, StRS-053 | SyRS-062, SyRS-071 | SwRS-285 | `src/nexus/CentronNexus/Shared/Authorization/CentronAuthorization.cs:21`, `:34`, `:39`, `:100-108`, `:23-32` |
| StRS-034, StRS-049 | SyRS-060, SyRS-061 | SwRS-286 | `src/nexus/CentronNexus/Shared/Authorization/PortAuthorization.cs:22-45`, `:50-71` - „if (http?.Connection.... |
| StRS-026 | SyRS-033 | SwRS-287 | `src/nexus/CentronNexus/Shared/Services/TicketCacheService.cs:45`, `:59` |
| StRS-034 | SyRS-076 | SwRS-288 | `src/nexus/CentronNexus/Shared/Layouts/` (sieben Layouts); Zuordnung `src/nexus/CentronNexus/Shared/Auth/Au... |
| StRS-001 | SyRS-138, SyRS-139 | SwRS-289 | `src/nexus/CentronNexus/Shared/GlobalSearches/GlobalSearch.razor:100-124`, `:96`, `:107-111` - „this._searc... |
| StRS-034 | SyRS-076 | SwRS-290 | `src/nexus/CentronNexus/Shared/Receipt/CalculatedPrices.razor:8`, `:26` - „var grossPrice = this.PricesByTa... |
| StRS-032 | SyRS-107 | SwRS-291 | `src/nexus/CentronNexus/Shared/SetupWizard/{SetupWizard,SetupWizardWebService,SetupWizardSecretKey,SetupWiz... |
| StRS-043 | SyRS-106 | SwRS-292 | `src/nexus/CentronNexus/Shared/Diagnostics/_Imports.razor:5-6` (zwei Attribute: `AuthorizeLoginUser` und `A... |
| StRS-036, StRS-051 | SyRS-087 | SwRS-293 | `src/nexus/CentronNexus/DocumentSigning/DocumentSigningPage.razor:365-380`, `:521-527` - „private bool CanA... |
| StRS-036, StRS-051 | SyRS-087 | SwRS-294 | `src/nexus/CentronNexus/DocumentSigning/DocumentSigningPage.razor:1-3`; `Office/SharedDocumentPage.razor:1-... |
| StRS-053 | SyRS-071 | SwRS-295 | `src/nexus/CentronNexus/Management/TaskManagement/_imports.razor:5` (Lizenzattribut `ServiceBoardWebDev`) |
| StRS-035 | SyRS-064 | SwRS-296 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormFieldEditPopup.razor:206-226` |
| StRS-034 | SyRS-057 | SwRS-297 | `src/nexus/CentronNexus/Management/WebAccount/Dialog/WebAccountEditDialog.razor:326-342`, `:353-366` - „if ... |
| StRS-034 | SyRS-068 | SwRS-298 | `src/nexus/CentronNexus/Management/Management.razor:13-35`, Methode `protected override async Task OnInitia... |
| StRS-034 | SyRS-068 | SwRS-299 | `src/nexus/CentronNexus/ProductionOrderManagement/Pages/ProductionOrderOverView.razor:1`, `:138` - „private... |
| StRS-026 | SyRS-034 | SwRS-300 | `src/nexus/CentronNexus/ServiceBoard/Shared/Common/TicketHeader.razor:289-305` - „<AuthorizeRightView Right... |
| StRS-007 | SyRS-070 | SwRS-301 | `src/nexus/CentronNexus/ServiceBoard/CachedTicketList/CachedTicketListPage.razor:1-2`, `:2135-2139` - „_onl... |
| StRS-050 | SyRS-086 | SwRS-302 | `src/nexus/CentronNexus/ServiceBoard/_Imports.razor:3-5`, Zitat `@attribute [AuthorizeLoginUser] @attribute... |
| StRS-051 | SyRS-066 | SwRS-303 | `src/nexus/CentronNexus/ServiceBoard/TicketDocuments/TicketDocumentsPage.razor:22-26`, Zitat `<DocumentsLis... |
| StRS-011, StRS-027 | SyRS-021 | SwRS-304 | `src/nexus/CentronNexus/ServiceBoard/Timerecords/Components/TimerDetails.razor:1327-1344` - „if (_helpdeskS... |
| StRS-026 | SyRS-144 | SwRS-305 | `src/nexus/CentronNexus/ServiceBoard/Scheduler/SchedulerPage.razor:1-4` - „[AuthorizeRightId(UserRightsCons... |
| StRS-035 | SyRS-064 | SwRS-306 | `src/nexus/CentronNexus/ServiceBoard/TicketWebForms/PublicWebFormPage.razor` (`LoadWebForm`) - „var isAvail... |
| StRS-035 | SyRS-064 | SwRS-307 | `src/nexus/CentronNexus/ServiceBoard/TicketWebForms/PublicWebFormPage.razor` (`GenerateNewCaptcha`/`SubmitF... |
| StRS-034 | SyRS-076 | SwRS-308 | je `@page` in `src/nexus/CentronNexus/ServiceBoard/Customers/**/*.razor:1` |
| StRS-027, StRS-034 | SyRS-076, SyRS-122 | SwRS-309 | `src/nexus/CentronNexus/ServiceBoard/MyDay/MyDayService.cs:41-69` |
| StRS-029 | SyRS-084 | SwRS-310 | `src/nexus/CentronNexus/ServiceBoard/PhoneCalls/CallsPage.razor:1-7` (gesamte Datei, gesamtes Modul) |
| StRS-033 | SyRS-073 | SwRS-311 | `src/nexus/CentronNexus/ServiceBoard/PasswordManager/PasswordManager.razor:1-7` (gesamte Datei, gesamtes Mo... |
| StRS-034, StRS-049 | SyRS-060, SyRS-061 | SwRS-312 | `src/nexus/CentronNexus/ServiceBoard/_Imports.razor:3-7` (drei Autorisierungsattribute und Layout) |
| StRS-032 | SyRS-107 | SwRS-313 | `src/nexus/CentronNexus/Settings/ServiceBoard/RequiredFields/RequiredFields.razor:159-184`, `:198-217` |
| StRS-050 | SyRS-140 | SwRS-314 | `src/nexus/CentronNexus/Settings/MailTemplates/MailTemplates.razor:114`, `:510`, `:540`, `:549`, `:557` |
| StRS-031 | SyRS-041 | SwRS-315 | `src/nexus/CentronNexus/Settings/_Imports.razor:3`, Zitat `@attribute [AuthorizeRightId(UserRightsConst.Adm... |
| StRS-043 | SyRS-080 | SwRS-316 | `src/nexus/CentronNexus/Utils/AsyncDisposableAction.cs:11-21` (`Guard.NotNull`, ungekapselte Ausführung der... |
| StRS-049 | SyRS-019 | SwRS-317 | `src/nexus/CentronNexus/WebCart/Components/WebCartClearance.razor:33`, `:42`, `:67`, `:92`, `:101`, `:107`,... |
| StRS-034, StRS-049 | SyRS-061 | SwRS-318 | `src/nexus/CentronNexus/WebCart/_Imports.razor:3-4` – Begründung: durchsetzende Anmeldetyp- und Portbindung... |
| StRS-036, StRS-051 | SyRS-087 | SwRS-319 | `src/nexus/CentronNexus/WebOffer/WebReceiptOverview.razor` (`LoadReceipt`) – Prüfung auf `WebReceiptState` ... |
| StRS-036 | SyRS-063 | SwRS-320 | `src/nexus/CentronNexus/WebOffer/WebReceiptOverview.razor:582`, `:836`, `:874`, `:939`, `:959`, `:1095`, `:... |
| StRS-032 | SyRS-107 | SwRS-321 | `src/nexus/CentronNexus.Host/Program.cs:383-430` – Begründung: durchsetzende Stelle der Middleware-Reihenfo... |
| StRS-050 | SyRS-086 | SwRS-322 | `src/nexus/CentronNexus.OutlookAddIn/_Imports.razor:8`, `:23` – Lizenzattribut und Layout, kein Login-Typ-A... |
| StRS-051 | SyRS-066 | SwRS-323 | `src/nexus/CentronNexus.OutlookAddIn/Model/BlacklistedDirectories.cs` – acht deutschsprachige Namenskonstan... |
| StRS-050 | SyRS-086 | SwRS-324 | `src/nexus/CentronNexus.OutlookAddIn/Customer/CustomerTab.razor:113`, `:295`, `:298` – Begründung: durchset... |
| StRS-050 | SyRS-086 | SwRS-325 | `src/nexus/CentronNexus.OutlookAddIn/Belege/ReceiptSearchTab.razor:189`, `:294-297` – „GetReceiptByI3D(rece... |
| StRS-050 | SyRS-086 | SwRS-326 | `src/nexus/CentronNexus.OutlookAddIn/Ticket/ManageTicketTab.razor:28`, `:50`, `:218`, `:244`, `:809` – Über... |
| StRS-051 | SyRS-066 | SwRS-327 | `src/nexus/CentronNexus.OutlookAddIn/Document/DocumentsTab.razor:239-245` – „directory.ChildrenDirectories.... |
| StRS-050 | SyRS-086 | SwRS-328 | `src/nexus/CentronNexus.OutlookAddIn/CRM/CrmActivityPage.razor:1`, `:8-10`, `:26-31` – Rendern von `CrmActi... |
| StRS-050 | SyRS-086 | SwRS-329 | `src/nexus/CentronNexus.OutlookAddIn/Model/OfficeDialogUrl.cs` (`WithAddInContext`) – Begründung: durchsetz... |
| StRS-038, StRS-041 | SyRS-102, SyRS-103 | SwRS-330 | `azure-blazor/security-pipeline.yaml:1-9` – „trigger: please_dont_get_triggered" mit Zeitplan 00:00 auf `ma... |
| StRS-038 | SyRS-102 | SwRS-331 | `scripts/Centron.Scripts/Program.cs:18-325` - `Target("default", ["create-nuget-packages", "build-installer... |
| StRS-039 | SyRS-100 | SwRS-332 | `scripts/Centron.Scripts/Program.cs:58-73` |
| StRS-038 | SyRS-102 | SwRS-333 | `scripts/Scripts/Program.cs:30-56` |
| StRS-039 | SyRS-100 | SwRS-334 | `scripts/Centron.Scripts/SignHelper.cs:8-24` - `RunSignTool(/*certificateFilePath, certificatePassword, */t... |
| StRS-042 | SyRS-099 | SwRS-335 | `deployment/WixSharpInstaller/Program.cs:19-58` - `AllowSameVersionUpgrades = true` mit Begründungskommentar |
| StRS-042 | SyRS-099 | SwRS-336 | `deployment/centron/CentronSetupProject/Product.wxs:5-11` - `REINSTALLMODE = amus`, `bind.FileVersion`, Upg... |
| StRS-042 | SyRS-099 | SwRS-337 | `deployment/centron/CentronSetupProject/Product.wxs:25-26` - `<WixVariable Id="WixUIBannerBmp" Value="Image... |
| StRS-042 | SyRS-099 | SwRS-338 | `deployment/centron/WebServiceSetupProject/Product.wxs:13` - per-Machine-Installationsumfang |
| StRS-042 | SyRS-099 | SwRS-339 | `deployment/centron/WebServiceSetupProject/Product.wxs:19-20` - Banner- und Hintergrundbindung |
| StRS-038 | SyRS-102 | SwRS-340 | `deployment/riverbird/version.txt` (gesamter Inhalt `11.1.2211`) |
| StRS-042 | SyRS-101 | SwRS-341 | `docker/Dockerfile:1-31` - `ARG dx_license` und `echo "$dx_license" > $HOME/.config/DevExpress/DevExpress_L... |
| StRS-042 | SyRS-101 | SwRS-342 | `docker/c-entron-api/Dockerfile:2-11` - `USER root` und `#ENTRYPOINT [ "/app/Centron.Host.Console" ]` |
| StRS-042 | SyRS-101 | SwRS-343 | `docker/c-entron-webservice/Dockerfile:8-19` - `sed`-Ersetzung mit Warnkommentar |
| StRS-040 | SyRS-105 | SwRS-344 | `docker/c-entron-regression-tests-db/Dockerfile` (gesamte Datei) |
| StRS-042 | SyRS-101 | SwRS-345 | `docker/compose/compose.yaml:2-54` - Dienstdefinitionen, Startabhängigkeiten, Netzwerkzuordnung |
| StRS-032 | SyRS-107 | SwRS-346 | `docker/compose/compose.yaml:7` - `MSSQL_SA_PASSWORD: SA!password` |
| StRS-031, StRS-032, StRS-033, StRS-038, StRS-043 | SyRS-074, SyRS-080 | SwRS-347 | `docker/compose/appsettings.Production.json:24-41` - `"Notifications": { "SecretKey": "J+ImFI4YsgTyIpOk/ixa... |
| StRS-042 | SyRS-101 | SwRS-348 | `docker/deploy/compose.yaml:3-47` gegen `docker/compose/compose.yaml:3-50` - abweichende Images, leere `HAR... |
| StRS-038 | SyRS-102 | SwRS-349 | `azure/build-pipeline.yml:32-44` - `failTaskOnFailedTests: true` |
| StRS-038 | SyRS-102 | SwRS-350 | `azure/build-pipeline2.yml:22-55` - Template-Einbindungen |
| StRS-040 | SyRS-104 | SwRS-351 | `azure/tests-pipeline.yml:63-75` - gepinntes Datenbankimage und Bereitschaftsprüfung mit 30-Sekunden-Grenze |
| StRS-042 | SyRS-101 | SwRS-352 | `azure/docker-pipeline.yml:30-70` - Tag- und Build-Arg-Definition der Push-Schritte |
| StRS-041 | SyRS-103 | SwRS-353 | `azure-blazor/security-pipeline.yaml:1-8` - `trigger: - please_dont_get_triggered` und `cron: '0 0 * * *'` |
| StRS-046 | SyRS-088 | SwRS-354 | `docs/README.md:50` - `- [Contract Billing RMM Article Logic](reference/receipts/contract-billing-rmm-artic... |
| StRS-046 | SyRS-088 | SwRS-355 | — |
| StRS-038 | — | SwRS-356 | `version.json` |
| StRS-042 | SyRS-099 | SwRS-357 | `src/backend/Centron.Entities/Entities/BaseEntity.cs:6-14`, Zitat `public class BaseEntity : PersistedEntit... |
| StRS-042 | SyRS-099 | SwRS-358 | `tests/Centron.Tests.EndToEnd/Infrastructure/Database.cs:68-151` (Skript-Engine mit `currentVersionOverride... |
| StRS-037 | SyRS-075 | SwRS-359 | `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/ScriptHelpers.cs:212-241` (`AddTableIfNotExists`) |
| StRS-044, StRS-045, StRS-046 | SyRS-090 | SwRS-360 | `src/webservice/Centron.Host/AspNetCore/HostedServices/EdiDownloadService.cs:21-23` und `:35-37`, Zitat `aw... |
| StRS-005 | SyRS-038 | SwRS-361 | — |
| — | SyRS-141 | SwRS-362 | — |
| StRS-022, StRS-047 | SyRS-092 | SwRS-363 | — |
| StRS-042 | SyRS-099 | SwRS-364 | — |
| StRS-034 | SyRS-055 | SwRS-365 | `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/ScriptHelpers.cs:93-125` (`AddRightIfNotExists... |
| StRS-042 | SyRS-108 | SwRS-366 | `scripts/Centron.Scripts/Program.cs:277` - Target `build-web-service-linux` |
| — | SyRS-136 | SwRS-367 | — |
| StRS-011, StRS-029 | SyRS-109 | SwRS-368 | `src/webservice/Centron.Host/AspNetCore/HostedServices/DataQualityService.cs:181-184`, Zitat `return TimeSp... |
| StRS-040 | SyRS-105 | SwRS-369 | `tests/Centron.Tests.EndToEnd/Infrastructure/EndToEndTest.cs:21-27`, `:67-73` - Snapshot-Rücksetzung im Kon... |
| StRS-040 | SyRS-105 | SwRS-370 | `tests/Centron.Tests.EndToEnd/Infrastructure/Verifier/CentronVerifier.cs:33`, `:98-104` - Vergleich gegen E... |
| StRS-040 | SyRS-105 | SwRS-371 | `tests/Centron.Tests.EndToEnd/TicketTests/Ticket103420/Ticket103420Test.cs` |
| StRS-032 | SyRS-051 | SwRS-372 | `tests/backend/Centron.Tests.BL/Administration/AccessTokens/AccessTokenWebServiceBLTest.cs:47-72`, `:194-21... |
| StRS-046 | SyRS-094 | SwRS-373 | `tests/apis/Centron.APIs.EgisDataAccess.Tests/EgisApiSearchRequirementsTests.cs:30-36` - Prüfung von `CanSe... |
| StRS-008 | SyRS-113 | SwRS-374 | `tests/shared/Centron.Tests.Controls/PositionGrid/ReverseChargeThresholdCalculatorTests.cs:14-73` - Ein- un... |
| StRS-034 | SyRS-077 | SwRS-375 | `tests/Centron.Tests.Integration/IntegrationTest.cs:13-37` - Login und Paging-Prüfung über `ICentronRestSer... |
| StRS-034 | SyRS-062 | SwRS-376 | `tests/PlaywrightTests/Utilities/Auth.cs:9-37` - Anmeldung mit `admin` / `1` gegen `http://localhost:8050/a... |
| StRS-038 | SyRS-102 | SwRS-377 | `Centron.sln:6-26` - Lösungsordner und WiX-Projekttyp-GUID |
| StRS-041 | SyRS-103 | SwRS-378 | `Directory.Build.props:6-24` - `TreatWarningsAsErrors=true` und `<WarningsNotAsErrors>...;NU1901;NU1902;NU1... |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-379 | `nuget.config:6` - `<add key="DevExpress Online NuGet Server" value="https://nuget.devexpress.com/iani6kju4... |
| StRS-035 | SyRS-054 | SwRS-380 | — |
| StRS-039 | SyRS-100 | SwRS-381 | `version.json` - Basisversion, `assemblyVersion` bis zur Revision, Cloud-Build-Buildnummer, Releasemuster |
| StRS-038 | SyRS-102 | SwRS-382 | `nuget.config:8` - `<add key="Nugets Directory" value="./nugets" />` |
| StRS-041 | SyRS-103 | SwRS-383 | `src/centron/Centron.WPF.UI/Centron.WPF.UI.csproj:15-23` - `<Reference ... HintPath>` auf `assemblies/` |
| StRS-042 | SyRS-099 | SwRS-384 | `SSMS_DB_SCHEMA.sql:1-12` - `CREATE DATABASE [CentronVOED2]` mit absoluten Dateipfaden und `Script Date: 11... |
| StRS-034 | SyRS-055 | SwRS-385 | — |
| StRS-039 | SyRS-100 | SwRS-386 | `.github/workflows/build.yml:313-334` - Prüfung `Get-AuthenticodeSignature(...).Status` ungleich `Valid` mi... |
| StRS-038 | SyRS-102 | SwRS-387 | `.github/workflows/build.yml:367-431` - Zweigbedingung, Umgebung `SoftwareBuilds`, `id-token: write` |
| StRS-038 | SyRS-102 | SwRS-388 | `.github/workflows/build.yml:367-431` - Zweigbedingung und Aufruf des wiederverwendbaren Workflows mit `id-... |
| StRS-038 | SyRS-102 | SwRS-389 | `.github/workflows/build.yml:367-431` - Zweigbedingung, Umgebung und OIDC-Berechtigung des Nexus-Upload-Jobs |
| StRS-040 | SyRS-104 | SwRS-390 | `.github/workflows/tests.yml:34-52` - Matrixdefinition mit `fail-fast: false` |
| StRS-040 | SyRS-105 | SwRS-391 | `.github/workflows/regression-tests.yml:51-87` - Suchmuster und `throw` bei Treffer |
| StRS-038 | SyRS-102 | SwRS-392 | `.github/workflows/cleanup-pr-artifacts.yml:3-6`, `:8-10` - Auslöser `pull_request_target`, `types: closed` |
| StRS-040 | SyRS-105 | SwRS-393 | `.vscode/launch.json` - Pfad `bin/Debug/net8.0-windows/c-entron 2.0.dll` |
| StRS-042 | SyRS-148 | SwRS-394 | `.editorconfig:16-31` - Schweregrad `warning` nur für die Feldbenennungsregel, `suggestion` für die übrigen |
| StRS-033 | SyRS-073 | SwRS-395 | `Centron.sln:19` - Listung von `StrongNamingKeyFile.snk` als Solution Item |
| StRS-038 | SyRS-102 | SwRS-396 | `.gitattributes:4` - `* text=auto eol=lf` |
| StRS-042 | SyRS-148 | SwRS-397 | `Centron.sln.DotSettings` (einziger Eintrag: Registrierung von `Centron.Controls.Annotations`) |
| StRS-042 | SyRS-101 | SwRS-398 | `.dockerignore` (gesamte Datei, 14 Zeilen mit `./src/centron/` und `**/app.config`) |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-399 | `Centron.Api.docuFORM/Helper/OAuthHelper.cs:11-39` (`GenerateRandomBase64String`, `GenerateCodeChallenge`) |
| StRS-031, StRS-032, StRS-033, StRS-038 | SyRS-074 | SwRS-400 | `src/webservice/Centron.Controllers/Controllers/v1/DataExchange/DocuFormApiSettingsController.cs:26-39` (`G... |
| StRS-004 | SyRS-013 | SwRS-401 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Klasse ReceiptBL, Methode CheckIfCustomerLimitIsReached... |
| StRS-004 | SyRS-013 | SwRS-402 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Klasse ReceiptBL, Methode CheckIfCustomerLimitIsReached... |
| StRS-004 | SyRS-013 | SwRS-403 | src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs, Zeilen 315-316: `bool TakesPlaceInLimitCalc... |
| StRS-016 | SyRS-022 | SwRS-404 | `src/centron/Centron.WPF.UI/Modules/Finances/Dunning/Pages/DunningCustomerSelectionViewModel.cs:466-469` (`... |
## 2 Vorwärtssicht: StRS nach unten
| StRS-ID | Titel | abgeleitete SyRS | abgeleitete SwRS (unmittelbar) |
|---|---|---|---|
| StRS-001 | Geschäftspartner als führende Kunden- und Lieferantenakte | SyRS-036, SyRS-132, SyRS-138 | SwRS-038 |
| StRS-002 | [HYPOTHESE] Dublettenfreiheit im Geschäftspartnerstamm | SyRS-036 | — |
| StRS-003 | Kundensperre und mahnstufenabhängige Belegsperre | SyRS-014, SyRS-059 | SwRS-097 |
| StRS-004 | Kreditlimitüberwachung im Kundengeschäft | SyRS-013 | SwRS-401, SwRS-402, SwRS-403 |
| StRS-005 | Nachvollziehbare Preis- und Konditionsfindung im Verkauf | SyRS-015, SyRS-038, SyRS-123 | SwRS-005 |
| StRS-006 | Durchgängige Belegkette vom Angebot bis zur Gutschrift mit Mengenbindung | SyRS-001, SyRS-002, SyRS-004, SyRS-005, SyRS-114 | SwRS-002 |
| StRS-007 | Eindeutige Belegnummern je Geschäftsvorfall und Filiale | SyRS-007, SyRS-008, SyRS-070 | SwRS-004 |
| StRS-008 | Rechnungsstellung mit zum Belegdatum gültigem Steuersatz | SyRS-111, SyRS-112, SyRS-113 | SwRS-033 |
| StRS-009 | Revisionssichere Rechnungsstornierung und Festschreibung | SyRS-006, SyRS-009, SyRS-010, SyRS-011 | SwRS-012 |
| StRS-010 | Anzahlungsrechnung und Verrechnung in der Schlussrechnung | SyRS-016 | SwRS-017 |
| StRS-011 | Abrechnung wiederkehrender Vertragsleistungen mit Kontingentbewirtschaftung | SyRS-020, SyRS-021, SyRS-109 | SwRS-022, SwRS-023 |
| StRS-012 | Vertragslaufzeit, Verlängerung, Kündigung und Wiedervorlage | SyRS-020 | SwRS-024, SwRS-025 |
| StRS-013 | Zählerbasierte Abrechnung technischer Anlagen auf einheitlichem Anlagenbestand | SyRS-037 | SwRS-026, SwRS-027 |
| StRS-014 | Vertriebsprovision aus Beleggeschäft | SyRS-116 | SwRS-007 |
| StRS-015 | Kassenbuchführung für Bargeschäfte | SyRS-012, SyRS-115 | SwRS-043 |
| StRS-016 | Forderungsmanagement mit gestuftem Mahnverfahren | SyRS-022, SyRS-023 | SwRS-018 |
| StRS-017 | Ausgleich offener Forderungen aus elektronischen Kontoauszügen | SyRS-024, SyRS-025, SyRS-026, SyRS-091 | SwRS-041 |
| StRS-018 | [HYPOTHESE] Skontogewährung beim Ausgleich offener Forderungen | SyRS-027 | — |
| StRS-019 | Forderungseinzug per SEPA-Lastschrift auf Grundlage erteilter Mandate | SyRS-117, SyRS-118 | SwRS-161 |
| StRS-020 | Erstattung von Reisekosten und verauslagten Beträgen an Mitarbeiter | SyRS-121 | SwRS-123 |
| StRS-021 | Übergabe der Geschäftsvorfälle an die Finanzbuchhaltung mit Exportnachweis | SyRS-018, SyRS-039 | SwRS-044 |
| StRS-022 | Elektronische Rechnungsstellung im geforderten Rechnungsformat | SyRS-092 | SwRS-059 |
| StRS-023 | Bedarfsgerechte Beschaffung über Bestellvorschläge | SyRS-031 | SwRS-119 |
| StRS-024 | Lieferantenbelegkette und Fortschreibung des Einstandspreises | SyRS-003, SyRS-032, SyRS-130, SyRS-149 | SwRS-035 |
| StRS-025 | Lagerbestandsführung, Seriennummernverfolgung, Kommissionierung und Inventur | SyRS-017, SyRS-028, SyRS-029, SyRS-030, SyRS-120, SyRS-134 | SwRS-034, SwRS-108 |
| StRS-026 | Servicegeschäft: Ticketbearbeitung mit vereinbarter Reaktionszeit und Eskalation | SyRS-033, SyRS-034, SyRS-124, SyRS-144 | SwRS-030 |
| StRS-027 | Erfassung erbrachter Serviceleistungen und deren Abrechnung | SyRS-021, SyRS-122 | SwRS-124 |
| StRS-028 | Reklamations- und Werkstattabwicklung zum Servicevorgang | SyRS-035 | SwRS-134 |
| StRS-029 | Projekt- und Aufgabensteuerung mit Wiedervorlagen und Vertretungsregelung | SyRS-084, SyRS-109, SyRS-125, SyRS-143 | SwRS-055 |
| StRS-030 | Betriebswirtschaftliche Auswertung für Geschäftsleitung und Führungskräfte | SyRS-040, SyRS-067, SyRS-133 | SwRS-045 |
| StRS-031 | Einheitliche, nachvollziehbare Verwaltung von Zugangsdaten und Geheimnissen | SyRS-041, SyRS-042, SyRS-046, SyRS-047, SyRS-048, SyRS-074, SyRS-079, SyRS-089, SyRS-146 | SwRS-216 |
| StRS-032 | Geschützte Ablage der Zugangsdaten zu angebundenen Fremddiensten | SyRS-051, SyRS-052, SyRS-074, SyRS-107 | SwRS-084 |
| StRS-033 | Keine Herausgabe hinterlegter Zugangsdaten an Bedienoberflächen | SyRS-043, SyRS-045, SyRS-073, SyRS-074 | SwRS-400 |
| StRS-034 | Wirksame Trennung von Mitarbeiter- und Kundenzugang im Auslieferungszustand | SyRS-049, SyRS-053, SyRS-055, SyRS-056, SyRS-057, SyRS-060, SyRS-061, SyRS-062, SyRS-068, SyRS-076, SyRS-077, SyRS-078, SyRS-085, SyRS-145 | SwRS-226 |
| StRS-035 | Missbrauchsschutz für anmeldefrei erreichbare Zugänge | SyRS-044, SyRS-054, SyRS-064, SyRS-083 | SwRS-307 |
| StRS-036 | Befristete und nachvollziehbare Verweislinks für Dokumente und Angebote | SyRS-058, SyRS-063, SyRS-065, SyRS-087, SyRS-129 | SwRS-049 |
| StRS-037 | Nachvollziehbarkeit sicherheitsrelevanter Vorgänge | SyRS-050, SyRS-075 | SwRS-047 |
| StRS-038 | Eine verbindliche Kette für Erstellung und Auslieferung der Software | SyRS-074, SyRS-102 | SwRS-356 |
| StRS-039 | Nachweisbare Signatur der ausgelieferten Programmdateien | SyRS-100 | — |
| StRS-040 | Ausführung aller vorhandenen Testbestände in der verbindlichen Kette | SyRS-104, SyRS-105 | — |
| StRS-041 | Sicherheitsanalyse als Voraussetzung der Freigabe | SyRS-103 | — |
| StRS-042 | Betreibbare und aktualisierbare Installation | SyRS-081, SyRS-097, SyRS-099, SyRS-101, SyRS-108, SyRS-110, SyRS-148 | — |
| StRS-043 | Betriebsdiagnose ohne Preisgabe von Sitzungs- und Zugangsdaten | SyRS-080, SyRS-106 | SwRS-238 |
| StRS-044 | Anbindung des Zahlungsverkehrs an das Bankkonto | SyRS-090, SyRS-091 | SwRS-266 |
| StRS-045 | Anbindung von Versanddienstleistern für die Sendungsabwicklung | SyRS-090, SyRS-093 | SwRS-268 |
| StRS-046 | Anbindung von Lieferanten- und Produktdatenquellen für die Beschaffung | SyRS-082, SyRS-088, SyRS-090, SyRS-094, SyRS-095, SyRS-098, SyRS-128 | SwRS-373 |
| StRS-047 | Elektronischer Austausch von Rechnungs- und Buchhaltungsdaten | SyRS-092 | SwRS-059, SwRS-363 |
| StRS-048 | Übernahme von Gerätezählerständen für die nutzungsabhängige Abrechnung | SyRS-096 | SwRS-275 |
| StRS-049 | Eigener Zugang für Kunden und Servicepartner | SyRS-019, SyRS-061 | SwRS-317 |
| StRS-050 | Zusammenarbeit mit der Büroanwendung für Vorgänge aus der E-Mail heraus | SyRS-086, SyRS-140, SyRS-142 | SwRS-324 |
| StRS-051 | Geschützte Ablage von Kunden- und Personaldokumenten | SyRS-066, SyRS-087, SyRS-131 | SwRS-062, SwRS-197 |
| StRS-052 | [HYPOTHESE] Getrennte Datenhaltung mehrerer Mandanten | SyRS-007, SyRS-069 | SwRS-052, SwRS-249 |
| StRS-053 | Abrechnung des Systems nach lizenzierten Benutzern und Funktionsbausteinen | SyRS-071, SyRS-072 | SwRS-206 |
## 3 Rückwärts- und Vorwärtssicht: SyRS
| SyRS-ID | Titel | begründende StRS | umsetzende SwRS |
|---|---|---|---|
| SyRS-001 | Belegartenkatalog und Trennung von Kunden- und Lieferantenbelegen | StRS-006 | SwRS-001, SwRS-002 |
| SyRS-002 | Belegkette der Kundenseite vom Angebot bis zur Gutschrift | StRS-006 | SwRS-001, SwRS-002 |
| SyRS-003 | Belegkette der Lieferantenseite als lineare Folge | StRS-024 | SwRS-117 |
| SyRS-004 | Prüfung der Weiterverarbeitung und Verbot des Mischens von Kunden- und Lieferantenbelegen | StRS-006 | SwRS-002, SwRS-010 |
| SyRS-005 | Belegzustandsmodell mit drei Zuständen ohne zentrale Zustandsmaschine | StRS-006 | SwRS-002, SwRS-012, SwRS-013 |
| SyRS-006 | Belegversionierung statt Löschung | StRS-009 | SwRS-241 |
| SyRS-007 | Vergabe der Belegnummer aus einem belegart- und filialbezogenen Nummernkreis | StRS-007, StRS-052 | SwRS-003, SwRS-004, SwRS-008, SwRS-011, SwRS-052 |
| SyRS-008 | Eindeutigkeit der Belegnummer — derzeit nur durch optimistische Wiederholschleife hergestellt | StRS-007 | SwRS-004, SwRS-118 |
| SyRS-009 | Vorbedingungen für das Stornieren einer Rechnung | StRS-009 | SwRS-012, SwRS-013 |
| SyRS-010 | Festschreibung einer Rechnung als unumkehrbarer Zustand | StRS-009 | — |
| SyRS-011 | Änderungssperre für festgeschriebene Rechnungen — derzeit nur im Windows-Client wirksam | StRS-009 | SwRS-082 |
| SyRS-012 | Barrechnungen sind von der Weiterverarbeitung ausgenommen — Ausnahme wirkt nur in der Auswahl | StRS-015 | — |
| SyRS-013 | Kreditlimitprüfung beim Speichern eines Kundenbelegs | StRS-004 | SwRS-401, SwRS-402, SwRS-403 |
| SyRS-014 | Mahnstufenabhängige Sperre für neue Kundenbelege | StRS-003 | — |
| SyRS-015 | Mindestpreisprüfung mit Überstimmung durch Zweitanmeldung | StRS-005 | — |
| SyRS-016 | Anzahlungsrechnung und Verrechnung in der Schlussrechnung | StRS-010 | SwRS-017 |
| SyRS-017 | Bestandswirkung ist an Lieferschein, Abholschein und Gutschrift gebunden | StRS-025 | SwRS-020, SwRS-034, SwRS-112 |
| SyRS-018 | Buchhaltungsexport und dauerhafte Exportmarkierung des Belegs | StRS-021 | SwRS-044, SwRS-088, SwRS-159, SwRS-160, SwRS-163 |
| SyRS-019 | Freigabekette des Web-Warenkorbs als Zustandsmaschine | StRS-049 | SwRS-009, SwRS-317 |
| SyRS-020 | Vertragsrechnungen entstehen ausschließlich über das Abrechnungszentrum | StRS-011, StRS-012 | SwRS-022, SwRS-024, SwRS-025, SwRS-094 |
| SyRS-021 | Vertragskontingente, Abrechnungsintervalle und Abrechnungsbedarf | StRS-011, StRS-027 | SwRS-019, SwRS-022, SwRS-023, SwRS-093, SwRS-095, SwRS-169, SwRS-171, SwRS-304 |
| SyRS-022 | Mahnstufenmodell und schrittweise Fortschreibung im Mahnlauf | StRS-016 | SwRS-018, SwRS-097, SwRS-404 |
| SyRS-023 | Offener Mahnbetrag, Zahlungstoleranz in Tagen und Mahnstopp | StRS-016 | SwRS-018, SwRS-098 |
| SyRS-024 | Dreistufige Zuordnung einer Kontobewegung zu offenen Rechnungen | StRS-017 | SwRS-040, SwRS-041, SwRS-042, SwRS-080, SwRS-166 |
| SyRS-025 | Zahlungstoleranz — dieselbe Regel mit zwei verschiedenen Vergleichsoperatoren | StRS-017 | SwRS-040 |
| SyRS-026 | Buchung eines Zahlungsbetrags, Rücklastschrift und Schutz vor Doppelbuchung | StRS-017 | SwRS-099, SwRS-243 |
| SyRS-027 | [HYPOTHESE] Skontoabzug beim Abgleich einer Zahlung mit einem offenen Posten | StRS-018 | SwRS-146 |
| SyRS-028 | Zustandsmodell der Inventur mit zwei getrennten Zustandssträngen | StRS-025 | — |
| SyRS-029 | Lagerabschluss der Inventur — abgeschlossenes Lager nimmt keine weitere Zählung auf | StRS-025 | SwRS-108 |
| SyRS-030 | Seriennummernzustand als Träger der Stückverfolgung und der Inventurdifferenz | StRS-025 | SwRS-090, SwRS-091, SwRS-114 |
| SyRS-031 | Ermittlung des Nachbestellbedarfs im Bestellvorschlag | StRS-023 | SwRS-036, SwRS-119, SwRS-120 |
| SyRS-032 | Lieferantenbelege sind ohne Rechteprüfung änderbar | StRS-024 | SwRS-021, SwRS-217 |
| SyRS-033 | Ticketstatus als datengetriebenes Modell mit genau einem Abschlussstatus | StRS-026 | SwRS-030, SwRS-129, SwRS-144, SwRS-287 |
| SyRS-034 | Vorbedingungen für den Abschluss eines Tickets | StRS-026 | SwRS-064, SwRS-124, SwRS-131, SwRS-132, SwRS-246, SwRS-300 |
| SyRS-035 | RMA-Vorgang je Ticket genau einmal, mit zwei getrennten Zustandsachsen je Position | StRS-028 | SwRS-134 |
| SyRS-036 | Kunden- und Adressstamm: Pflichtanschrift, Sperrmerkmale und Löschschutz | StRS-001, StRS-002 | SwRS-038, SwRS-071, SwRS-073, SwRS-074 |
| SyRS-037 | Stammblatt als Geräteakte mit monoton steigendem Zählerstand | StRS-013 | SwRS-026, SwRS-027, SwRS-100, SwRS-104 |
| SyRS-038 | Preisfindung als Kaskade mit fester Rangfolge | StRS-005 | SwRS-005, SwRS-006, SwRS-031, SwRS-032, SwRS-077, SwRS-107, SwRS-110, SwRS-188, SwRS-201, SwRS-361 |
| SyRS-039 | Kontenrahmen und Kontenfindung — Eindeutigkeitsregeln nur clientseitig durchgesetzt | StRS-021 | SwRS-109, SwRS-115 |
| SyRS-040 | [HYPOTHESE] Rechteprüfung beim Erzeugen und Verwalten von Berichten | StRS-030 | SwRS-045, SwRS-065, SwRS-101, SwRS-127, SwRS-158, SwRS-167, SwRS-173, SwRS-224 |
| SyRS-041 | Systemweite Wahl des Anmeldeverfahrens | StRS-031 | SwRS-046, SwRS-049, SwRS-211, SwRS-256, SwRS-315 |
| SyRS-042 | Kein unbeabsichtigter lokaler Kennwortpfad bei aktivem Verzeichnisdienst | StRS-031 | — |
| SyRS-043 | Speicherung von Anmeldekennwörtern mit Salz und Schlüsselstreckung | StRS-033 | SwRS-154, SwRS-172, SwRS-210 |
| SyRS-044 | Begrenzung fehlgeschlagener Anmeldeversuche | StRS-035 | — |
| SyRS-045 | Gesicherte Verbindung zum Verzeichnisdienst | StRS-033 | — |
| SyRS-046 | Kontodeaktivierung und Beschäftigungsfenster als Anmeldeschranke | StRS-031 | — |
| SyRS-047 | Zweiter Faktor auf allen Anmeldewegen | StRS-031 | SwRS-137, SwRS-180, SwRS-181, SwRS-182, SwRS-212 |
| SyRS-048 | Gültigkeitsdauer und Bindungskontext des zweiten Faktors | StRS-031 | SwRS-263 |
| SyRS-049 | Anwendungsbezogene Zugangsbeschränkung vor Sitzungsvergabe | StRS-034 | — |
| SyRS-050 | Sitzungstickets mit anwendungsabhängiger Ablauffrist | StRS-037 | — |
| SyRS-051 | Zugriffstoken mit erzwungenem Ablauf und begrenztem Geltungsbereich | StRS-032 | SwRS-140, SwRS-220, SwRS-372 |
| SyRS-052 | Geltung der Anwendungsbeschränkung auch für Zugriffstoken | StRS-032 | SwRS-258 |
| SyRS-053 | Vollständige Kennzeichnung unauthentifizierter Endpunkte | StRS-034 | — |
| SyRS-054 | Transport- und Cookie-Sicherheit der Weboberflächen | StRS-035 | SwRS-380 |
| SyRS-055 | Berechtigungsvergabe ausschließlich über Rechtegruppen | StRS-034 | SwRS-047, SwRS-048, SwRS-076, SwRS-079, SwRS-085, SwRS-096, SwRS-125, SwRS-136, SwRS-139, SwRS-213, SwRS-214, SwRS-221, SwRS-244, SwRS-365, SwRS-385 |
| SyRS-056 | Einschränkende Rechte als eigene Kategorie im Rechtemodell | StRS-034 | — |
| SyRS-057 | Einheitliches Berechtigungsmodell für Mitarbeiter- und Portalkonten | StRS-034 | SwRS-297 |
| SyRS-058 | Vorrang zentraler Freigabeeinstellungen vor individueller Rechtevergabe | StRS-036 | — |
| SyRS-059 | Wirksamkeitsfrist von Rechteänderungen | StRS-003 | — |
| SyRS-060 | Trennung von Mitarbeiter- und Kundenzugang über den Anmeldetyp | StRS-034 | SwRS-282, SwRS-286, SwRS-312 |
| SyRS-061 | Wirksame Netztrennung von Mitarbeiter- und Kundenportal | StRS-034, StRS-049 | SwRS-067, SwRS-286, SwRS-312, SwRS-318 |
| SyRS-062 | Autorisierungspflicht als Vorgabe für alle Weboberflächenrouten | StRS-034 | SwRS-226, SwRS-230, SwRS-232, SwRS-245, SwRS-285, SwRS-376 |
| SyRS-063 | Anonyme tokenbasierte Zugänge mit Ablauf, Einmaligkeit und Ratenbegrenzung | StRS-036 | SwRS-320 |
| SyRS-064 | Serverseitiger Missbrauchsschutz öffentlicher Formulare | StRS-035 | SwRS-227, SwRS-296, SwRS-306, SwRS-307 |
| SyRS-065 | Benutzerbezogene Authentifizierung der Echtzeitkanäle | StRS-036 | SwRS-236, SwRS-237 |
| SyRS-066 | Durchgängige Zugriffsprüfung auf Dokumentverzeichnisse | StRS-051 | SwRS-062, SwRS-063, SwRS-197, SwRS-205, SwRS-281, SwRS-303, SwRS-323, SwRS-327 |
| SyRS-067 | [HYPOTHESE] Rechteprüfung und Parametersicherheit der Berichtserzeugung | StRS-030 | — |
| SyRS-068 | Modul- und Funktionsschranken des Clients als geschlossene Vorgabe | StRS-034 | SwRS-072, SwRS-105, SwRS-122, SwRS-143, SwRS-206, SwRS-209, SwRS-298, SwRS-299 |
| SyRS-069 | Durchgängige Mandantentrennung als Systemeigenschaft | StRS-052 | SwRS-052, SwRS-138, SwRS-249 |
| SyRS-070 | Filialbezogene Einschränkung von Sicht und Verwaltungsumfang | StRS-007 | SwRS-028, SwRS-029, SwRS-087, SwRS-103, SwRS-164, SwRS-168, SwRS-170, SwRS-174, SwRS-195, SwRS-218, SwRS-283, SwRS-301 |
| SyRS-071 | Lizenzdurchsetzung bei Systemstart und bei jeder Anmeldung | StRS-053 | SwRS-193, SwRS-285, SwRS-295 |
| SyRS-072 | Hardwaregebundene Lizenzprüfung ohne clientseitige Umgehung | StRS-053 | SwRS-251, SwRS-262 |
| SyRS-073 | Geschützte Ablage des Masterschlüssels der Kennwortverwaltung | StRS-033 | SwRS-051, SwRS-176, SwRS-177, SwRS-179, SwRS-311, SwRS-395 |
| SyRS-074 | Geheimnisverwaltung in Konfiguration, Auslieferung und Quellverwaltung | StRS-031, StRS-032, StRS-033, StRS-038 | SwRS-050, SwRS-058, SwRS-084, SwRS-216, SwRS-223, SwRS-228, SwRS-261, SwRS-277, SwRS-278, SwRS-347, SwRS-379, SwRS-399, SwRS-400 |
| SyRS-075 | Vollständige Protokollierung sicherheitsrelevanter Vorgänge | StRS-037 | SwRS-068, SwRS-178, SwRS-183, SwRS-359 |
| SyRS-076 | Mehrkanaliger Zugang zum Gesamtsystem | StRS-034 | SwRS-288, SwRS-290, SwRS-308, SwRS-309 |
| SyRS-077 | Fail-closed-Vorgabe der REST-v1-Schnittstelle | StRS-034 | SwRS-083, SwRS-242, SwRS-253, SwRS-254, SwRS-375 |
| SyRS-078 | Abweichendes, fail-open ausgelegtes Standardverhalten der Legacy-WCF-Brücke | StRS-034 | — |
| SyRS-079 | Zwei gleichrangige Authentifizierungsschemata an der HTTP-Systemgrenze | StRS-031 | SwRS-248 |
| SyRS-080 | Einheitliches Fehlerverhalten der Zugangskanäle nach außen | StRS-043 | SwRS-215, SwRS-231, SwRS-250, SwRS-316, SwRS-347 |
| SyRS-081 | Transport- und Serialisierungsvarianten der Legacy-Schnittstelle | StRS-042 | SwRS-240, SwRS-255, SwRS-260 |
| SyRS-082 | Nachrichtenrahmen und Statusausdruck der Legacy-Schnittstelle | StRS-046 | SwRS-253, SwRS-257 |
| SyRS-083 | Herkunftsbeschränkung des Browserzugriffs (CORS) | StRS-035 | SwRS-229 |
| SyRS-084 | Echtzeitkanal für Benachrichtigungen, Chat, Verfügbarkeit und Telefonie | StRS-029 | SwRS-156, SwRS-157, SwRS-247, SwRS-310 |
| SyRS-085 | Trennung von Mitarbeiter- und Kundenzugang über getrennte Lauschports | StRS-034 | — |
| SyRS-086 | Outlook-Anbindung als mitgehosteter Zugangskanal | StRS-050 | SwRS-284, SwRS-302, SwRS-322, SwRS-324, SwRS-325, SwRS-326, SwRS-328, SwRS-329 |
| SyRS-087 | Anonyme, tokenbasierte Außenzugänge für Angebote, Dokumente und Webformulare | StRS-036, StRS-051 | SwRS-049, SwRS-089, SwRS-133, SwRS-225, SwRS-293, SwRS-294, SwRS-319 |
| SyRS-088 | Bedingt aktivierbare Schnittstellendokumentation | StRS-046 | SwRS-239, SwRS-354, SwRS-355 |
| SyRS-089 | Anonyme Auskunftsendpunkte vor der Anmeldung | StRS-031 | — |
| SyRS-090 | Angebundene externe Systeme und ihre fachliche Leistung | StRS-044, StRS-045, StRS-046 | SwRS-057, SwRS-060, SwRS-121, SwRS-165, SwRS-184, SwRS-222, SwRS-272, SwRS-273, SwRS-360 |
| SyRS-091 | Online-Banking-Anbindung finAPI mit Test-/Produktivumschaltung und Lizenzbindung | StRS-017, StRS-044 | SwRS-266 |
| SyRS-092 | ebInterface als Exportformat ohne Netzwerkanbindung | StRS-022, StRS-047 | SwRS-059, SwRS-267, SwRS-363 |
| SyRS-093 | Zwei parallele Versanddienstleisteranbindungen mit unterschiedlichen Mengengrenzen | StRS-045 | SwRS-268, SwRS-269 |
| SyRS-094 | Externe Artikel- und Lieferantendatenquellen als austauschbare Suchanbieter | StRS-046 | SwRS-086, SwRS-092, SwRS-111, SwRS-270, SwRS-271, SwRS-274, SwRS-373 |
| SyRS-095 | Serverseitige Ausführung der externen Datenbeschaffung | StRS-046 | SwRS-153, SwRS-155 |
| SyRS-096 | Managed-Print-Anbindung docuFORM für unbeaufsichtigten Betrieb | StRS-048 | SwRS-235, SwRS-275 |
| SyRS-097 | Zeitgrenzen und Wiederholungsverhalten gegenüber externen Systemen | StRS-042 | SwRS-276 |
| SyRS-098 | Losgrößen und Drosselung bei Massenabfragen an Fremdsysteme | StRS-046 | — |
| SyRS-099 | Auslieferung als Windows-Installationspakete und Windows-Dienst | StRS-042 | SwRS-066, SwRS-207, SwRS-252, SwRS-335, SwRS-336, SwRS-337, SwRS-338, SwRS-339, SwRS-357, SwRS-358, SwRS-364, SwRS-384 |
| SyRS-100 | Nachgewiesene Codesignatur der ausgelieferten Artefakte | StRS-039 | SwRS-332, SwRS-334, SwRS-381, SwRS-386 |
| SyRS-101 | Containerbetrieb als alternative Betriebsform | StRS-042 | SwRS-341, SwRS-342, SwRS-343, SwRS-345, SwRS-348, SwRS-352, SwRS-398 |
| SyRS-102 | Zwei parallel betriebene Auslieferungsketten | StRS-038 | SwRS-330, SwRS-331, SwRS-333, SwRS-340, SwRS-349, SwRS-350, SwRS-377, SwRS-382, SwRS-387, SwRS-388, SwRS-389, SwRS-392, SwRS-396 |
| SyRS-103 | Statische Sicherheits- und Abhängigkeitsanalyse als eigenständiger Prüflauf | StRS-041 | SwRS-330, SwRS-353, SwRS-378, SwRS-383 |
| SyRS-104 | Umfang und Einbindung der automatisierten Prüfungen | StRS-040 | SwRS-351, SwRS-390 |
| SyRS-105 | Reproduzierbare Testumgebung und Wirksamkeitssicherung der Vergleichstests | StRS-040 | SwRS-344, SwRS-369, SwRS-370, SwRS-371, SwRS-391, SwRS-393 |
| SyRS-106 | Protokollierung und Diagnosezugang im Betrieb | StRS-043 | SwRS-150, SwRS-196, SwRS-238, SwRS-265, SwRS-292 |
| SyRS-107 | Konfigurationsquellen und deren Schutzbedarf | StRS-032 | SwRS-148, SwRS-149, SwRS-280, SwRS-291, SwRS-313, SwRS-321, SwRS-346 |
| SyRS-108 | Betriebsumgebung und Plattformbindung | StRS-042 | SwRS-366 |
| SyRS-109 | Zeitgesteuerte Hintergrundverarbeitung als Betriebseigenschaft | StRS-011, StRS-029 | SwRS-055, SwRS-069, SwRS-128, SwRS-130, SwRS-185, SwRS-186, SwRS-208, SwRS-233, SwRS-234, SwRS-368 |
| SyRS-110 | [HYPOTHESE] Einschränkung des Mehrinstanzbetriebs durch prozesslokale Zustände | StRS-042 | SwRS-264 |
| SyRS-111 | Ermittlung des gültigen Steuersatzes am Beleg | StRS-008 | SwRS-033 |
| SyRS-112 | Positions- und Belegsummenbildung mit festgelegter Rundungsreihenfolge | StRS-008 | SwRS-014, SwRS-015, SwRS-016, SwRS-199, SwRS-200, SwRS-259 |
| SyRS-113 | Reverse-Charge-Behandlung am Beleg | StRS-008 | SwRS-200, SwRS-374 |
| SyRS-114 | Belegvorschau ohne Nummernverbrauch und Belegausgabewege | StRS-006 | SwRS-003, SwRS-065, SwRS-204 |
| SyRS-115 | Kassenbuchführung für Bargeschäfte | StRS-015 | SwRS-043 |
| SyRS-116 | Provisionsermittlung am Beleg | StRS-014 | SwRS-007 |
| SyRS-117 | SEPA-Mandatsverwaltung und Mandatslebenszyklus | StRS-019 | SwRS-078 |
| SyRS-118 | SEPA-Lastschriftlauf mit Prüfung der Einzugsdaten und Rücknahme | StRS-019 | SwRS-161 |
| SyRS-119 | [HYPOTHESE] Versandkostenermittlung über die Gewichtsstaffel | — | SwRS-191 |
| SyRS-120 | Lagerbewertung und Fortschreibung des Einstandspreises | StRS-025 | SwRS-035 |
| SyRS-121 | Reisekostenabwicklung und deren Genehmigung | StRS-020 | SwRS-123 |
| SyRS-122 | Erfassung von Arbeitszeiten mit Zuschlagsermittlung | StRS-027 | SwRS-145, SwRS-309 |
| SyRS-123 | Leasing- und Servicekonditionen | StRS-005 | SwRS-147 |
| SyRS-124 | Servicezeiten und Reaktionsfristen (SLA) | StRS-026 | SwRS-126 |
| SyRS-125 | Projektverwaltung sowie Projekt- und Kapazitätsübersicht | StRS-029 | SwRS-056, SwRS-135 |
| SyRS-126 | Produktionsauftragsverwaltung | — | SwRS-037, SwRS-187 |
| SyRS-127 | Kampagnenverwaltung und Werbesperre als Systemeigenschaft | — | SwRS-039, SwRS-102 |
| SyRS-128 | Import von Vertragsartikeln und von Stammdaten | StRS-046 | SwRS-111, SwRS-162, SwRS-202 |
| SyRS-129 | Elektronische Signatur von Belegen und Freigabedokumenten | StRS-036 | SwRS-063, SwRS-151 |
| SyRS-130 | Automatische Belegerfassung durch Beleg-Scan und Zuordnung erkannter Werte | StRS-024 | SwRS-198 |
| SyRS-131 | Mitarbeiterstamm als eigenständiger Stammdatenbestand | StRS-051 | SwRS-053, SwRS-062 |
| SyRS-132 | Länder-, Mengeneinheiten- und Hotline-Stammdaten als eigenständige Referenzbestände | StRS-001 | SwRS-075, SwRS-116, SwRS-152 |
| SyRS-133 | Kostenrechnungsstammdaten (Kostenträger und Kostenstellen) | StRS-030 | SwRS-106, SwRS-190 |
| SyRS-134 | Qualität der Artikelstammdaten — Pflichtangaben und Eindeutigkeit | StRS-025 | SwRS-106 |
| SyRS-135 | Kundenspezifische Zusatzfelder je Objektart mit Pflichtfeldsteuerung | — | SwRS-194 |
| SyRS-136 | Mehrsprachigkeit der Bedienoberflächen | — | SwRS-279, SwRS-367 |
| SyRS-137 | Erscheinungsbild und persönliche sowie globale Oberflächenprofile | — | SwRS-070, SwRS-203, SwRS-219 |
| SyRS-138 | Übergreifende Suche in der Weboberfläche | StRS-001 | SwRS-289 |
| SyRS-139 | [HYPOTHESE] Antwortzeitverhalten der Stammdatensuche | — | SwRS-113, SwRS-289 |
| SyRS-140 | E-Mail-Versand und Verwaltung von Mailvorlagen | StRS-050 | SwRS-061, SwRS-314 |
| SyRS-141 | Schutz vor unbeabsichtigtem E-Mail-Versand an Kunden aus Nicht-Produktivständen | — | SwRS-061, SwRS-362 |
| SyRS-142 | Synchronisation mit externen Kalendern | StRS-050 | SwRS-189 |
| SyRS-143 | Abwesenheits- und Urlaubsverwaltung | StRS-029 | SwRS-054 |
| SyRS-144 | Einsatzplanung im Servicebetrieb | StRS-026 | SwRS-135, SwRS-305 |
| SyRS-145 | KI-gestützte Datenänderung und Nutzung externer KI-Dienste | StRS-034 | SwRS-142, SwRS-184, SwRS-250 |
| SyRS-146 | Fernwartungszugang | StRS-031 | SwRS-175, SwRS-178 |
| SyRS-147 | Löschung personenbezogener Daten | — | SwRS-141 |
| SyRS-148 | Einheitliche Codebasis über die Bedienoberflächen hinweg | StRS-042 | SwRS-210, SwRS-394, SwRS-397 |
| SyRS-149 | Qualitätsmanagement-Meldegründe je Belegart | StRS-024 | SwRS-192 |
## 4 Anforderungen ohne durchgängige Verknüpfung
| ID | Befund | Titel |
|---|---|---|
| SwRS-081 | keine SyRS- und keine StRS-Verknüpfung | Versionierung und Schreibschutz von Lieferantenverträgen |
| SyRS-119 | keine StRS-Verknüpfung | [HYPOTHESE] Versandkostenermittlung über die Gewichtsstaffel |
| SyRS-126 | keine StRS-Verknüpfung | Produktionsauftragsverwaltung |
| SyRS-127 | keine StRS-Verknüpfung | Kampagnenverwaltung und Werbesperre als Systemeigenschaft |
| SyRS-135 | keine StRS-Verknüpfung | Kundenspezifische Zusatzfelder je Objektart mit Pflichtfeldsteuerung |
| SyRS-136 | keine StRS-Verknüpfung | Mehrsprachigkeit der Bedienoberflächen |
| SyRS-137 | keine StRS-Verknüpfung | Erscheinungsbild und persönliche sowie globale Oberflächenprofile |
| SyRS-139 | keine StRS-Verknüpfung | [HYPOTHESE] Antwortzeitverhalten der Stammdatensuche |
| SyRS-141 | keine StRS-Verknüpfung | Schutz vor unbeabsichtigtem E-Mail-Versand an Kunden aus Nicht-Produktivständen |
| SyRS-147 | keine StRS-Verknüpfung | Löschung personenbezogener Daten |
@@ -0,0 +1,290 @@
# Messprotokoll – Versuch 02 (Agentengestützt) – Prompt-Version 03-A
## Lauf
- **Prompt-Datei:** `Versuche/Versuch_02/02_Prompt.md`
- **Prompt-Version:** 03-A (unverändert gegenüber dem ersten V2-Lauf)
- **SHA-256 (Prompt):** `5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD`
- **Startzeit:** 2026-08-31T13:09:18.6547798+02:00
- **Endzeit:** 2026-08-31T16:56:35.8276426+02:00
- **Dauer gesamt:** 03:47:17 Wanduhr (API: 17:20:30 – Summe nebenläufiger Anfragen;
`duration_ms` = 316.873 ms erfasst den Gesamtlauf erkennbar nicht und wird nicht berichtet)
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.663 versionierte Dateien)
- **Codebasis-Commit:** `8a22d586` (dirty: nein)
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfung vor dem Lauf ohne Treffer);
Remote entkoppelt: ja
- **Prompt-Repo-Commit:** `8a22d586`
## Werkzeugkonfiguration
- **Skill-Version:** 9.2.0
- **Werkzeugadapter:** Claude Code
- **CLI-Version:** 2.1.251
- **Modell (angefordert):** `claude-opus-5`
- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 365.032.582 (91,9 %),
**`claude-sonnet-5` 32.157.585 (8,1 %)**, `claude-haiku-4-5-20251001` 9.491 (0,002 %)
- **Kontrolle Modell:** **VERLETZT** – siehe Abschnitt *Modellbedingung* unten
- **Effort:** `medium` (per `--effort` gesetzt; abweichend vom ersten V2-Lauf, der auf `high` lief)
- **Laufverzeichnis-ID:** `v9.2.0-da6a`
- **Ablage:** `Iteration 2/claude-opus-5/custom/medium/`
- **Parallele Läufe:** nein
- **Agentenmodus:** `custom` (V2). Agentendefinitionen: `Versuche/Versuch_02/03_Agents.json`,
SHA-256 `424DDD8398D8A6521D9B34AF5B221867C5643572B3821005C7E5E87954644170`, acht Rollen
- **Delegationstiefe:** **`unverschachtelt`** – Kontrolle **bestanden**:
`spawned_by_subagents` = 0, `max_depth` = 1
- **Permission-/Sandbox-Modus:** `acceptEdits`
- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` plus 33er-Denylist
- **Isolationsmechanismus:** kein `--safe-mode` (deaktiviert die Agentenrollen), stattdessen
`--strict-mcp-config` plus `--disallowedTools Skill WebSearch WebFetch SlashCommand`
- **Umgebungsprüfung (`custom`):** keine Hooks, Plugins, Output-Styles, Skills oder Agents im
User-Profil vorgefunden
- **Subagenten:** 56 gestartet, 56 abgeschlossen, 0 fehlgeschlagen, **0 abgewiesen**
(`refused.concurrency_limit` = 0 – das Nebenläufigkeitslimit wurde nie erreicht)
## Iterationszuordnung
Der Lauf eröffnet **Iteration 2** in Versuch 02. Gegenüber dem ersten V2-Lauf
(`Iteration 1/…/v9.1.0-0c39`) unterscheidet er sich in drei benannten Größen:
| Größe | Iteration 1 | Iteration 2 |
|---|---|---|
| Modell | `claude-sonnet-5` | `claude-opus-5` |
| Effort | `high` | `medium` |
| Delegationstiefe | `verschachtelt` (`02_Agents.json`) | `unverschachtelt` (`03_Agents.json`) |
Modell und Effort sind Ordnerebenen; die geänderte `--agents`-Datei ist eine geänderte
Werkzeugkonfiguration und begründet die neue Iteration. **Ein Modellvergleich zwischen beiden
Läufen ist wegen der drei gleichzeitig gewechselten Größen nicht zulässig.** Der Wechsel war
durch das Modellkontingent erzwungen (siehe *Kontingent*).
## Modellbedingung – verletzt
`modelUsage` weist neben `claude-opus-5` das nicht angeforderte Modell `claude-sonnet-5` mit
32.157.585 Tokens (8,1 % des Gesamtverbrauchs) aus. Die Auswertung der 56 persistierten
Subagenten-Transkripte lokalisiert den Fall genau:
| Rolle | Subagenten auf `claude-sonnet-5` | Auftrag |
|---|---:|---|
| `faktenermittler` | 6 | sämtlich „Fakten OP-63 docuFORM" |
| `swrs-autor` | 1 | „SwRS-399..400 docuFORM-Client" |
| `modulinventar` | 1 | „OP-Inventar §2.4 rekonstruieren" |
49 der 56 Subagenten liefen auf `claude-opus-5`, 8 auf `claude-sonnet-5`. Auffällig ist die
inhaltliche Konzentration: Sieben der acht Fälle betreffen denselben Gegenstand (docuFORM,
offener Punkt 63), und der `faktenermittler` wurde dafür sechsmal beauftragt. Ob der
Modellwechsel eine Folge wiederholter Beauftragung derselben Teilaufgabe ist oder eine davon
unabhängige Zuweisung der CLI, ist aus den vorliegenden Daten **nicht** zu entscheiden.
Damit reiht sich der Fall in die zwei bereits dokumentierten Modellabweichungen aus Versuch 1
ein (Fable-Subagenten auf `claude-opus-5[1m]`; 18,5 Mio. Opus-Tokens auf `claude-sonnet-5`).
Der Befund bestätigt die Regel des Skills: `--model` bindet den Hauptagenten, nicht zuverlässig
die Subagenten. **Für Modellvergleiche ist dieser Lauf nur mit ausdrücklichem Hinweis auf den
8,1-Prozent-Anteil verwendbar.**
Der neue Umstand gegenüber Versuch 1: Weil CLI 2.1.251 die Subagenten-Transkripte einzeln
persistiert, ist die Abweichung erstmals **rollen- und auftragsscharf** lokalisierbar statt nur
als Summe in `modelUsage` sichtbar.
## Zuständigkeitsbindung
| Rolle | Aufrufe |
|---|---:|
| `faktenermittler` | 27 |
| `swrs-autor` | 11 |
| `syrs-autor` | 6 |
| `modulinventar` | 5 |
| `strs-autor` | 3 |
| `belegpruefer` | 2 |
| `konsistenzpruefer` | 1 |
| `iso29148-orchestrator` | 1 |
| **Summe** | **56** |
**Alle acht gebundenen Rollen eingesetzt, und kein einziger Aufruf an einen eingebauten Typ.**
Das ist der deutlichste Unterschied zum ersten V2-Lauf, in dem 16 von 86 Starts (18,6 %) an
`general-purpose` und `Explore` gingen – davon 12 an der Traceability-Anreicherung (Schritt 6),
für die die Bindungstabelle keinen Bearbeiter vorsieht.
**Die Bindungslücke bei Schritt 6 wurde bewusst nicht geschlossen**, um die Zahl der geänderten
Größen klein zu halten. Sie ist damit eine Wiederholungsmessung – und das Ergebnis fällt anders
aus: Dasselbe Loch führte hier nicht zum eingebauten Typ. Die `Traceability.md` (86 KB) entstand
ohne einen einzigen ungebundenen Agenten. Ein Modelleffekt ist naheliegend, aber bei drei
gleichzeitig gewechselten Größen **nicht belegt**.
**Delegationstiefe `unverschachtelt` hat gegriffen:** `spawned_by_subagents` = 0, `max_depth` = 1,
56 Aufrufe gegen 56 Subagenten-Transkripte. Die Vorgabe wirkt allein über den Rollenprompt und
war nicht technisch erzwungen.
**Nebenbefund:** `refused.concurrency_limit` = 0. Der erste V2-Lauf hatte 72 Absagen bei 86
Starts – der Agent wollte dort weit stärker parallelisieren, als das Werkzeug zuließ. Ohne
Weiterdelegation und mit gröberem Zuschnitt tritt das Limit nicht mehr auf.
## Verbrauch
### Hauptagent (`usage`)
| Messgröße | Wert |
|---|---:|
| Input-Tokens | 20 |
| Output-Tokens | 20.168 (davon 1.033 Thinking-Tokens) |
| Cache-Write-Tokens | 35.850 |
| Cache-Read-Tokens | 7.384.969 |
| Agent-Turns | 10 |
### Gesamtlauf inkl. Subagenten (`modelUsage`)
| Messgröße | `claude-opus-5` | `claude-sonnet-5` | `claude-haiku-4-5` | Summe |
|---|---:|---:|---:|---:|
| Input-Tokens | 287.449 | 722 | 9.465 | 297.636 |
| Output-Tokens | 5.515.994 | 253.366 | 26 | 5.769.386 |
| Cache-Write-Tokens | 18.031.138 | 811.833 | 0 | 18.842.971 |
| Cache-Read-Tokens | 341.198.001 | 31.091.664 | 0 | 372.289.665 |
| **Tokens gesamt** | **365.032.582** | **32.157.585** | **9.491** | **397.199.658** |
**Tokens gesamt: 397.199.658.** 93,7 % davon sind Cache-Reads.
## Kontingent
Der Lauf wurde gestartet, um zu prüfen, ob die Zelle `claude-opus-5 / custom` innerhalb der
43 % des Modellkontingents machbar ist, die der Sonnet-Lauf verbraucht hatte. **Sie ist es
nicht.**
Zu Listenpreisen (Opus 5: $5/$25 je Mio. Input/Output; Cache-Write 1,25×, Cache-Read 0,1×;
Sonnet 5: $2/$10) kostet dieser Lauf rund **$433** gegenüber **$146** des Sonnet-Laufs – das
**2,97-fache**. Mit dem Sonnet-Lauf als Eichpunkt (43 % des Kontingents) entspricht das
rund **128 % des Kontingents**. Das Kontingent ist damit überschritten.
Die Ursache ist nicht das Preisverhältnis allein (2,5×), sondern zusätzlich ein um 12,6 %
höherer Tokenverbrauch – **trotz** `medium` statt `high`, **trotz** unterbundener
Weiterdelegation und **trotz** deutlich weniger Agenten (56 statt 86). Der Verbrauch je Subagent
lag bei rund 13,6 Mio. Transkript-Tokens gegenüber 7,0 Mio. beim Sonnet-Lauf. Opus zerlegt
gröber und arbeitet jeden Ausschnitt tiefer aus; die beiden strukturellen Sparmaßnahmen wurden
davon vollständig aufgezehrt.
**Für die Arbeit heißt das:** Die Zelle `claude-opus-5 / custom` ist unter dem verfügbaren
Kontingent nicht wiederholbar messbar. Sie steht neben `claude-opus-5 / builtin / high` aus
Versuch 1 als zweite Zelle, deren Grenze das Kontingent ist und nicht das Verfahren.
**Güte der Live-Schätzung.** Während des Laufs wurde der Verbrauch aus den Transkripten
geschätzt und mit einem am Sonnet-Lauf gewonnenen Faktor korrigiert (Transkriptsumme ÷ 2,45).
Die letzte Schätzung vor Laufende lautete 316 Mio. Tokens beziehungsweise 96 % des Kontingents;
tatsächlich waren es 397 Mio. und 128 %. Der Faktor beträgt für diesen Lauf 1,95 statt 2,45 – er
ist **nicht laufübergreifend stabil** und hängt vom Verhältnis Haupt- zu Subagenten-Nachrichten
ab. Eine Live-Schätzung taugt damit zur Richtungsanzeige, nicht zur Budgetsteuerung.
## 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 | 53 | 8,7 % |
| SyRS | 149 | 24,6 % |
| SwRS | 404 | 66,7 % |
| **Gesamt** | **606** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 222 | 36,6 % |
| Sicherheit | 220 | 36,3 % |
| Daten | 75 | 12,4 % |
| nicht-funktional | 51 | 8,4 % |
| Schnittstelle | 38 | 6,3 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 1.927 |
| davon `PRIMÄR` | 1.674 (86,9 %) |
| davon `SEKUNDÄR` | 180 (9,3 %) |
| davon `KONTEXT` | 73 (3,8 %) |
| Belege je Anforderung (Median) | 3,0 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 597 (98,5 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 442 | 72,9 % |
| workaround | 104 | 17,2 % |
| sonderfall | 35 | 5,8 % |
| veraltet | 25 | 4,1 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 577 | 95,2 % |
| als `HYPOTHESE` gekennzeichnet | 29 | 4,8 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 232 | 38,3 % |
| mit ISO-25010-Qualitätsmerkmal | 81 | 13,4 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (280 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 606 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 606 von 606 mit Tracelinks (100,0 %) |
## Ergebnis
- **Status:** erfolgreich (`is_error` = false, `subtype` = success, `stop_reason` = end_turn,
`terminal_reason` = completed, Exitcode 0)
- **Session-ID:** `8ada72a9-901a-4be3-915b-8ff0dfc21046`
- **Permission-Denials:** **0**
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 56
- **Subagenten-Prompts:** `_meta\subagenten.md`, 56 Aufrufe erfasst; Abgleich mit
`spawned` − `spawned_by_subagents` = 56 **stimmt exakt**, 0 Absagen
- **Gültigkeit:** **gültig mit Einschränkung** – alle sieben geforderten Dateien vorhanden,
`Stderr.log` 0 Byte, Root unverändert; **die Modellbedingung ist jedoch verletzt** (8,1 %
`claude-sonnet-5`)
- **Erzeugte Dateien:** `SwRS.md` (1.045 KB), `SyRS.md` (510 KB), `StRS.md` (240 KB),
`Analysebericht.md` (153 KB), `Traceability.md` (86 KB), `Hypothesen.md` (20 KB),
`Glossar.md` (19 KB) – genau die sieben vorgegebenen, keine Ergänzungsdateien
- **Root unverändert:** ja (`before.txt` und `after.txt` identisch, beide leer)
## Anmerkungen/Auffälligkeiten
**Vergleich mit dem ersten V2-Lauf** – wegen der drei gleichzeitig gewechselten Größen
ausdrücklich **kein** Modellvergleich, sondern eine Gegenüberstellung zweier Bedingungen:
| Kenngröße | Iteration 1 (Sonnet/high/verschachtelt) | Iteration 2 (Opus/medium/unverschachtelt) |
|---|---:|---:|
| Anforderungen | 845 | **606** |
| Verteilung StRS/SyRS/SwRS | 185 / 180 / 480 | 53 / 149 / 404 |
| Belege gesamt | 1.086 | **1.927** |
| Belege je Anforderung (Median) | 1,0 | **3,0** |
| Anforderungen mit `PRIMÄR`-Beleg | 95,6 % | **98,5 %** |
| Anforderungen ohne jeden Beleg | 9 | **0** |
| Hypothesenanteil | 8,9 % | 4,8 % |
| Konsolidierungskandidaten | 22,1 % | 38,3 % |
| mit ISO-25010-Merkmal | 65,9 % | **13,4 %** |
| Subagenten | 86 | 56 |
| Tokens gesamt | 352.828.287 | 397.199.658 |
| Wanduhrdauer | 03:07:16 | 03:47:17 |
Weniger Anforderungen, aber erheblich dichter belegt: 1.927 Belege auf 606 Anforderungen
gegenüber 1.086 auf 845, Median 3 statt 1, und **kein einziger Regelverstoß** in der
maschinellen Prüfung (der Sonnet-Lauf hatte 9 Anforderungen ohne Beleg).
**Deutliche Verschlechterung an einer Stelle:** Nur 13,4 % der Anforderungen tragen ein
ISO-25010-Qualitätsmerkmal gegenüber 65,9 %. Der Anteil nicht-funktionaler Anforderungen ist
zugleich von 14,6 % auf 8,4 % gefallen. Ob das an Modell, Effort oder Zerlegung liegt, ist mit
einem Lauf nicht zu trennen.
**Die StRS-Ebene ist auffällig dünn:** 53 Anforderungen (8,7 %) gegenüber 185 (21,9 %). Der
`strs-autor` wurde nur dreimal beauftragt, der `swrs-autor` elfmal. Die Ebenenverteilung bleibt
damit auch mit getrennten Autorenrollen die instabilste Größe der Reihe – sie schwankte über
alle Läufe von 92,7 % StRS bis 66,7 % SwRS.
**`num_turns` = 10** gegenüber 20 im ersten V2-Lauf, bei fast doppelter Wanduhrzeit je Turn. Der
Hauptagent hat gröber orchestriert und je Turn mehr Subagenten gebündelt.
**Offen für den nächsten Lauf:** Die Bindungstabelle braucht die Zeile
`Traceability-Anreicherung (Schritt 6) → iso29148-orchestrator`. Sie blieb in diesem Lauf
absichtlich offen, um die Zahl der Änderungen zu begrenzen.
@@ -0,0 +1,65 @@
## Gefundene Anforderungen
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
### Verteilung über die Ebenen
| Ebene | Anzahl | Anteil |
|---|---:|---:|
| StRS | 53 | 8,7 % |
| SyRS | 149 | 24,6 % |
| SwRS | 404 | 66,7 % |
| **Gesamt** | **606** | 100 % |
### Anforderungstypen
| Typ | Anzahl | Anteil |
|---|---:|---:|
| funktional | 222 | 36,6 % |
| Sicherheit | 220 | 36,3 % |
| Daten | 75 | 12,4 % |
| nicht-funktional | 51 | 8,4 % |
| Schnittstelle | 38 | 6,3 % |
### Belegqualität
| Messgröße | Wert |
|---|---:|
| Belege gesamt | 1.927 |
| davon `PRIMÄR` | 1.674 (86,9 %) |
| davon `SEKUNDÄR` | 180 (9,3 %) |
| davon `KONTEXT` | 73 (3,8 %) |
| Belege je Anforderung (Median) | 3,0 |
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 597 (98,5 %) |
### Übernahmewürdigkeit
| Einstufung | Anzahl | Anteil |
|---|---:|---:|
| übernehmen | 442 | 72,9 % |
| workaround | 104 | 17,2 % |
| sonderfall | 35 | 5,8 % |
| veraltet | 25 | 4,1 % |
### Status
| Kategorie | Anzahl | Anteil |
|---|---:|---:|
| belegt | 577 | 95,2 % |
| als `HYPOTHESE` gekennzeichnet | 29 | 4,8 % |
| als Workaround vermerkt | 0 | 0,0 % |
| Konsolidierungskandidaten | 232 | 38,3 % |
| mit ISO-25010-Qualitätsmerkmal | 81 | 13,4 % |
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
| Vorgabe | Ergebnis |
|---|---|
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (280 risikorelevante Anforderungen, alle gedeckt) |
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 606 Anforderungen eingestuft) |
| **Traceability** – Verknüpfung zwischen den Ebenen | 606 von 606 mit Tracelinks (100,0 %) |
@@ -0,0 +1,219 @@
# Versuch 02 - Agentengestuetzt - Prompt-Version 03-A
## Metadaten
- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien)
- **Prompt-Version:** 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)
- **Basis:** `Versuche/Versuch_01/03_Prompt.md`, SHA-256 `B8C8764F…C030F07`
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-31
- **Vorgänger:** `01_Prompt.md` (Prompt-Version 02-A, SHA-256 `DCDC0E3F…B71BCF`), **kein Lauf durchgeführt**
- **Änderungsgrund gegenüber `01_Prompt.md`:** Version 02-A leitete sich von Prompt-Version **02** ab. Versuch 1 ist inzwischen auf Prompt-Version **03** weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in **zwei** Größen unterscheiden — Agentenrollen *und* Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.
| Änderung gegenüber `Versuch_01/03_Prompt.md` | Grund |
|---|---|
| Neuer Abschnitt „Arbeitsteilung" | Prompt-Version 03 unterstellt stillschweigend **einen** Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. |
| In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung | Die 7-Datei-Regel aus Version 03 entstand an einem `solo`-Lauf (Kimi legte `SwRS-Ergaenzungen.md` an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt. |
| In der Arbeitsteilung: **Zuständigkeitsbindung** — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist **statisch** deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten. |
| In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe | Gebunden wird **wer** eine Teilaufgabe ausführt, nicht **wie viel** davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b. |
| In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung | Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen `subagent_stats` und die Subagenten-Prompts prüfbar. |
| Angehängte Tabellenzeilen und Schlussblockquote aus `03_Prompt.md` an ihren Platz gerückt | In `03_Prompt.md` stehen zwei Zeilen der Änderungstabelle **nach** dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die **gesamte** Datei sendet (`_meta/combined_prompt.md`), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein. |
**Der Prompt nennt keine Rolle namentlich.** Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen `solo`-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin **nicht** vorgegeben; sie bleiben Teil der Untersuchung.
Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf
> zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau
> beim Start bei.
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
### Pflicht-Eigenschaften jeder Anforderung
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
- **Belegklassifikation:** Kennzeichne jeden Beleg als
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
### Arbeitsteilung
Die Bearbeitung wird auf mehrere Bearbeiter verteilt. **Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen** — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.
- **Frei bleibt, wie du die Bearbeiter einsetzt.** Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, **wer** eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
- **Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig.** Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.
**Dokumentationspflicht.** Halte im `Analysebericht.md` fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.
### Formatvorgabe pro Anforderung
```
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
Titel: <kurzer Titel>
Ebene: <StRS | SyRS | SwRS>
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur: <Rolle / System / Komponente>
Vorbedingung: <Zustand vor Auslösen>
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
Belege:
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
- [SEKUNDÄR] <...> - Begründung: <...>
- [KONTEXT] <...> - Begründung: <...>
Prüfidee: <Akzeptanzkriterium oder Testidee>
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status: <belegt | HYPOTHESE>
```
### Traceability
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
### Nicht-funktionale Anforderungen
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
### Konsolidierungsbedarf
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
```text
Ergebnisse/
StRS.md
SyRS.md
SwRS.md
Traceability.md (oder Traceability.csv)
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
Selbstbewertung, bekannte Lücken)
```
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen im Arbeitsverzeichnis, schreibgeschützte
Kommandozeilenbefehle, das Schreiben von Ergebnisdateien im unten genannten Ausgabeverzeichnis
sowie acht beigestellte Agentenrollen.
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff, Skills und Slash-Kommandos.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare Werkzeuge zu
ersetzen.
Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese Teilaufgaben
durch den jeweils genannten Bearbeiter aus, nicht selbst:
| Teilaufgabe | Vorgesehener Bearbeiter |
|---|---|
| Modulinventar (Schritt 0) | modulinventar |
| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
| Formulierung der StRS-Anforderungen | strs-autor |
| Formulierung der SyRS-Anforderungen | syrs-autor |
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe entscheidest du.
Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter lesen nur und legen keine
Ergebnisdateien an; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen bleiben
deine Aufgabe. Die Bearbeiter delegieren nicht weiter — nur du beauftragst.
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
`c:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 2\claude-opus-5\custom\medium\02_Lauf_2026-08-31_130834_v9.2.0-da6a\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1,42 @@
$ErrorActionPreference = 'Continue'
$root = 'c:\DEV\MasterArbeit\QuellCode\CentronERP'
$lauf = (Get-Content 'c:\DEV\MasterArbeit\Versuche\Versuch_02\_aktueller_lauf.txt' -Raw).Trim()
$agents = (Get-Content 'c:\DEV\MasterArbeit\Versuche\Versuch_02\03_Agents.json' -Raw)
$claude = Get-ChildItem "$env:USERPROFILE\.vscode\extensions\anthropic.claude-code-*-win32-x64\resources\native-binary\claude.exe" |
Sort-Object FullName | Select-Object -Last 1 -ExpandProperty FullName
$denyBash = @(
'Bash(rm:*)','Bash(rmdir:*)','Bash(mv:*)','Bash(cp:*)','Bash(dd:*)',
'Bash(truncate:*)','Bash(chmod:*)','Bash(chown:*)','Bash(ln:*)','Bash(tee:*)',
'Bash(sed -i:*)','Bash(git checkout:*)','Bash(git restore:*)','Bash(git clean:*)',
'Bash(git reset:*)','Bash(git add:*)','Bash(git commit:*)','Bash(git push:*)',
'Bash(dotnet:*)','Bash(msbuild:*)','Bash(npm install:*)','Bash(nuget:*)'
)
$denyPs = @(
'PowerShell(Remove-Item:*)','PowerShell(Move-Item:*)','PowerShell(Copy-Item:*)',
'PowerShell(New-Item:*)','PowerShell(Set-Content:*)','PowerShell(Add-Content:*)',
'PowerShell(Clear-Content:*)','PowerShell(Out-File:*)','PowerShell(Set-ItemProperty:*)',
'PowerShell(dotnet:*)','PowerShell(msbuild:*)'
)
# Modus custom: KEIN --safe-mode (es deaktiviert die Agentenrollen). Ersatz nach Skill 7.0.0:
$denyCustom = @('Skill','WebSearch','WebFetch','SlashCommand')
$env:CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS = '0'
Set-Content -Path "$lauf\_meta\startzeit.txt" -Value (Get-Date -Format o)
Set-Location $root
Get-Content "$lauf\_meta\combined_prompt.md" -Raw |
& $claude -p `
--output-format json `
--strict-mcp-config `
--permission-mode acceptEdits `
--allowedTools "Bash" "PowerShell" `
--disallowedTools @($denyBash + $denyPs + $denyCustom) `
--model claude-opus-5 `
--effort medium `
--agents $agents `
--add-dir "$lauf" `
2> "$lauf\Stderr.log" | Set-Content "$lauf\RawResult.json"
Set-Content -Path "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o)
Set-Content -Path "$lauf\_meta\exitcode.txt" -Value $LASTEXITCODE
@@ -0,0 +1,917 @@
# StRS – Stakeholder Requirements Specification
c-entron ERP-Suite · Reverse Requirements Engineering · ISO/IEC/IEEE 29148:2018
Ebene: fachliche Sicht (Akteure, Geschäftsziele). Belegklassifikation: PRIMÄR / SEKUNDÄR / KONTEXT.
**ID-Bereich dieser Datei:** StRS-001 bis StRS-026.
Die Zuordnung „welcher Bearbeiter welche IDs formuliert" ist in `Analysebericht.md` (Abschnitt Arbeitsteilung) dokumentiert.
**Identifizierte Stakeholder / Akteure aus den Artefakten**
| Akteur | Herleitung (Artefakt) |
|---|---|
| Innendienst / Sachbearbeiter (OfficeStaff) | `ReceiptBL.CreateNewReceipt`: `customerReceipt.OfficeStaffI3D = customerDetail.Adviser1I3D` |
| Außendienst / Vertreter (SalesRepresentative) | ebd.: `SalesRepresentativeI3D = customerDetail.Adviser2I3D`; `VertreterPLZ`, `EmployeeToSalesArea` (Schema) |
| Disponent / Lagerist | `Warehousing/Commissions/CommissioningBL`, `Lagerorte`, `Nebenlager` (Schema) |
| Support-Mitarbeiter / Helpdesk-Bearbeiter | `hlpdsk_request_bearbeiter`, `CentronRights.md` §1–§9 |
| Servicetechniker (mit Signatur) | `hlpdsk_timer_signature`, `HelpdeskTimerSignatureBL` |
| Geschäftsführung / Controlling | `ControllingAuswertung`, `StatisticRolesToEmployee`, `RIGHT_MITARBEITERAUSLASTUNG` |
| Buchhaltung | `BookKeepingExport*`, `Kassenbuch*`, `Mahnlauf` |
| Systemadministrator / Mandantenbetreuer | `Administration/Licensing`, `Administration/Scripts`, `Mandant`, `MandantenStammdat` |
| Endkunde des Kunden (Webshop-Nutzer) | `README.md` („webcart is … intended for the customers of our customers"), `WebAccounts`, `WebAccountAuthenticator` |
| Externe Systeme (Handelsstufe, FiBu, Paketdienst, Bank) | `src/apis/*`, `DataExchange/EDI`, `DataExchange/BookKeeping` |
---
```
ID: StRS-001
Titel: Durchgängiger Vertriebsprozess von Angebot bis Rechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst, Außendienst
Vorbedingung: Kunde ist im Adressstamm geführt; Angebot oder Auftrag existiert in offenen Status.
Fakt: ReceiptBL.CanForwardReceiptsInto liefert die zulässigen Ziel-Belegarten; die Kette umfasst
OrderClass, DeliveryListClass, InvoiceClass, PickupListClass, CreditVoucherClass, ContractClass.
ValidateReceiptForwarding prüft je Quellbeleg: "Diese(s/r) {Belegart} kann nicht in eine(n)
{Belegart} weiterverarbeitet werden."
Aussage: Das System soll den Vertrieb entlang einer definierten Belegkette (Angebot → Auftrag →
Lieferschein → Rechnung, ergänzend Abhol-liste, Gutschrift, Vertrag) führen und den
Übergang nur entlang dieser Kette erlauben.
Ergebnis: Der Folgebeleg wird aus dem Vorgänger erzeugt; positionsbezogene Herkunftsbeziehungen
werden erhalten; ein nicht erlaubter Übergang wird mit Meldung abgewiesen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, ReceiptBL.CanForwardReceiptsInto (Zeilen 1019 ff.),
ReceiptBL.ValidateReceiptForwarding (Zeile ~995) - Begründung: die Methode definiert die zulässige
Kette und erzwingt sie bei jeder Weiterverarbeitung.
- [SEKUNDÄR] UI-Ordner src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ForwardReceipt - Begründung: eigene
Maske für den Vorgang „Weiterverarbeitung" belegt die fachliche Funktion im Zielsystem.
- [KONTEXT] Tabellen AngKopf/AngPos, BestKopf/BestPos, LiefKopf/LiefPos, RechKopf/RechPos (SSMS_DB_SCHEMA.sql)
- Begründung: je Kettenglied eigene Kopf-/Positionspaare, also vier Belegstufen mit eigener Historie.
Prüfidee: Versuch, ein Angebot direkt in eine Rechnung weiterzuverarbeiten; erwartetes Verhalten:
Abweisung mit Meldung, kein Datensatz angelegt.
Tracelinks: SyRS-001, SyRS-003, SwRS-001, SwRS-005
Konsolidierung: Kandidat: StRS-002, SwRS-015 – beide beschreiben dieselbe Belegkopf-/Positionsmaschine für
die andere Durchlaufrichtung bzw. datenmodelseitig.
Übernahmewürdigkeit: übernehmen - Kerngeschäftsfunktion, ohne die kein Handelssystem auskommt.
Status: belegt
```
```
ID: StRS-002
Titel: Beschaffungsprozess vom Bedarf bis zur Lieferantenrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkauf, Disposition
Vorbedingung: Lieferant (Kreditor) ist gepflegt; Bedarf liegt als Kundenposition oder manuelle Eingabe vor.
Fakt: Eigene Businesslogik für Lieferantenbelege: SupplierOrderBL, SupplierDeliveryListBL,
SupplierInvoicesBL, SupplierCreditVoucherBL, SupplierReceiptDocumentBL je mit eigenem
*SpecificLogic; Tabellen WareKopf/WarePos, WareneingangPos, KreditorRMAKopf/-Pos.
Aussage: Das System soll den Beschaffungsprozess (Lieferantenauftrag → Wareneingang/Lieferschein →
Lieferantenrechnung → Lieferanten-Gutschrift) abbilden und die Wareneingangsdaten auf den
zugehörigen Kundenbeleg zurückspiegeln (Direktlieferung).
Ergebnis: Lieferantenauftrag und Kundenbeleg sind positionsweise verknüpft; Bestellungen gelten als
vollständig oder teilweise fakturiert (SupplierOrderState.InvoiceComplet/InvoicePart).
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetReceiptForwardedInto (SupplierOrderState.
InvoiceComplet / InvoicePart je Position) - Begründung: setzt den Fakturierungsgrad der
Beschaffungsposition technisch um.
- [SEKUNDÄR] BL-Klassen SupplierOrderBL.cs, SupplierInvoiceSpecificLogic.cs, SupplierDeliveryListBL.cs -
Begründung: eigene Strategieimplementierung je Lieferantenbelegart.
- [KONTEXT] src/centron/Centron.WPF.UI/Modules/Purchasing (136 Dateien) - Begründung: eigene UI-Gruppe Einkauf.
Prüfidee: Lieferantenrechnung auf teillieferten Auftrag fakturieren; der Kundenbeleg zeigt „teilweise
fakturiert", erst nach letzter Position „vollständig fakturiert".
Tracelinks: StRS-001, SyRS-002, SyRS-016, SwRS-001
Konsolidierung: Kandidat: StRS-001 (identische Belegmaschine, andere Richtung – Zusammenführung auf ein
Belegmodell mit Rollenattribut Kunde/Lieferant prüfen).
Übernahmewürdigkeit: übernehmen - unverzichtbarer Gegenzug zum Vertrieb.
Status: belegt
```
```
ID: StRS-003
Titel: Mandanten- und Filialfähigkeit einer Installation
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Mandantenbetreuer, Geschäftsführung
Vorbedingung: Mandant und Filialen sind als Stammdaten gepflegt.
Fakt: Tabellen Mandant, MandantenStammdat, Filiale, FilialeLeiter, FilialeToLager, Branch,
BranchToStock, CustomerToBranches; Nummernkreisanlage CreateNumberGroups(int mandantI3D,
int? branchI3D); Belegattribut BranchOrigin (Enum BranchOrigin.Creator) mit Einstellungs-
schlüssel AppSettingsConst.LoadAssetBranchDataFrom („Filialdaten laden von dem").
Aussage: Das System soll mehrere rechtliche Einheiten (Mandanten) und mehrere Niederlassungen
(Filialen) in einer Installation führen; Belege, Nummernkreise, Lager und Erlöskonten
sind der jeweiligen Einheit zuzuordnen.
Ergebnis: Jeder Beleg trägt seine Filiale; Nummernkreise werden je Mandant/Filiale geführt;
Auswertungen sind je Filiale trennbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, CreateNumberGroups(mandantI3D,
branchI3D) (Zeile 154) - Begründung: Nummernkreise werden mandanten- und filialabhängig erzeugt.
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, UpdateReceiptBranch + BranchOrigin-Zuweisung -
Begründung: die Filialzugehörigkeit jedes neuen Belegs wird aus einer Konfiguration abgeleitet.
- [SEKUNDÄR] Tabellen Mandant, MandantenStammdat, Filiale, BranchToStock, WarenFilialeErloeskonto - Begründung:
datenseitige Trennung nach Mandant/Filiale inkl. filialabhängiger Erlöskonten.
Prüfidee: Zwei Filialen mit eigenen Nummernkreisen anlegen; in beiden je eine Rechnung erzeugen →
beide Nummern laufen getrennt, Filiale des Belegs stimmt mit Anlagefiliale überein.
Tracelinks: SyRS-011, SwRS-007, SwRS-023, SwRS-026
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - tragender Grund, warum Mandant und Filiale in praktisch jeder Tabelle auftauchen.
Status: belegt
```
```
ID: StRS-004
Titel: Einheitlicher Geschäftspartnerstamm für Kunden, Interessenten und Lieferanten
Ebene: StRS
Typ: Daten / funktional
Qualitätsmerkmal:
Akteur: Innendienst, Buchhaltung
Vorbedingung: –
Fakt: Zentrale Tabelle Accounts mit Typisierung über AccountTypes / AccountTypeToAccounts,
Speziali­sierungen AccountCustomers, AccountSuppliers, AccountContracts, AccountProduct,
AccountRelationships; darunter Adressen (AccountAddresses, AbweichendeAnschrift) und
Ansprechpartner (AccountAddressContacts, KontaktePersonen); Altbestand Kunden, Kreditor,
Interessent, OneWayContact, Personen bleibt parallel bestehen.
Aussage: Das System soll jeden Geschäftspartner genau einmal in einem einheitlichen Stamm führen und
die Eigenschaften Kunde, Lieferant, Interessent, Konzernzugehörigkeit als Rollen desselben
Partners abbilden; Anschrift und Ansprechpartner sind wiederverwendbar zuzuordnen.
Ergebnis: Belege, Verträge, Helpdesk-Tickets und Assets referenzieren denselben Partner; eine
geaenderte Schreibweise eines Namens wirkt auf alle Bezugnahmen.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Accounts / AccountTypes / AccountTypeToAccounts /
AccountCustomers / AccountSuppliers / AccountRelationships - Begründung: Rollenmodell des
Partnerstamms ist als Tabellenstruktur umgesetzt.
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetExclusiveOfVat liest Kunden-
(CustomerFinanceInformation) und Lieferantenseite (Kreditor.MwStNichtAusweisen) unterschiedlich -
Begründung: belegt, dass beide Rollen heute noch getrennt gelesen werden.
- [SEKUNDÄR] UI src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement (77 Dateien) - Begründung:
gemeinsame Pflegeoberfläche.
Prüfidee: Partner als Kunde und Lieferant gleichzeitig anlegen; Namensänderung im Stamm muss auf
Kunden- und Lieferantensicht gleichziehen.
Tracelinks: StRS-005, SyRS-011, SwRS-016
Konsolidierung: Kandidat: SwRS-016 – Tabellen Altbestand (Kunden, Kreditor, Interessent) vs. neuer
Account-Stamm bilden denselben Gegenstand doppelt ab.
Übernahmewürdigkeit: übernehmen (Zielmodell: nur noch der Account-Stamm) - Altbestands Tabellen sind
Migrationsbestandteile.
Status: belegt
```
```
ID: StRS-005
Titel: Kundenindividuelle Preise und Konditionen im Beleg
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst, Außendienst
Vorbedingung: Artikel ist gepflegt; für Kunde/Vertrag können Sonderpreise hinterlegt sein.
Fakt: ReceiptItemPriceBL.GetBasePrice berechnet (basePrice, discount) in fester Reihenfolge aus
Verkaufspreis, Sondervereinbarung (EKVKReduction/VKReductionProcent), Vertrags-Sonderpreis
(ContractSpecialPrice) und Kunden-Sonderpreis (CustomerSpecialPrice); Tabellen
KundenSonderpreise, Sondervereinbarung/-Artikel, ArtikStaffelpreise, ArtikelVolumePrices.
Aussage: Das System soll den im Beleg angesetzten Preis automatisch aus den kundenspezifischen
Vereinbarungen ableiten und dem Bearbeiter nur die Kontrolle bzw. die ausdrückliche
Abweichung erlauben.
Ergebnis: Position erhält Basispreis und Rabatt aus der höchstrangigen gültigen Vereinbarung;
die Herkunft ist im Beleg nachvollziehbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs, GetBasePrice
(Zeilen 144 ff.), GetContractSpecialPrice (Zeile 169), GetSpecialPrice (Zeile 588) -
Begründung: deterministische Preiskette ist dort als Code implementiert und erzwungen.
- [SEKUNDÄR] UI src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PriceMatrix, PositionToSpecialPrice -
Begründung: Bearbeitungsoberflächen der Preisherkunft.
Prüfidee: Für Artikel A Kunden-Sonderpreis und Vertrags-Sonderpreis gleichzeitig hinterlegen;
Belegposition anlegen → es greift die dokumentierte Vorrangfolge, kein manueller Eingriff nötig.
Tracelinks: SyRS-004, SwRS-004, SwRS-031
Konsolidierung: Kandidat: StRS-006 – Vertragspreislogik ist zweimal implementiert (KundenSonderpreise und
ContractSpecialPrice) und sollte in einem Preismodell aufgehen.
Übernahmewürdigkeit: übernehmen - Kern der Kalkulation und damit Kern des Geschäftsmodells.
Status: belegt
```
```
ID: StRS-006
Titel: Vertragsgeschäft mit Kontingenten, Zählern und wiederkehrender Abrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Innendienst, Servicetechniker, Buchhaltung
Vorbedingung: Vertrag (Wartung/Service/Full-Service) mit Laufzeit und Bepreisung ist geschlossen.
Fakt: Vertragstabelle ContractClass ist eigene Belegart in CanForwardReceiptsInto; Tabellen
VertragKopf/VertragPos, VertragKontingent*, VertragPosZaehler*, ZaehlerArt,
VertragBepreisung*/VertragsArtBepreisung*, VertragRechKopfZuordnung; Beleglog-Felder
ContingentKind/ContingentValue/ContingentUsedHours/ContingentResidualValueStart.
Aussage: Das System soll Dauerschuldverhältnisse als eigenständiges Objekt mit Leistungskontingent
(Betrag oder Stunden), Zählerstand und Preisregel führen und die Abrechnung aus dem
Verbrauch des Kontingents ableiten.
Ergebnis: Verbrauchsänderungen am Kontingent werden protokolliert; die Abrechnung referenziert
Vertrag und Verbrauch.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, WriteReceiptLogs – bedingte Log-Einträge
für ContingentKind/-Value/-UsedHours/-UsedAmount/-ResidualValueStart - Begründung: erzwingt
lückenlose Protokollierung jeder Kontingentbewegung.
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE VertragKontingent, VertragPosZaehler, ZaehlerArt,
VertragRechKopfZuordnung - Begründung: Kontingent-, Zähler- und Abrechnungsbeziehung sind
datenmodellseitig angelegt.
- [SEKUNDÄR] UI Modules/Finances/Contracts (156 Dateien), ContractEvaluation2 (4 Dateien) - Begründung:
eigene Vertragsbearbeitung und -auswertung.
Prüfidee: Stundenkontingent 10 h; Helpdeskzeit 3 h verbuchen → Restkontingent 7 h, Logeintrag mit
Alt-/Neuwert und Bearbeiter vorhanden.
Tracelinks: StRS-007, SyRS-001, SwRS-002, SwRS-032
Konsolidierung: Kandidat: StRS-005 (Preisregeln für Vertrag und Kunde getrennt), StRS-010 (Pauschalabrechnung)
Übernahmewürdigkeit: übernehmen - wiederkehrende Erlöse sind wirtschaftliche Basis des Unternehmens.
Status: belegt
```
```
ID: StRS-007
Titel: servicezeiterfassung mit Kundensignatur und Übergabe in die Abrechnung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Servicetechniker, Support-Mitarbeiter, Abrechnung
Vorbedingung: Helpdesk-Ticket existiert; Mitarbeiter-Artikel ist gepflegt.
Fakt: Tabellen hlpdsk_timer, hlpdsk_timer_signature, hlpdsk_timer_typen, hlpdsk_timer_log,
HelpdeskTimerBillingStates, HelpdeskTimerSpecialArticles, Reisekosten*/ServiceArbeiten;
HelpdeskTimerBL erstellt Belegpositionen aus Zeiten; Rechte EDIT_TIME, OWN_TIME_EDIT,
MOVE_HELPDESK_TIMER, DELETE_HELPDESK_TIMER, DELETE_HELPDESK_SIGNATURE (CentronRights.md §7–§9).
Aussage: Das System soll erbrachte Servicezeiten pro Ticket erfassen, gegen Zeichner- und
Berechtigungsregeln schützen, per Kunde signierbar machen und unverändert in die
Rechnungsposition überführen.
Ergebnis: Zeit ist einem Bearbeiter zugeordnet, optional signiert, und entweder offen (verschieb-/
löschbar) oder einem Beleg zugewiesen (gesperrt).
Ergebnis-Nachtrag: Zeichenberechtigung und Löschrecht sind getrennt zu betrachten; das Löschen ist nach
Belegzuordnung ausgeschlossen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, Zeile 556 ff. –
HasUserRight(UserRightsConst.Sales.Customer.Helpdesk.DELETE_HELPDESK_TIMER) und
„Die Helpdesk Zeit wurde einem Beleg zugewiesen. Löschen ist nicht möglich." - Begründung:
beide Schutzwirkungen werden an dieser Stelle durchgesetzt.
- [SEKUNDÄR] CentronRights.md §7.1 „This is a restricting right … the employee article of the time record
must belong to the user" - Begründung: dokumentiert die fachliche Absicht der Einschränkung.
- [KONTEXT] Tabelle hlpdsk_timer_signature - Begründung: Signatur ist als eigenständige Speicherung angelegt.
Prüfidee: Zeit an Beleg überführen, danach DELETE versuchen → Fehlermeldung, Satz bleibt erhalten;
Bearbeiter B ohne OWN_TIME_EDIT darf Zeit von A nicht ändern.
Tracelinks: StRS-006, SyRS-022, SwRS-012, StRS-019
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - direkte Erlösquelle des Servicebereichs.
Status: belegt
```
```
ID: StRS-008
Titel: Forderungsausfallrisiken的 Steuerung über Mahnwesen mit Belegsperre
Ebene: StRS
Typ: funktional / Sicherheit
Qualitätsmerkmal:
Akteur: Buchhaltung, Kreditorenbuchhaltung, Innendienst
Vorbedingung: Rechnung ist offen und überfällig.
Fakt: MahnlaufBL/DunningBL mit Mahnstufen 1–3 (GetCustomerOrSupplierDunningLevel liefert
0/1/2/3); ReceiptBL.CanUserCreateNewReceiptsAtCustomerOrSupplier vergleicht Mahnstufe mit
BlockNewReceiptsDunningLevel und meldet „Aufgrund der Mahnstufe darf kein neuer Beleg …
angelegt werden"; Mahnbrichte über Reportgruppe ReportGroupConstants.MAHNUNG; Tabellen
Mahnlauf, Eskalationen, EskalationTypen, EskalationsLog.
Aussage: Das System soll den Zahlungskredit eines Kunden in Stufen abbilden und ab einer
konfigurierbaren Stufe die automatische Sperre weiterer Beleganlage auslösen.
Ergebnis: Bei Mahnstufe >= Sperrstufe wird jede Neubeleganlage für den betroffenen Partner
abgewiesen; der Mahnbricht wird im Report definiert.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CanUserCreateNewReceiptsAtCustomerOrSupplier
(Zeile 10194 ff.) inkl. Aufruf BlockNewReceiptsDunningLevel - Begründung: die Sperre wird beim
Anlegen jedes Belegs geprüft.
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Zeile 150 –
ReportGroupConstants.MAHNUNG als Pflicht-Reportgruppe, sonst Exception - Begründung: erzwingt
eine definierte Mahnbruchvorlage je Mandant.
- [SEKUNDÄR] Tabellen Mahnlauf, Eskalationen, EskalationStatistik - Begründung: Ablage der Läufe und Stufen.
Prüfidee: Mahnstufe 2 setzen, Sperrstufe 2 → Anlage eines Angebots wird abgewiesen; Stufe zurücksetzen
→ Anlage wieder möglich.
Tracelinks: SyRS-005, SyRS-023, SwRS-014, StRS-018
Konsolidierung: Kandidat: StRS-013 – Eskalationslogik für Tickets und für Forderungen verwenden dieselben
Eskalationstypen-Tabellen für unterschiedliche Fachdomänen.
Übernahmewürdigkeit: übernehmen - existenzielle Risikosteuerung.
Status: belegt
```
```
ID: StRS-009
Titel: Übergabe aller relevanten Vorgänge an die Finanzbuchhaltung
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Buchhaltung, Fremtbuchhaltungssystem
Vorbedingung: Buchhaltungssystem ist als Exportziel konfiguriert (BookKeepingAccountSystems).
Fakt: BookKeepingExportBL mit LoadExportSettings, GetExportCustomerBookingData,
GetBookKeepingExportCustomer/SupplierDataHistory, GetBookKeepingExportCashBookDataHistory,
GetBookKeepingExportFileInfo; unknown Typ → Exception „Unknown BookKeepingType"; Tabellen
BookKeepingExport*, BookKeepingImportInterfaces*, BuchhaltungsExportDeb/Kred/Kasse/SageKHK,
BuchhaltungsExpDebPerson/KredPerson, FibuExportBuchungstextEinstellungen.
Aussage: Das System soll Kundensachverhalte, Lieferantensachverhalte, Stammdatenänderungen und
Kassenbewegungen in einem konfigurierbaren Format an eine externe Finanzbuchhaltung übergeben
und den Exportzeitpunkt je Datensatz nachvollziehbar marcaieren.
Ergebnis: Exportdatei wird je Konfiguration erzeugt; exportierte Datensätze sind als exportiert
gekennzeichnet und werden nicht erneut übergeben.
Belege:
- [PRIMÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs, Zeilen 441–449 und 789 –
throw new ArgumentOutOfRangeException("Unknown BookKeepingType") - Begründung: erzwingt die
Anmeldung jeder Buchhaltungsart im Code, unbekannte Typen scheitern laut.
- [SEKUNDÄR] Tabellen BookKeepingExportCustomInterfaceColumns/-Settings, FibuExportBuchungstextEinstellungen -
Begründung: Format und Texte sind konfigurierbar gehalten.
- [SEKUNDÄR] Beleg-Flag „IsAlreadyExported" (ReceiptBL.HandleIsAlreadyExported) - Begründung: Exportstatus
ist am Beleg geführt.
Prüfidee: Rechnung erzeugen, Export laufen lassen, Export erneut starten → Rechnung wird nicht
erneut ausgegeben.
Tracelinks: SyRS-015, SwRS-028, StRS-011
Konsolidierung: Kandidat: SwRS-028 – mehrere, teils parallele Exportformate (SageKHK, Kasse, Deb/Kred) für
denselben Vorgang.
Übernahmewürdigkeit: übernehmen (Funktionsumfang), die konkrete Formatvielfalt ist übernahmefähig zu bündeln.
Status: belegt
```
```
ID: StRS-010
Titel: Automatisierte und pauschale Abrechnung wiederkehrender Vorgänge
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Abrechnung, Buchhaltung
Vorbedingung: Pauschalvertrag, Flatrate oder abrechenbare Sammelvorgänge liegen vor.
Fakt: UI-Module Modules/Finances/AutomatedBilling (58), FlatrateBilling (37), TimerBilling (75),
ContractEvaluation2; BL-Seitig ReceiptInvoiceBL, DownPaymentBL, OposBL/OposRunBL,
LeasingRateBL, ServiceRateBL, HourlySurchargeRatesBL, Tabellen LeasingSaetze/LeasingFaktor,
ServiceSaetze, HourlySurchargeRates/-Items.
Aussage: Das System soll wiederkehrende Forderungen (Pauschalen, Leasing- und Service-Raten,
Zeitkontingente, Anzahlungen und Schlussrechnungen) automatisch erzeugen, ohne dass je
Vorgang ein Beleg manuell angelegt werden muss.
Ergebnis: Sammelläufe erzeugen Belege mit Referenz auf die zugrunde liegenden Einzelvorgänge;
Anzahlungen werden bei der Schlussrechnung gegen­gerechnet.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/DownPayment/DownPaymentBL.cs sowie ReceiptBL.Validate-
ReceiptForwarding, Anzahlungs-Hinweistext „… für den es Anzahlungsrechnungen gibt … sollte
daher nicht manuell in eine Rechnung weiterverarbeitet werden" - Begründung: erzwingt die
Anzahlungs-/Schlussrechnungs-Logik beim Weiterverarbeiten.
- [SEKUNDÄR] UI-Module AutomatedBilling, FlatrateBilling, TimerBilling - Begründung: eigene Bedienbereiche.
Prüfidee: Auftrag mit Anzahlung anlegen, Lieferschein weiterverarbeiten → Warnung zur Anzahlung;
Schlussrechnung gleicht Anzahlungssaldo aus.
Tracelinks: StRS-006, SyRS-001, SwRS-006
Konsolidierung: Kandidat: StRS-006 – Vertragsabrechnung und Pauschalabrechnung bilden dieselbe
wiederkehrende Forderung zweifach ab.
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-011
Titel: Revisionssichere Belegfassung: Version, Storno und Wiederverwendung
Ebene: StRS
Typ: funktional / Daten
Qualitätsmerkmal:
Akteur: Innendienst, Buchhaltung, Wirtschaftsprüfer
Vorbedingung: Beleg existiert in einer Fassung.
Fakt: Belegstatus enum ReceiptState { Active=1 „offen", Completed=2 „abgeschlossen",
Canceled=3 „storniert" }; je Belegart Versions-Tabellen (AngKopfVersions, BestKopf… nicht,
LiefKopfVersions, RechKopfVersions, GutKopfVersions, VertragKopfVersions, AufKopfVersions);
ReceiptBL.CreateNewVersion erhöht Version und prüft aktive Seriennummern sowie
„Die aktuelle Version dieses Belegs wurde bereits weiterverarbeitet."
Aussage: Das System soll jede Änderung an einem erfassten Beleg als neue Fassung erhalten, die
frühere Fassung unverändert aufbewahren und Storno als Status, nicht als Löschung abbilden.
Ergebnis: Alle Fassungen sind numeriert und aufrufbar; eine bereits weiterverarbeitete Fassung kann
nicht erneut geändert werden.
Belege:
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs – Enumeration mit
Description-Attributen offen/abgeschlossen/storniert - Begründung: abschliessender
Statuskorpus eines Belegs.
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewVersion<T> (receipt.Version =
currentReceiptVersion.Version + 1) inkl. Prüfung GetReceiptForwardedInto - Begründung:
Versionsbildung und Sperre weiterverarbeiteter Fassungen werden dort erzwungen.
- [SEKUNDÄR] Versions-Tabellen je Belegart in SSMS_DB_SCHEMA.sql - Begründung: Fassungen sind
datenmodel­seitig getrennt gehalten.
Prüfidee: Version 1 weiterverarbeiten, dann neue Version aus Version 1 erzeugen → Meldung
„bereits weiterverarbeitet", keine neue Fassung.
Tracelinks: SyRS-002, SwRS-002, SwRS-015, StRS-025
Konsolidierung: Kandidat: SwRS-015 – Versionshaltung ist je Belegart einzeln implementiert.
Übernahmewürdigkeit: übernehmen - GoBD-relevante Anforderung.
Status: belegt
```
```
ID: StRS-012
Titel: Abgabekonforme elektronische Rechnung (ZUGFeRD) und Signatur beim Versand
Ebene: StRS
Typ: funktional / nicht-funktional
Qualitätsmerkmal: Compliance (Rechtssicherheit); primäres ISO-25010-Merkmal: Wartbarkeit
Akteur: Buchhaltung, Finanzverwaltung, Kunde
Vorbedingung: ZUGFeRD ist global oder je Kunde aktiviert; Rechnung oder Gutschrift liegt vor.
Fakt: ReceiptBL.CreateFullReportForReceipt: für InvoiceClass und CreditVoucherClass bei
InvoiceZugferdBL.IsZugferdEnabled() oder GetLocalZUGFeRDSetting(receipt) wird
CreateZugferdConformPdfDocument mit Leitweg-ID erzeugt; Fallback ohne Positionen-Layout-Item:
„Für ZUGFeRD muss ein PDF Dokument über die Rechnung erzeugt werden.";Zustand Canceled
ausgenommen. Beim ReportAction Mail/Export greift PdfSigningBL.SignPdfDocument.
Leitweg-ID wird vorrangig aus der Konzernobergesellschaft geholt.
Aussage: Das System soll Ausgangsrechnungen und Gutschriften als syntaktisch korrektes hybrides
PDF mit eingebettetem strukturiertem Rechnungsdatensatz erzeugen, die Leitweg-ID des
Empfängers befüllen und auf Wunsch digital signieren.
Ergebnis: PDF enthält den ZUGFeRD-Anhang; Leitweg-ID stammt aus Konzern- oder Kundendatensatz;
signierter Versand ist von der Verfügbarkeit der Signaturkomponente abhängig.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateFullReportForReceipt –
Bedingungsblock (InvoiceClass || CreditVoucherClass) && IsZugferdEnabled() && State != Canceled,
Aufruf InvoiceZugferdBL.CreateZugferdConformPdfDocument(... GetLeitwegID(...)) - Begründung:
die Erzeugung wird im Ausgabepfad hart erzwungen.
- [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs (SignPdfDocument, IsPdfSigningAvailable) -
Begründung: Signatur ist an dieselbe Bedingung gekoppelt.
- [SEKUNDÄR] Tabellen EDIInvoiceHead/-Items, EDIInvoiceBarcodes, DocuFormSettings, ZugferdImport - Begründung:
Strukturdaten und Importpfad sind vorhanden.
Prüfidee: Rechnung mit aktivem ZUGFeRD drucken → PDF enthält XML-Anhang; Storno-Rechnung ohne Anhang.
Tracelinks: StRS-009, SyRS-013, SyRS-014, SwRS-021
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht.
Status: belegt
```
```
ID: StRS-013
Titel: Helpdesk- und Ticketbearbeitung mit Zuständigkeit, Fälligkeit und Eskalation
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Support-Mitarbeiter, Helpdesk-Leiter, Kunde (Sichtbarkeit)
Vorbedingung: Ticket ist angelegt oder aus Beleg automatisch erzeugt (AppSettingsConst.AutomHelpdesk).
Fakt: Rechte SHOW_HELPDESK, SHOW_HELPDESK_ONLY_OWN, SHOW_HELPDESK_ONLY_OWN_BRANCH,
ADD_NEW_HELPDESK, EDIT_HELPDESK, ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS, MATURITY_CHANGE,
CLOSE_REQUEST (CentronRights.md §1–§6); BL HelpdeskStatusBL, HelpdeskPrioritiesBL,
EscalationBL, HelpdeskForwardBL, HelpdeskCloseBL, HelpdeskSchedulerBL; Tabellen
hlpdsk_requests, hlpdsk_status, hlpdsk_prioritaeten, hlpdsk_history, Eskalationen,
EscalationsLog, EstimatedProgressForHelpdesks.
Aussage: Das System soll Support-Vorgänge mit Status, Priorität, Fälligkeit, Verantwortlichem und
Historie führen, die Sicht- und Bearbeitbarkeit nach Person, Abteilung und Filiale
einschränken und Überschreitungen automatisch eskalieren.
Ergebnis: Ein nicht berechtigter Nutzer sieht das Ticket weder in Liste noch im Zugriff;
Eskalationen werden mit Zeitstempel protokolliert.
Belege:
- [PRIMÄR] CentronRights.md §1.1/§1.2 – „This is a restricting right. If the user has this right, he
should only see and access tickets where he is either editor or responsible person." -
Begründung: benennt die durchzusetzende Sichtbarkeitsregel inkl. Konstantennamen.
- [PRIMÄR] src/backend/Centron.BL/Administration/Rights/UserRightsExt.cs / AppRightsBL.HasUserRight -
Begründung: zentrale Prüfstelle aller Rechte.
- [SEKUNDÄR] Tabellen hlpdsk_status, hlpdsk_history, EscalationsLog - Begründung: Status- und
Eskalationshaltung ist datenmodel­seitig vorhanden.
Prüfidee: Nutzer mit SHOW_HELPDESK_ONLY_OWN ruft Ticketliste auf → nur eigene Tickets; direkter
Aufruf fremder Ticket-I3D wird abgewiesen.
Tracelinks: StRS-007, StRS-019, SyRS-006, SyRS-022
Konsolidierung: Kandidat: SwRS-024 – zwei Helpdesk-Datenhaltungen (hlpdsk_* und Helpdesk*) im selben System.
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-014
Titel: IT-Assetlebenszyklus beim Kunden als Grundlage von Service und Abrechnung
Ebene: StRS
Typ: funktional / Daten
Qualitätsmerkmal:
Akteur: Servicetechniker, IT-Betreuer, Helpdesk
Vorbedingung: Kunde hat Geräte, Lizenzen und Verträge betreut.
Fakt: Über 240 Tabellen mit Präfix AssetManagement* (Device-, AD-, DHCP-, DNS-, IIS-, SQL-,
HyperV-, VMWare-, Backup-, Patch-, License-, Documentation-Bereiche) plus CMan*-Tabellen
(CManMachine, CManSoftware, CManPhysicalMemory …) plus separate Tabellen Printer, Equipment,
EquipmentTyp, GeraeteKopf/GeraetePos, GeraeteWartung, hlpdsk_geraete, HlpDsk_Geraete;
LicenseKopf/LizenzPos, VertragGeraete, AnlageFreigaben*.
Aussage: Das System soll die beim Kunden betreute IT-Infrastruktur (Geräte, Software, Lizenzen,
Verträge, Netzwerkkomponenten) inventarisieren, mit Hilfedesk-Tickets verbinden und die
Datenbasis für Wartungsverträge und Prüfnachweise liefern.
Ergebnis: Ein Gerät ist einem Kunden zugeordnet, mit Ticket-Historie, Lizenz und Vertrag verknüpft;
Erkannte Eigenschaften (CPU, RAM, Volumen, OS) werden gepflegt oder eingelesen.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AssetManagementDevices, AssetManagementLicenseSoftware,
AddressToAsset, hlpdsk_geraete - Begründung: Geräte sind eigene Entität mit Kunden- und
Ticketbeziehung.
- [SEKUNDÄR] UI src/centron/Centron.WPF.UI/Modules/Finances/Crm (532 Dateien) und Helpdesk (316 Dateien) -
Begründung: Asset-Pflege ist über Vertrieb und Helpdesk verteilt.
- [KONTEXT] Tabelle hlpdsk_nable_link, NableServices - Begründung: Anbindung eines externen Monitorings.
Prüfidee: Gerät einem Kunden zuordnen, Ticket auf Gerät anlegen → Gerät, Kunde, Ticket sind
gegenseitig referenziert.
Tracelinks: StRS-013, StRS-006, SwRS-017
Konsolidierung: Kandidat: StRS-017, SwRS-017 – „Stamtblatt" (Drucker) und „Asset" sind zwei Datenhaltungen
für denselben Gegenstand; zusätzlich CMan* vs. AssetManagement*.
Übernahmewürdigkeit: übernehmen (Funktionsumfang) – die parallele Zweitablage ist als Workaround zu werten.
Status: belegt
```
```
ID: StRS-015
Titel: Erfassung und Auswertung von IT-Stammdaten aus Fremdsystemen
Ebene: StRS
Typ: Schnittstelle
Qualitätsmerkmal:
Akteur: Servicetechniker, CMan-Client, Überwachungsdienst
Vorbedingung: Client-Agent oder Abfragedienst ist beim Kunden installiert bzw. konfiguriert.
Fakt: Tabellen GeraeteCMan*, CManMachine, CManEventLog, CManIntegrityFile/-Server, CManThreshold,
CManLANResources, Monitoring* (MonitoringTemplates, MonitoringDataChecks, MonitoringDataFailures,
MonitoringServiceSettings), MonScripts, AssetManagement*Checks/-SnmpDetails,
ExpectedEvents/ExpectedEventLogEntries, StopwatchNotifications;
RemoteConnections/-RDP/VNC/Web/Putty-Metadaten, RemoteCredentials.
Aussage: Das System soll Zustands- und Konfigurationsdaten von Kunden-IT aus Agenten, SNMP- und
Protokollabfragen übernehmen, gegen Schwellwerte prüfen, Abweichungen melden und
Supportzugänge strukturiert ablegen.
Ergebnis: Prüfergebnisse mit Zeitstempel und Fehlerhistorie; meldepflichtige Abweichung erzeugt
Benachrichtigung bzw. Ticket.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE CManThreshold, MonitoringDataFailures,
AssetManagementCheckErrorLogs - Begründung: Schwellwert und Fehlerspeicher sind datenmodelseitig
erzwungen.
- [SEKUNDÄR] Tabelle RemoteCredentials, RemoteRDPMetadatas - Begründung: Ablagestruktur für Supportzugänge.
- [KONTEXT] src/apis/Centron.APIs.FinAPI, NableServices - Begründung: Hinweise auf externe Dienste.
Prüfidee: Festgelegter Schwellwert unterschreiten → MonitoringDataFailure-Eintrag und Benachrichtigung.
Tracelinks: StRS-014, StRS-013, StRS-022
Konsolidierung: Kandidat: StRS-014 – Überwachungsdaten liegen in zwei Systemwelten (CMan* und
AssetManagement*/Monitoring*).
Übernahmewürdigkeit: übernehmen (Funktionsumfang); die doppelte Erfassung ist Migrationskandidat.
Status: belegt
```
```
ID: StRS-016
Titel: Eindeutige Warennachverfolgbarkeit über Seriennummer und Barcode
Ebene: StRS
Typ: funktional / Daten
Qualitätsmerkmal:
Akteur: Lagerist, Einkauf, Service
Vorbedingung: Artikel ist seriennummerngeführt; Bestand ist angelegt.
Fakt: BarcodeBL erzwingt Eindeutigkeit: „SN existiert bereits" (CreateNewBarcode), „SN ist bereits
vorhanden" (RenameBarcode), „The barcode … is already assigned to an order";
Seriennummernbereichsvergabe GetNextAvailableSerialNumberArea; Zustandswechsel
UpdateSerialNumberState, Ausbuchung CheckOutBarCodes, Historie BarcodeHistory;
Tabellen Barcode, BarCode2, AufBarcodes, RMAPosSN, InventurSeriennummern,
SeriennummerToPosition, XMLLockList.
Aussage: Das System soll jede seriennummergeführte Einheit eindeutig und systemweit unverwechselbar
identifizieren, ihren Bestand, Zustand und Lagerort führen und jeden Zustands- und
Standortwechsel über den gesamten Lebenszyklus nachvollziehbar speichern.
Ergebnis: Zweite Anlage derselben Seriennummer wird abgewiesen; Umbuchung auf ein Stammblatt nur bei
passendem Bestand möglich.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Warehousing/BarcodeBL.cs, CreateNewBarcode (Zeile 634 ff., „SN existiert
bereits"), RenameBarcode (Zeile 740 ff.), UpdateBarcodeSetInOrderState (Zeile 80 ff.) -
Begründung: Eindeutigkeit und Auftragsbindung werden dort geprüft.
- [PRIMÄR] ReceiptBL.ValidateReceiptForwarding – Prüfungen barcodesStillInReceiptResult,
enoughBarcodesResult - Begründung: Weiterverarbeitung scheitert bei fehlender/gebundener Seriennummer.
- [SEKUNDÄR] Tabellen Barcode, BarCode2, BarcodeHistory, XMLLockList - Begründung: Zwei Barcode-Tabellen
plus Sperrliste belegen die Nachverfolgungs- und Konkurrenzabsicht.
Prüfidee: Seriennummer „SN1" zwei Artikeln zu geben → zweite Anlage schlägt fehl; Lieferschein ohne
ausreichende aktive Seriennummern wird abgewiesen.
Tracelinks: StRS-018, SyRS-020, SwRS-013, SwRS-005
Konsolidierung: Kandidat: SwRS-013 – Barcode/BarCode2 Doppelhaltung.
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-017
Titel: Warenwirtschaft: Artikelstamm, Bestand, Lagerorte und Kommissionierung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Einkauf, Lager, Vertrieb
Vorbedingung: Artikel, Lager und Filialen sind gepflegt.
Fakt: ArtikelBL, GeneralArticleBL, ArticleStockBL, StockBL, StorageAreaBL, StoragePlaceBL,
SecondStockArticleBL (Nebenlager), CommissioningBL, OrderCommissionBL,
PartialCommissionOrderBL, InventoryBL/InventoryNewBL; Tabellen Artikel, ArtikelBestand,
ArtikelStueckliste, Lagerort, LagerorteQM, Lagerplatz, Nebenlager/NebenlagerArtikel,
LagerUmbuchungsliste, Warehouse, Warehouses, Teilkommissionierung
(PartialCommissionOrders/-ItemToBarcodeRelations).
Aussage: Das System soll Artikel mit Bestand je Lager und Lagerort führen, Reservierungen und
Teilkommissionierungen unterstützen und Bestandsbewegungen als Buchung abbilden.
Ergebnis: Bestand je Artikel/Lager ist ausbuchbar; eine Teilkommissionierung erzeugt eigene
Liefervorschläge mit abweichender Lieferadresse.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, ValidateReceiptForwarding (ArtikelLager-
Prüfung articleWarehousesAreValidResult) und Teilkommissionierungs-Zweige - Begründung:
Lagerbezug jeder Position wird beim Weiterverarbeiten geprüft.
- [SEKUNDÄR] UI Modules/Warehousing (529 Dateien), Subfolder Inventory, Commissioning, Commissions -
Begründung: eigene Masken für die Lagervorgänge.
- [KONTEXT] README.md Abschnitt „WebCart" - Begründung: bestätigt Warenwirtschaft als Datengrundlage
des Kunden-Shops.
Prüfidee: Artikel an zwei Lagerorten; Auslieferung aus einem Ort mindert nur dort den Bestand.
Tracelinks: StRS-016, StRS-001, SwRS-016, SwRS-029
Konsolidierung: Kandidat: StRS-014 – „Anlage/Stamtblatt" und „Artikel" werden an mehreren Stellen zusammen
geführt (AnlageFreigabenWarengruppen, KundeToArtikel).
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-018
Titel: Rücksendung, Reparatur und gesetzliche Geräteprüfung
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Service, Kunde, Prüfer
Vorbedingung: Gerät mit Seriennummer ist einem Kunden zugeordnet.
Fakt: RMA-Tabellefamilie RMAAnfKopf/-Pos, RMAKopf/-Pos/-PosSN/-PosStatus, RMARepKopf/-Pos,
RMARueckKopf/-Pos, RmaSendForth/SendBack, KundenRMA/KundenRMASN; Reparaturfamilie
RepaKopf/-Artikel/-Pruefling/-Pruefmittel/-Arbeitssicherheit/-Umweltschutz je mit
*History, RepEingangKopf/-Pos; Prüf-/Arbeitsschutzfamilie Wartung*, Prufmittel, Pruflinge,
Prufvorschrift/-Messwert, Arbeits­schutz, Arbeitssicherheit, Umweltschutz, Unterweisungen,
PersonUnterweisung; eigene UI-Module Rma (33), QM (8), Production (28).
Aussage: Das System soll Rücksende- und Reparaturvorgänge als eigene Belegkette abbilden und
wiederkehrende Prüfungen von Arbeitsmitteln und ortsveränderlichen Geräten inklusive
Prüfvorschrift, Messwert und Nachweisführung unterstützen.
Ergebnis: RMA-Status je Position wird geführt; Prüflinge haben Fristen, Prüfergebnisse werden
revisionssicher mit Historie gespeichert.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE RMAPosStatus, PrufvorschriftMesswert, WartungHistoryMesswert,
WartungHistoryPruflinge - Begründung: Status je RMA-Position und Messwert-Historie sind als
Tabellen umgesetzt.
- [SEKUNDÄR] UI-Ordner Modules/Rma, Modules/QM; Tabelle RepaKopfHistory - Begründung: eigene Bearbeitung
und versionierte Prüfnachweise.
Prüfidee: RMA-Position auf Status „zurückgesandt" setzen; Prüffrist eines Prüflings ablaufen lassen →
Wiedervorlage/Erinnerung wird erzeugt.
Tracelinks: StRS-016, StRS-014, StRS-002
Konsolidierung: Kandidat: StRS-014 – Wartungs-/Prüfdatenhaltung existiert mehrfach (Wartung*, Repa*,
GeraeteWartung).
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-019
Titel: Wer darf was sehen: Rollen-, Filial- und Bereichsbezogene Zugriffssteuerung
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Systemadministrator, Vorgesetzter, Sachbearbeiter
Vorbedingung: Benutzer ist Mitarbeiter einer Filiale und hat Rollen.
Fakt: Berechtigungs­katalog als benannte Konstanten (UserRightsConst.*) mit eigenen
„restricting rights"; ReceiptBL.CanUserEditReceipt prüft Bearbeitungsrecht und optional
„nur eigene Filiale" (BranchBL.IsBranchEqual); CanUserViewReceipt verweigert Web-Benutzern
das Belegsehen vollständig; Kalender und Mitarbeiterauslastung haben eigene
Filialeinschränkungen (RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE).
Aussage: Das System soll jede fachliche Funktion an ein Berechtigungsrecht binden und
einschränkende Rechte zusätzlich nach Person, Abteilung und Filiale differenzieren;
Berechtigungsprüfungen gehören in die Geschäftslogik, nicht in die Oberfläche.
Ergebnis: Fehlendes Recht führt zu fachlicher Fehlermeldung mit eigenem MessageCode
(RightCheckFailed), nicht zu einer ausgeblendeten Schaltfläche allein.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CanUserEditReceipt (Zeile 10272 ff.) mit
HasRightToEditReceipt / HasRightToEditReceiptOnlyOwnBranch / BranchBL.IsBranchEqual, Fehler-
code DefaultMessageCodes.RightCheckFailed - Begründung: doppelte Prüfung (Funktion + Filiale)
mit eigenem Fehlercode.
- [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, Zeile 556 – HasUserRight vor Löschen -
Begründung: gleiche Prüfidomäne in einer zweiten Domäne.
- [SEKUNDÄR] CentronRights.md (kompletter Rechte­katalog mit Konstantennamen) - Begründung: dokumentiert
die fachliche Semantik jedes Rechts.
- [KONTEXT] UserRightsConst.cs in src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/
Rights/ - Begründung: Verzeichnisname „EntitiesWrongPlace" zeigt Schichtverletzung an.
Prüfidee: Benutzer Filiale A will Beleg Filiale B bearbeiten → Abweisung mit RightCheckFailed;
Web-Account darf keinen Beleg sehen.
Tracelinks: StRS-008, StRS-013, StRS-020, SyRS-006, SyRS-007, SwRS-003, SwRS-024, SwRS-025
Konsolidierung: nein
Übernahmewürdigkeit: übernehmen - unverzichtbar, das Muster „einschränkendes Recht" ist ausdrücklich übernahmefähig.
Status: belegt
```
```
ID: StRS-020
Titel: Wahrnehmung von Lösch- und Sperrverlangen personenbezogener Daten (DSGVO)
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Datenschutzbeauftragter, Kunde, Administrator
Vorbedingung: Anfrage einer Person liegt vor.
Fakt: DataSecurityBL stellt personenbezogene Kontakte über SQL-Abfragen fest und ersetzt sie;
Konstanten DsgvoDeletedContactMessage = „DSGVO: Auf Anfrage gelöscht." und
DsgvoDeletedContactMessageWithEmployeeInfo „… (Durchgeführt von {0} am {1:…})"; Rechte
UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT; Aufräumläufe mit
DataSecurityCleanUpStatsKind, FilterForDeletedCustomers; Vorprüfungen „Insufficient rights!".
Aussage: Das System soll auf Löschverlangen betroffene Ansprechpartner und Kunden auffindbar machen,
die Löschung nachvollziehbar unter Angabe von Durchführendem und Zeitpunkt durchführen und
anschliessend aufräumbare Datenbestände getrennt nach Datenart ausweisen.
Ergebnis: Betroffene Person ist nicht mehr rekonstruierbar, der Löschvermerk mit Bearbeiter und Datum
bleibt erhalten; Aufräumen ohne Recht wird abgewiesen.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Zeilen 26–27, 37, 67,
379–380 (Rechteprüfung DSGVO_DELETE_CONTACT, „Insufficient rights!") - Begründung:
Rechteprüfung und Löschvermerk sind dort hart umgesetzt.
- [SEKUNDÄR] Tabellen SichProtokoll, SichFields/SichFieldsAssociated, Sichbenu - Begründung: benanntes
Modell für sensible Felder und Protokoll.
Prüfidee: Nutzer ohne DSGVO_DELETE_CONTACT ruft die Maske auf → „Insufficient rights!"; nach Löschung
enthält der Ansprechpartner den Vermerk mit Bearbeiter und Datum.
Tracelinks: StRS-019, StRS-025, SyRS-026, SwRS-025
Konsolidierung: Kandidat: SwRS-025 – Berechtigungs-, Sperr- und Protokollmodelle sind mehrfach angelegt
(Sich*, ChangeLog, CentronLog, ObjectHeritage).
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-021
Titel: Sichere Verwahrung von Kunden-Zugangsdaten mit Richtliniendurchgriff
Ebene: StRS
Typ: Sicherheit
Qualitätsmerkmal:
Akteur: Servicetechniker, Administratoren, Compliance
Vorbedingung: Kunde und Richtlinie sind gepflegt.
Fakt: Tabellen PasswordManagement, PasswordManagementAccessLog, PasswordManagementLog,
PasswordManagementType/Keyword, PasswordManagerGuidelines mit Zuordnungen zu Kunden,
Abteilungen, Mitarbeitern und ausgeschlossen Kunden, PasswordManagerLogs;
BL PasswordManagementBL/-UpdateBL/-AccessLogBL; zusätzlich RemoteCredentials, CometCredentials,
CometBackupSecretKeys, WasabiCredentials, AccountVPNAccesses.
Aussage: Das System soll Zugangsdaten der Kunden zentral verwahren, den Abruf protokollieren und
über Richtlinienvorgaben steuern, welche Abteilungen oder Mitarbeiter welche Datenarten sehen.
Ergebnis: Jeder Abruf ist protokolliert; Richtlinie und Ausschlussliste steuern die Sichtbarkeit.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE PasswordManagementAccessLog, PasswordManagementLog,
PasswordManagerGuidelineCustomers/-ExcludedCustomers - Begründung: Zugriffsprotokoll und
Richtliniendurchgriff sind datenmodelseitig erzwungen.
- [SEKUNDÄR] UI-Module Modules/PasswordManager (29 Dateien), PasswordManagementArea (6 BL-Klassen) -
Begründung: eigene Bedienoberfläche und BL-Schicht.
- [KONTEXT] Tabellen CometBackupSecretKeys, WasabiCredentials - Begründung: Belegt Mehrfachablage von
Zugangsdaten je Dienst.
Prüfidee: Abruf eines Eintrags durch nicht freigegebenes Profil → kein Klartext, Eintrag im
AccessLog; freigegebenes Profil → Abruf wird protokolliert.
Tracelinks: StRS-019, SyRS-009, SwRS-025
Konsolidierung: Kandidat: StRS-021/SwRS-025 – vier getrennte Zugangsdaten-Haltungen (PasswordManagement,
RemoteCredentials, CometCredentials, WasabiCredentials) für dieselbe Funktion.
Übernahmewürdigkeit: übernehmen (Funktion) / Workaround (parallele Ablagen)
Status: belegt
```
```
ID: StRS-022
Titel: Steuerung des Unternehmens über Statistiken, Auslastung und Controlling
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Geschäftsführung, Abteilungsleitung, Disponent
Vorbedingung: Vorgangsdaten sind erfasst; Auswertungsrollen sind zugeordnet.
Fakt: Statistiktabellen StatisticHelpdesk(-Details), StatisticStock, StatisticAssetDay/Year/
YearMonth, StatisticManagement*, StatisticRolesToEmployee/ToStatistics, CacheOrderStatistic,
CacheSalesStatistic, CacheTicketStatistic, CacheMspArticleStatistics, ControllingAuswertung,
ConsultingUmsatz, EmployeeStatistic, Consultant-Umsatz; Rechte RIGHT_MITARBEITERAUSLASTUNG
und RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE; UI Module/Statistics (141), MyDay (211).
Aussage: Das System soll Vertriebs-, Service-, Bestands- und Personal-Kennzahlen zeitlich
aufbereitet bereitstellen, die Mitarbeiterauslastung sichtbar machen und die Sicht nach
Rolle und Filiale begrenzen.
Ergebnis: Kennzahlen sind je Rolle wählbar und je Filiale eingeschränkt; vorberechnete Kennzahlen
sind als Cache hinterlegt.
Belege:
- [PRIMÄR] CentronRights.md „Mitarbeiterauslastung" – RIGHT_MITARBEITERAUSLASTUNG und
RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE als restriktives Recht - Begründung:
Zugriffssteuerung der Auswertung ist dokumentiert und über Konstanten erzwungen.
- [SEKUNDÄR] Tabellen Statistic* und Cache*Statistic - Begründung: zwei Bereitstellungswege
(Vorberechnung und Caching).
Prüfidee: Nutzer ohne RIGHT_MITARBEITERAUSLASTUNG sieht keine Kollegen-Auslastung; Nutzer mit
Filialrecht sieht nur eigene Filiale.
Tracelinks: StRS-013, StRS-019, SyRS-024
Konsolidierung: Kandidat: StRS-015 – Kennzahlen liegen in Statistiktabellen und Cache-Tabellen doppelt.
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-023
Titel: Selbstbedienung der Kunden: Shop, Angebotseinsicht, Auftragsfreigabe, Portal
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Endkunde des Kunden, Web-Account-Inhaber, Innendienst
Vorbedingung: Web-Account mit Kunde und Sonderpreisliste ist angelegt.
Fakt: README.md: „The webcart is a feature primarily intended for the customers of our customers …
available if you login as a web-account … The available articles come from the customers
'Sonderpreise'"; WebShopEinstellungen/WebShopKopf/WebShopPos/WebShopZuordnung,
WebKunden, WebAccounts/WebAccountsRights/WebRights/WebRightsCategories;
Zustandsmaschine WebReceiptState { InProcess, SendToCustomer, AcceptFullWebReceipt,
AcceptWebReceiptWithChangeRequests, Rejected, WebOfferSign, WebOfferSignedWithoutSignature,
WebReceiptShutDown }; WebRecepItemChangeRequests, ReceiptBL-Zeile 5932
„Web Receipt State is not accepted."; SelfCareForms* Tabellen, Nexus WebCart (74 Dateien)
und WebOffer (10 Dateien).
Aussage: Das System soll Kunden im Web eigene Artikel- und Preiskonditionen anbieten, Angebote zur
Annahme bereitstellen, Änderungen als Änderungswunsch entgegennehmen und die Freigabe
statusgeführt protokollieren; Kundenportal-Formulare sind konfigurierbar.
Ergebnis: Kunde sieht ausschliesslich Artikel und Preise seiner Konditionen; eine Annahme erzeugt
den Folgevorgang im Innendienst; abgelehnte oder geänderte Angebote werden dem Sachbearbeiter
zurückgespielt.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetReceiptByI3D: bei
IsWebAccountLogin und abweichender CustomerI3D wird null zurückgegeben; CreateNewReceipt:
„Keine Berechtigung"; Zeile 5932 InvalidEnumArgumentException „Web Receipt State is not accepted." -
Begründung: Mandantentrennung und Freigabemaschine werden im Code erzwungen.
- [PRIMÄR] src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs - Begründung:
abschliessende Zustandsmenge des Freigabeprozesses.
- [SEKUNDÄR] README.md Abschnitt „WebCart" - Begründung: nennt Zweck und Datenquelle (Sonderpreise).
- [SEKUNDÄR] Tabellen SelfCareForms, SelfCareFormFields, SelfCareFormStates, SelfCareFormTicketPattern -
Begründung: Konfigurierbarkeit des Portals.
Prüfidee: Web-Account Kunde A fragt Beleg von Kunde B ab → null/„Keine Berechtigung"; Annahme eines
Web-Angebots erzeugt Auftrag und Status WebReceiptShutDown für den Link.
Tracelinks: StRS-005, StRS-011, StRS-019, SyRS-008, SyRS-028, SyRS-032, SwRS-033
Konsolidierung: Kandidat: StRS-012 – Angebotsfreigabe im Web und Angebot als Beleg sind zwei Sichten
desselben Vorgangs.
Übernahmewürdigkeit: übernehmen - zentraler Differenzierer des Produkts.
Status: belegt
```
```
ID: StRS-024
Titel: Abbildung von Organisation, Prozessen und Projekten im System
Ebene: StRS
Typ: funktional
Qualitätsmerkmal:
Akteur: Projektleiter, Abteilungsleitung, Mitarbeiter
Vorbedingung: Abteilungen, Teams, Projekte und Aufgaben sind gepflegt.
Fakt: Tabellen Projekt* (Projekt, ProjektPhasen, ProjektPhasenAufgaben inkl.
ProjektPhasenAufgabenAbhaengigkeit, ProjektBeteiligte, ProjektMa*), CRMProjekt*,
TicketProjects/-Tasks/-Dependencies, TaskManagementTask mit Actions (Checklist, Customer,
Department, Device, Report, Substitute), Checklists*/RBChecklist*, Termine/Terminplanung*,
PersonalTeams (EmployeeTeam), ToDoListe*, MyDayWorkItems; UI Module/ProjectManagement.
Aussage: Das System soll interne und kundenbezogene Vorhaben mit Phasen, Aufgaben, Abhängigkeiten,
Beteiligten und Wiedervorlagen führen und die Tagesarbeit eines Mitarbeiters bündeln.
Ergebnis: Aufgaben sind Rollen und Objekten (Kunde, Gerät, Abteilung) zugeordnet; Phasenabhängigkeiten
steuern Fälligkeiten.
Belege:
- [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ProjektPhasenAufgabenAbhaengigkeit,
TaskManagementActionChecklist, TaskManagementActionSubstitute - Begründung: Abhängigkeits- und
Vertretungslogik ist datenmodelseitig erzwungen.
- [SEKUNDÄR] UI Module/ProjectManagement, MyDay (211 Dateien), TaskManager BL (4 Klassen) - Begründung:
eigene Oberflächen für Projekt- und Tagesgeschäft.
Prüfidee: Aufgabe B von Aufgabe A abhängig machen; Verschieben von A verschiebt Fälligkeit von B.
Tracelinks: StRS-013, StRS-007, StRS-022
Konsolidierung: Kandidat: StRS-013 – Vorgangssteuerung existiert dreifach (Ticket, TaskManagement,
Projektverwaltung).
Übernahmewürdigkeit: übernehmen (Funktionsumfang); die Dreifachanlage ist Konsolidierungskandidat.
Status: belegt
```
```
ID: StRS-025
Titel: Lückenlose Nachvollziehbarkeit fachlicher Änderungen
Ebene: StRS
Typ: funktional / Sicherheit
Qualitätsmerkmal:
Akteur: Sachbearbeiter, Revision, Geschäftsführung
Vorbedingung: Ein Vorgangsobjekt wird geändert.
Fakt: ReceiptBL.WriteReceiptLogs erzeugt je geändertem Attribut einen eigenen Logeintrag
(CreateContingentKindEntry, CreateContingentValueEntry, …); ReceiptLogBL.CreateReportEntry
protokolliert jeden Druckversand; Tabellen ChangeLog, CentronLog, CentronWebLog, WebLog,
ObjectHeritage, GlobalLog, ExceptionLog, *History-Tabellen (WartungHistory*, RepaKopfHistory,
GeraeteWartungHistory), XMLLockList, CachedTableStatistics; UI Ordner Logs.
Aussage: Das System soll jede fachlich relevante Änderung an Belegen, Verträgen, Wartungsobjekten
und Dokumenten mit Alt-/Neuwert, Bearbeiter und Zeitpunkt protokollieren und die Protokolle
bedienbar halten.
Ergebnis: Änderungen sind je Attribut rekonstruierbar; Druck- und Versandvorgänge sind je Beleg
abrufbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, WriteReceiptLogs – Attribut-für-Attribut-
Vergleich mit vorheriger Fassung und Logschreibung - Begründung: erzwungene Protokollierung.
- [SEKUNDÄR] Tabellen ChangeLog, CentronLog, ObjectHeritage, *History - Begründung: mehrere, getrennte
Protokollspeicher.
Prüfidee: Kontingentwert eines Vertrags ändern → genau ein Logeintrag mit altem/neuem Wert,
Bearbeiter, Zeitstempel.
Tracelinks: StRS-011, StRS-019, StRS-020, SyRS-025, SwRS-025
Konsolidierung: Kandidat: SwRS-025, StRS-020
Übernahmewürdigkeit: übernehmen
Status: belegt
```
```
ID: StRS-026
Titel: Kundenspezifische Erweiterbarkeit ohne Eingriff in den Quellcode
Ebene: StRS
Typ: nicht-funktional
Qualitätsmerkmal: Anpassbarkeit / Wartbarkeit (ISO/IEC 25010)
Akteur: Mandantenbetreuer, Administrator
Vorbedingung: Mandant benötigt zusätzliche Felder, Masken, Berichte oder Regeln.
Fakt: Module/Customizations (CustomTableBL), Tabellen ModuleCustomProperties/
ModuleCustomPropertyPossibleValues/ModuleCustomPropertyValues, ObjectFields, ObjectMappings,
Stammdatfelder, SharedData, ApplicationSettings/AppSettingsConst-Schlüssel,
Administration/Scripts mit 790 Skriptdateien (ScriptMethod*), CentronConstant/
CentronConstantTypen, MassUpdateTemplate, ReportDataQueries/ReportGroups konfigurierbar.
Aussage: Das System soll zusätzliche Felder, Auswahlwerte, Berichtedefinitionen, Masken und
Regellogik je Mandant konfigurativ oder per Skript ermöglichen, ohne dass der Kern geändert
werden muss.
Ergebnis: Neue Felder erscheinen in Maske, Suche, Bericht und Übergabe an die Buchhaltung; sie sind
beim Weiterverarbeiten von Belegen übertragbar.
Belege:
- [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Aufruf
ModuleCustomPropertyValueBL.GetTransferableCustomPropertyValues(...) in CopyReceipt und
ForwardReceipt - Begründung: erzwingt die Mitnahme kundeneigener Felder über Belegketten.
- [SEKUNDÄR] src/backend/Centron.BL/Administration/Scripts (790 Dateien) - Begründung: Skriptlaufzeit-
umgebung als Erweiterungspunkt.
- [KONTEXT] .editorconfig, Directory.Build.props, Customizations-Modul - Begründung: belegen
Mehrmandantenfähigkeit als Konstruktionsziel.
Prüfidee: Custom-Feld an Auftrag anlegen, Auftrag zu Lieferschein weiterverarbeiten → Wert ist im
Folgebeleg vorhanden.
Tracelinks: StRS-003, SyRS-031, SwRS-019, SwRS-020
Konsolidierung: Kandidat: SwRS-020 – benutzerdefinierte Felder existieren als Custom-Properties, Custom
Tables und Stammdatfelder in drei Mechanismen.
Übernahmewürdigkeit: übernehmen
Status: belegt
```
## Abgrenzung zu SyRS/SwRS
Die obenstehenden Anforderungen beschreiben **was** das System fachlich leisten muss und **warum**.
Die technische Ausgestaltung – Schnittstellenverhalten, Berechtigungsdurchsetzung an konkreten Stellen,
Performance, Protokolliermenge – ist auf den Ebenen SyRS (`SyRS.md`) und SwRS (`SwRS.md`) spezifiziert.
Doppelbeschreibungen desselben Sachverhalts aus verschiedener Ebenensicht sind bewusst keine
Konsolidierungsfälle; sie sind über `Tracelinks` verbunden.
@@ -0,0 +1,148 @@
# Traceability – Forward- und Rückwärtsverfolgung
c-entron ERP-Suite · Reverse Requirements Engineering · ISO/IEC/IEEE 29148:2018
Regeln dieses Laufs:
- Jede SwRS-Anforderung referenziert genau eine tragende SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert genau eine tragende StRS-Anforderung.
- Die Spalte „Artefaktbeleg" nennt den **primären** Beleg (durchsetzende Stelle), nicht die Vollständigkeit.
## 1. Konsolidierte Traceability-Tabelle
| StRS-ID | StRS-Kurztitel | SyRS-ID | SyRS-Kurztitel | SwRS-ID | SwRS-Kurztitel | Primärer Artefaktbeleg |
|---|---|---|---|---|---|---|
| StRS-001 | Vertriebsprozess Angebot→Rechnung | SyRS-001 | Weiterverarbeitung mit Kettenprüfung | SwRS-001 | Generischer Belegkern + Strategien | `ReceiptBL.cs` · CanForwardReceiptsInto, ValidateReceiptForwarding |
| StRS-001 | – | SyRS-003 | Nummernkreise je Mandant/Filiale | SwRS-007 | Read-Modify-Write-Zählertabelle | `NumberGroupBL.cs` · GetNextNumber (Z. 50–89) |
| StRS-001 | – | SyRS-018 | Versandsteuerung/Fracht | – | – | `FreightArticleSettingBL.cs`, `ShipcloudPackageTemplateBL.cs` |
| StRS-002 | Beschaffung Einkauf→Rechnung | SyRS-002 | Bearbeitungslock/Parallelität | SwRS-008 | Zwei Parallelitätsmechanismen | `ReceiptBL.cs` · CreateLock/RemoveLock, ConcurrencyControlGuid |
| StRS-002 | – | SyRS-016 | EDI zu Distributoren | – | – | `SupplierEdiBL.*.cs` (6 Partial-Klassen) |
| StRS-002 | – | SyRS-017 | Fremdartikelsuche/Kataloge | – | – | `IExternalArticleSearchProvider.cs` + 3 Anbieter |
| StRS-003 | Mandanten- und Filialfähigkeit | SyRS-003 | Nummernkreise | SwRS-007 | Nummernkreisvergabe | `NumberGroupBL.cs` · CreateNumberGroups(mandantI3D, branchI3D) |
| StRS-003 | – | SyRS-011 | Filialzugehörigkeit in Datenzugriffen | SwRS-023 | Filialgleichheit mit Default-Semantik | `ReceiptBL.cs` · CanUserCreateReceiptsInBranch (Z. 10251) |
| StRS-003 | – | SyRS-027 | Lizenzprüfung beim Start | – | – | `LicenseManager.cs` · SettingsForCentronNet, Public-Key-Prüfung |
| StRS-003 | – | – | – | SwRS-026 | Mandantenstammdaten als Ausgabekopf | `ReceiptBL.cs` · ExportReceiptToExcel (MandatorBL) |
| StRS-004 | Einheitlicher Geschäftspartnerstamm | SyRS-011 | Filial/Mandantenzugehörigkeit | SwRS-016 | 14fache Datenhaltung Artikel/Lager | `SSMS_DB_SCHEMA.sql` · Accounts/AccountTypes/Kunden/Kreditor |
| StRS-005 | Kundenindividuelle Preise | SyRS-004 | Vorrangfolge der Preisermittlung | SwRS-004 | Preiskomponente mit Cache | `ReceiptItemPriceBL.cs` · GetBasePrice (Z. 144 ff.) |
| StRS-005 | – | SyRS-004 | – | SwRS-031 | Invertierte Vorzeichenkonvention | `ReceiptItemPriceBL.cs` Z. 181–223 („values are inverted") |
| StRS-006 | Vertrags-/Kontingentgeschäft | SyRS-001 | Weiterverarbeitung (ContractClass) | SwRS-002 | Status- und Versionsmodell | `ReceiptBL.cs` · WriteReceiptLogs (Contingent-*) |
| StRS-006 | – | SyRS-001 | – | SwRS-032 | Dreistufige Konditionsauflösung | `ReceiptBL.cs` · GetDefaultPaymentCondition (Priority 1–3) |
| StRS-007 | Servicezeiterfassung mit Signatur | SyRS-022 | Schutz gebuchter Servicezeiten | SwRS-012 | Löschschutz über Belegzuordnung | `HelpdeskTimerBL.cs` Z. 550–570 |
| StRS-008 | Mahnwesen mit Belegsperre | SyRS-005 | Beleganlag sperre ab Mahnstufe | SwRS-014 | Mahnstufenherkunft + Lieferanten-Ausnahme | `ReceiptBL.cs` · CanUserCreateNewReceiptsAtCustomerOrSupplier (Z. 10194) |
| StRS-008 | – | SyRS-023 | Mahnlauf mit Berichtspflicht | SwRS-014 | – | `DunningRunBL.cs` Z. 150–153 (ReportGroupConstants.MAHNUNG) |
| StRS-009 | Übergabe an die FiBu | SyRS-015 | Konfigurierbarer Buchungs­export | SwRS-028 | Je Format Tabelle + Codezweig | `BookKeepingExportBL.cs` Z. 441–449, 789 |
| StRS-009 | – | SyRS-019 | Onlinebanking/Zahlungszuordnung | SwRS-027 | Kassenbuch mit Zählhilfe | `SSMS_DB_SCHEMA.sql` · OnlineBankingTransactionAssignments |
| StRS-010 | Automatisierte/Pauschalabrechnung | SyRS-001 | Weiterverarbeitung | SwRS-006 | Anzahlung/Schlussrechnung im Pfad | `ReceiptBL.cs` · DownPayment-Region in ValidateReceiptForwarding |
| StRS-011 | Revisionssichere Belegfassung | SyRS-002 | Lock und Parallelität | SwRS-002 | Drei Zustände + Versions-Tabellen | `ReceiptState.cs`, `ReceiptBL.cs` · CreateNewVersion |
| StRS-011 | – | SyRS-012 | Reportgruppen/Vorschau per Rollback | SwRS-022 | Berichtsystem Gruppen/Abfragen/Parameter | `ReceiptBL.cs` · CreateReportPreviewForReceipt (Rollback) |
| StRS-012 | ZUGFeRD und Signatur | SyRS-013 | ZUGFeRD mit Leitweg-ID | SwRS-021 | ZUGFeRD-/Signaturzweig im Ausgabepfad | `ReceiptBL.cs` · CreateFullReportForReceipt (ZUGFeRD-Zweig) |
| StRS-012 | – | SyRS-014 | Signatur beim Versand | SwRS-021 | – | `PdfSigningBL.cs` · SignPdfDocument, IsPdfSigningAvailable |
| StRS-013 | Helpdesk/Ticket mit Eskalation | SyRS-006 | Prüfung in der Geschäftslogik | SwRS-018 | Doppelte Helpdesk-Datenhaltung | `CentronRights.md` §1.1/§1.2, `AppRightsBL.HasUserRight` |
| StRS-013 | – | SyRS-022 | Schutz gebuchter Zeiten | SwRS-012 | – | `HelpdeskTimerBL.cs` Z. 556 |
| StRS-013 | – | SyRS-029 | Outlook/Telefonie/Mobil | – | – | `SSMS_DB_SCHEMA.sql` · GroupwareEntryIDs, CTRCalls |
| StRS-014 | IT-Assetlebenszyklus | SyRS-020 | Seriennummern-Eindeutigkeit | SwRS-017 | Drucker-Stamtblatt vs. Asset | `SSMS_DB_SCHEMA.sql` · Printer (Z. 46837) vs. AssetManagementDevices (Z. 6050) |
| StRS-014 | – | SyRS-021 | Bestands-/Nebenlager/Inventur | – | – | `InventoryBL.cs`, `SecondStockArticleBL.cs` |
| StRS-015 | IT-Stammdaten aus Fremdsystemen | SyRS-029 | Outlook/Telefonie/Mobil | – | – | `SSMS_DB_SCHEMA.sql` · CManThreshold, MonitoringDataFailures |
| StRS-016 | Seriennummern-Nachverfolgbarkeit | SyRS-020 | Eindeutigkeit/Buchung/Zustand | SwRS-013 | Doppelhaltung Barcode/BarCode2 | `BarcodeBL.cs` Z. 634, 740, 73–90, 575, 788, 1078 |
| StRS-016 | – | SyRS-020 | – | SwRS-030 | Integrität im Code statt DB | `SSMS_DB_SCHEMA.sql` · 1535 Tabellen / 21 UNIQUE |
| StRS-017 | Warenwirtschaft | SyRS-017 | Fremdartikel/Kataloge | SwRS-016 | Mehrfache Artikel-/Lagerwelten | `SSMS_DB_SCHEMA.sql` · Artikel/ARTIK/ARTIKALT/WareN |
| StRS-017 | – | SyRS-021 | Bestandsführung | SwRS-029 | Zwei Inventurimplementierungen | `InventoryBL.cs` + `InventoryNewBL.cs` |
| StRS-018 | RMA/Reparatur/Geräteprüfung | SyRS-020 | Seriennummern | – | – | `SSMS_DB_SCHEMA.sql` · RMAPosStatus, PrufvorschriftMesswert |
| StRS-019 | Rollen-, Filial-, Bereichssteuerung | SyRS-006 | Prüfung in der BL mit RightCheckFailed | SwRS-003 | Private Berechtigungsmethoden im Belegkern | `ReceiptBL.cs` · CanUserEditReceipt (Z. 10272) |
| StRS-019 | – | SyRS-007 | REST 401/403-Filter | SwRS-024 | Rechtekatalog als Konstanten, falsche Schicht | `AuthorizeUserRightAttribute.cs` Z. 38–52 |
| StRS-019 | – | SyRS-008 | Web-Account-Isolation | SwRS-033 | Web-Freigabezustände | `ReceiptBL.cs` · GetReceiptByI3D (WebAccount-Zweig) |
| StRS-019 | – | SyRS-009 | Mehrwege-Authentifizierung + 2FA | SwRS-009 | SHA-1-Passwortableitung | `AuthenticatorFactory.cs`, `ITwoFactorValidator.cs` |
| StRS-019 | – | SyRS-010 | Kennworthärte | SwRS-010 | Benutzerindividuelle Mindestlänge | `UsersBL.cs` · IsValidAppUserPassword (Z. 124–128) |
| StRS-019 | – | SyRS-010 | – | SwRS-011 | Separate 8-Zeichen-Grenze Web-Konten | `WebAccountBL.cs` · UpdatePassword (Z. 183–193) |
| StRS-019 | – | SyRS-011 | Filialzugehörigkeit | SwRS-023 | Filialgleichheit | `ReceiptBL.cs` · CanUserEditReceipt (IsBranchEqual) |
| StRS-019 | – | SyRS-028 | Nexus als zweiter Zugang | SwRS-034 | Schichtaufbau/Hostvarianten | `SSMS_DB_SCHEMA.sql` · WebRights, WebMenuConfig |
| StRS-020 | DSGVO-Löschrecht | SyRS-026 | Lösch- und Aufräumfunktionen | SwRS-025 | Zersplitterte Protokoll-/Schutzmodelle | `DataSecurityBL.cs` Z. 26–27, 37, 67, 379 |
| StRS-021 | Passworttresor | SyRS-009 | Authentifizierung | SwRS-025 | Schutzmodelle | `SSMS_DB_SCHEMA.sql` · PasswordManagementAccessLog |
| StRS-022 | Statistiken/Auslastung/Controlling | SyRS-024 | Leistungsfähigkeit bei Massen reads | SwRS-004 | Cache-Modus Preiskomponente | `CentronRights.md` (RIGHT_MITARBEITERAUSLASTUNG), `ReceiptItemPriceBL.cs` |
| StRS-023 | Kunden-Selbstbedienung | SyRS-008 | Datensatz­ebene Isolation | SwRS-033 | Zustandsmaschine Freigabe | `WebReceiptState.cs`, `ReceiptBL.cs` Z. 5932, 6198 |
| StRS-023 | – | SyRS-028 | Nexus/Webshop | SwRS-034 | – | `src/nexus/CentronNexus/WebCart` (74 Dateien) |
| StRS-023 | – | SyRS-032 | Angebotsfreigabe-Workflow | SwRS-033 | – | `ReceiptBL.cs` · ShutdownEventuallyWebOfferLinks |
| StRS-024 | Organisation/Prozesse/Projekte | SyRS-029 | Outlook/Telefonie/Mobil | – | – | `SSMS_DB_SCHEMA.sql` · ProjektPhasenAufgabenAbhaengigkeit |
| StRS-025 | Lückenlose Nachvollziehbarkeit | SyRS-012 | Reporting/Vorschau | SwRS-022 | Berichtsystem | `ReceiptBL.cs` · CreateReportPreviewForReceipt |
| StRS-025 | – | SyRS-025 | Protokollierung Fach/System/Ausnahme | SwRS-025 | Protokollmodelle | `ReceiptBL.cs` · _logger.Error + Fortsetzung des Pfads |
| StRS-026 | Mandantenerweiterbarkeit ohne Code | SyRS-030 | Schema-/Versionsanpassung | SwRS-034 | Host-/Deploymentvarianten | `SSMS_DB_SCHEMA.sql` · DBUpdate, ApplicationVersions |
| StRS-026 | – | SyRS-031 | Laufzeit-Felderweiterung | SwRS-019 | Skriptlaufzeit ScriptMethods | `ReceiptBL.cs` · GetTransferableCustomPropertyValues |
| StRS-026 | – | SyRS-031 | – | SwRS-020 | Drei Feldmechanismen | `SSMS_DB_SCHEMA.sql` · ModuleCustomProperties, Stammdatfelder |
## 2. Rückwärtssicht: SyRS → SwRS
| SyRS-ID | SwRS-Anforderungen, die sie umsetzen |
|---|---|
| SyRS-001 | SwRS-001, SwRS-005, SwRS-006, SwRS-032 |
| SyRS-002 | SwRS-002, SwRS-008 |
| SyRS-003 | SwRS-007, SwRS-030 |
| SyRS-004 | SwRS-004, SwRS-031 |
| SyRS-005 | SwRS-014 |
| SyRS-006 | SwRS-003, SwRS-012, SwRS-024 |
| SyRS-007 | SwRS-024, SwRS-034 |
| SyRS-008 | SwRS-033 |
| SyRS-009 | SwRS-009, SwRS-010 |
| SyRS-010 | SwRS-009, SwRS-010, SwRS-011 |
| SyRS-011 | SwRS-023 |
| SyRS-012 | SwRS-021, SwRS-022 |
| SyRS-013 | SwRS-021 |
| SyRS-014 | SwRS-021 |
| SyRS-015 | SwRS-027, SwRS-028 |
| SyRS-016 | SwRS-001 |
| SyRS-017 | SwRS-016 |
| SyRS-018 | – (nur SyRS-Ebene, kein SwRS-Kandidat identifiziert) |
| SyRS-019 | SwRS-027, SwRS-028 |
| SyRS-020 | SwRS-013, SwRS-030 |
| SyRS-021 | SwRS-029 |
| SyRS-022 | SwRS-012 |
| SyRS-023 | SwRS-014 |
| SyRS-024 | SwRS-004 |
| SyRS-025 | SwRS-025 |
| SyRS-026 | SwRS-025 |
| SyRS-027 | – (Lizenzkomponente ist externe Bibliothek, keine eigene SwRS-Anforderung gebildet) |
| SyRS-028 | SwRS-034 |
| SyRS-029 | – (Schnittstellenbereich, nur SyRS) |
| SyRS-030 | SwRS-034 |
| SyRS-031 | SwRS-019, SwRS-020 |
| SyRS-032 | SwRS-033 |
SyRS-018, SyRS-027 und SyRS-029 haben bewusst keine SwRS-Entsprechung: Sie beschreiben
Schnittstellenverhalten beziehungsweise Verhalten einer eingekauften Komponente, zu dem die
Codebasis keine eigenständige, belegbare Implementierungsregel enthält.
## 3. Rückwärtssicht: StRS → SyRS
| StRS-ID | SyRS-Anforderungen |
|---|---|
| StRS-001 | SyRS-001, SyRS-003, SyRS-018 |
| StRS-002 | SyRS-002, SyRS-016, SyRS-017 |
| StRS-003 | SyRS-003, SyRS-011, SyRS-027 |
| StRS-004 | SyRS-011 |
| StRS-005 | SyRS-004 |
| StRS-006 | SyRS-001 |
| StRS-007 | SyRS-022 |
| StRS-008 | SyRS-005, SyRS-023 |
| StRS-009 | SyRS-015, SyRS-019 |
| StRS-010 | SyRS-001 |
| StRS-011 | SyRS-002, SyRS-012 |
| StRS-012 | SyRS-013, SyRS-014 |
| StRS-013 | SyRS-006, SyRS-022, SyRS-029 |
| StRS-014 | SyRS-020, SyRS-021 |
| StRS-015 | SyRS-029 |
| StRS-016 | SyRS-020 |
| StRS-017 | SyRS-017, SyRS-021 |
| StRS-018 | SyRS-020 |
| StRS-019 | SyRS-006, SyRS-007, SyRS-008, SyRS-009, SyRS-010, SyRS-011, SyRS-028 |
| StRS-020 | SyRS-026 |
| StRS-021 | SyRS-009 |
| StRS-022 | SyRS-024 |
| StRS-023 | SyRS-008, SyRS-028, SyRS-032 |
| StRS-024 | SyRS-029 |
| StRS-025 | SyRS-012, SyRS-025 |
| StRS-026 | SyRS-030, SyRS-031 |
## 4. Anforderungen mit ausschliesslich indirekter Beleglage
Keine Anforderung dieses Sets ist ausschliesslich mit `SEKUNDÄR` oder `KONTEXT` belegt; jede führt
mindestens einen `PRIMÄR`-Beleg. Der Anteil schwacher Belege konzentriert sich auf die
Schnittstellenmodule (SyRS-016, SyRS-017, SyRS-019, SyRS-029) und auf StRS-014/StRS-015 – Details
im Abschnitt „Belegqualität" von `Analysebericht.md`.
@@ -0,0 +1,40 @@
# Abbruchanalyse
- **Status:** manuell abgebrochen; ungültige Fehlmessung
- **Abbruchzeit:** 2026-08-31T17:46:24.3204372+02:00
- **Grund:** TensorX meldete nach Angabe des Betreibers seit rund 30 Minuten keine Inferenz; lokal war seit 17:15:42 kein Artefaktfortschritt erkennbar.
- **Beendete Prozesse:** Python-Adapter PID 53764 sowie die danach hängenden PowerShell-Wrapper PID 57932 und PID 26076.
- **Codebasis:** unverändert; der pfadskopierte Git-Status für `QuellCode/CentronERP` war nach dem Abbruch sauber.
## Vorhandene Teilergebnisse
Vier von sieben Pflichtdateien wurden vollständig wirkend geschrieben:
| Datei | Bytes | Letzte Änderung |
|---|---:|---|
| `StRS.md` | 62.799 | 17:10:56 |
| `SyRS.md` | 75.072 | 17:12:31 |
| `SwRS.md` | 74.193 | 17:14:53 |
| `Traceability.md` | 12.542 | 17:15:42 |
Es fehlen `Hypothesen.md`, `Glossar.md` und `Analysebericht.md`. Damit sind insbesondere Konsistenzcheck, Selbstbewertung, Abdeckungsnachweis und die geschlossene Hypothesenliste nicht erbracht.
## Fehlende Messdaten
`RawResult.json` wurde nicht geschrieben, weil der Adapter die normalisierten Messdaten erst nach dem Ende des Agent-Loops persistiert. Tokenverbrauch, Turn-Zahl, Tool-Calls, Subagentenstatistik und der genaue letzte API-/Subagentenzustand sind deshalb nicht rekonstruierbar und werden nicht geschätzt.
`Stderr.log` blieb leer. Der über Windows PowerShell 5.1 umgeleitete native Fehlerstrom wurde trotz Flushes im Python-Prozess nicht sichtbar fortgeschrieben. Nach dem erzwungenen Beenden der hängenden Wrapper ging der gepufferte Inhalt verloren.
## Ursachenanalyse
Die unmittelbare Ursache war ein nicht selbst terminierender Adapterzustand. Der Lauf wurde mit `--timeout 0` gestartet; der Adapter übersetzt dies für `requests.post` in `timeout=None`. Dadurch existiert weder für den Hauptagenten noch für Subagenten eine obere Wartezeit auf eine TensorX-Antwort. Der Hauptagent wartet außerdem auf alle Futures einer parallel gestarteten Subagentengruppe. Ein einzelner hängender HTTP-Aufruf kann daher den gesamten Lauf unbegrenzt blockieren.
Ob konkret der Hauptagent oder ein Subagent in einem HTTP-Aufruf hing, lässt sich wegen der fehlenden inkrementellen Messdaten und des leeren Logs nicht beweisen. Belastbar sind nur: vier abgeschlossene Datei-Schreibvorgänge, danach mehr als 30 Minuten ohne Artefaktfortschritt, kein Abschlussobjekt und die externe Meldung fehlender Inferenz.
## Empfohlene technische Korrekturen vor einer Wiederholung
1. Endlichen Connect-/Read-Timeout für jeden TensorX-Aufruf setzen und Timeoutfehler in ein partielles Ergebnis überführen.
2. Nach jedem API-Turn und jedem Subagentenabschluss ein flushendes JSONL-Checkpoint schreiben, statt sämtliche Metriken nur im Speicher zu halten.
3. Den Adapter selbst in eine Logdatei schreiben lassen; native stderr nicht über Windows PowerShell 5.1 puffern.
4. `KeyboardInterrupt` beziehungsweise ein Abbruchsignal abfangen und dabei `RawResult.json` mit Status `aborted` und den bis dahin akkumulierten Metriken persistieren.
5. Für parallele Subagenten einen Watchdog vorsehen, der den betroffenen Future identifiziert und beendet, ohne den gesamten Lauf unbegrenzt warten zu lassen.
@@ -0,0 +1,219 @@
# Versuch 02 - Agentengestuetzt - Prompt-Version 03-A
## Metadaten
- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien)
- **Prompt-Version:** 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)
- **Basis:** `Versuche/Versuch_01/03_Prompt.md`, SHA-256 `B8C8764F…C030F07`
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-31
- **Vorgänger:** `01_Prompt.md` (Prompt-Version 02-A, SHA-256 `DCDC0E3F…B71BCF`), **kein Lauf durchgeführt**
- **Änderungsgrund gegenüber `01_Prompt.md`:** Version 02-A leitete sich von Prompt-Version **02** ab. Versuch 1 ist inzwischen auf Prompt-Version **03** weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in **zwei** Größen unterscheiden — Agentenrollen *und* Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.
| Änderung gegenüber `Versuch_01/03_Prompt.md` | Grund |
|---|---|
| Neuer Abschnitt „Arbeitsteilung" | Prompt-Version 03 unterstellt stillschweigend **einen** Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. |
| In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung | Die 7-Datei-Regel aus Version 03 entstand an einem `solo`-Lauf (Kimi legte `SwRS-Ergaenzungen.md` an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt. |
| In der Arbeitsteilung: **Zuständigkeitsbindung** — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist **statisch** deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten. |
| In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe | Gebunden wird **wer** eine Teilaufgabe ausführt, nicht **wie viel** davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b. |
| In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung | Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen `subagent_stats` und die Subagenten-Prompts prüfbar. |
| Angehängte Tabellenzeilen und Schlussblockquote aus `03_Prompt.md` an ihren Platz gerückt | In `03_Prompt.md` stehen zwei Zeilen der Änderungstabelle **nach** dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die **gesamte** Datei sendet (`_meta/combined_prompt.md`), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein. |
**Der Prompt nennt keine Rolle namentlich.** Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen `solo`-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin **nicht** vorgegeben; sie bleiben Teil der Untersuchung.
Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf
> zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau
> beim Start bei.
---
## Prompt
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
### Auftrag
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
### Vorgehen (statische Analyse, keine Ausführung)
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
### Pflicht-Eigenschaften jeder Anforderung
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
- **Belegklassifikation:** Kennzeichne jeden Beleg als
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
### Arbeitsteilung
Die Bearbeitung wird auf mehrere Bearbeiter verteilt. **Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen** — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.
- **Frei bleibt, wie du die Bearbeiter einsetzt.** Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, **wer** eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
- **Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig.** Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.
**Dokumentationspflicht.** Halte im `Analysebericht.md` fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.
### Formatvorgabe pro Anforderung
```
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
Titel: <kurzer Titel>
Ebene: <StRS | SyRS | SwRS>
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
Akteur: <Rolle / System / Komponente>
Vorbedingung: <Zustand vor Auslösen>
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
Belege:
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
- [SEKUNDÄR] <...> - Begründung: <...>
- [KONTEXT] <...> - Begründung: <...>
Prüfidee: <Akzeptanzkriterium oder Testidee>
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
Status: <belegt | HYPOTHESE>
```
### Traceability
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
### Nicht-funktionale Anforderungen
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
### Konsolidierungsbedarf
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
```text
Ergebnisse/
StRS.md
SyRS.md
SwRS.md
Traceability.md (oder Traceability.csv)
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
Selbstbewertung, bekannte Lücken)
```
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen im Arbeitsverzeichnis, schreibgeschützte
Kommandozeilenbefehle, das Schreiben von Ergebnisdateien im unten genannten Ausgabeverzeichnis
sowie acht beigestellte Agentenrollen.
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff, Skills und Slash-Kommandos.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare Werkzeuge zu
ersetzen.
Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese Teilaufgaben
durch den jeweils genannten Bearbeiter aus, nicht selbst:
| Teilaufgabe | Vorgesehener Bearbeiter |
|---|---|
| Modulinventar (Schritt 0) | modulinventar |
| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
| Formulierung der StRS-Anforderungen | strs-autor |
| Formulierung der SyRS-Anforderungen | syrs-autor |
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe entscheidest du.
Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter lesen nur und legen keine
Ergebnisdateien an; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen bleiben
deine Aufgabe. Die Bearbeiter delegieren nicht weiter — nur du beauftragst.
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
`C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 2\qwen\qwen3.8-flash-next\custom\low\01_Lauf_2026-08-31_165317_v9.3.0-6242\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1,17 @@
{
"experiment": "Versuch 2",
"iteration": 2,
"model": "qwen/qwen3.8-flash-next",
"mode": "custom",
"effort": "low",
"delegation_depth": "unverschachtelt",
"prompt": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_02\\02_Prompt.md",
"prompt_sha256": "5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD",
"agents": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_02\\03_Agents.json",
"agents_sha256": "424DDD8398D8A6521D9B34AF5B221867C5643572B3821005C7E5E87954644170",
"adapter": "C:\\DEV\\MasterArbeit\\.claude\\skills\\run-experiment\\glm-kimi-adapter.py",
"adapter_version": "2.1.0",
"skill_version": "9.3.0",
"repository_commit": "ca52aa4701693528c097f3377edb2c2b07ec5149",
"root_commit": "ca52aa4701693528c097f3377edb2c2b07ec5149"
}
@@ -0,0 +1,101 @@
$ErrorActionPreference = 'Stop'
$repo = 'C:\DEV\MasterArbeit'
$root = 'C:\DEV\MasterArbeit\QuellCode\CentronERP'
$lauf = 'C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 2\qwen\qwen3.8-flash-next\custom\low\01_Lauf_2026-08-31_165317_v9.3.0-6242'
$prompt = 'C:\DEV\MasterArbeit\Versuche\Versuch_02\02_Prompt.md'
$agents = 'C:\DEV\MasterArbeit\Versuche\Versuch_02\03_Agents.json'
$adapter = 'C:\DEV\MasterArbeit\.claude\skills\run-experiment\glm-kimi-adapter.py'
$model = 'qwen/qwen3.8-flash-next'
$effort = 'low'
$mode = 'custom'
$toolContext = @'
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen im Arbeitsverzeichnis, schreibgeschützte
Kommandozeilenbefehle, das Schreiben von Ergebnisdateien im unten genannten Ausgabeverzeichnis
sowie acht beigestellte Agentenrollen.
Nicht verfügbar sind: externe Werkzeugserver, Webzugriff, Skills und Slash-Kommandos.
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare Werkzeuge zu
ersetzen.
Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese Teilaufgaben
durch den jeweils genannten Bearbeiter aus, nicht selbst:
| Teilaufgabe | Vorgesehener Bearbeiter |
|---|---|
| Modulinventar (Schritt 0) | modulinventar |
| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
| Formulierung der StRS-Anforderungen | strs-autor |
| Formulierung der SyRS-Anforderungen | syrs-autor |
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe entscheidest du.
Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter lesen nur und legen keine
Ergebnisdateien an; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen bleiben
deine Aufgabe. Die Bearbeiter delegieren nicht weiter — nur du beauftragst.
'@
$outputContext = @"
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
``$lauf\Ergebnisse\``.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
"@
$combinedPrompt = (Get-Content -LiteralPath $prompt -Raw) +
"`r`n`r`n" + $toolContext +
"`r`n`r`n" + $outputContext
Set-Content -LiteralPath "$lauf\_meta\combined_prompt.md" -Value $combinedPrompt -Encoding utf8
$before = git -C $repo status --porcelain -- 'QuellCode/CentronERP' | Out-String
Set-Content -LiteralPath "$lauf\_meta\before.txt" -Value $before -Encoding utf8
$config = [ordered]@{
experiment = 'Versuch 2'
iteration = 2
model = $model
mode = $mode
effort = $effort
delegation_depth = 'unverschachtelt'
prompt = $prompt
prompt_sha256 = (Get-FileHash -LiteralPath $prompt -Algorithm SHA256).Hash
agents = $agents
agents_sha256 = (Get-FileHash -LiteralPath $agents -Algorithm SHA256).Hash
adapter = $adapter
adapter_version = '2.1.0'
skill_version = '9.3.0'
repository_commit = (git -C $repo rev-parse HEAD)
root_commit = (git -C $root rev-parse HEAD)
}
$config | ConvertTo-Json | Set-Content -LiteralPath "$lauf\_meta\konfiguration.json" -Encoding utf8
Set-Content -LiteralPath "$lauf\_meta\startzeit.txt" -Value (Get-Date -Format o) -Encoding utf8
Set-Location -LiteralPath $root
& python $adapter `
--prompt "$lauf\_meta\combined_prompt.md" `
--root $root `
--output "$lauf\Ergebnisse" `
--model $model `
--effort $effort `
--mode $mode `
--agents $agents `
--max-turns 0 `
--subagent-max-turns 0 `
--timeout 0 `
--heartbeat-interval 60 `
--result-dir $lauf `
2> "$lauf\Stderr.log"
$adapterExitCode = $LASTEXITCODE
Set-Content -LiteralPath "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o) -Encoding utf8
Set-Content -LiteralPath "$lauf\_meta\exitcode.txt" -Value $adapterExitCode -Encoding utf8
$after = git -C $repo status --porcelain -- 'QuellCode/CentronERP' | Out-String
Set-Content -LiteralPath "$lauf\_meta\after.txt" -Value $after -Encoding utf8
exit $adapterExitCode