Shared Catalogs in Magento 2: Kundenspezifische Kataloge und Preisstrategien

1. Shared Catalogs im B2B-Kontext einordnen

Ein Shared Catalog ist eine benannte Teilmenge des öffentlichen Katalogs, die einer oder mehreren Companies zugewiesen wird und damit steuert, welche Kategorien und Produkte für deren Mitglieder überhaupt sichtbar sind. Anders als eine reine Kundengruppen-Preisregel geht ein Shared Catalog also über die Preisgestaltung hinaus und wirkt zusätzlich auf die Sichtbarkeit ganzer Kategorien.

Jede Company im Standardsetup ist genau einem Shared Catalog zugeordnet, standardmäßig dem öffentlichen Katalog, der alle Kategorien ohne Einschränkung zeigt. Sobald ein eigener Shared Catalog angelegt und einer Company zugewiesen wird, sehen deren Mitglieder ausschließlich die dort freigegebenen Kategorien, unabhängig davon, wie der Katalog für anonyme Besucher oder andere Companies aussieht.

2. Technischer Aufbau: virtuelle Kundengruppe und Category Permissions

Unter der Haube ist ein Shared Catalog kein völlig neues Konzept, sondern eine Kombination aus zwei bestehenden Mechanismen. Beim Anlegen eines Shared Catalogs erzeugt Magento automatisch eine eigene, für Administratoren im regulären Kundengruppen-Grid verborgene Customer Group, die intern als Bindeglied zwischen Company und Katalog dient. Diese virtuelle Gruppe wird anschließend genau wie eine reguläre Kundengruppe von der Category-Permissions-Funktion des Moduls Magento_CatalogPermissions verwendet.

Für jede Kategorie lässt sich pro Kundengruppe eine Berechtigung von ALLOW, DENY oder ALLOW_PARTIAL hinterlegen, wobei ALLOW_PARTIAL die Kategorie zwar in der Navigation zeigt, aber den Produktinhalt sperrt. Ein Shared Catalog setzt diese Berechtigungen für seine virtuelle Kundengruppe gezielt, sodass Kategorien außerhalb der freigegebenen Struktur für Mitglieder der zugewiesenen Company effektiv unsichtbar bleiben, technisch aber weiterhin über den Category-Permissions-Index gefiltert werden.

<?php

declare(strict_types=1);

namespace Mironsoft\SharedCatalogExtension\Model;

use Magento\CatalogPermissions\App\ConfigInterface;
use Magento\CatalogPermissions\Model\Permission;
use Magento\SharedCatalog\Api\SharedCatalogRepositoryInterface;

/**
 * Liest die effektive Category-Permission für die virtuelle Kundengruppe
 * eines Shared Catalogs aus, um sie in einem eigenen Report auszuwerten.
 */
class SharedCatalogPermissionReader
{
    /**
     * @param SharedCatalogRepositoryInterface $sharedCatalogRepository
     * @param ConfigInterface $permissionsConfig
     */
    public function __construct(
        private readonly SharedCatalogRepositoryInterface $sharedCatalogRepository,
        private readonly ConfigInterface $permissionsConfig,
    ) {
    }

    /**
     * Liefert true, wenn die angegebene Kategorie für den Shared Catalog sichtbar ist.
     *
     * @param int $sharedCatalogId
     * @param int $categoryId
     * @return bool
     */
    public function isCategoryVisible(int $sharedCatalogId, int $categoryId): bool
    {
        $sharedCatalog = $this->sharedCatalogRepository->get($sharedCatalogId);
        $customerGroupId = (int) $sharedCatalog->getCustomerGroupId();

        return $this->permissionsConfig->getPermission($categoryId, 0, $customerGroupId)
            !== Permission::PERMISSION_DENY;
    }
}

3. Sichtbarkeit vs. Bestellbarkeit sauber trennen

Ein häufiges Missverständnis ist, Sichtbarkeit und Bestellbarkeit als denselben Mechanismus zu behandeln. Category Permissions steuern ausschließlich, ob eine Kategorie oder ein Produkt in der Navigation und Suche auftaucht, nicht ob ein Produkt tatsächlich bestellt werden darf. Ein Produkt kann technisch sichtbar, aber über andere Mechanismen wie Lagerbestand oder Mindestbestellmengen trotzdem nicht bestellbar sein, und umgekehrt lässt sich ein Produkt über eine DENY-Regel unsichtbar machen, obwohl es preislich und lagerseitig bestellbar wäre.

Für eigene Erweiterungen bedeutet das, dass Sichtbarkeitsprüfungen und Preisprüfungen getrennt implementiert werden müssen. Wer etwa einen eigenen Produkt-Feed für einen Shared Catalog bauen will, darf sich nicht allein auf den Category-Permissions-Index verlassen, sondern muss zusätzlich die Preisüberschreibungen des Katalogs und die reguläre Katalog-Sichtbarkeit des Produkts selbst berücksichtigen, um ein konsistentes Ergebnis zu erhalten.

4. Preisüberschreibungen pro Katalog

Neben der Sichtbarkeit ist die zweite zentrale Funktion eines Shared Catalogs die Preisgestaltung. Für jeden Katalog lässt sich pro Produkt entweder ein fester Preis oder eine prozentuale beziehungsweise absolute Abweichung vom regulären Katalogpreis hinterlegen. Technisch laufen diese Überschreibungen über dieselbe Preisregel-Infrastruktur, die auch für reguläre Catalog Price Rules verwendet wird, nur zielgerichtet auf die virtuelle Kundengruppe des jeweiligen Shared Catalogs.

Für die Pflege großer Preislisten bietet die Verwaltung einen Export als Excel-Tabelle, in der pro Produkt Preis und Sichtbarkeit gemeinsam bearbeitet und anschließend wieder importiert werden können. Für automatisierte Preispflege aus einem externen ERP-System empfiehlt sich stattdessen ein eigener Import über die Preisregel-APIs, der denselben Datenpfad nutzt, aber ohne den manuellen Excel-Umweg auskommt und sich in einen bestehenden Preissynchronisationsprozess einbetten lässt.

5. Shared Catalogs programmatisch verwalten

Über Magento\SharedCatalog\Api\SharedCatalogRepositoryInterface und SharedCatalogManagementInterface lassen sich Shared Catalogs vollständig programmatisch anlegen, Kategorien zuweisen und Companies verknüpfen, ohne den Admin manuell zu bedienen. Das ist besonders relevant für Projekte, in denen neue Firmenkunden automatisiert aus einem externen System angelegt werden und dabei sofort einen passenden Katalog zugewiesen bekommen sollen.

Für Bulk-Operationen, etwa das gleichzeitige Anpassen von hunderten Produktpreisen in einem Katalog, ist ein direkter Aufruf über die Preisregel-Services deutlich effizienter als hunderte einzelne Repository-Aufrufe, weil sich so unnötige Einzeltransaktionen und wiederholte Neuberechnungen der Preisregel vermeiden lassen.

6. Automatische Katalogzuweisung per Plugin

Ein typischer Erweiterungsfall ist die automatische Zuweisung eines passenden Shared Catalogs, sobald eine neue Company angelegt wird, etwa basierend auf einem benutzerdefinierten Attribut wie Kundensegment oder Vertriebsregion. Dafür bietet sich ein Plugin auf der Company-Anlage an, das nach dem erfolgreichen Speichern prüft, welcher Shared Catalog anhand der hinterlegten Regel passt, und die Zuweisung automatisch vornimmt.

Wichtig ist dabei, die Zuweisung nicht direkt im before-Teil eines Plugins auszuführen, weil zu diesem Zeitpunkt die Company-ID noch nicht feststeht. Ein after-Plugin auf der Save-Methode ist hier der richtige Ansatz, da die vollständige, gespeicherte Company-Entität inklusive ID zur Verfügung steht und die Zuweisung sicher nachgezogen werden kann.

<?php

declare(strict_types=1);

namespace Mironsoft\SharedCatalogExtension\Plugin;

use Magento\Company\Api\CompanyRepositoryInterface;
use Magento\Company\Api\Data\CompanyInterface;
use Magento\SharedCatalog\Api\SharedCatalogManagementInterface;
use Mironsoft\SharedCatalogExtension\Model\SegmentCatalogResolver;

/**
 * Weist einer neu angelegten Company automatisch den zum Kundensegment
 * passenden Shared Catalog zu.
 */
class AssignCatalogOnCompanyCreatePlugin
{
    /**
     * @param SegmentCatalogResolver $catalogResolver
     * @param SharedCatalogManagementInterface $catalogManagement
     */
    public function __construct(
        private readonly SegmentCatalogResolver $catalogResolver,
        private readonly SharedCatalogManagementInterface $catalogManagement,
    ) {
    }

    /**
     * @param CompanyRepositoryInterface $subject
     * @param CompanyInterface $result
     * @return CompanyInterface
     */
    public function afterSave(CompanyRepositoryInterface $subject, CompanyInterface $result): CompanyInterface
    {
        $sharedCatalogId = $this->catalogResolver->resolveForCompany($result);
        if ($sharedCatalogId !== null) {
            $this->catalogManagement->assignCompany((int) $result->getId(), $sharedCatalogId);
        }

        return $result;
    }
}

7. Indexierung: Category Permissions und Preisindex

Jeder Shared Catalog erzeugt intern eine eigene Kundengruppe, und der Category-Permissions-Index sowie der Produktpreis-Index arbeiten beide über eine Matrix aus Kundengruppe mal Kategorie beziehungsweise Kundengruppe mal Produkt. Mit jedem zusätzlichen Shared Catalog wächst diese Matrix, was sich direkt auf die Laufzeit der entsprechenden Indexer auswirkt, besonders bei großen Katalogen mit vielen Kategorien.

In der Praxis bedeutet das, dass ein vollständiger Reindex nach dem Anlegen mehrerer neuer Shared Catalogs spürbar länger dauern kann als vorher, weil sowohl die Sichtbarkeits- als auch die Preisberechnung für jede zusätzliche virtuelle Gruppe erneut durchlaufen werden muss. Wer viele Kataloge parallel plant, sollte den Indexer-Modus und die verfügbaren Ressourcen des Indexierungs-Crons entsprechend im Blick behalten.

8. Performance-Implikationen bei vielen Shared Catalogs

Ab einer bestimmten Anzahl paralleler Shared Catalogs, in der Praxis häufig irgendwo im mittleren zweistelligen Bereich abhängig von Katalog- und Kategoriegröße, wird die Indexierungslast spürbar. Statt für jedes einzelne Kundensegment einen eigenen Katalog anzulegen, lohnt sich häufig eine Konsolidierung: Ähnliche Preisstrategien lassen sich oft über gemeinsame Kataloge mit zusätzlichen, granuleren Preisregeln abdecken, statt für jede kleine Abweichung eine neue virtuelle Kundengruppe zu erzeugen.

Für Shops mit wirklich vielen unterschiedlichen Firmenkunden empfiehlt sich außerdem, den vollständigen Reindex bewusst außerhalb der Stoßzeiten zu planen und den Schedule-Modus für die betroffenen Indexer zu verwenden, statt bei jeder kleinen Preisänderung eine sofortige, synchrone Neuberechnung über den gesamten Katalog auszulösen.

9. Betrieb: Pflege und Nachvollziehbarkeit

Da Shared Catalogs sowohl Sichtbarkeit als auch Preise steuern, lohnt sich eine klare interne Dokumentation, welcher Katalog welchem Kundensegment mit welcher Preislogik zugeordnet ist. Ohne diese Übersicht wird es bei wachsender Katalogzahl schnell unübersichtlich, welche Company welche Preise sieht, insbesondere wenn mehrere Kataloge über die Zeit von unterschiedlichen Teammitgliedern gepflegt wurden.

Für Audits und Support-Anfragen ist außerdem sinnvoll, sich nicht nur auf die Admin-Oberfläche zu verlassen, sondern die zugrunde liegende Kundengruppen-Zuordnung und die Category-Permissions-Einträge auch direkt in der Datenbank nachvollziehen zu können, gerade wenn ein Kunde meldet, ein Produkt fälschlich zu sehen oder nicht zu sehen.

10. Zusammenfassung

11. FAQ: Shared Catalogs Preisstrategie