Haufe X360: Master/Slave-Artikellogik für konfigurierte Produkte (Master/Slave/Subslave)

Warenwirtschaft
, , , , ,
1

Ausgangslage

In vielen Handels- und Fertigungsprozessen reicht eine „flache“ Artikelanlage nicht aus, wenn Produkte konfiguriert werden müssen. Typisches Beispiel: Ein Fahrzeug (Basisprodukt) wird verkauft oder intern disponiert, und dazu gibt es passende Erweiterungen/Zubehör. In der Praxis entstehen dann zwei wiederkehrende Probleme:

  • Im Vorgang (Angebot/Auftrag/Bestellung) werden unpassende Artikel ergänzt, weil das System keine Abhängigkeiten kennt.

  • Die Artikelauswahl wird unübersichtlich, weil Anwender:innen aus sehr vielen Artikeln „von Hand“ die richtigen kombinieren müssen.

Lösung: Master/Slave/Subslave-Logik (3-stufig)

Wir haben eine Customization entwickelt, mit der sich in Haufe X360 eine Master/Slave-Artikellogik abbilden lässt. Ziel ist es, Artikel regelbasiert miteinander in Beziehung zu setzen und die Auswahl im Vorgang zu führen.

Konzept:

  • Master: das Basisprodukt (z. B. Fahrzeugmodell)

  • Slave: kompatible Erweiterungen/Optionen (z. B. Ausstattungspakete, Zubehör)

  • Subslave: optionale Unterkomponenten/abhängige Erweiterungen (z. B. Zubehör zum Paket, Ergänzungen, Varianten)

Damit lassen sich Kompatibilitätsregeln sauber abbilden: Zu einem gewählten Master dürfen nur die dafür freigegebenen Slaves/Subslaves hinzugefügt werden.

Kernnutzen

1) Fehlervermeidung („nur passend zum Master“)

  • Es wird verhindert, dass Anwender:innen Artikel hinzufügen, die nicht kompatibel sind.

  • Das reduziert Nacharbeit, Stornos, Rückfragen und Falschlieferungen.

2) Schneller konfigurieren durch geführte Auswahl

  • Artikel werden im Vorgang automatisch nach dem gewählten Master gruppiert.

  • Passende Slaves/Subslaves erscheinen strukturiert, statt über Suche/Listen mühsam ausgewählt zu werden.

3) Einheitliche Prozesslogik und höhere Datenqualität

  • Standardisierte Konfigurationen sorgen für konsistente Belege und bessere Auswertbarkeit (z. B. welche Pakete wurden zu welchem Master verkauft).

Wie es im Prozess funktioniert (vereinfacht)

  1. Anwender:in wählt einen Master-Artikel im Beleg (z. B. Angebot/Auftrag/Bestellung).

  2. Das System zeigt anschließend nur noch zulässige Slave-Artikel für diesen Master an bzw. erlaubt nur diese.

  3. Wird ein Slave gewählt, können optional passende Subslaves angeboten/zugelassen werden (abhängig vom gewählten Slave und/oder Master).

  4. Die Belegpositionen werden sichtbar gruppiert (Master als „Klammer“, darunter die zugeordneten Slaves/Subslaves).

Typische Einsatzszenarien

  • Konfigurierbare Produkte (Fahrzeuge, Maschinen, Anlagen, IT-Hardware-Bundles)

  • Zubehör-/Add-on-Logik (nur kompatibles Zubehör je Basismodell)

  • Service-/Wartungsverträge passend zu Produktvarianten

  • Bundles/Sets mit optionalen Erweiterungsstufen

Fachliche Regeln, die abbildbar sind

  • „Slave A ist nur zulässig für Master X und Y“

  • „Subslave C ist nur zulässig, wenn Slave B gewählt wurde“

  • „Bestimmte Kombinationen sind ausgeschlossen“ (z. B. Option 1 und Option 2 nicht gemeinsam)

  • „Pflichtoptionen“ (optional, falls gewünscht): zu Master X muss mindestens ein Paket gewählt werden

(Welche Regeltypen genau umgesetzt sind, hängt von eurer konkreten Ausprägung ab; das Grundprinzip ist darauf ausgelegt, solche Kompatibilitäten systematisch abzubilden.)

Voraussetzungen und Empfehlungen

Damit die Logik nachhaltig funktioniert, empfehlen wir:

  • Saubere Artikelstammdaten (Artikeltypen/Warengruppen, eindeutige Benennung, Status aktiv/inaktiv)

  • Ein klarer Owner-Prozess für die Pflege der Beziehungen (wer darf Master/Slave-Zuordnungen ändern?)

  • Eine Governance für neue Artikel: „erst Beziehung definieren, dann freigeben“

  • Testfälle/Regelsatz: 10–20 typische Konfigurationen als Regressionstest

Grenzen und typische Stolperfallen

  • Je komplexer die Produktlogik, desto wichtiger sind klare Pflegeprozesse und ein sauberer „Regelbaukasten“.

  • Ohne definierte Verantwortlichkeiten entstehen schnell Ausnahmen („bitte einmal schnell freischalten“) – das untergräbt die Datenqualität.

  • Bei sehr großen Artikelmengen ist eine sinnvolle Gruppierung/Hierarchie entscheidend, damit die geführte Auswahl wirklich schneller ist.

Bereitstellung und Anpassungen

Die Lösung wird als Customizing/Customization in Haufe X360 bereitgestellt.
Erweiterungen (z. B. zusätzliche Regeltypen, spezifische UI-/Beleglogiken, weitere Stufen, Sondervalidierungen) erfolgen nach Aufwand.