# Konfiguration-zu-Auftrag: Abnahmematrix

Stand der Vorlage: 29. August 2026

> Wichtig: Alle Produkte, Systeme, Rollen, IDs, Preisstände und Aufträge in dieser Vorlage sind ausdrücklich fiktiv. Sie dienen nur als Arbeitsbeispiel und müssen vor einer Nutzung durch eigene, fachlich freigegebene Testdaten ersetzt werden. Keine echten Kunden-, Zugangs- oder Produktdaten in eine öffentlich geteilte Kopie eintragen.

## Zweck

Diese Vorlage prüft nicht nur, ob eine API technisch antwortet. Sie prüft, ob genau die freigegebene Konfigurations- und Angebotsrevision im Zielsystem fachlich korrekt, nachvollziehbar und höchstens einmal wirksam wird. Für jeden Testfall werden Ausgangsdaten, erwarteter Zielzustand, Nachweis und fachliche Freigabe dokumentiert.

Die fiktive Beispielkette lautet:

`PIM-DEMO → Konfigurator-DEMO → CPQ-DEMO → ERP-DEMO`

Das Beispielprodukt heißt `Demo-Pumpenmodul PX`. Die Konfiguration `CFG-DEMO-1042-R1`, die Quote `QUOTE-DEMO-882-R3` und die Übergabe `ORD-DEMO-778` existieren nicht. Sie zeigen nur, wie stabile IDs und getrennte Revisionen dokumentiert werden können.

## 1. Projektkopf – vor dem Test ausfüllen

- Produktfamilie und repräsentatives Produkt:
- Fachlich führendes System für Produktstamm:
- Fachlich führendes System für Merkmale und Regeln:
- Fachlich führendes System für Preise und Konditionen:
- Zielsystem und erwartetes Zielobjekt:
- Testumgebungen und Versionen:
- Konfigurations-ID und Revision:
- Produkt-, Katalog- und Regelversion:
- Quote-ID und Revision, falls relevant:
- Externe Übergabe- oder Korrelations-ID:
- Verantwortlich Produktmanagement:
- Verantwortlich Vertrieb oder Pricing:
- Verantwortlich ERP/Fertigung:
- Verantwortlich Integration/Betrieb:
- Geplanter Testzeitraum:

## 2. Gemeinsame Abnahmeregeln

Vor den Einzelfällen sollten diese Regeln schriftlich freigegeben sein:

1. Welche technische Antwort gilt noch nicht als fachlicher Erfolg?
2. Welche ERP-Objekte und Positionen müssen nach einem erfolgreichen Handoff vorhanden sein?
3. Welche externe ID verhindert eine doppelte Anlage?
4. Wie wird ein Auftrag im Zielsystem anhand dieser ID gesucht?
5. Wann gilt eine Konfiguration als reproduzierbar?
6. Welche Produkt-, Regel-, Preis- und Quote-Versionen müssen gespeichert werden?
7. Welche Änderung erzeugt eine neue Revision und welche nur eine neue Darstellung?
8. Was geschieht bei deaktivierten Optionen oder geänderten Einheiten?
9. Wer entscheidet bei Preisabweichung oder unbekannter Materialzuordnung?
10. Wie werden unbekannter Ausgang, fachliche Ablehnung und technischer Fehler getrennt angezeigt?

## 3. Abnahmeszenarien

### AT-01 – Gültige Konfiguration wird genau einmal angenommen

**Fiktiver Aufbau:** `CFG-DEMO-1042-R1` enthält das Produkt `MAT-DEMO-4711`, freigegebene Optionen, Einheit, Regelversion `RULE-DEMO-7` und die angenommene Quote `QUOTE-DEMO-882-R3`.

**Aktion:** Die Übergabe `ORD-DEMO-778` wird einmal an das Test-ERP gesendet.

**Erwartung:** Das ERP legt genau einen Auftrag an, ordnet jede erwartete Position zu und speichert die externe Übergabe-ID sowie Konfigurations- und Quote-Revision. Eine erfolgreiche Transportantwort ohne diese Objekte genügt nicht.

**Nachweis:** Payload-Prüfsumme, ERP-Auftragsnummer, Screenshot oder Export der Positionen, externe ID im ERP und fachlicher Soll-Ist-Abgleich.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-02 – Identische Wiederholung erzeugt keinen Doppelauftrag

**Fiktiver Aufbau:** AT-01 ist bereits erfolgreich. Payload und externe Übergabe-ID bleiben unverändert.

**Aktion:** Derselbe Command wird absichtlich erneut zugestellt, so wie es nach Queue-Wiederanlauf oder unsicherer Netzwerkantwort geschehen könnte.

**Erwartung:** Das Ziel erkennt `ORD-DEMO-778` und liefert den bestehenden Auftrag oder einen eindeutigen Duplicate-Status. Es entsteht kein zweiter Auftrag und keine zweite Positionsgruppe.

**Nachweis:** Suche nach externer ID, Zahl der Zielobjekte vor und nach Wiederholung, Deduplizierungsprotokoll und zurückgegebene ERP-Referenz.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-03 – Neue Revision überschreibt den angenommenen Stand nicht

**Fiktiver Aufbau:** R1 wurde angenommen. Danach wird die Option des Demo-Pumpenmoduls geändert und `CFG-DEMO-1042-R2` erzeugt.

**Aktion:** R2 wird gespeichert und für einen möglichen Folgeprozess geöffnet.

**Erwartung:** R1, Quote R3 und der bestehende ERP-Auftrag bleiben unverändert referenzierbar. R2 benötigt den vereinbarten Änderungsprozess, eine neue Quote oder einen neuen Auftrag. Keine Systemkopie ersetzt still die alte Auswahl.

**Nachweis:** Revisionshistorie, unveränderte Referenz am bestehenden Auftrag und dokumentierter Status von R2.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-04 – Deaktivierte Option wird kontrolliert behandelt

**Fiktiver Aufbau:** Der Entwurf enthält `OPT-DEMO-BLAU`. Danach wird diese Option in der führenden Produktquelle für neue Vorgänge deaktiviert.

**Aktion:** Ein neuer Vorgang und der bestehende Entwurf werden nach der nächsten Synchronisation geöffnet.

**Erwartung:** Die Option ist für neue Vorgänge nicht auswählbar. Der bestehende Entwurf zeigt einen verständlichen Status und folgt der vereinbarten Regel für Bestandsschutz, Ersatzwert oder Revalidierung. Historische Belege verlieren ihre Referenz nicht.

**Nachweis:** Quell- und Zielversion, neuer Vorgang, Altvorgang, API-Antwort sowie Entscheidung des Produktverantwortlichen.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-05 – Preisänderung löst die vereinbarte Entscheidung aus

**Fiktiver Aufbau:** Die Quote dokumentiert einen erfundenen Preisstand. Vor dem Auftrag liefert das Test-ERP einen anderen Wert.

**Aktion:** Der Handoff wird einmal mit noch gültiger und einmal mit abgelaufener Quote getestet.

**Erwartung:** Das System verwendet die schriftlich vereinbarte Regel: gültiger Quote-Preis, Blockade oder erneute Freigabe. Der neue ERP-Wert überschreibt die Quote nicht still. Währung, Kunde, Gültigkeit und Preisbestandteile bleiben nachvollziehbar.

**Nachweis:** Alte und neue Preisantwort, Quote-Gültigkeit, ausgelöster Status und gegebenenfalls neue Freigabe.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-06 – ERP-Timeout bleibt als unbekannter Ausgang sichtbar

**Fiktiver Aufbau:** Die Testverbindung wird nach Versand von `ORD-DEMO-778`, aber vor lesbarer Antwort, kontrolliert unterbrochen.

**Aktion:** Der Integrationsdienst verarbeitet den Timeout. Anschließend wird der Reconciliation-Weg ausgeführt.

**Erwartung:** Der Vorgang wird nicht sofort als sicher fehlgeschlagen dargestellt und nicht mit einer neuen externen ID wiederholt. Das Ziel wird anhand von `ORD-DEMO-778` geprüft. Nur bestätigtes Nichtvorhandensein erlaubt den festgelegten erneuten Versuch.

**Nachweis:** Timeout-Protokoll, Korrelations-ID, Zielsuche, gefundener oder sicher nicht vorhandener Auftrag und dokumentierte Folgeentscheidung.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-07 – Unbekannte Einheit oder ID wird fachlich abgelehnt

**Fiktiver Aufbau:** Die Quelle sendet absichtlich den erfundenen Einheitencode `SET`, während das Ziel nur den abgestimmten Code `ST` akzeptiert.

**Aktion:** Die Konfiguration wird an das Testziel übergeben.

**Erwartung:** Das Ziel meldet Feld, Wert und fachlichen Ablehnungsgrund. Es entsteht kein als erfolgreich markierter Teilauftrag. Nach freigegebener Mappingkorrektur wird eine neue, nachvollziehbare Testausführung gestartet.

**Nachweis:** Ablehnung, betroffene Feldreferenz, alte und neue Mappingversion, fachliche Freigabe und Ergebnis des Wiederholungstests.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-08 – Fehlender PIM-Inhalt besitzt einen definierten Fallback

**Fiktiver Aufbau:** Für einen Testkanal fehlt eine Übersetzung oder das primäre Demo-Asset ist absichtlich nicht erreichbar.

**Aktion:** Katalogimport und Anzeige im vorgesehenen Kanal werden ausgeführt.

**Erwartung:** Je Vereinbarung erscheint ein freigegebener Fallback oder die Veröffentlichung wird kontrolliert blockiert. Ein fehlendes Bild darf nicht die technische Auswahl verändern. Ein vertragsrelevantes Dokument darf nicht durch eine ungeprüfte aktuelle Datei ersetzt werden.

**Nachweis:** Quellantwort, Importstatus, Kanalansicht, Fallbackreferenz und Veröffentlichungsergebnis.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-09 – Teilweise ERP-Anlage wird erkannt und gesperrt

**Fiktiver Aufbau:** Das Test-ERP nimmt den Auftragskopf an, lehnt jedoch eine Optionsposition wegen fehlender Materialzuordnung ab.

**Aktion:** Der Zieladapter liefert den gemischten Zustand an den Integrationsprozess zurück.

**Erwartung:** Der Gesamtvorgang bleibt sichtbar klärungsbedürftig. Es erfolgt kein automatischer Voll-Retry mit neuem Auftragskopf. Erwartete und tatsächliche Positionen werden verglichen; Ergänzen, Stornieren oder Neuanlage benötigen eine dokumentierte fachliche Entscheidung.

**Nachweis:** ERP-Auftragskopf, vorhandene und fehlende Positionen, Ablehnung, Sperrstatus und Korrekturentscheidung.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

### AT-10 – Ereignisse außerhalb der Reihenfolge überschreiben nichts

**Fiktiver Aufbau:** Für dasselbe PIM-Objekt werden zuerst Version 12 und danach verspätet Version 11 zugestellt.

**Aktion:** Beide Ereignisse laufen durch Queue und Zielverarbeitung. Danach wird ein vollständiger Soll-Ist-Abgleich mit der führenden Quelle gestartet.

**Erwartung:** Version 11 überschreibt den bestätigten neueren Stand nicht. Der Soll-Ist-Abgleich bestätigt Version 12 oder stellt eine sichtbare Abweichung zur fachlichen Klärung bereit.

**Nachweis:** Ereignis-IDs, Empfangs- und Objektversion, Verarbeitungsentscheidung und Ergebnis des Quellabgleichs.

**Ergebnis:** ☐ bestanden ☐ abgelehnt ☐ offen

## 4. Ergebnisprotokoll

Für jeden Lauf ergänzen:

- Testfall-ID:
- Datum und Umgebung:
- verwendete Produkt-, Regel-, Preis- und Mappingversion:
- Konfigurations-, Quote- und Übergabe-ID:
- tatsächlicher Zielstatus:
- Zielobjekte und Positionen:
- technische Logs oder Korrelation:
- fachliche Abweichung:
- Entscheidung und Verantwortlicher:
- erneuter Test erforderlich: ja / nein
- Link oder Ablageort des Nachweises:

## 5. Go-/No-Go vor Pilot oder Produktivsetzung

Ein Go ist erst sinnvoll, wenn:

- alle Muss-Szenarien einen eindeutigen fachlichen Ausgang besitzen,
- doppelte Zustellung keinen doppelten Geschäftsvorgang erzeugt,
- ein unbekannter Ausgang über stabile IDs abgeglichen werden kann,
- Preis- und Versionsabweichungen nicht still überschrieben werden,
- fachliche Ablehnungen für die zuständige Rolle bearbeitbar sind,
- Monitoring und Reconciliation mit Verantwortlichkeiten getestet wurden,
- Testdaten, Zugang und Nachweise keine unzulässigen echten Kundendaten enthalten,
- und Produktmanagement, Vertrieb beziehungsweise Pricing sowie ERP-Verantwortung das Ergebnis gemeinsam freigegeben haben.

No-Go-Gründe und nächste Entscheidung:

1. 
2. 
3. 

Freigaben:

- Produktmanagement:
- Vertrieb/Pricing:
- ERP/Fertigung:
- Integration/Betrieb:

Diese Vorlage ist eine Arbeitsgrundlage. Sie ist keine Vollständigkeits-, Sicherheits-, Datenschutz-, Kosten-, Termin- oder Machbarkeitszusage.