↩️

Retouren & Reklamationen

returns supply_chain 🛡️ RLS Protected

Rücksendungsmanagement für Kunden und Lieferanten, Qualitätsprüfung, Einlagerung und Gutschrifterstellung.

Fachliche Bestimmung: Umfassender RMA-Prozess (Return Merchandise Authorization). Kunden oder Servicetechniker melden Rücksendungen an. Das System vergibt eine RMA-Nummer, führt den Lagerarbeiter durch die Qualitäts- und Fehlerprüfung, bucht fehlerfreie Ware zurück in den Bestand und stößt automatisch die Erstellung von Gutschriften oder Ersatzlieferungen an.

Fachprozess-Erzählung & KI-Architektur Workflows & Lifecycles (3) Fachprozesse & Capabilities (43) Data Models & Fields (5) Entry Points (UI & APIs) (40) Regulatory & Compliance

⚡ Workflows & Lifecycles

RMA-Retourenprüfung & Verbuchung `rma_workflow`

Vom Retoureneingang über die technische Zustandsprüfung bis zur Gutschrift.

stateDiagram-v2 [*] --> REGISTER: RMA anlegen REGISTER --> RECEIVE: Ware trifft ein RECEIVE --> INSPECT: Qualitätsprüfung INSPECT --> RESTOCK: Ware einwandfrei -> Lagerzubuchung INSPECT --> SCRAP: Defekt -> Schrottbuchung RESTOCK --> SETTLE: Gutschrift auslösen SCRAP --> SETTLE: Kulanz- / Garantiegutschrift SETTLE --> [*]

1. REGISTER

Retourenanmeldung

Kunde oder Innendienst meldet Rücksendung mit Grund an.

Aktionen: RMA-Nummer erzeugen

2. RECEIVE

Eingang & Identifikation

Paket trifft im Lager ein, Barcode-Scan der RMA.

Aktionen: Prüfauftrag anlegen

3. INSPECT

Zustandsprüfung

Prüfung: Neuwertig, Gebraucht, Reparaturbedürftig oder Schrott.

Aktionen: Prüfergebnis dokumentieren

4. SETTLE

Abwicklung

Wiedereinlagerung ins Lager oder Verschrottung, Auslösen der Gutschrift.

Aktionen: Gutschrift erzeugen

Benutzerbefehl: returns agent `plan:command_returns_agent`

Geprüfter Durable-Plan (durable_plan), Start: manual_command.

1. returns_agent

returns_agent

{"key": "execute_command", "label": "Befehl prüfen, ausführen oder zur Freigabe vorlegen", "adapter": "agent.execute", "agent": "returns_agent", "condition_fact": null}

Aktionen: returns_agent

Retoure `status:return_order`

Beobachtbare Zustandsmaschine (observable_only). Übergänge hier nicht erzwungen — siehe Service-Validierung.

1. draft

draft

Status «draft» der Zustandsmaschine Retoure.

2. requested

requested

Status «requested» der Zustandsmaschine Retoure.

3. approved

approved

Status «approved» der Zustandsmaschine Retoure.

4. rejected

rejected

Status «rejected» der Zustandsmaschine Retoure.

5. in_transit

in_transit

Status «in_transit» der Zustandsmaschine Retoure.

6. part_received

part_received

Status «part_received» der Zustandsmaschine Retoure.

7. received

received

Status «received» der Zustandsmaschine Retoure.

8. inspected

inspected

Status «inspected» der Zustandsmaschine Retoure.

9. resolved

resolved

Status «resolved» der Zustandsmaschine Retoure.

10. closed

closed

Status «closed» der Zustandsmaschine Retoure.

11. cancelled

cancelled

Status «cancelled» der Zustandsmaschine Retoure.

⚙️ Fachprozesse & Capabilities (System-Fachlogik)

Registrierte Fachoperationen und System-Capabilities dieses Moduls zur Steuerung von Workflows, Kaskaden und KI-Agenten.

Gesamt: 43 manual_entry: 1 engine: 27 operator_surface: 2 engine_step: 11 durable_plan: 1 observable_only: 1

Capability & Schlüssel	Fachliche Bezeichnung	Ausführung / Coverage	Risikostufe & Freigabe	Effekte & Kaskaden
Agent-Einstieg returns_agent `agent_entry:returns_agent`	Agent-Einstieg returns_agent Quelle: `code:module_agent_map`	manual_entry	✓ Auto	Keine Seiteneffekte deklariert
Retoure genehmigen `capability:approve_return` Op: `approve_return`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.approved`
Retoure stornieren `capability:cancel_return` Op: `cancel_return`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.cancelled`
Retoure abschließen `capability:close_return` Op: `close_return`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.closed`
Sammelgutschrift für Retouren erstellen `capability:create_collective_return_credit` Op: `create_collective_return_credit`	Objekt: `customer` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`credit_note.created`
Retourenprüfung erfassen `capability:inspect_return` Op: `inspect_return`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.inspected`
Vertragliche Retoure eröffnen `capability:open_return_from_contract` Op: `open_return_from_contract`	Intent: `open_return_case` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`engine:open_return_from_contract`
Gewährleistungsfall aus Vertrag `capability:open_warranty_claim` Op: `open_warranty_claim`	Intent: `open_warranty_claim` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`engine:open_warranty_claim`
Retoureneingang buchen `capability:receive_return` Op: `receive_return`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.received`
Retoure ablehnen `capability:reject_return` Op: `reject_return`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.rejected`
Retoure entscheiden / abwickeln `capability:resolve_return` Op: `resolve_return`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.resolved`
Umtausch `capability:returns.exchange.create` Op: `returns.exchange.create`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`returns.exchange.create`
Rückerstattung `capability:returns.refund.issue` Op: `returns.refund.issue`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`returns.refund.issue`
Retoure einlagern `capability:returns.restock` Op: `returns.restock`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`returns.restock`
Return: add note `capability:returns.return.add_note` Op: `returns.return.add_note`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.add_note`
Return: add photos `capability:returns.return.add_photos` Op: `returns.return.add_photos`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.add_photos`
Return: approve `capability:returns.return.approve` Op: `returns.return.approve`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.approve`
Return: cancel `capability:returns.return.cancel` Op: `returns.return.cancel`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.cancel`
Return: close `capability:returns.return.close` Op: `returns.return.close`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.close`
Return: create `capability:returns.return.create` Op: `returns.return.create`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.create`
Return: create collective credit note `capability:returns.return.create_collective_credit_note` Op: `returns.return.create_collective_credit_note`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.create_collective_credit_note`
Return: create from rental booking `capability:returns.return.create_from_rental_booking` Op: `returns.return.create_from_rental_booking`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.create_from_rental_booking`
Return: mark shipped `capability:returns.return.mark_shipped` Op: `returns.return.mark_shipped`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.mark_shipped`
Return: receive `capability:returns.return.receive` Op: `returns.return.receive`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.receive`
Return: reject `capability:returns.return.reject` Op: `returns.return.reject`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.reject`
Retoure freigeben `capability:returns.rma.approve` Op: `returns.rma.approve`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return_order.approved`
Retoure annehmen `capability:returns.rma.receive` Op: `returns.rma.receive`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return_order.received`
Retoure versenden `capability:ship_return` Op: `ship_return`	Objekt: `return_order` Quelle: `code:capability_registry`	⚙️ Engine	✓ Auto Risiko: `business_record`	`return.shipped`
return_line: edit form `form_surface_anchor:return_line.edit`	Objekt: `return_line` Quelle: `code:erp_form_surface`	operator_surface	✓ Auto	Keine Seiteneffekte deklariert
return_order: edit form `form_surface_anchor:return_order.edit`	Objekt: `return_order` Quelle: `code:erp_form_surface`	operator_surface	✓ Auto	Keine Seiteneffekte deklariert
approve return `gateway:approve_return` Op: `approve_return`	approve return Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
cancel return `gateway:cancel_return` Op: `cancel_return`	cancel return Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
close return `gateway:close_return` Op: `close_return`	close return Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
collective return credit `gateway:collective_return_credit` Op: `collective_return_credit`	collective return credit Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
inspect return `gateway:inspect_return` Op: `inspect_return`	inspect return Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
receive return `gateway:receive_return` Op: `receive_return`	receive return Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
reject return `gateway:reject_return` Op: `reject_return`	reject return Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
resolve return `gateway:resolve_return` Op: `resolve_return`	resolve return Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
Vertragliche Retoure eröffnen `gateway:return_intake` Op: `open_return_from_contract`	Vertragliche Retoure eröffnen Quelle: `code:reviewed_gateway`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
ship return `gateway:ship_return` Op: `ship_return`	ship return Quelle: `code:engine_facade`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
Gewährleistungsfall aus Vertrag `gateway:warranty_claim` Op: `open_warranty_claim`	Gewährleistungsfall aus Vertrag Quelle: `code:reviewed_gateway`	⚙️ Engine	✓ Auto	Keine Seiteneffekte deklariert
Benutzerbefehl: returns agent `plan:command_returns_agent`	Benutzerbefehl: returns agent Quelle: `code:reviewed_execution_plan`	durable_plan	✓ Auto	Keine Seiteneffekte deklariert
Retoure `status:return_order`	Objekt: `return_order` Quelle: `code:status_machine`	observable_only	✓ Auto	Keine Seiteneffekte deklariert

🧠 Fachprozess-Erzählung & Dual Knowledge Architektur

Synthese aus der ideologischen Blaupause (Meta-Fachlogik / Soll), der faktischen System-Implementierung (System-Fachlogik / Ist) und No-Code Customizing für KI-Consultants.

Dual Knowledge Layer

📖

Der durchgängige Businessprozess im Detail (End-to-End Fließtext-Erzählung)

Der durchgängige Retouren- und Reklamationsprozess in der betrieblichen Praxis

Retouren und Reklamationen sind heikle Kundenkontaktpunkte mit hohem finanziellem und juristischem Risiko. Centurio ERP verwandelt Beschwerden in strukturierte Qualitätsprozesse mit lückenloser Rückverfolgbarkeit.

1. Reklamationsanmeldung & RMA-Nummernvergabe (RMA Intake)

Ein Retourenprozess beginnt mit dem Kundenkontakt:

Eingangskanäle: Der Kunde meldet einen Mangel per Telefon, E-Mail (inbox), Ticket-System (tickets) oder über das B2B-Kundenportal (portal).
Verifikationsprüfung: Das System gleicht die Reklamation mit der ursprünglichen Verkaufsrechnung (invoices) oder dem Lieferschein (sales) ab:
- Befindet sich der Artikel innerhalb der gesetzlichen Gewährleistungsfrist (§ 438 BGB) oder einer vertraglichen Garantie?
- Stimmen Seriennummer oder Chargennummer mit dem ausgelieferten Beleg überein?
RMA-Vergabe: Ist die Reklamation plausibel, generiert das System eine eindeutige RMA-Nummer (Return Merchandise Authorization) über cap:returns.rma.create und sendet einen Retourenschein mit Paketmarke an den Kunden. Unangemeldete Rücksendungen werden im Lager sofort als Wild-Retoure identifiziert und zur Klärung gesperrt.

2. Physischer Wareneingang ins Sperrlager (Quarantine Inward)

Trifft das Paket im Lager ein:

Der Lagermitarbeiter scannt den Barcode des RMA-Scheins.
Das System bucht den Artikel über cap:returns.rma.receive_package physisch ein – jedoch nicht in den freien Verkaufsbestand, sondern zwingend in das definierte Sperr- und Quarantänelager (quarantine_location).
Das verhindert, dass defekte oder ungeprüfte Ware versehentlich an andere Kunden ausgeliefert oder in der Produktion verbaut wird.

3. Technische & optische Befundung (Inspection & Diagnostics)

Im Prüffeld oder in der Werkstatt begutachtet ein Qualitätsprüfer die Retoure:

Fehlerbild-Dokumentation: Über die Capability cap:returns.rma.record_inspection werden Befund, Messwerte und Schadensfotos erfasst.
Ursachenklassifikation (Root Cause Analysis):
- Transportschaden: Beschädigung auf dem Versandweg ➔ Schadenmeldung an Frachtführer (claims).
- Herstellungs- / Montagefehler: Qualitätsmangel im eigenen Werk ➔ Auslösung eines internen CAPA-Korrekturauftrags in der Fertigung (assembly).
- Zulieferfehler: Mangelhaftes Zukaufteil ➔ Auslösung eines Lieferantenregresses im Einkauf (purchasing).
- Fehlbedienung / Kundenschaden: Mangel durch unsachgemäßen Gebrauch ➔ Ablehnung der kostenlosen Gewährleistung.

4. Die kaufmännische & operative Entscheidungsverzweigung (Resolution Gate)

Auf Basis des Befundberichts trifft der Qualitäts- oder Kundendienstleiter die verbindliche Entscheidung:

Entscheidungspfad A: Warengutschrift (Credit Note): Kann oder soll der Artikel nicht repariert werden, stößt cap:returns.rma.trigger_credit_note die Erzeugung einer Rechnungskorrektur im Rechnungsmodul an. Der offene Posten des Kunden wird gemindert oder der Betrag erstattet.
Entscheidungspfad B: Kostenlose Ersatzlieferung: Das System generiert automatisch einen neuen Kundenauftrag mit 100% Kulanz-/Garantierabatt (cap:sales.sales_order.create_replacement), der priorisiert durch das Lager ausgeliefert wird.
Entscheidungspfad C: Nacharbeit & Reparatur: Handelt es sich um hochwertiges Investitionsgut, wird über cap:workorders.workorder.create_from_return ein Reparaturauftrag in der Werkstatt eröffnet. Nach Instandsetzung wird der reparierte Originalartikel an den Kunden zurückgesandt.
Entscheidungspfad D: Ablehnung (Rejection): Liegt kein Gewährleistungsfall vor, erstellt das System einen formalen Ablehnungsbescheid mit Prüfprotokoll. Der Kunde kann wählen zwischen kostenpflichtiger Reparatur oder Rücksendung auf eigene Kosten.
Entscheidungspfad E: Lieferantenregress: Handelt es sich um ein defektes Zukaufteil, nimmt das System den Vorlieferanten in Regress (cap:purchasing.supplier_claim.create), fordert Ersatz oder eine Lieferantengutschrift an.

5. Materialverbleib: Aufarbeitung, B-Ware oder Verschrottung

Was geschieht mit dem physischen Artikel im Quarantänelager?

Aufarbeitung & B-Ware: Kann der Artikel nach Reinigung oder Neuverpackung wieder verkauft werden, erfolgt die Umbuchung in den Sonderbestand B-Ware mit reduziertem Bewertungspreis.
Verschrottung (Scrap): Ist der Artikel unbrauchbar, bucht der Gateway gw:return_scrap@v1 das Material endgültig auf das Aufwandskonto Ausschuss/Schrott aus; es wird ein Nachweis zur ordnungsgemäßen Entsorgung erzeugt.

6. Transaktionssicherer Abschluss & Qualitäts-Feedback

Über den Gateway gw:return_resolution@v1 wird der RMA-Vorgang abgeschlossen (cap:returns.rma.complete).
Alle Kaskaden (Gutschrift, Ersatzauftrag, Lieferantenforderung) werden synchronisiert.
Das Outbox-Signal RETURN_PROCESS_RESOLVED aktualisiert die Qualitätskennzahlen des Artikels und des Lieferanten im Management-Cockpit.

🏛️

Meta-Fachlogik: Ideologische Blaupause, Soll-Weltbild & Normen

Meta-Fachlogik: Die ideologische Blaupause & das normative Weltbild

Die Meta-Fachlogik des Retourenmanagements beruht auf dem gesetzlichen Gewährleistungsrecht (BGB), dem SCOR-Modell (sR1 Return Defective Product) und Methoden des Qualitätsmanagements (Closed-Loop CAPA).

1. Zivilrechtliche Grundlagen der Mängelhaftung (BGB §§ 434 ff.)

Sachmangel (§ 434 BGB): Eine Sache ist frei von Sachmängeln, wenn sie bei Gefahrenübergang den subjektiven und objektiven Anforderungen sowie den Montageanforderungen entspricht.
Nacherfüllungsanspruch (§ 439 BGB):
- Der Käufer hat primär Anspruch auf Nacherfüllung: Er kann nach seiner Wahl die Beseitigung des Mangels (Nachbesserung / Reparatur) oder die Lieferung einer mangelfreien Sache (Ersatzlieferung) verlangen.
- Erst nach erfolglosem Ablauf einer angemessenen Frist zur Nacherfüllung darf der Käufer vom Vertrag zurücktreten (§ 440 BGB) oder den Kaufpreis mindern (§ 441 BGB).
- Das Soll-Modell verlangt die lückenlose Fristenüberwachung dieser Nacherfüllungsstufen.
Beweislastumkehr: Im B2C-Verbrauchsgüterkauf (§ 477 BGB) gilt eine gesetzliche Vermutung der Mangelhaftigkeit innerhalb von 12 Monaten; im B2B-Handelsgeschäft greift die unverzügliche Rügepflicht nach HGB § 377.

2. Reverse Logistics im SCOR-Modell & Qualitätsverbesserung

sR1 / sR2 Return Processes: Das Soll-Modell betrachtet Retouren nicht als lästige Kostenfalle, sondern als unverzichtbaren Sensor für Produktmängel.
Closed-Loop CAPA (Corrective and Preventive Actions): Jeder wiederkehrende Retourengrund muss zwingend in den Konstruktions- und Fertigungsregelkreis zurückgespeist werden, um Serienfehler dauerhaft abzustellen.

3. Invarianten des Soll-Modells

Keine Retoure ohne eindeutige RMA-Nummer und Belegverknüpfung.
Retourenware darf niemals ohne bestandene Freigabeprüfung in den regulären Verkaufsbestand gebucht werden.
Gutschriften dürfen erst erzeugt werden, wenn der physische Wareneingang bestätigt oder ein Vorabaustausch explizit autorisiert wurde.
Verschrottungen von Artikeln über Schwellenwert (z.B. > 500 €) verlangen eine Vier-Augen-Freigabe.

Normbezug für `returns`

Prüfkatalog Standards-Registry v2026.10.1. Dieser Abschnitt ordnet Prüfreferenzen zu und stellt nicht fest, dass das Modul eine Norm einhält; keine Kataloganforderung ist als PASS bewertet.

Geführte Prüfreferenzen:

scor-ds-14.0, SCOR Digital Standard (SCOR-DS) Version 14.0, Ausgabe SCOR-DS 14.0 (2025). Art: reference_process. Lizenz schließt eine inhaltliche Nutzung aus. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.
iso-9001-2026, ISO 9001:2026 Quality management systems — Requirements, Ausgabe ISO 9001:2026 (6. Ausgabe, 2026-09-16). Art: normative. Volltext liegt nicht vor. Keine Klauselprüfung. Keine modulspezifische Kataloganforderung. Die Zuordnung bleibt eine Prüfreferenz.

Plattformweite Katalogwerke mit Geltungsbereich all (unter anderem WCAG 2.2, EN 301 549 V4.1.1, ISO 9241-110:2020, ISO 9241-210:2019, ISO/IEC 25010:2023, ISO 9001:2026, ISO/IEC 27001:2022, APQC PCF 8.0, DSGVO, EU AI Act) umfassen dieses Modul mit. Wo der Volltext fehlt, bleibt der Zugang ohne Quelle, lizenzpflichtig oder nur als öffentliche Zusammenfassung gekennzeichnet. Auch diese Nennung weist keine eingehaltene Vorgabe nach.

⚙️

Systemische Fachlogik: Faktische Umsetzung in Centurio ERP & Capabilities

Systemische Fachlogik: Die faktische Umsetzung in Centurio ERP

Die System-Fachlogik dokumentiert die Realisierung im Kernmodul returns.

1. Datenmodelle & Semantische Schicht (ORM)

ReturnAuthorization: Der RMA-Vorgangskopf (Felder: id, tenant_id, rma_number, customer_id, original_invoice_id, original_sales_order_id, status, reason_code, total_claimed_amount).
ReturnLine: Einzelpositionen (Felder: rma_id, product_id, lot_id, serial_number, claimed_quantity, received_quantity, inspection_result, resolution_type [credit, replacement, repair, reject]).
ReturnInspection: Befundungsprotokoll mit Prüfer-ID, Messdaten und Fotodokumentations-Links.
SupplierClaim: Weiterleitung des Mangels an den Vorlieferanten.

2. Das Capability-Register

cap:returns.rma.create: Registrierung eines neuen Reklamationsfalls und RMA-Generierung.
cap:returns.rma.receive_package: Wareneingangsbuchung ins Sperrlager.
cap:returns.rma.record_inspection: Erfassung von Mangelursache und Fehlerbild.
cap:returns.rma.trigger_credit_note: Automatische Erzeugung einer Rechnungskorrektur.
cap:returns.rma.create_replacement_order: Erzeugung eines kostenlosen Ersatzauftrags.
cap:returns.rma.reject: Ablehnung der Reklamation mit förmlicher Begründung.
cap:returns.rma.scrap_item: Buchung des Artikels zur Verschrottung.
cap:returns.rma.complete: Finaler Vorgangsabschluss.

3. Der Gateway `gw:return_resolution@v1`

Der Abwicklungs-Gateway sichert die finale Auflösung ab:

Validierung: Prüft, ob alle Zeilen einen dokumentierten Befund und eine gültige Entscheidungszuweisung tragen.
Kaskadierung: Erzeugt transaktional die Folgebelege (Gutschrift in invoices, Ersatzauftrag in sales oder Reparatur in workorders).
Bestandsausbuchung: Löst den Quarantänestatus auf (Umbuchung B-Ware oder Schrottung).
Outbox-Signal: Feuert RETURN_RESOLUTION_EXECUTED.

4. Statusmodelle

registered (RMA erteilt) ➔ waiting_reception (Paket erwartet) ➔ received_quarantine (Im Prüflager) ➔ inspecting (In Begutachtung) ➔ resolution_approved (Entscheidung getroffen) ➔ completed (Abgewickelt) oder rejected (Abgelehnt).

🤖

KI-Consultant Leitfaden: Customizing- & No-Code-Konzept (Soll-Ist-Synthese)

AI Solution Architect Blueprint

KI-Consultant Blueprint: Customizing & No-Code Architektur

Anleitung für Solution Architects zur Einrichtung von Reklamations- und Gewährleistungsprozessen.

1. Kundenanforderungsanalyse

Welche Reklamationsgründe sind branchenspezifisch relevant (z.B. Maßabweichung, Transportschaden, Softwarefehler)?
Soll bei Geringwertartikeln (z.B. Warenwert < 20 €) auf die physische Rücksendung verzichtet werden (No-Return Refund)?
Wie lange sind vertragliche Garantiefristen (12, 24, 36 Monate)?

2. No-Code Zusatzfelder (Custom Fields)

Im No-Code Studio (/semantic/customizing):

Auf ReturnAuthorization:
- carrier_tracking_return_number (Text): Sendungsverfolgungsnummer des Retourenpakets.
- freight_cost_credited (Checkbox): Werden dem Kunden die Rücksendekosten erstattet?
Auf ReturnLine:
- serial_number_scanned (Text): Exakter Abgleich der Geräteseriennummer.
- wear_and_tear_percent (Dezimal): Abzug bei Wertminderung durch übermäßige Nutzung.

3. No-Code Workflow Canvas DAGs

Blueprint A: No-Return Kulanz-Erstattung für Geringwertartikel

Trigger-Node: cap:returns.rma.create wird aufgerufen.
Condition-Node: rma.total_claimed_amount < 25.00 AND customer.credit_standing == 'good'.
Action-Node 1: Überspringe physischen Rückversand; rufe direkt cap:returns.rma.trigger_credit_note auf.
Action-Node 2: Sende kundenfreundliche E-Mail: Betrag erstattet – Artikel darf entsorgt oder behalten werden.

Blueprint B: Automatischer Lieferantenregress bei Zukaufteilen

Trigger-Node: cap:returns.rma.record_inspection deklariert root_cause == 'supplier_defect'.
Action-Node: Erzeuge automatisch einen SupplierClaim im Einkaufsmodul mit Referenz auf den Lieferanten und die Original-Bestellnummer, blockiere Zahlungen an den Lieferanten.

📚 Operative Prozessbegriffe & Transaktionsschnittstellen

Zentrale Fachbegriffe im Prozesszusammenhang (Operatives Modell)

RMA (Return Merchandise Authorization)

Autorisierungsnummer für die Rücksendung zur eindeutigen Paketidentifikation.

Quarantänelager / Sperrlager

Physisch und buchhalterisch getrennter Lagerbereich für ungeprüfte Rücksendungen.

Mängelrüge & Gewährleistung (§ 437 BGB)

Gesetzlicher Anspruch des Käufers auf Nachbesserung, Ersatzlieferung oder Minderung.

Befundung & Fehlerklassifikation

Strukturierte Begutachtung zur Ermittlung der Schadensursache.

Rechnungskorrektur / Gutschrift

Fiskalische Rückbuchung des Rechnungsbetrags bei anerkannter Reklamation.

Lieferantenregress

Weitergabe von Gewährleistungs- und Schadensersatzansprüchen an den Vorlieferanten.

No-Return Refund

Kaufmännische Entscheidung zur Erstattung ohne Rücksendung bei geringem Warenwert.

📥 Eingänge & Trigger (Inputs)

Kundenbeschwerde per E-Mail, Telefon oder Kundenportal
Eintreffendes Rücksendepaket an der Rampe des Lagers
Transportschadenprotokoll des Frachtführers (Spedition/Paketdienst)
Qualitätsmeldungen des Kunden mit Schadensfotos

📤 Ausgänge & Arbeitsergebnisse (Outputs)

RMA-Rücksendeschein mit Paketlabel für den Kunden
Befundungsprotokoll mit Messwerten und Schadensursachen
Revisionssichere Gutschriften und Rechnungskorrekturen
Kostenlose Ersatzlieferungsaufträge für den Warenausgang
Lieferantenreklamationen für den Einkauf

⚡ Kaskaden & Folgeprozesse (Cascades)

rma_received -> quarantine_stock_increase: Einlagerung in das gesperrte Prüflager
resolution_credit -> invoice_credit_note_generated: Erzeugung der kaufmännischen Gutschrift
resolution_replacement -> sales_order_replacement_created: Auslösung des Nachlieferungsauftrags
supplier_defect_detected -> trigger_supplier_claim: Einsteuern in den Lieferantenregress

🛡️ Nebenprozesse & Resilienz

Regulierung von Transportschäden mit der Transportversicherung
Klärung unberechtigter Retouren (Rücksendung zu Lasten des Kunden)
Aufarbeitung und Sondervermarktung von Retouren als B-Ware
Schrottung und Entsorgungsnachweis bei unbrauchbaren Artikeln

💡 No-Code Checkliste & Praxistipps

Gewährleistungsfristen je Artikelkategorie im System konfigurieren
Katalog standardisierter Retourengründe für statistische Auswertungen pflegen
Wertgrenzen für automatische Kulanzgutschriften (No-Return) definieren
No-Code Zusatzfelder für Frachtführer-Tracking und Seriennummern auf ReturnLine anlegen

🗄️ Data Models & Fields

ReturnLines return_lines RLS Aktiv

30 Fields / Columns

Tabelle return_lines

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`return_id`	`UUID`	Ja *	FK ➔ return_orders.id	Feld return_id
`position`	`INTEGER`	Ja *	-	Feld position
`stock_owner`	`VARCHAR(16)`	Ja *	-	Feld stock_owner
`product_id`	`UUID`	Nein	FK ➔ products.id	Feld product_id
`stored_article_id`	`UUID`	Nein	FK ➔ stored_articles.id	Feld stored_article_id
`asset_id`	`UUID`	Nein	FK ➔ assets.id	Feld asset_id
`invoice_item_id`	`UUID`	Nein	FK ➔ invoice_items.id	Feld invoice_item_id
`description`	`VARCHAR(255)`	Ja *	-	Feld description
`unit`	`VARCHAR(32)`	Ja *	-	Feld unit
`unit_price`	`NUMERIC(14, 2)`	Nein	-	Feld unit_price
`tax_rate`	`NUMERIC(6, 3)`	Nein	-	Feld tax_rate
`quantity_requested`	`NUMERIC(14, 4)`	Ja *	-	Feld quantity_requested
`quantity_received`	`NUMERIC(14, 4)`	Ja *	-	Feld quantity_received
`quantity_accepted`	`NUMERIC(14, 4)`	Ja *	-	Feld quantity_accepted
`from_location_id`	`UUID`	Nein	FK ➔ locations.id	Feld from_location_id
`tracking_codes`	`JSONB`	Ja *	-	Feld tracking_codes
`reason_id`	`UUID`	Nein	FK ➔ return_reasons.id	Feld reason_id
`condition_grade`	`VARCHAR(1)`	Nein	-	Feld condition_grade
`disposition`	`VARCHAR(24)`	Nein	-	Feld disposition
`disposition_location_id`	`UUID`	Nein	FK ➔ locations.id	Feld disposition_location_id
`disposed_at`	`DATETIME`	Nein	-	Feld disposed_at
`unit_cost`	`NUMERIC(14, 2)`	Nein	-	Feld unit_cost
`inspection_notes`	`TEXT`	Nein	-	Feld inspection_notes
`photo_document_ids`	`JSONB`	Ja *	-	Feld photo_document_ids
`child_return_id`	`UUID`	Nein	FK ➔ return_orders.id	Feld child_return_id
`id`	`UUID`	Nein	PK	Feld id
`tenant_id`	`UUID`	Ja *	FK ➔ organizations.id	Feld tenant_id
`created_at`	`DATETIME`	Ja *	-	Feld created_at
`updated_at`	`DATETIME`	Ja *	-	Feld updated_at
`metadata`	`JSONB`	Ja *	-	Feld metadata

ReturnNotes return_notes RLS Aktiv

9 Fields / Columns

Tabelle return_notes

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`return_id`	`UUID`	Ja *	FK ➔ return_orders.id	Feld return_id
`author_id`	`UUID`	Nein	-	Feld author_id
`kind`	`VARCHAR(16)`	Ja *	-	Feld kind
`body`	`TEXT`	Ja *	-	Feld body
`id`	`UUID`	Nein	PK	Feld id
`tenant_id`	`UUID`	Ja *	FK ➔ organizations.id	Feld tenant_id
`created_at`	`DATETIME`	Ja *	-	Feld created_at
`updated_at`	`DATETIME`	Ja *	-	Feld updated_at
`metadata`	`JSONB`	Ja *	-	Feld metadata

ReturnOrders return_orders RLS Aktiv

46 Fields / Columns

Tabelle return_orders

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`rma_number`	`VARCHAR(64)`	Ja *	-	Feld rma_number
`kind`	`VARCHAR(24)`	Ja *	-	Feld kind
`status`	`VARCHAR(16)`	Ja *	-	Feld status
`channel`	`VARCHAR(16)`	Ja *	-	Feld channel
`public_token`	`UUID`	Ja *	-	Feld public_token
`customer_id`	`UUID`	Nein	FK ➔ customers.id	Feld customer_id
`supplier_id`	`UUID`	Nein	FK ➔ suppliers.id	Feld supplier_id
`contract_id`	`UUID`	Nein	FK ➔ contracts.id	Feld contract_id
`invoice_id`	`UUID`	Nein	FK ➔ invoices.id	Feld invoice_id
`work_order_id`	`UUID`	Nein	FK ➔ work_orders.id	Feld work_order_id
`project_id`	`UUID`	Nein	FK ➔ projects.id	Feld project_id
`rental_booking_id`	`UUID`	Nein	FK ➔ rental_bookings.id	Feld rental_booking_id
`ticket_id`	`UUID`	Nein	FK ➔ tickets.id	Feld ticket_id
`parent_return_id`	`UUID`	Nein	FK ➔ return_orders.id	Feld parent_return_id
`policy_id`	`UUID`	Nein	FK ➔ return_policies.id	Feld policy_id
`reason_id`	`UUID`	Nein	FK ➔ return_reasons.id	Feld reason_id
`reason_text`	`TEXT`	Nein	-	Feld reason_text
`resolution`	`VARCHAR(24)`	Nein	-	Feld resolution
`restocking_fee_percent`	`NUMERIC(5, 2)`	Ja *	-	Feld restocking_fee_percent
`credit_note_id`	`UUID`	Nein	FK ➔ invoices.id	Feld credit_note_id
`replacement_ref`	`VARCHAR(255)`	Nein	-	Feld replacement_ref
`repair_work_order_id`	`UUID`	Nein	FK ➔ work_orders.id	Feld repair_work_order_id
`charge_invoice_id`	`UUID`	Nein	FK ➔ invoices.id	Feld charge_invoice_id
`credit_amount`	`NUMERIC(14, 2)`	Nein	-	Feld credit_amount
`carrier`	`VARCHAR(128)`	Nein	-	Feld carrier
`tracking_number`	`VARCHAR(128)`	Nein	-	Feld tracking_number
`return_location_id`	`UUID`	Nein	FK ➔ locations.id	Feld return_location_id
`pickup_address`	`TEXT`	Nein	-	Feld pickup_address
`risk_score`	`INTEGER`	Ja *	-	Feld risk_score
`risk_flags`	`JSONB`	Ja *	-	Feld risk_flags
`requested_at`	`DATETIME`	Nein	-	Feld requested_at
`approved_at`	`DATETIME`	Nein	-	Feld approved_at
`shipped_at`	`DATETIME`	Nein	-	Feld shipped_at
`received_at`	`DATETIME`	Nein	-	Feld received_at
`inspected_at`	`DATETIME`	Nein	-	Feld inspected_at
`resolved_at`	`DATETIME`	Nein	-	Feld resolved_at
`notes`	`TEXT`	Nein	-	Feld notes
`id`	`UUID`	Nein	PK	Feld id
`tenant_id`	`UUID`	Ja *	FK ➔ organizations.id	Feld tenant_id
`created_at`	`DATETIME`	Ja *	-	Feld created_at
`updated_at`	`DATETIME`	Ja *	-	Feld updated_at
`created_by`	`UUID`	Nein	-	Feld created_by
`updated_by`	`UUID`	Nein	-	Feld updated_by
`source_type`	`VARCHAR(32)`	Nein	-	Feld source_type
`source_id`	`UUID`	Nein	-	Feld source_id
`metadata`	`JSONB`	Ja *	-	Feld metadata

ReturnPolicies return_policies RLS Aktiv

22 Fields / Columns

Tabelle return_policies

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`name`	`VARCHAR(255)`	Ja *	-	Feld name
`customer_id`	`UUID`	Nein	FK ➔ customers.id	Feld customer_id
`contract_id`	`UUID`	Nein	FK ➔ contracts.id	Feld contract_id
`is_default`	`BOOLEAN`	Ja *	-	Feld is_default
`window_days`	`INTEGER`	Ja *	-	Feld window_days
`auto_approve`	`BOOLEAN`	Ja *	-	Feld auto_approve
`restocking_fee_percent`	`NUMERIC(5, 2)`	Ja *	-	Feld restocking_fee_percent
`require_inspection`	`BOOLEAN`	Ja *	-	Feld require_inspection
`shipping_paid_by`	`VARCHAR(16)`	Ja *	-	Feld shipping_paid_by
`grade_credit_percent`	`JSONB`	Ja *	-	Feld grade_credit_percent
`condition_matrix`	`JSONB`	Ja *	-	Feld condition_matrix
`max_return_rate_percent`	`NUMERIC(5, 2)`	Ja *	-	Feld max_return_rate_percent
`active`	`BOOLEAN`	Ja *	-	Feld active
`id`	`UUID`	Nein	PK	Feld id
`tenant_id`	`UUID`	Ja *	FK ➔ organizations.id	Feld tenant_id
`created_at`	`DATETIME`	Ja *	-	Feld created_at
`updated_at`	`DATETIME`	Ja *	-	Feld updated_at
`created_by`	`UUID`	Nein	-	Feld created_by
`updated_by`	`UUID`	Nein	-	Feld updated_by
`source_type`	`VARCHAR(32)`	Nein	-	Feld source_type
`source_id`	`UUID`	Nein	-	Feld source_id
`metadata`	`JSONB`	Ja *	-	Feld metadata

ReturnReasons return_reasons RLS Aktiv

16 Fields / Columns

Tabelle return_reasons

Feldname	Data Type	Required	Schlüssel	Functional Meaning
`code`	`VARCHAR(32)`	Ja *	-	Feld code
`label`	`VARCHAR(255)`	Ja *	-	Feld label
`category`	`VARCHAR(32)`	Ja *	-	Feld category
`fault_party`	`VARCHAR(16)`	Ja *	-	Feld fault_party
`default_disposition`	`VARCHAR(24)`	Nein	-	Feld default_disposition
`default_resolution`	`VARCHAR(24)`	Nein	-	Feld default_resolution
`active`	`BOOLEAN`	Ja *	-	Feld active
`id`	`UUID`	Nein	PK	Feld id
`tenant_id`	`UUID`	Ja *	FK ➔ organizations.id	Feld tenant_id
`created_at`	`DATETIME`	Ja *	-	Feld created_at
`updated_at`	`DATETIME`	Ja *	-	Feld updated_at
`created_by`	`UUID`	Nein	-	Feld created_by
`updated_by`	`UUID`	Nein	-	Feld updated_by
`source_type`	`VARCHAR(32)`	Nein	-	Feld source_type
`source_id`	`UUID`	Nein	-	Feld source_id
`metadata`	`JSONB`	Ja *	-	Feld metadata

🔌 Entry Points (UI & APIs)

Art	Method	Endpoint / Path	Titel & Zweck	Required Role
⚡ REST API	GET	`/api/v1/returns`	list_returns Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/analytics`	analytics Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/contract/{contract_id}/returnables`	contract_returnables Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/invoice/{invoice_id}/items`	invoice_items Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/meta`	meta Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/party-context`	party_context Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/policies`	list_policies Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/reasons`	list_reasons Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/{return_id}`	get_return Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/api/v1/returns/{return_id}/credit-preview`	credit_preview Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/portal/{slug}/retouren`	returns_page Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/pub/retoure/status/{token}`	return_status Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/pub/retoure/status/{token}/slip`	return_slip Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/pub/retoure/{tenant_id}`	return_form Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/returns`	returns_list_page Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/returns/analytics`	returns_analytics_page Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/returns/new`	returns_new_page Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/returns/settings`	returns_settings_page Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/returns/{return_id}`	returns_detail_page Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	GET	`/returns/{return_id}/print`	returns_print_page Semantic binding: inventory_only; mutation=False	`returns`
⚡ REST API	PATCH	`/api/v1/returns/policies/{policy_id}`	update_policy Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	PATCH	`/api/v1/returns/reasons/{reason_id}`	update_reason Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns`	create_return Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/collective-credit-note`	create_collective_credit_note Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/policies`	create_policy Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/reasons`	create_reason Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/approve`	approve Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/cancel`	cancel Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/close`	close Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/escalate-ticket`	escalate_to_ticket Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/inspect`	inspect Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/lines/{line_id}/photos`	add_photos Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/notes`	add_note Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/receive`	receive Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/reject`	reject Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/resolve`	resolve Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/api/v1/returns/{return_id}/ship`	ship Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/portal/{slug}/retouren/anfordern`	return_request Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/pub/retoure/{tenant_id}`	return_lookup Semantic binding: operator_surface; mutation=True	`returns`
⚡ REST API	POST	`/pub/retoure/{tenant_id}/submit`	return_submit Semantic binding: operator_surface; mutation=True	`returns`

🛡️ Regulatory & Compliance

Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:

BGB Widerrufsrecht (§355)
Gewährleistungsrecht (§437 BGB)
GoBD Gutschriftennachweis

Related Modules:

➔ inventory ➔ finance ➔ customers ➔ portal