Shared Catalog Fallback Mechanism

Back to Portal

A technical breakdown of how the Ayko_SharedCatalog fallback mechanism operates within the Penn-Elcom Magento 2 codebase. This module solves the issue of having to explicitly define every B2B price in every shared catalog.

1. The Business Context & Goal

Penn-Elcom use customer groups which they name as "Special Pricing Agreement". This is where Penn-Elcom and a Business agree a special price for a subsection of products.

For products not specifically included in that business's agreement, they will fall into a larger group tier rather than defaulting to the standard retail price.

Overview of the Special Pricing Agreements and Fallback Groups (Click to view full size)

The technical goal of the Ayko_SharedCatalog module is to facilitate this behavior efficiently. If a B2B Customer Group (Shared Catalog) does not have an explicitly defined price for a specific product, the system must fallback to a designated parent catalog's price without complex frontend calculation overhead.

Configuring the Fallback Customer Group for a Catalog (Click to view full size)

2. Database Schema Extensions

To power this relationship, the module extends the core schema:

DB Table: A new column fallback_group_id is added to the shared_catalog table via db_schema.xml.
Extension Attributes: The Customer Group API (GroupInterface) is extended with a fallback_customer_group attribute, linking the shared catalog fallback directly to the customer group.

3. Indexer Interception (The Core Engine)

The heavy lifting of the fallback mechanism is deliberately executed at the Index Level rather than the Frontend to ensure performance. It relies on two key plugins:

Plugin: `Price\Action` & `Price\TierPrice`

The module hooks into the afterExecute method of Magento's native Price Indexer. When Magento finishes indexing standard prices into dimension tables (e.g., catalog_product_index_price_cg31_ws1), the Ayko plugin runs a secondary routine:

It loops through all logged-in Customer Groups and checks if they have a fallbackGroupId assigned.
If a fallback exists, it resolves the specific dimension table of that fallback group (e.g., cg7_ws1).
It constructs a highly efficient INSERT ... ON DUPLICATE KEY UPDATE SQL query.
The Filter: It explicitly filters out products that already have a tier price in the primary group using a LEFT JOIN. It strictly looks for:

pi.entity_id IS NULL OR pi.tier_price IS NULL

This guarantees that explicit primary prices are never overwritten by the fallback.
It injects the missing fallback prices directly into the primary group's index table.

// The core SQL condition ensuring only missing prices fallback
$select->joinLeft(
    ['pi' => $conn->getTableName($primaryTable)],
    'pi.entity_id = fb.entity_id AND pi.customer_group_id = ' . $primaryGroupId,
    []
);
$select->where('pi.entity_id IS NULL OR pi.tier_price IS NULL');
        

Search Integration Impact

Because this fallback mechanism injects the final computed prices directly into the core Magento index tables (catalog_product_index_price and tier price tables), any search engine that reads prices natively from the Magento index (like ElasticSuite) will automatically inherit these fallback prices without any extra API work.